一文詳解實時數(shù)據(jù)倉庫的發(fā)展、架構(gòu)和趨勢

數(shù)據(jù)處理現(xiàn)狀：當前基于Hive的離線數(shù)據(jù)倉庫已經(jīng)非常成熟，數(shù)據(jù)中臺體系也基本上是圍繞離線數(shù)倉進行建設(shè)。但是隨著實時計算引擎的不斷發(fā)展以及業(yè)務(wù)對于實時報表的產(chǎn)出需求不斷膨脹，業(yè)界最近幾年就一直聚焦并探索于兩個相關(guān)的熱點問題：實時數(shù)倉建設(shè)和大數(shù)據(jù)架構(gòu)的批流一體建設(shè)。

1實時數(shù)倉建設(shè)：實時數(shù)倉1.0

傳統(tǒng)意義上我們通常將數(shù)據(jù)處理分為離線數(shù)據(jù)處理和實時數(shù)據(jù)處理。對于實時處理場景，我們一般又可以分為兩類，一類諸如監(jiān)控報警類、大屏展示類場景要求秒級甚至毫秒級；另一類諸如大部分實時報表的需求通常沒有非常高的時效性要求，一般分鐘級別，比如10分鐘甚至30分鐘以內(nèi)都可以接受。

對于第一類實時數(shù)據(jù)場景來說，業(yè)界通常的做法比較簡單粗暴，一般也不需要非常仔細地進行數(shù)據(jù)分層，數(shù)據(jù)直接通過Flink計算或者聚合之后將結(jié)果寫入MySQL/ES/HBASE/Druid/Kudu等，直接提供應(yīng)用查詢或者多維分析。如下所示：

而對于后者來說，通常做法會按照數(shù)倉結(jié)構(gòu)進行設(shè)計，我們稱后者這種應(yīng)用場景為實時數(shù)倉，將作為本篇文章討論的重點。從業(yè)界情況來看，當前主流的實時數(shù)倉架構(gòu)基本都是基于Kafka+Flink的架構(gòu)（為了行文方便，就稱為實時數(shù)倉1.0）。下圖是基于業(yè)界各大公司分享的實時數(shù)倉架構(gòu)抽象的一個方案：

這套架構(gòu)總體依然遵循標準的數(shù)倉分層結(jié)構(gòu)，各種數(shù)據(jù)首先匯聚于ODS數(shù)據(jù)接入層。再接著經(jīng)過這些來源明細數(shù)據(jù)的數(shù)據(jù)清洗、過濾等操作，完成多來源同類明細數(shù)據(jù)的融合，形成面向業(yè)務(wù)主題的DWD數(shù)據(jù)明細層。在此基礎(chǔ)上進行輕度的匯總操作，形成一定程度上方便查詢的DWS輕度匯總層（注：這里沒有畫出DIM維度層，一般選型為Redis/HBase，下文架構(gòu)圖中同樣沒有畫出DIM維度層，在此說明）。最后再面向業(yè)務(wù)需求，在DWS層基礎(chǔ)上進一步對數(shù)據(jù)進行組織進入ADS數(shù)據(jù)應(yīng)用層，業(yè)務(wù)在數(shù)據(jù)應(yīng)用層的基礎(chǔ)上支持用戶畫像、用戶報表等業(yè)務(wù)場景。

基于Kafka+Flink的這套架構(gòu)方案很好的解決了實時數(shù)倉對于時效性的業(yè)務(wù)訴求，通常延遲可以做到秒級甚至更短。基于上圖所示實時數(shù)倉架構(gòu)方案，筆者整理了一個目前業(yè)界比較主流的整體數(shù)倉架構(gòu)方案：

上圖中上層鏈路是離線數(shù)倉數(shù)據(jù)流轉(zhuǎn)鏈路，下層鏈路是實時數(shù)倉數(shù)據(jù)流轉(zhuǎn)鏈路，當然實際情況可能是很多公司在實時數(shù)倉建設(shè)中并沒有嚴格按照數(shù)倉分層結(jié)構(gòu)進行分層，與上圖稍有不同。

然而基于Kafka+Flink的實時數(shù)倉方案有幾個非常明顯的缺陷：

（1）Kafka無法支持海量數(shù)據(jù)存儲。對于海量數(shù)據(jù)量的業(yè)務(wù)線來說，Kafka一般只能存儲非常短時間的數(shù)據(jù)，比如最近一周，甚至最近一天；

（2）Kafka無法支持高效的OLAP查詢。大多數(shù)業(yè)務(wù)都希望能在DWDDWS層支持即席查詢的，但是Kafka無法非常友好地支持這樣的需求；

（3）無法復用目前已經(jīng)非常成熟的基于離線數(shù)倉的數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系。需要重新實現(xiàn)一套數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系；

