Flink Table Store 典型應用場景

摘要：本文整理自 Flink PMC 李勁松（之信）9 月 24 日在 Apache Flink Meetup 的分享。主要內容包括：
介紹 Flink Table Store
應用場景
Demo
後續挑戰

一、介紹 Flink Table Store

離線數倉和實時數倉是兩個典型的數倉形態。

離線數倉為批排程的方式，延遲較高，另外更新為全量合併，代價高。實時數倉為流的形式，資料能夠達到較低的延遲，但是中間資料不可查，也沒有歷史資料的沉澱。

因此，業界提出了 Streaming Warehouse。其特點為有儲存，有 Queue 的能力，能夠讓資料流動起來，也能夠沉澱歷史資料，可以供各種查詢引擎比如 Spark 、Flink 進行 ad-hoc 查詢。架構特點為全鏈路實時流動，沉澱數倉的中間資料，隨時可查，實時、離線分析一體化。

總結來說，動態表需要的能力有如下三個：

Table Format：能儲存全量資料，能夠提供很強的更新能力以處理資料庫 CDC 和流處理產生的大量更新資料，且能夠面向 Ad-Hoc 提供高效的批查詢。
Streaming Queue：流讀、流寫，能在儲存上建立增量處理 Pipeline。
Lookup Join：面向 Flink 維表 Join 提供 Lookup Join 的能力。

Flink Table Store 能夠很好地滿足以上三個需求。它是一個湖儲存，可以接收上游來自 MySQL Flink CDC、Logs 、Flink 產生的 Stateful Computation 等大量更新的資料，寫入湖儲存，湖儲存只是一個 lib/jar，置於 Flink 側能流寫流讀，置於 Spark 側可寫可查詢，本身是建立在 HDFS 或物件儲存之上。

下游可以被 Flink Streaming 查詢，建立 Streaming Pipeline ，也可以被各種引擎查詢，比如 Hive、Spark、Trino 等。

建立 Flink Table Store 的根本原因是為了彌補社群現有的缺失。我們期望 Flink Table Store 能夠達到 OLAP 引擎的快速更新和快速查詢能力，又有湖儲存的低成本特性。

上圖可見，Iceberg、Delta、Hudi 等都具有較低的儲存成本，更新時延從小時級到分鐘級不等，更新方案有 copy on write 、merge on read 。如果想要高效能查詢，需要對湖儲存進行手動排序。Clickhouse 是儲存成本較高的 OLAP 系統，能提供秒級更新時延，查詢效能非常快，基於 LSM 組織架構能達到非常好的更新效果和查詢加速。

Flink Table Store 可以認為是湖儲存版本的 Clickhouse MergeTree Engine，我們期望能夠藉此貼近 Streaming Warehouse 併發揮最大作用。

二、應用場景

Flink CDC 缺少一個能夠提供全增量一體匯入的儲存系統，而這可以透過 Flink Table Store 來實現。DDL 也很簡單，透過 Create Table 和 Insert Into 即可全增量一體地讀取 CDC 資料寫入 Flink Table Store 中。Flink Table Store 能夠提供高吞吐、全增量一體的更新，簡化了流程，提升鏈路的易用性。儲存也較為開放，能夠被多引擎實時 Ad-Hoc 查詢。LSM 按照 Key 來排序，如果查詢條件中有 Key 相關的過濾條件，即可達到高效能的主鍵查詢。

鏈路的第一步並不是要替換整個數倉，而是儘可能切入 ODS/DWD 層，實現更好的資料庫 CDC 入湖入倉體驗。

Flink Table Store 建好後即可直接對湖儲存進行流讀。如果能允許分鐘級的流式 Pipeline ，那麼 Flink Table Store 將是很好的選擇。

Flink Table Store 包含歷史資料的流讀，能儲存全量資料，因此每一次啟動流讀都是全量資料，能產出最正確的結果。建立流式 Pipeline 後，每一箇中間表都可查詢。

上圖中的配置 Changelog-Producer=Input，表明整個流 Pipeline 是靠源頭的 MySQL 資料給 CDC 產生的 Changelog 來產生正確的處理鏈路。

如果上游不是 CDC 或是包含隨機欄位或包含隨機維表，則鏈路很有可能產生資料不正確的問題，這時為了解決資料的正確性問題，Flink SQL會在 Source 後面產生 Changelog Normalizer 節點，物化所有資料，以此產生正確的 Changelog 資料，而這是一個非常高消耗的節點。另外，如果你的 FTS 表宣告瞭 Merge-Engine，比如是 Partial-Update，也需要儲存本身來產生 Changelog，因為在寫入時是拿不到完整的全行資料。

針對該缺點，FTS 0.3 版本將實現讓儲存本身能夠產生完整的 Changelog，避免 Normalization 導致的成本，使 Streaming 分析沒有後顧之憂。

