— 2023 —

基于Hudi+Flink打造流式数据湖的
落地实践

演讲人：陈世治 bilibili 资深开发工程师

背景与挑战 典型场景案例 基建与内核 未来工作展望
背景与挑战
 B站数仓当前架构与痛点
痛点：

• 批流双链路，不同的存储和计算组件，
架构负担大，维护和资源成本高

• 实链路路可观测行差，离线链路时效
不足，资源峰值效应明显

• 数据孤岛问题，在多组件间出入仓并
流转，数据管理存在断层

• 查询效率低，不依赖OLAP组件服务，
无法满足高效数据分析
数据湖能力愿景
典型场景案例
RDB一键入湖 流量日志分流 物化查询加速 实时数仓演进
 RDB一键入湖
• 背景：业务数据入湖，从datax+hive方案转向cdc+hudi方案，提升时效性
 RDB一键入湖
• 痛点：实时入湖对以往基于批全量同步的使用范式带来的挑战

 用户要有感切换，且需自主过滤漂移数据
• 引申：SQL过滤无法对变更流生效

 实时变更，历史分区时刻变化，下游离线

ETL任务无法稳定重跑

• 潜在解决方案：

Hudi Export Hive：使用割裂；架构和存储冗余 Hudi Savepoint：切分不准确问题未解决

 RDB一键入湖
• 优化方案：Hudi SnapshotView 快照视图 + 多引擎读/写支持

 Hudi支持过滤的分区视图快照，切分准确

• RT视图，创建后即可访问PredicatedFileSlice

• 过滤下推至log merge前，实现跨天/小时等时

间分区的精准切分

 Hudi Meta映射视图数据文件，无冗余存储

 独立timeline管理，支持对视图compaction物

化、clustering加速等（下文展开）

 多引擎支持，用户端使用姿势不变，

hint/option切换（下文展开）
 RDB一键入湖
• 问题：如何在(元)数据组织上，区分实时分区/增量快照分区/全量快照分区？

 引申思考：timeline新增action+过滤无法满足需求，因为它也有compaction等操作。这里面更多的是一种

用户场景或视图的切换

• 最终方案：基于Timeline的分支管理

 实现类Git的timeline管理

• branch/tag create/delete

• checkout，cherry-pick等

 轻量的timeline分支操作，实时/增量

快照/全量快照便捷切换

 每个分支都有各自的表服务
 RDB一键入湖
• 问题：写入/读取的引擎适配

 写入：需判断snapshot view生成时机
• 分区提交时确认数据到位，触发快照生成
• 基于watermark的分区推进机制（后续介绍）

 读取：支持FlinkBatch/Spark/Hive等查询引擎

• 收益：

 降本
• 每分区粒度只存增量，大幅降低存储成本

 增效：
• 时效性分钟级
• 使用姿势简单，支持实时/增量/全量分区
• 替代原拉链表使用范式
 流量日志分流
• 背景：千亿级流量，万级别行为事件分类，产出数据供全站各BU交叉使用

• 痛点：
 时效性不足
• 小时级产出，下游有分钟级诉求

 稳定性不足
• 传输层->ODS->DWD 1条流产出，
含主站/直播/游戏等，业务隔离性差

 以业务类型分区的分流方式不够灵活
• 业务向的物理分区，到位通知复杂
• 对1w+ 事件类型，只能按组分区，
下游使用仍需过滤大量数据
• 数据跨BU交叉订阅，权限管理混乱
 流量日志分流
• 方案：Hudi替换Hive + 传输层：边缘分流 + 仓内分流：Hudi Clustering + Flink View支持

 Hudi Append替换原Hive
• 下游支持Hudi增量消费，分钟级时效

 传输层分流
• 平台边缘开始根据规则动态分流
• 单流单job，增强隔离性和稳定性

 仓内分流
• 去除业务意义上的物理分区，下游通过
视图View访问，业务字段为逻辑分区
• Hudi Clustering逻辑分区字段 ，通过
dataskip，减少数据摄取
 流量日志分流
• 方案查询性能对比
Hive 与Hudi Clustering + View查询性能对比
1600

1400

1200

1000

800

600

400

200

-200
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
读hudi表时间/s 192 684 100 212 78 88 229 84 24 275 255 95 89 28 207 43 75 171
读hive表时间/s 222 1382 93 551 73 125 202 165 42 282 489 89 131 132 723 188 53 229
性能提升/% 13 50 -7 61 -6 29 -13 49 42 2 47 -6 32 78 71 77 -41 25

