1. !"#$ %&'()*+ 移动云湖仓一体的探索与实践 中国移动云能力中心 2021年11月

2. 目录 S 01 湖仓一体概述 02 移动云LakeHouse实践 03 应用前景 目 录

3. 01 湖仓一体概述

4. 关于湖仓一体 “湖仓一体”的概念最早起源于Databricks公司提出的Lakehouse架构，它不是某个产品，而是数据管理领域中的一种开放的技术架构范例。随 着大数据和云原生技术的发展和融合，湖仓一体更能发挥出数据湖的灵活性与生态丰富性，以及数据仓库的成长性（成本、性能、安全、治理等 企业级能力）。 关键点一 湖和仓的数据/元数据在不需要用户人工干预 使 用 成 本 的情况下，可以无缝打通、自由顺畅地流动 （由外向内入湖、由内向外出湖、围绕周边环 云上数据湖 成长性 灵活性 湖） 关键点二 云数据仓库 系统根据特定的规则自动地将数据在湖仓之间 进行缓存和移动，并能与数据科学相关的高级 业务规模 功能打通，进一步实现敏捷分析和深度智能

5. 主要理念 随着业务数据量的爆炸式增长以及业务对高时效性的要求，大数据分析技术经历了从传统数仓到数据湖，再到湖仓一体的演进。传统基于 Hadoop的大数据平台架构也是一种数据湖架构，湖仓一体的核心理念以及与当前Hadoop集群架构的区别大致如下： 统一的存储系统 • 数据传输，逐渐演进到统一存储系统， 降低集群间传输消耗 存储多种格式的原始数据 • 当前根据业务分多个集群，之间大量 当前底层存储单一，主要以 HDFS为主，逐渐演进为支 持多种介质，多种类型数据 的统一存储系统 支持上层多种计算框架 • 当前计算框架以MR/Spark为主，未来 演进为在数据湖上直接构建更多计算框 架和应用场景

6. 02 移动云LakeHouse实践

7. 整体架构 云原生大数据分析LakeHouse采用计算和存储分离架构，基于移动云EOS和内置HDFS提供了支持Hudi存储机制的湖仓一体方案，通过内置 Spark引擎进行交互式查询，可以快速洞察业务数据变化。

8. 核心功能 01 02 03 04 存储和计算分离 • 存储层与计算层分离部署，存储和计算支持独立弹性扩缩容，相互之间没有影响 • 存储支持对象存储和HDFS，HDFS存储结构化数据，提供高性能存储，对象存储存储非结构化、 原始数据、冷数据，提供高性价比 • 计算支持多引擎，Spark、Presto、Flink均实现serverless化，即开即用，满足不同场景 一键入湖 • • • • 支持连接云上云下多种数据库与存储 入湖流程自动化，降低用户的配置成本 降低对数据源的额外负载，控制在10%以内，支持根据数据源的实例规格自动调整连接数 支持增量更新Hudi 智能元数据发现 • • • • 基于规则，智能识别结构化、半结构化文件的元数据，构建数据目录 自动感知元数据变化 统一元数据，提供类HiveMeta API 智能数据路由和权限统一管控 按量计费 • 存储资源按照使用量计费 • 计算资源支持多种计费模式 • 支持弹性调整租户集群资源规格，快速扩缩容

9. 基于RBF的逻辑视图 在基于Hive构造的数据湖体系中，每个Hive db通常对应一个数仓实例，共享统一的存储HDFS，为了实现存储资源的多租户隔离特性，我们借 鉴RBF的统一视图隔离能力，通过不同的Znode来隔离多个数仓实例StateStore，使每个数仓拥有自己独立的逻辑视图，同时利用RBF挂载多NS 的能力来实现NameNode负载均衡的效果。此外，为顺应云原生趋势，我们将RBF服务容器化部署，在创建Hive db时指定由RBF构成的HDFS schema路径，可以实现资源快速的创建、扩展和回收。 Kubernetes ApiServer NameSpace1 RBF Pod1 Hive db 1 RBF Pod2 Hive db 2 NameSpace2 fs.defaultFS=hdfs://rbf1 hdfs dfs -mkdir /tmp fs.defaultFS=hdfs://rbf2 hdfs dfs -mkdir /tmp NameSpace 3 这样，通过为用户提供单独的存储逻辑视图，不仅可以隔离不同数仓实例之间的数据，又能借助RBF对底层HDFS的均衡负载来实现对Hive数据 的负载均衡。例如，对Hive db目录hivedbdir通过RBF方式mount到两个Namespace： $ hdfs dfsrouteradmin -add /hivedbdir ns1,ns2 /data -order HASH_ALL

