網易數(shù)帆開源Arctic，lceberg、Hive上增加更多實時場景

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

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

　　近日，網易數(shù)帆舉辦了“企業(yè)級流式湖倉服務Arctic開源發(fā)布會”。發(fā)布會上，詳細介紹了網易數(shù)帆如何理解湖倉一體、Arctic項目的孵化和成型，這一項目可以解決哪些問題、發(fā)揮怎樣的能力、能夠為大數(shù)據(jù)從業(yè)者帶來什么，以及社區(qū)的建設和未來的發(fā)展。

　　產品發(fā)布：開放式架構下的開源流式數(shù)倉平臺

　　在長期服務客戶的過程中，網易數(shù)帆總結出自己的數(shù)據(jù)建設方法論：DataOps、DataFusion，以及DataProduct。發(fā)布會開始，網易數(shù)帆大數(shù)據(jù)產品線總經理余利華就如何在這一方法論之下架構開源流式數(shù)倉平臺，以及如何進行Arctic項目孵化進行了深入分享。

　　在網易數(shù)帆的大數(shù)據(jù)技術體系架構中，最底層是基礎設施，即存儲計算能力架設;底層之上是數(shù)據(jù)研發(fā)層，提供包括數(shù)據(jù)傳輸、實時開發(fā)、離線開發(fā)、數(shù)據(jù)測試、任務發(fā)布、任務運維等能力，覆蓋DataOps整個過程;再往上是數(shù)據(jù)中臺，在這一層，數(shù)據(jù)研發(fā)和治理的一體化、中臺架構解決數(shù)據(jù)孤島，以及設計基于ROI的數(shù)據(jù)資產沉淀方法是主要亮點;數(shù)據(jù)中臺再往上是數(shù)據(jù)產品，可基于無代碼的方式建設場景化的數(shù)據(jù)產品。

　　首先，在技術架構上，該體系最大的特點是開放式，可讓各模塊獨立成為一個項目：存儲單拉出來是HDFS，緩存單拉出來是Alluxio，執(zhí)行引擎和查詢拉出來是Spark、Impala，等等。每個模塊獨立成一個項目，通過松耦合的方式組裝在一起就形成了開放式大數(shù)據(jù)技術體系。這樣的架構好處顯而易見，包括能力全面、生命力強，以及建設成本較低。

　　其次，第二個技術特點是開源，包括采用直接開源的軟件，以及在開源軟件不能滿足的情況下給社區(qū)做Patch。這樣一來不僅能夠被社區(qū)評審和檢驗，公司本身也不用長期維護Patch，降低維護成本。截至目前，網易數(shù)帆在Spark領域累計合入提交了近600多個Patch，同時也培養(yǎng)了一位Spark committer。網易數(shù)帆在整個大數(shù)據(jù)發(fā)展史上，培養(yǎng)了多位Apache的committer。

　　此外，如果社區(qū)確實無法滿足開源需求，才會進行自研開源，比如Kyuubi。這個項目在立項時，開放式架構的其他層有Spark、Impala、Parquet等開源技術可選，但是缺少統(tǒng)一的多租戶安全的SQL網關，因此Kyuubi誕生。目前這個項目已進入Apache孵化，并在阿里云、騰訊云、中國移動、小米等公司落地，有17位committer和83位貢獻者。

　　當然，在建設中臺的過程中，也面臨不小的挑戰(zhàn)。首先，是技術不統(tǒng)一，實時技術和離線技術采用兩套技術棧，帶來的問題是整個系統(tǒng)的運維復雜，同時存儲冗余也浪費成本;其次，研發(fā)體系的割裂讓成本增加。此外，應用開發(fā)也十分復雜，將實時表和離線表通過兩種存儲方式存儲，不僅增加了用戶理解困難度，冗余數(shù)據(jù)也帶來了數(shù)據(jù)口徑的指標二義性問題。

　　在余利華看來，以上問題的解決核心在于提供流式數(shù)倉平臺，把實時表和離線表相結合，一張表既可以支持流式消費、流式寫入，也要支持批量查詢和更新。

