編輯導讀：在數據分析中，實時數據倉庫很重要，它決定了報表和BI到底能不能實時展現數據。但很多人可能都對它不夠了解，本文作者結合自己的工作實踐，從7個方面分享了數據倉庫建設的相關步驟和需要注意的問題，一起來看看~
之前發了一篇數據倉庫的文章，發現大家對數據倉庫還是非常感興趣的。今天再和大家一起聊聊實時數倉吧！
實時數倉可謂是決定性的東西，能決定什麼？決定你的報表和BI到底能不能實時展現數據。
01 數據倉庫的發展趨勢
1.1 數據倉庫的趨勢
關於數據倉庫的概念就不多介紹了。
數據倉庫是伴隨著企業信息化發展起來的，在企業信息化的過程中，隨著信息化工具的升級和新工具的應用，數據量變得越來越大，數據格式越來越多，決策要求越來越苛刻，數據倉庫技術也在不停的發展。
數據倉庫的趨勢：
實時數據倉庫以滿足實時化&自動化決策需求大數據&數據可以支持大量&複雜數據類型
1.2 數據倉庫的發展
數據倉庫有兩個環節：數據倉庫的構建與數據倉庫的應用。
早期數據倉庫構建主要指的是把企業的業務資料庫如 ERP、CRM、SCM 等數據按照決策分析的要求建模並匯總到數據倉庫引擎中，其應用以報表為主，目的是支持管理層和業務人員決策（中長期策略性決策）。
隨著業務和環境的發展，這兩方面都在發生著劇烈變化。
隨著IT技術走向網際網路、移動化，數據源變得越來越豐富，在原來業務資料庫的基礎上出現了非結構化數據，比如網站 log，IoT 設備數據，APP 埋點數據等，這些數據量比以往結構化的數據大了幾個量級，對 ETL 過程、存儲都提出了更高的要求。
網際網路的在線特性也將業務需求推向了實時化，隨時根據當前客戶行為而調整策略變得越來越常見，比如大促過程中庫存管理，運營管理等（即既有中遠期策略型，也有短期操作型）；同時公司業務網際網路化之後導致同時服務的客戶劇增，有些情況人工難以完全處理，這就需要機器自動決策，比如欺詐檢測和用戶審核。
總結來看，對數據倉庫的需求可以抽象成兩方面：實時產生結果、處理和保存大量異構數據。
02 數據倉庫架構的演變
從1990年 Inmon 提出數據倉庫概念到今天，數據架構經歷了最初的傳統數倉架構——離線數倉庫——離線大數據架構、Lambda 架構、Kappa 架構以及 Flink 的火熱帶出的流批一體架構，數據架構技術不斷演進，本質是在往流批一體的方向發展，讓用戶能以最自然、最小的成本完成實時計算。
2.1 傳統數倉架構
這是比較傳統的一種方式，結構或半結構化數據通過離線ETL定期加載到離線數據，之後通過計算引擎取得結果，供前端使用。這裡的離線數倉+計算引擎，通常是使用大型商業資料庫來承擔，例如Oracle、DB2、Teradata等。
2.2 離線大數據架構
隨著數據規模的不斷增大，傳統數倉方式難以承載海量數據。隨著大數據技術的普及，採用大數據技術來承載存儲與計算任務。當然，也可以使用傳傳統資料庫集群或MPP架構資料庫來完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。
2.3 Lambda架構
隨著業務的發展，隨著業務的發展，人們對數據實時性提出了更高的要求。此時，出現了Lambda架構，其將對實時性要求高的部分拆分出來，增加條實時計算鏈路。從源頭開始做流式改造，將數據發送到消息隊列中，實時計算引擎消費隊列數據，完成實時數據的增量計算。
與此同時，批量處理部分依然存在，實時與批量並行運行。最終由統一的數據服務層合併結果給予前端。一般是以批量處理結果為準，實時結果主要為快速響應。
2.4 Kappa架構
Lambda架構，一個比較嚴重的問題就是需要維護兩套邏輯。一部分在批量引擎實現，一部分在流式引擎實現，維護成本很高。此外，對資源消耗也較大。而後面誕生的Kappa架構，正是為了解決上述問題。其在數據需要重新處理或數據變更時，可通過歷史數據重新處理來完成。
方式是通過上遊重放完成(從數據源拉取數據重新計算)。Kappa架構最大的問題是流式重新處理歷史的吞吐能力會低於批處理，但這個可以通過增加計算資源來彌補。
2.5混合架構
上述架構各有其適應場景，有時需要綜合使用上述架構組合滿足實際需求。當然這也必將帶來架構的複雜度。用戶應根據自身需求，有所取捨。在一般大多數場景下，是可以使用單一架構解決問題。現在很多產品在流批一體、海量、實時性方面也有非常好的表現，可以考慮這種「全能手」解決問題。
03 三種大數據數據倉庫架構
3.1 離線大數據架構
數據源通過離線的方式導入到離線數據中。下遊應用根據業務需求選擇直接讀取 DM 或加一層數據服務，比如 MySQL 或 Redis。數據倉庫從模型層面分為三層：
ODS，操作數據層，保存原始數據；DWD，數據倉庫明細層，根據主題定義好事實與維度表，保存最細粒度的事實數據；DM，數據集市/輕度匯總層，在 DWD 層的基礎之上根據不同的業務需求做輕度匯總；典型的數倉存儲是 HDFS/Hive，ETL 可以是 MapReduce 腳本或 HiveSQL。
3.2 Lambda 架構
Lambda 架構問題：
同樣的需求需要開發兩套一樣的代碼：這是 Lambda 架構最大的問題，兩套代碼不僅僅意味著開發困難（同樣的需求，一個在批處理引擎上實現，一個在流處理引擎上實現，還要分別構造數據測試保證兩者結果一致），後期維護更加困難，比如需求變更後需要分別更改兩套代碼，獨立測試結果，且兩個作業需要同步上線。
資源佔用增多：同樣的邏輯計算兩次，整體資源佔用會增多，多出實時計算這部分。
3.3 Kappa 架構
Lambda 架構雖然滿足了實時的需求，但帶來了更多的開發與運維工作，其架構背景是流處理引擎還不完善，流處理的結果只作為臨時的、近似的值提供參考。後來隨著 Flink 等流處理引擎的出現，流處理技術很成熟了，這是為了解決兩套代碼的問題，LickedIn 的 Jay Kreps 提出了 Kappa 架構。
Kappa 架構可以認為是 Lambda 架構的簡化版（只要移除 lambda 架構中的批處理部分即可）。
在 Kappa 架構中，需求修改或歷史數據重新處理都通過上遊重放完成。
Kappa 架構最大的問題是流式重新處理歷史的吞吐能力會低於批處理，但這個可以通過增加計算資源來彌補。
Kappa 架構的重新處理過程：
3.4 Lambda 架構與 Kappa 架構的對比
在真實的場景中，很多時候並不是完全規範的 Lambda 架構或 Kappa 架構，可以是兩者的混合，比如大部分實時指標使用 Kappa 架構完成計算，少量關鍵指標（比如金額相關）使用 Lambda 架構用批處理重新計算，增加一次校對過程。
Kappa 架構並不是中間結果完全不落地，現在很多大數據系統都需要支持機器學習（離線訓練），所以實時中間結果需要落地對應的存儲引擎供機器學習使用，另外有時候還需要對明細數據查詢，這種場景也需要把實時明細層寫出到對應的引擎中。後面案例會涉及到。
04 實時數倉建設思路
計算框架選型：storm/flink等實時計算框架，強烈推薦flink，其『批量合一』的特性及活躍的開源社區，有逐漸替代spark的趨勢。數據存儲選型：首要考慮查詢效率，其次是插入、更新等問題，可選擇apache druid，不過在數據更新上存在缺陷，選型時注意該問題頻繁更新的數據建議不要採用該方案。當然存儲這塊需要具體問題具體分析，不同場景下hbase、redis等都是可選項。實時數倉分層：為更好的統一管理數據，實時數倉可採用離線數倉的數據模型進行分層處理，可以分為實時明細層寫入druid等查詢效率高的存儲方便下遊使用；輕度匯總層對數據進行匯總分析後供下遊使用。數據流轉方案：實時數倉的數據來源可以為kafka消息隊列，這樣可以做到隊列中的數據即可以寫入數據湖用於批量分析，也可以實時處理，下遊可以寫入數據集市供業務使。
05 菜鳥實時數倉案例
最後分享菜鳥倉配實時數據倉庫的案例本，涉及全局設計、數據模型、數據保障等幾個方面。
5.1 整體設計
整體設計如下圖，基於業務系統的數據，數據模型採用中間層的設計理念，建設倉配實時數倉；計算引擎，選擇更易用、性能表現更佳的實時計算作為主要的計算引擎；數據服務，選擇天工數據服務中間件，避免直連資料庫，且基於天工可以做到主備鏈路靈活配置秒級切換；數據應用，圍繞大促全鏈路，從活動計劃、活動備貨、活動直播、活動售後、活動復盤五個維度，建設倉配大促數據體系。
5.2 數據模型
不管是從計算成本，還是從易用性，還是從復用性，還是從一致性等等，都必須避免煙囪式的開發模式，而是以中間層的方式建設倉配實時數倉。與離線中間層基本一致，將實時中間層分為兩層。
第一層 DWD 公共實時明細層。實時計算訂閱業務數據消息隊列，然後通過數據清洗、多數據源 join、流式數據與離線維度信息等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加數據易用性和復用性，得到最終的實時明細數據。這部分數據有兩個分支，一部分直接落地到 ADS，供實時明細查詢使用，一部分再發送到消息隊列中，供下層計算使用。第二層 DWS 公共實時匯總層。以數據域+業務域的理念建設公共匯總層，與離線數倉不同的是，這裡匯總層分為輕度匯總層和高度匯總層，並同時產出，輕度匯總層寫入 ADS，用於前端產品複雜的 olap 查詢場景，滿足自助分析和產出報表的需求；高度匯總層寫入 Hbase，用於前端比較簡單的 kv 查詢場景，提升查詢性能，比如實時大屏等。
06 美團點評基於Flink的實時數倉平臺實踐
最底層是收集層，這一層負責收集用戶的實時數據，包括 Binlog、後端服務日誌以及 IoT 數據，經過日誌收集團隊和 DB 收集團隊的處理，數據將會被收集到 Kafka 中。這些數據不只是參與實時計算，也會參與離線計算。
收集層之上是存儲層，這一層除了使用 Kafka 做消息通道之外，還會基於 HDFS 做狀態數據存儲以及基於 HBase 做維度數據的存儲。
存儲層之上是引擎層，包括 Storm 和 Flink。實時計算平臺會在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持。
在引擎層之上就是平臺層了，平臺層從數據、任務和資源三個視角去管理。
架構的最上層是應用層，包括了實時數倉、機器學習、數據同步以及事件驅動應用等。
從功能角度來看，美團點評的實時計算平臺主要包括作業和資源管理兩個方面的功能。其中，作業部分包括作業配置、作業發布以及作業狀態三個方面的功能。
在作業配置方面，則包括作業設置、運行時設置以及拓撲結構設置；在作業發布方面，則包括版本管理、編譯/發布/回滾等；作業狀態則包括運行時狀態、自定義指標和報警以及命令/運行時日誌等。在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力。
07 實時數倉與離線數倉的對比
在看過前面的案例之後，我們看一下實時數倉與離線數倉在幾方面的對比：
首先，從架構上，實時數倉與離線數倉有比較明顯的區別，實時數倉以 Kappa 架構為主，而離線數倉以傳統大數據架構為主。Lambda 架構可以認為是兩者的中間態。其次，從建設方法上，實時數倉和離線數倉基本還是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流數據的 join 有隱藏時間語義，在建設中需注意。最後，從數據保障看，實時數倉因為要保證實時性，所以對數據量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線數據的一個較為明顯的區別。綜上，實時數倉主要解決數據時效性問題，結合機器學習框架可以處理實時推薦、實時獲取廣告投放效果等智能化業務場景。實時數倉的建設應早日提上日程，未來企業對數據時效性的要求會越來越高，實時數倉會很好的解決該問題。
本文由 @李啟方 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議