在 Streaming Warehouse 中， Flink 應用對儲存的另一個需求是能夠做維表 Lookup Join，因此 Flink Table Store 0.3 版本提供了該能力。可以建立 Flink Table Store 表，達到維表 Join 的效果。

Flink Table Store 帶來價值在於能夠實時拉取 Flink Table Store的最新版本，支援維表主鍵的關聯，也支援維表非主鍵的關聯。維表 Join 會將 Flink Table Store 的資料透過 projection push down 、filter push down 後拉到本地，進行本地 cache ，無需擔心 OOM 。欄位較少時可以支援個數千萬欄位，整體建議千萬級以下規模，後續也將逐步加強，希望能夠達到 HBase 類似的儲存計算分離效果。

寬表合併本質上是寬表 Join ，可以用雙流 Join 的方式來解決。但有些場景的資料量比較大，雙流 Join 成本上難以滿足。儲存本身在特殊 Join 上、同 PK 打寬表的場景下，也可以透過儲存延遲 Merge 的方式實現寬表合併效果。

如上圖右側程式碼所示，只需指定 Merge-Engine=Partial-Update ，寫入時即可將兩張表進行 union all 並寫入同一張表，實現按主鍵打寬表。打寬表寫入後，可透過多引擎實時查詢，能查詢到最新 Snapshot 。

當前版本尚存在一些缺陷，因為 Flink Table Store 目前不支援多作業寫入，因此只能透過 union all 的方式， 0.3 版本中會提出多 Writer 併發寫入的能力。另外，寬表只能被 ad-hoc 查詢，無法被流讀，0.3 版本也會開發 Changelog 生成來實現流讀能力。

三、Demo

Demo 內容為：Docker 裡面有資料，透過 TPC-H Data Gem的方式全量匯入 MySQL 中，不斷地有執行緒產生增量資料。建立 Flink 叢集、Flink Table Store 表，透過 Flink CDC 匯入，建立Streaming Pipeline，最終產生聚合資料。

本 Demo 為全增量一體 CDC 實時入湖，單機輕鬆完成近百個分割槽 +6000 萬 CDC 資料。

Flink Table Store 作為湖儲存，支援大規模實時更新寫入是其核心特性之一。配合 Flink CDC 即可替代以前兩條割裂的全量鏈路加增量鏈路分別同步的情況，實現將資料庫中全量和增量資料一起同步入湖。

本 demo 的 Schema 包含主子訂單 ID 、商品 ID 、賣家 ID、價格、發貨、履約日期和物流等一系列資訊。

每條記錄大約為 128 bytes ，總共生成大約 5990 萬+條資料。同步寫入 Flink Table Store 明細表時，以發貨日期作為分割槽欄位，建立年+月二級分割槽。時間跨度為 7 年，因此一共動態寫入 84 個分割槽。

經測試，在單機併發為 2，Checkpoint Interval 為 1min 的配置下，46 min 內寫入 59.9 million 去哪量資料，平均寫入效能為 1.3 million/min。如果在生產環境下使用 20 個併發，可以在一小時內同步超過 6 億條資料，非常可觀。

將 Flink-Table-Store-101 克隆到本地，然後切換到 Real- Time-Update 目錄下，啟動容器。此處會先構建自定義 MySQL 映象，在 Container 啟動之後，自動生成 5900 萬+條資料，並透過 load data info 匯入到 MySQL lineitem 表。生成的資料總共切分為 16 個 chunk ，大約需要 1 分鐘左右可生成完畢。資料生成完畢後匯入 chunk，大約需要 15 分鐘。

啟動叢集，準備好依賴。開啟 Localhost 8081。

資料全部匯入完成後，開啟全量同步。

建立 Schema.sql 檔案，匯入所有建表語句。主要內容為：建立 Table Store Catalog ，指定 Warehouse 為 Time 檔案目錄下的 Table-Store-101，並將 Table Store 設定為 Current Catalog。建立 CDC 的 ODS Table ，需要注意是，在 Flink Table Store Catalog 下，其他表需要宣告成 Temporary Table 。

建立 DWD Table ，額外新增了兩個分割槽欄位，l_year 和 l_ month 。每個 Partition 下面設定兩個 Bucket ，使用 Input 作為 Changelog Producer ，使得上游 CDC 不丟棄 Update_Before，並且下游消費時候不會產生 Changelog-Normalize 節點。

接下來為聚合作業 Schema。

儲存並且將其作為啟動 SQL Client 的初始化檔案。

啟動 SQL Client，提交全量同步作業，使用內建函式 year（）和 month（）來生成兩個分割槽欄位。

作業提交後，上圖可見資料已經讀取進來。

切換到 Flink Table Store 目錄，檢視生成的 Snapshot Manifest 檔案和 SST 檔案。

顯示分割槽下的資料已經寫入。

檢視 Snapshot 顯示已經提交一次。

