網易數帆實時資料湖Arctic的探索和實踐
作者 | 蔡芳芳
採訪嘉賓 | 馬進 網易數帆平臺開發專家
資料中臺也要從離線為主走向實時化，湖倉一體是第一步。
資料從離線到實時是當前一個很大的趨勢，但要建設實時資料、應用實時資料還面臨兩個難題。首先是實時和離線的技術棧不統一，導致系統和研發重複投入，在這之上的資料模型、程式碼也不能統一；其次是缺少資料治理，實時資料通常沒有納入資料中臺管理，沒有建模規範、資料質量差。針對這兩個問題，網易數帆近日推出了實時資料湖引擎 Arctic。據介紹，Arctic 具備實時資料更新和匯入的能力，能夠無縫對接資料中臺，將資料治理帶入實時領域，同時支援批量查詢和增量消費，可以做到流表和批表的一體。
這是作為網易公司基礎軟體團隊的網易數帆首次對外發布在湖倉一體方向的進展，同時宣佈的還有網易數帆有數實時資料中臺戰略。為了深入瞭解網易數帆在湖倉一體方向的探索和思考，以及實時資料湖引擎 Arctic 的設計思路和產品定位，InfoQ 採訪了網易數帆平臺開發專家馬進，圍繞以上問題逐一展開探討。
網易數帆要做什麼樣的湖倉一體？
湖倉一體（Lakehouse）最初指的是資料湖和資料倉儲融合、兼具兩者優點的新興資料架構，但如今它已經不只是一個純粹的技術概念，而是被賦予了更多與廠商產品層面相關的含義。在湖倉一體越來越火的同時，不同廠商也為它做出了各自的解讀。在進一步探討網易的湖倉一體實踐之前，我們有必要先了解一下網易數帆是怎麼理解“湖倉一體”的。
網易數帆團隊開展湖倉一體工作主要源於現實應用場景中的一個痛點，即在大資料場景下的實時資料和離線資料的處理鏈路是割裂開的，而且實時資料和離線資料的儲存也分別採用了兩套不同的儲存方案。一方面，重複建設和維護的成本比較大，另一方面，雙方的研究成果也沒有得到很好的複用。所以，團隊一開始的目標其實是為了實現流批一體，也就是將實時資料和離線資料的處理和儲存統一起來。
那為什麼後面演變成湖倉一體呢？馬進將流批一體劃分為三個層次，分別是儲存流批一體、開發流批一體和工具流批一體，並給出了這樣一個等式：
“儲存流批一體 = 湖倉一體 = 基於資料湖實現所有數倉功能”
離線數倉儲存從本質上來講，對應的就是資料湖技術，比如 Hadoop 生態的 Hive；相應的，實時數倉對應的就是傳統數倉所具備的技術能力，像 Greenplum、Teradata、Oracle 這樣的商用資料庫，其實都具備流式更新和 ACID 的能力，可以完成一些實時報表的工作。網易數帆團隊希望讓基於資料湖概念的離線數倉技術具備實時計算的能力以及 ACID 的保障，也就是具備傳統數倉的能力，因此，資料湖和傳統數倉各項能力的結合，就是網易數帆團隊要做的湖倉一體。基於這個目標，網易數帆打造了實時資料湖引擎 Arctic。
從實現路徑來看，Arctic 的原始需求是基於資料湖解決“倉”的問題，團隊對它的規劃是先要具備“倉”的功能，“倉”的相關工作做好後，再去延展實現“湖”的功能。
邏輯資料湖和湖倉一體，同一場景的兩種解法
除了湖倉一體，InfoQ 注意到，此前網易數帆還多次在公開場合提到另一個概念，即邏輯資料湖。網易資料科學中心總監、網易數帆有數產品總經理餘利華曾在接受InfoQ採訪時表示，邏輯資料湖是一種價效比更高的方式。這也給我們帶來了一些疑惑：邏輯資料湖這個概念因什麼而出現？它和湖倉一體、資料中臺之間的關係要怎麼理解？
馬進表示，邏輯資料湖與湖倉一體是同一場景下的兩個解決方案，本質上來說都是為中颱服務的。邏輯資料湖是“物理分散、邏輯統一”，而湖倉一體是“物理統一”，二者是同一問題下的兩個分支。
資料中臺提供的是一套資料治理和資料研發的方法論，主要面向業務，其中的資料建模、資料研發包括資料運維，它們的治理體系是一套。但是從中臺模組產品往下看，就會有不同方案的拆分。
其中，邏輯資料湖比較尊重業務以往的歷史負擔，比如之前用了 Greenplum、Oracle 這種資料倉儲，希望資料中臺能夠直接基於這些資料倉儲建設，不做資料遷移。從業務方來看，資料建模、資料開發與中臺的治理體系是一套，但底層的資料儲存可以不同。邏輯資料湖嘗試用技術把一個個資料孤島打通，比如對不同的資料倉儲做聯邦 Join，可以認為它是為了解決這種不統一的一個方案。“物理分散”，即底層的儲存可以分開，但“邏輯統一”，上層的中臺邏輯是統一的。
據瞭解，邏輯資料湖方案主要是為了滿足網易數帆部分企業客戶的需求，網易集團內部其實沒有太多這樣的負擔，甚至可以說這種負擔幾乎沒有，因為網易內部一開始就是基於 Hadoop 自建資料湖去實現的。但對很多企業客戶來說，他們以前採購了不同的資料庫，後來要構建自己的資料湖和資料中臺體系，網易數帆就給他們提供了邏輯資料湖的方案，客戶可以繼續使用原有方案，同時網易數帆給他們提供一個整套的中臺入口，統一管理不同的資料孤島。這是邏輯資料湖主要適用的場景。
相比較之下，湖倉一體的解決方案更加徹底。對於沒有歷史負擔的業務場景或企業客戶，他們所有新建業務都可以基於湖倉一體的方案來建設。基於湖倉一體方案，底層儲存在物理上就是統一的，都基於資料湖，上層也必然是統一的。
可以認為，這兩個方案都是服務於整個中臺，去構建一個統一的資料中臺的治理邏輯。馬進解釋道，兩種方案的收益不同，邏輯資料湖可以讓使用者快速上手，更好地覆蓋企業的歷史負擔；而湖倉一體可以用更低的成本去解決業務上的痛點，如果把時間線拉長，未來當雲端計算更大範圍普及之後，基於雲端物件儲存建設資料湖，跟使用傳統商用資料庫或商用數倉相比，節省的成本可能高達幾十倍甚至幾百倍。
實時資料湖 Arctic 的設計思路和定位
網易數帆建設湖倉一體的核心技術原理與 Hive 離線數倉方案最大的不同是對資料的管理粒度更加細化，Hive 的管理粒度在 Partition 級別，而網易數帆湖倉一體方案的管理粒度細化到檔案。由於上層承接資料中臺體系，湖倉一體需要為上層提供體系化的檔案管理方案，涵蓋檔案治理和檔案合併等功能，因此具備細粒度的檔案管理能力是首要需求。
經過調研，團隊最終選擇使用 Apache Iceberg，主要考慮是因為 Iceberg 本身的後設資料管理是面向檔案的，有非常全的 manifest 機制，可以把表中的所有檔案管理起來，Iceberg 作為底座提供了 ACID 的事務保證以及 MVCC 功能，可以保證資料的一致性，同時又具有可擴充套件性。
在 Iceberg 的基礎上，團隊又自研了實時攝取、檔案索引、資料合併，以及一整套後設資料管理服務。
技術選型
據馬進介紹，在最早做技術選型的時候，團隊也調研過與 Iceberg 同型別的開源專案 Apache Hudi 和 Delta Lake，但最終都因為一些原因而放棄選用。在做調研時，Hudi 還是相對比較封閉的狀態（它對自己的定位是 Spark 的一個 Lib，去年年底到今年才開始真正把支援 Flink 作為優先順序比較高的工作），而網易數帆需要一個開放的解決方案來適配高度定製化需求。
除此之外，也有一些技術細節的考量。比如資料格式方面的問題，Hudi 的檔案索引採用的是 Bloomfilter 以及 HBase 的機制，這兩種機制都不是特別理想，HBase 需要引入第三方 KV 資料庫，對商業輸出不利，而 Bloomfilter 比較重，會讓實時性大打折扣，因此都不太適合網易數帆的技術選型。網易數帆對 Arctic 核心功能的想法和設計，也跟 Hudi 有出入。
而沒選 Delta Lake 則是因為它對實時性並不是看得很重，馬進團隊通過研究相關論文發現，Delta Lake 更多還是把 Spark 的生態作為第一優先順序，這與團隊做湖倉一體的目標還是有一些區別。
相比之下，Iceberg 相對更開放，對計算引擎的整合、對上層後設資料的整合、對不同系統的整合都做得比較好，可以滿足團隊高度定製化的需求。因此團隊最終選擇了 Iceberg，能更好地落實自己的想法，並做出網易數帆獨有的功能特色。
基於 Iceberg，但不侷限於 Iceberg
雖然 Arctic 以 Iceberg 為底座，但馬進認為，從社群定位來看，Hudi 才是跟 Arctic 最像的。資料湖倉有一個非常重要的功能，即能夠基於主鍵進行行級更新，Hudi 在功能上與 Arctic 比較匹配，只是在核心設計上二者存在分歧，在實時入湖這一方面 Hudi 也最具有代表性。所以 Arctic 在做效能對比測試的時候，也是拿 Hudi 來對比，而不是 Iceberg。
實際上，網易數帆團隊在一開始做 Arctic 這個產品時，並不打算繫結任何一個開源的資料湖方案，包括 Iceberg。
最初團隊更希望基於資料湖做一個流批一體的湖倉，通過制定一個管理 Base 資料（即存量資料）和 Change 資料（即增量資料或實時資料）的方案，做到對兩種資料的解耦，不管底層使用什麼資料湖技術，無論 Iceberg 還是 Delta Lake，對外暴露的都是同一套湖倉一體方案。這是 Arctic 最初的定位，即不跟任何一家資料湖基座做高度繫結，但要做到這一點需要極高的研發投入，很難一步到位。因此前期團隊對於 Arctic 的定位首先是滿足網易湖倉一體的業務目標，把上層實時入湖功能涉及的讀合併、非同步合併、後設資料服務、小檔案治理等等在一個資料湖基座上管理起來，有了資料湖的基座，就可以基於此再去做上層的服務，然後再考慮增加在不同資料湖上構建湖倉一體的能力。
這看起來似乎又在已經相當複雜的資料系統中增加了一個服務層，不過馬進表示並非如此。首先做資料中臺，本身就是在 Hive 之上加了一層；其次增加的這些功能實際上是引擎端的適配，會有一個單獨的治理服務，而這個治理服務是偏中臺的模組，可以認為是整套資料中臺體系中的一部分。這個治理服務能夠把湖倉的後設資料管理起來，類似 Hive 中的 HMS，同時也可以做一些資料合併的規劃，還能對接不同的計算引擎，比如 Presto、Impala、Spark SQL 以及 Flink。
據馬進透露，團隊預計會在明年 Q2 將 Arctic 開源出去。其實團隊一直有在考慮如何將自研的東西貢獻回開源社群。從去年開始，網易數帆團隊就嘗試跟一些頭部網際網路公司共建 Iceberg 社群，希望能引導社群往湖倉一體的方向去發展。但社群本身對發展方向有自己的規劃，包括社群創始人前不久也已經從Netflix離職自己出來創業、圍繞Iceberg成立了商業公司，想要推動社群往一定的方向走成本很高，進度也會比較慢。
因此網易數帆團隊目前更希望先把所有的想法在 Arctic 上落實好，讓整個湖倉一體方案運轉起來，然後將做出來的成果開放出來，再進一步跟社群溝通，看哪些東西可以貢獻回社群。馬進認為，最重要的是希望 Arctic 至少能夠在網易長期經營起來。
落地情況和挑戰
目前網易數帆已經有部分客戶在使用 Arctic，集團內部也有不少業務接入了 Arctic。馬進透露，根據前段時間中期彙報的統計資料，網易集團內部已經有大約 600TB 規模的資料在使用 Arctic，並且陸續有新的業務開始嘗試。
按照資料來源，馬進將 Arctic 的使用者場景分為兩大類，不同使用場景採用的資料架構不同，引入 Arctic 時使用的改造方案也有所不同。
第一類場景的資料主要來源於日誌，比如網易雲音樂、網易傳媒，還有電商的部分數倉系統，他們的資料都以日誌為主。對於日誌資料，業務線在幾年前已經構建了非常健全的 T+1 資料處理解決方案，現在他們希望將原有的 T+1 的離線業務改造成實時業務。但是改造成實時鏈路後，又擔心資料的準確性，因為日誌資料比較容易出現資料亂序和重複。針對這種日誌型資料的場景，更多使用的是 Lambda 架構，Arctic 針對 Hive 提供了原地升級的方案，即將 Hive 的離線數倉表通過特定方式升級為 Arctic 表，升級後就可以通過實時計算引擎進行資料寫入，而離線數倉還保持了批量寫入的能力。Arctic 表會自動根據場景做實時和離線的切換來面對不同的業務場景。網易集團內部主推 Lambda 架構，因為集團內部日誌型資料場景更多一些。
Kappa 架構則更多面向企業使用者，像金融、製造業、物流等傳統行業，他們的資料不管是實時資料還是全量資料，主要來源是資料庫。資料庫裡儲存的資料很少出現亂序重複的問題，相對比較準確，也有完整的機制保證資料一致性。這種情況通常不需要用離線鏈路來兜底，日常用一個實時鏈路就可以。但有時候也會出現資料庫表變更的情況，比如增加一列或減少一列資料、資料表結構發生變化，或者一些資料出現了錯誤，需要大規模修正，這時就需要對原始資料進行批量計算回補，同時需要離線鏈路去發揮作用。
綜上，網易集團內部主要進行 Lambda 架構的改造，而針對企業客戶，主要的實踐是 Kappa 架構。網易集團內部的網際網路業務和傳統企業客戶的業務，資料處理的場景和方式不一樣，不過兩者沒有絕對的界限，網易集團內部也有一些潛在的使用 Kappa 架構的場景，比如嚴選電商就有很多實時資料來自資料庫的場景。
對於湖倉一體方案的實施和落地，Kappa 架構是最理想的方案，因為天然具備實時性，也沒有歷史負擔，建設湖倉一體的成本低；而對於 Lambda 架構來說，就可能面臨已有離線鏈路、但離線做的不夠規範，本身就需要一定的改造，這種情況升級改造的成本會比較高，技術實現上也需要更多磨合。當前團隊推動湖倉一體方案落地更多會選擇一些基於 Kappa 架構的場景，Lambda 架構主要與集團內部大的業務共建，過程相對比較緩慢。
除了前面所說的歷史負擔問題，企業嘗試採用湖倉一體技術還面臨另一個挑戰，就是組織上的問題。在馬進看來，目前資料中臺整個方案“離線”的基因很重，實時相對來說是一個比較獨立的分支，而且實時計算不光用在大資料場景，線上場景也經常涉及。如果希望通過實時給整個資料中臺賦能，就需要侵入到資料中臺的架構體系裡面去。這就涉及不同團隊的磨合以及目標統一的問題，在推進上有一定的困難。這與前兩年企業推行資料中臺戰略面臨的挑戰是類似的。
馬進坦言，去年準備做湖倉一體的時候，就面臨比較大的阻力，因為資料中臺團隊也有自己的規劃，比如前面提到的邏輯資料湖，而湖倉一體是從另外一個角度去解決問題。這就需要公司的決策層在這件事情上有非常精準的判斷並制定相應的戰略目標。今年在網易數字+大會上正式宣佈將實時資料中臺作為戰略來推進，是網易數帆在推進湖倉一體過程中有優勢的一點。
流批一體的最終目標還有多遠？
對於網易數帆來說，湖倉一體（即儲存的流批一體）是最終實現流批一體必經的一步，最終願景是用一個邏輯一套程式碼去覆蓋離線和實時兩個場景。如果實時和離線是兩套儲存、用到兩張表，就不可能用一套程式碼解決，因此要優先解決儲存的流批一體，然後再基於此做開發的流批一體。把工具和團隊統一之後，中臺的模組如資料模型、資料資產、資料質量等等也都可以做流批一體了，從原先只有離線的功能，到具備實時功能，這被稱為工具流批一體，更確切的說法是中臺模組的流批一體，最終給前端業務呈現的就是實時資料中臺。
流批一體是網易數帆團隊一直以來的戰術方向，即做到大資料平臺的實時化，而不是將實時計算獨立出來做。前述流批一體的三個層次都是網易大資料平臺未來的重點改進方向。
針對儲存的流批一體，現在已經有實時資料湖引擎 Arctic，後續團隊的工作重點主要包括效能優化和自研特色功能，比如實時資料攝取、資料合併、後設資料管理服務等，整體有一個長期的研究規劃。未來 Arctic 也將適配更多計算引擎，除了已經適配的 Flink、Spark，Impala 的適配工作也在進行中，明年 Arctic 開源的時候，也會做好 Presto 的適配。
同時，開發流批一體和工具流批一體方面的工作也在緊鑼密鼓地展開。
開發的流批一體主要是負責 Flink 的小團隊在跟進，目前主要在實踐階段。馬進表示，計算流批一體的社群成熟度要比儲存流批一體好很多，網易更多是在業務側實踐，爭取明年可以推出開發流批一體的工具和平臺。工具流批一體則是整個資料中臺團隊在推進，整體進度已經完成了 20%~30%，不過暫時還沒有對外發布。
在馬進看來，未來實時和離線技術必然會收斂到一起，從技術實現來看相對樂觀，目前網易數帆也已經有相對應的解決方案，但大規模的業務落地需要更多時間。至少還需要兩年時間，才會有更多業務把流批一體和湖倉一體作為一個比較標準的方案，過程的快慢與每個業務自身對存算分離的訴求的急迫程度有關。
客觀來說，現階段湖倉一體技術在開源技術裡還不是很成熟。馬進表示，企業需要對大方向保持關注，但到底要不要採用，還得看企業的發展情況。如果企業的自研能力相對缺乏，可以繼續觀望，等待更加成熟的解決方案出現。在他看來，現在的解決方案大多數都還處在體驗嚐鮮的階段，遠沒有達到廣泛應用的階段。對於有一定技術實力的企業，可以先基於集團內部場景推廣使用，這也是很多頭部企業的做法，比如阿里、騰訊以及位元組，網易也是先基於集團內部場景孵化一些解決方案。
不過網易數帆的工作重點是給企業做私有化解決方案，相比之下，阿里和騰訊的工作重點是公有云，更希望能將客戶的解決方案壟斷在自己的生態之中，而網易數帆則更傾向於背靠開源，然後強於開源，做技術的破壁者。
過去一年，圍繞湖倉一體和流批一體話題，InfoQ採訪了數位大資料平臺領域專家，雖然每家公司的解讀和實現路徑各有不同，但對於湖倉一體和流批一體未來長期的發展趨勢基本能夠達成一致。
從長遠來看，不管是阿里雲、騰訊雲還是 Databricks，未來的湖倉一體發展趨勢都是趨同的，即基於廉價的儲存設施，把數倉的能力建設好，短期內可能由於公司發展戰略及自身定位的差異，研究方向存在一定差異。
雖然如此，技術更迭的過程仍免不了曲折。對於很多企業來說，之前已經做了實時計算並構建出一套比較獨立的架構，並沒有很強的動力去做架構升級和更新。這有點類似於過去資料庫領域常常提到的“自己革自己命”，資料中臺也面臨這樣的困擾。但以發展的眼光來看，這樣的突破非常有必要。如果進行了革命，最終實時和離線統一到一起，未來大資料平臺會更加簡單精練，工具的專業門檻會越來越高，但使用成本會越來越低，使用者使用工具的投入走向收斂。
大資料平臺以及資料業務全面的實時化，必然會對當前的生產關係以及組織架構帶來一定的調整訴求。這是一個自我改革的驅動，需要企業有一定的魄力。
採訪嘉賓介紹：
馬進，網易數帆平臺開發專家，網易資料科學中心線上資料和實時計算團隊負責人，負責網易集團分散式資料庫，資料傳輸平臺，實時計算平臺，實時資料湖等專案，長期從事中介軟體、大資料基礎設施方面的研究和實踐，目前帶領團隊聚焦在流批一體、湖倉一體的平臺方案和技術演進上。