关于hadoop:Apache-Hudi-在-B-站构建实时数据湖的实践

简介：B 站抉择 Flink + Hudi 的数据湖技术计划，以及针对其做出的优化。
本文作者喻兆靖，介绍了为什么 B 站抉择 Flink + Hudi 的数据湖技术计划，以及针对其做出的优化。次要内容为：

传统离线数仓痛点
数据湖技术计划
Hudi 工作稳定性保障
数据入湖实际
增量数据湖平台收益
社区奉献
将来的倒退与思考

一、传统离线数仓痛点

1. 痛点

之前 B 站数仓的入仓流程大抵如下所示：

在这种架构下产生了以下几个外围痛点：

大规模的数据落地 HDFS 后，只能在凌晨分区归档后能力查问并做下一步解决；
数据量较大的 RDS 数据同步，须要在凌晨分区归档后能力解决，并且须要做排序、去重以及 join 前一天分区的数据，能力产生出当天的数据；
仅能通过分区粒度读取数据，在分流等场景下会呈现大量的冗余 IO。
总结一下就是:

• 调度启动晚；
• 合并速度慢；
• 反复读取多。

2. 痛点思考

• 调度启动晚

思路：既然 Flink 落 ODS 是准实时写入的，有明确的文件增量概念，能够应用基于文件的增量同 步，将荡涤、补维、分流等逻辑通过增量的形式进行解决，这样就能够在 ODS 分区未归档的时 候就解决数据，实践上数据的提早只取决于最初一批文件的解决工夫。

• 合并速度慢

思路：既然读取曾经能够做到增量化了，那么合并也能够做到增量化，能够通过数据湖的能力结 合增量读取实现合并的增量化。

• 反复读取多

思路：反复读取多的次要起因是分区的粒度太粗了，只能准确到小时 / 天级别。咱们须要尝试一 些更加细粒度的数据组织计划，将 Data Skipping 能够做到字段级别，这样就能够进行高效的数 据查问了。

3. 解决方案: Magneto – 基于 Hudi 的增量数据湖平台

以下是基于 Magneto 构建的入仓流程：

• Flow

应用流式 Flow 的形式，对立离线和实时的 ETL Pipline

• Organizer

数据重组织，减速查问
反对增量数据的 compaction

• Engine

计算层应用 Flink，存储层应用 Hudi

• Metadata

提炼表计算 SQL 逻辑
标准化 Table Format 计算范式

二、数据湖技术计划

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 计划可供选择，然而都有劣势：

Bloom Index：应用 Bloom Index 的话，Spark 会在写入的时候，每个 task 都去 list 一遍所有的文件，读取 footer 内写入的 Bloom 过滤数据，这样会对咱们外部压力曾经十分大的 HDFS 造成十分恐怖的压力。

Hbase Index：这种形式倒是能够做到 O(1) 的找到索引，然而须要引入内部依赖，这样会使整个计划变的比拟重。

咱们须要和 Flink 增量解决的框架进行对接。

3. Flink + Hudi 集成的优化

3.1 Hudi 0.8 版本集成 Flink 计划

针对 Hudi 0.8 版本集成裸露进去的问题，B 站和社区单干进行了优化与欠缺。

3.2 Bootstrap State 冷启动

背景：反对在曾经存在 Hudi 表启动 Flink 工作写入，从而能够做到由 Spark on Hudi 到 Flink on Hudi 的计划切换

原计划：

问题：每个 Task 解决全量数据，而后抉择属于以后 Task 的 HoodieKey 存入 state 优化计划。

• 每个 Bootstrap Operator 在初始化时，加载属于以后 Task 的 fileId 相干的 BaseFile 和 logFile；
• 将 BaseFile 和 logFile 中的 recordKey 组装成 HoodieKey，通过 Key By 的模式发送给 BucketAssignFunction，而后将 HoodieKey 作为索引存储在 BucketAssignFunction 的 state 中。

成果：通过将 Bootstrap 性能独自抽出一个 Operator，做到了索引加载的可扩展性，加载速度晋升 N (取决于并发度) 倍。

3.3 Checkpoint 一致性优化

背景：在 Hudi 0.8 版本的 StreamWriteFunction 中，存在极其状况下的数据一致性问题。

原计划：

