共计 6938 个字符，预计需要花费 18 分钟才能阅读完成。
分享嘉宾：孙方彬 中国移动云能力核心 软件开发工程师
编辑整理：Hoh Xil
出品平台：DataFunTalk
导读：在云原生 + 大数据的时代，随着业务数据量的爆炸式增长以及对高时效性的要求，云原生大数据分析技术，经验了从传统数仓到数据湖，再到湖仓一体的演进。本文次要介绍挪动云云原生大数据分析 LakeHouse 的整体架构、外围性能、关键技术点，以及在私有云 / 公有云的利用场景。
次要内容包含：
- 湖仓一体概述
- 挪动云 LakeHouse
- 实际利用场景
01 湖仓一体概述
- 对于湖仓一体
“湖仓一体”是最近比拟火的一个概念，“湖仓一体”的概念最早起源于 Databricks 公司提出的 Lakehouse 架构，它不是某个产品，而是数据管理畛域中的一种凋谢的技术架构范例。随着大数据和云原生技术的倒退和交融，湖仓一体更能施展出数据湖的灵活性与生态丰富性，以及数据仓库的成长性。这里的成长性包含：服务器的老本，业务的性能，企业级的平安、治理等个性。
大家能够看到（左图），在特定业务规模前，数据湖的灵活性有肯定劣势，随着业务规模的增长，数据仓库的成长性更有劣势。
湖仓一体的 2 个关键点：
- 湖和仓的数据 / 元数据在不须要用户人工干预的状况下，能够无缝买通、自在顺畅地流（包含：由内向内入湖、由外向外出湖、围绕周边环湖）；
- 零碎依据特定的规定主动地将数据在湖仓之间进行缓存和挪动，并能与数据迷信相干的高级性能买通，进一步实现麻利剖析和深度智能。
- 次要理念
随着业务数据量的爆炸式增长以及业务对高时效性的要求，大数据分析技术经验了从传统数仓到数据湖，再到湖仓一体的演进。传统基于 Hadoop 的大数据平台架构也是一种数据湖架构，湖仓一体的核心理念以及与以后 Hadoop 集群架构的区别大抵如下：
- 存储多种格局的原始数据：以后 Hadoop 集群底层存储繁多，次要以 HDFS 为主，对于湖仓一体来说，逐步会演进为反对多种介质，多种类型数据的对立存储系统
- 对立的存储系统：以后依据业务分多个集群，之间大量数据传输，逐步演进到对立存储系统，升高集群间传输耗费
- 反对下层多种计算框架：以后 Hadoop 架构的计算框架以 MR/Spark 为主，将来演进为在数据湖上间接构建更多计算框架和利用场景
湖仓一体的产品状态大抵有两类：
- 基于私有云上数据湖架构的产品和解决方案（例如：阿里云 MaxCompute 湖仓一体、华为云 FusionInsight 智能数据湖）
- 基于开源 Hadoop 生态的组件（DeltaLake、Hudi、Iceberg）作为数据存储中间层（例如：Amazon 智能湖仓架构、Azure Synapse Analytics）
02 挪动云 LakeHouse 实际
上面介绍挪动云 LakeHouse 的整体架构及对湖仓一体的摸索和实际：
- 整体架构
上图是咱们的整体架构图，名字叫云原生大数据分析 LakeHouse。云原生大数据分析 LakeHouse 采纳计算和存储拆散架构，基于挪动云对象存储 EOS 和内置 HDFS 提供了反对 Hudi 存储机制的湖仓一体计划，通过内置 Spark 引擎进行交互式查问，能够疾速洞察业务数据变动。
咱们的架构具体包含：
- 数据源：包含 RDB、Kafka、HDFS、EOS、FTP，通过 FlinkX 一键入湖
- 数据存储（数据湖）：咱们内置了 HDFS 和挪动云的 EOS，借助 Hudi 实现 Upsert 能力，达到近实时的增量更新，咱们还适当地引入 Alluxio，进行数据缓存，来达到数据分析的 SQL 查问减速能力。
- 计算引擎：咱们的计算引擎都是 Severless 化的，跑在 Kubernetes 中。咱们引入了对立资源拜访 / 调度组件 YuniKorn，相似于传统 Hadoop 生态体系中 YARN 的资源调度，会有一些常见的调度算法，比方共性调度，先进先出等常见的调度
- 智能元数据：智能元数据发现，就是将咱们数据源的数据目录转化成内置存储中的一个 Hive 表，对立进行元数据管理
- 数据开发：SQLConsole，用户能够间接在页面上编写 SQL 进行交互查问；还有 SDK 的形式，以及 JDBC/ODBC 接口；后续咱们会反对 DevIDE，反对在页面上的 SQL 开发
- 外围性能
外围性能次要有以下四方面：
① 存储和计算拆散：
- 存储层与计算层拆散部署，存储和计算反对独立弹性扩缩容，相互之间没有影响
- 存储反对对象存储和 HDFS，HDFS 存储结构化数据，提供高性能存储，对象存储存储非结构化、原始数据、冷数据，提供高性价比
- 计算反对多引擎，Spark、Presto、Flink 均实现 serverless 化，即开即用，满足不同查问场景
② 一键入湖： - 反对连贯挪动云云上云下多种数据库、存储、音讯队列
- 入湖流程自动化，升高用户的配置老本
- 升高对数据源的额定负载，管制在 10% 以内，反对依据数据源的实例规格主动调整连接数（比方在 MySQL 同步数据时，会在 MySQL 负载容许的状况下，主动调整连接数）
- 反对增量更新（通过 Hudi 实现增量更新）
③ 智能元数据发现： - 基于特定的规定，智能辨认结构化、半结构化文件的元数据，构建数据目录
- 主动感知元数据变动
- 对立元数据，提供类 HiveMeta API，针对不同计算引擎拜访底层数据
- 智能数据路由和权限对立管控（借助挪动云的账号体系和 Ranger 实现的）
④ 按量计算： - 存储资源依照使用量计费
- 计算资源反对多种计费模式
- 反对弹性调整租户集群资源规格，疾速扩缩容
- 基于 RBF 的逻辑视图
在基于 Hive 结构的数据湖体系中，每个 Hive db 通常对应一个数仓实例，共享对立的存储 HDFS，为了实现存储资源的多租户隔离个性，咱们借鉴 RBF 的对立视图隔离能力，通过 Zookeeper 上不同的 Znode 来隔离多个数仓实例 StateStore，使每个数仓领有本人独立的逻辑视图，同时利用 RBF 挂载多 NameSpace 的能力来实现 NameNode 负载平衡的成果。此外，为适应云原生趋势，咱们将 RBF 服务容器化部署，在创立 Hive db 时指定由 RBF 形成的 HDFSschema 门路，能够实现资源疾速的创立、扩大和回收。
上图是咱们的一个简略的架构图，RBF 以 Pod 的模式部署在 Kubernetes 中，而后 Hivedb 别离映射为一个 RBF 的 schema 门路。而后，上面是借助了 NameSpace 的负载平衡能力。
这样，通过为用户提供独自的存储逻辑视图，不仅能够隔离不同数仓实例之间的数据，又能借助 RBF 对底层 HDFS 的负载平衡来实现对 Hive 数据的负载平衡能力。
例如，对 Hive db 目录 hivedbdir 通过 RBF 形式 mount 到两个 Namespace，挂载命令如下：
$ hdfs dfsrouteradmin -add/hivedbdir ns1,ns2 /data -order HASH_ALL- Hive 在对象存储的多租户实现
在私有云场景下，不同用户的 bucket 认证信息不同，须要屡次配置并重启 HiveServer 服务，无奈在对象存储上实现 Hive 多租户的成果。为解决这个问题，咱们通过批改 Hive 源码在表属性 tblproperties 中增加 s3 的认证参数，在拜访 bucket 时加载表属性中的认证信息至 threadlocal conf 变量，来实现 session 级别的认证参数传递。这样就在不重启 Hive 服务的状况下反对了多 bucket 认证，达到了对象存储上的 Hive 多租户成果。
如图所示，如果在服务端为用户配置不同的参数，就须要重启服务，这时不可能承受的。通过咱们的革新之后，建表语法就变成了上面这种格局：
create external table testcephtbl(id int) location 's3a://bucket1/tmp/testlocation' tblproperties('fs.s3a.access.key'='xxx,'fs.s3a.endpoint'='xxx','fs.s3a.secret.key'='xxx);- 优化引擎拜访对象存储
在大数据生态中，多种计算引擎都能够通过 Metastore 服务拜访 Hive 中的数据，例如 SparkSQL 要拜访存在对象存储中的 Hive 数据，须要在提交作业的 Driver 模块中依据表的 location 信息加载对应 bucket 认证信息，SQL 提交命令如下：
$SPARK_HOME/bin/beeline-u“jdbc:hive2://host:port/default?fs.s3a.access.key=xxx;fs.s3a.endpoint=xxx;fs.s3a.endpoint=xxx”-e“selecta.id from test1 a join test2 on a.id=b.id”也就是说，用户须要感知数据是存在对象存储中，并且很难确定一个 SQL 中的多个表属于哪几个 bucket，重大影响了业务开发进度。为此，咱们基于之前的 Hive 表属性实现了获取对象存储认证参数插件，用户无需感知 SQL 中的表来自哪个 bucket，也无需在提交 SQL 时指定认证参数。如上图橙色框所示，Spark SQL 在 Driver 中实现参数，来匹配认证参数信息。对 MetaStore 来说是一个对立的拜访视图。
最终提交 SQL 作业命令如下：
$SPARK_HOME/bin/beeline -u“jdbc:hive2://host:port/default”-e“select a.id from test1 a join test2 ona.id=b.id”- Serverless 实现
这里以 Spark 为例，通过 RBF 的多租户实现，Spark 过程运行在平安隔离的 K8S Namespace 中，每个 Namespace 依据资源规格对应不同的计算单元（例如：1CU=1 core * 4GB）。对于微批的场景，应用 SQL Console 每提交一个 task，engine 模块会启动一个 Spark 集群，为 Driver 和 Executor 按特定的算法申请相应的计算资源来运行计算工作，工作完结后资源即刻回收；对于即席 ad-hoc 的场景，能够应用 JDBC 提交 task，engine 模块通过 Kyuubi 服务启动一个 session 可配置的 spark 集群，长驻一段时间后回收资源；所有的 SQL task 只有在运行胜利后按理论的资源规格计费，如果不应用是不免费的。
逻辑视图如上，咱们的 Kubernetes 通过每个 Namespace 把资源进行隔离；下面是一个对立调度的 YuniKorn 进行 Capacity Management/Job Scheduling 的调度。再往上是 SQL Parser 组件，会把 SparkSQL 和 HiveSQL 语法进行兼容；最上方，咱们还提供了 Spark JAR 的形式，可能反对剖析 HBase 或者其它介质中结构化 / 半结构化的数据。
通过 Serverless 的实现，咱们大大的升高了用户的应用流程。
没有用 Serverless 时的流程：
① 购买服务器，构建集群
② 部署一套开源大数据根底组件：HDFS、Zookeeper、Yarn、Ranger、Hive 等③ 利用不同工具导入数据
④ 编写查问 SQL 计算，输入后果
⑤ 各种繁琐的运维
应用 Sercerless 后的流程：
① 注册挪动云账号，订购 LakeHouse 实例
② 创立数据同步工作
③ 编写查问 SQL 计算，输入后果
④ 服务全托管，全程无运维
- 元数据管理与发现
元数据管理模块基于特定规定，智能辨认结构化、半结构化文件的元数据来构建数据目录，通过周期性的元数据爬取实现主动感知元数据变动，并提供多种优化策略来升高爬取时对数据源的负载；同时，提供类 Hive Metastore 的 API 供多种计算引擎间接对表进行拜访：
元数据管理模块整体架构如左图所示：通过元数据爬取 RDB/EOS 数据，格局有 json/parquet/avro 等常见的半结构化数据，而后是 Hive MetaStore 对立拜访层，计算引擎 hive/spark/presto 能够通过类 metastore api 来拜访存在湖中的数据，用户通过 Web UI 进行目录映射。
文件类元数据发现过程，如右图所示：有一张表，上面有几个目录，比方按 year 离开的，而后在某个具体目录有两个子目录，对于它的元数据发现过程，就会呈现 3 行的数据，id、name 和 type，就会映射成同一张表，而后不同的目录是按不同的字段进行分区。
- Serverless 一键入湖
为实现 Serverless 的入湖创立，咱们采纳了基于 Flink 的分布式数据同步框架 FlinkX，来满足多种异构数据源之间高效的数据迁徙，具备以下特点：
- 资源弹性：作业运行在 Kubernetes 上，资源隔离，反对分布式运行和弹性扩缩容
- 灵活性：将源 / 指标数据源形象成 Reader/Writer 插件，反对双向读写和多种数据源
- 易用性：操作简化，反对批流一体、断点续传，可主动调整数据源连接数，升高侵入性
上图是咱们通过 FlinkX 进行调度工作的流程：
- 用户通过 JobManager 创立并提交 task 配置，通过 Quartz 调度 task，作业运行时调用 Flink Kubernetes 客户端拜访 Kubernetes Master 创立出 Flink Master 所须要的资源，并启动相应的 Container；
- Flink Master Deployment 外面内置一个用户 FlinkX Jar，这时 Cluster Entrypoint 就会从中去运行 main 函数，而后产生 JobGraph；之后再提交到 Dispatcher，Dispatcher 会启动一个 JobMaster 向 KubernetesResourceManager 申请资源，RM 发现没有可用的资源会持续向 Kubernetes Master 申请资源，申请资源之后将其发送回去，启动新的 TaskManager；
- TaskManager 启动之后再注册回来，此时 RM 再向它申请 slot 提供给 JobMaster，最初由 JobMaster 将相应的 FlinkX Task 部署到 TaskManager 上。这样整个 Flink 集群的拉起，到用户提交 Jar 都实现了。
咱们的 Flink 集群其实也是一种 serverless 的实现。
- JDBC 反对
为了晋升不同用户的数据分析体验，咱们基于 Apache Kyuubi 来反对多租户、多种计算引擎的 JDBC 连贯服务，Kyuubi 具备残缺的认证和受权服务，反对高可用性和负载平衡，并且提供两级弹性资源管理架构，能够无效进步资源利用率。
在接触 Kyuubi 前，咱们尝试应用了原生的 Spark thrift server 来实现，然而它有肯定的局限性，比方不反对多租户，单点的不具备高可用，资源是长驻的，资源调度须要本人来治理。咱们通过引入 Kyuubi 来反对多租户和高可用，通过 engine 动静申请开释，并且 Kyuubi 反对 Yarn 和 Kubernetes 资源调度。
在应用过程中，为了适配挪动云的账号体系以及 LakeHouse 架构，咱们对 Kyuubi 相应的模块进行了优化和革新，局部如下：
- 用户认证：基于挪动云 AccessKey，SecretKey 对接挪动云认证体系。
- 资源管理：Kyuubi 原生只反对用户指定资源，基于云原生适配后禁止用户指定资源，对立由 Lakehouse 进行资源调度和调配。
- 权限管控：适配 Lakehouse 底层权限管理体系，实现细粒度权限的管控。
- 云原生部署：基于 Helm3 的 kyuubi server 云原生部署，反对高可用和负载平衡
- 对象存储：反对对象存储表辨认和动静 ak，sk 权限认证
- 增量更新
咱们应用 Hudi 作为数据存储中间层，可能基于 HDFS、对象存储等底层存储，反对 ACID 语义、实现疾速更新能力。常见的流场景如下：
- 将 Kafka/MySQL binlog 中的数据借助 DeltaStreamer/CDC 通过定时 Flink 工作写入到 Hudi 表中
- 通过 Flink/Spark 工作同步 Hive 元数据
- 局部源数据批改
- 用户拜访和查问数据
如右图所示，咱们封装了 Hudi 自带的 DeltaStreamer / CDC，自定义 FlinkX 的 Reader / Writer 个性，实现 serverless 入湖和数据同步。
如左图所示，咱们比拟了两种数据格式：
- 对于实时性要求不高的场景尽量应用 COW（写时复制）表类型，如果对数据新鲜度有肯定要求则可应用 MOR（读写合并）
- MOR 会比 COW 更容易产生小文件并且对资源需要更高
以上就是挪动云 Lakehouse 实现的细节。
03 利用场景
最次要的场景是构建云原生大数据分析平台：LakeHouse 反对多样化数据起源，包含但不限于利用本身产生的数据、采集的各类日志数据、数据库中抽取的各类数据，并提供离线批处理、实时计算、交互式查问等能力，节俭了搭建传统大数据平台需投入的大量软硬件资源、研发老本及运维老本。
另外，在公有云场景下，在充分利用现有集群架构的前提下，以新增组件形式引入 Lakehouse 能力；引入数仓能力，适配多种数据对立存储和治理；对立元数据，造成湖仓一体的元数据视图：
- Hadoop 平台视图：Lakehouse 作为 Hadoop 平台上一个组件，可能提供 SQL 查问能力，并反对多种数据源
- 湖仓视图：基于 LakeHouse 提供数据湖仓平台，HDFS/OceanStor 提供存储，计算云原生，多种服务对立元数据管理。
明天的分享就到这里，谢谢大家。
分享嘉宾：