當前的問題 Apache Paimon 最典型的場景是解決了 CDC (Change Data Capture) 數據的入湖；CDC 數據來自資料庫。一般來說，分析需求是不會直接查詢資料庫的。 容易對業務造成影響，一般分析需求會查詢全表，這可能導致資料庫負載過高，影響業務 分析性能不太好，業務資料庫 ...
當前的問題
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 入湖最佳實踐
Apache Paimon 實時數據湖 Streaming Lakehouse 的存儲底座
