Arctic 的湖倉一體踐行之路

本文將系統地介紹 lakehouse、table format 概念，闡述湖倉一體作爲數據湖流批一體的解決方案，可以發揮哪些價值。在這個價值驅動下，我們過去兩年開發了 arctic 這個流式湖倉服務，並在今年下半年開源。

湖倉一體拓展了數據中臺和 dataops 的邊界，讓業務基於數據湖，數據中臺也能做流式更新；實時數倉，讓數據湖能夠具備傳統數倉，kudu，doris 的能力，爲業務極大地降本提效，歡迎感興趣的同學諮詢和交流。

前數據湖是什麼

數據湖這個概念最早由 Pentaho 創始人兼 CTO James Dixon 在 2010 年提出，從當時背景看，這個點子主要是爲了推銷自家公司基於 hadoop 的 BI 產品方案，時至今日，雖然 Pentaho 已被日立公司收購，這位大佬也另謀出處，而數據湖的含義已遠遠超出原先的定義，經過各個大廠，尤其是 AWS，Azure 這類公有云廠商的加持，基於數據湖已衍生出非常多樣的工具和方法論。

簡單說，我們可以把數據湖當做一個存儲各類結構化、半結構化和非結構化數據的池子，這個池子可以是私有化的 hadoop 集羣，也可以是雲端的對象存儲，因爲我們要存儲體量非常大的原始數據和明細數據，這個池子的成本必須足夠低，開啓 EC 的 HDFS 或對象存儲無疑是最佳選擇。這個大需要多大？我們用 AWS 提供的一張圖來說明：

有了很大的池子存儲原始數據和明細數據，數據分析師再也不用擔心數據無法溯源，明細丟失的問題，但是按照傳統的 BI 方法論，依然需要將數據湖的數據導入到數倉中，才能構建出終端想要的數據集市，那麼爲什麼我們不能放棄舊框架，直接在數據湖上做分析，不是更快更省？

於是乎，數據湖開始了紅紅火火的十年，在過去十多年中發生了很多標誌性事件，我們將數據湖過去十年的發展拆爲兩個階段：

第一個五年（2010-2015）打地基，像 mapreduce，spark，flink 這些計算引擎讓數據湖之上的 ETL，數據清洗和加工變得簡單，parquet、orc 這類列存文件格式，impala、presto、trino 這些基於數據湖的 OLAP 引擎讓數據湖之上的數據分析觸手可得。

第二個五年（2015-2020）造建築，不管是雲端還是私有環境，各種數據模型，研發工具 ，治理平臺玩地風生水起，網易有數、阿里 Dataworks 都是在這個時期誕生的數據中臺產品。總體來看，數據湖技術經過五年的打地基，五年的造建築，目前基於數據湖的工具和方法論已經非常成熟，比如網易做大數據的同學，很多人都接觸過有數，或者直接使用過 hadoop、hive。

與幾十年根基的傳統數倉相比，數據湖近十年發展歷程可謂佔盡天時地利人和，越來越多的企業在強調數字化轉型，越來越多的業務需要大數據幫助決策，此爲天時；強大的擴展性，讓任何企業都可以通過堆機器來應對爆炸的數據體量，不被任何商業公司綁架，不管你需不需要數倉，你可能都需要一個數據湖，此爲地利；hadoop 開源體系，給用戶帶來了豐富的生態資源，也給企業培養了海量的大數據人才，大家喜歡開源，此爲人和，另外，AI、機器學習、數據挖掘這類非標業務非常依賴生態資源的加持，數據湖在這方面有得天獨厚的優勢。

但同時，數據湖缺乏標準化的服務，生態內的組件大多各自爲戰，這帶來了幾個問題：

• 建築造地累，比如有數在產品側需要對接非常多的組件，每個組件都有自己的玩法，架構難免臃腫，人效上不去，當然如果產品不做這些事，就得業務自己做，人效更低；

• 會導致數據沼澤問題，哪些表在給哪些業務用，哪些數據有浪費，有重複建設，這些都必須在上層定製方案，基礎設施這一層缺乏有效的度量和管理支撐，過去企業分享數據中臺效果，動輒節省一大半的成本，說明數據湖之上的沼澤問題是非常嚴重的；

• 對流和實時場景支持有限，因爲數據湖的生態中沒有支持行級更新的服務，行業內基本上用數據湖做離線數倉，實時數倉會選擇其他方案；

