一、數據湖與Lakehouse

2021年開發者大會上，我們的一位研究員分享的一個議題，提到了很多數據，主要想闡述的是行業發展到現在這個階段，數據的膨脹非常厲害，數據增速非?？膳隆o論是數據規模還是生產處理的實時化，到生產處理的智能化，以及數據加速上云的云化過程。

這些數據來自Gartner、IDC的分析，都是行業最權威的分析報告里沉淀總結出來的。這就意味著我們在數據領域尤其是分析領域的機遇和挑戰都很大。

在海量的數據上，我們要真正做好數據價值的挖掘和使用會面臨很多挑戰，第一是現有的架構慢慢都要往云上架構遷移；第二個是數據量；第三個是Serverless按量付費，慢慢從嘗試性的選擇成為默認選擇；第四是還有多樣化的應用、異構數據源。相信大家接觸過云都知道，無論是哪個云廠商都有很多種云服務可供，尤其是數據類服務數量繁多。這時候，大量數據源一定會帶來一個問題：分析難度大，尤其是想做關聯分析的時候，異構數據源怎么連接起來是很大的問題。其次是差異化的數據格式，通常我們做數據寫入會時選擇方便、簡單的格式，比如CSV、Json格式，但對分析來講，這些格式往往是非常低效的，尤其是數據到了TB、PB級的時候，根本沒法分析。這時候Parquet、ORC等面向分析的列存格式就衍生出來了。當然還包括鏈路安全以及差異化群體等等，數據量膨脹的過程中又增加了很多的分析難度。

在真實的客戶場景里，很多數據已經上云了和“入湖”了。湖是什么？我們對湖的定義和理解更像AWS的S3或者阿里云OSS這種對象存儲，是簡單易用的API形式，可以存各種各樣差異化的數據格式，有無限的容量、按量付費等非常多的好處。之前想基于湖做分析非常麻煩，很多時候要做T+1的建倉和各種云服務投遞。有時候數據格式不對就要人肉做ETL，如果數據已經在湖里要做元信息發現分析等等，整個運維鏈路很復雜，問題也很多。這里都是線上客戶實際面臨的離線數據湖問題，有些優先級偏高，有些低些，總而言之問題非常多。

其實Databricks大概19年就開始將研究重點從Spark方向，慢慢往Lakehouse方向調整了。他們發表了兩篇論文，這兩篇論文為數據湖怎么被統一訪問、怎么被更好地訪問提供了理論層面的定義。

基于Lakehouse的新概念，想做到的是屏蔽格式上的各種差異，為不同的應用提供統一的接口以及更加簡化的數據訪問、數據分析能力。架構說實現數據倉、數據湖、Lakehouse一步步演進。

他的兩篇論文闡述了很多新概念：第一，怎么設計和實現MVCC，能讓離線數倉也有像數據庫一樣的MVCC能力，從而滿足大部分對批事務的需求；第二，提供不同的存儲模式，能夠適應不同的讀和寫Workload；第三，提供一些近實時的寫入和合并能力，為數據量提供鏈路能力?？傊?，他的思路能夠較好解決離線數據分析的難題。

目前業界有三款產品相對比較流行，第一個是Delta Lake，它是Databricks自己發布的數據湖管理協議；第二個是Iceberg，Iceberg也是Apache的一個開源項目；第三個是Hudi，Hudi最早由Uber內部研發，后來開源的項目（早期用得比較多的是Hive的ACID）。目前這三個產品因為可以對接HDFS的API，可以適配底層的湖存儲，而OSS又可以適配到HDFS存儲接口。由于核心原理相似，三個產品各方面的能力都在逐漸靠近，同時有了論文做理論支撐，我們才會有方向去實踐。

對我們來說，當時選擇Hudi也是因為其產品成熟度方面的原因，還有它面向數據庫方面的數據入湖能力，形態上比較滿足我們在數據庫團隊做CDC方面的業務需求。

Hudi早期的定義是Hadoop Updates anD Incrementals的縮寫，后面是面向Hadoop的Update、Delete、Insert的概念，核心邏輯是事務版本化、狀態機控制和異步化執行，模擬整個MVCC的邏輯，提供對于內部列存文件比如Parquet、ORC等對象列表的增量式管理，實現高效的存儲讀寫。它和Databricks定義的Lakehouse概念很相似，不謀而合，Iceberg也是一樣，它的能力也在逐步往這個方向提升。

