Flink X Hologres 構建企業級 Streaming Warehouse

摘要：本文整理自阿里雲資深技術專家，阿里雲 Hologres 負責人姜偉華（果貝），在 FFA 實時湖倉專場的分享。本篇內容主要分為四個部分：
實時數倉分層的技術需求
阿里雲一站式實時數倉 Hologres 介紹
Flink x Hologres：天作之合
基於 Flink Catalog 的 Streaming Warehouse 實踐

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

一、實時數倉分層的技術需求

首先，我們講一講分層技術。大資料現在越來越講究實時化，在各種場景下都需要實時。因此大資料需要構建實時數倉，但如何構建實時數倉呢？

離線數倉的構建，有非常標準的方法論體系，首先透過分層 ODS->DWD->DWS->ADS，然後透過定時排程去實現分層和構造。相比離線數倉，實時數倉沒有明確的方法論體系。因此在實踐中，有各種各樣的方法，但沒有一個方法是萬能。最近行業內提出了 Streaming Warehouse。Streaming Warehouse 的本質是分層之間能夠做到實時資料的流動，從而解決實時數倉分層的問題。

下面，我們來了解下實時數倉的主流分層方案。

第一個方案，資料透過 Flink 清洗後，寫到 Kafka 形成 ODS 層。再從 Kafka 消費，經過加工形成 DWD 層。然後 Flink 加工成 DWS 層，最後透過加工形成 ADS 層的資料寫到 KV 引擎，供應用消費。

因為 Kafka 資料進行分析和探查很麻煩。所以，我們會同步一份 Kafka 資料到實時數倉，透過實時數倉進行分析和探查。

這個體系的優勢是層次明確，分工明確。但它的劣勢是需要有大量的同步任務；資料資源消耗很大；資料有很多冗餘；處理鏈路較複雜，需要好多元件。除此之外，在這個體系下構建的實時數倉分層，尤其是 Kafka 分層，它的複用性非常差。

第二個方案，這個方法不需要分層，整體架構只需要一層。我們把資料加工清洗後，寫到實時數倉裡，形成 DWD 層。所有的查詢都是查詢 DWD 層的明細資料。所以該方法也被稱之為 ELT，把明細資料寫進去（EL），變換（T）在查詢時進行。

這個方案的好處在於，沒有 ETL，只有一層；資料修訂很方便。但它的弊端有兩個方面：

在查詢效能方面，由於是明細資料查詢，所以在某些場景下不能滿足 QPS 或延遲的要求。
因為沒有分層，所以資料複用很困難，很難兼顧各方面的訴求。

第三個方案，既然實時流式無法完成資料的實時數倉分層，我們可以將資料實時寫入實時數倉的 DWD 層。DWS 層、ADS 層用離線的高頻排程方法，實現分鐘級的排程。從而借用離線數倉，進行分層構造。

這個方案的好處在於，它可以複用很多離線經驗，方案成本低且成熟。但這個方案存在如下缺點：

延遲大。每一層的延遲都跟排程相關，隨著層次越多，排程延遲越大。實時數倉也變成了準實時數倉。
不能完全複用離線方案。離線排程一般是小時級或天級，我們可以使用全量計算。但在分鐘級排程時，必須做增量計算，否則無法及時排程。

第四個方案，Flink 實時加工後，將資料寫到實時數倉形成 DWD 層。但 DWS 層或 ADS 層的構造，依賴於實時數倉的實時物化檢視的能力。現在實時數倉都開始提供物化檢視的能力，這種能力本質上是提供了一些簡單的聚合類物化檢視。

如果使用者的物化檢視需求較簡單，可以利用實時數倉裡的實時物化檢視能力，將 DWS 層到 ADS 層的構建自動化。從而讓物化檢視的查詢保證較高的 QPS。這個方案最大的缺點在於，實時物化檢視還不成熟，能力有限。

二、阿里雲一站式實時數倉 Hologres 介紹

