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

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: B 站选择 Flink + Hudi 的数据湖技术方案,以及针对其做出的优化。

本文作者喻兆靖,介绍了为什么 B 站选择 Flink + Hudi 的数据湖技术方案,以及针对其做出的优化。主要内容为:

  1. 传统离线数仓痛点
  2. 数据湖技术方案
  3. Hudi 任务稳定性保障
  4. 数据入湖实践
  5. 增量数据湖平台收益
  6. 社区贡献
  7. 未来的发展与思考

GitHub 地址
https://github.com/apache/flink
欢迎大家给 Flink 点赞送 star~

一、传统离线数仓痛点

1. 痛点

之前 B 站数仓的入仓流程大致如下所示:

img

在这种架构下产生了以下几个核心痛点:

  1. 大规模的数据落地 HDFS 后,只能在凌晨分区归档后才能查询并做下一步处理;
  2. 数据量较大的 RDS 数据同步,需要在凌晨分区归档后才能处理,并且需要做排序、去重以及 join 前一天分区的数据,才能产生出当天的数据;
  3. 仅能通过分区粒度读取数据,在分流等场景下会出现大量的冗余 IO。

总结一下就是:

  • 调度启动晚;
  • 合并速度慢;
  • 重复读取多。

2. 痛点思考

  • 调度启动晚

    思路:既然 Flink 落 ODS 是准实时写入的,有明确的文件增量概念,可以使用基于文件的增量同 步,将清洗、补维、分流等逻辑通过增量的方式进行处理,这样就可以在 ODS 分区未归档的时 候就处理数据,理论上数据的延迟只取决于最后一批文件的处理时间。

  • 合并速度慢

    思路:既然读取已经可以做到增量化了,那么合并也可以做到增量化,可以通过数据湖的能力结 合增量读取完成合并的增量化。

  • 重复读取多

    思路:重复读取多的主要原因是分区的粒度太粗了,只能精确到小时/天级别。我们需要尝试一 些更加细粒度的数据组织方案,将 Data Skipping 可以做到字段级别,这样就可以进行高效的数 据查询了。

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

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

img

  • Flow

    • 使用流式 Flow 的方式,统一离线和实时的 ETL Pipline
  • Organizer

    • 数据重组织,加速查询
    • 支持增量数据的 compaction
  • Engine

    • 计算层使用 Flink,存储层使用 Hudi
  • Metadata

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

二、数据湖技术方案

1. Iceberg 与 Hudi 的取舍

1.1 技术细节对比

img

1.2 社区活跃度对比

统计截止至 2021-08-09

img

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 的主要原因有三个:

  1. 我们部分自己维护了 Flink 引擎,支撑了全公司的实时计算,从成本上考虑不想同时维护两套计算引擎,尤其是在我们内部 Spark 版本也做了很多内部修改的情况下。
  2. Spark + Hudi 的集成方案主要有两种 Index 方案可供选择,但是都有劣势:

    • Bloom Index:使用 Bloom Index 的话,Spark 会在写入的时候,每个 task 都去 list 一遍所有的文件,读取 footer 内写入的 Bloom 过滤数据,这样会对我们内部压力已经非常大的 HDFS 造成非常恐怖的压力。
    • Hbase Index:这种方式倒是可以做到 O(1) 的找到索引,但是需要引入外部依赖,这样会使整个方案变的比较重。
  3. 我们需要和 Flink 增量处理的框架进行对接。

3. Flink + Hudi 集成的优化

3.1 Hudi 0.8 版本集成 Flink 方案

img

针对 Hudi 0.8 版本集成暴露出来的问题,B站和社区合作进行了优化与完善。

3.2 Bootstrap State 冷启动

背景:支持在已经存在 Hudi 表启动 Flink 任务写入,从而可以做到由 Spark on Hudi 到 Flink on Hudi 的方案切换

原方案:

img

问题:每个 Task 处理全量数据,然后选择属于当前 Task 的 HoodieKey 存入 state 优化方案。

img

  • 每个 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 中,存在极端情况下的数据一致性问题。

原方案:

img

问题:CheckpointComplete不在CK生命周期内,存在CK成功但是instant没有commit的情 况,从而导致出现数据丢失。

