目前大數據架構已經走向了數據湖時代，無論是單純的批處理模式，還是同時支持實時和離線數據處理的Lambda架構都已經過時。均不再適應現在大數據的業務發展需要。

一 Lambda架構

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

Lambda架構

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

經過多年的發展，Lambda架構比較穩定，能滿足過去的應用場景。但是它有很多致命的弱點：

1.1 數據口徑不一致問題

因為離線和實時計算走的是兩個完全不同的代碼，算出來的結果往往不同，可能會當天看到一個結果數據，第二天發現數據變成了。

1.2 T+1離線嚴重超時

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

1.3 需要維護兩套代碼

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

為了解決Lambda架構的痛點，就產生了KAppa架構，相信大家對這個架構也非常熟悉。

二 Kappa架構

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

Kappa架構

Kappa架構也不是完美的，它也有很多問題。

2.1 鏈路更加混亂復雜

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

2.2 數據一致性受到挑戰

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

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

2.3 實時數據倉庫建設需求

是否有一種技術，既能夠保證數據高效的回溯能力，支持數據更新，又能夠實現數據的流批讀寫，并且還能夠實現分鐘級別的數據接入。

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

實時數倉的要求

三 Flink+Iceberg構建實時數倉

3.1 準實時數據倉庫分析系統

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

Flink+Iceberg架構

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

3.2 采用Iceberg替代Kafka實時數倉的優劣勢

升級后的問題

四 未來規劃

4.1 Iceberg 內核能力提升

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

4.2 內部大數據平臺升級

希望借助Alluxio構建一個數據湖加速功能，以便在查詢層實現秒級分析功能。

建立自動Schema建表的功能。

和所有業務系統打通，逐步遷移完成所有業務線的數據湖建設。