一、背景與行業(yè)現(xiàn)狀1、數(shù)據(jù)湖理解的幾個誤區(qū)

現(xiàn)在很多企業(yè)都對數(shù)據(jù)湖存在一些誤區(qū)，從上圖左側(cè)對數(shù)據(jù)湖的不同定義（紅色字體標(biāo)識）可以看出，數(shù)據(jù)湖并不像大家想象的那樣。誤區(qū)主要分為以下三種：第一種認(rèn)為數(shù)據(jù)湖僅用來進(jìn)行海量的存儲；第二種認(rèn)為數(shù)據(jù)湖是用來處理非結(jié)構(gòu)數(shù)據(jù)的，不處理結(jié)構(gòu)化數(shù)據(jù)；第三種認(rèn)為數(shù)據(jù)湖僅可以用來做貼源層，不能建數(shù)倉。

(資料圖片)

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

2、當(dāng)前數(shù)據(jù)湖在數(shù)據(jù)處理的幾種用法—數(shù)據(jù)湖能力并未充分利用

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

（1）數(shù)據(jù)湖做原始數(shù)據(jù)存儲

數(shù)據(jù)湖作為一個貼源層，從業(yè)務(wù)數(shù)據(jù)庫將原始數(shù)據(jù)導(dǎo)入到數(shù)據(jù)湖中存儲起來，在用數(shù)環(huán)節(jié)需要將數(shù)據(jù)再導(dǎo)出到傳統(tǒng)數(shù)倉或者其他查詢庫中，整個過程只是用了數(shù)據(jù)湖的存儲能力。

（2）數(shù)據(jù)湖做原始數(shù)據(jù)存儲+批量計算

第二種在上面的基礎(chǔ)上增加了批量計算，基于貼源層寫很多大表關(guān)聯(lián)、多表關(guān)聯(lián)，生成應(yīng)用表，然后把應(yīng)用表抽到分析倉庫、數(shù)據(jù)倉庫中。這種用法也沒有把數(shù)據(jù)湖的全部能力用出來。

（3）數(shù)據(jù)湖分集群建設(shè)

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

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

3、Lakehouse相比于數(shù)據(jù)庫、數(shù)據(jù)湖、數(shù)據(jù)倉庫具備的能力介紹

針對以上使用數(shù)據(jù)湖存在的問題，我們對比一下數(shù)據(jù)平臺發(fā)展過程中經(jīng)歷的幾個階段。

（1）第一個階段是數(shù)據(jù)庫

不管是從業(yè)務(wù)的角度還是從技術(shù)棧角度，大家對數(shù)據(jù)庫都是最熟的。

（2）第二階段是數(shù)據(jù)倉庫

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

（3）第三階段是數(shù)據(jù)湖

數(shù)據(jù)湖在存儲規(guī)模和計算能力上進(jìn)一步加大，整個集群規(guī)?？梢陨先f臺，整體的能力會有更大的提升，同時擴(kuò)容更加平滑。另外它增加了很多數(shù)據(jù)庫和數(shù)倉不具備的能力，比如實(shí)時計算、機(jī)器學(xué)習(xí)。它也會有一些弱勢，比如相對前面兩個它的交互式分析能力會弱一些。

（4）第四階段是Lakehouse

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

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

4、Lakehouse架構(gòu)使得實(shí)時計算進(jìn)入流批一體階段

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

（1）Lambda實(shí)時架構(gòu)

這種架構(gòu)是Strom和Flink實(shí)時計算組件出現(xiàn)后廣泛采用的架構(gòu)，最大的特點(diǎn)就是批量與實(shí)時是存儲和計算分開的兩套架構(gòu)，因此在集群建設(shè)和開發(fā)團(tuán)隊組建上也出現(xiàn)了分開建設(shè)的情況，這樣就導(dǎo)致了流批數(shù)據(jù)共享問題、數(shù)據(jù)一致性問題和運(yùn)維問題等。同時早期流式計算的計算模型也相對比較簡單，承擔(dān)數(shù)據(jù)業(yè)務(wù)場景多聚焦于實(shí)時監(jiān)控和風(fēng)控等場景，對原有的批量業(yè)務(wù)沒有太大的增強(qiáng)。