• 數據質量，因爲數據湖非常開放，並且本身會存很多原始數據，在數據質量方面有天然不足，需要上層產品在質量保障方面多加考量。

火爆的湖倉一體

湖倉一體是個舶來詞，英文叫 lakehouse， 由 databricks 公司首先在 2020 年 3 月提出，在 databricks 的理念中，傳統數據湖在批計算，AI，機器學習等領域有豐富的資源和實踐，但是在流計算，數據質量和數據治理方面相較於傳統數倉有較大不足，爲此 databricks 提供了 lakehouse 平臺，基於數據湖之上提供不弱於傳統數倉的能力，也能享受數據湖在 AI，機器學習，批計算上的積累。

Databricks 作爲一家商業化公司來講 lakehouse 的故事，必然有營銷的成分在，但必須承認 lakehouse 這個概念已經深入人心，包括 databricks 的老對手 snowflake，也在講自己是 lakehouse。感興趣的同學建議看看 Databricks 工程師最早提出 lakehouse 的博客：

What Is a Lakehouse?

說到 lakehouse，就必須提到 table format 的概念，Table format 最早由 iceberg 提出，現在基本成爲行業共識， table format 是什麼？簡單概括：

• Table format 定義了哪些文件構成一張表，這樣任何引擎都可以根據 table format 查詢和檢索數據；

• Table format 規範了數據和文件的分佈方式，任何引擎寫入數據都要遵照這個標準，通過 format 定義的標準支持 ACID，模式演進等高階功能。

目前國內外同行將 delta、iceberg 和 hudi 作爲數據湖 table format 的對標方案，在 databricks 的故事中，delta 是 lakehouse 的存儲底座，所以 table format 和 lakehouse 有非常密切的關係，我們有理由相信，lakehouse 方案應當是基於數據湖 table format，涵蓋數據研發和數據治理的一整套方案。

湖倉一體有多火，關注行業動態的小夥伴應該會有切身感受，比如從今年開始基本上任何有體量的大會、論壇、meetup 都會組織湖倉一體相關的分會場，我們也能看到各個大廠在這個方向上的積極探索和實踐，在 gartner 發佈 Hype Cycle™ for Data Management 權威報告中，lakehouse 目前處於躍升期位置，相比於成熟期的 deta lakes，lakehouse 未來還有 3-5 年的發展成熟週期： 

還有一份報告值得關注，在 2021 （2022 的報告還未發佈）最新發布的數據庫魔力象限中，主打 lakehouse 產品的 databricks 和 snowflake 攜手進入領導力第一象限，而去年這份報告中，只有 snowflake 處於挑戰者的位置：

Lakehouse 不光在技術圈受捧，在資本圈也是鼎鼎有名，巴老爺子加持的 snowflake 千億神話自不必說，databricks 經過多輪融資之後，也達到了 380 億美金的估值。就在前不久，delta2.0 完全開源了（過去只開源了一部分），並且推出了一系列新功能，感興趣的同學可以看下我這篇針對 delta2.0 的分析：

 從 Delta 2.0 開始聊聊我們需要怎樣的數據湖？

爲什麼做 Arctic

2020 年開始，通過用戶走訪和行業調研，我們開始嘗試用 flink + iceberg 打造流批一體數據湖的方案，首要的目標是先構建存儲的流批統一，在流批一體的數據湖之上，再去探索代碼的流批一體，但是在實踐中發現，iceberg 作爲 table format，直接拿來匹配流批一體的需求還存在很大的 GAP，arctic 這個項目便是在這個背景下產生的。

3.1 企業需要湖倉一體

流批一體和湖倉一體是什麼關係，這是過去兩年被問的最多的問題。

簡單說，流批一體是需求，湖倉一體是方案，就好比我說我想喫甜的東西，你拿給我一塊蛋糕，甜是流批一體，蛋糕是湖倉一體。我們可以蛋糕是甜的，但不能是甜的東西就一定是蛋糕，從 lakehouse 提出的背景看，湖倉一體一定是流批一體，但流批一體不一定基於數據湖，事實上很多傳統數倉都具備流批一體的能力。

企業爲什麼需要湖倉一體，可以拆成兩個問題：

• 企業爲什麼需要流批一體

• 爲什麼要在數據湖上做這個事

我們來看看目前主流的流批共存的架構是怎麼樣的：

