阿里雲 Flink+Hologres:構建企業級一站式實時數倉

阿里雲大資料AI技術發表於2022-08-24

作者|徐榜江 余文兵 趙紅梅

隨著大資料的迅猛發展,企業越來越重視資料的價值,這就意味著需要資料儘快到達企業分析決策人員,以最大化發揮資料價值。企業最常見的做法就是透過構建實時數倉來滿足對資料的快速探索。在業務建設過程中,實時數倉需要支援資料實時寫入與更新、業務敏捷快速響應、資料自助分析、運維操作便捷、雲原生彈性擴縮容等一系列需求,而這就依賴一個強大的實時數倉解決方案。阿里雲實時計算 Flink 版(以下簡稱“阿里雲 Flink”)提供全增量一體化資料同步技術、強大的流式 ETL 等能力,支援海量資料實時入倉入湖。阿里雲 Hologres 作為新一代實時數倉引擎能同時解決 OLAP 多維分析、線上服務、離線資料加速等多個業務查詢場景,透過阿里雲 Flink 與 Hologres 的強強結合,實現全鏈路的資料探索實時化、資料分析敏捷化,快速助力業務構建企業級一站式實時數倉,實現更具時效更智慧的業務決策。

在本文中,我們將會介紹阿里雲 Flink、阿里雲 Hologres 在構建實時數倉上所具備的核心能力以及二者結合的最佳解決方案,使用者透過阿里雲 Flink+Hologres 實時數倉解決方案,可以顯著降低數倉建設門檻,讓資料發揮更大的價值,助力各行各業實現數字化升級。

Flink CDC 核心能力

Apache Flink 是開源的大資料流式計算引擎,支援處理資料庫、Binlog、線上日誌等多種實時資料,提供端到端亞秒級實時資料分析能力,並透過標準 SQL 降低實時業務開發門檻。伴隨著實時化浪潮的發展和深化,Flink 已逐步演進為流處理的領軍角色和事實標準,並蟬聯 Apache 社群最活躍專案。

Flink CDC 是阿里雲端計算平臺事業部 2020 年 7 月開源的一款資料整合框架,與 Flink 生態深度融合,具有全增量一體化、無鎖讀取、併發讀取、分散式架構等技術優勢,既可以替代傳統的 DataX 和 Canal 工具做資料同步,也支援資料庫資料實時入湖入倉,同時還具備強大的資料加工能力。

在構建實時數倉的過程中,資料採集是必需的元件。在傳統的 ETL 架構裡,採集層國外使用者通常選擇 Debezium,國內使用者則習慣用 DataX 和 Canal,採集工具負責採集資料庫的全量資料和增量資料。採集到的資料會輸出到訊息中介軟體如 Kafka,然後透過 Flink 計算引擎實時消費訊息中介軟體資料做計算層的資料清洗和資料加工,加工完成後再寫入目的端(裝載層),通常是各種資料庫、資料湖和資料倉儲。在傳統 ETL 鏈路中,資料採集工具與訊息佇列是比較重的元件,可能維護在不同的團隊,在上游的資料來源有業務變更或者這些元件需要升級維護時,整個鏈路的維護成本會非常大。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

透過使用 Flink CDC 去替換上圖中的資料採集元件與訊息佇列,將採集層(Extraction)和計算層(Transformation)合併,簡化了整個 ETL 分析鏈路,使用者可以使用更少的元件完成資料鏈路的搭建,整體架構帶來更低的運維開銷和更少的硬體成本、更好的資料鏈路穩定性、以及降低端到端的資料延遲。除了穩定性的提升,Flink CDC 的另一個優勢就是使用者只需要寫 SQL 指令碼就能完成 CDC 資料的清洗,加工和同步,極大地降低了使用者使用門檻。

除全增量一體化同步能力外,阿里雲 Flink CDC 還提供了表結構變更自動同步、整庫同步、分庫分表合併同步等諸多企業級特性,方便使用者快速打通資料孤島,實現業務價值。

