更新時間：2025-04-17 10:28:07
數(shù)倉開發(fā)
647去年，實時數(shù)據(jù)倉庫的概念突然變得非常流行?？赡苁且驗閭鹘y(tǒng)的離線數(shù)據(jù)倉庫已經(jīng)發(fā)展了多年，技術(shù)相對成熟，所以大家開始將注意力放在更具挑戰(zhàn)性的實時數(shù)據(jù)倉庫上；也可能是隨著存量市場競爭的到來，對于數(shù)據(jù)獲取速度的要求越來越高，T+1的數(shù)據(jù)獲取無法滿足需求，因此實時構(gòu)建數(shù)據(jù)的需求也應運而生。
實時數(shù)據(jù)倉庫的技術(shù)要求：
-
高并發(fā)性：未來實時數(shù)據(jù)不僅僅是為幾個運營或管理層人員使用，更會面向商戶和用戶。隨著用戶數(shù)量的增加，會帶來并發(fā)量的增加。因此，實時數(shù)據(jù)倉庫必須具備提供高并發(fā)數(shù)據(jù)服務(wù)的能力。
-
查詢速度：目前許多實時指標的應用場景是移動端，移動端對數(shù)據(jù)響應速度的要求遠高于PC端。大多數(shù)數(shù)據(jù)使用場景希望能夠在毫秒級返回數(shù)據(jù)。未來，如果將實時標簽應用于用戶推薦中，對響應速度的要求將更高。
-
處理速度：在大促銷期間，需要具備極強的處理能力，能夠應對流量峰值的情況。還需要具備低延遲甚至零延遲的消費能力。
實時數(shù)據(jù)倉庫的技術(shù)基礎(chǔ)：流式技術(shù)架構(gòu) 目前，流式計算框架相對成熟，開源組件如Storm、Spark Streaming和Flink得到廣泛應用。簡單來說，流式數(shù)據(jù)處理是指系統(tǒng)每產(chǎn)生一條數(shù)據(jù)，都會立即采集并發(fā)送到流式任務(wù)中心進行處理，無需額外的定時調(diào)度。
業(yè)界廣泛采用的框架有Twitter的Storm、Apache的Spark Streaming以及近年來流行的Flink。這些框架整體架構(gòu)相似，但在實現(xiàn)細節(jié)上有許多不同，需要根據(jù)業(yè)務(wù)場景的特征靈活選擇。
流式框架具有以下優(yōu)點：
高時效性：通常延遲在秒級別。
任務(wù)常駐：流式任務(wù)一旦啟動，會持續(xù)運行，直到人為終止，且數(shù)據(jù)源是無限的。
高處理性能：流式計算通常會使用高性能服務(wù)器來運行任務(wù)，因為一旦處理吞吐量無法跟上采集吞吐量，就會導致數(shù)據(jù)計算延遲。
邏輯簡單：由于流式計算通常是對單條數(shù)據(jù)進行處理，缺乏數(shù)據(jù)間關(guān)聯(lián)運算能力，因此在支持的業(yè)務(wù)邏輯上相對簡單，處理結(jié)果與離線存在一定差異。
實時數(shù)據(jù)倉庫的兩個常見架構(gòu)：
Lambda架構(gòu)：Lambda架構(gòu)的核心理念是"流批一體化"。隨著機器性能和數(shù)據(jù)框架的不斷完善，用戶實際上并不關(guān)心底層如何運行，只要能夠按照統(tǒng)一模型返回結(jié)果即可?，F(xiàn)在許多應用（例如Spark和Flink）都支持這種結(jié)構(gòu)，即數(shù)據(jù)進入平臺后可以選擇批處理運行或者流式處理運行，但無論如何，一致性始終保持不變。
Kappa架構(gòu)：雖然Lambda架構(gòu)理念很好，但長期使用會導致數(shù)據(jù)復雜性增加。為解決復雜性問題，有人提出了用一套架構(gòu)解決所有問題的設(shè)想，而流行的做法就是基于流計算。通過增加流計算的時間窗口來實現(xiàn)邏輯上的批處理操作。
實時數(shù)據(jù)倉庫的查詢引擎：
實時數(shù)據(jù)倉庫的查詢依賴于交互式查詢引擎，常見于OLAP場景。根據(jù)存儲數(shù)據(jù)方式的不同，可以分為ROLAP、MOLAP和HOLAP：
ROLAP：在大數(shù)據(jù)生態(tài)圈中，常用于ROLAP場景的交互式計算引擎包括Impala和Presto。它們以關(guān)系數(shù)據(jù)庫為核心，使用關(guān)系型結(jié)構(gòu)進行多維數(shù)據(jù)表示和存儲。
ROLAP將多維結(jié)構(gòu)劃分為事實表和維度表。事實表存儲數(shù)據(jù)和維度關(guān)鍵字，維度表存放維度層次、成員類別等維度描述信息。ROLAP的優(yōu)勢是可以實時從源數(shù)據(jù)中獲取最新數(shù)據(jù)更新，以保持數(shù)據(jù)實時性，但運算效率較低，用戶等待時間較長。
MOLAP：MOLAP是一種通過預計算Cube方式加速查詢的OLAP引擎，其核心思想是"空間換時間"。常見代表包括Druid和Kylin。MOLAP以多維數(shù)據(jù)組織方式為核心，使用多維數(shù)組存儲數(shù)據(jù)。
多維數(shù)據(jù)形成"數(shù)據(jù)立方體（Cube）"結(jié)構(gòu)，該結(jié)構(gòu)經(jīng)過高度優(yōu)化，可以最大程度提高查詢性能。MOLAP的優(yōu)勢在于可通過預處理多維數(shù)據(jù)顯著提高運算效率，但占用存儲空間大且數(shù)據(jù)更新有一定延遲。
HOLAP：HOLAP是基于混合數(shù)據(jù)組織的OLAP實現(xiàn)。根據(jù)業(yè)務(wù)需求，用戶可以選擇使用ROLAP和MOLAP。通常，不常用或需要靈活定義分析的部分使用ROLAP，而常用、常規(guī)模型采用MOLAP。
實時數(shù)據(jù)倉庫的分層模型： 實時數(shù)據(jù)倉庫的分層思路沿用了離線數(shù)據(jù)倉庫的思想。
CDM層（明細數(shù)據(jù)層）：根據(jù)業(yè)務(wù)場景的不同，CDM層會被劃分為各個主題域。
DWS層（匯總數(shù)據(jù)層）：DWS層對各個域進行適度匯總。
ADS層（應用數(shù)據(jù)層）：ADS層的設(shè)計并不完全根據(jù)需求一對一建設(shè)，而是結(jié)合不同需求對該層進行統(tǒng)一設(shè)計，以快速支持更多需求場景。
實時技術(shù)中的冪等機制： 冪等是一個數(shù)學概念，其特點是任意多次執(zhí)行產(chǎn)生的影響與一次執(zhí)行的影響相同，例如setTrue()函數(shù)就是一個冪等函數(shù)，無論執(zhí)行多少次，結(jié)果都一樣。在復雜情況下（如網(wǎng)絡(luò)波動、Storm重啟等），可能出現(xiàn)重復數(shù)據(jù)，因此并非所有操作都是冪等的。在冪等的概念下，我們需要了解消息傳輸保障的三種機制：At most once、At least once和Exactly once。
At most once：消息傳輸機制上每條消息傳輸零次或一次，即消息可能丟失。
At least once：意味著每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重復但不會丟失。
Exactly once：消息傳輸機制上每條消息有且只有一次，即消息傳輸既不會丟失也不會重復。
實時數(shù)據(jù)倉庫中的多表關(guān)聯(lián)：
在流式數(shù)據(jù)處理中，數(shù)據(jù)計算基于計算增量進行，因此各個環(huán)節(jié)到達的時間和順序都是不確定且無序的。在這種情況下，進行兩個表的關(guān)聯(lián)必須將數(shù)據(jù)存儲在內(nèi)存中。當一條數(shù)據(jù)到達時，需要在另一個表中查找數(shù)據(jù)。如果能夠找到則關(guān)聯(lián)成功，寫入下游；如果找不到，則可以將其分到未分配數(shù)據(jù)集合中等待。為了提高數(shù)據(jù)查找性能，在實際處理中，通常會根據(jù)關(guān)聯(lián)主鍵對數(shù)據(jù)進行分桶處理，減少查找數(shù)據(jù)量，提高性能。
實時技術(shù)中的洪峰挑戰(zhàn)：
解決洪峰挑戰(zhàn)的主要思路如下：
合理分配獨占資源和共享資源：在一臺機器中，共享資源池可以被多個實時任務(wù)搶占。如果一個任務(wù)80%的時間都需要爭奪資源，可以考慮分配更多的獨占資源。
合理設(shè)置緩存機制：盡管內(nèi)存的讀寫性能最好，但仍然有許多數(shù)據(jù)需要從讀庫更新。可以將熱門數(shù)據(jù)盡量保留在內(nèi)存中，并通過異步方式更新緩存。
計算合并單元：在流式計算框架中，拓撲結(jié)構(gòu)層級越深，性能越差?？紤]合并計算單元，可以有效降低數(shù)據(jù)傳輸、序列化等時間。
內(nèi)存共享：在海量數(shù)據(jù)處理中，大部分對象以字符串形式存在。合理共享對象在不同線程間，可以大幅降低字符拷貝帶來的性能消耗。
平衡高吞吐與低延遲：高吞吐與低延遲本身就是矛盾體。將多個讀寫庫操作或ACK操作合并可以有效降低數(shù)據(jù)吞吐量，但也會增加延遲?？梢栽跇I(yè)務(wù)上取舍。
總結(jié)：
在實時數(shù)據(jù)倉庫的建設(shè)中，已經(jīng)有了常用的方案選擇。整體架構(gòu)設(shè)計通過分層設(shè)計為OLAP查詢分擔壓力，讓出計算空間，復雜的計算統(tǒng)一在實時計算層處理，避免給OLAP查詢帶來過大壓力。匯總計算交給OLAP數(shù)據(jù)庫進行。
因此，在整個架構(gòu)中，實時計算通常使用Spark+Flink，消息隊列Kafka處于壟斷地位。在大數(shù)據(jù)領(lǐng)域，Kafka仍然是消息隊列應用中的首選。Hbase、Redis和MySQL在特定場景下也有一席之地。
我們專注高端建站，小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復、物聯(lián)網(wǎng)開發(fā)、各類API接口對接開發(fā)等。十余年開發(fā)經(jīng)驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！
