如何快速構建企業級資料湖倉?
更多技術交流、求職機會,歡迎關注位元組跳動資料平臺微信公眾號,回覆【1】進入官方交流群
本文整理自火山引擎開發者社群技術大講堂第四期演講,主要介紹了資料湖倉開源趨勢、火山引擎 EMR 的架構及特點,以及如何基於火山引擎 EMR 構建企業級資料湖倉。
資料湖倉開源趨勢
趨勢一:資料架構向 LakeHouse 方向發展
LakeHouse 是什麼?簡言之,LakeHouse 是在 DataLake 基礎上融合了 Data Warehouse 特性的一種資料方案,它既保留了 DataLake 分析結構化、半結構化、非結構化資料,支援多種場景的能力,同時也引入了 Data Warehouse 支援事務和資料質量的特點。LakeHouse 定義了一種叫我們稱之為 Table Format 的儲存標準。Table format 有四個典型的特徵:
-
支援 ACID 和歷史快照,保證資料併發訪問安全,同時歷史快照功能方便流、AI 等場景需求。
-
滿足多引擎訪問:能夠對接 Spark 等 ETL 的場景,同時能夠支援 Presto 和 channel 等互動式的場景,還要支援流 Flink 的訪問能力。
-
開放儲存:資料不侷限於某種儲存底層,支援包括從本地、HDFS 到雲物件儲存等多種底層。
-
Table 格式:本質上是基於儲存的、 Table 的資料+元資料定義。
具體來說,這種資料格式有三個實現:Delta Lake、Iceberg 和 Hudi。三種格式的出發點略有不同,但是場景需求裡都包含了事務支援和流式支援。在具體實現中,三種格式也採用了相似做法,即在資料湖的儲存之上定義一個元資料,並跟資料一樣儲存在儲存介質上面。這三者相似的需求以及相似的架構,導致了他們在演化過程中變得越來越相似。
可以看到,三種資料格式都基本能覆蓋絕大部分特性。

下表給出了三種格式在生態方面的支援情況(截止 2022/8/18):