（2）基于OLAP庫的實(shí)時架構(gòu)

這種架構(gòu)其實(shí)是對Lambda架構(gòu)的增強(qiáng)，Lambda架構(gòu)計算的結(jié)果要寫入到數(shù)據(jù)庫或者數(shù)據(jù)倉庫，以實(shí)現(xiàn)快速用數(shù)的需求，然后傳統(tǒng)數(shù)據(jù)庫或者數(shù)據(jù)倉庫在實(shí)時性上都達(dá)不到要求，因此該架構(gòu)主要也是改善這個問題，可實(shí)現(xiàn)大量數(shù)據(jù)的實(shí)時寫入，大量數(shù)據(jù)存儲以及實(shí)時查詢的需求。

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

（3）基于Lakehouse的流批一體架構(gòu)

Lakehouse這種技術(shù)出來以后，尤其是以Hudi為代表的組件，提供了增量計算的能力?；贚akehouse架構(gòu)去做流批一體能夠在數(shù)據(jù)進(jìn)行加工處理的時候支持連續(xù)實(shí)時的計算。

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

在這三種實(shí)時計算的架構(gòu)中，目前我覺得Lakehouse應(yīng)該會是實(shí)時架構(gòu)的一個大的趨勢。

二、基于Lakehouse湖內(nèi)建倉參考架構(gòu)

下面介紹基于Lakehouse湖內(nèi)建倉參考架構(gòu)。

1、統(tǒng)一的計算集群層

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

2、統(tǒng)一的元數(shù)據(jù)和權(quán)限管理層

基于數(shù)據(jù)湖構(gòu)建統(tǒng)一的數(shù)據(jù)平臺，提供了統(tǒng)一的元數(shù)據(jù)管理和數(shù)據(jù)權(quán)限管理。原來分集群建設(shè)，導(dǎo)致元數(shù)據(jù)和用戶賬號不統(tǒng)一，在數(shù)據(jù)和權(quán)限管理上也帶來很大麻煩。如果統(tǒng)一元數(shù)據(jù)和賬號體系的管理，就能更方便的做統(tǒng)一的數(shù)據(jù)管理和權(quán)限管理。

3、數(shù)據(jù)集成層

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

4、Lakehouse層

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

5、統(tǒng)一存儲集群層

底層存儲采用統(tǒng)一的對象存儲或分布式的塊存儲來解決海量數(shù)據(jù)存儲的問題。

6、多樣集市層

在整個架構(gòu)里面，即使實(shí)現(xiàn)了數(shù)據(jù)的快速的消費(fèi)，每個集市組件都有自己一定的適配場景，因此需要根據(jù)自身業(yè)務(wù)的技術(shù)要求選用合適的組件。單一一個組件很難滿足所有的數(shù)據(jù)業(yè)務(wù)要求，因此集市層建設(shè)組件可以多樣化。

現(xiàn)在有很多快速查的組件，比如Doris、ClickHouse、HBase、Redis、IotDB等?？梢越Y(jié)合業(yè)務(wù)場景要求把結(jié)果數(shù)據(jù)同步到集市層組件，這樣在業(yè)務(wù)場景中的適配度會比較高。比如要做千億級別的，甚至字段能達(dá)到幾千列的，那么使用ClickHouse的效果就會非常好，時序數(shù)據(jù)分析采用IotDB。基于傳統(tǒng)數(shù)據(jù)倉庫或者數(shù)據(jù)湖是沒有辦法達(dá)到這么高的性能。

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

三、湖內(nèi)建倉典型場景方案介紹

下面列舉幾個在湖內(nèi)建倉的典型場景。

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

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

（1）流式加工模式

所有的表都存在數(shù)據(jù)湖，基于Flink引擎/Spark引擎實(shí)現(xiàn)流式數(shù)據(jù)加工，把數(shù)據(jù)流式的寫入到湖里的表，源表數(shù)據(jù)與目標(biāo)表數(shù)據(jù)都可以長持久化存儲。