接下來，介紹一下阿里雲一站式實時數倉 Hologres 產品。Hologres 是阿里雲自研的一站式實時數倉，它同時包含三種能力：

它支援傳統的實時數倉和 OLAP。
它支援 Serving(KV)場景，有非常高的 QPS 和很低的延遲。
它支援資料湖和阿里雲離線數倉 MaxCompute 加速的能力。

首先，在實時數倉方面。大家可以把 Hologres 當做一個常見的實時數倉。它的特點在於寫入側支援百萬 RPS 實時寫入，寫入即可查，沒有延遲。我們支援高效能的實時整行更新和區域性更新。其中。整行更新是把整行替換掉，區域性更新可以更新一行中的區域性欄位，二者都是實時更新。

在查詢側，一方面對於實時看板類的需求，支援高 QPS。比如幾百或上千 QPS 的簡單查詢。另一方面，我們也支援複雜計算。近期，Hologres 拿到了 TPC-H 30TB 的效能世界第一的 TPC 官方認證成績。

其次，在資料服務方面。Hologres 不但支援百萬 QPS KV 點查，而且支援阿里雲達摩院的 Proxima 向量檢索引擎，可以支援非常高的向量檢索能力。這些能力在 Hologres 中是全 SQL 表達，對使用者使用非常友好。

為了同時兼顧資料服務和實時數倉的需求，我們支援行列共存的資料格式。行列共存是指，一張表的資料既有一份行存，又有一份列存，並且系統保證這兩份資料是強一致的。對於 OLAP 分析，最佳化器會自動選擇列存。對於線上服務，它會自動選擇行存。

因為 Hologres 同時支援 OLAP 分析和線上服務，其中線上服務要求非常高的穩定性和 SLA。所以我們要保證 OLAP 分析和線上服務時，不會發生衝突。

因此，我們支援讀寫的分離、OLAP 分析和資料服務的強隔離。這裡的強隔離不同於普通實時數倉的弱隔離。弱隔離一般透過資源組的方式來實現，Hologres 直接做了強隔離，並沒有透過資源組。

最後，在湖倉資料互動式分析方面。對於阿里雲 MaxCompute 離線數倉裡的資料，資料湖的資料都可以做秒級的互動式分析。且不需要做任何的資料搬遷。這種表我們稱為“外表”。使用者可以將外表和內表進行關聯分析。

因為 Hologres 的定位是一站式的企業級實時數倉，所以除了上述能力，我們還有很多其他能力。包括資料的治理、成本治理、資料血緣、資料脫敏、資料加密、IP 白名單、資料的備份和恢復等等。

三、Flink x Hologres：天作之合

Flink 和 Hologres 有非常深度的整合關係。最初 Hologres 團隊和 Flink 團隊是同一個團隊，所以 Hologres 在設計之初，著重考慮如何支援 Flink。那麼 Hologres 和 Flink 有哪些深度整合的能力？

第一，Hologres 可以作為 Flink 的維表。因為 Hologres 有很強的點查能力，所以它可以作為 Flink 的維表使用。在實時計算的場景下，Flink 對維表的需求很強。我們支援百萬級至千萬級的 RPS 查詢，且維表可實時更新。因此，很多使用者會把 Hologres 用作 Flink 的實時維表（比方說實時特徵儲存）。

第二，Hologres 可以作為 Flink 的結果表。Hologres 有非常強的實時寫入和整行實時更新的能力，跟 Flink 非常匹配。因為 Flink 的輸出需要強大的 Update，結果表需要很強的覆蓋能力、以及實時更新能力。

與此同時，Hologres 還有很強的區域性更新能力。區域性更新能力在很多場景下，可以替代 Flink 的多流 Join，為客戶節省成本。

