当前的问题
Apache Paimon 最典型的场景是解决了 CDC (Change Data Capture) 数据的入湖;CDC 数据来自数据库。一般来说,分析需求是不会直接查询数据库的。
- 容易对业务造成影响,一般分析需求会查询全表,这可能导致数据库负载过高,影响业务
- 分析性能不太好,业务数据库一般不是列存,查询部分列 Projection 性能太差
- 没有 Immutable 的视图,离线数仓里面需要根据 Immutable 的一个分区来计算
所以需要通过 CDC 的方式同步数据库的数据到数据仓库或数据湖里。
CDC可以理解为是Changelog数据流。
目前典型的同步方式依然是 Hive 的全量与增量的离线合并同步方式。
在 Hive 数仓里维护两张表:增量分区表和全量分区表,通过:
- (按需) 初始化时使用 DataX 或 Sqoop 等工具同步整张数据库表到 Hive 全量表的分区中。
- 每天定时 (比如凌晨0点30分) 同步增量数据 (通过 Kafka) 到 Hive 增量分区表,形成一个增量分区 T。
- 将 增量分区 T 与 全量分区 T-1 进行合并,产出今天的 全量表 分区 T。
这个流程在今天也是主流的同步方式,离线数据提供一个 Immutable 的视图,让数据的可靠性大大增加。
但是它的问题不少:
- 架构链路复杂度高:由于链路复杂,每天产出全量分区容易有问题导致不能按时产出,新增业务也比较复杂,全量和增量割裂。
- 时延高:至少 T + 1 延时,而且需要等全量和增量合并完成。
- 存储成本高:每天全量表一个分区存储所有数据,意味着 100 天就需要 100 倍的存储成本。
- 计算成本高:每天需要读取全量数据,与增量数据进行全量合并,在增量数据不多时浪费严重。
引入Paimon
和其它数据湖不同的是,Paimon 是从流世界里面诞生的数据湖,所以它在对接流写流读、对接 Flink 方面都要比其它数据湖做得更好。
Flink 结合 Paimon 打造的入湖架构如下:
步骤如下:
- 通过 Flink CDC 一键全增量一体入湖到 Paimon,此任务可以配置 Tag 的自动创建,然后通过 Paimon 的能力,将 Tag 映射为 Hive 的分区,完全兼容原有 Hive SQL 的用法。
只需一步。
Paimon 的每一次写都会生成一个 Immutable 的快照,快照可以被 Time Travel 的读取,但是快照会有过期被删除的问题,因此要解决此问题,可以基于快照创建 Tag;Tag 就是快照集合,通过Tag提供离线历史数据的访问。
流式入湖方式可以有如下多种方式:
- Flink SQL 入湖,SQL 处理,可以有函数等 Streaming SQL 的处理
- Paimon 一键 Schema Evolution 入湖,好处是 Schema 也会同步到下游 Paimon 表里:详见 https://paimon.apache.org/docs/master/cdc-ingestion/overview/
它的好处是:
- 架构链路复杂度低,不再因为各种组件的问题导致链路延时,你只用运维这一个流作业,而且可以完全兼容原有 Hive SQL 用法。
- 时延低:延时取决于流作业的 Checkpoint Interval,数据最低1分钟实时可见 (建议1-5分钟)。不但如此,Paimon 也提供了流读的能力,让你完成分钟级的 Streaming 计算,也可以写到下游别的存储。
- 存储成本低:得益于湖格式的 Snapshot 管理,加上 LSM 的文件复用,比如同样是存储 100天的快照,原有 Hive 数仓 100 天需要 100 份的存储,Paimon 在某些增量数据不多的场景只需要 2 份的存储,大幅节省存储资源。
- 计算成本低:得益于 LSM 的增量合并能力,此条链路只有增量数据的处理,没有全量的合并。可能有用户会担心,常驻的流作业会消耗更多的资源,对 Paimon 来说,你可以打开纯异步 Compaction 的机制,以 Paimon 优异的性能表现,只用少量的资源即可完成同步,Paimon 另有整库同步等能力帮助你节省资源。
参考
Flink + Paimon 数据 CDC 入湖最佳实践
文章版权声明:除非注明,否则均为
譬如朝露_策温技术开发工作室博客原创文章,转载或复制请以超链接形式并注明出处。
发表评论
侧栏公告
寄语
譬如朝露博客是一个分享前端知识的网站,联系方式11523518。
热评文章
标签列表
热门文章
友情链接