10. Hive在对象存储的多租户实现 在公有云场景下，不同用户的bucket认证信息不同，需要多次配置并重启HiveServer服务，无法在对象存储上实现Hive多租户的效果。为解决 这个问题，我们通过在表属性tblproperties中添加s3的认证参数，在访问bucket时加载表属性中的认证信息至threadlocal conf变量，来完成 session级别的认证参数传递。这样就在不重启Hive服务的情况下支持了多bucket认证，达到了对象存储上的Hive多租户效果。 Hive Client 1 Hive Client 2 HiveServer2 MetaStore bucket 1 建表语法示例如下： 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); bucket 2

11. 优化引擎访问对象存储 在大数据生态中，多种计算引擎都可以通过Metastore服务访问Hive中的数据，例如SparkSQL要访问存在对象存储中的Hive数据，需要在提交 作业的Driver模块中根据表的location信息加载对应bucket认证信息，提交命令如下： $SPARK_HOME/bin/beeline -u “jdbc:hive2://host:port/default?fs.s3a.access.key=xxx;fs.s3a.endpoint=xxx ;fs.s3a.endpoint=xxx”-e “select a.id from test1 a join test2 on a.id=b.id” 也就是说，用户需要感知数据是存在对象存储中，并且很难确定一个SQL中的多个表属于哪几个bucket，严重影响了业务开发进度。为此，我们 基于之前的Hive表属性实现了获取对象存储认证参数插件，用户无需感知SQL中的表来自哪个bucket，也无需在提交SQL时指定认证参数，如下： Spark SQL Driver Auth Plugin MetaStore bucket 1 bucket 2 最终提交SQL作业命令如下： $SPARK_HOME/bin/beeline -u “jdbc:hive2://host:port/default”-e “select a.id from test1 a join test2 on a.id=b.id”

12. Serverless实现 这里以Spark为例，通过RBF的多租户实现，Spark进程运行在安全隔离的K8S Namespace中，每个Namespace根据资源规格对应不同的计算 单元（例如：1CU=1 core * 4GB）。对于微批的场景，使用SQL Console每提交一个task，engine模块会启动一个Spark集群，为Driver和 Executor按特定的算法申请相应的计算资源来运行计算任务，任务结束后资源即刻回收；对于即席的场景，可以使用JDBC提交task，engine模 块通过Kyuubi服务启动一个session可配置的spark集群，长驻一段时间后回收资源；所有的SQL task只有在运行成功后按实际的资源规格计费。 SQL Console JDBC/ODBC Spark JAR SQL Parser (Compatible with SparkSQL and HiveSQL) Kubernetes YuniKorn Capacity Management/Job Scheduling Namespace-1 Namespace-N …… Without Serverless With Serverless ① 购买服务器，构建集群 ① 注册移动云账号，订购LakeHouse实例 ② 部署一套开源大数据基础组件：HDFS、Zookeeper、Yarn、Ranger、Hive等 ② 创建数据同步任务 ③ 利用不同工具导入数据 ③ 编写查询SQL计算，输出结果 ④ 编写查询SQL计算，输出结果 ④ 服务全托管，全程无运维 ⑤ 各种繁琐的运维

13. 元数据管理与发现 元数据管理模块基于特定规则，智能识别结构化、半结构化文件的元数据来构建数据目录，通过周期性的元数据爬取实现自动感知元数据变化， 并提供多种优化策略来降低爬取时对数据源的负载；同时，提供类Hive Metastore的API供多种计算引擎直接对表进行访问：

