萬字長文詳解開源流式湖倉服務Arctic

語言: CN / TW / HK

本文根據作者於Arctic開源釋出會演講內容整理(略有刪減),系統解讀Arctic專案研發初衷、生態定位、核心特性、效能表現及未來規劃。

首先感謝大家參與我們Arctic開源釋出會。我是馬進,網易數帆實時計算和湖倉一體團隊負責人。我們在2020年開始關注資料湖新的技術,並用它來構建流批一體、湖倉一體的架構。最早我們使用Flink+Iceberg,但是實踐過程中發現這個架構距離生產場景還有很大的gap,所以有了Arctic專案 (github.com/NetEase/arctic)

資料湖 Table format 之爭

先看目前Apache Hudi、Apache Iceberg、Delta這幾個主流的開源Table format(表格式)的選型。

Table format這個概念最早由Iceberg提出,現在行業對它的理解主要有兩點。第一點是Table format定義了哪些檔案可以構成一張表,這樣Apache Flink、Apache Spark、Trino、Apache Impala等任何引擎都可以根據Table format去查詢、檢索資料。第二點就是Table format規範了資料和檔案的分佈方式,任何引擎寫入資料都要遵照這個標準,通過format定義的標準來支援以前Hive不支援的ACID和模式演進。我們看到Iceberg、Delta和Hudi在這些功能上基本上是拉平的,雖然他們在各自實現上有很大不同,但抽象他們的共性個人認為是非常有意義的事情。

拿目前主流的資料湖Table format和Hive進行對比,Hive簡單定義了表和HDFS上靜態目錄的對映關係,它本身是沒有ACID的保障的,我們在真實的生產場景中只能單讀單寫。目前我們上層的 資料中臺或者是DataOps平臺能夠通過工作流的方式保障我們能正確使用Hive,當然只能用於離線場景

新的Iceberg、Delta、Hudi所主導的Table format能力中,增加了一個 快照 的概念,表的元資料不再是一個簡單的表和檔案的關係,變成了表和快照以及快照和檔案的關係,資料的每次寫入會產生新的快照,而這個快照和檔案產生一個動態的對映關係,這樣它能實現每次寫入ACID的保障,也能通過快照的隔離實現使用者的多讀多寫。而且基於快照也能給上層提供一些比較有意思的功能,比如說可以基於快照的增量寫入實現增量讀,也就是CDC的功能,可以通過快照去支援回溯,例如我們在time travel或者資料的rollback。

總結下來Table format有四點核心特性。

第一,結構自由。 像之前的Hive只能支援簡單的加列操作,而在Delta、Iceberg這樣的Table format之上使用者可以自由地更改表的結構,可以加列、減列、改列,而且對資料的遷移和變更不會有要求。

第二,讀寫自由。 因為它通過快照能夠保證資料的ACID,任何實時、離線以及AI的需求都可以自由地往這個表裡面寫資料或者讀資料。

第三,流批同源。 因為Table format核心的一個功能是可以很好地支援流場景,我們的批和流都可以往新的Table format去寫和讀。

第四,引擎平權。 這點非常重要,它不能只是繫結某一個引擎,比如說像Delta在1.0時代是Spark生態中的一個元件,在一個月之前Delta2.0的釋出再次向我們證明了去適配多個引擎的重要性。

在Table format這些專案的官網中,他們會主推一些功能主要包含CDC、SQL擴充套件,資料的Rollback,以及time travel,模式演進(Schema evolution)以及我們經常說的流式更新(Upsert)、讀時合併(merge-on-read)的功能。

CDC一定程度上能起到平替訊息佇列的作用,比如說在生產場景中,實時計算主要會用Kafka或者Pulsar做流表的選型。有了Table format之後,我們可以基於資料湖來實現類似於訊息佇列的功能,當然它的資料延遲會從毫秒或者秒級降級為分鐘級別。像Upsert、讀時合併和行業內或者說很多公司去推廣資料湖的主要場景,就是拿這個實時更新以及讀時合併去平替Apache Kudu、Doris、Greenplum這些實時更新的數倉系統。

