去年，實時數據倉庫的概念突然變得非常流行。可能是因為傳統的離線數據倉庫已經發展了多年，技術相對成熟，所以大家開始將注意力放在更具挑戰性的實時數據倉庫上；也可能是隨著存量市場競爭的到來，對于數據獲取速度的要求越來越高，T+1的數據獲取無法滿足需求，因此實時構建數據的需求也應運而生。

實時數據倉庫的技術要求：

1. 高并發性：未來實時數據不僅僅是為幾個運營或管理層人員使用，更會面向商戶和用戶。隨著用戶數量的增加，會帶來并發量的增加。因此，實時數據倉庫必須具備提供高并發數據服務的能力。

   
   

2. 查詢速度：目前許多實時指標的應用場景是移動端，移動端對數據響應速度的要求遠高于PC端。大多數數據使用場景希望能夠在毫秒級返回數據。未來，如果將實時標簽應用于用戶推薦中，對響應速度的要求將更高。

   
   

3. 處理速度：在大促銷期間，需要具備極強的處理能力，能夠應對流量峰值的情況。還需要具備低延遲甚至零延遲的消費能力。

   
   

實時數據倉庫的技術基礎：流式技術架構 目前，流式計算框架相對成熟，開源組件如Storm、Spark Streaming和Flink得到廣泛應用。簡單來說，流式數據處理是指系統每產生一條數據，都會立即采集并發送到流式任務中心進行處理，無需額外的定時調度。

業界廣泛采用的框架有Twitter的Storm、Apache的Spark Streaming以及近年來流行的Flink。這些框架整體架構相似，但在實現細節上有許多不同，需要根據業務場景的特征靈活選擇。

流式框架具有以下優點：

1. 高時效性：通常延遲在秒級別。
   
   

2. 任務常駐：流式任務一旦啟動，會持續運行，直到人為終止，且數據源是無限的。
   
   

3. 高處理性能：流式計算通常會使用高性能服務器來運行任務，因為一旦處理吞吐量無法跟上采集吞吐量，就會導致數據計算延遲。
   
   

4. 邏輯簡單：由于流式計算通常是對單條數據進行處理，缺乏數據間關聯運算能力，因此在支持的業務邏輯上相對簡單，處理結果與離線存在一定差異。
   
   

實時數據倉庫的兩個常見架構： Lambda架構：Lambda架構的核心理念是"流批一體化"。隨著機器性能和數據框架的不斷完善，用戶實際上并不關心底層如何運行，只要能夠按照統一模型返回結果即可。現在許多應用（例如Spark和Flink）都支持這種結構，即數據進入平臺后可以選擇批處理運行或者流式處理運行，但無論如何，一致性始終保持不變。

Kappa架構：雖然Lambda架構理念很好，但長期使用會導致數據復雜性增加。為解決復雜性問題，有人提出了用一套架構解決所有問題的設想，而流行的做法就是基于流計算。通過增加流計算的時間窗口來實現邏輯上的批處理操作。

實時數據倉庫的查詢引擎： 實時數據倉庫的查詢依賴于交互式查詢引擎，常見于OLAP場景。根據存儲數據方式的不同，可以分為ROLAP、MOLAP和HOLAP：

ROLAP：在大數據生態圈中，常用于ROLAP場景的交互式計算引擎包括Impala和Presto。它們以關系數據庫為核心，使用關系型結構進行多維數據表示和存儲。

ROLAP將多維結構劃分為事實表和維度表。事實表存儲數據和維度關鍵字，維度表存放維度層次、成員類別等維度描述信息。ROLAP的優勢是可以實時從源數據中獲取最新數據更新，以保持數據實時性，但運算效率較低，用戶等待時間較長。

MOLAP：MOLAP是一種通過預計算Cube方式加速查詢的OLAP引擎，其核心思想是"空間換時間"。常見代表包括Druid和Kylin。MOLAP以多維數據組織方式為核心，使用多維數組存儲數據。