（2）增量批加工模式

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

（3）全量批加工模式

基于Hudi的鏡像讀模式，實(shí)現(xiàn)數(shù)據(jù)全量讀取。保持分區(qū)裁剪等數(shù)據(jù)過濾能力。語法邏輯與傳統(tǒng)批量作業(yè)保持一致、原有批量作業(yè)可以直接搬遷。

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

2、數(shù)據(jù)加工—數(shù)據(jù)分層模型提升數(shù)據(jù)復(fù)用率、降低資源消耗、提升計算性能（1）數(shù)據(jù)加工存在的問題

在跨業(yè)務(wù)中心數(shù)據(jù)引用的時候，各自進(jìn)行全量業(yè)務(wù)加工，導(dǎo)致出現(xiàn)數(shù)據(jù)處理量大、加工邏輯復(fù)雜、資源消耗大、時效低等問題；在業(yè)務(wù)中心內(nèi)部處理加工的時候，由于業(yè)務(wù)庫經(jīng)過長期演進(jìn)，數(shù)據(jù)模型變得更加復(fù)雜，導(dǎo)致流式加工關(guān)聯(lián)數(shù)據(jù)過多、資源消耗大、穩(wěn)定性以及時效受到挑戰(zhàn)。通常大家都習(xí)慣于用數(shù)據(jù)庫和數(shù)倉那種模式，直接寫一個非常大的SQL把結(jié)果讀出來。

有了數(shù)據(jù)湖以后，它的存儲成本相對來說要廉價很多，這時存儲成本和計算成本相比較的話，存儲成本會更低。因?yàn)榍罢叩挠梅ㄓ嬎愠杀竞芨?，耗費(fèi)了CPU和內(nèi)存，節(jié)省了硬盤，所以下面其實(shí)更應(yīng)該多用一用硬盤的存儲能力。

（2）數(shù)據(jù)分層中增加“共享層”

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

（3）數(shù)據(jù)分層的價值

首先，能夠保證各業(yè)務(wù)之間數(shù)據(jù)共享時數(shù)據(jù)口徑是一致的。

第二是降本增效，適當(dāng)?shù)卦黾右稽c(diǎn)冗余的存儲資源，可以把計算資源消耗降低，同時數(shù)據(jù)時延也降下來了，可以提升整體性能。

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

3、現(xiàn)有存量的批量數(shù)據(jù)和任務(wù)轉(zhuǎn)換為實(shí)時（按照業(yè)務(wù)需求進(jìn)行切換）

如果我們已經(jīng)有一個建好的數(shù)據(jù)湖，現(xiàn)在要上Lakehouse。如果把整個數(shù)據(jù)湖幾萬張表全部推倒重來，成本、代價、風(fēng)險都非常高。

我們建議的方式是按照業(yè)務(wù)逐步切換，切換以后數(shù)據(jù)是可以沿用的，新的業(yè)務(wù)跑實(shí)時，或者用Lakehouse的架構(gòu)去跑，老的業(yè)務(wù)繼續(xù)跑HiveSQL。即使有一些數(shù)據(jù)是交叉的，也不會影響，因?yàn)樵械腍ive技術(shù)可以讀Lakehouse的表，所以這樣去做會更加平滑。

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

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

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

5、Lakehouse的典型場景：鏡像表構(gòu)建，簡化方案、降低成本、數(shù)據(jù)事務(wù)性保證

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

增量同步方式又可以進(jìn)一步分為批量和實(shí)時，如下：

批量入湖

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

實(shí)時入湖

引入Lakehouse以后，基于Lakehouse的upsert能力實(shí)現(xiàn)數(shù)據(jù)實(shí)時入湖，構(gòu)建鏡像表會非常方便。直接把增量數(shù)據(jù)寫入湖中，如果有相同的數(shù)據(jù)，就直接更新，沒有相同的數(shù)據(jù)，就會認(rèn)為是新增的，鏡像表就能非常快的構(gòu)建出來。

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