　　在基于數(shù)據(jù)湖的開放式架構中，從下到上分別是文件系統(tǒng)層，實現(xiàn)數(shù)據(jù)的存儲和訪問;文件格式，定義文件和數(shù)據(jù)之間的關系;表格式層，定義文件與表之間的邏輯關系;最上層是接口，是以SQL的方式統(tǒng)一訪問的入口。

　　如果要支持流式數(shù)倉，需要在表格式層動點“小手術”，引入Iceberg、Delta等新型表格式。新型表格式解決了數(shù)據(jù)更新、大表訪問性能、數(shù)據(jù)增量消費等問題，但是仍然遺留了不少問題。余利華舉了三個例子：第一是小文件問題，頻繁數(shù)據(jù)寫入，帶來很多小文件，導致查詢性能很差，有時候性能會下降一半; 第二是兼容性問題，是否能兼容目前最主流的HIVE格式，簡化應用推廣，是否能兼容Iceberg/Delta等格式，數(shù)據(jù)中臺還是那個數(shù)據(jù)中臺，我們只是多了選擇表格式的自由; 第三是流式更新問題，Iceberg、Delta表格式流式更新能力較弱， 用在數(shù)據(jù)庫到大數(shù)據(jù)實時同步場景性能有所不足， 短期內需要做一些增強。

　　為對以上問題進行針對性解決，網易數(shù)帆和華泰證券一起研發(fā)了企業(yè)級的流式湖倉服務Arctic，并將其開源。

　　Arctic技術架構：實現(xiàn)開箱即用的元數(shù)據(jù)服務

　　據(jù)網易數(shù)帆大數(shù)據(jù)實時計算技術專家、湖倉一體項目負責人馬進介紹，公司自2020年開始關注數(shù)據(jù)湖新技術便聚焦于構建流批一體和湖倉一體的架構。最初想要采用Flink+Iceberg，但在真實場景應用時發(fā)現(xiàn)過多問題，因而進行了自主設計，便是Arctic的雛形。

　　也是從2020年開始，Hudi和Iceberg進入不少開發(fā)者的視野，隨著它們從Apache孵化到畢業(yè)，Table format的概念逐漸被更多人接受。首先，Table format定義了哪些文件可以構成一張表，像Flink、Spark、Trino、Impala，任何引擎都可以根據(jù)Table format去查詢檢索數(shù)據(jù);其次，Table format規(guī)范了數(shù)據(jù)和文件的分布方式，任何引擎寫入數(shù)據(jù)都要遵照這個標準。

　　事實上，在有了Table format之后，可以基于數(shù)據(jù)湖來實現(xiàn)類似于消息隊列的功能，數(shù)據(jù)延遲會從毫秒或者秒級降級為分鐘級別，像實時更新、讀時合并。行業(yè)內很多公司推廣數(shù)據(jù)湖的主要場景時，主要以實時更新以及讀時合并平替如Kudu、Doris、Greenplum這些支持更新的數(shù)倉系統(tǒng)。

　　進一步，在企業(yè)需要怎樣的數(shù)據(jù)湖這個問題上，有三點值得注意：首先，如果只關注數(shù)據(jù)湖Table Format個別中間功能，推廣起來會比較困難;其次，當用數(shù)據(jù)湖做消息隊列時，可能引入很多小文件，小文件的管理需要保持關注;最后，還有一個隱形的問題——成本分攤，以前消息隊列的成本由業(yè)務團隊承擔，現(xiàn)在用一個公共的數(shù)據(jù)湖底座，成本的合理分攤也需要注意。

　　因為存在以上問題，業(yè)內很多公司在是否使用數(shù)據(jù)庫新技術作為替代解決方案這個問題上都比較糾結。那么，Lakehouse技術如何給企業(yè)帶來更大價值?

　　在馬進看來，應用場景一般期望在數(shù)據(jù)中臺層、方法論層可以使用一套規(guī)范或流程把實時和離線，以及更多的AI場景統(tǒng)一起來。而Lakehouse這個概念創(chuàng)造出來的意義，就是拓展產品的邊界，讓數(shù)據(jù)湖能更多的服務于流的場景和AI的場景，他表示：“Lakehouse，或者說湖倉一體給業(yè)務終端帶來的是體系上的收益，而不在于對某個功能的使用。”

