钟宇江-实时洞察湖仓之力-0702.pdf

《钟宇江-实时洞察湖仓之力-0702.pdf》由会员分享，可在线阅读，更多相关《钟宇江-实时洞察湖仓之力-0702.pdf（22页珍藏版）》请在三个皮匠报告上搜索。

1、DataFunConDataFunCon#20242024基于基于 Apache Paimon Apache Paimon 的的实时湖仓架构探索实时湖仓架构探索钟宇江 小米 背景 探索基于 Paimon 构建近实时的数据湖仓 未来展望Agenda背景背景现状 当前实时湖仓计算框架以当前实时湖仓计算框架以 Flink+Talos+Iceberg Flink+Talos+Iceberg 为主为主当前当前架构痛点：架构痛点：实时计算成本高实时计算成本高目前的目前的 Iceberg Iceberg 对流计算语义支持有限，数据实时化过程中使用的一些操作所消耗对流计算语义支持有限，数据实时化过程中使用的一

2、些操作所消耗的计算资源的计算资源非常大，比如非常大，比如 stream join stream join、deduplicatededuplicate 和流读和流读 changelog changelog 等等 架构复杂，作业稳定性差架构复杂，作业稳定性差比如在一些大数据量比如在一些大数据量 Join Join 场景下，需要使用大量场景下，需要使用大量 Timer Timer 来优化延迟关联的情况，来优化延迟关联的情况，且且 Flink state Flink state 非常大，还会需要引入非常大，还会需要引入 KV KV 系统来做补充，逻辑系统来做补充，逻辑复杂导致稳定性复杂导致稳定性差差

3、 存储成本高存储成本高实时链路的数据无法在离线链路复用，离线和实时是两套数据，同时还有实时链路的数据无法在离线链路复用，离线和实时是两套数据，同时还有 KV KV 系统系统中的数据冗余中的数据冗余现状 存在的问题存在的问题 Flink Flink 作业逻辑复杂，作业逻辑复杂，状态非常大，状态非常大，稳定性差稳定性差 HBase/Pegasus HBase/Pegasus 成本高，且成本高，且 Join Join 性能差性能差典型案例架构架构升级：升级：降低计算成本降低计算成本希望能将流计算和数据湖仓更好的结合，尽可能减少实时化带来的希望能将流计算和数据湖仓更好的结合，尽可能减少实时化带来的额外

4、资源额外资源消耗消耗 简化架构，提升简化架构，提升稳定性稳定性希望实时化链路尽可能的简单，减少用户开发负担，同时提升作业稳定性希望实时化链路尽可能的简单，减少用户开发负担，同时提升作业稳定性 统一统一数据链路数据链路尽量避免实时和离线两套链路导致的开发和运维成本，同时减少数据尽量避免实时和离线两套链路导致的开发和运维成本，同时减少数据冗余冗余对于实时数仓的期待 希望能够希望能够在界定在界定 correctness correctness 的前提下，平衡好的前提下，平衡好 freshness freshness 和和 cost cost 之间的关系之间的关系对于实时数仓的期待基于基于 Paimo

5、n Paimon 构建近实时的数据湖仓构建近实时的数据湖仓 Apache Paimon 是什么？创创新新地地将将 LSM LSM 结构融合到结构融合到 Lakehouse Lakehouse 架构，在架构，在有效应对有效应对流处理流处理语义语义挑战的同时挑战的同时，对批处理及，对批处理及 OLAP OLAP 也也有不错的支持有不错的支持 LakehouseLakehouse：Data lake,ACID,Schema evolution,Time travelData lake,ACID,Schema evolution,Time travel Stream:Stream:LSM,Change

6、log,Lookup joinLSM,Changelog,Lookup join Batch:Row-level update,Z-Order,Statistics metadataBatch:Row-level update,Z-Order,Statistics metadata探索场景 1：使用 Paimon 优化 Stream join根本根本原因：原因：Join Join 效率效率低低 高频次的磁盘随机读高频次的磁盘随机读 网络网络 IO IO 数据冗余数据冗余痛点：成本高痛点：成本高+架构复杂架构复杂探索场景 1：使用 Paimon 优化 Stream joinPartial-upd