啟動 12 分鐘以後，可以看到全量資料已經同步完成。

提交聚合作業。聚合作業計算完成後，開始查詢。

切換到 Batch 模式，提交查詢作業。

查詢作業結束以後，為了展示方便，對其進行排序。

結果顯示為一條資料，資料已更新。

除了查詢聚合資料外，也可以查明細資料。比如發現 1998 年 12 月訂單資料有問題，需要排查明細進一步定位問題範圍。再查詢退貨情況以及聚合結果，可以看到資料在更新。

檢視明細層作業，可以看到增量資料已經開始匯入，到目前為止寫入 6000 萬條資料。

四、後續挑戰

Streaming Data Warehouse 面臨的挑戰主要有以下四個方面。

第一，儲存管控。我們希望透過 Flink CDC、Flink SQL 流批一體計算加上 Flink Table Store 儲存打造閉環，透過 Flink SQL 來管控運維、執行 Pipeline 的一整套系統，需要運維管控後設資料的工作，這也是 Flink 1.17 的重點推進方向。

第二，流計算準確性。想要完全分層次的 Streaming Pipeline ，本質上要求儲存能夠自己產生完整的 Changelog ，則流計算中的手動去重、莫名其妙的資料正確性等問題都能夠自然而然得到解決。

第三，Join 。Join 在邏輯上存在諸多問題，維表 Join 需要額外系統，但有時語義不滿足，因為維表更新並不觸發計算。而且維表 Join 具有一定的隨機性，會破壞完整的 Changelog 定義。另外，雙流 Join 需要儲存全量明細，代價太高。

第四，物化檢視一致性。構建 Streaming Data Warehouse 本質上是構建一系列物化檢視，而如果Streaming Data Warehouse 的每個 Table 都可查，一致性卻無法保障，最終呈現的也是不一致的檢視。

Flink Table Store後續規劃的三個目標如下：

第一，好用的流儲存。比如多作業寫同時寫入、Compaction 分離，比如完整的 Streaming Data Warehouse API 設計，包括完整的 DDL、Update、Delete 語法、Time Travel API 支援。以上能力將與 Flink 社群一起在 1.17 版本中重點攻克。

第二，準確的流儲存。儲存本身能夠產生完整的 Changelog ，下游的流計算易用性才能真正得到提高。

第三，可連線的流儲存。繼續增強 Lookup Join ，實現二級索引以更好地 Join，實現維表對齊能力，解決維表不確定性。

Q&A

Q：現在業務是用 Flink CDC 寫 Hudi 表，與 Hive 整合對映。如果換成 SQLGateway ，版本是否會有影響？

A：目前 SQLGateway 與 Flink 版本繫結在一起。比如升級到 Flink 1.16，則 Gateway 、Hudi、Hive 都要適配 Flink 1.16。後續我們會增強 Gateway 和 Flink 版本的解耦。

Q：Flink Table Store 與 Hudi、Lceberg 的差別在哪裡？

A：本質差別在於資料定位。 Flink Table Store使用 LSM 結構來更新和接受查詢，相當於在寫過程中不斷地 Spill、 Compaction，其優點在於編寫進來的資料已經排序好。並且透過 Append Spill 來更新，更新效能高。另外，LSM 結構可以在儲存上有更大的擴充套件性，比如類似 Clickhouse 那樣可以有各種場景的 MergeTree，加速查詢。

Q：Flink Table Store 的 Compaction 操作是在寫入時完成嗎？

A：是的，預設情況下建立作業後，透過 Streaming 寫入，在寫入作業 Writer 中，後臺執行緒會不斷地進行 Compaction 。當然，也可以選擇將 Compaction 分離為單獨的 Compaction 作業來完成。

Q：目前只能透過 Flink SQL 來查詢 Table Store 嗎？

A：不是。Flink Table Store 本質上是 Flink 在寫的時候，透過一定的組織方式將資料透過檔案方式放在 DFS 上，類似於 RocksDB 的分層分 level 的檔案組織方式。Flink Table Store 現在有 Spark、Trino、Hive 查詢，只要將 Flink Table 輸入 Jar 包，放置於 Hive Spark 的 Lib 下，即可直接查詢 Flink Table Store 表。

Q：查詢速度與 Clickhouse 接近嗎？

A：如果透過 PK 查詢，並且有 Filter 條件，則查詢速度非常快。這也是 Clickhouse 引入 LSM 做 Merge Engine 的原因。但是如果需要大量計算，那還是 Clickhouse 的查詢快很多。

■ Flink Table Store 目前已經發布 0.3.0：https://flink.apache.org/news...

最後，歡迎大家掃碼加入【Flink Table Stare 交流群】交流和反饋相關的問題和想法。

點選檢視直播回放 & 演講PPT

Flink Table Store 典型應用場景

一、介紹 Flink Table Store

二、應用場景

三、Demo

四、後續挑戰

更多內容

相關文章