1.1 全增量一體化同步

Flink CDC 透過增量快照讀取演算法在開源資料整合領域率先支援了無鎖讀取、並行讀取、斷點續傳、不丟不重四個重要特性。其中無鎖讀取徹底解決了資料同步對上游業務資料庫的死鎖風險,並行讀取很好地滿足了海量資料同步的需求,斷點續傳和不丟不重特性則是提升了同步鏈路的穩定性和可靠性。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

增量快照讀取演算法的核心思路就是在全量讀取階段把表分成一個個 chunk 進行併發讀取,在進入增量階段後只需要一個 task 進行單併發讀取 Binlog 日誌,在全量和增量自動切換時,透過無鎖演算法保障一致性。這種設計在提高讀取效率的同時,進一步節約了資源,實現了全增量一體化的資料同步。配合阿里雲實時計算產品提供的資源自動調優特性,Flink CDC 作業的資源可以做到自動擴縮容,無需手動介入。

1.2 表結構變更自動同步

隨著業務的迭代和發展,資料來源的表結構變更是經常會發生的操作。使用者需要及時地去修改資料同步作業以適配最新的表結構,這一方面帶來了較大的運維成本,也影響了同步管道的穩定性和資料的時效性。阿里雲 Flink 支援透過 Catalog 來實現後設資料的自動發現和管理,配合 CTAS (Create Table AS)語法,使用者可以透過一行 SQL 實現資料的同步和表結構變更自動同步。

Flink SQL> USE CATALOG holo;
Flink SQL> CREATE TABLE user AS TABLE mysql.`order_db`.`user`;

CTAS 語句會解析成一個 Flink 作業執行,這個 Flink 作業源頭支援讀取資料變更和表結構變更並同步到下游,資料和表結構變更都可以保證順序,上述 CTAS 語句執行時結構變更同步的效果如下圖所示。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

示例如果在上游 MySQL 的 user 表中新增一列 age,並插入一條 id 為 27,年齡為 30 的記錄。

MySQL> ALTER TABLE `user` ADD COLUMN `age` INT;
MySQL> INSERT INTO `user` (id, name, age) VALUES (27, 'Tony', 30);

user 表上的資料和結構變更都能實時地自動同步到下游 Hologres 的 user 表中,id 為 12,16 和 19 的歷史資料,新增的列會自動補 NULL 值。

1.3 整庫同步

在實時數倉構建中,使用者經常需要將整個資料庫同步到數倉中做進一步的分析,一張表一個同步作業的方式不但浪費資源,也會給上游資料庫產生較大的壓力。針對這類使用者痛點,阿里雲 Flink CDC 提供了整庫同步特性。整庫同步功能透過 CDAS (Create Database AS) 語法配合 Catalog 實現。

Flink SQL> USE CATALOG holo;
Flink SQL> CREATE DATABASE holo_order AS DATABASE
      mysql.`order_db` INCLUDING ALL TABLES;

例如 MySQL Catalog 和 Hologres Catalog 配合 CDAS 語法,可以完成 MySQL 到 Hologres 的全增量資料同步。CDAS 語句會解析成一個 Flink 作業執行,這個 Flink 作業自動解析源表的表結構及相應的引數,並將指定的一個或多個資料庫同步到下游 Hologres 數倉中,整個過程使用者無需手寫 DDL 語句,無需使用者在 Hologres 提前建立表,就能快速實現資料的整庫同步。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

CDAS 作業預設提供表結構變更同步能力,所有表的結構變更都會按照發生順序同步至下游 Hologres 實時數倉,CDAS 語法也支援過濾不需要同步的表。

1.4 分庫分表合併同步

分庫分表是高併發業務系統採用的經典資料庫設計,通常我們需要將分庫分表的業務資料匯聚到一張數倉中的大表,方便後續的資料分析,即分庫分表合併同步的場景。針對這種場景,阿里雲 Flink CDC 提供了分庫分表合併同步特性,透過在 CTAS 語法支援源庫和源表的正規表示式,源資料庫的分表可以高效地合併同步到下游 Hologres 數倉中。

