AI 助理
文档备案控制台
开发者社区 大数据与机器学习 实时计算 Flink 文章 正文

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

2021-09-06 3370
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 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

文章标签：
实时计算 Flink版
云原生数据仓库AnalyticDB MySQL版
云数据库 RDS MySQL 版
前端开发
消息中间件
流计算
分布式计算
关系型数据库
索引
MySQL
Kafka
Spark
Apache
关键词：
Apache实践
Apache hudi
数据湖hudi
Apache数据湖
hudi数据湖
相关实践学习
基于Hologres+Flink搭建GitHub实时数据大屏
通过使用Flink、Hologres构建实时数仓，并通过Hologres对接BI分析工具（以DataV为例），实现海量数据实时分析.
实时计算 Flink 实战课程
如何使用实时计算 Flink 搞定数据处理难题？实时计算 Flink 极客训练营产品、技术专家齐上阵，从开源 Flink功能介绍到实时计算 Flink 优势详解，现场实操，5天即可上手！ 欢迎开通实时计算 Flink 版： https://cn.aliyun.com/product/bigdata/sc Flink Forward Asia 介绍： Flink Forward 是由 Apache 官方授权，Apache Flink Community China 支持的会议，通过参会不仅可以了解到 Flink 社区的最新动态和发展计划，还可以了解到国内外一线大厂围绕 Flink 生态的生产实践经验，是 Flink 开发者和使用者不可错过的盛会。 去年经过品牌升级后的 Flink Forward Asia 吸引了超过2000人线下参与，一举成为国内最大的 Apache 顶级项目会议。结合2020年的特殊情况，Flink Forward Asia 2020 将在12月26日以线上峰会的形式与大家见面。
阿里云实时计算Flink
目录
相关文章
存储 数据管理 物联网
866 0
存储 SQL 分布式计算
466 0
探索云世界动手实践
|
存储 分布式计算 大数据
基于阿里云大数据平台的实时数据湖构建与数据分析实战
在大数据时代，数据湖作为集中存储和处理海量数据的架构，成为企业数据管理的核心。阿里云提供包括MaxCompute、DataWorks、E-MapReduce等在内的完整大数据平台，支持从数据采集、存储、处理到分析的全流程。本文通过电商平台案例，展示如何基于阿里云构建实时数据湖，实现数据价值挖掘。平台优势包括全托管服务、高扩展性、丰富的生态集成和强大的数据分析工具。
探索云世界动手实践
751 1
技术内容小助手
|
存储 SQL 大数据
从数据存储到分析：构建高效开源数据湖仓解决方案
今年开源大数据迈向湖仓一体（Lake House）时代，重点介绍Open Lake解决方案。该方案基于云原生架构，兼容开源生态，提供开箱即用的数据湖仓产品。其核心优势在于统一数据管理和存储，支持实时与批处理分析，打破多计算产品的数据壁垒。通过阿里云的Data Lake Formation和Apache Paimon等技术，用户可高效搭建、管理并分析大规模数据，实现BI和AI融合，满足多样化数据分析需求。
技术内容小助手
1473 7
郑小健
|
数据采集 存储 分布式计算
构建智能数据湖：DataWorks助力企业实现数据驱动转型
【8月更文第25天】本文将详细介绍如何利用阿里巴巴云的DataWorks平台构建一个智能、灵活、可扩展的数据湖存储体系，以帮助企业实现数据驱动的业务转型。我们将通过具体的案例和技术实践来展示DataWorks如何集成各种数据源，并通过数据湖进行高级分析和挖掘，最终基于数据洞察驱动业务增长和创新。
郑小健
808 53
游客lkw7toijkbadm
|
存储 搜索推荐 数据建模
阿里巴巴大数据实践之数据建模：构建企业级数据湖
阿里巴巴通过构建高效的数据湖和实施先进的数据建模策略，实现了数据驱动的业务增长。这些实践不仅提升了内部运营效率，也为客户提供了更好的服务体验。随着数据量的不断增长和技术的不断创新，阿里巴巴将持续优化其数据建模方法，以适应未来的变化和发展。
游客lkw7toijkbadm
1237 7
灵杰开发者
|
9月前
|
人工智能 数据处理 API
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新，共筑基于 Apache Flink Agents 的智能体 AI 未来
Apache Flink Agents 是由阿里云、Ververica、Confluent 与 LinkedIn 联合推出的开源子项目，旨在基于 Flink 构建可扩展、事件驱动的生产级 AI 智能体框架，实现数据与智能的实时融合。
灵杰开发者
1467 6
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新，共筑基于 Apache Flink Agents 的智能体 AI 未来
灵杰开发者
|
10月前
|
人工智能 运维 Java
Flink Agents：基于Apache Flink的事件驱动AI智能体框架
本文基于Apache Flink PMC成员宋辛童在Community Over Code Asia 2025的演讲，深入解析Flink Agents项目的技术背景、架构设计与应用场景。该项目聚焦事件驱动型AI智能体，结合Flink的实时处理能力，推动AI在工业场景中的工程化落地，涵盖智能运维、直播分析等典型应用，展现其在AI发展第四层次——智能体AI中的重要意义。
灵杰开发者
3209 27
Flink Agents：基于Apache Flink的事件驱动AI智能体框架
灵杰开发者
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构：Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享，深入解析 Flink 状态管理系统的发展历程，从核心设计到 Flink 2.0 存算分离架构，并展望未来基于流批一体的通用增量计算方向。
灵杰开发者
667 0
从嵌入式状态管理到云原生架构：Apache Flink 的演进与下一代增量计算范式
灵杰开发者
|
11月前
|
消息中间件 存储 Kafka
Apache Flink错误处理实战手册：2年生产环境调试经验总结
本文由 Ververica 客户成功经理 Naci Simsek 撰写，基于其在多个行业 Flink 项目中的实战经验，总结了 Apache Flink 生产环境中常见的三大典型问题及其解决方案。内容涵盖 Kafka 连接器迁移导致的状态管理问题、任务槽负载不均问题以及 Kryo 序列化引发的性能陷阱，旨在帮助企业开发者避免常见误区，提升实时流处理系统的稳定性与性能。
灵杰开发者
830 0
Apache Flink错误处理实战手册：2年生产环境调试经验总结
大数据与机器学习

