一、背景與行業現狀

1、數據湖理解的幾個誤區

現在很多企業都對數據湖存在一些誤區，從上圖左側對數據湖的不同定義（紅色字體標識）可以看出，數據湖并不像大家想象的那樣。誤區主要分為以下三種：第一種認為數據湖僅用來進行海量的存儲；第二種認為數據湖是用來處理非結構數據的，不處理結構化數據；第三種認為數據湖僅可以用來做貼源層，不能建數倉。

我們從數據湖所承載的大數據平臺技術上看，它除了存儲之外，還具備批量計算、實時計算、交互式分析、機器學習等多種能力。所以基于以上大家對數據湖的理解來使用數據湖是限制了它的數據處理加工能力和使用范圍，同時也提高了建設成本。

2、當前數據湖在數據處理的幾種用法—數據湖能力并未充分利用

下面是幾種常見的數據湖用法，但是這幾種用法都沒有把數據湖的能力完全發揮出來。

（1）數據湖做原始數據存儲

數據湖作為一個貼源層，從業務數據庫將原始數據導入到數據湖中存儲起來，在用數環節需要將數據再導出到傳統數倉或者其他查詢庫中，整個過程只是用了數據湖的存儲能力。

（2）數據湖做原始數據存儲+批量計算

第二種在上面的基礎上增加了批量計算，基于貼源層寫很多大表關聯、多表關聯，生成應用表，然后把應用表抽到分析倉庫、數據倉庫中。這種用法也沒有把數據湖的全部能力用出來。

（3）數據湖分集群建設

第三種是分集群建設，把大數據平臺真正的能力都用出來了，但是在集群規劃部署的時候，按照不同負載建設了不同的集群，比如：創建一個批量集群、一個分析集群，一個實時計算集群。分集群建設的理念認為各種不同的負載會導致相互之間影響，為了保證負載和業務的SLA能夠達到要求，就分開進行建設。其實大數據集群具有很好的資源隔離能力，分集群建設會導致資源浪費，數據共享難、數據存儲冗余、運維成本高等問題。

這幾種用法都沒有真正發揮出數據湖的價值，只是用了它的一個方面。第三種用法比較典型，很多企業從組織架構上就會設置一個批量計算組、實時計算組，通常建設的集群也是兩個。這樣會造成集群資源冗余和數據重復考拷貝，增加了很多數據遷移和開發成本，以及底層資源的消耗。

3、Lakehouse相比于數據庫、數據湖、數據倉庫具備的能力介紹

針對以上使用數據湖存在的問題，我們對比一下數據平臺發展過程中經歷的幾個階段。

（1）第一個階段是數據庫

不管是從業務的角度還是從技術棧角度，大家對數據庫都是最熟的。

（2）第二階段是數據倉庫

當數據庫的整體能力達不到我們的存儲要求之后，就出現了數據倉庫。數據倉庫定位也是偏OLAP。它把數據的存儲的能力通過分布式的方式去加大，計算能力也相應增加了上去。在有些特性和用法上是非常相似的。

（3）第三階段是數據湖

數據湖在存儲規模和計算能力上進一步加大，整個集群規模可以上萬臺，整體的能力會有更大的提升，同時擴容更加平滑。另外它增加了很多數據庫和數倉不具備的能力，比如實時計算、機器學習。它也會有一些弱勢，比如相對前面兩個它的交互式分析能力會弱一些。

（4）第四階段是Lakehouse

數據湖得到廣泛應用之后，在數據湖上承載的業務越來越多，這個時候就會發現數據湖的能力不具備支持更多的應用場景，比如：數據操作的事務能力、數據更新的能力，流數據與批量數據的共享、交互查詢能力性能等。但是我們又不希望構建多個平臺，我們希望一個平臺能夠承載所有業務，這時Lakehouse架構應運而生。Lakehouse在數據湖上疊加了一些數倉的能力，并且做了非常大的延伸，使一些數倉的能力在數據湖上構建起來。