企業需要怎樣的資料湖

首先一點是 如果我們只是關注資料湖Table format中個別的功能,推廣起來是非常困難的 。比如說資料湖的CDC功能,確實在某種程度上能夠平替訊息佇列,但是也會引入一些其他的問題:首先是延遲的問題;其次是用資料湖做訊息佇列可能會引入很多小檔案,這個小檔案誰來管理?還有第三個是比較隱形的問題,以前訊息佇列的成本就是掛在業務團隊那邊,如果我們現在用一個公共的資料湖底座,這個成本該怎麼分攤?

在過去兩年中,我們跟行業內很多公司交流,大體上都是在這樣一種矛盾之中掙扎,想用資料湖的新技術來替代一些其他方案,對業務的吸引力是非常不足的。我們的資料湖或者Lakehouse(湖倉一體)的技術究竟能給企業帶來怎樣的價值?

在我們的生產場景中,我們的整個資料平臺體系在2020年遇到最主要的問題,就是流批平臺割裂。大家知道我們圍繞Hive這套離線數倉已經產生了非常豐富的方法論,從資料模型、資料資產到資料質量,基於資料湖的開放架構我們產生了非常好的一套規範、標準以及治理體系。

但是我們把目光切換到實時場景下,目前主要用Flink做實時計算,用Kafka作為流表的選型,當我們做流表join時可能單獨需要從資料庫那邊拉一個實時同步的任務,後面如果我們做資料分析,需要比較高的資料新鮮度,需要引入Kudu或者Doris這些能夠準實時或者實時更新的數倉系統。

這套東西和我們離線整套的技術選型以及工具是非常割裂的,而且沒有形成比較好的規範,主要還是點對點的開發為主。

舉個例子,如果我們既要做實時也要做離線,就需要拉兩套鏈路。離線的鏈路根據我們整套方法論,根據離線整個流程的工作流,是能比較容易規範地定義出一套出來。實時場景下我們更多需要開發者,需要使用者自己去了解Flink怎麼玩兒,Kafka怎麼讀,這個過程中序列化、反序列化怎麼做,怎麼在Kudu上建表,這一套規範給使用者帶來了非常大的負擔。

尤其是AI的一些業務,他們要做資料生產,其實更加關注資料訓練、樣本這些跟AI相關的流程本身,對HBase、KV這些他們是一概不瞭解的,所以他們會把需求提到另外一個團隊,而另外一個團隊只能點對點地去響應。

總結一下傳統Lambda架構給我們帶來哪些弊端。

第一是資料孤島的問題。 如果我們使用Kudu或者其他跟資料湖割裂的一套數倉方案,會帶來獨立的採購和部署成本,會因為容易儲存而浪費成本。因為資料之間難以複用和互通,如果我們在相同的業務場景下需要一個實時的數倉,可能需要從源頭重新拉一份資料出來,導致成本和人效的浪費。

第二是研發人效低,研發體系割裂,研發規範不通用。 這在AI特徵、推薦的場景比較典型,需要使用者自己去搞定什麼時候呼叫實時的東西,什麼時候呼叫離線的東西,會導致整個業務層非常複雜。

最後是指標和語義的二義性問題。 比如過去幾年我們主要是使用Kudu作為實時數倉方案,使用者需要自己在Kudu裡面建一個數倉表,會有Kudu的一套Schema,在Hive這邊有一套通過資料模型建立的表,而這兩套東西都需要使用者自己去維護。當業務邏輯發生變更的時候,使用者可能改了Hive但是沒有改Kudu的,長久下來就會導致指標和語義的二義性問題。而且隨著時間的推移,維護的成本會越來越高。

所以業務期望的是什麼呢?其實是我們在平臺層,在整個資料中臺層或者在整套資料的方法論這一層,能夠用一套規範、一套流程把實時和離線,以及AI等更多的場景統一。所以我們回過頭來看 Lakehouse這個概念創造出來的意義,就是拓展產品的邊界,讓資料湖能更多地服務於流的場景、AI的場景