（4）Lambad架構(gòu)維護成本很高。很顯然，這種架構(gòu)下數(shù)據(jù)存在兩份、schema不統(tǒng)一、 數(shù)據(jù)處理邏輯不統(tǒng)一，整個數(shù)倉系統(tǒng)維護成本很高；

（5）Kafka不支持update/upsert。目前Kafka僅支持append。實際場景中在DWS輕度匯聚層很多時候是需要更新的，DWD明細層到DWS輕度匯聚層一般會根據(jù)時間粒度以及維度進行一定的聚合，用于減少數(shù)據(jù)量，提升查詢性能。假如原始數(shù)據(jù)是秒級數(shù)據(jù)，聚合窗口是1分鐘，那就有可能產(chǎn)生某些延遲的數(shù)據(jù)經(jīng)過時間窗口聚合之后需要更新之前數(shù)據(jù)的需求。這部分更新需求無法使用Kafka實現(xiàn)。

所以實時數(shù)倉發(fā)展到現(xiàn)在的架構(gòu)，一定程度上解決了數(shù)據(jù)報表時效性問題，但是這樣的架構(gòu)依然存在不少問題，隨著技術(shù)的發(fā)展，相信基于Kafka+Flink的實時數(shù)倉架構(gòu)也會進一步往前發(fā)展。那會往哪里發(fā)展呢？

大數(shù)據(jù)架構(gòu)的批流一體建設(shè)。

帶著上面的問題我們再來接著聊一聊最近一兩年和實時數(shù)倉一樣很火的另一個概念：批流一體。對于批流一體的理解，筆者發(fā)現(xiàn)有很多種解讀，比如有些業(yè)界前輩認為批和流在開發(fā)層面上都統(tǒng)一到相同的SQL上是批流一體，又有些前輩認為在計算引擎層面上批和流可以集成在同一個計算引擎是批流一體，比如Spark/Spark Structured Streaming就算一個在計算引擎層面實現(xiàn)了批流一體的計算框架，與此同時另一個計算引擎Flink，目前在流處理方面已經(jīng)做了很多的工作而且在業(yè)界得到了普遍的認可，但在批處理方面還有一定的路要走。

2實時數(shù)倉2.0

筆者認為無論是業(yè)務(wù)SQL使用上的統(tǒng)一還是計算引擎上的統(tǒng)一，都是批流一體的一個方面。除此之外，批流一體還有一個最核心的方面，那就是存儲層面上的統(tǒng)一。在這個方面業(yè)界也有一些走在前面的技術(shù)，比如最近一段時間開始流行起來的數(shù)據(jù)湖三劍客-- delta/hudi/iceberg，就在往這個方向走。存儲一旦能夠做到統(tǒng)一，上述數(shù)據(jù)倉庫架構(gòu)就會變成如下模樣（以Iceberg數(shù)據(jù)湖作為統(tǒng)一存儲為例），稱為實時數(shù)倉2.0：

這套架構(gòu)中無論是流處理還是批處理，數(shù)據(jù)存儲都統(tǒng)一到數(shù)據(jù)湖Iceberg上。那這么一套架構(gòu)將存儲統(tǒng)一后有什么好處呢？很明顯，可以解決Kafka+Flink架構(gòu)實時數(shù)倉存在的前面4個問題：

（1）可以解決Kafka存儲數(shù)據(jù)量少的問題。目前所有數(shù)據(jù)湖基本思路都是基于HDFS之上實現(xiàn)的一個文件管理系統(tǒng)，所以數(shù)據(jù)體量可以很大。

（2）DW層數(shù)據(jù)依然可以支持OLAP查詢。同樣數(shù)據(jù)湖基于HDFS之上實現(xiàn)，只需要當前的OLAP查詢引擎做一些適配就可以進行OLAP查詢。

（3）批流存儲都基于Iceberg/HDFS存儲之后，就完全可以復用一套相同的數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系。

（4）Kappa架構(gòu)相比Lambad架構(gòu)來說，schema統(tǒng)一，數(shù)據(jù)處理邏輯統(tǒng)一，用戶不再需要維護兩份數(shù)據(jù)。

有的同學說了，這不，你直接解決了前4個問題嘛，還有第5個問題呢？對，第5個問題下文會講到。

又有的同學會說了，上述架構(gòu)確實解決了Lambad架構(gòu)的諸多問題，但是這套架構(gòu)看起來就像是一條離線處理鏈路，它是怎么做到報表實時產(chǎn)出呢？確實，上述架構(gòu)圖主要將離線處理鏈路上的HDFS換成了數(shù)據(jù)湖Iceberg，就號稱可以實現(xiàn)實時數(shù)倉，聽起來容易讓人迷糊。這里的關(guān)鍵就是數(shù)據(jù)湖Iceberg，它到底有什么魔力？