Flink SQL> USE CATALOG holo;
Flink SQL> CREATE TABLE order AS TABLE mysql.`order_db.*`.`order_.*`;

述 CTAS 語句中的源庫名 order_db.* 是個正規表示式,可以匹配當前 MySQL 例項下的 order_db01,order_db02 和 order_db03 三個庫,源表名 order* 也是個正規表示式,可以匹配三個庫下所有以 order 打頭的表。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

針對分庫分表同步場景,使用者只需要提供分庫分表的正規表示式就可以將這多張分庫分表合併同步到下游 Hologres 數倉的 ordder 表中。與其他 CDAS 語句一樣,分庫分表同步場景預設提供表結構變更自動同步特性,下游 Hologres 表的 schema 為所有分表合併後的最寬 schema。分庫分表同步時每行記錄所屬的庫名和表名會作為額外的兩個欄位自動寫入到 user 表中,庫名(上圖中 db 列)、表名(上圖中 tbl 列)和原主鍵(上圖中 id 列) 會一起作為下游 Hologres user 表的聯合主鍵,保證 Hologres user 表上主鍵的唯一性。

Hologres 核心能力

阿里雲 Hologres 是自研的一站式實時資料倉儲引擎,支援海量資料實時寫入、實時更新、實時分析,支援標準 SQL(相容 PostgreSQL 協議),提供 PB 級資料多維分析(OLAP)與即席分析以及高併發低延遲的線上資料服務(Serving),與阿里雲 Flink、MaxCompute、DataWorks 等深度融合,為企業提供離線上一體化全棧數倉解決方案。

2.1 高效能實時寫入與更新

資料寫入的時效性是實時數倉的重要能力之一。對於 BI 類等延遲不敏感的業務查詢,如果寫入時延幾秒甚至幾分鐘可能是可以接受的。而對於很多生產系統,如實時風控、實時大屏等場景,要求資料寫入即可見。如果寫入出現延遲,就會查詢不到最新的資料,嚴重影響線上業務決策。在實時數倉整個資料處理鏈路中,Hologres 作為一站式實時資料倉儲引擎,提供海量資料高效能的實時寫入,資料寫入即可查詢,無延遲。

同時在數倉場景上,資料來源複雜,會涉及到非常多的資料更新、修正的場景,Hologres 可以透過主鍵(Primary Key, PK)提供高效能的 Upsert 能力,整個寫入和更新過程確保 Exactly Once,滿足對對資料的合併、更新等需求。

下圖為 Hologres 128C 例項下,10 個併發實時寫入 20 列的列存表的測試結果。其中豎軸表示每秒寫入記錄數,橫軸為 4 個寫入場景:

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

  • Append Only:寫入表無主鍵,寫入能力 230 萬+的 RPS。

  • INSERT:寫入表有主鍵,如果主鍵衝突就丟棄新行,寫入能力 200 萬 RPS。

  • UPDATE-1:寫入表有主鍵,表中原始資料量為 2 億,按照主鍵 Upsert,寫入能力 80 萬的 RPS。

  • UPDATE-2:寫入表有主鍵,表中資料量為 20 億,按照主鍵做 Upsert,寫入能力 70 萬的 RPS。

2.2 實時 OLAP 分析

Hologres 採用可擴充套件的 MPP 全平行計算,支援行存、列存、行列共存等多種儲存模式,同時支援多種索引型別。透過分散式處理 SQL 以及向量化的運算元,能夠將 CPU 資源發揮到極致,從而支援海量資料亞秒級分析,無需預計算,就能支援實時多維分析、即席分析等多種實時 OLAP 分析的場景,再直接無縫對接上層應用/服務,滿足所見即所得的分析體驗。