在我們的生產場景中, Lakehouse給業務最終帶來的應當也是一個體繫上的收益,而不在於說某一個功能上用了它 。比如說我在CDC或者在分析的場景下用了,但是如果使用者只是單純地去比較Kudu和Hudi或者Iceberg之間的差異,他可能很難說到底帶來什麼樣的收益;但是如果我們告訴使用者說整套平臺可以即插即用地把離線和實時全部統一掉,這個收益就很大了。基於這樣一個目標,我們開發了流式湖倉服務Arctic這樣一套系統。

理解Arctic流式湖倉服務

Arctic是什麼呢?簡單來說Arctic是由網易數帆開源的流式湖倉系統(Streaming LakeHouse Service),它在lceberg和Hive之上增加了更多實時場景的能力,所以 Arctic首先強調的是實時場景的能力,並且面向DataOps提供開箱即用的元資料服務,而且讓資料湖更加好用和實用 。我們用一句話概括會比較抽象,後面我們會用更多功能的舉例以及我們一些乾貨上的分享,讓大家深入理解Arctic到底是什麼。

生態位差異

首先我們通過這張圖強調生態位的差異, Arctic從生態位上在Table format之上 ,所以嚴格意義上說我們不應該把Arctic當成是另外一套Iceberg或者另外一套Table format。

另外一點,我們在Table format之上,主要考慮跟開源的Table format做相容,所以 Arctic的一個核心目標是幫助企業用好資料湖的Table format,以及解決或者拉平在Table format以及使用者,或者說產品真實的需求之間的gap

Arctic本身包含兩個核心元件,第一個是元資料服務AMS,它在我們系統中定位是下一代HMS的角色。第二個,我們持續自優化的功能,會有整套optimizer元件和機制,來實現後臺資料優化。

Tablestore 設計與優勢

我們之前和很多使用者聊過Arctic,大部分使用者的第一個問題是我們跟開源的Iceberg具體是什麼關係。通過這張圖我想來說明這點。首先 在Arctic中有Tablestore這個概念,Tablestore是一個儲存單元的定位 ,有點類似於傳統資料庫裡面聚簇索引的概念。當流式寫入的時候,我們會用一個change的Tablestore儲存一個CDC寫入的資料,這個資料有點類似於我們資料庫中的binlog或者relog,後面這個change table可以用於CDC的回放,也可以當作一個單獨的表來訪問。

Hudi、Iceberg也有upsert的功能,但2020年我們開始做這個事情的時候Iceberg還沒有這個功能,社群出於對 manifest 這層設計的嚴謹考量在實現上會有一些妥協,所以最終我們決定了在上層去做這個事,並且會體現我們的一些優勢。

Change表主要儲存的是CDC的change資料,另外還有一套Basestore會儲存我們的存量資料,兩個Tablestore其實是兩張獨立的Iceberg表。另外我們還可選的整合Kafka的logstore,也就是說我們的 資料可以雙寫 ,一部分先寫到Kafka裡面,再寫進資料湖裡,這樣實現了流表和批表的統一。

這樣設計有什麼樣的優勢?首先change表裡的 CDC資料可以按順序回放 ,會解決Iceberg原生的V2 CDC不太好回放的問題。

第二個是 change表可以開放訪問 。在很多電商、物流的場景裡change資料不光是作為一個表內建的資料用,很多時候訂單表、物流表的變更資料也會作為獨立的數倉表來用,我們通過這樣的設計允許把change表單獨拎出來用,當然會新增一些寫入保護。如果未來業務有一些定製化需求,比如說在change表中額外新增一些欄位,新增一些業務自己的UDF的計算邏輯,這個設計也具備這樣的可能。

