更多技術交流、求職機會，歡迎關注位元組跳動資料平臺微信公眾號，回覆【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官網瞭解更多