Hudi官方網站對外提供的架構是這樣的形態。之前我們做技術選型、調研的時候發現很多同行也已經充分使用Hudi做數據入湖和離線數據管理的方案選型。第一，因為產品比較成熟；第二，它符合我們CDC的需求；第三，Delta Lake有一套開源版本，一套內部優化版本，對外只提供開源版本，我們認為它不一定把最好的東西呈現。Iceberg起步比較晚，早期相比其他兩個產品能力不太完全，所以沒有考慮它。因為我們都是Java團隊，也有自己的Spark產品，Hudi正好比較契合我們用自己的runtime支持數據入湖的能力，因此也就選擇了Hudi。

當然我們也一直在關注這三個產品的發展，后來國內的一個開源項目StarLake，也是做類似的事情。每種產品都在進步，長期來看能力基本對齊，我覺得會和論文里定義的能力慢慢吻合。

“以開源Hudi為列式、多版本格式為基礎，將異構數據源增量、低延遲入湖，存儲在開放、低成本的對象存儲上，并且在這個過程中要實現數據布局優化、元信息進化的能力，最終實現離線數據統一管理，無差別支持上面的計算和分析能力，這是整體的方案。”這是我們對Lakehouse的理解，以及我們的技術探索方向。

二、阿里云Lakehouse實踐

下面介紹一下阿里云Lakehouse的技術探索和具體的實踐。首先，大概介紹一下阿里云數據庫團隊近年來一直提的概念“數據庫、倉、湖一體化”戰略。

大家都知道數據庫產品分為四個層次：一是DB；二是NewSQL/NoSQL產品；三是數倉產品；四是湖數據產品。越往上數據的價值密度越大，會以元表元倉形式的數據關聯到分析中去，比如DB數據格式非常簡單、清晰； 越往下數據量越來越龐大，數據形式越來越復雜，有各種各樣的存儲格式，數據湖形式有結構化、半結構化、非結構化，要分析就必須要做一定的提煉、挖掘，才能真正把數據價值用起來。

四個存儲方向有各自的領域，同時又有關聯分析訴求，主要就是要打破數據孤島，讓數據一體化，才能讓價值更立體化。如果只是做一些日志分析，例如關聯的地域、客戶來源的話，也只是使用了GroupBy或者是Count等相對簡單的分析能力。對于底層數據，可能要做多次清洗、回流，才能往向在線化、高并發的場景一層層分析。這里不僅僅直接將數據從湖到庫寫入，也可以到倉，到NoSQL/NewSQL的產品里，到KV系統里去，利用好在線化的查詢能力，等等。

反過來也是一樣，這些數據庫/NewSQL產品甚至數倉中的數據也會向下流動，構建低成本、大容量的存儲備份、歸檔，降低上面的存儲壓力、分析吞吐壓力，且可以形成強大的聯合分析能力。這也是我自己對數據庫、倉、湖一體化的理解。

剛才講了數據庫的發展方向和定位，再看看數據庫下面OLAP本身的分層數倉體系中Lakehouse是怎樣的定位。做過數倉產品的同學都比我熟悉，（PPT圖示）基本上是這樣的分層體系，最開始各種各樣的形態非數倉或者非數據湖系統外面有各種各樣的形式存儲數據，我們理解通過Lakehouse的能力，做入湖、建倉，通過清洗、沉淀和聚合，形成ODS或者是CDM層，這里做了初步的數據聚合和匯總能力，形成數據集市的概念。

這些數據在阿里云上我們會基于Hudi的協議，基于Parquet文件格式存到整個OSS上面，內部通過ETL把初始數據集進一步聚合為更清晰、更面向業務的數據集上，然后再構建ETL，往實時數倉里導入，等等。或者這些數據集直接面向低頻的交互式分析、BI分析，或面向Spark等引擎做機器學習，最終輸出到整個數據應用上，這是整體的分層體系。

整個過程中，我們會接入統一的元信息體系。因為如果系統的每個部分都有自己的術語，都要保留一份自己的元信息，對OLAP體系來講是分裂的，因此元信息一定要統一，調度也是一樣。不同數據倉層次的表在不同的地方要串聯起來，一定要有完整、統一的調度能力。以上是我理解Lakehouse在OLAP體系中的的定位，主要是貼源層，匯聚離線數據的能力。

