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

演讲人：陈世治bilibili资深开发工程师 典型场景案例 未来工作展望 背景与挑战 基建与内核 背景与挑战 B站数仓当前架构与痛点 痛点： •批流双链路，不同的存储和计算组件，架构负担大，维护和资源成本高 •实链路路可观测行差，离线链路时效不足，资源峰值效应明显 •数据孤岛问题，在多组件间出入仓并流转，数据管理存在断层 •查询效率低，不依赖OLAP组件服务，无法满足高效数据分析 数据湖能力愿景 典型场景案例 RDB一键入湖 •背景：业务数据入湖，从datax+hive方案转向cdc+hudi方案，提升时效性 RDB一键入湖 •痛点：实时入湖对以往基于批全量同步的使用范式带来的挑战 用户要有感切换，且需自主过滤漂移数据•引申：SQL过滤无法对变更流生效实时变更，历史分区时刻变化，下游离线ETL任务无法稳定重跑 •潜在解决方案： Hudi Export Hive：使用割裂；架构和存储冗余 Hudi Savepoint：切分不准确问题未解决 RDB一键入湖 •优化方案：Hudi SnapshotView快照视图+多引擎读/写支持 Hudi支持过滤的分区视图快照，切分准确 •RT视图，创建后即可访问PredicatedFileSlice•过滤下推至log merge前，实现跨天/小时等时间分区的精准切分 HudiMeta映射视图数据文件，无冗余存储 独立timeline管理，支持对视图compaction物化、clustering加速等（下文展开） 多引擎支持，用户端使用姿势不变，hint/option切换（下文展开） RDB一键入湖 •问题：如何在(元)数据组织上，区分实时分区/增量快照分区/全量快照分区？ 引申思考：timeline新增action+过滤无法满足需求，因为它也有compaction等操作。这里面更多的是一种 •最终方案：基于Timeline的分支管理 实现类Git的timeline管理 •branch/tag create/delete•checkout，cherry-pick等 每个分支都有各自的表服务 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，减少数据摄取 流量日志分流 •方案查询性能对比 物化查询加速 •痛点: 开发运维成本高 •每出1个聚合指标，需要新增1个实时任务•可靠性低，单任务异常导致报表异常 •优化方案： 物化查询加速 Flink物化支持 •BatchSQL新增物化解析规则•Catalog支持物化视图，并集成Hudi•支持物化加载及进度 Hudi Meta拓展： •TableMeta支持projection元数据•InstantMeta拓展watermark进度 降级方案 •Alluxio Cache加速层可降级至HDFS•物化表可降级至原表 物化查询加速 •Hudi Batch查询优化 组件复用 •metaClient复用减少解析耗时 •线程池并行加载split•存算分离架构跳过本地优化block加载 实时数仓演进 •背景 •痛点 为数据兜底，2条链路重复建设，高成本Kafka可观测性差，DQC困难Kafka链路数据修复难数据出仓组件多，链路断层，成本高 实时数仓演进 •方案：Hudi替换Kafka/Hive/Mysql + Hudi DQC+ Flink替换Spark 降本，流批存储统一流批口径统一 报警方便，如同环比报警 实时离线统一DQC方案 基建与内核 Table Service优化 •表服务存在的问题 稳定性差，资源利用率低•写入与表服务各自的流批特征明显，适合剥离 •调整策略后作业需重新发布方可生效 •对于物化等自研表服务，拓展成本高•不可平台托管，用户门槛高 Table Service优化 •优化方案：表服务Standalone模式+ HudiManager 分区推进支持 •批流融合过程中分区推进的痛点： 社区功能集中在分区sync而非advance流转批场景下，实时写入链路，无法在确认数据到位后，调度下游离线任务无法照顾到实时分析和离线ETL两种场景 •方案：基于Watermark推进分区+ HMSPartition 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不可读 •方案：InstantRollback +SavepointRollback兜底，以Spark Procedure接入 坏instant前有正常instant，直接rollback否则，rollback至最近的一次savepointsavepoint以周期性生成和过期，托管到HudiManager 未来工作展望 未来工作展望 •数据湖内核能力增强：Hudi Join优化、无锁并发更新、读能力增强 •数据湖基建完善：统一Metastore、表服务增强 •流批一体场景落地：搜推广、数仓模型层能力建设 •平台化：回跑能力工具化、平台流批服务打通 演讲人：陈世治bilibili资深开发工程师