去(qù)年(nián)，實時(shí)數據倉庫的(de)概念突然變得非常流行。可能是因為(wèi)傳統的(de)離線數據倉庫已經發展了多年(nián)，技(jì)術相(xiàng)對(duì)成熟，所以大家(jiā)開(kāi)始将注意力放(fàng)在更具挑戰性的(de)實時(shí)數據倉庫上(shàng)；也可能是随着存量市(shì)場(chǎng)競争的(de)到來(lái)，對(duì)于數據獲取速度的(de)要求越來(lái)越高(gāo)，T+1的(de)數據獲取無法滿足需求，因此實時(shí)構建數據的(de)需求也應運而生(shēng)。

實時(shí)數據倉庫的(de)技(jì)術要求：

1. 高(gāo)并發性：未來(lái)實時(shí)數據不僅僅是為(wèi)幾個(gè)運營或管理(lǐ)層人(rén)員(yuán)使用，更會面向商戶和(hé)用戶。随着用戶數量的(de)增加，會帶來(lái)并發量的(de)增加。因此，實時(shí)數據倉庫必須具備提供高(gāo)并發數據服務的(de)能力。

   
   

2. 查詢速度：目前許多實時(shí)指标的(de)應用場(chǎng)景是移動端，移動端對(duì)數據響應速度的(de)要求遠(yuǎn)高(gāo)于PC端。大多數數據使用場(chǎng)景希望能夠在毫秒級返回數據。未來(lái)，如果将實時(shí)标簽應用于用戶推薦中，對(duì)響應速度的(de)要求将更高(gāo)。

   
   

3. 處理(lǐ)速度：在大促銷期間(jiān)，需要具備極強的(de)處理(lǐ)能力，能夠應對(duì)流量峰值的(de)情況。還(hái)需要具備低(dī)延遲甚至零延遲的(de)消費(fèi)能力。

   
   

實時(shí)數據倉庫的(de)技(jì)術基礎：流式技(jì)術架構 目前，流式計(jì)算(suàn)框架相(xiàng)對(duì)成熟，開(kāi)源組件(jiàn)如Storm、Spark Streaming和(hé)Flink得到廣泛應用。簡單來(lái)說(shuō)，流式數據處理(lǐ)是指系統每産生(shēng)一條數據，都(dōu)會立即采集并發送到流式任務中心進行處理(lǐ)，無需額外(wài)的(de)定時(shí)調度。

業(yè)界廣泛采用的(de)框架有(yǒu)Twitter的(de)Storm、Apache的(de)Spark Streaming以及近(jìn)年(nián)來(lái)流行的(de)Flink。這(zhè)些框架整體(tǐ)架構相(xiàng)似，但(dàn)在實現(xiàn)細節上(shàng)有(yǒu)許多不同，需要根據業(yè)務場(chǎng)景的(de)特征靈活選擇。

流式框架具有(yǒu)以下(xià)優點：

1. 高(gāo)時(shí)效性：通(tōng)常延遲在秒級别。
   
   

2. 任務常駐：流式任務一旦啓動，會持續運行，直到人(rén)為(wèi)終止，且數據源是無限的(de)。
   
   

3. 高(gāo)處理(lǐ)性能：流式計(jì)算(suàn)通(tōng)常會使用高(gāo)性能服務器(qì)來(lái)運行任務，因為(wèi)一旦處理(lǐ)吞吐量無法跟上(shàng)采集吞吐量，就會導緻數據計(jì)算(suàn)延遲。
   
   

4. 邏輯簡單：由于流式計(jì)算(suàn)通(tōng)常是對(duì)單條數據進行處理(lǐ)，缺乏數據間(jiān)關聯運算(suàn)能力，因此在支持的(de)業(yè)務邏輯上(shàng)相(xiàng)對(duì)簡單，處理(lǐ)結果與離線存在一定差異。
   
   

