開源流式湖倉服務Arctic詳解：并非另一套Table Format
首先感謝大家參與我們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結合得緊密一些。