場景中用 hive 做批表，kafka 做流表，實時場景下需要用戶構建數據庫同步到 hbase 的實時任務，需要用戶實現 join hbase 維表的流計算任務，把數據寫到支持實時更新的 kudu 中，最後由業務根據實時和離線的需要選擇查詢 kudu 表還是 hive 表，在此之前，用戶需要分別在數據模型中建表，使用 kudu 的工具建表，並且自己處理兩個系統的差異。在這個架構中，用戶遭受了割裂的體驗，並且需要在上層做很多工作。

在這套 lambda 架構中，用戶使用 hive 和離線開發工具構建離線數倉，使用 kudu，hbase 和實時開發平臺構建實時任務，相同的業務邏輯構建了兩套數據模型，維護兩套數倉和兩套任務鏈路，造成人效和資源的浪費，語義的二義性也會給維護帶來更大的成本，對數據分析師，算法工程師，數據科學家，去熟悉兩套規範和工具，理解更多的底層概念也是一項很大的挑戰。比如對網易雲音樂而言，數據分析師和算法工程師很多，怎樣儘可能提效和降本是一個很有意義的課題，而對一些規模有限的業務團隊，人力緊張，也可能沒有多餘的預算來搭建兩套系統，既快且省可能是第一位的訴求。

理解了流批一體的必要性，那麼爲什麼要基於數據湖做流批一體？

第一數據湖是個兜底的存儲中心，具有極強的彈性伸縮能力，符合 “省” 的要求，第二過去我們圍繞數據湖已經搭建了非常豐富的工具，而且現在依然在向 dataops 的方向持續演進，基於這套方法論也沉澱了非常多的規範和實踐，如果基於數據湖做流批一體，數據中臺上的很多能力可以複用，快速上手，符合業務對 “快” 的需求。

反之如果我們使用其他數倉做流批一體，比如 doris，相當於在數據湖之外又構建了一個數據孤島，在依然需要數據湖的情況下，業務需要自己處理 doris 和數據湖的傳輸和一致性，沒有從根本上解決問題。

3.2 Table format 不等於湖倉一體

我們從數據分析的可用性，數據加工的實時性，湖倉的管理三個方面來說明 table format 與我們需要的 lakehouse 之間的 gap。

3.2.1 數據分析可用性

與 Hive 相比，delta/iceberg/hudi 最核心的不同是在表格式中抽象出快照的概念，表的任何數據變更都會構造出新的快照，delta/iceberg/hudi 通過快照的隔離實現數據寫入的 ACID 和讀取的 MVCC，更好地支持數據實時攝取和計算，如下圖所示：

Table format 是數據湖之上比 hive 更進一步的元數據封裝，遵循所讀即所寫的原則，而在用戶的讀寫之間應當有一個標準化的服務，比如在流和實時場景下，會在數據湖中寫入很多碎片文件，這些小文件會導致讀性能的急劇下降，在 chbenchmark 中，我們發現流式寫入 2 小時就會導致 olap 性能下降 1 倍以上，不管是數據去重還是小文件合併，我們需要需要一套持續優化的服務來保障數據分析持續可用。

3.2.2 實時數據加工

湖倉一體的特性讓批和流的數據加工、數據分析、科學計算、機器學習都能在數據湖中完成，在這幾個環節中，數據加工是最基礎的步驟，流批一體的數據加工可以讓 BI 和 AI 共享 lakehouse 高人效，低成本，強彈性的紅利。

目前生產環境中大多使用 hive 和 kafka 分別作爲批表和流表選型，實時場景下再搭配 flink 和 kudu 這類支持行級更新的列存數據庫做實時數倉方案，用消息隊列的優勢在於毫秒到秒級的數據時效性，如果我們用 lakehouse 替換掉 hive 和 kafka，在離線數倉和批計算上，可以做到平替，但是在實時數倉和流計算上，由於數據湖的增量讀有分鐘級延遲，會出現毫秒 / 秒級的時效性到分鐘級時效性的降級。而且從實踐上講，以 kafka 或 pulsar 作爲流表實現更加成熟，這令數據湖在實時加工鏈路中天然吸引不足。

在大量用戶調研後，我們發現用戶大多能接受數據分析分鐘級別的時效性，但對端到端的處理延遲有更高的要求，尤其對數據開發同學，KPI 指標可能是構建的數據建設的複用度，低時效性的數據處理可能喪失對更多場景的吸引，同時面對複雜的數據分層場景，會讓端到端的延遲更加不可控。

