如何快速建構企業級資料湖倉？

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