左邊圖是Databricks發布的對Lakehouse技術體系的整體設想和架構，我們可以看到Lakehouse在事務性、數據更新能力和實時處理上都得到了非常大的提升，滿足了我們對更多業務場景的需要，通過一個統一的平臺解決不同業務場景的數據加工的需求。

4、Lakehouse架構使得實時計算進入流批一體階段

實時計算有三種不同的架構，分別是Lambda實時架構、基于OLAP庫的實時架構和基于Lakehouse的流批一體架構。

（1）Lambda實時架構

這種架構是Strom和Flink實時計算組件出現后廣泛采用的架構，最大的特點就是批量與實時是存儲和計算分開的兩套架構，因此在集群建設和開發團隊組建上也出現了分開建設的情況，這樣就導致了流批數據共享問題、數據一致性問題和運維問題等。同時早期流式計算的計算模型也相對比較簡單，承擔數據業務場景多聚焦于實時監控和風控等場景，對原有的批量業務沒有太大的增強。

（2）基于OLAP庫的實時架構

這種架構其實是對Lambda架構的增強，Lambda架構計算的結果要寫入到數據庫或者數據倉庫，以實現快速用數的需求，然后傳統數據庫或者數據倉庫在實時性上都達不到要求，因此該架構主要也是改善這個問題，可實現大量數據的實時寫入，大量數據存儲以及實時查詢的需求。

但是Lambda架構存在的問題，在該種架構中是依然存在的，比如：批量數據與實時數據共享問題，批和流的數據相互引用還是比較不方便的，都是異步的或者是定時、周期的，相互之間使用同步的方式去做，本質上批和流還是兩套東西。同時行業內也將這種架構稱為實時數倉，其實嚴格來說不完全具備實時數倉的能力，實時數倉處理具備實時寫入和實時查詢之外，還要具備在數倉分層存儲架構，尤其是分層之間的數據流轉也要具備實時性，目前該種架構的產品還不具備該能力。

（3）基于Lakehouse的流批一體架構

Lakehouse這種技術出來以后，尤其是以Hudi為代表的組件，提供了增量計算的能力。基于Lakehouse架構去做流批一體能夠在數據進行加工處理的時候支持連續實時的計算。

基于實時的倉庫，在Lakehouse里面可以做實時分層的數據加工。在分層內做完加工后的數據和批量的數據是一體的。比如同樣一張表可以實時讀或批量讀；同樣一張表可以實時寫，也可以批量寫，做到了批量數據和實時數據的統一存儲。在某些場景下，也可以做到計算引擎的一體化和數據處理代碼一體化。比如基于Flink SQL去做流式加工，在批量的時候也可以復用Flink SQL的代碼，它的SQL 邏輯是完全一樣的，可能只是改變一個參數來切換它的運行模式是流還是批，做到完全的代碼一體。

在這三種實時計算的架構中，目前我覺得Lakehouse應該會是實時架構的一個大的趨勢。

二、基于Lakehouse湖內建倉參考架構

下面介紹基于Lakehouse湖內建倉參考架構。

1、統一的計算集群層

首先我們要把數據湖不同計算負載的能力用起來，在同一個集群實現批處理、流處理、交互式查詢和機器學習，避免多集群建設的帶來的運維成本和資源成本增加。數據湖可以按租戶把資源隔離開，租戶使用不同的資源池跑自己的作業，相互之間是不受影響的。這樣就可以避免出現資源負載互相影響或者業務SLA的問題，所以可以通過統一的集群去構建多類負載的能力。

2、統一的元數據和權限管理層

基于數據湖構建統一的數據平臺，提供了統一的元數據管理和數據權限管理。原來分集群建設，導致元數據和用戶賬號不統一，在數據和權限管理上也帶來很大麻煩。如果統一元數據和賬號體系的管理，就能更方便的做統一的數據管理和權限管理。

