本文PPT下載下傳連結： 王烨(萌豆)-阿裡雲進階技術專家 -《阿裡雲基于Hudi建構Lakehouse實踐》.pdf 其他幹貨： 李少鋒(風澤) - 阿裡雲技術專家-《基于Apache Hudi的CDC資料入湖》.pdf 翟佳-StreamNative 聯合創始人、Apache Pulsar PMC 成員-《Pulsar 2.8.0 功能特性概述及規劃》.pdf 盛宇帆-StreamNative 軟體工程師-《基于 Flink 的全新 Pulsar Connector 的設計、開發和使用》.pdf
一、資料湖與Lakehouse
2021年開發者大會上，我們的一位研究員分享的一個議題，提到了很多資料，主要想闡述的是行業發展到現在這個階段，資料的膨脹非常厲害，資料增速非常可怕。無論是資料規模還是生産處理的實時化，到生産處理的智能化，以及資料加速上雲的雲化過程。
這些資料來自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清洗不同的表，在一定程度上通用化，讓使用者用得更簡單。未來内置更多場景化能力，讓使用者建構和應用湖倉更加簡單！