湖倉一體，可以提供資料湖的開放格式、低成本儲存，以及強大的管理能力。資料分析、機器學習、實時計算、音影片檢索等都可以從“湖”裡汲取資料，從而讓資料治理更加便捷高效。
在傳統行業數字化轉型過程中，尤其像在金融行業，全域資料統一管理、集中開發和融合共享是必然趨勢，這是時下湖倉一體被寄予厚望的重要原因。那麼，如何架構經過驗證的湖倉一體解決方案，並推動它很好的演進？
近日，網易數帆舉辦了“企業級流式湖倉服務Arctic開源釋出會”。釋出會上，詳細介紹了網易數帆如何理解湖倉一體、Arctic專案的孵化和成型，這一專案可以解決哪些問題、發揮怎樣的能力、能夠為大資料從業者帶來什麼，以及社群的建設和未來的發展。
產品釋出：開放式架構下的開源流式數倉平臺
在長期服務客戶的過程中，網易數帆總結出自己的資料建設方法論：DataOps、DataFusion，以及DataProduct。釋出會開始，網易數帆大資料產品線總經理餘利華就如何在這一方法論之下架構開源流式數倉平臺，以及如何進行Arctic專案孵化進行了深入分享。
在網易數帆的大資料技術體系架構中，最底層是基礎設施，即儲存計算能力架設；底層之上是資料研發層，提供包括資料傳輸、實時開發、離線開發、資料測試、任務釋出、任務運維等能力，覆蓋DataOps整個過程；再往上是資料中臺，在這一層，資料研發和治理的一體化、中臺架構解決資料孤島，以及設計基於ROI的資料資產沉澱方法是主要亮點；資料中臺再往上是資料產品，可基於無程式碼的方式建設場景化的資料產品。
首先，在技術架構上，該體系最大的特點是開放式，可讓各模組獨立成為一個專案：儲存單拉出來是HDFS，快取單拉出來是Alluxio，執行引擎和查詢拉出來是Spark、Impala，等等。每個模組獨立成一個專案，通過鬆耦合的方式組裝在一起就形成了開放式大資料技術體系。這樣的架構好處顯而易見，包括能力全面、生命力強，以及建設成本較低。
其次，第二個技術特點是開源，包括採用直接開源的軟體，以及在開源軟體不能滿足的情況下給社群做Patch。這樣一來不僅能夠被社群評審和檢驗，公司本身也不用長期維護Patch，降低維護成本。截至目前，網易數帆在Spark領域累計合入提交了近600多個Patch，同時也培養了一位Spark committer。網易數帆在整個大資料發展史上，培養了多位Apache的committer。
此外，如果社群確實無法滿足開源需求，才會進行自研開源，比如Kyuubi。這個專案在立項時，開放式架構的其他層有Spark、Impala、Parquet等開源技術可選，但是缺少統一的多租戶安全的SQL閘道器，因此Kyuubi誕生。目前這個專案已進入Apache孵化，並在阿里雲、騰訊雲、中國移動、小米等公司落地，有17位committer和83位貢獻者。
當然，在建設中臺的過程中，也面臨不小的挑戰。首先，是技術不統一，實時技術和離線技術採用兩套技術棧，帶來的問題是整個系統的運維複雜，同時儲存冗餘也浪費成本；其次，研發體系的割裂讓成本增加。此外，應用開發也十分複雜，將實時表和離線表透過兩種儲存方式儲存，不僅增加了使用者理解困難度，冗餘資料也帶來了資料口徑的指標二義性問題。
在餘利華看來，以上問題的解決核心在於提供流式數倉平臺，把實時表和離線表相結合，一張表既可以支援流式消費、流式寫入，也要支援批次查詢和更新。
在基於資料湖的開放式架構中，從下到上分別是檔案系統層，實現資料的儲存和訪問；檔案格式，定義檔案和資料之間的關係；表格式層，定義檔案與表之間的邏輯關係；最上層是介面，是以SQL的方式統一訪問的入口。
如果要支援流式數倉，需要在表格式層動點“小手術”，引入Iceberg、Delta等新型表格式。新型表格式解決了資料更新、大表訪問效能、資料增量消費等問題，但是仍然遺留了不少問題。餘利華舉了三個例子：第一是小檔案問題，頻繁資料寫入，帶來很多小檔案，導致查詢效能很差，有時候效能會下降一半；第二是相容性問題，是否能相容目前最主流的HIVE格式，簡化應用推廣，是否能相容Iceberg/Delta等格式，資料中臺還是那個資料中臺，我們只是多了選擇表格式的自由；第三是流式更新問題，Iceberg、Delta表格式流式更新能力較弱， 用在資料庫到大資料實時同步場景效能有所不足， 短期內需要做一些增強。
為對以上問題進行針對性解決，網易數帆和華泰證券一起研發了企業級的流式湖倉服務Arctic，並將其開源。
Arctic技術架構：實現開箱即用的元資料服務
據網易數帆大資料實時計算技術專家、湖倉一體專案負責人馬進介紹，公司自2020年開始關注資料湖新技術便聚焦於構建流批一體和湖倉一體的架構。最初想要採用Flink+Iceberg，但在真實場景應用時發現過多問題，因而進行了自主設計，便是Arctic的雛形。
也是從2020年開始，Hudi和Iceberg進入不少開發者的視野，隨著它們從Apache孵化到畢業，Table format的概念逐漸被更多人接受。首先，Table format定義了哪些檔案可以構成一張表，像Flink、Spark、Trino、Impala，任何引擎都可以根據Table format去查詢檢索資料；其次，Table format規範了資料和檔案的分佈方式，任何引擎寫入資料都要遵照這個標準。
事實上，在有了Table format之後，可以基於資料湖來實現類似於訊息佇列的功能，資料延遲會從毫秒或者秒級降級為分鐘級別，像實時更新、讀時合併。行業內很多公司推廣資料湖的主要場景時，主要以實時更新以及讀時合併平替如Kudu、Doris、Greenplum這些支援更新的數倉系統。
進一步，在企業需要怎樣的資料湖這個問題上，有三點值得注意：首先，如果只關注資料湖Table Format個別中間功能，推廣起來會比較困難；其次，當用資料湖做訊息佇列時，可能引入很多小檔案，小檔案的管理需要保持關注；最後，還有一個隱形的問題——成本分攤，以前訊息佇列的成本由業務團隊承擔，現在用一個公共的資料湖底座，成本的合理分攤也需要注意。
因為存在以上問題，業內很多公司在是否使用資料庫新技術作為替代解決方案這個問題上都比較糾結。那麼，Lakehouse技術如何給企業帶來更大價值？
在馬進看來，應用場景一般期望在資料中臺層、方法論層可以使用一套規範或流程把實時和離線，以及更多的AI場景統一起來。而Lakehouse這個概念創造出來的意義，就是拓展產品的邊界，讓資料湖能更多的服務於流的場景和AI的場景，他表示：“Lakehouse，或者說湖倉一體給業務終端帶來的是體系上的收益，而不在於對某個功能的使用。”
為了實現這樣的效果，Arctic在lceberg和Hive之上增加了更多實時場景的能力，面向DataOps提供開箱即用的元資料服務，讓資料湖更加合用和實用。
具體來說，Arctic包含兩個核心元件：元資料服務AMS，在系統中的定位是下一代HMS的角色；以及包含了整套optimizer的元件和機制，可以實現持續的後臺資料自最佳化。
具體到架構和元件的設定，在資料湖層包括change files、base files，分別對應changestore和basestore；上層則設定了一個AMS，是三元組的元資料中心，支援和HMS做同步。同時，AMS會提供事務和衝突解決API；在Optimizer層，有一整套完整的擴充套件機制和管理機制，包括Optimizer container和Optimize group。此外，在Arctic架構中匹配了單獨的管理介面Dashboard，提升湖倉本身的管理體驗。而在Table format的相容性設定上，主要提供兩種方案，其一是Iceberg，包括basestore、changestore都是獨立的Iceberg表，均可相容到Iceberg的V2版本；其二是Hive的相容模式，如果使用者使用的是Hive formate相容，它的change資料還是存在Iceberg裡面。
談及做開源的初衷，馬進表示說：“過去我們做開源可能缺少統一的步調，去年領導層也下定決心，明確了未來做開源會以更加專注的方式。以Arctic專案為例，我們不會做任何的商業隱藏。從組織架構上，會以獨立的團隊推進開源，如果有商業轉化會由其他的團隊來推進。”
在釋出會最後，來自華泰證券的大資料流計算技術專家陳豐進行了關於Arctic在金融資料平臺的應用實踐案例分享——幫助公司初步建成了數智中臺實時湖倉，並在業務支撐中取得了預期的效果。
湖倉一體最大應用難點在選型，好的開源氣質是“不隱藏”
1、湖倉一體能解決最核心的問題是什麼，是如何解決的？
馬進：對湖倉一體的概念理解，在國內可能有一些分歧。這個詞最早是阿里提出的，當時提湖倉一體更多是想把MaxCompute和私有化的Hive結合起來，讓使用者私有化的Hive擴充套件到雲端的MaxCompute中來。但我們如今所說的湖倉一體概念更多是指Databricks提出的Lakehouse這樣的概念，它解決的核心問題是基於資料湖的技術，包括雲端的物件儲存，比如亞馬遜的S3，阿里雲的OSS，以及在私有化場景中主要是Hadoop，在這些資料湖的生態之上構建BI、AI和流計算，包括各種應用場景中的工具使用。
湖倉一體要做分層，首先要有對基礎軟體的需求，需要有一套管理系統以及對應的底層技術，能夠讓資料湖滿足我們對各種各樣場景的需求，包括對離線的需求、實時的需求，以及機器學習、特徵計算這些不同應用的需求。
另外，我們可能需要在產品端，針對Lakehouse湖倉一體的技術做一些適配，讓它的整個規範流程能夠用這樣一個底座實現最簡潔的方式。所以回到這個問題，湖倉一體核心的問題其實就是將產品的邊界、方法論的邊界拓展到實時場景、AI場景，形成完整的、對使用者友好和便捷的工具到基礎軟體的生態。
2、湖倉一體在各產業場景中面臨著哪些共通的應用難點，有哪些解決方案？
馬進：我覺得湖倉一體最大的應用難點在於選型，我們現在的湖倉一體選型非常多，有Delta、Iceberg、Hudi等。因為不可能讓資料分析師、演算法工程師、資料科學家們直接操作底層的東西，肯定會有一層產品的包裝，以及相應的工具配套。但是這些做工具的人或者做產品的團隊很難選型，比如選出什麼樣的東西對我來說最合理、最好。
所以我們會發現一個現狀，雖然這個技術方向很熱，但真正把資料湖Format這套技術應用到生產場景中，進而做大規模的推廣其實是非常少的，用一句更加通俗的話說，這屬於“雷聲大雨點小”。所以，最重要的原因是我們現在開源的這些技術功能和產品需求還有很大的距離。
我們推出的開源專案，它的目標或者核心意義在於拉平目前開源Table format與產品之間的距離，我們的定位叫做流式湖倉服務。從概念上就能看出來，並不會基於資料湖重新造一套東西出來。我們更關注怎麼能幫助企業和使用者把這個東西用起來。在這個過程中，比如說存在管理的問題、適配的問題，都會在這一層基礎軟體層解決。
3、剛才我們談到了DataOps，您是怎麼看這個技術的？
馬進：說起DataOps，很多人會說一長串，不管是流程上還是規範上，說明這個概念還比較抽象，所以需要很多的解釋。我個人認為DataOps有點類似於DevOps，更多是給使用者提供一套工具集，讓使用者可以開發資料，同時使用資料的流程變得簡單，這個事情是可以體系化的運作的。
比如，我們最早面向資料分析師的數量是幾個、幾十個，現在大的企業有幾百個資料分析師和資料科學家，這就需要多租戶的能力。我們透過一套DataOps平臺，從資料開發到持續整合，到後續運維，其實有一套方法論。所以，簡單來說，我覺得DataOps就是對這套方法論進一步的抽象，它有進化的過程，最原始是資料開發運維平臺，到後面有資料中臺，可以在平臺層沉澱更多的業務能力，在這後面我們強調業務在持續迭代過程中的敏捷性，就到了DataOps。
4、Arctic有持續自最佳化的能力，具體是怎麼實現的？如果已經用了Delta或者Iceberg，遷移到Arctic需要做什麼準備工作？有什麼需要注意的？
馬進：Arctic的持續自最佳化功能實現涉及兩個方面：一是判斷湖倉表資料發生了哪些變化，要了解使用者新寫進來的資料，尤其是小檔案，會在引擎的connector中提供對接能力，使用者每一次資料提交都會上報到元資料中心，可以實時感知到使用者新寫入了哪些資料。之後，元資料服務後臺會提供一套最佳化器——optimizer排程服務，可以排程一些持續在進展中的程序做小檔案合併，並且我們有整套機制為使用者提供一套最佳最佳化實踐。
至於企業已經用了Delta或者Iceberg，遷移到Arctic需要做哪些工作這個問題，首先我們的架構是開放的，從生態位角度來講可以擁抱Delta，但目前這個工作還沒有做，主要還是面向Iceberg。如果企業已經用了Iceberg，把一張表變成Arctic其實非常方便，後續會在社群中提供相應原地升級方案，使用者只需要透過一個命令，就能把Iceberg表變成Arctic表，並且它同時依然是一張Iceberg表，可以用之前Iceberg表的所有功能。在使用的時候只需要區分它是用Arctic catalog還是Iceberg Catalog訪問，就可以選擇用各自的哪些功能，升級的過程是原地升級，而且只是個元資料的變更，會非常快速。
5、您認為好的開源專案是什麼樣的？Arctic未來會怎麼做開源的建設？
馬進：一個好的開源專案應該是比較純粹，符合開源氣質的專案。可以拿Delta和Iceberg兩個專案來舉例，從我的角度講，Iceberg是非常符合開源氣質的專案，因為它本身早期就是從Netflix內部需求孵化出的專案，然後開源出來給更多企業使用，不會說哪個功能是內部使用不對外開放，或者跟自家的某些功能做深度繫結。
Delta是一個非常優秀的專案，它的理念也非常好，自開源伊始它的理念在整個行業都是很超前的。但從當時開源的狀態來說，並不是非常純粹的開源專案，包括有些功能沒有放在開源社群裡，以及跟Spark深度繫結，有比較強的商業氣息。
從我個人視角來看，一個好的開源專案首先應該符合開源氣質，不管是團隊還是專案本身，不應該有任何隱藏。目標應該通往基金會孵化，貢獻給更多的使用者和開發者，不只是國內，還有國外的使用者。所以，Arctic未來做開源社群建設，我們也會秉承不隱藏的理念，包括和更多的國內外使用者溝通，儘可能把專案推向更高的舞臺。