前面介紹了Lakehouse在數據庫和OLAP團隊里的定位，后面重點介紹一下Lakehouse在我們的領域設計是怎樣的形態。因為之前我自己用過K8s做分析系統上云，所以對K8s的很多理念還是比較清楚。

在我們自己設計的時候也試圖參考、學習一下K8s的體系。K8s有我們經常提到的DevOps概念，這是一種實踐范式。在這個范式下會創建很多實例，在實例里會管理很多應用，這些應用最終通過Pod方式被原子性調度執行，Pod里再跑一些業務邏輯，各種各樣的Container。

我們認為Lakehouse也是一種范式，一種處理離線數據的范式。在這里，數據集是我們的核心概念，比如要構建一套面向某種場景、某個方向的數據集。我們能要定義A、B、C不同數據集，在我們看來這是一個實例。圍繞這個數據集編排各種各樣的Workload工作負載，比如做DB入湖。還有分析優化類的Workload，比如索引構建，比如像z-ordering、Clustering、Compaction等技術，查詢優化能力提升得更好。還有就是Management類型的Workload，比如定期把歷史數據清理了，做冷熱存儲分層，因為OSS提供了很多這樣的能力，把這些能力用好。最下面一層是各種Job，我們內部是基于Spark建設離線計算能力，我們把Workload前后編排成小的job，原子的job全部彈性到Spark上執行，以上是我們對于Lakehouse在技術實踐中的領域設計。

這是整體的技術架構。首先，在云上有各種各樣的數據源，通過編排定義各種各樣的Workload，跑在我們自己的Spark彈性計算上。核心的存儲是基于Hudi+OSS，我們也支持別的HDFS系統，比如阿里云的LindormDFS，內部元信息系統管理庫、表、列等元信息。后面基于K8s調度所有的管控服務。上層通過原生的Hudi接口，對接計算、分析能力。這是整個彈性架構。

其實Serverless Spark是我們的計算基礎，提供作業級彈性，因為Spark本身也支持Spark Streaming，通過短時間彈出一個Spark作業實現流計算。選擇OSS和LindormDFS做存儲基礎，主要利用低成本、無限容量的好處。

在這個架構上，怎么連通用戶的數據實現數據入湖到存儲、到分析的能力呢？以上是我們基于VPC構建的安全方案。首先我們是共享集群模式，用戶側可以通過SDK和VPDN網絡連接過來，再由阿里云內部網關打通計算集群，實現管理和調度；再通過阿里云彈性網卡技術，聯通用戶的VPC實現數據通路，同時實現路由能力和網絡隔離能力，不同用戶還可能有子網網段沖突問題，通過彈性網卡技術可以實現相同網段同時連接同一個計算集群的能力。

用過阿里云OSS的同學都知道，OSS本身是阿里云VPC網絡里的公網，它是共享區，不需要復雜的網絡。而RDS和Kafka是部署在用戶的VPC里，通過一套網絡架構就可以實現多種網絡打通。對比VPC網段沖突，共享區域沒有這樣的問題。其次，數據之間隔離，ENI有端到端的限制，比如VPC有ID標志、有不同的授權要求，非法用戶嘗試連接VPC，如果不是這個網卡則網絡包無法聯通，就可以實現安全的隔離和數據的通路。

網絡架構已經確定了，怎么運行執行呢？在整個設計里，我們會以K8s的DSL設計為榜樣，前面提到會定義很多入湖任務，一個Workload可能有很多小任務，這時候需要類似定義DSL的編排能力，job1、job2、再到job3，定義一套編排腳本；這些編排腳本，通過SDK、控制臺等入口提交過來，再通過API Server接收并由Scheduler調度起來。這個Scheduler會和Spark的網關之間打通，實現任務管理、狀態管理、任務分發等，最終調度內部的K8s拉起作業來執行。有些全量作業跑一次，比如DB拉一次就行了，還有常駐的流式作業、有觸發式的異步作業、定時異步作業等等，不同的形態相同的調度能力，從而可以擴展。過程中有作業狀態持續反饋狀態、間隙性統計等等。在K8s里，K8s Master承擔了這樣的角色，同樣有API Server和Scheduler的角色。在我們這里也是類似，也是通過一主多從架構實現調度能力HA機制等等。

