汽車之家湖倉一體架構實踐

分享嘉賓：邸星星 @汽車之家

編輯整理：DataFun、Flink 中文社區

**導讀：**本文將介紹如何基於 Apache Iceberg 構建湖倉一體架構，將數據可見性提升至分鐘級；從多維分析的角度來探討引入 Apache Iceberg 帶來的收益，以及未來還有哪些收益可以期待。

01

數據倉庫架構升級的背景

1. 基於 Hive 的數據倉庫的痛點

原有的數據倉庫完全基於 Hive 建造而成，主要存在上述三大痛點。

2. Iceberg 關鍵特性

Iceberg 主要有四大關鍵特性：支持 ACID 語義、增量快照機制、開放的表格式和流批接口支持。

02

基於 Iceberg 的湖倉一體架構實踐

湖倉一體的意義就是說我不需要看見湖和倉，數據有着打通的元數據的格式，它可以自由的流動，也可以對接上層多樣化的計算生態。

——賈揚清

1. Append 流入湖的鏈路

上圖爲日誌類數據入湖的鏈路，日誌類數據包含客戶端日誌、用戶端日誌以及服務端日誌。這些日誌數據會實時錄入到 Kafka，然後通過 Flink 任務寫到 Iceberg 裏面，最終存儲到 HDFS。

2. Flink SQL 入湖鏈路打通

我們的 Flink SQL 入湖鏈路打通是基於 “Flink 1.11 + Iceberg 0.11” 完成的，對接 Iceberg Catalog 我們主要做了以下內容：

然後在這基礎上，平臺開放 Iceberg 表的管理功能，使得用戶可以自己在平臺上建 SQL 的表。

3. 入湖 - 支持代理用戶

第二步是內部的實踐，對接現有預算體系、權限體系。

因爲之前平臺做實時作業的時候，平臺都是默認爲 Flink 用戶去運行的，之前存儲不涉及 HDFS 存儲，因此可能沒有什麼問題，也就沒有思考預算劃分方面的問題。

但是現在寫 Iceberg 的話，可能就會涉及一些問題。比如數倉團隊有自己的集市，數據就應該寫到他們的目錄下面，預算也是劃到他們的預算下，同時權限和離線團隊賬號的體系打通。

如上所示，這塊主要是在平臺上做了代理用戶的功能，用戶可以去指定用哪個賬號去把這個數據寫到 Iceberg 裏面，實現過程主要有以下三個。

① 增加 Table 級別配置：'iceberg.user.proxy' = 'targetUser’

② 訪問 HDFS 時啓用代理用戶：

③ 訪問 Hive Metastore 時指定代理用戶

org.apache.spark.deploy.security.HiveDelegationTokenProvider

4. Flink SQL 入湖示例

DDL + DML

5. CDC 數據入湖鏈路

如上所示，我們有一個 AutoDTS 平臺，負責業務庫數據的實時接入。我們會把這些業務庫的數據接入到 Kafka 裏面，同時它還支持在平臺上配置分發任務，相當於把進 Kafka 的數據分發到不同的存儲引擎裏，在這個場景下是分發到 Iceberg 裏。

6. Flink SQL CDC 入湖鏈路打通

下面是我們基於 “Flink1.11 + Iceberg 0.11” 支持 CDC 入湖所做的改動：

改進 Iceberg Sink：

Flink 1.11 版本爲 AppendStreamTableSink，無法處理 CDC 流，修改並適配。

表管理

7. CDC 數據入湖

① 支持 Bucket

Upsert 場景下，需要確保同一條數據寫入到同一 Bucket 下，這又如何實現？

目前 Flink SQL 語法不支持聲明 bucket 分區，通過配置的方式聲明 Bucket：

'partition.bucket.source'='id', // 指定 bucket 字段

'partition.bucket.num'='10',   // 指定 bucket 數量

② Copy-on-write sink

做 Copy-on-Write 的原因是原本社區的 Merge-on-Read 不支持合併小文件，所以我們臨時去做了 Copy-on-write sink 的實現。目前業務一直在測試使用，效果良好。