　　為了實現(xiàn)這樣的效果，Arctic在lceberg和Hive之上增加了更多實時場景的能力，面向DataOps提供開箱即用的元數(shù)據(jù)服務，讓數(shù)據(jù)湖更加合用和實用。

　　具體來說，Arctic包含兩個核心組件：元數(shù)據(jù)服務AMS，在系統(tǒng)中的定位是下一代HMS的角色;以及包含了整套optimizer的組件和機制，可以實現(xiàn)持續(xù)的后臺數(shù)據(jù)自優(yōu)化。

　　具體到架構和組件的設置，在數(shù)據(jù)湖層包括change files、base files，分別對應changestore和basestore;上層則設置了一個AMS，是三元組的元數(shù)據(jù)中心，支持和HMS做同步。同時，AMS會提供事務和沖突解決API;在Optimizer層，有一整套完整的擴展機制和管理機制，包括Optimizer container和Optimize group。此外，在Arctic架構中匹配了單獨的管理界面Dashboard，提升湖倉本身的管理體驗。而在Table format的兼容性設定上，主要提供兩種方案，其一是Iceberg，包括basestore、changestore都是獨立的Iceberg表，均可兼容到Iceberg的V2版本;其二是Hive的兼容模式，如果用戶使用的是Hive formate兼容，它的change數(shù)據(jù)還是存在Iceberg里面。

　　談及做開源的初衷，馬進表示說：“過去我們做開源可能缺少統(tǒng)一的步調，去年領導層也下定決心，明確了未來做開源會以更加專注的方式。以Arctic項目為例，我們不會做任何的商業(yè)隱藏。從組織架構上，會以獨立的團隊推進開源，如果有商業(yè)轉化會由其他的團隊來推進。”

　　在發(fā)布會最后，來自華泰證券的大數(shù)據(jù)流計算技術專家陳豐進行了關于Arctic在金融數(shù)據(jù)平臺的應用實踐案例分享——幫助公司初步建成了數(shù)智中臺實時湖倉，并在業(yè)務支撐中取得了預期的效果。

　　湖倉一體最大應用難點在選型，好的開源氣質是“不隱藏”

　　1、湖倉一體能解決最核心的問題是什么，是如何解決的?

　　馬進：對湖倉一體的概念理解，在國內可能有一些分歧。這個詞最早是阿里提出的，當時提湖倉一體更多是想把MaxCompute和私有化的Hive結合起來，讓用戶私有化的Hive擴展到云端的MaxCompute中來。但我們如今所說的湖倉一體概念更多是指Databricks提出的Lakehouse這樣的概念，它解決的核心問題是基于數(shù)據(jù)湖的技術，包括云端的對象存儲，比如亞馬遜的S3，阿里云的OSS，以及在私有化場景中主要是Hadoop，在這些數(shù)據(jù)湖的生態(tài)之上構建BI、AI和流計算，包括各種應用場景中的工具使用。

　　湖倉一體要做分層，首先要有對基礎軟件的需求，需要有一套管理系統(tǒng)以及對應的底層技術，能夠讓數(shù)據(jù)湖滿足我們對各種各樣場景的需求，包括對離線的需求、實時的需求，以及機器學習、特征計算這些不同應用的需求。

　　另外，我們可能需要在產品端，針對Lakehouse湖倉一體的技術做一些適配，讓它的整個規(guī)范流程能夠用這樣一個底座實現(xiàn)最簡潔的方式。所以回到這個問題，湖倉一體核心的問題其實就是將產品的邊界、方法論的邊界拓展到實時場景、AI場景，形成完整的、對用戶友好和便捷的工具到基礎軟件的生態(tài)。

　　2、湖倉一體在各產業(yè)場景中面臨著哪些共通的應用難點，有哪些解決方案?

　　馬進：我覺得湖倉一體最大的應用難點在于選型，我們現(xiàn)在的湖倉一體選型非常多，有Delta、Iceberg、Hudi等。因為不可能讓數(shù)據(jù)分析師、算法工程師、數(shù)據(jù)科學家們直接操作底層的東西，肯定會有一層產品的包裝，以及相應的工具配套。但是這些做工具的人或者做產品的團隊很難選型，比如選出什么樣的東西對我來說最合理、最好。