第三點我們這套設計理念change和base之間的轉化,這個過程是optimize。這個概念在Delta、Iceberg和Hudi中都有介紹過,它的核心是做一些小檔案合併, 我們把change資料到base資料的轉換也納入optimize的範疇,並且這些過程對使用者來說是透明的 ,如果使用者直接用Iceberg或者Delta,所有的optimize操作在底層都會有一個快照,這樣對使用者是不友好的,我們在上層把這套東西封裝起來了。當用戶讀一個高新鮮度的資料做分析時,我們的引擎端會做一個change和base的merge-on-read。

Arctic 架構和元件

理解了Tablestore的概念之後再來看Arctic的架構和元件,我們就會更加容易理解。在資料湖這一層我們有change files、base files,分別對應changestore和basestore。Tablestore的概念不僅可以用於CDC的場景,未來對於一些排序,對於ZOrder一些具體的需求同樣可以採用上層架設獨立的Tablestore來解決。

在上層我們有一個前面介紹過的AMS( Arctic Meta Service ), AMS是Arctic流式湖倉服務中“服務”這一層所重點強調的元件,是面向三元組的元資料中心

三元組是什麼呢?就是catalog.table.db這樣的三元組,大家知道在Spark 3.0和Flink 1.2之後,主推的是multi catalog這樣的功能,它可以適配不同的資料來源。目前我們在主流的大資料實踐中更多的是把HMS當作元資料中心來使用,HMS是二元組的結構,如果我們想擴充套件,把HMS裡面根據更多的資料來源,需要做很多定製性的工作。比如說網易數帆有數平臺其實是在HMS之外單獨做了一個元資料中心,來管理三元組和資料來源的關係,AMS本身就是面向三元組設計的元資料服務。

第二個我們的 AMS可以和HMS做同步 ,就是我們的Schema可以存在HMS裡面,除了Hive所能夠儲存的一些欄位資訊外,一些額外的元件資訊,一些額外的properties會存在AMS中,這樣AMS可以和HMS一起提供服務,所以業務不用擔心在使用Arctic的時候一定要做一個替換,這其實是一個很灰度的過程。

第三個是 AMS會提供事務和衝突解決的API

在optimizer這兒,我們有一整套完整的擴充套件機制和管理機制。首先我們有一個 optimizer container的概念,本質上是平臺排程任務的元件 ,我們整個後臺的optimize過程對業務來說是透明的,後臺需要有一套排程服務,能夠把optimize的程序排程到一個平臺中(比如YARN上、K8s),這種不同的模式就是optimizer container的概念,未來使用者也可以通過container介面去擴充套件它的排程框架。

optimizer group是在container內部做資源隔離 ,比如說使用者覺得有一些表的optimize需要高優先順序執行,可以給他抽出一個獨立的optimizer group執行他的優化任務。

第三點在我們架構中有單獨的Dashboard,也是我們的一個管理介面,我們非常注重湖倉本身的管理體驗。

最後一點也是非常重要的,剛才提過我們有 Table format完全相容 的特性。目前提供兩種,一個是Iceberg,因為我們是基於Iceberg來做的,basestore、changestore都是獨立的Iceberg表,並且我們的相容是隨著Iceberg的迭代持續推進的,目前已經相容Iceberg V2。

另外我們也有Hive相容的模式,能讓業務在不用改程式碼的前提下,直接使用Arctic的一些主要功能,如果使用者使用的是Hive format相容,它的change資料還是存在Iceberg裡面的。

管理功能

之前有提到Arctic非常注重管理體驗,尤其對於我們後臺持續優化的管理,有一套功能以及相對應的度量和標定的能力提供給大家。下圖中所展現的,哪些表正在optimizing用到的資源、持續的時間,未來應該怎樣做一個更合理的資源排程,通過我們的管理功能都會給到大家。

我們的table service的功能,對於表有很多元資料的資訊,包括每張表動態的變更,一些DDL的歷史資訊,事務的資訊,都會在表服務中體現。

併發衝突解決

當我們採用了Table format去解決流批同源場景的時候,舉個例子,比如下圖上半部分,我們在做一個數據的CDC同步,正常情況下是一個Flink任務去做持續的同步,但是如果我們想做資料回滾或者要做資料更正,比如說添加了一列,這一列有個預設值,需要我們通過批的方式把數值初始化一下,會起一個Spark任務和Flink同步去跑。這個時候如果Saprk任務和Flink任務操作到了同一行資料,這個資料的主鍵是一樣的,就會遇到資料衝突的問題。