6、Lakehouse的典型場景：拉鏈表構(gòu)建，兼顧流式計算、批量計算和數(shù)據(jù)回溯

下面再舉一個典型的場景，我們在數(shù)倉里面會構(gòu)建拉鏈表，尤其是基于TD的數(shù)倉會構(gòu)建大量的拉鏈表。拉鏈表在數(shù)倉里面針對某一個狀態(tài)有開始時間和結(jié)束時間?；跁r間戳?xí)捎锰旒?、分鐘級或者更?xì)粒度的狀態(tài)管理，只要有變化都可以保留下來。

傳統(tǒng)數(shù)倉的拉鏈表實(shí)現(xiàn)

傳統(tǒng)數(shù)倉的拉鏈表基于Start_time和End_time實(shí)現(xiàn)不同粒度的拉鏈數(shù)據(jù)；數(shù)據(jù)的寫入與讀取都是采用批量方式進(jìn)行，增量與全量表關(guān)聯(lián)得到閉鏈操作目標(biāo)數(shù)據(jù)。端到端時效性較差，T+1的數(shù)據(jù)可見性。

流批一體實(shí)現(xiàn)方案

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

四、后續(xù)規(guī)劃&挑戰(zhàn)1、挑戰(zhàn)并發(fā)挑戰(zhàn)：業(yè)務(wù)方希望能夠?qū)崿F(xiàn)單表的高的并發(fā)寫入要求。復(fù)雜事務(wù)：跨表、跨語句的事務(wù)要求。如果事務(wù)很復(fù)雜，它的回滾量會非常大，會直接影響整個集成的穩(wěn)定性。門檻高：現(xiàn)代Lakehouse功能豐富、參數(shù)配置復(fù)雜，技術(shù)門檻高。這樣在用的時候，就需要熟悉它的各種用法、各種場景，這也為落地帶來了一定挑戰(zhàn)。

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

2、后期規(guī)劃

針對這些問題，我們也做了很多規(guī)劃?？偨Y(jié)起來有兩個方向：

（1）開箱即用

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

（2）場景能力增強(qiáng)

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

五、Q&AQ1：現(xiàn)在 Lakehouse 有哪些開源版本嗎？

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

Q2;湖倉一起的架構(gòu)中，底層的存儲對于非結(jié)構(gòu)化和結(jié)構(gòu)化的數(shù)據(jù)怎么做到統(tǒng)一存儲的？他們的元數(shù)據(jù)也能統(tǒng)一管理嗎？

A：非結(jié)構(gòu)化的存儲和結(jié)構(gòu)化數(shù)據(jù)存儲在開始的時候，它的元數(shù)據(jù)肯定是沒辦法做到一起的。你比如一個文件它本身就沒有什么元數(shù)據(jù)，它只有一個文件名的概念。非結(jié)構(gòu)化存儲在做了特征模型之后，是可以統(tǒng)一去存儲的，去復(fù)用。另外關(guān)于結(jié)構(gòu)化數(shù)據(jù)在一些機(jī)器學(xué)習(xí)里面，它也會有一些特征的處理，特征以后的數(shù)據(jù)是可以去做統(tǒng)一存儲的。

如果是原始數(shù)據(jù)，統(tǒng)一存儲在元數(shù)據(jù)層其實(shí)就是文件系統(tǒng)的元數(shù)據(jù)了。

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

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

比如我們希望數(shù)據(jù)處理的端到端更快，其實(shí)它可以在我們原有的離線數(shù)據(jù)分層上適當(dāng)?shù)厝ヌ惶热鐝拿骷?xì)層直接跳到結(jié)果層、應(yīng)用層。在有些分層，比如我們貼源層是結(jié)構(gòu)化數(shù)據(jù)，本身它的數(shù)據(jù)質(zhì)量相對比較高，這個時候也可以從貼源層直接跳到應(yīng)用層。總之，按照不同時效、不同業(yè)務(wù)要求，它的分層會比較靈活。

關(guān)鍵詞：