在這里，為什么我們要把一個Workload面向用戶側的任務拆成N個不同的job？因為這些任務完全放在一個進程里跑，整個Workload的水位變化非常大，做彈性調度非常難。全量任務跑一次就可以了，但是配多少資源合適呢？很多時候Spark沒有那么靈活，尤其是異步任務和定時任務拉起來消耗很大，但是用完之后又不知道下一次什么時候來，很難預測。就像很多信號系統處理里，需要做傅里葉變換一樣，把復雜的波型拆成多個簡單的波型，信號處理就簡單起來。我們也是有這樣感性的理解。用不同的Job來執行Workload中不同角色的任務，就很容易實現彈性能力。像定時或臨時性的觸發Job，臨時拉一個job，資源消耗與常駐的流式任務完全無關，就可以完全不影響流式任務的穩定性、入湖延遲等等。這是設計背后的思考，就是讓復雜的問題簡單化。因為基于彈性的角度來講，拆得波形越簡單，彈性就會更好做，預測也會簡單一點。

入湖里會涉及很多用戶的賬密信息，因為不是所有云產品都以AWS的IAM或阿里云的RAM等系統來構建完全云化的資源權限控制。很多產品還是以賬密方式做認證和授權管理，包括用戶自建的系統，數據庫系統等等。這樣，用戶要把所有的連接賬密都交給我們，怎么更安全的管理它們？我們是基于阿里云的兩套體系：一套是KMS，以硬件級數據加密體系來加密用戶數據；第二套是STS，完全云化的三方鑒權能力，實現用戶數據的安全訪問，尤其是敏感數據的隔離或者保護的機制，這就是我們現在的整個體系。

還有一個問題，不同用戶之間通過各種機制完全隔離開了，但是同一個用戶有很多的任務。在Lakehouse概念中有四層結構，一個數據集下面有多個庫，庫下面有多個表，表下面有不同的分區，分區下面是不同的數據文件。用戶有子賬號體系、有各種不同的作業，因此操作數據時可能會出現相互影響。

比如不同的入湖任務都想要寫同一張表，線上A任務已經正常運行了，結果另外的用戶配置了B任務，也要寫入同一個空間，這就有可能把已經上線的A任務數據全部沖掉，這是很危險的事情。還有其他用戶刪除作業的行為，可能會刪掉線上正在運行任務的數據，有可能其他任務還在訪問，但又不能感知它；還比如通過別的云服務、或是VPC內別的程序、自己部署的服務等等，都可能操作這個表，導致數據出問題。因此我們設計了一整套機制，一方面是在表級別實現鎖的機制，如果有任務最早就占有一張數據寫入權限時，后面的任務在這個任務生命周期結束之前，都不允許再寫入，不可以寫臟了。

另一方面基于OSS的Bucket Policy能力，構建不同程序的權限校驗能力。只允許Lakehouse的的任務有權限寫數據，而其他程序不允許寫，但其他程序可以讀。同一個賬號的這些數據本來就是為了共享、為了分析，為了各種應用場景的接入，就是可以讀，但絕對不可以污染它。我們在這些方面做了可靠性工作。

我們更多講的架構體系，回到整體看一下怎么理解數據模型，我們認為整個過程是以行為中心（因為數倉還是一行行的數據，存儲在表的范圍內），以行數據構建統一入湖、存儲、分析，元信息模型等。首先有各種各樣的數據源（有文本或二進制，binlog就是二進制的數據；或者類似Kafka中可以存儲各種二進制），這些數據最終通過各種各樣Connector、Reader（不同的系統有不同的叫法），把數據讀過來，映射成行數據。在這些行數據中，有關鍵的描述信息，比如來源信息、變更類型等等，還有可變的列集合。再通過一系列的規則轉化，比如濾掉某些數據，要為數據生成主鍵，要段定義版本、類型轉換等等；最后再通過Hudi Payload封裝、轉換、元信息信息維護、文件生成等等方式，最終寫到湖存儲里。

在存儲里通過元信息、分區等數據維護，并對接后續計算和分析，就無縫看到湖、倉里所有存的數據的元信息，無縫對接不同形態的應用場景。