另一個實時數據加工的問題是維表關聯，就是我們俗稱打寬的場景，在上文的 lambda 架構中，當用戶需要維表關聯時，往往需要引入一套 hbase 或 redis 這樣的 KV 系統，數據開發同學、算法工程師不光要耗時耗力學習和使用 kv，還需要自己構建數據庫到 kv 的同步，接收和處理這些同步任務的報警，處理 kv 數據的序列化反序列化，嚴重降低了數據開發和算法工程師的幸福度。

在 databricks 的理念中，lakehouse 能做到開箱即用的流批一體，但顯然用戶期望的流批一體和 delta、iceberg 這類 table format 之間還有較大的 gap，用戶對 lakehouse 的期望既要兼顧到端到端的延遲，數據打寬時也要能像離線 join 一樣做到即插即用。

3.2.3 怎麼做湖倉管理

上文提到，小文件是典型的湖倉管理要解決的問題，過多的小文件會讓 OLAP 性能下降，HDFS 的 NN 不堪重負。而當我們在數據湖之上構建更多的實時數倉，會面臨更多成本、時效性和性能的管理需求：

• 表的時效性怎麼量化，是否達到用戶預期？

• 湖倉表當前的查詢性能有多少可優化空間？

• 數據優化的資源怎樣量化，怎樣最大化利用？

• 怎樣靈活分配資源，爲高優先調度資源？

區別於 MPP 架構的傳統數倉，湖倉是個天然存算分離，彈性伸縮的架構，過去部署一套 greenplum，部署了幾臺機器，就用幾臺機器，如果發現容量或性能不足，就去擴容，數據遷移。對這種傳統存算一體的架構，對應的管理系統目標是儘可能把內部的運作黑盒化，對外提供一些度量和指標來衡量系統的健康度或性能。

而在湖倉中，首先這套管理系統是缺失的，hive 以及現在的數據湖 table format 歸根到底只是定義了表在數據湖上的元數據形態，並沒有動態的湖倉管理機制，其次如果我們想做一套湖倉管理系統，思路和存算一體的 MPP 數據庫也會有所區別，比如湖倉在後臺進行的數據優化動作，用戶需要爲這些彈性的優化行爲花錢，而這個錢會直接作用在湖倉的時效性和性能上，存算分離的管理系統需要爲用戶更加透明地梳理好時效性，性能，成本之間的關係：

這套湖倉管理系統，需要在保障性能、可用性的前提下，利用好數據湖彈性伸縮的能力幫助用戶最大限度降本，爲用戶花出去的每分錢負責。

Arctic 是什麼

我們聊了企業爲什麼需要流批一體和湖倉一體，也聊到了 table format 和湖倉一體之間的 GAP，生產場景中會存在的需求和問題，Arctic 便是我們團隊對這些需求和問題的答案。

Arctic 目前已經開源，我們對 arctic 目前的定位是流式湖倉服務，是基於 lakehouse 開箱即用的流批一體服務，流式強調在數據湖之添加了更多實時的能力，如更加優化的 CDC 攝取，流式更新，生產可用的實時合併，對用戶無感的流式數據自優化等，服務強調 arctic 是搭建在 table format 之上的管理服務，如上文所屬，arctic 管理服務聚焦在爲用戶梳理時效性，性能以及成本之間的關係，幫助用戶做好容量規劃，數據管理和治理。目前 arctic 是搭建在 iceberg 之上，理論上說，arctic 未來也可以基於 delta 和 hudi。

Arctic 架構如下圖所示：

可以看到，Arctic 的核心組件包含 AMS 和 Optimizer，在 arctic 中，AMS 被定義爲新一代 HMS，AMS 管理 Arctic 所有 schema，向計算引擎提供元數據服務和事務 API，以及負責觸發後臺結構優化任務。

Arctic 作爲流式湖倉服務，會在後臺持續進行文件結構優化操作，並致力於這些優化任務的可視化和可測量，優化操作包括但不限於小文件合併，數據分區，數據在 Tablestore 之間的合併轉化。