　　所以我們會發(fā)現(xiàn)一個現(xiàn)狀，雖然這個技術方向很熱，但真正把數(shù)據(jù)湖Format這套技術應用到生產場景中，進而做大規(guī)模的推廣其實是非常少的，用一句更加通俗的話說，這屬于“雷聲大雨點小”。所以，最重要的原因是我們現(xiàn)在開源的這些技術功能和產品需求還有很大的距離。

　　我們推出的開源項目，它的目標或者核心意義在于拉平目前開源Table format與產品之間的距離，我們的定位叫做流式湖倉服務。從概念上就能看出來，并不會基于數(shù)據(jù)湖重新造一套東西出來。我們更關注怎么能幫助企業(yè)和用戶把這個東西用起來。在這個過程中，比如說存在管理的問題、適配的問題，都會在這一層基礎軟件層解決。

　　3、剛才我們談到了DataOps，您是怎么看這個技術的?

　　馬進：說起DataOps，很多人會說一長串，不管是流程上還是規(guī)范上，說明這個概念還比較抽象，所以需要很多的解釋。我個人認為DataOps有點類似于DevOps，更多是給用戶提供一套工具集，讓用戶可以開發(fā)數(shù)據(jù)，同時使用數(shù)據(jù)的流程變得簡單，這個事情是可以體系化的運作的。

　　比如，我們最早面向數(shù)據(jù)分析師的數(shù)量是幾個、幾十個，現(xiàn)在大的企業(yè)有幾百個數(shù)據(jù)分析師和數(shù)據(jù)科學家，這就需要多租戶的能力。我們通過一套DataOps平臺，從數(shù)據(jù)開發(fā)到持續(xù)集成，到后續(xù)運維，其實有一套方法論。所以，簡單來說，我覺得DataOps就是對這套方法論進一步的抽象，它有進化的過程，最原始是數(shù)據(jù)開發(fā)運維平臺，到后面有數(shù)據(jù)中臺，可以在平臺層沉淀更多的業(yè)務能力，在這后面我們強調業(yè)務在持續(xù)迭代過程中的敏捷性，就到了DataOps。

　　4、Arctic有持續(xù)自優(yōu)化的能力，具體是怎么實現(xiàn)的?如果已經用了Delta或者Iceberg，遷移到Arctic需要做什么準備工作?有什么需要注意的?

　　馬進：Arctic的持續(xù)自優(yōu)化功能實現(xiàn)涉及兩個方面：一是判斷湖倉表數(shù)據(jù)發(fā)生了哪些變化，要了解用戶新寫進來的數(shù)據(jù)，尤其是小文件，會在引擎的connector中提供對接能力，用戶每一次數(shù)據(jù)提交都會上報到元數(shù)據(jù)中心，可以實時感知到用戶新寫入了哪些數(shù)據(jù)。之后，元數(shù)據(jù)服務后臺會提供一套優(yōu)化器——optimizer調度服務，可以調度一些持續(xù)在進展中的進程做小文件合并，并且我們有整套機制為用戶提供一套最佳優(yōu)化實踐。

　　至于企業(yè)已經用了Delta或者Iceberg，遷移到Arctic需要做哪些工作這個問題，首先我們的架構是開放的，從生態(tài)位角度來講可以擁抱Delta，但目前這個工作還沒有做，主要還是面向Iceberg。如果企業(yè)已經用了Iceberg，把一張表變成Arctic其實非常方便，后續(xù)會在社區(qū)中提供相應原地升級方案，用戶只需要通過一個命令，就能把Iceberg表變成Arctic表，并且它同時依然是一張Iceberg表，可以用之前Iceberg表的所有功能。在使用的時候只需要區(qū)分它是用Arctic catalog還是Iceberg Catalog訪問，就可以選擇用各自的哪些功能，升級的過程是原地升級，而且只是個元數(shù)據(jù)的變更，會非�？焖佟�

　　5、您認為好的開源項目是什么樣的?Arctic未來會怎么做開源的建設?

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

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

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