问题：CheckpointComplete 不在 CK 生命周期内，存在 CK 胜利然而 instant 没有 commit 的情 况，从而导致呈现数据失落。

优化计划：

3.4 Append 模式反对及优化

背景：Append 模式是用于反对不须要 update 的数据集时应用的模式，能够在流程中省略索引、合并等不必要的解决，从而大幅提高写入效率。

次要批改：

• 反对每次 FlushBucket 写入一个新的文件，避免出现读写的放大；
• 增加参数，反对敞开 BoundedInMemeoryQueue 外部的限速机制，在 Flink Append 模式下只须要将 Queue 的大小和 Bucket buffer 设置成同样的大小就能够了；
• 针对每个 CK 产生的小文件，制订自定义 Compaction 打算；
• 通过以上的开发和优化之后，在纯 Insert 场景下性能可达原先 COW 的 5 倍。

三、Hudi 工作稳定性保障

1. Hudi 集成 Flink Metrics

通过在要害节点上报 Metric，能够比拟清晰的把握整个工作的运行状况：

2. 零碎内数据校验

3. 零碎外数据校验

四、数据入湖实际

1. CDC 数据入湖

1.1 TiDB 入湖计划

因为目前开源的各种计划都没方法间接反对 TiDB 的数据导出，间接应用 Select 的形式会影响数 据库的稳定性，所以拆成了全量 + 增量的形式：

• 启动 TI-CDC，将 TIDB 的 CDC 数据写入对应的 Kafka topic；
• 利用 TiDB 提供的 Dumpling 组件，批改局部源码，反对间接写入 HDFS；
• 启动 Flink 将全量数据通过 Bulk Insert 的形式写入 Hudi；
• 生产增量的 CDC 数据，通过 Flink MOR 的形式写入 Hudi。

1.2 MySQL 入湖计划

MySQL 的入湖计划是间接应用开源的 Flink-CDC，将全量和增量数据通过一个 Flink 工作写入 Kafka topic：

• 启动 Flink-CDC 工作将全量数据以及 CDC 数据导入 Kafka topic；
• 启动 Flink Batch 工作读取全量数据，通过 Bulk Insert 写入 Hudi；
• 切换为 Flink Streaming 工作将增量 CDC 数据通过 MOR 的形式写入 Hudi。

2. 日志数据增量入湖

• 实现 HDFSStreamingSource 和 ReaderOperator，增量同步 ODS 的数据文件，并且通过写入 ODS 的分区索引信息，缩小对 HDFS 的 list 申请；
• 反对 transform SQL 配置化，容许用户进行自定义逻辑转化，包含但不限于维表 join、自定义 udf、按字段分流等；
• 实现 Flink on Hudi 的 Append 模式，大幅晋升不须要合并的数据写入速率。

五、增量数据湖平台收益

• 通过 Flink 增量同步大幅度晋升了数据同步的时效性，分区就绪工夫从 2:00~5:00 提前到 00:30 分内；
• 存储引擎应用 Hudi，提供用户基于 COW、MOR 的多种查问形式，让不同用户能够依据本人 的利用场景抉择适合的查问形式，而不是单纯的只能期待分区归档后查问；
• 相较于之前数仓的 T+1 Binlog 合并形式，基于 Hudi 的主动 Compaction 使得用户能够将 Hive 当成 MySQL 的快照进行查问；
• 大幅节约资源，原先须要反复查问的分流工作只须要执行一次，节约大概 18000 core。

六、社区奉献

上述优化都曾经合并到 Hudi 社区，B 站在将来会进一步增强 Hudi 的建设，与社区一起成⻓。

局部外围 PR

https://issues.apache.org/jir…

https://issues.apache.org/jir…

https://issues.apache.org/jir…

https://issues.apache.org/jir…

https://issues.apache.org/jir…

https://issues.apache.org/jir…

https://issues.apache.org/jir…

七、将来的倒退与思考

• 平台反对流批一体，对立实时与离线逻辑；
• 推动数仓增量化，达成 Hudi ODS -> Flink -> Hudi DW -> Flink -> Hudi ADS 的全流程；
• 在 Flink 上反对 Hudi 的 Clustering，体现出 Hudi 在数据组织上的劣势，并摸索 Z-Order 等减速多维查问的性能体现；
• 反对 inline clustering。

原文链接
本文为阿里云原创内容，未经容许不得转载。