去年開始，實時數倉的概念突然火了。也許是傳統的脫機數倉搞了很多年，技術相對成熟了，因此大家都把注意力放到了挑戰性更高的實時上來；也許是隨著存量市場競爭的到來，對於速度的要求越來越快，t+1已經不能滿足資料的獲取要求了，實時的構建需求也就應運而生了。
總之，時效性開始大於分析性。
文字簡單介紹實時數倉的一些基礎理論，更系統性的理論，仍然行業需要更大範圍的應用和總結。總之，這是一塊有前景的新領域，值得探索。
高併發性
未來的實時資料一定不是僅僅給幾個運營或管理層人員使用，會更多的面向商戶、使用者，那麼使用者增加的情況下一定會帶來併發量的提公升，因此實時數倉一定要具備提供高併發資料服務的能力。
查詢速度
目前很多實時指標的應用場景在移動端，移動端對於資料的響應要求遠高於pc端，對於大多數資料使用場景希望能夠毫秒級返回，未來實時標籤如果應用到使用者推薦上，對於響應的速度要求更高。
處理速度
要保證大促期間，在流量峰值的情況下有極強的處理能力，並且具備消費低延遲性甚至0延遲。
目前流式計算框架相對成熟，以storm、spark streaming為代表的開源元件也被廣泛應用。流式資料處理，簡單來講，就是系統每產生一條資料，都會被立刻採集併發送到流式任務中心進行處理，不需要額外的定時排程來執行任務。目前在業界比較廣泛採用的框架有twitter的storm、apache的spark streaming，以及最近幾年流行的flink。它們整體架構大同小異，但在實現細節上有諸多的不同，需要根據業務場景的特徵來靈活選擇框架。
流式框架具備以下優點：
時效性高：延遲粒度通常在秒級；
任務常駐：流式任務一旦啟動，就會一直執行，直到人為終止，且資料來源是無界的；
處理效能高：流式計算通常會採用較好的伺服器來執行任務，因為一旦處理吞吐量趕不上採集吞吐量，就會出現資料計算延遲；
邏輯簡單：由於流式計算通常是針對單條資料做處理，缺乏資料之間的關聯運算能力，所以在支援的業務邏輯上相對簡單，並且處理結果會與離線存在一定的差異。
lambda架構：lambda架構的核心理念是「流批一體化」，因為隨著機器效能和資料框架的不斷完善，使用者其實不關心底層是如何執行的，批處理也好，流式處理也罷，能按照統一的模型返回結果就可以了，這就是lambda架構誕生的原因。現在很多應用，例如spark和flink，都支援這種結構，也就是資料進入平台後，可以選擇批處理執行，也可以選擇流式處理執行，但不管怎樣，一致性都是相同的。
實時數倉的查詢依賴於互動式查詢引擎，常見於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實現。
實時數倉的分層思路沿用了離線的思想。
冪等是乙個數學概念，特點是任意多次執行所產生的影響均與一次執行的影響相同，例如settrue()函式就是乙個冪等函式,無論多次執行，其結果都是一樣的。在很多複雜情況下，例如網路波動、storm重啟等，會出現重複資料，因此並不是所有操作都是冪等的。
在冪等的概念下，我們需要了解訊息傳輸保障的三種機制：at most once、at least once和exactly once。
在流式資料處理中，資料的計算是以計算增量為基礎的，所以各個環節到達的時間和順序，既是不確定的，也是無序的。在這種情況下，如果兩表要關聯，勢必需要將資料在記憶體中進行儲存，當一條資料到達後，需要去另乙個表中查詢資料，如果能夠查到，則關聯成功，寫入下游；如果無法查到，可以被分到未分配的資料集合中進行等待。在實際處理中，考慮到資料查詢的效能，會把資料按照關聯主鍵進行分桶處理，以降低查詢的資料量，提高效能。
主要解決思路有如下幾種：
合理設定快取機制：雖然記憶體的讀寫效能是最好的，但很多資料依然需要讀庫更新，可以考慮將熱門資料盡量多的留在記憶體中，通過非同步的方式來更新快取；
計算合併單元：在流式計算框架中，拓撲結構的層級越深，效能越差，考慮合併計算單元，可以有效降低資料的傳輸、序列化等時間；
記憶體共享：在海量資料的處理中，大部分的物件都是以字串形式存在的，在不同執行緒間合理共享物件，可以大幅度降低字元拷貝帶來的效能消耗；
在高吞吐與低延遲間尋求平衡：高吞吐與低延遲天生就是一對矛盾體，將多個讀寫庫的操作或者ack操作合併時，可以有效降低資料吞吐，但也會增加延遲，可以進行業務上的取捨。
在整個實時數倉的建設中，業界已經有了常用的方案選型。整體架構設計通過分層設計為olap查詢分擔壓力，讓出計算空間，複雜的計算統一在實時計算層處理掉，避免給olap查詢帶來過大的壓力。彙總計算交給olap資料庫進行。因此，在整個架構中實時計算一般是spark+flink配合，訊息佇列kafka一家獨大，在整個大資料領域訊息佇列的應用中仍然處於壟斷地位，hbase、redis和mysql都在特定場景下有一席之地。
目前還沒有乙個olap系統能夠滿足各種場景的查詢需求。其本質原因是，沒有乙個系統能同時在資料量、效能、和靈活性三個方面做到完美，每個系統在設計時都需要在這三者間做出取捨。
從長遠看，spark和flink更有可能成為下一代的hadoop，值得投入大量時間學習。
實時數倉1
介紹 丟擲問題有脫機數倉了，做實時數倉，是否能兼顧到以前的指標體系，是不是可以直接替代？類似於畫像體系是否可以在此基礎上進行構建？實時數倉是否可以是實時平台的基礎？架構有沒有明確的定義？框架變化 儲存框架 框架優勢 劣勢mysql 事務查詢 儲存的效能瓶頸 elasticsearch 吞吐量大，快速...
實時數倉 Lambda架構
在某些場景中，資料的價值隨著時間的推移而逐漸減少。所以在傳統大資料脫機數倉的基礎上，逐漸對資料的實時性提出了更高的要求。其中lambda架構是較早的解決方案，使用流處理和批處理兩種架構進行資料處理。其中流處理部分負責實時資料的處理，但流處理因為資料可靠性並不高，所以需要批處理部分定期進行運算稽查。流...
脫機數倉與實時數倉案例
資料倉儲是乙個面向主題的 subject oriented 整合的 integrate 相對穩定的 non volatile 反映歷史變化 time variant 的資料集合，用於支援管理決策。資料倉儲是伴隨著企業資訊化發展起來的，在企業資訊化的過程中，隨著資訊化工具的公升級和新工具的應用，資料量...