現在在Table format這一層普遍提供的是樂觀併發控制的語義,當我們出現衝突的時候首先想到的是讓某一個提交失敗,換句話說,樂觀併發控制的語義核心的一點是不允許併發出現,那麼在我們這個場景裡Spark任務可能永遠提交不成功的,因為我們對它的期待是做全部的資料重寫,這樣它的資料範疇是一定會和我們的實時資料衝突的。但業務肯定希望他的資料能夠提交成功,所以我們提供了併發衝突解決的機制,讓這個資料能夠提交成功,並且同時保障它依然具有事務一致性的語義。

下半部分也是類似的,我們對一個數倉表、湖倉表進行了ad-hoc併發的更新c1和c2,c1在c2之後提交,但是c1在c2之前開始,當它們出現衝突之後是c1覆蓋c2,還是c2覆蓋c1?從目前資料湖方案來說,一般是誰後提交以誰為準,但是在更多的生產場景中我們需要誰先開始以誰為準。這一塊時間關係就不展開,有任何疑問可以在使用者群裡與我們深入交流。

Arctic auto bucketing

在效能方面Arctic也做了很多工作,我們目前是基於Iceberg的,Iceberg是非常靈活開放的Table format,它在partition之下沒有考慮我的資料以及我的資料對應的更新,應該怎樣更好地做對映來提升它的效能。

在Iceberg之上我們做了 auto bucketing 的功能,這個功能跟Hudi中file_group的概念有些類似。不同的是我們沒有給使用者暴露file_group或者file_index這樣的概念。我們在檔案之上提供了分組的功能,是一種可擴充套件的方式,通過二叉樹的擴充套件方式讓每一個節點的資料量儘可能維持在使用者配置的大小。比如說Iceberg預設配置128兆,我們通過後臺的一整optimizing套機制,會盡可能維護每個node的大小向128兆靠攏。

當一個node資料超過這個範疇之後,我們會嘗試把它分裂,之前也提到我們分了changestore和basestore,它們都是按照同樣的方式管理,這樣在每一個節點之上可以對應到change資料和base的資料,就能實現更精細的資料對映,資料分析的效能會有一個非常好的提升。

可以看到在 merge-on-read 的過程也可以用到整套機制。2000年左右伯克利有一篇論文專門描述這種方案,感興趣的同學也可以自己去了解。

Arctic效能測試

流式湖倉,或者在資料湖上做實時流式數倉的整套實踐,目前還沒有非常好的benchmark工具來定義它的效能怎麼樣。對這個問題我們也做了很多考慮和探索,目前我們的方案和HTAP benchmark採用的思路是一致的,根據TiDB的介紹,找到行業裡很早就有的CHbenchmark這個概念加以改造。

CHbenchmark支援一個數據庫既跑TPC-C也跑TPC-H。從下圖左邊可以看到,有6張表是重合的,既在TPC-C中跑也在TPC-H中跑,有3張表是在TPC-C中引用,3張表只在TPC-H中引用。

基於這套方案我們做了一個改造,首先用TPC-C跑資料庫,在下面我們再跑一個Flink CDC任務,把資料庫實時流式地同步到Arctic資料湖中,用Arctic資料湖構建一個分鐘級別資料新鮮度的流式湖倉,在這之上我們再跑CHbenchmark中TPC-H的部分,這樣能得到比較標準的流式湖倉的資料分析的效能。

針對optimize前後的Arctic、Iceberg和Hudi測試的結果(Trino下測試),我們按階段做了一個簡單的對比,分為0-30分鐘、30-60、60-90分鐘和90-120分鐘四組。下圖藍色的部分是沒有optimize的資料分析的效能,從0-30分鐘,到最後的90-120分鐘,延遲從20秒降低到了40多秒,降低了一半多。而黃色部分有持續合併的Arctic,效能穩定在20秒左右。