下圖為 Hologres 128C 例項下,TPCH 100G 標準資料集下的測試結果,橫軸表示 query,縱軸是響應時間:

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

2.3 高效能線上服務

隨著實時數倉的廣泛應用,越來越多的企業把實時數倉作為線上服務系統提供線上查詢。Hologres 作為 HSAP(Hybrid Serving and Analytics Processing, 服務與分析一體化)的最佳落地實踐,除了具備處理分析型 Query 的能力外,還具備十分強大的線上服務 Serving 能力(高 QPS 點查),例如 KV 點查與向量檢索。在 KV 點查場景中,Holgres 透過 SQL 介面可以支援 百萬級的 QPS 吞吐與極低的延時。透過 Hologres 能夠做到一套系統、一份資料支援同時 OLAP 分析和線上服務兩種場景,簡化資料架構。

下圖為 Hologres 128C 例項下,CPU 消耗 25%的點查測試效能:

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

2.4 讀寫分離高可用

實時資料倉儲 Hologres 提供高 QPS 低延遲的寫入能力,支援線上服務的查詢場景,還支援複雜的多維分析 OLAP 查詢。當不同型別,不同複雜的任務請求到 Hologres 例項上時,Hologres 不僅需要確保任務的正常執行,還要確保系統的穩定性。當前 Hologres 支援透過共享儲存的一主多從子例項的高可用架構,實現了完整的讀寫分離功能,保障 不同業務場景的 SLA。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

  1. 讀寫分離:實現了完整的讀寫分離功能,保障不同業務場景的 SLA,在高吞吐的資料寫入和複雜的 ETL 作業、OLAP 查詢、AdHoc 查詢、線上服務等場景中,系統負載物理上完全隔離,不會因寫入任務產生了查詢任務的抖動。

  2. 多型別負載資源隔離:一個主例項可以配置四個只讀例項,例項之間可以根據業務情況配置不同規格,系統負載物理上完全隔離,避免相互影響而帶來抖動。

  3. 例項間資料毫秒級非同步同步延遲:P99 5ms 內。

2.5 Binlog 訂閱

類似於傳統資料庫 MySQL 中的 Binlog 概念,Binlog 用來記錄資料庫中表資料的修改記錄,比如 Insert/Delete/Update 的操作。在 Hologres 中,表的 Binlog 是一種強 Schema 格式的資料,Binlog 記錄的序列號(BigInt),在單 shard 內單調遞增,類似於 Kafka 中的 Offset 概念。透過阿里雲 Flink 消費 Hologres Binlog,可以實現數倉分層間的全鏈路實時開發,在分層治理的前提下,縮短資料加工端到端延遲,同時提升實時數倉分層的開發效率。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

阿里雲 Flink x Hologres 一站式企業級實時數倉解決方案

3.1 實時數倉 ETL

ETL( Extract-Transform-Load)是比較傳統的資料倉儲建設方法,業務庫的資料 Binlog 經過阿里雲 Flink 的 ETL 處理之後,資料寫入到實時數倉 Hologres 中,然後進行各類資料查詢分析。ETL 的方法核心是需要在數倉中具備完善的數倉模型分層,通常按照 ODS(Operational Data Source)> DWD(Data Warehouse Detail)> DWS(Data Warehouse Summary)> ADS(Application Data Service)分層,整個數倉鏈路比較完善。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

在這個鏈路中,需要將資料來源比如 MySQL 的 Binlog 資料透過阿里雲 Flink CDC 同步到訊息佇列 Kafka,再透過阿里雲 Flink 將 ODS 的資料進行過濾,清洗,邏輯轉化等操作,形成對不同的業務主題模型的 DWD 資料明細層,同時將資料傳送到 Kafka 叢集,之後再透過阿里雲 Flink 將 DWD 的資料進行輕度的彙總操作,形成業務上更加方便查詢的 DWS 輕度彙總層資料,再將資料寫入 Kafka 叢集。最後再面向業務具體的應用層的需求,在 DWS 層基礎上透過阿里雲 Flink 實時處理形成 ADS 資料應用層,寫入實時數倉 Hologres 進行儲存和分析,支援業務各種不同型別的報表,畫像等業務場景。