最後考慮的問題點:Table Format 是不是一個終極武器?我們認為答案是否定的。主要有幾方面的原因:
-
使用體驗離預期有差距:由於 Table Format 設計上的原因,流式寫入的效率不高,寫入越頻繁小檔案問題就越嚴重;
-
有一定維護成本:使用 Table Format 的使用者需要自己維護,會給使用者造成一定的負擔;
-
與現有生態之間存在 gap:開源社群暫不支援和 Table format 之間的表同步,自己做同步又會引入一致性的問題;
-
對業務吸引不夠:由於以上三點原因,Table Format 對業務的吸引力大打折扣。
如何去解這些問題呢?現在業界已經有基於 Table Format 應用的經驗、案例或者商業公司,比如 Data Bricks、基於 Iceberg 的 Tabluar 以及基於 Hudi 的 OneHouse 公司。
通過這些公司的商業產品,底層元件、運維和優化都交由商業產品解決,有效減輕負擔。而且商業公司還有能力提供上層的 ETL 管道等產品,使得使用者可以更容易從原有架構遷移。因此,LakeHouse 並不等於 Table Format,而是等於 Table Format 加上一些上層建築。這些上層建築由商業公司提供,但除此之外也期望能來來自社群。
趨勢二:計算向精細化記憶體管理和高效執行方向發展
資料湖的本質是起 task ,然後做計算。當引擎逐漸完善之後,對於效能需求逐步上升,不可避免地要朝精細化的記憶體管理以及高效執行方向發展。目前,社群出現了兩個趨勢:Native 化和向量化(Vectorized)。
第一,Native 化。
Native 化有兩個典型的代表。
-
Spark:去年官宣的 Photon 專案,宣稱在 tpcs 測試集上達到 2X 加速效果。
-
Presto: Velox native 引擎。Velox 引擎現在不太成熟,但是根據 Presto 社群官方說法,可以實現原來 1/3 的成本。由此可猜測,等價情況下能獲得 3X 效能提升。
除了以上兩者,近幾年熱門的 ClickHouse 和 Doris 也是 Native 化的表現。
第二,向量化。
Codegen 和向量化都是從資料倉庫,而不是 Hadoop 體系的產品中衍生出來。
Codegen 是 Hyper 提出的技術,而向量化則是 MonetDB 提出的,所以計算引擎的精細化也是沿著數倉開闢的路子在走。Spark 等 Hadoop 體系均走了 Codegen 的道路,因為 Java 做 Codegen 比做向量化要更容易一些。
但現在,向量化是一個更好的選擇,因為向量化可以一次處理一批資料,而不只是一條資料。其好處是可以充分利用 CPU 的特性,如 SIMD,Pipeline 執行等。
趨勢三:多模計算,即元件邊界逐漸模糊,向全領域能力擴充套件
Spark ,最早為批處理引擎,後補了 Streaming 和 AI 的能力;Trino 為 OLAP 引擎,現在也在大力發展批式計算;Flink 為流引擎,後補了批式計算和 AI 能力;Doris 則在加強 multi-catalog……
各家引擎都在拓展使用者場景。這種多模計算產生的結果是,對於各個領域內差別不大的場景,技術會逐漸收斂到一個最優解,最終只有一兩個引擎獲得成功。差別比較大的場景,則在每個場景形成一兩個寡頭,寡頭跨場景的能力則競爭力很弱。
趨勢四:分析實時化
大資料最早是批式計算的形式,但理想狀態是純流式方式。分析實時化的表現有(近)實時引擎和流引擎。
-
(近)實時引擎
ClickHouse:近實時 OLAP 引擎,寬表查詢效能優異
Doris:近實時全場景 OLAP 引擎
Druid:犧牲明細查詢,將 OLAP 實時化,毫秒級返回
-
流引擎
Flink:流計算逐步擴大市場份額
Kafka SQL:基於 Kafka 實現實時化分析
Streaming Database:Materialize 和 RisingWave 在開發的一種產品形態,效果類似於 Data Bricks 的 Data Live Table
企業構建資料湖倉的挑戰
企業在構建資料湖倉時面臨的挑戰分為以下 5 個方面:
-
整體資料鏈路複雜:即使是開發一個小的 APP,要搭建整個資料鏈路也很複雜,比如資料迴流需要寫資料庫;日誌要回流,要基於迴流資料做指標計算,迴流資料還需要轉儲以及 CDC;基於轉儲資料還要做 ETL 分析。
-
湖倉需求多樣:如果存在機器學習需求,即要完成特徵工程等一系列步驟,這些步驟也催生了資料湖倉的多種需求,包括支援批式、流失計算和互動式資料科學等各種場景。
-
湖倉資料來源廣泛:包括業務交易資料、業務資產資料、使用者行為資料、上下游產生的中間資料等。
-
資料開發中參與角色眾多:包括管理者、一線業務人員、業務開發、基礎設施參與人員等等。
-
企業往往需要根據平臺進行二次開發:基礎設施無法直接對接業務,根據業務特點靈活定製平臺,解決方案平臺化、產品化等。
由此衍生出一系列問題,包括穩定性、擴充套件性、功能、效能、成本、運維、安全、生態這 8 個方面。企業如果要單方面解決這些問題,哪怕是其中一個,可能也要花費巨大的人力物力。
火山引擎 EMR 即是這樣一個平臺。下一部分將主要介紹,火山引擎 EMR 如何幫助使用者解決這些挑戰以及如何基於 EMR 構建企業級資料湖倉。
基於火山引擎 EMR 構建企業級資料湖倉
火山引擎 EMR
一句話總結,火山引擎 EMR 是開源大資料平臺 E-MapReduce,提供企業級的 Hadoop、Spark、Flink、Hive、Presto、Kafka、ClickHouse、Hudi、Iceberg 等大資料生態元件,100% 開源相容,支援構建實時資料湖、資料倉庫、湖倉一體等資料平臺架構,能幫助使用者輕鬆完成企業大資料平臺的建設,降低運維門檻,快速形成大資料分析能力。火山引擎 EMR 有以下 4 個特點:
-
開源相容 &開放環境:100% 相容社群主流版本,滿足應用開發需求;同時提供半托管的白盒環境,支援引導操作與叢集指令碼能力。
-
引擎企業級優化:引入了 Spark、Flink 等核心引擎的企業級特性優化及安全管理。
-
Stateless 雲原生湖倉:把狀態外接做成存算分離的架構。
-
雲上便捷運維:提供一站式雲託管運維的能力與元件,讓使用者能夠分鐘級地建立和銷燬叢集,同時提供精細化的叢集運維監控告警能力。
Stateless、瞬態叢集

Stateless 是指把所有有狀態的資料外接,讓使用者的計算叢集變成無狀態的叢集。這些有狀態的元件包括:History Server、表的元資料、平臺的元資料、審計日誌、中間資料等。完全外接的 Stateless 叢集可以達成極致的彈性伸縮狀態。狀態外接有兩個重要的元件,Hive Metastore 和 各個 Public History Server。
Hive Metastore Service: 中心化元資料託管服務

Hive Metastore 定位為公共服務,使用者可以選擇獨佔或共享 Metastore 例項。如果使用者期望節省成本,或者為公司使用者,那麼兩個部門之間可以使用一個 Hive Metastore service;而對於一些要求比較高的部門,可以單獨建一個 Metastore Service 的例項。
持久化的 History Server 服務

