大資料架構系列：如何理解湖倉一體？

導語 |  本文推選自騰訊雲開發者社群-【技思廣益 · 騰訊技術人原創集】專欄。該專欄是騰訊雲開發者社群為騰訊技術人與廣泛開發者打造的分享交流視窗。欄目邀約騰訊技術人分享原創的技術積澱，與廣泛開發者互啟迪共成長。本文作者是騰訊後臺開發工程師葉強盛。

引 言

這十多 年大數 據技術蓬勃發展，從市場的表現來看基於大資料的資料儲存和計算是非常有價值的，其中以雲資料倉庫為主打業務的公司Snowflake市值最高（截止當前449億美元），另一家以湖倉一體為方向公司Databricks估值或達380億美元； 各大伺機而動的雲廠商也紛紛推出自己的資料湖、雲資料倉庫、湖倉一體產品。

大資料領域概念（術語）還是非常多的，大多數時候都是先射箭再畫靶，先有的需求大家搞了一段時間，然後由一些權威人士提出一些概念（術語）用於描述，所以不能嚴格用數學的定義方式去框定這些概念（術語）的邊界；且很多時候一個術語“形象”比“準確”更易傳播，形象意味著易懂，準確意味著資訊量巨大（參考數學定義）。建議可以從需求的角度去切入理解這些大資料概念和技術，不要過於追求準確的定義。

無論是資料湖還是資料倉庫最後還是面向於解決使用者的問題，使用者要的其實是資料裡的資訊，依賴於湖和倉的資料攝取、儲存、計算能力主要是因為海量多元的資料，如果使用者資料小業務簡單完全可以用本地Excel匯入資料進行各種有效分析。以下討論資料湖、資料倉庫、湖倉一體都是基於使用者的資料是海量且複雜多元的。

如上圖，在一個複雜場景裡，資料分析人員需要進行業務建模、資料建模；技術人員需要進行資料架構的設計、開發、維護；使用者可以使用業務模型、資料模型後產生業務價值；App根據演算法、模型、使用者畫像等提供功能和推薦。

What: 什麼是資料湖、資料倉庫？

說明 一下，當前主流的資料湖技術對二進位制資料（圖片、音訊等）不友好，文章上下文說的都是分析型（結構化、半結構化）資料。

只要業務場景複雜資料多元化，無論是你基於任何一個儲存框架也得儲存各種各樣的資料，然後你得有計算引擎可以計算這些資料；同時由於業務要求，你需要對資料進行實時分析。資料湖技術把上述的過程整合化、標準化了；在資料入湖一開始就對資料按照指定標準進行組織，支援流批 一體，不同框架有不同的組織方式（對特定場景有優化），但是目的都差不多；入湖後，提供標準化的資料讀取方式，支援各種MPP引擎的計算；因為資料提前組織過，所以寫入效能下降，查詢效能提升。所以你可能之前一直在用資料湖，只是沒用到資料湖技術。

資料倉庫在入庫之前，一般需要進行資料建模； 接著按照表的格式對資料進行標準化和表指定的儲存引擎進行資料組織，此時可能會損失掉一些資訊； 計算層通常都會對儲存引擎的資料結構進行優化，以此來獲得極致的查詢體驗。 日 常我們在進行大資料架構的設計實現時，一般會做的比資料倉庫限定的範圍多，但是我們還是稱為資料倉庫，所以還是再次提一下，不要太追求準確的定義。

（以上圖片來自阿里雲）

Why： 業 界為 什麼要做湖倉一體？

我來形象地描 述 一下： 集合兩者的優勢，像資料倉庫一樣管理的資料湖，像資料湖一樣開放的資料倉庫。

從W hat描述中資料湖和資料倉庫的描述可以看出，業內常用的大資料架構基本上就是湖倉一體，即拓寬的資料倉庫的功能，也會主動的規範資料的儲存和使用。 業內目前分享出來的資訊來看，主要還是為了替換掉老的Lambda和Kappa架構，想通過一個相對簡單的架構進行降本提效。

（以上圖片來自阿里雲）

How：業界怎麼做湖倉一體？

目前業內的湖倉一體的架構一般都叫基於某某資料倉庫的湖倉一體架構，使用者會把熱資料（頻繁查詢）放在資料倉庫中，無論在儲存和計算上都有大量的優化，計算速度快、成本高；冷資料放在資料湖中，計算慢、成本低，當用戶要查詢時，直接通過資料倉庫的計算層來遠端訪問資料湖格式的資料，許多架構中還會來臨時擴容彈性計算節點來計算冷資料，避免熱資料的高效查詢受影響。

湖倉一體冷熱儲存架構

如 上圖，近N天的熱資料在常駐MP P計算層進行查詢，資料變冷後轉成資料湖儲存格式入湖，後續由彈性MPP計算層對資料進行計算，一般冷資料次數頻率較低。

湖倉一體存算分離架構

如上圖，所有資料非同步入湖，資料倉庫的元資料會更新，使用者查詢時會快取需要掃描的原始資料，通過快取淘汰機制清理計算頻率較低的資料。

真實業務場景可能是同一套架構裡面會支援上述兩種實現。也有一些湖倉一體的架構中沒有資料倉庫產品，僅用了Presto作為查詢加速（火山引擎、Bilibili），不過整體架構大致也差不多。

以下列舉了業界實現的方案：

阿里雲 MaxCompute+Hologres

阿里雲 EMR+Sarrocks

華為雲 湖倉一體

位元組跳動 基於Doris的湖倉一體探索

位元組跳動-火山引擎 湖倉一體雲服務

bilibili 湖倉一體架構

Google BigLake

Amazon Lake House

Azure Lake House

SnowFlake Data Lake

總結

當前湖倉一體主要面向於解決使用者資料量特別大且多元化的場景，倉的作用在於提速，湖的作用在支援海量的資料併發寫入和海量儲存；且設計者希望儘量降低架構的複雜度，提高效率。

以下個人評估，僅供參考：

• SnowFlake在分析型資料場景下基本上就是天生的湖倉一體，優勢巨大。

• Doris/Starrocks的架構也會往Snowflake方向改進，潛力滿滿。

• 基於Spark/Presto的湖倉一體，查詢的效率會低於上述兩種，但是可以作為補足上述的部分場景。

參考資料：

1 . 多 角 度解析 ： 資料湖 VS 資料倉庫的根本區別

2. 深度對比Delta、Iceberg和Hudi三大開源資料湖方案

3.2萬字詳解資料湖：概念、特徵、架構與案例

4.詳解資料湖，概念、特徵、架構、方案、場景以及建湖全過程

5.4萬字全面掌握資料庫、資料倉庫、資料集市、資料湖、資料中臺

6.大資料發展20年，“倉湖一體”是終局？

7.B站基於Iceberg的湖倉一體架構實踐

8.亞馬遜湖倉一體

9.構建切實有效的湖倉一體架構

作者簡介

推薦閱讀

揭祕前端眼中的Rust！

如何基於標準化的OpenTelemetry構建APM探針能力

DevOps難以落地之謎，揭開DevOps的神祕面紗！

看完這篇，輕鬆get限流！

:point_down: 點 擊 「閱讀原文」 ， 註冊成為社 區創作者，認識大咖，打造你的技術影響力！