第三，Hologres 可以作為 Flink 的源表。Hologres 提供了 Binlog，一張表的任何變化，比如 insert、update、delete 等等，都會產生 Binlog 事件。Flink 可以訂閱 Binlog，進行驅動計算。由於 Flink 支援 Hologres 的整表讀取，二者結合構成了 Flink 全增量一體化的讀取能力。並且，我們對接 Flink CDC，它可以驅動 CDC 的計算。

第四，我們在 Flink 中實現了 Hologres 的 Catalog。使用者不需要在 Flink 裡建 Hologres 的外表。透過 Catalog 的任何操作，都會直接實時反映到 Hologres 裡。透過這種方法，Flink+Hologres 就具備了整庫同步、Schema Evolution 的能力。

由此可見，我們在維表、結果表、源表、Catalog 四個方面，對 Flink 和 Hologres 做了深度整合。

接下來，介紹一下 Flink 和 Hologres，如何構建 Streaming Warehouse？相比常見的 Flink+Kafka 的分層方案，Flink+Hologres 可以完全將其替換。

首先，將 Flink 寫到 Hologres 裡，形成 ODS 層。Flink 訂閱 ODS 層的 Binlog 進行加工，將 Flink 從 DWD 層再次寫入 Hologres 裡。

然後，再訂閱 DWD 層的 Binlog，透過計算形成 DWS 層，將其再次寫入 Hologres 裡。最後，由 Hologres 對外提供應用查詢。

該方案相比 Kafka 有如下優點：

第一，解決了傳統中間層 Kafka 資料不易查、不易更新、不易修正的問題。Hologres 的每一層都可查、可更新、可修正。
第二，Hologres 的每一層都可以單獨對外提供服務。因為每一層的資料都是可查的，所以資料的複用會更好，真正實現數倉分層複用的目標。
第三，Hologres 支援資料複用，模型統一，架構簡化。目前，該方案已經有很多客戶使用。透過 Flink+Hologres，實現實時數倉分層。

上面講的 Flink+Hologres 的 Streaming Warehouse 方案，其強依賴於以下三個 Hologres 核心能力：

第一個能力是 Binlog。因為實時數倉一般沒有 Binlog，但 Hologres 提供了 Binlog 能力，用來驅動 Flink 做實時計算，正因為有了 binlog，Hologres 才能作為流式計算的上游。

第二個能力是行列共存。一張表既有行存資料，又有列存資料。這兩份資料是強一致的。行列共存的特性讓中間層的每張表，不但能夠給 Flink 使用，而且可以給其他應用（比方說 OLAP、或者線上服務）使用。

第三個能力是資源強隔離。實時數倉一般是弱隔離或軟隔離，透過資源組、資源佇列的方法實現資源隔離。如果 Flink 的資源消耗很大，可能影響中間層的點查效能。但在強隔離的情況下，Flink 對 Binlog 的資料拉取，不會影響線上服務。

透過 Binlog、行列共存、資源強隔離的三個特點，不僅能讓 Flink+Hologres 形成 Streaming Warehouse，並且能夠使中間的每層資料複用，被其他應用或線上服務使用。

接下來，講一講基於 Flink+Hologres 的多流合併。因為 Hologres 有特別強大的區域性更新能力，所以我們可以簡化 Flink 的多流 Join。

比如在風控場景下，我們需要基於使用者 ID 構建使用者的多側面畫像。使用者畫像來自很多資料來源，比如客戶的瀏覽行為、成交行為、履約行為等等。把資料來源的資料按照使用者 ID，把每個使用者放到一行裡，形成不同的欄位，形成使用者的完整畫像。

傳統的方式需要用 Flink 多流 Join 實現，Flink 把上游的多個資料來源關聯到一起。Join 後寫到 Kafka 裡，然後驅動下游的 Flink，加工這行完整的資料。

多流 Join 非常耗資源。所以在 Flink+Hologres 場景下，Hologres 可以利用區域性更新能力，把一張表定為定義成 Hologres 的行存表或行列共存表。此時，整個方案就簡化成上游每個資料來源，同步資料到 Hologres 表的若干個欄位裡，若干個任務同時寫入這張表，然後利用 Hologres 的區域性更新能力，把資料彙總在一起。