實時數倉 ETL 的處理優點是數倉各種層次比較完備,職責清晰,但是缺點是 Flink 結合 Kafka 叢集維護複雜,處理鏈路比較長,歷史資料修正複雜,ADS 應用層的資料實時性會弱,其次資料在各個 Kafka 中不便於查詢,不便於檢查資料質量,也不便於實現 schema 的動態變化。

3.2 實時數倉 ELT

隨著業務對資料的時效性要求越來越高時,相較於 ETL 複雜繁雜的處理鏈路,業務需要更快速的將資料實時入倉,因此 ELT 變成了比較流行的處理方法。ELT 是英文 Extract-Load-Transform 的縮寫,我們可將 ELT 理解為一個資料遷移整合的過程。在這個過程中,我們可以對資料來源關係型資料庫比如 MySQL、PostgresSQL 和非關係型資料庫比如 HBase、Cassandra 等業務庫的 Binlog,訊息佇列比如 Datahub、Kafka 中的埋點採集日誌等資料,經過阿里雲 Flink 實時抽取,然後載入到 Hologres 中進行相關的 OLAP 分析和線上服務。

在這個鏈路中,阿里雲 Flink 負責資料的實時入倉以及資料的清洗關聯,清洗後的資料實時入 Hologres,由 Hologres 直接儲存明細資料。在 Hologres 中可以簡化分層,以明細層為主,按需搭配其他彙總層,透過 Hologres 強大的資料處理能力直接對接報表、應用等上層查詢服務。上層的分析 SQL 無法固化,通常在 ADS 層以邏輯檢視(View)封裝 SQL 邏輯,上層應用直接查詢封裝好的 View,實現即席查詢。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

實時數倉中採取 ELT 的方式進行建設,會給資料和業務帶來比較大的收益,詳細如下:

  • 靈活性:將原始的業務資料直接入倉,形成 ODS 層的資料,在數倉中透過 View 可以靈活地對資料進行轉換(Transformation)的處理,View 可以隨時根據業務進行調整。

  • 成本低:資料倉儲的架構比較清晰,鏈路比較短,運維成本比較低。

  • 指標修正簡單:上層都是 View 邏輯封裝,只需要更新底表的資料即可,無需逐層修正資料。

但是該方案也存在一些缺點,當 View 的邏輯較為複雜,資料量較多時,查詢效能較低。因此比較適合於資料來源於資料庫和埋點系統,對 QPS 要求不高,對靈活性要求比較高,且計算資源較為充足的場景。

3.3 實時數倉分層(Streaming Warehouse 方案)

按照傳統數倉的開發方法論,採用 ODS>DWD>DWS>ADS 開發的方法,透過阿里雲 Flink 和 Hologres Binlog 的組合關係,支援層與層之間有狀態的全鏈路事件實時驅動。在該方案中,資料透過阿里雲 Flink CDC 實時入倉至 Hologres,再透過阿里雲 Flink 訂閱 Hologres Binlog,實現資料在不同層次之間的連續加工,最後寫入 Hologres 對接應用查詢。

透過這個方案,Hologres 可以達到像 Kafka、Datahub 等訊息佇列同等的能力,增加資料複用的能力,一個 Table 的資料既可以提供給下游阿里雲 Flink 任務消費,還可以對接上游 OLAP/線上服務查詢,不僅節省了成本,還簡化數倉架構,同時也讓數倉中的每一個層次都可以實時構建、實時查詢,提升資料的流轉效率。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

3.4 流批一體數倉

