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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　湖倉一體最大應(yīng)用難點在選型，好的開源氣質(zhì)是“不隱藏”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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