實時(shí)數據倉庫的(de)兩個(gè)常見架構： Lambda架構：Lambda架構的(de)核心理(lǐ)念是"流批一體(tǐ)化(huà)"。随着機(jī)器(qì)性能和(hé)數據框架的(de)不斷完善，用戶實際上(shàng)并不關心底層如何運行，隻要能夠按照(zhào)統一模型返回結果即可。現(xiàn)在許多應用（例如Spark和(hé)Flink）都(dōu)支持這(zhè)種結構，即數據進入平台後可以選擇批處理(lǐ)運行或者流式處理(lǐ)運行，但(dàn)無論如何，一緻性始終保持不變。

Kappa架構：雖然Lambda架構理(lǐ)念很(hěn)好(hǎo)，但(dàn)長(cháng)期使用會導緻數據複雜(zá)性增加。為(wèi)解決複雜(zá)性問(wèn)題，有(yǒu)人(rén)提出了用一套架構解決所有(yǒu)問(wèn)題的(de)設想，而流行的(de)做法就是基于流計(jì)算(suàn)。通(tōng)過增加流計(jì)算(suàn)的(de)時(shí)間(jiān)窗口來(lái)實現(xiàn)邏輯上(shàng)的(de)批處理(lǐ)操作(zuò)。

實時(shí)數據倉庫的(de)查詢引擎： 實時(shí)數據倉庫的(de)查詢依賴于交互式查詢引擎，常見于OLAP場(chǎng)景。根據存儲數據方式的(de)不同，可以分為(wèi)ROLAP、MOLAP和(hé)HOLAP：

ROLAP：在大數據生(shēng)态圈中，常用于ROLAP場(chǎng)景的(de)交互式計(jì)算(suàn)引擎包括Impala和(hé)Presto。它們以關系數據庫為(wèi)核心，使用關系型結構進行多維數據表示和(hé)存儲。

ROLAP将多維結構劃分為(wèi)事(shì)實表和(hé)維度表。事(shì)實表存儲數據和(hé)維度關鍵字，維度表存放(fàng)維度層次、成員(yuán)類别等維度描述信息。ROLAP的(de)優勢是可以實時(shí)從(cóng)源數據中獲取最新數據更新，以保持數據實時(shí)性，但(dàn)運算(suàn)效率較低(dī)，用戶等待時(shí)間(jiān)較長(cháng)。

MOLAP：MOLAP是一種通(tōng)過預計(jì)算(suàn)Cube方式加速查詢的(de)OLAP引擎，其核心思想是"空間(jiān)換時(shí)間(jiān)"。常見代表包括Druid和(hé)Kylin。MOLAP以多維數據組織方式為(wèi)核心，使用多維數組存儲數據。

多維數據形成"數據立方體(tǐ)（Cube）"結構，該結構經過高(gāo)度優化(huà)，可以最大程度提高(gāo)查詢性能。MOLAP的(de)優勢在于可通(tōng)過預處理(lǐ)多維數據顯著提高(gāo)運算(suàn)效率，但(dàn)占用存儲空間(jiān)大且數據更新有(yǒu)一定延遲。

HOLAP：HOLAP是基于混合數據組織的(de)OLAP實現(xiàn)。根據業(yè)務需求，用戶可以選擇使用ROLAP和(hé)MOLAP。通(tōng)常，不常用或需要靈活定義分析的(de)部分使用ROLAP，而常用、常規模型采用MOLAP。

實時(shí)數據倉庫的(de)分層模型： 實時(shí)數據倉庫的(de)分層思路(lù)沿用了離線數據倉庫的(de)思想。

CDM層（明(míng)細數據層）：根據業(yè)務場(chǎng)景的(de)不同，CDM層會被劃分為(wèi)各個(gè)主題域。

DWS層（彙總數據層）：DWS層對(duì)各個(gè)域進行适度彙總。

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

實時(shí)技(jì)術中的(de)幂等機(jī)制： 幂等是一個(gè)數學概念，其特點是任意多次執行産生(shēng)的(de)影響與一次執行的(de)影響相(xiàng)同，例如setTrue()函數就是一個(gè)幂等函數，無論執行多少次，結果都(dōu)一樣。在複雜(zá)情況下(xià)（如網絡波動、Storm重啓等），可能出現(xiàn)重複數據，因此并非所有(yǒu)操作(zuò)都(dōu)是幂等的(de)。在幂等的(de)概念下(xià)，我們需要了解消息傳輸保障的(de)三種機(jī)制：At most once、At least once和(hé)Exactly once。

