|0x00 數倉爲什麼要實時
去年開始，實時數倉的概念突然火了。也許是傳統的離線數倉搞了很多年，技術相對成熟了，因此大家都把注意力放到了挑戰性更高的實時上來；也許是隨着存量市場競爭的到來，對於速度的要求越來越快，T+1已經不能滿足數據的獲取要求了，實時的構建需求也就應運而生了。
總之，時效性開始大於分析性。
文本簡單介紹實時數倉的一些基礎理論，更系統性的理論，仍然行業需要更大範圍的應用和總結。總之，這是一塊有前景的新領域，值得探索。
|0x01 實時數倉的技術要求
- 高併發性
未來的實時數據一定不是僅僅給幾個運營或管理層人員使用，會更多的面向商戶、用戶，那麼用戶增加的情況下一定會帶來併發量的提升，因此實時數倉一定要具備提供高併發數據服務的能力。 - 查詢速度
目前很多實時指標的應用場景在移動端，移動端對於數據的響應要求遠高於PC端，對於大多數數據使用場景希望能夠毫秒級返回，未來實時標籤如果應用到用戶推薦上，對於響應的速度要求更高。 - 處理速度
要保證大促期間，在流量峯值的情況下有極強的處理能力，並且具備消費低延遲性甚至0延遲。
|0x02 實時數倉的技術基礎：流式技術架構
目前流式計算框架相對成熟，以Storm、Spark Streaming爲代表的開源組件也被廣泛應用。流式數據處理，簡單來講，就是系統每產生一條數據，都會被立刻採集併發送到流式任務中心進行處理，不需要額外的定時調度來執行任務。目前在業界比較廣泛採用的框架有Twitter的Storm、Apache的Spark Streaming，以及最近幾年流行的Flink。它們整體架構大同小異，但在實現細節上有諸多的不同，需要根據業務場景的特徵來靈活選擇框架。
流式框架具備以下優點：
- 時效性高：延遲粒度通常在秒級；
- 任務常駐：流式任務一旦啓動，就會一直運行，直到人爲終止，且數據源是無界的；
- 處理性能高：流式計算通常會採用較好的服務器來運行任務，因爲一旦處理吞吐量趕不上採集吞吐量，就會出現數據計算延遲；
- 邏輯簡單：由於流式計算通常是針對單條數據做處理，缺乏數據之間的關聯運算能力，所以在支持的業務邏輯上相對簡單，並且處理結果會與離線存在一定的差異。
|0x03 實時數倉的兩個常見架構
Lambda架構：Lambda架構的核心理念是“流批一體化”，因爲隨着機器性能和數據框架的不斷完善，用戶其實不關心底層是如何運行的，批處理也好，流式處理也罷，能按照統一的模型返回結果就可以了，這就是Lambda架構誕生的原因。現在很多應用，例如Spark和Flink，都支持這種結構，也就是數據進入平臺後，可以選擇批處理運行，也可以選擇流式處理運行，但不管怎樣，一致性都是相同的。
Kappa架構：Lambda架構雖然理念很好，但用多了會有一個問題：數據複雜性大大增加。爲了解決複雜性的問題，有人提出了用一套架構解決所有問題的設想，而流行的做法就是基於流計算來做。通過加大流計算的“時間窗口”，來實現邏輯意義上的批處理操作。
|0x04 實時數倉的查詢引擎
實時數倉的查詢依賴於交互式查詢引擎，常見於OLAP場景，根據存儲數據方式的不同可以分爲ROLAP、MOLAP和HOLAP：
ROLAP：在大數據生態圈中，主流的應用於ROLAP場景的交互式計算引擎包括Impala和Presto。基於關係數據庫OLAP實現（Relational OLAP），它以關係數據庫爲核心，以關係型結構進行多維數據的表示和存儲。它將多維結構劃分成兩類表：一類是事實表，迎來存儲數據和維度關鍵字；另一類是維度表，即對每個維度至少使用一個表來存放維度層次、成員類別等維度描述信息。ROLAP的最大好處是可以實時地從源數據中獲得最新數據更新，以保持數據實時性，缺點在於運算效率比較低，用戶等待時間比較長。
MOLAP： MOLAP是一種通過預計算cube方式加速查詢的OLAP引擎，它的核心思想是“空間換時間”，典型的代表包括Druid和Kylin。基於多維數據組織的OLAP實現（Multidimensional OLAP），它以多維數據組織方式爲核心，使用多維數組存儲數據。多維數據在存儲系統中形成“數據立方體（Cube）”結構，此結構是高度優化的，可以最大程度提高查詢性能。MOLAP的有事在於藉助數據多位預處理顯著提高運算效率，主要缺陷在於佔用存儲空間大和數據更新有一定延遲。
HOLAP：基於混合數據組織的OLAP實現（Hybrid OLAP），用戶可以根據自己的業務需求，選擇哪些模型採用ROLAP、哪些採用MOLAP。一般來說，將不常用或需要靈活定義的分析使用ROLAP，而常用、常規模型採用MOLAP實現。
|0x05 實時數倉的分層模型
實時數倉的分層思路沿用了離線的思想。
- CDM層（明細數據層）: CDM層主要分交易、營銷、流量、商戶、商品、履約、客滿7個域。
- DWS層（彙總數據層）：DWS層對各個域進行了適度彙總。
- ADS層 （應用數據層）：ADS層並不完全根據需求一對一建設，而是結合不同的需求對這一層進行統一設計，形成新零售的指標庫，以快速支撐更多的需求場景。
|0x06 實時數倉中的冪等機制
冪等是一個數學概念，特點是任意多次執行所產生的影響均與一次執行的影響相同，例如setTrue()函數就是一個冪等函數,無論多次執行，其結果都是一樣的。在很多複雜情況下，例如網絡波動、Storm重啓等，會出現重複數據，因此並不是所有操作都是冪等的。
在冪等的概念下，我們需要了解消息傳輸保障的三種機制：At most once、At least once和Exactly once。
- At most once：消息傳輸機制是每條消息傳輸零次或者一次，即消息可能會丟失；
- At least once：意味着每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重複但不會丟失；
- Exactly once：的消息傳輸機制是每條消息有且只有一次，即消息傳輸既不會丟失也不會重複。
|0x07 實時數倉中的多表關聯
在流式數據處理中，數據的計算是以計算增量爲基礎的，所以各個環節到達的時間和順序，既是不確定的，也是無序的。在這種情況下，如果兩表要關聯，勢必需要將數據在內存中進行存儲，當一條數據到達後，需要去另一個表中查找數據，如果能夠查到，則關聯成功，寫入下游；如果無法查到，可以被分到未分配的數據集合中進行等待。在實際處理中，考慮到數據查找的性能，會把數據按照關聯主鍵進行分桶處理，以降低查找的數據量，提高性能。
|0x08 實時數倉中的洪峯挑戰
主要解決思路有如下幾種：
- 獨佔資源與共享資源合理分配：在一臺機器中，共享資源池可以被多個實時任務搶佔，如果一個任務80%的時間都需要搶資源，可以考慮分配更多的獨佔資源；
- 合理設置緩存機制：雖然內存的讀寫性能是最好的，但很多數據依然需要讀庫更新，可以考慮將熱門數據儘量多的留在內存中，通過異步的方式來更新緩存；
- 計算合併單元：在流式計算框架中，拓撲結構的層級越深，性能越差，考慮合併計算單元，可以有效降低數據的傳輸、序列化等時間；
- 內存共享：在海量數據的處理中，大部分的對象都是以字符串形式存在的，在不同線程間合理共享對象，可以大幅度降低字符拷貝帶來的性能消耗；
- 在高吞吐與低延遲間尋求平衡：高吞吐與低延遲天生就是一對矛盾體，將多個讀寫庫的操作或者ACK操作合併時，可以有效降低數據吞吐，但也會增加延遲，可以進行業務上的取捨。
|0xFF 總結
在整個實時數倉的建設中，業界已經有了常用的方案選型。整體架構設計通過分層設計爲OLAP查詢分擔壓力，讓出計算空間，複雜的計算統一在實時計算層處理掉，避免給OLAP查詢帶來過大的壓力。彙總計算交給OLAP數據庫進行。因此，在整個架構中實時計算一般是Spark+Flink配合，消息隊列Kafka一家獨大，在整個大數據領域消息隊列的應用中仍然處於壟斷地位，Hbase、Redis和MySQL都在特定場景下有一席之地。
目前還沒有一個OLAP系統能夠滿足各種場景的查詢需求。其本質原因是，沒有一個系統能同時在數據量、性能、和靈活性三個方面做到完美，每個系統在設計時都需要在這三者間做出取捨。
從長遠看，Spark和Flink更有可能成爲下一代的Hadoop，值得投入大量時間學習。
