湖倉一體，可以提供數據湖的開放格式、低成本存儲，以及強大的管理能力。數據分析、機器學習、實時計算、音視頻檢索等都可以從“湖”里汲取數據，從而讓數據治理更加便捷高效。

　　在傳統行業數字化轉型過程中，尤其像在金融行業，全域數據統一管理、集中開發和融合共享是必然趨勢，這是時下湖倉一體被寄予厚望的重要原因。那么，如何架構經過驗證的湖倉一體解決方案，并推動它很好的演進?

　　近日，網易數帆舉辦了“企業級流式湖倉服務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未來會怎么做開源的建設?

　　馬進：一個好的開源項目應該是比較純粹，符合開源氣質的項目�？梢阅肈elta和Iceberg兩個項目來舉例，從我的角度講，Iceberg是非常符合開源氣質的項目，因為它本身早期就是從Netflix內部需求孵化出的項目，然后開源出來給更多企業使用，不會說哪個功能是內部使用不對外開放，或者跟自家的某些功能做深度綁定。

　　Delta是一個非常優秀的項目，它的理念也非常好，自開源伊始它的理念在整個行業都是很超前的。但從當時開源的狀態來說，并不是非常純粹的開源項目，包括有些功能沒有放在開源社區里，以及跟Spark深度綁定，有比較強的商業氣息。

　　從我個人視角來看，一個好的開源項目首先應該符合開源氣質，不管是團隊還是項目本身，不應該有任何隱藏。目標應該通往基金會孵化，貢獻給更多的用戶和開發者，不只是國內，還有國外的用戶。所以，Arctic未來做開源社區建設，我們也會秉承不隱藏的理念，包括和更多的國內外用戶溝通，盡可能把項目推向更高的舞臺。