|
|
导读：大家好，我是来自阿里云数据库的李少锋，当初次要专一于 ADB Hudi & Spark 的研发以及产品化，明天十分快乐可以借这个时机和大家分享下阿里云 ADB 基于 Apache Hudi 构建 Lakehouse 的运用与理论。
接上去我将分为 3 个部份给大家引见明天的议题，首先我会引见通过将近一年打磨推出的ADB 湖仓版的架构以及症结劣势，接着会引见在反对客户构建 Lakehouse 时，咱们是如何战胜基于 Hudi 构建千亿数据入湖的应战；最初将引见基于 ADB 构建 Lakehouse 的理论。
分享佳宾｜李少锋 阿里云 数据库技术专家
出品社区｜DataFun
01
ADB 湖仓版机构与症结劣势
首先先来引见下 ADB 湖仓版架构及其症结劣势
wj32urjxn3w.jpg
一体版本，咱们称为 ADB 湖仓版。湖仓版在数据全链路的「采存算管用」5 小气面都进行了片面降级。
在「收集」方面，咱们推出了数据管道 APS 功用，能够一键低本钱接入数据库、日志、大数据中的数据。
在「存储」方面，咱们除了新增 Hudi 格局的表面才能，也对外部存储进行了降级革新。经过只存一份数据，同时知足离线、在线 2 类场景。
在「计算」方面，咱们对自研的 XIHE BSP SQL 引擎进行容错性、运维才能等方面的晋升，同时引入开源 Spark 引擎知足更繁杂的离线处置场景和机器学习场景。
在「办理」方面，咱们推出了一致的元数据办理办事，一致湖仓元数据及权限，让湖仓数据的流通更顺畅
在「运用」方面，除了经过SQL形式的BI剖析运用外，还反对基于 Spark 的 AI 运用。
咱们但愿经过资源一体化和体验一体化，2 个一体化才能，帮忙客户完成降本增效。资源一体化是指一份数据、极致弹性和融会引擎。体验一体化是指一致的计费单位、数据管道、数据办理和数据拜候。
hmg3zw5mwrw.jpg
在 ADB 湖仓版中，首先将一份全量数据存在低本钱高吞吐存储介质上，低本钱离线处置场景间接读写低本钱存储介质，升高数据存储和数据 IO 本钱，包管高吞吐。其次将实时数据存在独自的存储 IO 节点（EIU）上，包管「行级」的数据实时性，同时对全量数据构建索引，并经过 Cache 才能对数据进行减速，知足百 ms 级高机能在线剖析场景。因此，数据湖中的数据能够在数仓中减速拜候；而数仓中的数据，也能够利用离线资源进行计算。
xadvlgj1chc.jpg
极致弹性经过弹得好、弹得起、弹得快三个特征，贴合业务负载，包管查问机能，升高资源本钱。
弹得好是指提供了合适在线剖析业务的分时弹性和合适离线处置、机器学习的按需弹性，完善贴合业务负载，知足业务需要。
弹得起是指基于神龙 + ECS + ECI构建了三级资源库存供应才能，保障弹性资源交付率超过 95%。
弹得快是指资源池化后经过缓存减速等技术，弹性启动效力能够达到 10s 内。
zwfuynxlvoe.jpg
撑持离线、在线两类场景的面前，除了方才提到的一份数据。还有自研的XIHE融会计算引擎，同时提供 MPP 模式和 BSP 模式，并提供自动切换才能。
自动切换才能是指当查问使用 MPP 模式无奈在一定耗时内实现时，零碎会自动切换为 BSP模式进行履行。将来，咱们还将在一个查问中，按照算子特征部份算子采取 MPP 模式，部份算子采取 BSP 模式，统筹高机能和高吞吐，提供更智能的查问体验。
同时融会引擎为提供资源利用率提供了可能，通常离线处置产生在晚上，在线剖析产生在白昼，一份资源能够同时反对 2 类场景，经过错峰晋升资源利用率。
c403dwp3xk4.jpg
最初再引见一下一致数据管道APS。数据疾速接入，是数据剖析的第一步，也是最容易流失客户的一步。但咱们发现数据接入面临体验差、本钱高、门坎初等痛点。
所以，咱们抉择跟其它接入工具做好深度优化的同时，面向中小客户，构建一个一致数据管道 APS，底层基于 Flink 实时引擎，提供易用性好、低延时、低本钱的数据接入体验。
nxz1ybldtqp.jpg
关于湖仓中的表元数据，ADB 做了一致元数据办事，湖仓中的元数据/权限可互通，可经过不同引擎自在拜候湖仓数据；而关于湖仓数据，为了屏蔽底层数据存储格局的差别，便于第三方引擎集成，ADB 提供了面向内存列存格局 Arrow，知足对吞吐的要求，关于外部存储，曾经经过 Arrow 格局实现 Spark 对接，提供高吞吐才能。
kian3fj0ao3.jpg
自研是打造技术深度的根底，但同时咱们踊跃拥抱开源，知足曾经成长在开源生态上的客户能够更平滑地使用湖仓版。表面类型，在 Parquet/ORC/JSON/CSV 等 Append 类型数据格局的根底上，为反对在对象存储上低本钱 Lakehouse，反对了Apache Hudi，提供近实时的更新、删除才能，知足客户对低本钱的诉求。
02
基于 Hudi 构建千亿数据入湖的应战
以上就是 ADB 湖仓版的架构与症结劣势，接着引见基于 Hudi 构建千亿数据入湖的应战以及如何咱们是如何战胜这些应战的。
k24tudjogmv.jpg
首先咱们看下典型的业务场景，业务源端数据经过数据收集进入阿里云 SLS，而后经过 APS数据管道办事进入ADB 湖仓版，基于 ADB 湖仓版之上构建日志查问、日志导出、日志剖析等功用。
该业务场景有如下典型的特征：
1.高吞吐，单链路最高 4GB/s 吞吐，日增数据量 350TB，总存储量超 20PB；
2.数据歪斜/热点重大：源端数据歪斜十分重大，从百万到几十条数据不等；
3.扫描量大：日志查问的扫描量 50GB ~ 500GB 不等，查问并发在 100+；
假如使用数仓的话会见临本钱高的问题，此外是数仓短少热点打散才能，只能不停加资源，瓶颈显著；最初是数仓零碎资源是固化的，没有静态弹机能力，或者弹机能力较弱，承载不同客户查问需要时，容易相互搅扰，尤为是大客户的数据扫描。
mkrmol4nzky.jpg
先来看下日志数据入湖的技术架构，数据从 SLS 读取，而后经过 Flink 写入 Hudi，全部架构十分简略，其中关于 SLS 和 Flink 的形态存储阐明如下：
1.SLS 多 Shard 存储，由 Flink 的多个 Source 算子并行消费
2.消费后经过 Sink 算子调用 Hudi Worker/Writer 写出到 Hudi（实际链路还存在 Repartition，热点打散等逻辑）
3.Flink Checkpoint 后端存储以及 Hudi 数据存储在OSS
fnv2vkmavmz.jpg
接着来看下Flink 写入 Hudi 的主流程，首先明白 Flink 写 Hudi 时会存在两种角色，Coordinator 担任处置元数据，如对 Hudi Instant 的相干操作，Worker/Writer 担任处置数据，如写入数据为 parquet 格局，写入步骤如下
1.Coordinator 开启一个 Hudi Instant
2.Filnk Sink 发送数据给 Hudi Worker 写出
3.触发 Flink Checkpoint 时，则经过 Sink 算子通知 Worker Flush 数据，同时耐久化operator-state
4.当 Flink 实现 Checkpoint 耐久化时，通知 Coordinator 提交该 Instant，Coordinator 实现终究提交，写 co妹妹it 文件，数据对外可见
5.提交后会当即开启一个新的 Instant，持续上述循环
acdysskdczu.jpg
假如把 Flink 写 Hudi 包管端到端统一性分红两部份，一部份是 Flink 框架外部的，此外一个部份是与 Hudi 交互的部份。
1.其中步骤 1 到 3 之间是 Flink Checkpoint 逻辑，假如异样在这些步骤上产生，则以为 Checkpoint失败，触发 Job 重启，从上一次 Checkpoint 恢复，至关于两阶段提交的 Preco妹妹it 阶段失败，事务回滚，假如有 Hudi 的 inflight co妹妹it，等候 Hudi Rollback 便可，有数据纷歧致问题
2.当 3 到 4 之间产生异样，则泛起 Flink 和 Hudi 形态纷歧致。此时 Flink 以为 Checkpoint 已完结，而 Hudi 实际尚未提交。假如对此状况不做处置，则产生了数据丧失，由于Flink Checkpoint 终了后，SLS 位点曾经前移，而这部份数据在 Hudi 上并未实现提交，因此容错的重点是如何处置此阶段惹起的数据统一性问题
3.咱们拿一个例子举例剖析在步骤 3 和 4 以前产生异样时，假如包管数据统一性
4.不然以为上一次 Instant 履行失败，等候 Rollback 便可，脏数据对用户不成见
txd43aghti3.jpg
咱们举例剖析下在步骤 3 和 4 之间产生异样时，是如何包管数据统一性的，能够看到关于1615 的 co妹妹it 在 Flink 实现 Checkpoint 时会将其 instant 信息耐久化至 Flink 后端存储。
从 checkpoint 恢复时有如下步骤：
1.Checkpoint 时 Sink 算子 Flush 数据及耐久化 Instant 的 state；
2.Worker 申请处于 pending 的 Instant，与从 state 恢复的 Instant 做比较并报告请示给 Coordinator；
3.Coordinator 从 Instant Timeline 中获得最新的 Instant 信息，并接纳一切 Worker 的报告请示；
4.假如 Worker 报告请示 Instant 相反，而且不在 Timeline 中已实现的 Instant 中，则表现该 Instant 尚未提交，触发 Reco妹妹it。
通过上述步骤能够包管在 Flink 实现 Checkpoint 时，但关于 Hudi Co妹妹it 失败时的场景会进行 reco妹妹it，从而包管数据的统一性。
jh2b23xfucw.jpg
接着引见咱们在处置 4GB/s 的高吞吐时面临的应战，一个十分大的应战就是热点数据处置，咱们统计了 5 分钟内各 Task 处置数据的大小，发现各 Task 处置数据从 200W 条到几十条不等，热点问题显著。
而在写入链路中会按照分区字段做 shuffle，同一个分区由一个 Task 写入,关于上述存在的热点问题会致使部份TM上的分区写入十分慢，致使数据提早/功课挂掉。
面对写入热点问题，咱们开发了热点打散功用，经过配置指定规定打散热点数据，同时能够按照数据流量自动更新热点打散规定，确保零碎的硬朗性，能够看到通过热点打散后个 TM 处置的数据量/CPU占用/内存占用根本相反而且对比安稳，功课不乱性也失掉了晋升。
3yn3b5bljq3.jpg
此外一个应战是 OOM，其实和热点打散也有很大瓜葛，咱们发现功课运转时会泛起OOM，致使功课挂掉，数据提早下跌，因此咱们对堆外/堆内内存的使用做了对比粗疏的梳理，使用内存的部份次要集中在：
1.写 Parquet 文件占用堆外内存
2.OSS Flush 占用堆外内存
3.单 TM 的 Slot 数、写并发都影响内存占用，如每个写并发处置 30-50 Handle，TM 16 并发，8M row group size 至多占用 6400 M 内存
4.堆内内存负载太高致使频繁Full GC
咱们针对上述份内存使用做了优化，如：
1.row group size 配置为 4M，增加堆外内存占用，同时将堆外内存调大
2.close 时及时释放 compressor 占用的内存，这部份对 parquet 源码做了革新
3.显露出堆外内存目标，减少堆外内存监控，这部份也是对 parquet 源码做了革新
4.源端 source 算子与 Shard 调配更平衡，以此包管各 TM 消费的 shard 数根本均等
izcb2shf1pc.jpg
最初一个对比大的应战就是 OSS 限流，云对象存储（如OSS）对 List 操作不敌对，list objects 对 OSS 办事器压力较大，如在咱们场景下，1500 写并发，会发生 1W QPS list object，OSS 侧目前限流 1K QPS，限流显著，限流会致使功课处置变慢，提早变高，为解决该问题，咱们也梳理了写入链路对 OSS 的申请，在元数据链路对 OSS 的申请如下：
1.Timeline 构建需求 list .hoodie 目录
2.Flink CkpMetaData 基于 OSS 传递给 Worker
3.Hadoop-OSS SDK create/exists/mkdir 函数依赖 getStatus 接口，getStatus 接口现有完成致使少量 list 申请，其中 getStatus 接口关于不存在的文件，会额定进行一次 list objects 申请确认 Path 是否目录，对 Marker File、partitionMetadata、数据文件都会发生少量的 list objects 申请
在数据链路对 OSS 申请如下：先暂时写到当地磁盘，再上传至 OSS，致使当地磁盘写满。
针对上述对 OSS 的申请，咱们做了如下优化，在元数据侧：
1.Timeline Based CkpMetaData，将TM申请打到 JM，防止少量 TM 扫描 OSS 文件
2.Hadoop-OSS SDK，显露出间接创立文件的接口，不进行目录反省
3.PartitionMetaData 缓存处置，在内存中对每个分区的元数据文件做了缓存处置，尽可能增加与 OSS 的交互
4.Create Marker File 异步处置，异步化处置不梗阻对 Handle 的创立，增加创立 Handle 的本钱
5.开启 Timeline Based Marker File，这个是社区曾经有的才能，间接开启便可
这里额定增补下可能有小火伴对比猎奇为何开启 hudi metadata table 来解决云对象存储的限流问题，咱们外部做过测试，发现开启 metadata table 时，写入会愈来愈慢，无奈知足高吞吐的场景。
以上就是咱们在处置日志数据入湖时面临的典型应战以及咱们如何战胜这些应战，接着讲讲咱们在处置数据入湖时为知足业务要求做的症结特性开发。
n4neim0nuqm.jpg
首先是反对并发写，业务侧要求链路有补数据才能，补数据场景波及多 Flink Client 写不同分区，实时写链路，补数据链路，Table Service 链路并发操作表数据/元数据，这要求：
1.表数据不紊乱
2.补数据/TableService 链路不影响实时写链路
因此咱们对 Hudi 内核侧做了部份修正来反对并发写场景：
1.CkpMetadata 独一标识，包管不同功课使用不同 ckp meta
2.ViewStorage 独一标识，包管不同功课 Timeline Server 隔离
3.Lazy Table Service，包管并行功课不相互 rollback co妹妹it，防止数据紊乱
4.Instant 生成重试战略，包管 Timeline Instant 的独一性，防止数据紊乱
5.独立 Table Service 处置，使用独自的功课运转 Table Service，与实时写链路彻底隔离
spmau5u2shu.jpg
此外一个症结特性是出于本钱斟酌，业务侧要求 Hudi 中数据不克不及有限地保留，需求根据用户设定的战略保存指按时间的数据，这要求：
1.Hudi 提供分区级别根据数据量，分区数和过时时间等不同维度进行生命周期办理的才能
2.Hudi 反对并发设置生命周期办理战略，由于面向多租户会波及并发更新办理战略
针对业务对生命周期办理的需要，咱们开发 Hudi 的生命周期办理功用，详细完成如下：
1.关于生命周期办理使用，首先经过 call co妹妹and 添加生命周期办理战略，并进行耐久化，为反对并发更新，咱们参考 Hudi MOR 表中 Base 文件和 Log 文件的设计，并发更新会写入不同的 Log 文件；
2.关于生命周期办理的履行，在每一个次 co妹妹it 完结落后行统计信息增量收集并更新至统计信息文件，而后根据分区战略进行过时分区的处置，关于过时分区会生成一个 replace co妹妹it，等候后续被 clean 便可，同时汇合并后面的战略 Base 文件和 Log 文件，生成新的 Base 文件以及更新统计信息；
咱们也提供了根据分区数、数据量、过时时间三种不同战略来办理 Hudi 表中的分区的生命周期，很好的知足业务侧的需要。
wyhlvyheyak.jpg
最初一个对比大的症结特性是独立 TableService，业务侧要求包管实时写链路不乱，同时但愿进步入湖数据的查问机能，这要求：
1.在不影响主链路同步机能状况下，清算 Co妹妹its/文件版本，包管表形态大小可控
2.为进步查问机能，提供异步 Clustering 才能，合并小文件，增加扫描量，进步查问机能
基于上述诉求咱们开发了基于 ADB 湖仓版的独立 Table Service 办事，在入湖链路写入实现后会进行一次调度，而后将申请写入调度组件，供调度组件后续拉起弹性的 Flink/Spark TableService 功课，能够做到对实时写入链路无影响。
关于表形态办理以及数据规划优化均是采取的独立 TableService 功课履行，包管表的形态大小可控，同时经过异步 Clustering 操作，端到端查问机能晋升 40% 以上。
aqibib21523.jpg
在对日志入湖链路进行了深化打磨后，咱们能够包管最高 4GB/s 的数据写入，提早在 5min内，知足业务需要。
同时也建立了目标监控大盘与异样链路告警功用，便于疾速定位问题以及泛起问题后疾速响应。
以上引见即是咱们是如何基于Hudi构建千亿数据入湖以及如何战胜入湖应战的。
03
基于 ADB 构建 Lakehouse 的理论
最初引见下基于 ADB 构建 Lakehouse 的理论。
epod1joydhy.jpg
后面也提到 ADB 湖仓版拥抱开源技术，ADB 集成为了流式处置引擎 Flink，并在此根底上推出了APS 数据管道办事，APS 具备如下劣势：
1.低本钱，低提早：功课级别弹性资源，按量付费；按流量自在设定功课资源；充沛享用 Flink 流式处置机能红利
2.少数据源疾速集成：得益于 Flink 成熟的 Connectors 机制，能够便利对接如 SLS、Kafka 等数据源，同时能够包管数据入湖的准确统一性
3.低使用门坎：反对白屏化操作疾速构建 Lakehouse，基于一致元数据办事，Lakehouse 数据可经过 Spark/ADB 引擎无缝拜候
而为了知足客户关于批处置以及机器学习才能的诉求，ADB 集成为了 Spark 引擎，并在此技术上推出了 Servlersss Spark，其具备如下劣势：
1.一份数据存储，在离线同享：无缝对接 ADB 已有元数据和数据；反对大吞吐读写 ADB 数据；Spark 批量写入的数据，在线剖析查问可间接拜候
2.数据库体系&体验：使用 ADB 一致的账号、权限和鉴权体系；反对经过 ADB Workflow、DMS 以及 DataWorks 调度编排 SparkSQL 功课
3.彻底兼容 Spark 生态：基于最新的 Apache Spark 3.X 版本，充沛享用开源社区红利；反对 SparkSQL、DataFrame API 主流编程接口以及 Thrift Server；反对 Spark UDF，反对 Hive UDF/UDTF/UDAF
4.按量计费，秒级弹性：开箱即用，按量计费无任何持有本钱；基于神龙、ECS/ECI 的管控底座以及资源池化，缓存减速等技术，反对 Spark Pod 秒级拉起
关于实时性有诉求的场景，能够基于 ADB APS 办事能够十分便利的构建准实时 Lakehouse，白屏化操作疾速配置入湖通道，多种数据源反对，知足不同数据源接入诉求，更少数据源也在继续集成中。
而关于实时性没有诉求的场景，能够基于 Spark + Hudi + ADB 任务编排构建离线 Lakehouse,如想对 RDS 数据构建离线Lakehouse进行剖析，可以使用ADB任务编排，利用 Spark 将 RDS 数据离线导入 Lakehouse，并做数据的荡涤和加工，有需求最初可经过一条简略的 Spark SQL将数据从 Hudi 导入 ADB 做查问剖析减速。
此外 ADB Spark 与 Hudi 和 ADB 表都做了深度集成，便于客户使用，如关于 Hudi 表的使用，免去了得多 Hudi 额定的配置，开箱即用；关于 ADB 表，可经过 Spark 创立、删除 ADB 表元数据，也反对读写 ADB 表数据。
此外最初引见下 Spark 与 ADB 集成提供的 Zero-ETL 解决计划，这也与 2022 AWS reinvent 推出的数据集成办事 Zero-ETL 相似，咱们经过一个场景理解 Zero-ETL 的运用及其劣势。
客户假如关于 ADB 表有剖析挖掘的需要，受限于 JDBC 形式吞吐的限度，需求先将 ADB内表数据以 parquet 格局导出到 OSS，利用 OSS 的带宽，再经过 Spark 进行剖析挖掘，最初输入挖掘后果，能够看到这类计划中存在ETL操作，从而引入数据统一性差、时效性低的问题。
在 ADB 湖仓版中 Spark 与 ADB 做了深度集成，经过 Lakehouse API间接拜候 ADB 内表数据，吞吐高，所以面对一样的场景，能够使用上面的链路，即间接经过 Spark 剖析 ADB 数据，无需 ETL，数据统一性好，时效性也很高；此外关于 Lakehouse API 层的拜候也反对列投影、谓词下推、分区裁剪等才能，更多下推才能也在继续建立中。
后面引见了得多对于 ADB 湖仓版的功用以及劣势，包罗 Serverless Spark、APS 办事、融会引擎、任务流编排等等。而关于 ADB 湖仓版的定位总结成一句话就是从湖到仓，打造云原生一站式数据剖析平台。
让客户经过 ADB 湖仓版平台就能轻松玩转数据剖析。
此外 AnalyticDB MySQL 湖仓版从 7 月份开始，用时 4 个月的邀测后，十一 月 1 日正式开始公测，能够经过点击「AnalyticDB MySQL3.0婀栦粨鐗堝叕娴嬬敵璇?」进行公测请求。
明天的分享就到这里，谢谢大家。
｜分享佳宾｜
李少锋
阿里云 数据库技术专家
Apache Hudi Co妹妹itter & PMC成员，数据库OLAP ADB Hudi&Spark团队技术担任人。
｜DataFun新媒体矩阵｜
｜对于DataFun｜
专一于大数据、人工智能技术运用的分享与交流。发动于2017年，在北京、上海、深圳、杭州等城市举行超过100+线下和100+线上沙龙、论坛及峰会，已约请超过2000位专家和学者参预分享。其大众号 DataFunTalk 累计出产原创文章800+，百万+浏览，15万+精准粉丝。 |
|
中级会员