优化方案:

img

3.4 Append 模式支持及优化

背景:Append 模式是用于支持不需要 update 的数据集时使用的模式,可以在流程中省略索引、 合并等不必要的处理,从而大幅提高写入效率。

img

主要修改:

  • 支持每次 FlushBucket 写入一个新的文件,避免出现读写的放大;
  • 添加参数,支持关闭 BoundedInMemeoryQueue 内部的限速机制,在 Flink Append 模式下只需要将 Queue 的大小和 Bucket buffer 设置成同样的大小就可以了;
  • 针对每个 CK 产生的小文件,制定自定义 Compaction 计划;
  • 通过以上的开发和优化之后,在纯 Insert 场景下性能可达原先 COW 的 5 倍。

三、Hudi 任务稳定性保障

1. Hudi 集成 Flink Metrics

通过在关键节点上报 Metric,可以比较清晰的掌握整个任务的运行情况:

img

img

2. 系统内数据校验

img

3. 系统外数据校验

img

四、数据入湖实践

1. CDC数据入湖

1.1 TiDB入湖方案

由于目前开源的各种方案都没办法直接支持 TiDB 的数据导出,直接使用 Select 的方式会影响数 据库的稳定性,所以拆成了全量 + 增量的方式:

  1. 启动 TI-CDC,将 TIDB 的 CDC 数据写入对应的 Kafka topic;
  2. 利用 TiDB 提供的 Dumpling 组件,修改部分源码,支持直接写入 HDFS;
  3. 启动 Flink 将全量数据通过 Bulk Insert 的方式写入 Hudi;
  4. 消费增量的 CDC 数据,通过 Flink MOR 的方式写入 Hudi。

1.2 MySQL 入湖方案

MySQL 的入湖方案是直接使用开源的 Flink-CDC,将全量和增量数据通过一个 Flink 任务写入 Kafka topic:

  1. 启动 Flink-CDC 任务将全量数据以及 CDC 数据导入 Kafka topic;
  2. 启动 Flink Batch 任务读取全量数据,通过 Bulk Insert 写入 Hudi;
  3. 切换为 Flink Streaming 任务将增量 CDC 数据通过 MOR 的方式写入 Hudi。

img

2. 日志数据增量入湖

  • 实现 HDFSStreamingSource 和 ReaderOperator,增量同步 ODS 的数据文件,并且通过写入 ODS 的分区索引信息,减少对 HDFS 的 list 请求;
  • 支持 transform SQL 配置化,允许用户进行自定义逻辑转化,包括但不限于维表 join、自定义 udf、按字段分流等;
  • 实现 Flink on Hudi 的 Append 模式,大幅提升不需要合并的数据写入速率。

img

五、增量数据湖平台收益

  • 通过 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/jira/projects/Hudi/issues/Hudi-1923

https://issues.apache.org/jira/projects/Hudi/issues/Hudi-1924

https://issues.apache.org/jira/projects/Hudi/issues/Hudi-1954

https://issues.apache.org/jira/projects/Hudi/issues/Hudi-2019

https://issues.apache.org/jira/projects/Hudi/issues/Hudi-2052

https://issues.apache.org/jira/projects/Hudi/issues/Hudi-2084

https://issues.apache.org/jira/projects/Hudi/issues/Hudi-2342

七、未来的发展与思考

  • 平台支持流批一体,统一实时与离线逻辑;
  • 推进数仓增量化,达成 Hudi ODS -> Flink -> Hudi DW -> Flink -> Hudi ADS 的全流程;
  • 在 Flink 上支持 Hudi 的 Clustering,体现出 Hudi 在数据组织上的优势,并探索 Z-Order 等加速多维查询的性能表现;
  • 支持 inline clustering。

第三届 Apache Flink 极客挑战赛报名开始!
30 万奖金等你来!

伴随着海量数据的冲击,数据处理分析能力在业务中的价值与日俱增,各行各业对于数据处理时效性的探索也在不断深入,作为主打实时计算的计算引擎 - Apache Flink 应运而生。