读hudi表时间/s 读hive表时间/s 性能提升/%

 物化查询加速
• 痛点:

 数据出仓管理难

• ADS数据需出仓到Mysql/Clickhouse等

 聚合查询时间长，IO放大严重
• DQC：每5min统计1h窗口内数据
• BI报表：DAU曲线，需历史累积

 开发运维成本高
• 每出1个聚合指标，需要新增1个实时任务
• 可靠性低，单任务异常导致报表异常

• 优化方案：

Flink视图支持 + Hudi Projection物化加速 + Alluxio缓存加速

 物化查询加速

 Flink物化支持
• BatchSQL新增物化解析规则
• Catalog支持物化视图，并集成Hudi
• 支持物化加载及进度

 Hudi Meta拓展：
• TableMeta支持projection元数据
• InstantMeta拓展watermark进度

 降级方案
• Alluxio Cache加速层可降级至HDFS
• 物化表可降级至原表
 物化查询加速
• Hudi Batch查询优化
 组件复用
• metaClient复用减少解析耗时

 Split生成加速
• 线程池并行加载split
• 存算分离架构跳过本地优化block加载

 基于FileIndex加速
• 基于索引的batch并行度推测

 基于Clustering加速
• 对物化Upsert表，支持历史数据Clustering
 实时数仓演进
• 背景

• 痛点
 为数据兜底，2条链路重复建设，高成本
 Kafka可观测性差，DQC困难
 Kafka链路数据修复难
 数据出仓组件多，链路断层，成本高
 实时数仓演进
• 方案：Hudi替换Kafka/Hive/Mysql + Hudi DQC+ Flink替换Spark

Hudi替换Kafka MQ场景 支持近实时DQC 数据不出仓直连BI

 降本，流批存储统一  对比Kafka，可直接查询Hudi表中数据做  节省ADS层多组件存储

 流批口径统一 DQC，无需dump
 报警方便，如同环比报警
 实时离线统一DQC方案
基建与内核
TableService优化 分区推进支持 数据回滚增强
 Table Service优化
• 表服务存在的问题
 稳定性差，资源利用率低
• 写入与表服务各自的流批特征明显，
适合剥离

 策略灵活度差
• 调整策略后作业需重新发布方可生效

 模块耦合度高
• 对于物化等自研表服务，拓展成本高
• 不可平台托管，用户门槛高
 Table Service优化
• 优化方案：表服务Standalone模式 + Hudi Manager
 分区推进支持
• 批流融合过程中分区推进的痛点：

 社区功能集中在分区sync而非advance

 流转批场景下，实时写入链路，无法在确认

数据到位后，调度下游离线任务

 无法照顾到实时分析和离线ETL两种场景

• 方案：基于Watermark推进分区 + HMS

Partition Metadata拓展

 基于watermark/写入数据/上次状态来推进，保障准确推进

 HMS Partition commit 分为arrival(commit = false)，ready(commit = true) 2次提交

 分区推进进度存在PartitionState里，避免重启等异常引起丢失
 分区推进支持
• 引擎适配

 实时分析：sql hint查询当前所有arrival commit分区数据文件

 离线ETL：默认查询所有ready commit的分区下的数据文件
 数据回滚增强
• 数据回滚，可分为业务数据回滚和元数据异常运维2个部分。

• 批流融合过程中，数据回滚有如下痛点：

 流批SQL不统一，流写入基于Flink，批量

修复基于Spark

 基于Kafka的链路，基本无修复能力

• 基于Hudi + Flink的方案：

 HudiCatalog回滚功能，增强并发更新能力(有锁)

 Flink Batch替代Spark
• 历史分区：batch overwrite
• 当前分区：drop partition + stream overwrite

 平台支持一键级联重跑
 数据回滚增强
• Hudi元数据有如下面临回滚修复的场景：

 发现元数据状态跟数据文件不一致

 因HDFS坏块等导致archive timeline或

instant不可读

• 方案：Instant Rollback + Savepoint Rollback兜

底，以Spark Procedure接入

 坏instant前有正常instant，直接rollback

 否则，rollback至最近的一次savepoint

 savepoint以周期性生成和过期，托管到HudiManager
未来工作展望
 未来工作展望
• 数据湖内核能力增强：Hudi Join优化、无锁并发更新、读能力增强

• 数据湖基建完善：统一Metastore、表服务增强

• 流批一体场景落地：搜推广、数仓模型层能力建设

• 平台化：回跑能力工具化、平台流批服务打通
演讲人：陈世治 bilibili 资深开发工程师