多維數據形成"數據立方體（Cube）"結構，該結構經過高度優化，可以最大程度提高查詢性能。MOLAP的優勢在于可通過預處理多維數據顯著提高運算效率，但占用存儲空間大且數據更新有一定延遲。

HOLAP：HOLAP是基于混合數據組織的OLAP實現。根據業務需求，用戶可以選擇使用ROLAP和MOLAP。通常，不常用或需要靈活定義分析的部分使用ROLAP，而常用、常規模型采用MOLAP。

實時數據倉庫的分層模型： 實時數據倉庫的分層思路沿用了離線數據倉庫的思想。

CDM層（明細數據層）：根據業務場景的不同，CDM層會被劃分為各個主題域。

DWS層（匯總數據層）：DWS層對各個域進行適度匯總。

ADS層（應用數據層）：ADS層的設計并不完全根據需求一對一建設，而是結合不同需求對該層進行統一設計，以快速支持更多需求場景。

實時技術中的冪等機制： 冪等是一個數學概念，其特點是任意多次執行產生的影響與一次執行的影響相同，例如setTrue()函數就是一個冪等函數，無論執行多少次，結果都一樣。在復雜情況下（如網絡波動、Storm重啟等），可能出現重復數據，因此并非所有操作都是冪等的。在冪等的概念下，我們需要了解消息傳輸保障的三種機制：At most once、At least once和Exactly once。

At most once：消息傳輸機制上每條消息傳輸零次或一次，即消息可能丟失。

At least once：意味著每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重復但不會丟失。

Exactly once：消息傳輸機制上每條消息有且只有一次，即消息傳輸既不會丟失也不會重復。

實時數據倉庫中的多表關聯： 在流式數據處理中，數據計算基于計算增量進行，因此各個環節到達的時間和順序都是不確定且無序的。在這種情況下，進行兩個表的關聯必須將數據存儲在內存中。當一條數據到達時，需要在另一個表中查找數據。如果能夠找到則關聯成功，寫入下游；如果找不到，則可以將其分到未分配數據集合中等待。為了提高數據查找性能，在實際處理中，通常會根據關聯主鍵對數據進行分桶處理，減少查找數據量，提高性能。

實時技術中的洪峰挑戰： 解決洪峰挑戰的主要思路如下：

1. 合理分配獨占資源和共享資源：在一臺機器中，共享資源池可以被多個實時任務搶占。如果一個任務80%的時間都需要爭奪資源，可以考慮分配更多的獨占資源。
   
   

2. 合理設置緩存機制：盡管內存的讀寫性能最好，但仍然有許多數據需要從讀庫更新。可以將熱門數據盡量保留在內存中，并通過異步方式更新緩存。
   
   

3. 計算合并單元：在流式計算框架中，拓撲結構層級越深，性能越差。考慮合并計算單元，可以有效降低數據傳輸、序列化等時間。
   
   

4. 內存共享：在海量數據處理中，大部分對象以字符串形式存在。合理共享對象在不同線程間，可以大幅降低字符拷貝帶來的性能消耗。
   
   

5. 平衡高吞吐與低延遲：高吞吐與低延遲本身就是矛盾體。將多個讀寫庫操作或ACK操作合并可以有效降低數據吞吐量，但也會增加延遲。可以在業務上取舍。
   
   

總結： 在實時數據倉庫的建設中，已經有了常用的方案選擇。整體架構設計通過分層設計為OLAP查詢分擔壓力，讓出計算空間，復雜的計算統一在實時計算層處理，避免給OLAP查詢帶來過大壓力。匯總計算交給OLAP數據庫進行。

因此，在整個架構中，實時計算通常使用Spark+Flink，消息隊列Kafka處于壟斷地位。在大數據領域，Kafka仍然是消息隊列應用中的首選。Hbase、Redis和MySQL在特定場景下也有一席之地。