3、數據集成層

在數據入湖和出湖的時候，需要有一個比較好的數據集成平臺。雖然有很多開源的組件可以實現，但是開源實現和商業版本相比，在穩定性和資源消耗上是存在短板的。所以不同的商業公司，包括各家云廠商都有數據集成的產品，在一鍵處理能力以及對資源消耗上都做了非常大的優化。

4、Lakehouse層

基于Lakehouse構建數據倉庫，比如貼源層、明細層、匯總層。不同的企業根據自己的數據治理規范要求建設自身需要的分層體系。建完分層以后，各層之間的數據流轉都是流批一體的，可以做大數據量的批量處理，也可以做增量的流式處理。在整個數據接入過程當中遵循ELT的理念，在接入的時候不做業務邏輯的處理，加載以后再做處理。Lakehouse架構提供事務的能力、數據更新的能力和流式讀寫的能力，以及查詢性能提升的能力，比如索引能力、物化視圖等能力。

5、統一存儲集群層

底層存儲采用統一的對象存儲或分布式的塊存儲來解決海量數據存儲的問題。

6、多樣集市層

在整個架構里面，即使實現了數據的快速的消費，每個集市組件都有自己一定的適配場景，因此需要根據自身業務的技術要求選用合適的組件。單一一個組件很難滿足所有的數據業務要求，因此集市層建設組件可以多樣化。

現在有很多快速查的組件，比如Doris、ClickHouse、HBase、Redis、IotDB等。可以結合業務場景要求把結果數據同步到集市層組件，這樣在業務場景中的適配度會比較高。比如要做千億級別的，甚至字段能達到幾千列的，那么使用ClickHouse的效果就會非常好，時序數據分析采用IotDB。基于傳統數據倉庫或者數據湖是沒有辦法達到這么高的性能。

我們認為整體的參考架構要把數據湖的能力全面地應用起來，解決大粒度的批流數據的加工處理。同時在數據消費的時候，根據具體場景，選用不同的組件來滿足個性化的要求。而且經過統一的建設之后，整體建設成本大幅下降，很多資源冗余、數據冗余、開發的冗余也會大大降低。

三、湖內建倉典型場景方案介紹

下面列舉幾個在湖內建倉的典型場景。

1、實時數據湖典型場景：流批一體加工模式，批量數據與實時數據共享

在Lakehouse做流批一體加工的時候，有幾種比較典型的加工模型：

（1）流式加工模式

所有的表都存在數據湖，基于Flink引擎/Spark引擎實現流式數據加工，把數據流式的寫入到湖里的表，源表數據與目標表數據都可以長持久化存儲。

（2）增量批加工模式

增量批處理是基于Hive和SparkSQL實現增量的批讀數據。其處理語法邏輯與傳統Hive和SparkSQL基本保持一致。增量批將全量批轉化小表處理，性能高，資源消耗低，也避免了出現集群資源集中上漲的情況。

（3）全量批加工模式

基于Hudi的鏡像讀模式，實現數據全量讀取。保持分區裁剪等數據過濾能力。語法邏輯與傳統批量作業保持一致、原有批量作業可以直接搬遷。

其實上面這幾種作業的SQL邏輯都是一樣的，只是在有些參數和特定場景的處理上會有稍許的不同。批量加工和流式加工的數據是共用的。

2、數據加工—數據分層模型提升數據復用率、降低資源消耗、提升計算性能

（1）數據加工存在的問題

在跨業務中心數據引用的時候，各自進行全量業務加工，導致出現數據處理量大、加工邏輯復雜、資源消耗大、時效低等問題；在業務中心內部處理加工的時候，由于業務庫經過長期演進，數據模型變得更加復雜，導致流式加工關聯數據過多、資源消耗大、穩定性以及時效受到挑戰。通常大家都習慣于用數據庫和數倉那種模式，直接寫一個非常大的SQL把結果讀出來。

