在某些場景中，資料的價值隨著時間的推移而逐漸減少。所以在傳統大資料脫機數倉的基礎上，逐漸對資料的實時性提出了更高的要求。
其中lambda架構是較早的解決方案，使用流處理和批處理兩種架構進行資料處理。其中流處理部分負責實時資料的處理，但流處理因為資料可靠性並不高，所以需要批處理部分定期進行運算稽查。
流處理相當於作為臨時檢視存在，滿足資料實時性要求。而準確資料以批處理計算為主。
在這種架構中，分為流處理層：speed layer，批處理層：batch layer，這兩層處理後的資料儲存到server layer中。資料應用訪問server layer獲取資料。
技術選型方面，這裡以主流技術選型為主，一般新增資料進入到吞吐量大、實時性高的kafka資料佇列中。
批處理服務定期將資料抽取到分布式檔案系統hdfs中，然後交由分布式計算引擎hive進行處理。處理後的精準結果由impala快速查詢引擎提供服務。
實時處理服務實時從kafka中獲取資料，交由flink、spark streaming等實時計算引擎進行實時處理。
處理結果會儲存到支援實時讀寫的資料庫中，如hbase、druid。
應用方面，離線和實時處理互相補充，實時處理可以快速獲取最新資料，而對於精準的歷史資料，則由離線處理提供。
這裡有兩個典型的應用場景：廣告投放、智慧型停車。
在廣告投放場景中，使用者的實時訪問資料由實時處理進行處理，進行實時推薦，但推薦內容也需要考慮使用者的歷史訪問記錄，這些離線的歷史記錄則由離線處理進行處理提供。
而智慧型停車中，實時系統對進入停車場的車輛資料進行實時分析，但如果多輛車進入，系統可能會給多輛車提供同乙個車位，系統體驗會很差。但如果通過歷史資料，根據擁擠程度，和停車場車位的使用率，來建立模型。這樣，實時系統與離線系統的結合，會給出更為出色的方案。
實時數倉1
介紹 丟擲問題有脫機數倉了，做實時數倉，是否能兼顧到以前的指標體系，是不是可以直接替代？類似於畫像體系是否可以在此基礎上進行構建？實時數倉是否可以是實時平台的基礎？架構有沒有明確的定義？框架變化 儲存框架 框架優勢 劣勢mysql 事務查詢 儲存的效能瓶頸 elasticsearch 吞吐量大，快速...
脫機數倉到實時數倉的架構演變
1.實時數倉的相關概述 1.1 實時數倉產生背景 我們先來回顧一下資料倉儲的概念。資料倉儲的概念是於 90 年代由 bill inmon 提出,當時的背景是傳統的 oltp 資料庫無法很好的支援長週期分析決策場景，所以資料倉儲概念的 4 個核心點，我們要結合著 oltp 資料庫當時的狀態來對比理解。...
脫機數倉與實時數倉案例
資料倉儲是乙個面向主題的 subject oriented 整合的 integrate 相對穩定的 non volatile 反映歷史變化 time variant 的資料集合，用於支援管理決策。資料倉儲是伴隨著企業資訊化發展起來的，在企業資訊化的過程中，隨著資訊化工具的公升級和新工具的應用，資料量...