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

一.前言

Apache Paimon 最典型的场景是解决了 CDC （Change Data Capture）数据的入湖，看完这篇文章可以了解到：

1、为什么 CDC 入Hive迁移到 Paimon？

2、CDC 入 Paimon 怎么样做到成本最低？

3、Paimon 对比 Hudi有什么样的优势？

 Paimon 从 CDC 入湖场景出发，希望提供给你 简单、低成本、低延时 的一键入湖。本文基于 Paimon 0.6，0.6 正在发布中，可提前在此处下载：https://paimon.apache.org/docs/master/project/download/

二.CDC 入 Hive

CDC 数据来自数据库。一般来说，分析需求是不会直接查询数据库的。

1.容易对业务造成影响，一般分析需求会查询全表，这可能导致数据库负载过高，影响业务

2.分析性能不好，业务数据库一般不是列存，查询部分列Projection性能太差

3.没有Immutable的视图，离线数仓里面需要根据 Immutable的一个分区来计算

所以需要通过CDC 的方式同步数据库的数据到数据仓库或数据湖里。目前典型的同步方式依然是Hive的全量与增量的离线合并同步方式。

在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. 计算成本高：每天需要读取全量数据，与增量数据进行全量合并，在增量数据不多时浪费严重。

是时候该做一些改变了。

三.CDC 入Paimon

Apache Paimon（incubating）是一项流式数据湖存储技术，可以为用户提供高吞吐、低延迟数据摄入、流式订阅以及实时查询能力。Paimon采用开放的数据格式和技术理念，可以与 ApacheFlink/Spark/Trino 等诸多业界主流计算引擎进行对接，共同推进Streaming Lakehouse架构的普及和发展。

和其它数据湖不同的是，Paimon 是从流世界里面诞生的数据湖，所以它在对接流写流读、对接 Flink 方面都要比其它数据湖做得更好，详见后续的功能和性能对比。

Flink 结合 Paimon 打造的入湖架构如下：

步骤如下：

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

只需一步。

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

1. Flink SQL 入湖，SQL 处理