下面介紹一下我們對常見數據源接入形式的支持。DB入湖是最常見的場景，在阿里云上，有RDS和PolarDB等產品。以MySQL引擎舉例，一般都是有主庫、從庫、離線庫等架構，可能還有主從接入點，但是萬變不離其宗。DB入湖要先做一次全量同步，再做增量同步。對用戶來講，DB入湖是明確的Workload，但對系統來講要先做好全量同步這件事情，再自動對接增量同步這件事情，數據還要通過一定的機制把位點銜接住，確保數據的正確性。整個調度過程通過統一的管控服務獲取DB信息，自動選擇從庫或線上壓力最小的實例，進行全量同步寫到庫里，并維護好相應的Watermark，記錄全量從什么時間點開始的、從庫和主庫之間有多少延遲等。全量做完之后，開始做增量任務，利用DTS等同步binlog服務，基于前面的Watermark做數據回溯，開始做增量。利用Hudi里的Upsert能力，以用戶定義的PK和版本按照一定邏輯把數據合并，確保數據最終一致，分析側的正確性。

在整個Watremark維護上需要考慮很多，如果全量掛了，再重試一下，位點應該從哪里開始，如果增量掛了，不僅要考慮增量之前已經進行到哪里，還要漸進式的維護增量位點，不能每次增量一掛就回退到最開始全量前的位點，那后面數據延遲太嚴重了。在Lakehouse表級別維護這些信息，在Workload運行時、重啟、重試等過程可以自動銜接，對用戶透明。

第二個是像類消息產品的入湖，我們也做了一些技術探索和業務嘗試，它的數據不像DB一樣Schema都很明確。像阿里云現有的Kafka服務里，它的Schema只有兩個字段，Key和Value，Key描述消息Id，value自定義，大部分時候是一個Json，或者是二進制串。首先要解決怎么映射成行，會有很多邏輯處理，比如先做一些Schema推斷，得到原始的結構。Json原來的嵌套格式比較容易存儲，但是分析起來比較費勁，只有打平成一個寬表分析才方便，所以還要做一些嵌套打平、格式展開等等邏輯，再配合前面提到的核心邏輯，最終實現文件寫入、元信息合并等等。這個元信息合并就是指，源頭的列的個數不確定，對于不同的行有時候有這個列，有時候沒有。而對于Hudi來講，需要在應用層把元信息維護好。Lakehouse里的Schema Evolution，就是Schema的合并、列的兼容處理、新增列的自動維護等等。

我們內部有基于Lindorm的方案。Lindorm是我們自研兼容HBase、Cassandra等大寬表接口的KV行存。它有很多的歷史文件和很多Log數據，通過內部的LTS服務調，把全量和增量數據通過Lakehouse方式存在轉換成列存文件，支持分析。

對Kafka、SLS系統中都有分片（Partition、Shard）概念，流量變化很大時需要自動擴縮容，因此消費側要主動感知變化，不影響數據正確性的持續消費。并且這種數據都是偏Append-Only，正好可以利用好Hudi小文件合并能力，讓下游分析更簡單、更快、更高效。

三、客戶最佳實踐

以上是技術探索的分享，接下來會介紹一下在客戶的應用。之前一個跨境電商的客戶，他們問題就是DB數據不容易分析，目前有PolarDB和MongoDB系統，希望把所有數據近實時入湖到OSS上做分析。現在業界聯邦分析FederatedAnalytics，問題在于直連查詢數據時原庫的壓力很大，最好的方式就是入湖到離線湖中里做分析。通過Lakehouse方式構建離線湖倉，再對接計算和分析，或者對接ETL清晰，規避對線上數據的影響，同一架構把整體數據平臺構建起來，應用、分析百花齊放，不影響任何東西。

這個客戶的難點是他們有很多庫、表以及各種各樣的應用case，我們在Hudi上做了很多優化，也完成了20多個patch貢獻到社區里完善Hudi，包括元信息打通、部分Schema Evolution能力，在客戶側也應用起來。

另一個客戶數是Kafka日志近實時分析。原來他們的方案需要人肉做很多步驟，包括入湖、數據管理、小文件合并等。通過Lakehouse方案，對接客戶數據，自動合并入湖，維護元信息，客戶直接應用就可以了，內部直接打通了。

還有一個問題小文件，在他們的場景里與Hudi社區一起參與Clustering技術的建設。Clustering就是自動將小文件合并成大文件，因為大文件利于分析。其次，在合并過程中，可以按照某些特定列把數據排序，后續訪問這些數據列時，性能會好很多。

四、未來展望

最后，我再分享一下我們團隊對未來的思考，Lakehouse可以怎么應用起來。