实时计算 Flink

热门文章

最新文章

  • 1
    数据仓库介绍与实时数仓案例
  • 2
    流计算StreamCompute
  • 3
    Flume+Kafka+Flink+Redis构建大数据实时处理系统：实时统计网站PV、UV展示
  • 4
    流计算精品翻译: The Dataflow Model
  • 5
    接着！！Apache Flink 全领域干货合集（持续更新）
  • 6
    回顾 | Kafka x Flink Meetup 与世界人工智能大会大数据 AI 专场精彩回顾（附PPT下载）
  • 7
    Flink SQL 功能解密系列 —— 流式 TopN 挑战与实现
  • 8
    Apache Flink 的迁移之路，2 年处理效果提升 5 倍
  • 9
    基于实时计算（Flink）打造一个简单的实时推荐系统
  • 10
    广告场景下的实时计算
  • 1
    Skill即服务：用Agent安全玩转云上Flink
    380
  • 2
    Flink Forward Asia 2026 官宣深圳｜From Cloud Native to AI Native
    959
  • 3
    Flink Agents 0.3 Roadmap解读
    575
  • 4
    相约深圳，全球征集｜Flink Forward Asia 2026 演讲议题征集正式启动
    719
  • 5
    Flink CDC 3.6.0：支持 Flink 1.20/2.2, MySQL/PostgreSQL入湖入流支持Schema Evolution
    978
  • 6
    Apache Flink Agents 0.2.1 发布公告
    382
  • 7
    （二）走进阿里云实时计算Flink版-场景案例篇
    1056
  • 8
    （一）走进阿里云实时计算Flink版-产品能力篇
    1021
  • 9
    Flink 实时计算 x SLS 存储下推：阿里云 OpenAPI 网关监控平台实践
    875
  • 10
    基于Flink CDC的企业级日志实时入湖入流解决方案
    763

    • 相关课程

    更多
  • 大数据知识图谱系列—如何选择合适的OLAP引擎进行数据湖分析

    • 相关电子书

    更多
  • DLA 一站式数据湖管理-如何高效构建安全的数据湖？
  • 阿里云云原生数据湖体系全解读
  • 数据湖存储解决方案蓝皮书
    • 下一篇
    一条命令迁移，帮你实现 OpenClaw 与 Hermes Agent 记忆互通！