当前的问题
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 另有整库同步等能力帮助你节省资源。