如果開啟這張表的 Binlog，上游任何資料來源的變化都會更新這張表，使這張表的 Binlog 中生成行資料的最新狀態，然後驅動下游的 Flink 繼續計算，從而完美匹配常見的風控場景。這種用法下，資源消耗、運維都得到了極大的簡化。

四、基於 Flink Catalog 的 Streaming Warehouse 實踐

雖然上述方案已經非常成熟，但唯一的缺點在於，使用者需要在兩個系統之間切換，過程比較繁瑣。為了讓使用者操作更簡單，我們基於 Flink Catalog 提供了更加簡單的使用體驗。

下面我們來看看怎麼樣基於 Flink Catalog 去構建基於 Flink+Hologres 的 Streaming Warehouse。我們會發現，有了 Flink Catalog 後，整個使用體驗會很簡單，並能充分發揮 Flink 和 Hologres 兩個產品的強大能力。

上圖是一個典型的 Flink+Hologres 實時 ETL 鏈路；

ODS 層、DWD 層、ODS 層的資料都存在 Hologres 中。
鏈路中所有的資料加工都是透過 Flink SQL 完成。在整個 ETL 鏈路中，使用者不需要任何 Hologres SQL，直接寫 Flink SQL 即可。
Flink 使用者可以透過 Flink SQL 對每層中的 Hologres 資料進行資料探查（流模式和批模式都可以）。比方說，當我們發現 DWS 層的資料結果出現問題，需要檢視哪層的結果有問題或邏輯有錯誤。此時，我們可以複用原來的 Flink SQL 來進行探查、定位或者資料重新消費。
Hologres 中的每層資料都可以對外提供查詢和服務（透過 Hologres SQL）。

接下來，以某個電商場景為例，演示一下基於 Flink Catalog 的 Streaming Warehouse。如上圖所示，有一個 MySQL 資料庫作為訂單庫，裡面有訂單表 orders、訂單支付表 orders_pay、以及產品品類表 product_catalog。

第一步，我們透過 Flink 的實時數倉，把資料實時同步到 Hologres 裡，形成 ODS 層。
第二步，加工 DWD 層。將 DWD 層的資料寫到 Hologres 裡。在這個過程中，我們需要把訂單表和訂單支付表，合併成一張表，實現多路合併。與此同時，我們希望 orders 表關聯商品品類表 product_catalog。
第三步，驅動下游計算，構建 DWS 層。以使用者維度和商店維度，收集統計資料。比如使用者每天的訂單金額和商店每天的訂單金額，從而形成一條完整的鏈路。
第四步，將 DWS 層的表推薦給系統使用。作為使用者和商店的特徵，用做推薦用途。
第五步，DWD 層的表能夠直接用來做實時統計分析、統計產品、實時大屏、實時報表。

上圖中的綠色鏈路，全部使用 Flink SQL 完成。橙色鏈路對外提供服務，由 Hologres SQL 完成。

接下來，講一講每個步驟是如何執行的。

第一步，在 Flink 實時數倉，形成 ODS 層。首先，建立一個 Hologres 的 Catalog。MySQL 中儲存訂單、支付以及商品資訊 3 張表，透過 Flink Catalog 功能，將 MySQL 整庫的資料實時同步至 Hologres，形成 ODS。相關程式碼如上圖所示。我們可以看到，Mysql 整庫同步到 Hologres，透過 Flink SQL 來表達是非常簡單的。

第二步，DWD 實時構建。資料實時寫入 ODS 層後，Flink 讀取 Hologres Binlog，並用多流合併、維表關聯將訂單、交易、商品 3 個表打成一個大寬表，實時寫入至 Hologres 的訂單彙總表中，形成 DWD 層。