YARN、Spark、Flink、Presto 等幾種 History Server 都從引擎中被剝離出來,形成 Public History Server 服務。該服務有幾個特點:
-
獨立於叢集之外執行的常駐服務;
-
提供持久化的 History 資料儲存。當該叢集銷燬之後,歷史資料還可儲存 60 天;
-
提供原生 History Server UI,使用者不會感覺生疏;
-
租戶間 History 資料隔離;
-
更友好的使用體驗:相對於元件內建 History Server, 獨立服務需要繫結公網並開放 8443 端口才能訪問,Public History Server 真正做到了開箱即用,無需其它額外配置。同時整合 IAM SSO 准入認證,通常情況下使用者從 EMR 管控端跳轉到 Public History Server 可以實現無感 SSO 認證登入,無需再次輸入使用者登入憑證。
存算分離,彈性伸縮

火山引擎 EMR 具備 CloudFS 和 TOS 兩個資料儲存層,冷資料可以儲存在物件儲存 TOS 上。CloudFS 則構建在 TOS 層之上,提供相容 HDFS 語義儲存,提供快取加速功能,可以把溫資料放在 CloudFS 。在引擎內部內建一些本地快取,用於快取熱資料。分層快取能夠彌補企業上雲之後,資料因儲存在物件儲存所造成的效能損失。另外 Cloud FS 提供 HDFS 的語義,可便於開源元件切入。
雲託管,易運維
在管控層面,火山引擎 EMR 提供了很多工具,便於管理員管理整個叢集,包括叢集管理、服務管理、節點管理、日誌中心、配置中心、使用者許可權、彈性伸縮等,使用者可以到火山引擎上建一個最小規格叢集體驗。
使用者友好
在使用者側,火山引擎 EMR 提供了作業管理介面,提供全域性視角檢視叢集資源消耗、異常情況等。同時該介面提供一鍵檢視作業詳情,作業診斷等功能,包括不限於異常探測、執行資源消耗、優化建議等。未來,期望能夠基於作業提供優化建議,比如引數調整等。
構建企業級資料湖倉的最佳實踐
接下來我們通過幾個案例來看看基於火山引擎 EMR 構建的企業級資料湖倉最佳實踐。
案例 1:多元化分析平臺
多元化分析指兼具離線分析場景與互動式分析的場景,以及高效能場景,以便支援應用層直接使用資料集市中的資料。以某網際網路企業平臺部門距離,使用者期望基於業務資料構建分析平臺,支援多種分析負載,包括視覺化大屏、報表系統、自助分析以及開發分析應用等。
要搭建這種多元化分析平臺,使用者可以通過 DataLeap 進行資料開發,讓資料通過離線方式或實時同步的方式流入資料庫倉。然後,基於 Spark/Hive/Presto/Trino 進行批式資料分析和互動式分析。對於流式處理,可以把資料轉儲到 Cloud FS 和 TOS,基於流式做出一個計算結果,上傳到 Clickhouse 和 Doris 來滿足一些高效能分析的場景。

案例 2:高效能實時數倉
某頭部直播業務的實時數倉 達到 100+W/s 資料入倉速度,且支援橫向擴充套件。通過流式計算引擎計算後,明細資料進入 Doris 叢集 ODS 層,資料聚合計算後進入 DWS 層,資料指標經計算後存入 ADS 層,且資料支撐線上更新。由 Doris 對資料應用層提供服務,支援線上、離線查詢分析,支援幾十萬級 QPS。
該業務資料量比較大,同時對資料分析的時間性要求高,希望業務人員能通過實時檢視業務指標的變化快速做出反應,達到精準營銷的效果。
該方案是通過 Flink 把資料直接流入 Doris,即原始資料直接到 Doris 的 ODS 層。由於 Doris 本身效能可以提供時延很短的查詢體驗,因此基於 Doris 完成 ODS > DWD > DWS > ADS 的轉化。

案例 3:實時計算
對效能要求高的場景,目前推薦使用實時計算方式,讓資料省略中間各層。在 Flink 裡完成計算,結果直接寫入 RDS/ Redis。以某車聯網公司為例,實時採集運營的 500 輛新能源汽車行駛和電池資料進行實時分析和告警,每 5 分鐘採集一次,日增量在 10GB,資料通過訊息佇列 Kafka 或 Pulsar 匯聚到大資料平臺,使用 Flink 流計算引擎進行毫秒級實時指標計算,計算結果儲存到 RDS 中供平臺進行實時資料展示。