有了數據湖以后，它的存儲成本相對來說要廉價很多，這時存儲成本和計算成本相比較的話，存儲成本會更低。因為前者的用法計算成本很高，耗費了CPU和內存，節省了硬盤，所以下面其實更應該多用一用硬盤的存儲能力。

（2）數據分層中增加“共享層”

我們推薦在做復雜處理的時候，中間增加一層或兩層，把數據中一些共用的東西抽出來，降低每一層的加工復雜度。數據之間、各個作業之間的加工數據能夠復用。這樣在開發的時候會大幅簡化作業邏輯，降低整體資源消耗，并提升端到端整體的時效性。

（3）數據分層的價值

首先，能夠保證各業務之間數據共享時數據口徑是一致的。

第二是降本增效，適當地增加一點冗余的存儲資源，可以把計算資源消耗降低，同時數據時延也降下來了，可以提升整體性能。

第三是數據的解耦，貼源層跟業務層的業務邏輯保持一致，在數據業務加工的時候，不會改變貼源層的數據存儲，在做數據回溯的時候，能夠非常方便地去做問題的定位和排查。

3、現有存量的批量數據和任務轉換為實時（按照業務需求進行切換）

如果我們已經有一個建好的數據湖，現在要上Lakehouse。如果把整個數據湖幾萬張表全部推倒重來，成本、代價、風險都非常高。

我們建議的方式是按照業務逐步切換，切換以后數據是可以沿用的，新的業務跑實時，或者用Lakehouse的架構去跑，老的業務繼續跑HiveSQL。即使有一些數據是交叉的，也不會影響，因為原有的Hive技術可以讀Lakehouse的表，所以這樣去做會更加平滑。

4、歷史批量表與Lakehouse實時表的互相引用方式

前面我們介紹了存量的批量數據和任務轉換為實時，接下來我們看一下這些表之間會不會存在引用上的問題。

雖然批量模式下引用實時表，原有批量作業的代碼和調用方式不用修改。但是在實時模式引用批量數據具有一定限制。比如ORC表不支持增量讀的方式，只支持全量讀，所以在碰到原有表數據加工的時候要做一定的適配。因為一般實時模式都是新業務，它本身就要重寫，再適配也是可以接受的，并不會帶來太多額外的工作量。我們可以基于應用逐步把所有業務切換完以后，就完全變成新的數據加工模式。

5、Lakehouse的典型場景：鏡像表構建，簡化方案、降低成本、數據事務性保證

鏡像表的生成在數據接入層有兩種：第一種是批量同步方式，以T+1的方式進行全表同步，成本會比較高；第二種是增量同步方式，按照自增ID或時間戳把增量的數據同步過來，但要跟原有的表做存增量合并的處理，存增量合并是將增量數據與已有存量數據通過join方式得到新增、刪除、更新的數據，然后進行Merge操作，得到最新的全量鏡像表。

增量同步方式又可以進一步分為批量和實時，如下：

• 批量入湖

批量入湖在存增量合并的時候，經常會遇到端到端時效性低、開發成本高、資源消耗高等問題。在一些案例中，為了解決端到端的數據開發，在每一層都做存增量合并，資源消耗會占到業務開發的1/4到1/3，造成整體的成本很高，開發工作量也比較大。

• 實時入湖

引入Lakehouse以后，基于Lakehouse的upsert能力實現數據實時入湖，構建鏡像表會非常方便。直接把增量數據寫入湖中，如果有相同的數據，就直接更新，沒有相同的數據，就會認為是新增的，鏡像表就能非常快的構建出來。

鏡像表構建的方案簡化了，計算成本和存儲成本也都可以降下來，并且還有事務性的保證。

6、Lakehouse的典型場景：拉鏈表構建，兼顧流式計算、批量計算和數據回溯