灰色的是原生的Iceberg upsert方案,0-30分鐘是在30秒左右,從30-60分鐘效能是急劇下降的。為什麼Iceberg出現了這麼大的效能滑坡呢?因為原生Iceberg確實沒有insert資料和delete資料的精細化的對映,所以當我們持續寫入流式檔案之後,每一個insert file都會跟delete file產生非常多的關聯,從而導致我們在Trino中做merge-on-read的效能急劇下降。後面測60-90分鐘、90-120分鐘就直接OOM,跑不出來了。

黃色部分是Hudi。目前來看Arctic和Hudi一樣,通過後臺優化能夠保證資料分析的效能,維持在一個比較平穩的數字。目前來看我們通過上層的優化,比Hudi要好一些。後續我們也會在官網中把我們整個測試流程和相關配置向大家公開。

Arctic 目前看 mor 效能相比 Hudi 有一定優勢,這裡我們先不強調Arctic 做得有多好我們也研究了Hudi,它有RO和RT兩種模式,前者是隻會讀合併資料,RT模式是merge-on-read的一種模式。它的RO模式和RT模式效能差距非常大,所以未來可能會有很大的優化空間。

Arctic roadmap 與總結

最後我們對Arctic roadmap以及整個系統做個簡單的總結。Arctic是一個流式湖倉服務,提供分別對應streaming、lakehouse、service的核心特性。

streaming層面我們提供了主鍵的高效流式更新,我們有資料自分桶、結構自由化的能力,Spark、Trino merge-on-read的功能,提供分鐘級別新鮮度的資料分析。

在lakehouse層面我們做到格式的相容,百分之百相容lceberg和Hive的表格式語法,如果有一些功能是Arctic沒有而Iceberg有的,使用者只需要切換到Iceberg catalog,就能夠把一張Arctic表當作Iceberg表來使用,並且我們提供了base和change兩個表的訪問方式。

引擎平權支援Spark和Flink讀寫資料,支援Trino和Impala查詢資料,目前Impala主要是用到Hive的相容特性,可以把Arctic表作為一個Hive做查詢,從而支援Impala。

在service這一塊主要強調管理上的功能:

第一個是支援將資料湖和訊息佇列封裝成統一的表,實現流批表的統一,這樣使用者使用Arctic表不用擔心從秒級或者毫秒級降低到分鐘級別,他依然可以使用資料湖提供毫秒或者秒級的資料延遲的能力。

第二點提供流式湖倉標準化度量,dashboard和相關的管理工具。

第三點是解決併發寫入衝突,實現事務一致性語義。

在管理層面我們聚焦回答下面這幾個問題,這些工作還有很長的路要走。

第一個是表的實時性怎麼量化,比如說我們搭建一個流式的湖倉表之後,當前的新鮮度是一分鐘、兩分鐘還是多少,是否達到了使用者的預期。

第二個怎樣在時效性、成本、效能之間給使用者提供trade off方案。

第三個查詢效能有多少優化空間,需要投入多大的資源做這樣的事情。

第四點資料優化的資源該怎樣量化,怎樣最大化利用這些資源。如果使用者深入瞭解Arctic,會發現我們optimizing跟目前Hudi其他的有很大不同,首先我們optimizing是在平臺層面排程的,不是在每一個寫入的任務裡做的,這樣我們可以集中化管理這些資料優化的資源,並且可以提供最快的迭代。比如我們發現通過一些優化能夠讓合併效率有很大的提升,就可以很快迭代。

最後一點是怎樣靈活分配資源,為高優先順序來排程資源。

在未來Core feature維度的工作,首先我們關注的是 不依賴外部KV實現Flink lookup join功能 。我們之前看到的一個架構裡,如果在實時場景下做一個維表join,可能需要一個外部的KV做同步,目前我們在做這樣的方案,就是不需要做外部的同步了,可以直接基於Arctic表來做維表join。