在實時數倉中,流計算任務和批處理任務都是分兩條工作流進行開發的,也即是 Kappa 架構模式。在這套數倉架構中,會存在人力成本過高,資料鏈路冗餘,資料口徑不一致,開發效率低下的一些問題。為了解決這些問題,阿里雲 Flink+Hologres 提供了流批一體的能力。在該場景中,將輸入層統一變成 Hologres,透過一套業務邏輯程式碼達到流和批處理的能力,其中 Flink SQL 的 Stream 任務消費 Hologres Binlog 提供流式處理,Flink SQL 的 Batch 任務讀取 Hologres 表的原始資料達到批處理能力,經過 Flink 統一的計算處理之後,統一寫入儲存至 Hologres。

阿里雲 Flink 結合 Hologres 的流批一體技術,統一了資料輸入層、實時離線計算層和資料分析儲存層,極大的提升了資料開發的效率,保證了資料的質量。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

典型應用場景

阿里雲 Flink 與 Hologres 深度整合,助力企業快速構建一站式實時數倉:

  • 可透過阿里雲 Flink 實時寫入 Hologres,高效能寫入與更新,資料寫入即可見,無延遲,滿足實時數倉高效能低延遲寫入需求;

  • 可透過阿里雲 Flink 的全量讀取、Binlog 讀取、CDC 讀取、全增量一體化等多種方式,讀取 Hologres 源表資料,無需額外元件,統一計算和儲存,加速資料流轉效率;

  • 可透過阿里雲 Flink 讀取 Hologres 維表,助力高效能維表關聯、資料打寬等多種應用場景;

  • 阿里雲 Flink 與 Hologres 後設資料打通,透過 Hologres Catalog,實現後設資料自動發現,極大提升作業開發效率和正確性。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

透過阿里雲 Flink 與 Hologres 的實時數倉標準解決方案,能夠支撐多種實時數倉應用場景,如實時推薦、實時風控等,滿足企業的實時分析需求。下面我們將會介紹阿里雲 Flink + Hologres 的典型應用場景,助力業務更加高效的搭建實時數倉。

4.1 海量資料實時入倉

實時數倉搭建的第一步便是海量資料的實時入倉,基於阿里雲 Flink CDC 可以簡單高效地將海量資料同步到實時數倉中,並能將增量資料以及表結構變更實時同步到數倉中。而整個流程只需在阿里雲 Flink 上定義一條 CREATE DATABASE AS DATABASE 的 SQL 即可(詳細步驟可參考 實時入倉快速入門[4])。經測試,對於 MySQL 中的 TPC-DS 1T 資料集,使用阿里雲 Flink 64 併發,只需 5 小時便能完全同步到 Hologres,TPS 約 30 萬條/秒。在增量 Binlog 同步階段,使用阿里雲 Flink 單併發,同步效能達到 10 萬條/秒。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

4.2 雙流 Join

資料實時入倉形成了 ODS 層的資料後,通常需要將事實資料與維度資料利用 Flink 多流 Join 的能力實時地打平成寬表,結合 Hologres 寬表極佳的多維分析效能,助力上層業務查詢提速。阿里雲 Flink 支援以全增量一體化的模式讀取 Hologres 表,即先讀取全量資料再平滑切換到讀取 CDC 資料,整個過程保證資料的不重不丟。因此基於阿里雲 Flink 可以非常方便地實時加工和打寬 Hologres 的 ODS 層資料,完成 DWD 層的寬表模型構建。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

4.3 寬表 Merge

資料倉儲中我們通常需要關心的就是建模,資料模型通常分為四種:寬表模型、星型模型、雪花模型、星座模型(Hologres 均支援),在這裡我們重點要提到的是寬表模型的建設。寬表模型通常是指將業務主體相關的指標、維表、屬性關聯在一起的模型表,也可以泛指將多個事實表和多個維度表相關聯到一起形成的寬表。