左圖中的 SQL 是 DWD 層表的建表語句。這張目標表包含了來自 orders、orders_pay、product_catalog 的欄位，關聯了相關的使用者資訊、商戶資訊、訂單資訊、商品品類資訊等等，形成了一張寬表。

右圖中的 SQL 是真正的計算邏輯。這裡包含兩個 INSERT 語句。

第一個 INSERT 語句是從 orders 表實時打寬後寫入。這裡用到了 Hologres 的維表關聯能力。實時打寬後，寫入目標表的部分欄位。
第二個 INSERT 語句是從 orders_pay 表實時同步到同一張目標表，更新另外一些欄位。

這兩個 INSERT 語句最大的關聯在於，它們寫的是同一張表，會自動利用目標表的主鍵 ID 進行關聯。每個 INSERT 都是做了目標表的區域性更新，兩者的合力結果是實時更新的目標寬表。

在上述過程中，它用了多種 Hologres 能力。比如驅動 Flink 做構建 DWD 層表；維表關聯能力；區域性更新能力等等。

第三步，DWS 層的實時聚合。在 DWD 的基礎上，透過 Flink 讀取 Hologres DWD 的 Binlog 資料，進行實時指標聚合計算，比如按照使用者維度聚合，按照商戶維度聚合等，然後實時寫入 Hologres，形成 DWS 層。

上圖中，左邊是 DDL 語句，右邊是聚合語句。經過簡單的三步後，Flink SQL 構建了完整的 Streaming Warehouse 分層體系。

第四步，構建應用。基於 DWS 層，對外提供服務。資料的分層和加工完成後，業務就可以透過 Hologres 查詢資料並應用。在這個例子裡，推薦系統要求非常高的點查效能，所以要求百萬級的 QPS 檢查能力。Hologres 的行存表或者行列共存表完全可以滿足。

這個方案和傳統的實時數倉最大的差別是：傳統的實時數倉只有最後一層的資料，可對外提供服務。而在 Hologres 裡，DWD 等中間層資料也可以對外提供服務，進行實時報表統計。使用者可以在中間層進行查詢操作，對接各種實時應用、實時大屏。比如直接查 DWD 層的資料，典型的如根據使用者 ID 返回推薦商品（KV 場景），以及實時報表檢視訂單量和退單量（OLAP）。

第五步，問題排查：Flink 資料探查。如果某個業務指標出現異常，Flink 可以直接探查每層表的資料來快速定位。比如用 Flink 探查 Hologres DWD 層的 orders 表。Hologres 支援 Flink 的流模式和批模式對資料的探查。

由於流模式是 Flink 的預設模式，因此我們不需要設定執行模式。它可以直接記錄資料變化，從而非常方便的檢視資料異常。流模式可以探查獲取一段時間範圍內的資料及其變化情況。

與此同時，批模式探查是獲取當前時刻的最新資料。Hologres 也支援 Flink 批模式的資料探查。批模式和流模式的區別在於，流模式關注的是變化，批模式關注的是表中的最新狀態。

綜上所述，當 Hologres 跟 Flink 深度整合，就可以構建強大的 Streaming Warehouse。全鏈路都可以用 SQL 表示，並且只需要用到 Flink 和 Hologres 兩個元件，操作非常方便。

實時 ETL 鏈路、資料分層完全可以用 Flink SQL 實現。對外查詢可以用強大的 Hologres 計算引擎來做，每層資料可複用、可查，方便構建實時數倉的資料分層和複用體系。

這種體系有著很好的效能。Hologres 有非常強的實時寫入、實時更新能力和強大的 OLAP、點查能力，Flink 有著非常強的實時加工能力。

使用者可以基於這個方案，利用 Hologres 強大的百萬 QPS 點查能力和高效能 OLAP 能力構建各種實時應用。

與此同時，我們有很多企業級能力，讓大家的運維更簡單，可觀測性更好，安全能力更強，從而更加方便的構建企業級的 Streaming Warehouse。