目前大數(shù)據(jù)架構(gòu)已經(jīng)走向了數(shù)據(jù)湖時代，無論是單純的批處理模式，還是同時支持實時和離線數(shù)據(jù)處理的Lambda架構(gòu)都已經(jīng)過時。均不再適應(yīng)現(xiàn)在大數(shù)據(jù)的業(yè)務(wù)發(fā)展需要。

一 Lambda架構(gòu)

相信現(xiàn)在還有很多公司公司的數(shù)據(jù)架構(gòu)仍然是Lambda架構(gòu)，它解決了這些公司大數(shù)據(jù)的離線和實時數(shù)據(jù)處理，一個典析的Lambda架構(gòu)如下圖所示：

Lambda架構(gòu)

從底層的數(shù)據(jù)源開始，通過Kafka、Flume等大數(shù)據(jù)組件，將各種各樣的數(shù)據(jù)同步到大數(shù)據(jù)平臺，然后分成兩條線進(jìn)行計算。一條線進(jìn)入離線批量數(shù)據(jù)處理平臺（Spark、Hive、MapReduce等），去計算T+1或者H+1的業(yè)務(wù)指標(biāo)，這些指標(biāo)需要T+1或者H+1才能看到；另外一條線是進(jìn)入到實時數(shù)據(jù)處理平臺（Flink、SparkStreaming等），去計算實時統(tǒng)計指標(biāo)。

經(jīng)過多年的發(fā)展，Lambda架構(gòu)比較穩(wěn)定，能滿足過去的應(yīng)用場景。但是它有很多致命的弱點：

1.1 數(shù)據(jù)口徑不一致問題

因為離線和實時計算走的是兩個完全不同的代碼，算出來的結(jié)果往往不同，可能會當(dāng)天看到一個結(jié)果數(shù)據(jù)，第二天發(fā)現(xiàn)數(shù)據(jù)變成了。

1.2 T+1離線嚴(yán)重超時

像新浪微博這種體量的公司，每天有400TB+的數(shù)據(jù)寫入大數(shù)據(jù)平臺，而且數(shù)據(jù)在不斷地增加。我們經(jīng)常會發(fā)現(xiàn)在夜間3-4個小時內(nèi)，離線程序執(zhí)行不完，不能保證數(shù)據(jù)在上班之前準(zhǔn)時生成。尤其是在夜間發(fā)生故障之后，白天的數(shù)據(jù)產(chǎn)出時間更加難以把控。

1.3 需要維護(hù)兩套代碼

每次數(shù)據(jù)源有變化，或者業(yè)務(wù)方有新的需求。都要修改兩次業(yè)務(wù)邏輯代碼，既要修改離線的ETL任務(wù)，又要修改流式任務(wù)，開發(fā)周期很長（工作量是雙倍），人力成本比較大。

為了解決Lambda架構(gòu)的痛點，就產(chǎn)生了KAppa架構(gòu)，相信大家對這個架構(gòu)也非常熟悉。

二 Kappa架構(gòu)

針對Lambda架構(gòu)需要維護(hù)兩套程序的缺點，后面產(chǎn)生了Kappa架構(gòu)。Kappa架構(gòu)的核心思想是，改進(jìn)流計算系統(tǒng)來解決全量數(shù)據(jù)，讓實時和離線處理過程采用同一套代碼。Kappa架構(gòu)的初衷是，只有在必要的時候才會對歷史數(shù)據(jù)進(jìn)行重新計算。下圖是Kappa架構(gòu)模型：

Kappa架構(gòu)

Kappa架構(gòu)也不是完美的，它也有很多問題。

2.1 鏈路更加混亂復(fù)雜

首先，我們需要借用Kafka來構(gòu)建實時場景，但是如果需要對ODS層數(shù)據(jù)做進(jìn)一步的分析時，就要接入Flink計算引擎把數(shù)據(jù)寫入到DWD層的Kafka，同樣也會將一部分結(jié)果數(shù)據(jù)寫入到DWS層的Kafka。但是，如果想做簡單的數(shù)據(jù)分析時，又要將DWD和DWS層的數(shù)據(jù)寫入到ClickHouse、ES、MySQL或者是Hive里做進(jìn)一步分析，這無疑帶來了鏈路的復(fù)雜性。