Optimizer container 是 optimizing 任務調度的容器，目前生產環境主要是在 yarn 上調度，支持擴展 optimizer container 實現調度到 k8s 或其平臺。Optimizer group 用於資源隔離，optimizing container 下可以設置一個或多個 optimizer group，也可以通過 optimizer group 實現優先級的功能，在 yarn 上 optimizer container 對應隊列。

篇幅關係不再對 arctic 的架構與概念進一步展開，感興趣的同學可以移步我們的文檔，後續我也會在其他的文章裏聊聊 arctic 在架構設計中的考量，與其他產品的差異。

能用 Arctic 做什麼？

Arctic 的目標是開箱即用的流批一體：

與原先流批割裂的 lambda 架構相比，arctic 用存儲統一了數據生產的鏈路，arctic 表既可以作爲離線表給 spark 用，也可以作爲流表給 flink 用，還可以用 impala/trino 的 OLAP 引擎查詢 arctic 表，構建數據集市。值得一提的是，arctic 的流表能夠做到毫秒到秒級，arctic 將用戶需要的消息隊列，作爲 broker service 封裝到 arctic 的管理體系裏，用戶只需要在創建表的時候指定是否需要引入隊列，在後續的使用中即可透明無感地用到消息隊列實時分發的能力，arctic 在對接 flink 的 connector 中，封裝了消息隊列與數據湖的雙寫和一致性保障。

在 AP 性能上，arctic 通過 optimizer 機制實現表的結構自優化，在我們的 benchmark 測試中，流式寫入 iceberg 表 1 個小時以後，因爲小文件問題，以及一些不完善，性能下降會非常厲害，1.5 小時候數據已經跑不出來了，arctic 的平均延遲維持在 20s 左右，而 hudi 30s 左右（平均延遲越小，性能越好），詳細的 benchmark 報告可以移步：https://arctic.netease.com/ch/benchmark/

Arctic 流批一體的能力可以拓展數據中臺，或 dataops 的邊界，更直觀點說，用戶可以直接用各種有數的中臺工具來實現流批一體，比如今年我們在幫有道做的替換 doris，和傳媒一起做的替換 clickhouse，業務在使用之前的系統時，缺乏高效率的工具，還要爲這些獨立部署的資源買單，切到 arctic 之後，由於數據湖高度彈性的能力，和低成本的特性，可以給用戶省錢提效。

Arctic 不光可以用在大數據場景，今年調研發現，在線業務也有一些需要存儲大體量的歷史數據，或者 AP 和 TP 混用的場景，比如風控場景需要存儲非常多日誌清洗後的數據，而這些數據全部存儲在 ES 裏成本會失控，我們和雲音樂團隊一起做了一個數據湖與 ES 混合使用的方案，數據湖來兜底，會存儲非常久的數據，並且是實時入湖，在我們測量下，用數據湖來實現冷熱分離，佔用的空間小 XX 倍，成本上則帶來幾十倍的提升。

期望與規劃

要做到開箱即用的流批一體，arctic 還有不少的工作要做。

比如不依賴外部 kv 的維表關聯，在前不久發佈的 arctic v0.3.1 版本中，我們發佈了這項功能的 beta 版本，在一些維表不是很大的場景下，可以做到生產可用，未來還需要做哪些優化工作，已經在 roadmap 裏，再比如 inline upsert 功能，讓 flink 任務可以流式更新大寬表中的部分列，從而代替狀態過大的多流 join，這兩個是我們今年在流場景下想要重點打造的功能。完整的 roadmap 記錄在 這裏 。

在批場景，我們已經支持了相當一部分業務，通過 spark 的讀時合併讓業務能夠獨到準實時的數據，用戶也可以通過有數提供的 impala 對接 arctic 實現分鐘級時效性的實時數倉，用 trino 的用戶，可以將 arctic 的 trino connector 集成到自己的 trino 集羣中，我們的小夥伴會做好對接工作。

未來 arctic 也將不斷豐富管理功能（這塊在 lakehouse 領域還比較空白），arctic 作爲網易數帆重點打造的一個開源項目，非常歡迎內外部的開發者能夠關注、使用和參與，一起打造行業領先的湖倉管理系統，未來一年我們極有可能嘗試在 apache 孵化。

如果你對數據湖，湖倉一體、table format 或 arctic 社區感興趣，歡迎聯繫我們深入交流：微信添加 “kllnn999” 爲好友，備註“Arctic 交流”。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/23UTHsU5pmZpmCXe1oV_7Q