寬表建設通常的做法就是透過阿里雲 Flink 的雙流 Join 來實現,包括 Regular Join,Interval Join,Temporal Join。對於主鍵關聯的場景(即 Join 條件分別是兩條流的主鍵),我們可以將 Join 的工作下沉到 Hologres 去做,透過 Hologres 的區域性更新功能來實現寬表 Merge,從而省去了 Flink Join 的狀態維護成本。比如廣告場景中,一個 Flink 任務處理廣告曝光資料流,統計每個產品的曝光量,以產品 ID 作為主鍵,更新到產品指標寬表中。同時,另一個 Flink 任務處理廣告點選資料流,統計每個產品的點選量,也以產品 ID 作為主鍵,更新到產品指標寬表中。整個過程不需要進行雙流 Join,最終 Hologres 會自己完成整行資料的組裝。基於得到的產品指標寬表,使用者可以方便地在 Hologres 進行廣告營銷的分析,例如計算產品的 CTR=點選數/曝光數。下圖和程式碼示例展示瞭如何從雙流 Join 改為寬表 Merge。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

CREATE TABLE ods_ad_click (
  product_id INT,
  click_id BIGINT,
  click_time TIMESTAMP
) WITH ('connector'='datahub', 'topic'='..');
CREATE TABLE ods_ad_impressions (
  product_id INT,
  imp_id BIGINT,
  imp_time TIMESTAMP
) WITH ('connector'='datahub', 'topic'='..');
CREATE TABLE dws_ad_product (
  product_id INT,
  click_cnt BIGINT,
  imp_cnt BIGINT,
  PRIMARY KEY (product_id) NOT ENFORCED
) WITH ('connector'='hologres','insertOrUpdate'='true');
INSERT INTO dws_ad_product (product_id, click_cnt)
SELECT product_id, COUNT(click_id) as click_cnt
FROM ods_ad_click 
GROUP BY product_id;
INSERT INTO dws_ad_product (product_id, imp_cnt)
SELECT product_id, COUNT(imp_id) AS imp_cnt 
FROM ods_ad_impressions
GROUP BY product_id;

使用 Hologres 寬表的 Merge 能力,不僅可以提升流作業的開發效率,還能減少流作業所需要的資源消耗,也能夠更容易的維護各個流作業,讓作業之間不會相互影響。但需要注意的是,寬表 Merge 僅限於使用在主鍵關聯的場景,並不適用於數倉中常見的星型模型和雪花模型,所以在大部分場景仍需使用 Flink 的雙流 Join 來完成寬表建模。

4.4 實時維表 Lookup

在實時數倉中,在構建 DWD 層的資料過程中,一般都是透過阿里雲 Flink 來讀取訊息佇列比如 Datahub 上的 ODS 資料,同時需要關聯維表來形成 DWD 層。在阿里雲 Flink 的計算過程中,需要高效的讀取維表的能力,Hologres 可以透過高 QPS 低延遲的點查能力來滿足實現這類場景需求。比如我們需要透過 ODS 的資料去 Join 維表形成 DWD 層的時候,就可以利用 Hologres 提供的點查能力,在該模式中,通常使用行存表的主鍵點查模式提高維表的 Lookup 效率。具體的實現類似如下:

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

典型使用者案例

依託阿里雲 Flink+Hologres 解決方案,企業可以快速構建一站式實時數倉,助力實時推薦、實時風控、實時大屏等多種業務場景,實現對資料的快速處理,極速探索查詢。目前該方案已在阿里巴巴內部、眾多雲上企業生產落地,成為實時數倉的最佳解決方案之一。

以某知名全球 TOP20 遊戲公司業務為例,其透過阿里雲 Flink+Hologres 實時數倉方案,替換開源 Flink+Presto+HBase+ClickHouse 架構,簡化資料處理鏈路、統一數倉架構、統一儲存、查詢效能提升 100%甚至更多,完美支撐資料分析、廣告投放、實時決策等多個場景,助力業務快速增長。

5.1 業務困難:ETL 鏈路複雜、OLAP 查詢慢

客戶原數倉架構使用全套開源元件,架構圖如下。其中開源 Flink 做 ETL 處理,處理後寫入 ClickHouse、Starocks 等 OLAP 引擎。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