14. Serverless一键入湖 为实现Serverless的入湖创建，我们采用了基于Flink的分布式数据同步框架FlinkX，来满足多种异构数据源之间高效的数据迁移，具备以下特点： • 资源弹性：作业运行在K8S上，资源隔离，支持分布式运行和弹性扩缩容 • 灵活性：将源/目标数据源抽象成Reader/Writer插件，支持双向读写和多种数据源 • 易用性：操作简化，支持批流一体、断点续传，可自动调整数据源连接数，降低侵入性 • 用户通过JobManager创建并提交task配置，通过Quartz调 度task，作业运行时调用Flink K8S客户端访问K8S Master 创建出Flink Master所需要的资源，并启动相应的Container • Flink Master Deployment里面内置一个用户FlinkX Jar，这 时Cluster Entrypoint就会从中去运行main函数，然后产生 JobGraph；之后再提交到Dispatcher，Dispatcher会启动 一个 JobMaster向K8s ResourceManager申请资源，RM发 现没有可用的资源会继续向K8S Master申请资源，请求资源 之后将其发送回去，启动新的TaskManager • TaskManager启动之后再注册回来，此时RM再向它申请 slot提供给JobMaster，最后由 JobMaster将相应的FlinkX Task部署到TaskManager上。这样整个Flink集群的拉起， 到用户提交Jar都完成了

15. JDBC支持 为了提升不同用户的数据分析体验，我们基于Kyuubi来支持多租户、多种计算引擎的JDBC连接服务，Kyuubi具有完整的认证和授权服务，支持 高可用性和负载均衡，并且提供两级弹性资源管理架构，可以有效提高资源利用率。 Spark thrift server kyuubi 多租户 否 是 高可用 否 是 资源占用 永久 通过engine动态申请释放 资源调度 自管理 Yarn&Kubernetes 在使用过程中，为了适配移动云的账号体系以及LakeHouse架构，我们对Kyuubi相应的模块进行了优化和改造，部分如下： • 用户认证：基于移动云AccessKey,SecretKey对接移动云认证体系。 • 资源管理：Kyuubi原生只支持用户指定资源，基于云原生适配后禁止用户指定资源，统一由Lakehouse进行资源调度和分配。 • 权限管控：适配Lakehouse底层权限管理体系，实现细粒度权限的管控。 • 云原生部署：基于Helm3的kyuubi server云原生部署，支持高可用和负载均衡 • 对象存储：支持对象存储表识别和动态ak，sk权限认证

16. 增量更新 我们使用Hudi作为数据存储中间层，能够基于HDFS、对象存储等底层存储，支持ACID语义、实现快速更新能力。常见的流场景如下： • 将Kafka/MySQL binlog中的数据借助DeltaStreamer/CDC通过定时Flink任务写入到Hudi表中 • 通过Flink/Spark任务同步Hive元数据 • 部分源数据修改 • 用户访问和查询数据 权衡 COW MOR 数据延迟 更高 更低 更新代价(I/O) 更高（重写整个parquet文件） 更低（追加到增量日志） Parquet文件大小 更小（高更新代价（I/o）） 更大（低更新代价） 写放大 更高 更低（取决于压缩策略） Ø 对于实时性要求不高的场景尽量使用COW（写时复制）表类型，如果对数 据新鲜度有一定要求则可使用MOR（读写合并） Ø MOR会比COR更容易产生小文件并且对资源需求更高

17. 03 应用前景

18. 构建云原生大数据分析平台 LakeHouse支持多样化数据来源，包括但不限于应用自身产生的数据、采集的各类日志数据、数据库中抽取的各类数据，并提供离线批处理、实 时计算、交互式查询等能力，节省了搭建传统大数据平台需投入的大量软硬件资源、研发成本及运维成本。 DB 转储 SQL交互式分析查 询 上传 对象存储 /HDFS/ Hudi Streaming 实时 离线计算、机器 学习

19. 谢 谢！