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

《基于Hudi+Flink打造流式数据湖的落地实践.pdf》由会员分享，可在线阅读，更多相关《基于Hudi+Flink打造流式数据湖的落地实践.pdf（31页珍藏版）》请在三个皮匠报告上搜索。

1、基于Hudi+Flink打造流式数据湖的落地实践演讲人：陈世治 bilibili 资深开发工程师 2023 背景与挑战典型场景案例基建与内核未来工作展望背景与挑战B站数仓当前架构与痛点痛点：批流双链路，不同的存储和计算组件，架构负担大，维护和资源成本高 实链路路可观测行差，离线链路时效不足，资源峰值效应明显 数据孤岛问题，在多组件间出入仓并流转，数据管理存在断层 查询效率低，不依赖OLAP组件服务，无法满足高效数据分析数据湖能力愿景典型场景案例RDB一键入湖流量日志分流物化查询加速实时数仓演进RDB一键入湖 背景：业务数据入湖，从datax+hive方案转向cdc+hudi方案，提升时效性RD

2、B一键入湖 痛点：实时入湖对以往基于批全量同步的使用范式带来的挑战 潜在解决方案：Hudi Export Hive：使用割裂；架构和存储冗余Hudi Savepoint：切分不准确问题未解决 用户要有感切换，且需自主过滤漂移数据引申：SQL过滤无法对变更流生效 实时变更，历史分区时刻变化，下游离线ETL任务无法稳定重跑RDB一键入湖 优化方案：Hudi SnapshotView 快照视图+多引擎读/写支持 Hudi支持过滤的分区视图快照，切分准确RT视图，创建后即可访问PredicatedFileSlice过滤下推至log merge前，实现跨天/小时等时间分区的精准切分 Hudi Meta映

3、射视图数据文件，无冗余存储 独立timeline管理，支持对视图compaction物化、clustering加速等（下文展开）多引擎支持，用户端使用姿势不变，hint/option切换（下文展开）RDB一键入湖 问题：如何在(元)数据组织上，区分实时分区/增量快照分区/全量快照分区？最终方案：基于Timeline的分支管理 实现类Git的timeline管理branch/tag create/deletecheckout，cherry-pick等 轻量的timeline分支操作，实时/增量快照/全量快照便捷切换 每个分支都有各自的表服务 引申思考：timeline新增action+过滤无法满

4、足需求，因为它也有compaction等操作。这里面更多的是一种用户场景或视图的切换RDB一键入湖 问题：写入/读取的引擎适配 写入：需判断snapshot view生成时机分区提交时确认数据到位，触发快照生成基于watermark的分区推进机制（后续介绍）读取：支持FlinkBatch/Spark/Hive等查询引擎 降本每分区粒度只存增量，大幅降低存储成本 增效：时效性分钟级使用姿势简单，支持实时/增量/全量分区替代原拉链表使用范式 收益：流量日志分流 背景：千亿级流量，万级别行为事件分类，产出数据供全站各BU交叉使用 痛点：时效性不足小时级产出，下游有分钟级诉求 稳定性不足传输层-ODS

5、-DWD 1条流产出，含主站/直播/游戏等，业务隔离性差 以业务类型分区的分流方式不够灵活业务向的物理分区，到位通知复杂对1w+事件类型，只能按组分区，下游使用仍需过滤大量数据数据跨BU交叉订阅，权限管理混乱流量日志分流 方案：Hudi替换Hive+传输层：边缘分流+仓内分流：Hudi Clustering+Flink View支持 Hudi Append替换原Hive下游支持Hudi增量消费，分钟级时效 传输层分流平台边缘开始根据规则动态分流单流单job，增强隔离性和稳定性 仓内分流去除业务意义上的物理分区，下游通过视图View访问，业务字段为逻辑分区Hudi Clustering逻辑分区字

6、段，通过dataskip，减少数据摄取流量日志分流 方案查询性能对比读hudi表时间/s 192684100212788822984242752559589282074375171读hive表时间/s 222 13829355173125202165422824898913113272318853229性能提升/%1350-761-629-134942247-632787177-4125123456789101112131415161718-20002004006008001000120014001600Hive 与Hudi Clustering+View查询性能对比读hudi表时间/s读hi