為了回答這個問題，筆者就上述架構(gòu)以及數(shù)據(jù)湖技術(shù)本身做一個簡單的介紹（接下來也會基于Iceberg出一個專題深入介紹數(shù)據(jù)湖技術(shù)）。上述架構(gòu)圖中有兩條數(shù)據(jù)處理鏈路，一條是基于Flink的實時數(shù)據(jù)鏈路，一條是基于Spark的離線數(shù)據(jù)鏈路。通常數(shù)據(jù)都是直接走實時鏈路處理，而離線鏈路則更多的應(yīng)用于數(shù)據(jù)修正等非常規(guī)場景。這樣的架構(gòu)要成為一個可以落地的實時數(shù)倉方案，數(shù)據(jù)湖Iceberg是需要滿足如下幾個要求的：

（1）支持流式寫入-增量拉取。流式寫入其實現(xiàn)在基于Flink就可以實現(xiàn)，無非是將checkpoint間隔設(shè)置的短一點，比如1分鐘，就意味每分鐘生成的文件就可以寫入到HDFS，這就是流式寫入。沒錯，但是這里有兩個問題，第一個問題是小文件很多，但這不是最關(guān)鍵的，第二個問題才是最致命的，就是上游每分鐘提交了很多文件到HDFS上，下游消費的Flink是不知道哪些文件是最新提交的，因此下游Flink就不知道應(yīng)該去消費處理哪些文件。這個問題才是離線數(shù)倉做不到實時的最關(guān)鍵原因之一，離線數(shù)倉的玩法是說上游將數(shù)據(jù)全部導入完成了，告訴下游說這波數(shù)據(jù)全部導完了，你可以消費處理了，這樣的話就做不到實時處理。

數(shù)據(jù)湖就解決了這個問題。實時數(shù)據(jù)鏈路處理的時候上游Flink寫入的文件進來之后，下游就可以將數(shù)據(jù)文件一致性地讀走。這里強調(diào)一致性地讀，就是不能多讀一個文件也不能少讀一個文件。上游這段時間寫了多少文件，下游就要讀走多少文件。我們稱這樣的讀取叫增量拉取。

（2）解決小文件多的問題。數(shù)據(jù)湖實現(xiàn)了相關(guān)合并小文件的接口，Spark/Flink上層引擎可以周期性地調(diào)用接口進行小文件合并。

（3）支持批量以及流式的Upsert(Delete)功能。批量Upsert/Delete功能主要用于離線數(shù)據(jù)修正。流式upsert場景上文介紹了，主要是流處理場景下經(jīng)過窗口時間聚合之后有延遲數(shù)據(jù)到來的話會有更新的需求。這類需求是需要一個可以支持更新的存儲系統(tǒng)的，而離線數(shù)倉做更新的話需要全量數(shù)據(jù)覆蓋，這也是離線數(shù)倉做不到實時的關(guān)鍵原因之一，數(shù)據(jù)湖是需要解決掉這個問題的。

（4）支持比較完整的OLAP生態(tài)。比如支持Hive/Spark/Presto/Impala等OLAP查詢引擎，提供高效的多維聚合查詢性能。

這里需要備注一點，目前Iceberg部分功能還在開發(fā)中。具體技術(shù)層面Iceberg是怎么解決上述問題的，請持續(xù)關(guān)注本號，接下來一篇文章會詳細講解哦。

3實時數(shù)倉3.0

按照批流一體上面的探討，如果計算引擎做到了批流一體的統(tǒng)一，就可以做到SQL統(tǒng)一、計算統(tǒng)一以及存儲統(tǒng)一，這時就邁入實時數(shù)倉3.0時代。對于以Spark為核心技術(shù)棧的公司來說，實時數(shù)倉2.0的到來就意味著3.0的到來，因為在計算引擎層面Spark早已做到批流一體?；赟park/數(shù)據(jù)湖的3.0架構(gòu)如下圖：

假如未來Flink在批處理領(lǐng)域成熟到一定程度，基于Flink/數(shù)據(jù)湖的3.0架構(gòu)如下圖：

上面所介紹的，是筆者認為接下來幾年數(shù)據(jù)倉庫發(fā)展的一個可能路徑。對于業(yè)界目前實時數(shù)倉的一個發(fā)展預(yù)估，個人覺得目前業(yè)界大多公司都還往實時數(shù)倉1.0這個架構(gòu)上靠；而在接下來1到2年時間隨著數(shù)據(jù)湖技術(shù)的成熟，實時數(shù)倉2.0架構(gòu)會成為越來越多公司的選擇，其實到了2.0時代之后，業(yè)務(wù)同學最關(guān)心的報表實時性訴求和大數(shù)據(jù)平臺同學最關(guān)心的數(shù)據(jù)存儲一份訴求都可以解決；隨著計算引擎的成熟，實時數(shù)倉3.0可能和實時數(shù)倉2.0一起或者略微滯后一些普及。

編輯：jq