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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2實(shí)時(shí)數(shù)倉2.0

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

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

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

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

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

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

有的同學(xué)說了，這不，你直接解決了前4個(gè)問題嘛，還有第5個(gè)問題呢？對(duì)，第5個(gè)問題下文會(huì)講到。

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

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

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

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

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

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

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

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

3實(shí)時(shí)數(shù)倉3.0

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

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

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

編輯：jq