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

总结

背景与挑战

B站数仓当前架构存在批流双链路负担大、可观测性差、数据孤岛、查询效率低等痛点。未来愿景是构建数据湖能力，解决现有问题。

典型场景案例

1. RDB一键入湖

   • 痛点：实时入湖挑战传统批全量同步范式，用户需感知切换并过滤漂移数据。
   • 解决方案：采用Hudi SnapshotView快照视图+多引擎读写支持，实现分区精准切分、无冗余存储、独立timeline管理。
   • 核心方案：基于Timeline的分支管理（类似Git），区分实时分区/增量快照分区/全量快照分区；写入/读取引擎适配（FlinkBatch/Spark/Hive等）。
   • 收益：降本（分区粒度增量存储）、增效（分钟级时效）、使用简单。

2. 流量日志分流

   • 痛点：时效性不足（小时级产出）、稳定性差（业务隔离性差）、分流方式不够灵活（按组分区）。
   • 解决方案：Hudi替换Hive + 传输层边缘分流 + 仓内分流（Hudi Clustering + Flink View支持）。
   • 收益：下游支持Hudi增量消费（分钟级时效）、增强隔离性和稳定性、减少数据摄取。

3. 物化查询加速

   • 痛点：开发运维成本高、可靠性低。
   • 解决方案：Flink物化支持（BatchSQL新增物化解析规则、Catalog支持物化视图）、Hudi Meta拓展（TableMeta支持projection、InstantMeta拓展watermark进度）。
   • 收益：降本（Alluxio Cache加速层、物化表降级）、增效（组件复用、存算分离架构）。

4. 实时数仓演进

   • 痛点：链路重复建设、Kafka可观测性差、数据修复难、链路断层。
   • 解决方案：Hudi替换Kafka/Hive/Mysql + Hudi DQC + Flink替换Spark。
   • 收益：降本（流批存储统一）、增效（流批口径统一、实时离线统一DQC方案）。

基建与内核

1. Table Service优化

   • 问题：稳定性差、资源利用率低、拓展成本高。
   • 优化方案：表服务Standalone模式 + HudiManager。

2. 分区推进支持

   • 痛点：社区功能集中在分区sync而非advance，流转批场景下无法确认数据到位后调度下游任务。
   • 方案：基于Watermark推进分区 + HMSPartition Metadata拓展，保障准确推进；实时分析/离线ETL适配查询。

3. 数据回滚增强

   • 痛点：流批SQL不统一、Kafka链路修复能力弱。
   • 方案：HudiCatalog回滚功能 + Flink Batch替代Spark（历史分区overwrite、当前分区drop+overwrite）、平台支持一键级联重跑。
   • 元数据回滚方案：InstantRollback + SavepointRollback（Spark Procedure接入）。

未来工作展望

1. 数据湖内核能力增强：Hudi Join优化、无锁并发更新、读能力增强。
2. 数据湖基建完善：统一Metastore、表服务增强。
3. 流批一体场景落地：搜推广、数仓模型层能力建设。
4. 平台化：回跑能力工具化、平台流批服务打通。