为给行业带来更多实时计算赋能实践的思路,鼓励广大热爱技术的开发者加深对 Flink 的掌握,Apache Flink 社区联手阿里云、英特尔、阿里巴巴人工智能治理与可持续发展实验室 (AAIG)、Occlum 联合举办 "第三届 Apache Flink 极客挑战赛暨 AAIG CUP" 活动,即日起正式启动。

👉 点击了解更多赛事信息 👈

img


更多 Flink 相关技术问题,可扫码加入社区钉钉交流群
第一时间获取最新技术文章和社区动态,请关注公众号~

image.png

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动:
99 元试用 实时计算Flink版(包年包月、10CU)即有机会获得 Flink 独家定制T恤;另包 3 个月及以上还有 85 折优惠!
了解活动详情:https://www.aliyun.com/product/bigdata/sc

image.png

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
18天前
|
消息中间件 存储 监控
构建高可用性Apache Kafka集群:从理论到实践
【10月更文挑战第24天】随着大数据时代的到来,数据传输与处理的需求日益增长。Apache Kafka作为一个高性能的消息队列服务,因其出色的吞吐量、可扩展性和容错能力而受到广泛欢迎。然而,在构建大规模生产环境下的Kafka集群时,保证其高可用性是至关重要的。本文将从个人实践经验出发,详细介绍如何构建一个高可用性的Kafka集群,包括集群规划、节点配置以及故障恢复机制等方面。
50 4
|
17天前
|
存储 数据挖掘 数据处理
巴别时代使用 Apache Paimon 构建 Streaming Lakehouse 的实践
随着数据湖技术的发展,企业纷纷探索其优化潜力。本文分享了巴别时代使用 Apache Paimon 构建 Streaming Lakehouse 的实践。Paimon 支持流式和批处理,提供高性能、统一的数据访问和流批一体的优势。通过示例代码和实践经验,展示了如何高效处理实时数据,解决了数据一致性和故障恢复等挑战。
99 61
|
3月前
|
消息中间件 运维 Kafka
Apache Flink 实践问题之达到网卡的最大速度如何解决
Apache Flink 实践问题之达到网卡的最大速度如何解决
46 2
|
1月前
|
存储 小程序 Apache
10月26日@杭州,飞轮科技 x 阿里云举办 Apache Doris Meetup,探索保险、游戏、制造及电信领域数据仓库建设实践
10月26日,由飞轮科技与阿里云联手发起的 Apache Doris 杭州站 Meetup 即将开启!
54 0
|
3月前
|
数据采集 分布式计算 Kubernetes
Apache Flink 实践问题之ZooKeeper 网络瞬断时如何解决
Apache Flink 实践问题之ZooKeeper 网络瞬断时如何解决
91 4
|
3月前
|
存储 消息中间件 Java
Apache Flink 实践问题之原生TM UI日志问题如何解决
Apache Flink 实践问题之原生TM UI日志问题如何解决
45 1
|
28天前
|
SQL Java API
Apache Flink 2.0-preview released
Apache Flink 社区正积极筹备 Flink 2.0 的发布,这是自 Flink 1.0 发布以来的首个重大更新。Flink 2.0 将引入多项激动人心的功能和改进,包括存算分离状态管理、物化表、批作业自适应执行等,同时也包含了一些不兼容的变更。目前提供的预览版旨在让用户提前尝试新功能并收集反馈,但不建议在生产环境中使用。
575 13
Apache Flink 2.0-preview released
|
1月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
63 3
|
2月前
|
SQL 消息中间件 关系型数据库
Apache Doris Flink Connector 24.0.0 版本正式发布
该版本新增了对 Flink 1.20 的支持,并支持通过 Arrow Flight SQL 高速读取 Doris 中数据。
|
3月前
|
消息中间件 监控 数据挖掘
基于RabbitMQ与Apache Flink构建实时分析系统
【8月更文第28天】本文将介绍如何利用RabbitMQ作为数据源,结合Apache Flink进行实时数据分析。我们将构建一个简单的实时分析系统,该系统能够接收来自不同来源的数据,对数据进行实时处理,并将结果输出到另一个队列或存储系统中。
217 2

推荐镜像

更多