案例 4:線上機器學習
在線上機器學習場景下,資料通過離線的方式存到資料湖倉。離線資料可以通過 Spark 進行特徵抽取及特徵工程,並把提取出來的特徵返存到湖倉或者 HBase 等鍵值儲存。
基於離線的資料可以進行離線訓練,如通過 Spark MLlib 搭建傳統的機型學習模型,或者通過 TensorFlow 進行深度模型的訓練,把深度訓練出來的模型部署到模型服務中。在線上方面,資料通過 Kafka 流入 Flink 進行線上特徵抽取,然後把線上特徵放在 Redis。同時線上部分的增量資料可用 TensorFlow 進行增量訓練,把增量模型也匯入模型服務裡。模型服務根據原來批式訓練出來的模型和增量模型做成實時的 AI 服務,可滿足實時風控等對時間要求比較高的場景。

火山引擎 EMR 湖倉方向未來規劃
最後與大家分享火山引擎 EMR 在湖倉方向未來的規劃。
-
資料加速:期望進一步加速資料分析。企業上雲之後,痛點之一為資料放到物件儲存之後效能是否會下降。要解決該問題,主要在資料快取(包括檔案級 Cache 和 Page 級 Cache)和索引方面(包括 Bitmap、Bloom Filter)做一些工作。
-
解決剛需痛點場景:分析 CDC 資料和多路徑,解決資料湖倉割裂的問題。對於後者,可以嘗試:
Doris 直接加速訪問 HMS 中的 Hive/Iceberg/Hudi 表,實現湖倉互通。
持續優化基於 Iceberg 資料湖方案,使得效能接近倉的體驗。
-
擁抱開源:希望將工作合入到開源社群,包括 Data Block Alluxio 的功能和效能優化;Doris MultiCatalog、元資料服務化、冷熱分離優化;Iceberg 二級索引等。
-
AI4Data(資料智慧管家):我們長期規劃是成為一個智慧資料管家,具體包括:
自動診斷高頻低價效比 SQL 及作業;
自動優化使用者 SQL 及作業,智慧地從資料分佈、Cache、Index、物化檢視等維度來優化使用者賬單;
智慧運維:
叢集負載過高時,自動擴容;負載降低時,自動收縮。
叢集節點故障時,做到使用者完全無感知地 Failover。
自動地實現資料均衡分佈。
-
產品打磨:在產品側,第一目標是打磨產品,先把產品底座做堅實,並在管控方面(包括建立叢集體驗優化、彈性伸縮優化等)、作業開發與管理方面與周邊生態方面做進一步打磨。
活動推薦
12 月 20 日 19:00,《火山引擎 VeDI 資料中臺架構剖析與方案分享》
本期直播分享將聚焦位元組跳動資料中臺建設經驗,在存算分離、湖倉一體、ServerLess 等技術發展趨勢下,從企業數倉架構選擇、資料湖解決方案與應用實踐,以及一站式資料治理等角度,為企業構建自身資料中臺提供思路和啟發。
戳連結,立即進群、觀看直播、贏取好禮:11dr.cn/d/5xvloe9D7

點選跳轉火山引擎 E-MapReduce官網瞭解更多
- 從銀行數字化轉型來聊一聊,火山引擎 VeDI 旗下 ByteHouse 的應用場景
- ByteHouse 實時匯入技術演進
- 關於 DataLeap 中的 Notebook,你想知道的都在這
- 火山引擎DataLeap:3個關鍵步驟,複製位元組跳動一站式資料治理經驗
- 如何又快又好實現 Catalog 系統搜尋能力?火山引擎 DataLeap 這樣做
- 什麼是A/B實驗,為什麼要開A/B實驗?
- 計算效能提升百倍 火山引擎數智平臺這款產品助力企業員工更好看數用數
- 火山引擎DataLeap資料排程例項的 DAG 優化方案
- 如何快速構建企業級資料湖倉?
- 位元組跳動基於Doris的湖倉分析探索實踐
- 火山引擎在行為分析場景下的ClickHouse JOIN優化
- 位元組跳動資料血緣圖譜升級方案設計與實現
- 提速 10 倍!深度解讀位元組跳動新型雲原生 Spark History Server
- 位元組跳動基於 ClickHouse 優化實踐之“查詢優化器”
- 位元組跳動基於ClickHouse優化實踐之“多表關聯查詢”
- “今日頭條”名字是 AB 測試定的?位元組跳動用九年時間打造出了怎樣的資料平臺
- 位元組跳動基於ClickHouse優化實踐之Upsert
- 位元組跳動資料質量動態探查及相關前端實現
- 位元組跳動資料平臺技術揭祕:基於 ClickHouse 的複雜查詢實現與優化
- 位元組跳動資料平臺技術揭祕:基於ClickHouse的複雜查詢實現與優化