下面再舉一個典型的場景，我們在數倉里面會構建拉鏈表，尤其是基于TD的數倉會構建大量的拉鏈表。拉鏈表在數倉里面針對某一個狀態有開始時間和結束時間。基于時間戳會采用天級、分鐘級或者更細粒度的狀態管理，只要有變化都可以保留下來。

• 傳統數倉的拉鏈表實現

傳統數倉的拉鏈表基于Start_time和End_time實現不同粒度的拉鏈數據；數據的寫入與讀取都是采用批量方式進行，增量與全量表關聯得到閉鏈操作目標數據。端到端時效性較差，T+1的數據可見性。

• 流批一體實現方案

基于流批一體的方案除了保留原有數倉的批量能力外，新增了實時處理能力。批量處理方式在落地實現上可以基于原有邏輯實現，也可以通過update、upsert能力簡化實現復雜度。在實時處理上可以新增最新數據的流式計算，提升業務的時效。因此基于流批一體的實現既可以實現原有批量處理的能力，有可以實現實時的處理能力，且能保持拉鏈表的特點。

四、后續規劃&挑戰

1、挑戰

• 并發挑戰：業務方希望能夠實現單表的高的并發寫入要求。
• 復雜事務：跨表、跨語句的事務要求。如果事務很復雜，它的回滾量會非常大，會直接影響整個集成的穩定性。
• 門檻高：現代Lakehouse功能豐富、參數配置復雜，技術門檻高。這樣在用的時候，就需要熟悉它的各種用法、各種場景，這也為落地帶來了一定挑戰。

此外，基于批量的處理模式大家都很熟悉，也習慣了批的處理模式；但是流式處理和流批一體的模式屬于新的模式，在數據建模設計以及數據處理的理念上需要進一步適配，對于設計和開發人員會帶來一定的挑戰。

2、后期規劃

針對這些問題，我們也做了很多規劃。總結起來有兩個方向：

（1）開箱即用

我們希望這么多豐富的功能使用上更簡單。能夠做到在部署好后直接把業務 SQL 搭上去就能跑，而且跑的很好。

（2）場景能力增強

數據湖做交互式查詢的性能跟OLAP的庫有一定的差別，我們要繼續提升性能。我們希望實現更多的實時加工處理，并且速度能做得更快。結合具體場景，根據業務上的要求來豐富它的處理能力。

五、Q&A

Q1：現在 Lakehouse 有哪些開源版本嗎？

A：目前開源的Lakehouse有Hudi、Iceberg和DeltaLake，是現在比較主流的。其中Hudi在國內的使用比較普及；Iceberg和DeltaLake在北美用得會比較多一些。

Q2;湖倉一起的架構中，底層的存儲對于非結構化和結構化的數據怎么做到統一存儲的？他們的元數據也能統一管理嗎？

A：非結構化的存儲和結構化數據存儲在開始的時候，它的元數據肯定是沒辦法做到一起的。你比如一個文件它本身就沒有什么元數據，它只有一個文件名的概念。非結構化存儲在做了特征模型之后，是可以統一去存儲的，去復用。另外關于結構化數據在一些機器學習里面，它也會有一些特征的處理，特征以后的數據是可以去做統一存儲的。

如果是原始數據，統一存儲在元數據層其實就是文件系統的元數據了。

Q3：湖倉分層與離線數據分層上處理上有什么特別注意的地方嗎?

A：實時的分層處理（湖倉分層）和離線分層處理，其實從模型上面不會有太大的區別，最大的區別是我們對實時要求的區別。

比如我們希望數據處理的端到端更快，其實它可以在我們原有的離線數據分層上適當地去跳一跳，比如從明細層直接跳到結果層、應用層。在有些分層，比如我們貼源層是結構化數據，本身它的數據質量相對比較高，這個時候也可以從貼源層直接跳到應用層。總之，按照不同時效、不同業務要求，它的分層會比較靈活。