ApacheHudi在B站构建实时数据湖的实践.docx
《ApacheHudi在B站构建实时数据湖的实践.docx》由会员分享，可在线阅读，更多相关《ApacheHudi在B站构建实时数据湖的实践.docx（11页珍藏版）》请在冰豆网上搜索。
ApacheHudi在B站构建实时数据湖的实践
简介：
B站选择Flink+Hudi的数据湖技术方案，以及针对其出的优化。
本文
传统离线数仓痛
数据湖技术方案
Hudi任务稳定性保障
数据入湖实践
增量数据湖收益
社区贡献
未来的发展与思考
一、传统离线数仓痛
1.痛
之前B站数仓的入仓流程致如下所示：
在这种架构下产生了以下几个核心痛：
规模的数据落地HDFS后，只能在凌晨分区归档后才能查询并下一步处理；
数据量较的RDS数据同步，需要在凌晨分区归档后才能处理，并且需要排序、去重以及join前一天分区的数据，才能产生出当天的数据；
仅能通过分区粒度读取数据，在分流等场景下会出现量的冗余IO。
总结一下就:
调度启动晚；
合并速度慢；
重复读取多。
2.痛思考
调度启动晚
思路：
既然Flink落ODS准实时写入的，有明确的文件增量概念，可以使用基于文件的增量同步，将清洗、补维、分流等逻辑通过增量的进行处理，这样就可以在ODS分区未归档的时候就处理数据，理论上数据的延迟只取决于最后一批文件的处理时间。
合并速度慢
思路：
既然读取已经可以到增量化了，那么合并也可以到增量化，可以通过数据湖的能力结合增量读取完成合并的增量化。
重复读取多
思路：
重复读取多的主要原因分区的粒度太粗了，只能精确到小时/天级别。
们需要尝试一些更加细粒度的数据方案，将DataSkipping可以到字段级别，这样就可以进行的数据查询了。
3.解决方案:
Magneto-基于Hudi的增量数据湖
以下基于Magneto构建的入仓流程：
Flow
使用流式Flow的，统一离线和实时的ETLPipline
Organizer
数据重，加速查询
支持增量数据的paction
Engine
计算层使用Flink，存储层使用Hudi
Metadata
提炼表计算SQL逻辑
标准化TableFormat计算范式
二、数据湖技术方案
1.Iceberg与Hudi的取舍
1.1技术细节对比
1.2社区活跃度对比
统计截止至2021-08-09
1.3总结
致可以分为以下几个主要纬度来进行对比：
对Append的支持
Iceberg设计之初的主要支持方案，针对该场景了很多优化。
Hudi在0.9版本中对Appned模式进行了支持，目前在部分场景下和Iceberg的差距不，目前的0.10版本中仍然在持续优化，与Iceberg的性能已经非常相近了。
对Upsert的支持
Hudi设计之初的主要支持方案，相对于Iceberg的设计，性能和文件数量上有非常明显的优势，并且Compaction流程和逻辑全部都高度抽象的接口。
Iceberg对于Upsert的支持启动较晚，社区方案在性能、小文件等地方与Hudi还有比较明显的差距。
社区活跃度
Hudi的社区相较于Iceberg社区明显更加活跃，得益于社区活跃，Hudi对于功能的丰富程度与Iceberg拉了一定的差距。
综合对比，们选择了Hudi作为们的数据湖组件，并在其上继续优化们需要的功能（Flink更好的集成、Clustering支持等）
2.选择Flink+Hudi作为写入
们选择Flink+Hudi的集成Hudi的主要原因有三个：
们部分自己维护了Flink引擎，支撑了全的实时计算，从成本上考虑不想同时维护两套计算引擎，尤其在们内部Spark版本也了很多内部的情况下。
Spark+Hudi的集成方案主要有两种Index方案可供选择，但都有劣势：
BloomIndex：
使用BloomIndex的话，Spark会在写入的时候，每个task都去list一遍所有的文件，读取footer内写入的Bloom过滤数据，这样会对们内部压力已经非常的HDFS造成非常恐怖的压力。
HbaseIndex：
这种倒可以到O
（1）的找到索引，但需要引入外部依赖，这样会使整个方案变的比较重。
们需要和Flink增量处理的框架进行对接。
3.Flink+Hudi集成的优化
3.1Hudi0.8版本集成Flink方案
针对Hudi0.8版本集成暴露出来的问题，B站和社区合作进行了优化与完善。
3.2BootstrapState冷启动
背景：
支持在已经存在Hudi表启动Flink任务写入，从而可以到由SparkonHudi到FlinkonHudi的方案切换
原方案：
问题：
每个Task处理全量数据，然后选择属于当前Task的HoodieKey存入state优化方案。
每个BootstrapOperator在初始化时，加载属于当前Task的fileId相关的BaseFile和logFile；
将BaseFile和logFile中的recordKey成HoodieKey，通过KeyBy的形式给BucketAssignFunction，然后将HoodieKey作为索引存储在BucketAssignFunction的state中。
：
通过将Bootstrap功能单独抽出一个Operator，到了索引加载的可扩展性，加载速度提升N（取决于并发度）倍。
3.3Checkpoint一致性优化
背景：
在Hudi0.8版本的StreamWriteFunction中，存在极端情况下的数据一致性问题。
原方案：
问题：
CheckpointComplete不在CK生命周期内，存在CK成功但instant没有mit的情况，从而导致出现数据丢失。
优化方案：
3.4Append模式支持及优化
背景：
Append模式用于支持不需要update的数据集时使用的模式，可以在流程中省略索引、合并等不必要的处理，从而幅提高写入效率。
主要：
支持每次FlushBucket写入一个新的文件，避免出现读写的放；
参数，支持关闭BoundedInMemeoryQueue内部的限速机制，在FlinkAppend模式下只需要将Queue的小和Bucketbuffer设置成同样的小就可以了；
针对每个CK产生的小文件，制定自定义Compaction计划；
通过以上的发和优化之后，在纯Insert场景下性能可达原先COW的5倍。
三、Hudi任务稳定性保障
1.Hudi集成FlinkMetrics
通过在关键节上报Metric，可以比较清晰的掌握整个任务的运行情况：
2.系统内数据校验
3.系统外数据校验
四、数据入湖实践
1.CDC数据入湖
1.1TiDB入湖方案
由于目前源的各种方案都没法直接支持TiDB的数据导出，直接使用Select的会影响数据库的稳定性，所以拆成了全量+增量的：
启动TI-CDC，将TIDB的CDC数据写入对应的Kafkatopic；
利用TiDB的Dumpling组件，部分源码，支持直接写入HDFS；
启动Flink将全量数据通过BulkInsert的写入Hudi；
消费增量的CDC数据，通过FlinkMOR的写入Hudi。
1.2MySQL入湖方案
MySQL的入湖方案直接使用源的Flink-CDC，将全量和增量数据通过一个Flink任务写入Kafkatopic：
启动Flink-CDC任务将全量数据以及CDC数据导入Kafkatopic；
启动FlinkBatch任务读取全量数据，通过BulkInsert写入Hudi；
切换为FlinkStreaming任务将增量CDC数据通过MOR的写入Hudi。
2.日志数据增量入湖
实现HDFSStreamingSource和ReaderOperator，增量同步ODS的数据文件，并且通过写入ODS的分区索引信息，减少对HDFS的list请求；
支持transformSQL配置化，允许用户进行自定义逻辑转化，包括但不限于维表join、自定义udf、按字段分流等；
实现FlinkonHudi的Append模式，幅提升不需要合并的数据写入速率。
五、增量数据湖收益
通过Flink增量同步幅度提升了数据同步的时效性，分区就绪时间从2:
00~5:
00提前到00:
30分内；
存储引擎使用Hudi，用户基于COW、MOR的多种查询，让不同用户可以根据自己的应用场景选择合适的查询，而不单纯的只能等待分区归档后查询；
相较于之前数仓的T+1Binlog合并，基于Hudi的自动Compaction使得用户可以将Hive当成MySQL的快照进行查询；
幅节约资源，原先需要重复查询的分流任务只需要执行一次，节约约18000core。
六、社区贡献
上述优化都已经合并到Hudi社区，B站在未来会进一步加强Hudi的建设，与社区成⻓。
部分核心PR
rel="nofollow">
rel="nofollow">
rel="nofollow">
rel="nofollow">
rel="nofollow">
rel="nofollow">
rel="nofollow">
七、未来的发展与思考
支持流批一体，统一实时与离线逻辑；
推进数仓增量化，达成HudiODS->Flink->HudiDW->Flink->HudiADS的全流程；
在Flink上支持Hudi的Clustering，体现出Hudi在数据上的优势，并探索Z-Order等加速多维查询的性能表现；
支持inlineclustering。
rel="nofollow">
升级会员 