這套架構遇見的主要痛點有:

1、ETL 鏈路複雜

  • 為了解決資料實時 ETL,客戶透過 Flink CDC + Hudi 做流批一體。但由於上游業務資料經常變更表結構,而開源 Flink CDC 缺乏 Schema Evolution 的能力,每次表結構變更都需要任務重新啟動,操作非常麻煩,浪費大量開發時間。

  • Hudi 的查詢效能不滿足業務需求,還需要再加一個 Presto 做加速查詢,造成鏈路冗餘。

2、OLAP 架構冗餘,查詢慢

客戶主要是靠買量發行作為遊戲推廣的重要手段,為了解決廣告歸因的實時決策場景對查詢加速的需要,於是部署了開源 Presto、ClickHouse、HBase 等多套叢集搭建混合 OLAP 平臺。帶來的問題有:

  • 平臺需要維護多套叢集,導致運維變得非常複雜。

  • 開發需要在各種 SQL 中切換,為開發團隊帶來了許多困擾。

  • 由於 ClickHouse 缺乏主鍵,在歸因分析時需要使用 Last Click 模型,帶來了大量的額外工作。

  • 同時 OLAP 引擎的查詢效能沒有辦法很好的滿足業務需求,沒辦法根據資料實時決策。

  • 資料需要在多個 OLAP 系統中儲存,造成儲存冗餘,導致成本壓力劇增。

基於上面的痛點,客戶開始重新做技術選型,並使用阿里雲 Flink+Hologres 來替換現有的開源數倉架構。

5.2 架構升級:阿里雲 Flink+Hologres 統一資料儲存與服務

透過阿里雲 Flink+Hologres 替換後的資料鏈路如下:

  • 資料來源資料透過 Flink CDC 能力寫入 Kafka 做前置清洗,清洗後透過阿里雲 Flink 進行 ETL 處理。

  • 阿里雲 Flink 經過 ETL 後的資料實時寫入 Hologres,透過 Hologres 替換了 Kafka 作為實時數倉的中間資料層,統一了流批儲存。

  • 在 Hologres 中根據 ODS > DWD > DWS 層彙總加工。在 ODS 層,阿里雲 Flink 訂閱 Hologres Binlog,計算後寫入 Hologres DWD 層,DWD 層在 Hologres 中彙總成 DWS 層,最後 DWS 對接上層報表和資料服務等業務。

  • 為了儲存的統一,也將原離線 Hive 資料替換成阿里雲 MaxCompute,以 MaxCompute 為離線主要鏈路。因 Hologres 與 MaxCompute 的高效互通能力,Hologres 透過外表離線加速查詢 MaxCompute,並將歷史資料定期歸檔至 MaxCompute。

阿里雲 Flink+Hologres:構建企業級一站式實時數倉

5.3 業務收益:架構統一,效能提升 100%

透過架構升級後,客戶的顯著業務收益如下:

  • 依託阿里雲 Flink+Hologres,資料可以實時寫入 Hologres,寫入即可見,並且 Hologres 有主鍵,能夠支撐高效能的寫入更新能力,百萬級更新毫秒級延遲。

  • 阿里雲 Flink 提供 Schema Evolution 的能力,自動感知上游表結構變更並同步 Hologres,改造後的實時 ETL 鏈路透過訂閱 Hologres Binlog 日誌來完成,降低鏈路維護成本。

  • 透過 Hologres 統一了資料查詢出口,經過客戶實測,Hologres 可以達到毫秒級延遲,相比開源 ClickHouse 效能提升 100%甚至更多,JOIN 查詢效能快 10 倍。

  • 升級後數倉架構變得更加靈活簡潔,統一了儲存,只需要一套系統就能滿足業務需求,降低運維壓力和運維成本。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70004426/viewspace-2911799/,如需轉載,請註明出處,否則將追究法律責任。

相關文章