天天看點

「大資料」大資料架構:如何了解湖倉一體?

作者:架構思考

一、引言

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

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

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

「大資料」大資料架構:如何了解湖倉一體?

資料流程

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

二、What: 什麼是資料湖、資料倉庫?

說明一下,目前主流的資料湖技術對二進制資料(圖檔、音頻等)不友好,文章上下文說的都是分析型(結構化、半結構化)資料。

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

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

「大資料」大資料架構:如何了解湖倉一體?

湖倉對比

三、Why:業界為什麼要做湖倉一體?

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

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

「大資料」大資料架構:如何了解湖倉一體?

湖倉價值的交點

四、How:業界怎麼做湖倉一體?

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

「大資料」大資料架構:如何了解湖倉一體?

湖倉一體冷熱存儲架構

如上圖,近N天的熱資料在常駐MPP計算層進行查詢,資料變冷後轉成資料湖存儲格式入湖,後續由彈性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的湖倉一體,查詢的效率會低于上述兩種,但是可以作為補足上述的部分場景。

文章來源:葉強盛_騰訊天穹大資料_https://mp.weixin.qq.com/s?__biz=MzI2NDU4OTExOQ==&mid=2247544074&idx=1&sn=e1bbc81dfa782c0ec45b6b233f1a0a5c&chksm=eaa8375adddfbe4c653f4530bd90a2d79f6615b09e08d0b443b5aaa14a337db5ce5b0c2a2f6b&scene=178&cur_album_id=2650119358723145730#rd

繼續閱讀