人工智能学习

聊聊流式数据湖Paimon(二)

本文主要是介绍聊聊流式数据湖Paimon(二),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

当前的问题

Apache Paimon 最典型的场景是解决了 CDC (Change Data Capture) 数据的入湖;CDC 数据来自数据库。一般来说,分析需求是不会直接查询数据库的。

  1. 容易对业务造成影响,一般分析需求会查询全表,这可能导致数据库负载过高,影响业务
  2. 分析性能不太好,业务数据库一般不是列存,查询部分列 Projection 性能太差
  3. 没有 Immutable 的视图,离线数仓里面需要根据 Immutable 的一个分区来计算

所以需要通过 CDC 的方式同步数据库的数据到数据仓库或数据湖里。

CDC可以理解为是Changelog数据流。

目前典型的同步方式依然是 Hive 的全量与增量的离线合并同步方式。
image.png
在 Hive 数仓里维护两张表:增量分区表和全量分区表,通过:

  1. (按需) 初始化时使用 DataX 或 Sqoop 等工具同步整张数据库表到 Hive 全量表的分区中。
  2. 每天定时 (比如凌晨0点30分) 同步增量数据 (通过 Kafka) 到 Hive 增量分区表,形成一个增量分区 T。
  3. 将 增量分区 T 与 全量分区 T-1 进行合并,产出今天的 全量表 分区 T。

这个流程在今天也是主流的同步方式,离线数据提供一个 Immutable 的视图,让数据的可靠性大大增加。
但是它的问题不少:

  1. 架构链路复杂度高:由于链路复杂,每天产出全量分区容易有问题导致不能按时产出,新增业务也比较复杂,全量和增量割裂。
  2. 时延高:至少 T + 1 延时,而且需要等全量和增量合并完成。
  3. 存储成本高:每天全量表一个分区存储所有数据,意味着 100 天就需要 100 倍的存储成本。
  4. 计算成本高:每天需要读取全量数据,与增量数据进行全量合并,在增量数据不多时浪费严重。

引入Paimon

和其它数据湖不同的是,Paimon 是从流世界里面诞生的数据湖,所以它在对接流写流读、对接 Flink 方面都要比其它数据湖做得更好。
Flink 结合 Paimon 打造的入湖架构如下:
image.png
步骤如下:

  1. 通过 Flink CDC 一键全增量一体入湖到 Paimon,此任务可以配置 Tag 的自动创建,然后通过 Paimon 的能力,将 Tag 映射为 Hive 的分区,完全兼容原有 Hive SQL 的用法。

只需一步。

Paimon 的每一次写都会生成一个 Immutable 的快照,快照可以被 Time Travel 的读取,但是快照会有过期被删除的问题,因此要解决此问题,可以基于快照创建 Tag;Tag 就是快照集合,通过Tag提供离线历史数据的访问。

流式入湖方式可以有如下多种方式:

  1. Flink SQL 入湖,SQL 处理,可以有函数等 Streaming SQL 的处理
  2. Paimon 一键 Schema Evolution 入湖,好处是 Schema 也会同步到下游 Paimon 表里:详见 https://paimon.apache.org/docs/master/cdc-ingestion/overview/

它的好处是:

  1. 架构链路复杂度低,不再因为各种组件的问题导致链路延时,你只用运维这一个流作业,而且可以完全兼容原有 Hive SQL 用法。
  2. 时延低:延时取决于流作业的 Checkpoint Interval,数据最低1分钟实时可见 (建议1-5分钟)。不但如此,Paimon 也提供了流读的能力,让你完成分钟级的 Streaming 计算,也可以写到下游别的存储。
  3. 存储成本低:得益于湖格式的 Snapshot 管理,加上 LSM 的文件复用,比如同样是存储 100天的快照,原有 Hive 数仓 100 天需要 100 份的存储,Paimon 在某些增量数据不多的场景只需要 2 份的存储,大幅节省存储资源。
  4. 计算成本低:得益于 LSM 的增量合并能力,此条链路只有增量数据的处理,没有全量的合并。可能有用户会担心,常驻的流作业会消耗更多的资源,对 Paimon 来说,你可以打开纯异步 Compaction 的机制,以 Paimon 优异的性能表现,只用少量的资源即可完成同步,Paimon 另有整库同步等能力帮助你节省资源。

参考

Flink + Paimon 数据 CDC 入湖最佳实践

这篇关于聊聊流式数据湖Paimon(二)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!