站构建实时数据湖的通常 B Apache Hudi 在

本文作者喻兆靖，引见了为什么 B 站选用 Flink + Hudi 的数据湖技术方案，以及针对其做出的优化。重要内容为：

1.传统离线数仓痛点

2.数据湖技术方案

3.Hudi 义务稳固性保证

4.数据入湖通常

5.增量数据湖平台收益

6.社区奉献

7.未来的开展与思索

一、传统离线数仓痛点

1. 痛点

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

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

总结一下就是:

2. 痛点思索

3. 处置方案: Magneto - 基于 Hudi 的增量数据湖平台

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

二、数据湖技术方案

1. Iceberg 与 Hudi 的取舍

统计截止至 2021-08-09

大抵可以分为以下几个重要纬度来启动对比：

综合对比，咱们选用了 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 集成的优化

针对 Hudi 0.8 版本集成暴显露来的疑问，B站和社区协作启动了优化与完善。

背景： 支持在曾经存在 Hudi 表启动 Flink 义务写入，从而可以做到由 Spark on Hudi 到 Flink on Hudi 的方案切换

原方案：

疑问： 每个 Task 处置全量数据，而后选用属于 Task 的 HoodieKey 存入 state 优化方案。

成果： 经过将 Bootstrap 性能独自抽出一个 Operator，做到了索引加载的可裁减性，加载速度优化 N (取决于并发度) 倍。

背景： 在 Hudi 0.8 版本的 StreamWriteFunction 中，存在极其状况下的数据分歧性疑问。

原方案：

疑问： CheckpointComplete不在CK生命周期内，存在CK成功然而instant没有commit的情 况，从而造成发生数据失落。

优化方案：

背景 ：Append 形式是用于支持不须要 update 的数据集时经常使用的形式，可以在流程中省略索引、 兼并等不用要的处置，从而大幅提高写入效率。

重要修正：

三、Hudi 义务稳固性保证

1. Hudi 集成 Flink Metrics

经过在关键节点上报 Metric，可以比拟明晰的把握整个义务的运转状况：

2. 系统内数据校验

3. 系统外数据校验

四、数据入湖通常

1. CDC数据入湖

因为目前开源的各种方案都没方法间接支持 TiDB 的数据导出，间接经常使用 Select 的方式会影响数 据库的稳固性，所以拆成了全量 + 增量的方式：

MySQL 的入湖方案是间接经常使用开源的 Flink-CDC，将全量和增量数据经过一个 Flink 义务写入 Kafka topic：

2. 日志数据增量入湖

五、增量数据湖平台收益

六、社区奉献

上述优化都曾经兼并到 Hudi 社区，B站在未来会进一步增强 Hudi 的树立，与社区一同成。

局部外围PR

七、未来的开展与思索