导读： 大家好，我是来自阿里云数据库的李少锋，如今关键专一于 ADB Hudi & Spark 的研发以及产品化，当天十分快乐能够借这个时机和大家分享下阿里云 ADB 基于 Apache Hudi 构建 Lakehouse 的运行与通常。
接上去我将分为 3 个局部给大家引见当天的议题，首先我会引见经过将近一年打磨推出的ADB 湖仓版的架构以及关键长处，接着会引见在允许客户构建 Lakehouse 时，咱们是如何克制基于 Hudi 构建千亿数据入湖的应战；最后将引见基于 ADB 构建 Lakehouse 的通常。
1、ADB 湖仓版机构与关键长处
首先先来引见下 ADB 湖仓版架构及其关键长处。
一体版本，咱们称为 ADB 湖仓版。湖仓版在数据全链路的「采存算管用」5 慷慨面都启动了片面更新。
在「采集」方面 ，咱们推出了数据管道 APS 性能，可以一键低老本接入数据库、日志、大数据中的数据。
在「存储」方面 ，咱们除了新增 Hudi 格局的外表才干，也对外部存储启动了更新变革。经过只存一份数据，同时满足离线、在线 2 类场景。
在「计算」方面 ，咱们对自研的 XIHE BSP SQL 引擎启动容错性、运维才干等方面的优化，同时引入开源 Spark 引擎满足更复杂的离线处置场景和机器学习场景。
在「控制」方面 ，咱们推出了一致的元数据控制服务，一致湖仓元数据及权限，让湖仓数据的流通更顺畅。
在「运行」方面 ，除了经过SQL形式的BI剖析运行外，还允许基于 Spark 的 AI 运行。
咱们宿愿经过资源一体化和体验一体化，2 个一体化才干，协助客户成功降本增效。资源一体化是指一份数据、极致弹性和融合引擎。体验一体化是指一致的计费单位、数据管道、数据控制和数据访问。
在 ADB 湖仓版中，首先将一份全量数据存在低老本高吞吐存储介质上，低老本离线处置场景间接读写低老本存储介质，降落数据存储和数据 IO 老本，保证高吞吐。其次将实时数据存在独自的存储 IO 节点（EIU）上，保证「行级」的数据实时性，同时对全量数据构建索引，并经过 Cache 才干对数据启动减速，满足百 ms 级高性能在线剖析场景。因此，数据湖中的数据可以在数仓中减速访问；而数仓中的数据，也可以应用离线资源启动计算。
极致弹性经过弹得好、弹得起、弹得快三个特点，贴合业务负载，保证查问性能，降落资源老本。
弹得好 是指提供了适宜在线剖析业务的分时弹性和适宜离线处置、机器学习的按需弹性，完美贴合业务负载，满足业务需求。
弹得起 是指基于神龙 + ECS + ECI构建了三级资源库存供应才干，保证弹性资源交付率超越 95%。
弹得快 是指资源池化后经过缓存减速等技术，弹性启动效率可以到达 10s 内。
撑持离线、在线两类场景的面前，除了刚才提到的一份数据。还有自研的XIHE融算计算引擎，同时提供 MPP 形式和 BSP 形式，并提供智能切换才干。
智能切换才干是指当查问经常使用 MPP 形式无法在必定耗时内成功时，系统会智能切换为 BSP形式启动口头。未来，咱们还将在一个查问中，依据算子特点局部算子驳回 MPP 形式，局部算子驳回 BSP 形式，统筹高性能和高吞吐，提供更智能的查问体验。
同时融合引擎为提供资源应用率提供了或许，通常离线处置出当初早晨，在线剖析出当初白昼，一份资源可以同时允许 2 类场景，经过失峰优化资源应用率。
最后再引见一下一致数据管道APS。数据极速接入，是数据剖析的第一步，也是最容易散失客户的一步。但咱们发现数据接入面临体验差、老本高、门槛初等痛点。
所以，咱们选择跟其它接入工具做好深度优化的同时，面向中小客户，构建一个一致数据管道 APS，底层基于 Flink 实时引擎，提供易用性好、低延时、低老本的数据接入体验。
关于湖仓中的表元数据，ADB 做了一致元数据服务，湖仓中的元数据/权限可互通，可经过不同引擎自在访问湖仓数据；而关于湖仓数据，为了屏蔽底层数据存储格局的差异，便于第三方引擎集成，ADB 提供了面向内存列存格局 Arrow，满足对吞吐的要求，关于外部存储，曾经经过 Arrow 格局成功 Spark 对接，提供高吞吐才干。
自研是打造技术深度的基础，但同时咱们踊跃拥抱开源，满足曾经成长在开源生态上的客户可以更平滑地经常使用湖仓版。外表类型，在 Parquet/ORC/JSON/CSV 等 Append 类型数据格局的基础上，为允许在对象存储上低老本 Lakehouse，允许了Apache Hudi，提供近实时的更新、删除才干，满足客户对低老本的诉求。
2、基于 Hudi 构建千亿数据入湖的应战
以上就是 ADB 湖仓版的架构与关键长处，接着引见基于 Hudi 构建千亿数据入湖的应战以及如何咱们是如何克制这些应战的。
首先咱们看下典型的业务场景，业务源端数据经过数据采集进入阿里云 SLS，而后经过 APS数据管道服务进入ADB 湖仓版，基于 ADB 湖仓版之上构建日志查问、日志导出、日志剖析等性能。
该业务场景有如下典型的特点：
1.高吞吐，单链路最高 4GB/s 吞吐，日增数据量 350TB，总存储量超 20PB。
2.数据歪斜/热点重大：源端数据歪斜十分重大，从百万到几十条数据不等。
3.扫描量大：日志查问的扫描量 50GB ~ 500GB 不等，查问并发在 100+。
假设经常使用数仓的话会面临老本高的疑问，另外是数仓缺少热点打散才干，只能不时加资源，瓶颈清楚；最后是数仓系统资源是固化的，没有灵活弹性才干，或许弹性才干较弱，承载不同客户查问需求时，容易相互搅扰，尤其是大客户的数据扫描。
先来看下 日志数据入湖的技术架构 ，数据从 SLS 读取，而后经过 Flink 写入 Hudi，整个架构十分繁难，其中关于 SLS 和 Flink 的形态存储说明如下：
1.SLS 多 Shard 存储，由 Flink 的多个 Source 算子并行消费。
2.消费后经过 Sink 算子调用 Hudi Worker/Writer 写出到 Hudi（实践链路还存在 Repartition，热点打散等逻辑）。
3.Flink Checkpoint 后端存储以及 Hudi 数据存储在OSS。
接着来看下Flink 写入 Hudi 的干流程，首先明白 Flink 写 Hudi 时会存在两种角色，Coordinator 担任处置元数据，如对 Hudi Instant 的相关操作，Worker/Writer 担任处置数据，如写入数据为 parquet 格局，写入步骤如下：
3.触发 Flink Checkpoint 时，则经过 Sink 算子通知 Worker Flush 数据，同时耐久化operator-state。
4.当 Flink 成功 Checkpoint 耐久化时，通知 Coordinator 提交该 Instant，Coordinator 成功最终提交，写 commit 文件，数据对外可见。
5.提交后会立刻开启一个新的 Instant，继续上述循环。
假设把 Flink 写 Hudi 保证端到端分歧性分红两局部，一局部是 Flink 框架外部的，另外一个局部是与 Hudi 交互的局部。
1.其中步骤 1 到 3 之间是 Flink Checkpoint 逻辑，假设意外在这些步骤上出现，则以为 Checkpoint失败，触发 Job 重启，从上一次性 Checkpoint 复原，相当于两阶段提交的 Precommit 阶段失败，事务回滚，假设有 Hudi 的 inflight commit，期待 Hudi Rollback 即可，有数据不分歧疑问。
2.当 3 到 4 之间出现意外，则出现 Flink 和 Hudi 形态不分歧。此时 Flink 以为 Checkpoint 已完结，而 Hudi 实践尚未提交。假设对此状况不做处置，则出现了数据失落，由于Flink Checkpoint 终了后，SLS 位点曾经前移，而这局部数据在 Hudi 上并未成功提交，因此容错的重点是如何处置此阶段惹起的数据分歧性疑问。
3.咱们拿一个例子举例剖析在步骤 3 和 4 之前出现意外时，假设保证数据分歧性。
4.否则以为上一次性 Instant 口头失败，期待 Rollback 即可，脏数据对用户无法见。
咱们举例剖析下在步骤 3 和 4 之间出现意外时，是如何保证数据分歧性的，可以看到关于1615 的 commit 在 Flink 成功 Checkpoint 时会将其 instant 消息耐久化至 Flink 后端存储。
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 尚未提交，触发 Recommit。
经过上述步骤可以保证在 Flink 成功 Checkpoint 时，但关于 Hudi Commit 失败时的场景会启动 recommit，从而保证数据的分歧性。
接着引见咱们在处置 4GB/s 的高吞吐时面临的应战，一个十分大的应战就是热点数据处置，咱们统计了 5 分钟内各 Task 处置数据的大小，发现各 Task 处置数据从 200W 条到几十条不等，热点疑问清楚。
而在写入链路中会依据分区字段做 shuffle，同一个分区由一个 Task 写入,关于上述存在的热点疑问会造成局部TM上的分区写入十分慢，造成数据提前/作业挂掉。
面对写入热点疑问，咱们开发了热点打散性能，经过性能指定规定打散热点数据，同时可以依据数据流量智能更新热点打散规定，确保系统的强健性，可以看到经过热点打散后个 TM 处置的数据量/CPU占用/内存占用基本相反并且比拟颠簸，作业稳固性也失掉了优化。
另外一个应战是 OOM，其实和热点打散也有很大相关，咱们发现作业运转时会出现OOM，造成作业挂掉，数据提前下跌，因此咱们对堆外/堆内内存的经常使用做了比拟粗疏的梳理，经常使用内存的局部关键集中在：
1.写 Parquet 文件占用堆外内存。
3.单 TM 的 Slot 数、写并发都影响内存占用，如每个写并发处置 30-50 Handle，TM 16 并发，8M row group size 最多占用 6 M 内存。
4.堆内内存负载过高造成频繁Full GC。
咱们针对上述分外存经常使用做了优化，如：
1.row group size 性能为 4M，缩小堆外内存占用，同时将堆外内存调大。
2.close 时及时监禁 compressor 占用的内存，这局部对 parquet 源码做了变革。
3.显显露堆外内存目的，参与堆外内存监控，这局部也是对 parquet 源码做了变革。
4.源端 source 算子与 Shard 调配更平衡，以此保证各 TM 消费的 shard 数基本均等。
一个比拟大的应战就是 OSS 限流，云对象存储（如OSS）对 List 操作不友好，list objects 对 OSS 主机压力较大，如在咱们场景下，1500 写并发，会发生 1W QPS list object，OSS 侧目前限流 1K QPS，限流清楚，限流会造成作业处置变慢，提前变高，为处置该疑问，咱们也梳理了写入链路对 OSS 的恳求，在元数据链路对 OSS 的恳求如下：
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 时，写入会越来越慢，无法满足高吞吐的场景。
以上就是咱们在处置日志数据入湖时面临的典型应战以及咱们如何克制这些应战，接着讲讲咱们在处置数据入湖时为满足业务要求做的关键个性开发。
首先是允许并发写，业务侧要求链路有补数据才干，补数据场景触及多 Flink Client 写不同分区，实时写链路，补数据链路，Table Service 链路并发操作表数据/元数据，这要求：
2.补数据/TableService 链路不影响实时写链路。
因此咱们对 Hudi 内核侧做了局部修正来允许并发写场景：
1.CkpMetadata 惟一标识，保证不同作业经常使用不同 ckp meta。
2.ViewStorage 惟一标识，保证不同作业 Timeline Server 隔离。
3.Lazy Table Service，保证并行作业不相互 rollback commit，防止数据杂乱。
4.Instant 生成重试战略，保证 Timeline Instant 的惟一性，防止数据杂乱。
5.独立 Table Service 处置，经常使用独自的作业运转 Table Service，与实时写链路齐全隔离。
另外一个关键个性是出于老本思考，业务侧要求 Hudi 中数据不能有限地保管，须要依照用户设定的战略保管指定期间的数据，这要求：
1.Hudi 提供分区级别依照数据量，分区数和过时期间等不同维度启动生命周期控制的才干。
2.Hudi 允许并发设置生命周期控制战略，由于面向多租户会触及并发更新控制战略。
针对业务对生命周期控制的需求，咱们开发 Hudi 的生命周期控制性能，详细成功如下：
1.关于生命周期控制经常使用，首先经过 call command 参与生命周期控制战略，并启动耐久化，为允许并发更新，咱们参考 Hudi MOR 表中 Base 文件和 Log 文件的设计，并发更新会写入不同的 Log 文件。
2.关于生命周期控制的口头，在每一次性 commit 完结后启动统计消息增量采集并更新至统计消息文件，而后依照分区战略启动过时分区的处置，关于过时分区会生成一个 replace commit，期待后续被 clean 即可，同时集兼并前面的战略 Base 文件和 Log 文件，生成新的 Base 文件以及更新统计消息。
咱们也提供了依照分区数、数据量、过时期间三种不同战略来控制 Hudi 表中的分区的生命周期，很好的满足业务侧的需求。
最后一个比拟大的关键个性是独立 TableService，业务侧要求保证明时写链路稳固，同时宿愿提高入湖数据的查问性能，这要求：
1.在不影响主链路同步性能状况下，清算 Commits/文件版本，保证表形态大小可控。
2.为提高查问性能，提供异步 Clustering 才干，兼并小文件，缩小扫描量，提高查问性能。
基于上述诉求咱们开发了基于 ADB 湖仓版的独立 Table Service 服务，在入湖链路写入成功后会启动一次性调度，而后将恳求写入调度组件，供调度组件后续拉起弹性的 Flink/Spark TableService 作业，可以做到对实时写入链路无影响。
关于表形态控制以及数据规划优化均是驳回的独立 TableService 作业口头，保证表的形态大小可控，同时经过异步 Clustering 操作，端到端查问性能优化 40% 以上。
在对日志入湖链路启动了深化打磨后，咱们可以保证最高 4GB/s 的数据写入，提前在 5min内，满足业务需求。
同时也树立了目的监控大盘与意外链路告警性能，便于极速定位疑问以及出现疑问后极速照应。
以上引见便是咱们是如何基于Hudi构建千亿数据入湖以及如何克制入湖应战的。
最后引见下基于 ADB 构建 Lakehouse 的通常。
前面也提到 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 以及> 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 湖仓版平台就可以轻松玩转数据剖析。