At most once：消息傳輸機(jī)制上(shàng)每條消息傳輸零次或一次，即消息可能丢失。

At least once：意味着每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重複但(dàn)不會丢失。

Exactly once：消息傳輸機(jī)制上(shàng)每條消息有(yǒu)且隻有(yǒu)一次，即消息傳輸既不會丢失也不會重複。

實時(shí)數據倉庫中的(de)多表關聯： 在流式數據處理(lǐ)中，數據計(jì)算(suàn)基于計(jì)算(suàn)增量進行，因此各個(gè)環節到達的(de)時(shí)間(jiān)和(hé)順序都(dōu)是不确定且無序的(de)。在這(zhè)種情況下(xià)，進行兩個(gè)表的(de)關聯必須将數據存儲在內(nèi)存中。當一條數據到達時(shí)，需要在另一個(gè)表中查找數據。如果能夠找到則關聯成功，寫入下(xià)遊；如果找不到，則可以将其分到未分配數據集合中等待。為(wèi)了提高(gāo)數據查找性能，在實際處理(lǐ)中，通(tōng)常會根據關聯主鍵對(duì)數據進行分桶處理(lǐ)，減少查找數據量，提高(gāo)性能。

實時(shí)技(jì)術中的(de)洪峰挑戰： 解決洪峰挑戰的(de)主要思路(lù)如下(xià)：

1. 合理(lǐ)分配獨占資源和(hé)共享資源：在一台機(jī)器(qì)中，共享資源池可以被多個(gè)實時(shí)任務搶占。如果一個(gè)任務80%的(de)時(shí)間(jiān)都(dōu)需要争奪資源，可以考慮分配更多的(de)獨占資源。
   
   

2. 合理(lǐ)設置緩存機(jī)制：盡管內(nèi)存的(de)讀寫性能最好(hǎo)，但(dàn)仍然有(yǒu)許多數據需要從(cóng)讀庫更新。可以将熱門數據盡量保留在內(nèi)存中，并通(tōng)過異步方式更新緩存。
   
   

3. 計(jì)算(suàn)合并單元：在流式計(jì)算(suàn)框架中，拓撲結構層級越深，性能越差。考慮合并計(jì)算(suàn)單元，可以有(yǒu)效降低(dī)數據傳輸、序列化(huà)等時(shí)間(jiān)。
   
   

4. 內(nèi)存共享：在海(hǎi)量數據處理(lǐ)中，大部分對(duì)象以字符串形式存在。合理(lǐ)共享對(duì)象在不同線程間(jiān)，可以大幅降低(dī)字符拷貝帶來(lái)的(de)性能消耗。
   
   

5. 平衡高(gāo)吞吐與低(dī)延遲：高(gāo)吞吐與低(dī)延遲本身(shēn)就是矛盾體(tǐ)。将多個(gè)讀寫庫操作(zuò)或ACK操作(zuò)合并可以有(yǒu)效降低(dī)數據吞吐量，但(dàn)也會增加延遲。可以在業(yè)務上(shàng)取舍。
   
   

總結： 在實時(shí)數據倉庫的(de)建設中，已經有(yǒu)了常用的(de)方案選擇。整體(tǐ)架構設計(jì)通(tōng)過分層設計(jì)為(wèi)OLAP查詢分擔壓力，讓出計(jì)算(suàn)空間(jiān)，複雜(zá)的(de)計(jì)算(suàn)統一在實時(shí)計(jì)算(suàn)層處理(lǐ)，避免給OLAP查詢帶來(lái)過大壓力。彙總計(jì)算(suàn)交給OLAP數據庫進行。

因此，在整個(gè)架構中，實時(shí)計(jì)算(suàn)通(tōng)常使用Spark+Flink，消息隊列Kafka處于壟斷地(dì)位。在大數據領域，Kafka仍然是消息隊列應用中的(de)首選。Hbase、Redis和(hé)MySQL在特定場(chǎng)景下(xià)也有(yǒu)一席之地(dì)。