2.2 數(shù)據(jù)一致性受到挑戰(zhàn)

其次，Kappa架構(gòu)是嚴(yán)重依賴于消息隊列的，我們知道消息隊列本身的準(zhǔn)確性嚴(yán)格依賴它上游數(shù)據(jù)的順序，但是，消息隊列越多，發(fā)生亂序的可能性越大。通常情況下，ODS層的數(shù)據(jù)是絕對準(zhǔn)確的，把ODS層數(shù)據(jù)經(jīng)過計算之后寫入到DWD層時就會產(chǎn)生亂序，DWD到DWS更容易產(chǎn)生亂序，這樣的數(shù)據(jù)不一致性問題非常大。

那么有沒有一種架構(gòu)，既能滿足實時性的需求，又能滿足離線計算的需求，同時還能減輕運營開發(fā)成本？解決Kappa架構(gòu)的痛點呢？

2.3 實時數(shù)據(jù)倉庫建設(shè)需求

是否有一種技術(shù)，既能夠保證數(shù)據(jù)高效的回溯能力，支持?jǐn)?shù)據(jù)更新，又能夠?qū)崿F(xiàn)數(shù)據(jù)的流批讀寫，并且還能夠?qū)崿F(xiàn)分鐘級別的數(shù)據(jù)接入。

這也是建設(shè)實時數(shù)據(jù)倉庫的迫切需要，實際上需要對Kappa架構(gòu)進(jìn)行改進(jìn)升級，以解決Kappa架構(gòu)中遇到的問題，接下來我們會進(jìn)一步探討數(shù)據(jù)湖技術(shù)--Iceberg。

實時數(shù)倉的要求

三 Flink+Iceberg構(gòu)建實時數(shù)倉

3.1 準(zhǔn)實時數(shù)據(jù)倉庫分析系統(tǒng)

我們知道Iceberg支持讀寫分離，又支持并發(fā)讀、增量讀、合并小文件，而且還能做到秒級/分鐘級的數(shù)據(jù)延遲。我們基于Iceberg這些優(yōu)勢，采用Flink+Iceberg的方式構(gòu)建了流批一體化的實時數(shù)據(jù)倉庫。

Flink+Iceberg架構(gòu)

在數(shù)據(jù)倉庫處理層，可以用 presto 進(jìn)行一些簡單的查詢，因為 Iceberg 支持 Streaming read，所以在系統(tǒng)的中間層也可以直接接入 Flink，直接在中間層用 Flink 做一些批處理或者流式計算的任務(wù)，把中間結(jié)果做進(jìn)一步計算后輸出到下游。

3.2 采用Iceberg替代Kafka實時數(shù)倉的優(yōu)劣勢

升級后的問題

四 未來規(guī)劃

4.1 Iceberg 內(nèi)核能力提升

• Row-level delete 功能。目前社區(qū)還不支持行級別的刪除功能，Iceberg 當(dāng)前只支持 copy on write 的 update 的能力。如果要真正地構(gòu)建一個實時數(shù)據(jù)倉庫，還是需要一個高效的 merge on read 的 update 能力。我們會繼續(xù)根據(jù)社區(qū)的更新動態(tài)，逐步迭代升級。
• 建立統(tǒng)一索引加速數(shù)據(jù)檢索。期待社區(qū)會有一個完善的統(tǒng)一索引加速功能。

4.2 內(nèi)部大數(shù)據(jù)平臺升級

希望借助Alluxio構(gòu)建一個數(shù)據(jù)湖加速功能，以便在查詢層實現(xiàn)秒級分析功能。

建立自動Schema建表的功能。

和所有業(yè)務(wù)系統(tǒng)打通，逐步遷移完成所有業(yè)務(wù)線的數(shù)據(jù)湖建設(shè)。