第一，更豐富的入湖數據源。Lakehous重要的價值在于屏蔽各種數據差異，打破數據孤島。在云上很多系統中有各種各樣的數據，有很大的分析價值，未來要統一更多的數據源，只支持一個DB或Kafka，客戶價值不是最大化的。只有把足量的數據匯總到一起，形成大的離線湖倉，并且屏蔽復雜度，對用戶的價值才愈發明顯。除了云產品，還有其他形式的入湖，像專有云、自建系統、自主上傳場景等。主要還是強化貼源層的能力。

第二，更低成本、更可靠的存儲能力，圍繞數據生命周期管理。因為阿里云OSS有非常豐富的計費方式，支持多種存儲（標準存儲、低頻存儲、冷存儲以及更冷的存儲）等等，計費邏輯里幾十項，一般人不完全清楚。但對用戶來講，成本永遠是設計中心心，尤其是構建海量的離線湖倉，因為數據量越來越大、成本就越來越多。

之前接觸過一個客戶，他需要存儲三十年的數據，他們的業務是股票分析，要把交易所、券商的所有數據全部爬下來，傳到大的湖倉里。因為要做三十年的分析，成本優化是非常關鍵的。原來選擇在線系統，存幾個月就扛不住了，因為數據量太大了。分析數據是有從冷到熱、從相對低頻到高頻訪問的特點，Lakehouse利用這些特點，通過定義規則和邏輯，自動屏蔽用戶對哪些目錄需要冷存儲、哪些目錄需要熱存儲的復雜維護，幫用戶走得更進一步。

第三，更強的分析能力。在Hudi加速分析的能力里，除了前面提到的Clustering，還有Compaction。Clustering就是小文件合并，比如日志場景，每寫入一批就產生一個文件，這些文件一般都不是很大，但文件越小越碎分析時的訪問代價很大。訪問一個文件就要做鑒權、建連接、元信息訪問。訪問一個大文件這些過程只做一次，而訪問小文件則成倍放大，開銷非常大。在Append場景，通過Clustering快速合并小文件成大文件，規避因為寫入而導致的分析性能線性退化問題，確保分析高效。

在Hudi中如果是Merge On Read類型的表，比如Delete、Update都會快速寫到log文件，在后續讀的時候Merge數據，形成完整的邏輯的數據視圖。這里問題也很明顯，如果有1000個log文件，每次讀需要合并1000次，分析能力退化肯定非常嚴重。這時Hudi的Compaction能力就會定期把log文件合并起來。前面提到，如果完全要在同一個入湖作業里實現，尤其是文件合并，計算開銷很大，在做這些重負載的時候，對入湖鏈路的延遲影響很大，一定要通過異步化調度的方式，實現寫延遲保障。并且這些過程都是可彈性的，不論是100個文件要合還是1萬個文件要合，都是可以快速彈性而不影響延遲，非常有優勢。

第四，更豐富的場景化應用。個人覺得Lakehouse還是面向貼源層的能力，配合做一定程度的聚合。因為更高層次的聚合性和實時性，有更多實時數倉選擇，現在業界比較火的DorisDB、ClickHouse對實時的高頻分析有很大優勢。基于Hudi、Lakehouse、OSS做實時分析沒有太多優勢，所以還是以構建貼源層的能力為主。

原來都是近實時入湖場景，但是可能有些用戶沒有這么多實時性要求，周期性的T+1邏輯建倉可以滿足，可以利用Hudi+Lakehouse能力，每天查詢一部分邏輯增量數據并寫入Hudi，并維護分區，和實現Schema Evolution能力。

早期數據量越來越大，客戶通過分庫分表實現邏輯拆分。分析的時候發現庫、表太多了，分析、關聯難度大，這時候可以通過構建多庫多表合并建倉能力，匯總到一張表后做分析。

然后是跨區域融合分析，有很多客戶提這樣的需求，尤其是海外。有些客戶要服務海外用戶，必須有部分業務在海外，特別在跨境電商的場景，而它的采購體系、倉儲體系、物流體系、分銷體系等又都在國內建設，很多數據想要融合分析怎么辦？首先OSS提供了跨域復制，但也只是到數據層面，沒有任何邏輯，在這里可以通過Lakehouse做邏輯層建設，把不同region數據混合在一起，匯總到同一個區域之后，提供統一的SQL join、union等能力。

最后Hudi有TimeTravel、Incremental query的能力，這時候構建incremental ETL清洗不同的表，在一定程度上通用化，讓用戶用得更簡單。未來內置更多場景化能力，讓用戶構建和應用湖倉更加簡單！