第二個是 流式更新部分列 ,現在我們主要是通過CDC來做streaming upsert,很多場景,比如特徵、大寬表,我們可能需要能夠更新部分列。

後面是 更多的optimizer container支援 ,比如說K8s; 更多SQL語法的支援 ,比如說merge into——目前我們在Arctic層面還沒有這樣的語法,使用者可以把Arctic的表當成Iceberg表來用,來支援merge into。未來如果在Arctic層面支援了merge into,它會和Iceberg有所不同,因為我們的變更資料首先會進入到change空間。

最後一點因為我們的生態位是在資料湖Table format之上,所以未來我們會做架構的解耦,去 擴充套件到更多的Table format ,比如Delta、Hudi。

最後談談我們開源的初衷。過去我們做開源可能沒有一個非常統一的步調,去年我們領導層下了一個決心,會按照一種更加專注的方式做開源,以Arctic這個專案為例,我們不會做任何的商業隱藏。而且從組織架構而言我們團隊推進開源也是非常獨立的過程,如果可能有商業化會由其他的團隊推進。

我們會致力於為開發者、使用者、成員構建一個公開、自由的資料湖技術交流社群。當然目前我們主要面向的是國內使用者,官網也是以中文為主。希望更多的開發者參與到我們這個專案中來。

這是我今天要分享的全部內容,謝謝大家!

Q&A

主持人:有沒有關注過關於Flink Tablestore的特性,跟Arctic又有怎樣的區別?

馬進:有。首先大家做的東西都比較相似,去年我們就看到了Flink社群裡面這樣的proposal。我理解Flink一定會做這樣的事情,他們也是希望能搭建一套自己完整的生態,就像Delta對於Spark一樣。

雖然是相似的,但是大家的目標是不太一樣的,Flink做這個事對流這個場景而言更加原汁原味,但是肯定不會像我們更多考慮到怎麼在Spark上,在其他的引擎上做一些事情,怎麼在上層提供更多的管理功能。所以拋開一些功能上的重合,我理解大家的初衷或者最終要解決的問題還是會有差異。

主持人:雖然在表現形式上是相似的,但是Flink tablestore的這種方式更貼近原生Flink的場景,但是我們除了相容Flink的場景之外還會有更多偏向於Spark的場景做相容和支援。

馬進:不光是Spark,我們還提供了Hive相容。如果是Hive使用者,怎麼能讓一些Hive表比較順滑地升級到我們湖倉一體新的架構上,這是我們系統去考量的一些東西,在這個過程中怎樣提供一些便利的管理功能,提供度量指標,這些可能和Flink Tablestore考慮的點是不一樣的。

主持人:Arctic底層剛才講到是基於Iceberg實現的,在程式碼上有強繫結的關係嗎?以後會不會考慮基於其他的Table format做這種轉換?

馬進:我們也經歷過一些變化。現在我們自己定的標準首先不會侵入到format內部的實現,也不會魔改開源的程式碼。但早期我們並沒有這樣明確的目標,會有一些在Iceberg上的更改。現在我們程式碼和Iceberg相對來說是可以做一個比較乾淨的解耦,但是目前我們沒有做這個事,比如說Schema這些定義用的還是Iceberg包裡的東西,但是這個東西要解耦是很容易的。這裡面有個設計上的初衷,產品要去考慮怎麼把資料湖用起來,會有一些考慮,比如Iceberg和Delta誰更可能成為未來的主流?我們希望使用者能免除這樣的煩惱,未來我們希望能在上層給使用者提供一個統一的他需要的Lakehouse方案,下層我們再做這樣的選型。

主持人:說白了我們不幫使用者做出最終的決定,而是提供更多的可能性,無論未來是Iceberg還是Delta,我們都能用一種比較開放的方式相容。

馬進:這個是長遠的,現在我們還會和Iceberg結合得緊密一些。

Arctic 文件地址:

https://arctic.netease.com/ch/

GitHub 地址:

https://github.com/NetEase/arctic

視訊觀看:

https://www.bilibili.com/video/BV1Nd4y1o7yk/