上方爲 Copy-on-Write 的實現，其實跟原來的 Merge-on-Read 比較類似，也是有 StreamWriter 多並行度寫入和 FileCommitter 單並行度順序提交。

在 Copy-on-Write 裏面，需要根據表的數據量合理設置 Bucket 數，無需額外做小文件合併。

StreamWriter 在 snapshotState 階段多並行度寫入

FileCommitter 單並行度順序提交

8. 示例 - CDC 數據配置入湖

如上圖所示，在實際使用中，業務方可以在 DTS 平臺上創建或配置分發任務即可。

實例類型選擇 Iceberg 表，然後選擇目標庫，表明要把哪個表的數據同步到 Iceberg 裏，然後可以選原表和目標表的字段的映射關係是什麼樣的，配置之後就可以啓動分發任務。啓動之後，會在實時計算平臺 Flink 裏面提交一個實時任務，接着用 Copy-on-write sink 去實時地把數據寫到 Iceberg 表裏面。

9. 入湖其他實踐

10. 小文件合併及數據清理

11. 計算引擎 – Flink

Flink 是實時平臺的核心計算引擎，目前主要支持數據入湖場景，主要有以下幾個方面的特點。

數據準實時入湖：

Flink 和 Iceberg 在數據入湖方面集成度最高，Flink 社區主動擁抱數據湖技術。

平臺集成：

AutoStream 引入 IcebergCatalog，支持通過 SQL 建表、入湖 AutoDTS 支持將 MySQL、SQLServer、TiDB 表配置入湖。

流批一體：

在流批一體的理念下，Flink 的優勢會逐漸體現出來。

12. 計算引擎 – Hive

Hive 在 SQL 批處理層面 Iceberg 和 Spark 3 集成度更高，主要提供以下三個方面的功能。

定期小文件合併及 meta 信息查詢：

SELECT * FROM prod.db.table.history 還可查看 snapshots, files, manifests。

離線數據寫入：

分析查詢：

主要支持日常的準實時分析查詢場景。

13. 計算引擎 – Trino/Presto

AutoBI 已經和 Presto 集成，用於報表、分析型查詢場景。

Trino

Presto

社區集成中：https://github.com/prestodb/presto/pull/15836

14. 踩過的坑

03

收益與總結

1. 總結

通過對湖倉一體、流批融合的探索，我們分別做了總結。

湖倉一體

流批融合

準實時場景下實現流批統一：同源、同計算、同存儲。

2. 業務收益

3. 架構收益 - 準實時數倉

上方也提到了，我們支持準實時的入倉和分析，相當於是爲後續的準實時數倉建設提供了基礎的架構驗證。準實時數倉的優勢是一次開發、口徑統一、統一存儲，是真正的批流一體。劣勢是實時性較差，原來可能是秒級、毫秒級的延遲，現在是分鐘級的數據可見性。

但是在架構層面上，這個意義還是很大的，後續我們能看到一些希望，可以把整個原來 “T + 1” 的數倉，做成準實時的數倉，提升數倉整體的數據時效性，然後更好地支持上下游的業務。

04

後續規劃

今天的分享就到這裏，謝謝大家。

在文末分享、點贊、在看，給個 3 連擊唄~

分享嘉賓：

社羣推薦：

歡迎加入 **DataFunTalk 大數據 **交流羣，跟同行零距離交流。識別二維碼，添加小助手微信，入羣。

**關於我們：
**

**DataFunTalk **專注於大數據、人工智能技術應用的分享與交流。發起於 2017 年，在北京、上海、深圳、杭州等城市舉辦超過 100 + 線下和 100 + 線上沙龍、論壇及峯會，已邀請近 1000 位專家和學者參與分享。其公衆號 DataFunTalk 累計生產原創文章 400+，百萬 + 閱讀，10 萬 + 精準粉絲。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/RTluGmL582H-EWlX8M99ww

猜你喜歡