1.實時數倉的相關概述
1.1 實時數倉產生背景
我們先來回顧一下資料倉儲的概念。
資料倉儲的概念是於 90 年代由 bill inmon 提出, 當時的背景是傳統的 oltp 資料庫無法很好的支援長週期分析決策場景，所以資料倉儲概念的 4 個核心點，我們要結合著 oltp 資料庫當時的狀態來對比理解。
面向主題的：資料倉儲的資料組織方式與 oltp 面向事務處理不同。因為資料倉儲是面向分析決策的，所以資料經常按分析場景或者是分析物件等主題形式來組織。
整合的：對於資料倉儲來說，經常需要去集合多個分散的、異構的資料來源，做一些資料清洗等 etl 處理，整合成一塊資料倉儲，oltp 則不需要做類似的整合操作。
相對穩定的：oltp 資料庫一般都是面向業務的，它主要的作用是把當前的業務狀態精準的反映出來，所以 oltp 資料庫需要支援大量的增、刪、改的操作。但是對於資料倉儲來說，只要是入倉存下來的資料，一般使用場景都是查詢，因此資料是相對穩定的。
反映歷史變化：資料倉儲是反映歷史變化的資料集合，可以理解成它會將歷史的一些資料的快照存下來。而對於 oltp 資料庫來說，只要反映當時的最新的狀態就可以了。
以上這 4 個點是資料倉儲的乙個核心的定義。我們也可以看出對於實時資料倉儲來說，傳統資料倉儲也就是離線資料倉儲中的一些定義會被弱化，比如說在反映歷史變化這一點。介紹完資料倉儲的基本概念，簡單說下資料倉儲建模這塊會用到一些經典的建模方法，主要有正規化建模、維度建模和 data vault。在網際網路大資料場景下，用的最多的是維度建模方法。
然後先看一下脫機數倉的經典架構。如下圖：
這個數倉架構主要是偏向網際網路大資料的場景方案，由上圖可以看出有三個核心環節。
第乙個環節是資料來源部分，一般網際網路公司的資料來源主要有兩類：
第 1 類是通過在客戶端埋點上報，收集使用者的行為日誌，以及一些後端日誌的日誌型別資料來源。對於埋點行為日誌來說，一般會經過乙個這樣的流程，首先資料會上報到 nginx 然後經過 flume 收集，然後儲存到 kafka 這樣的訊息佇列，然後再由實時或者離線的一些拉取的任務，拉取到我們的離線資料倉儲 hdfs。
第 2 類資料來源是業務資料庫，而對於業務資料庫的話，一般會經過 canal 收集它的 binlog，然後也是收集到訊息佇列中，最終再由 camus 拉取到 hdfs。
這兩部分資料來源最終都會落地到 hdfs 中的 ods 層，也叫貼源資料層，這層資料和原始資料源是保持一致的。
第二個環節是離線資料倉儲，是圖中藍色的框展示的部分。可以看到它是乙個分層的結構，其中的模型設計是依據維度建模思路。
在中間的離線資料倉儲的生產環節，一般都是採用一些離線生產的架構引擎，比如說 mapreduce、hive、spark 等等，資料一般是存在 hdfs 上。
經過前兩個環節後，我們的一些應用層的資料會儲存到資料服務裡，比如說 hbase 、redis、kylin 這樣的一些 kv 的儲存。並且會針對存在這些資料儲存上的一些資料，封裝對應的服務介面，對外提供服務。在最外層我們會去產出一些面向業務的報表、面向分析的資料產品，以及會支援線上的一些業務產品等等。這一層的話，稱之為更貼近業務端的資料應用部分。
以上是乙個基本的脫機數倉經典架構的介紹。
大家都了解到現在隨著移動裝置的普及，我們逐漸的由製造業時代過渡到了網際網路時代。在製造業的時代，傳統的數倉，主要是為了去支援以前的一些傳統行業的企業的業務決策者、管理者，去做一些業務決策。那個時代的業務決策週期是比較長的，同時當時的資料量較小，oracle、db2 這一類資料庫就已經足夠存了。
但隨著分布式計算技術的發展、智慧型化技術發展、以及整體算力的提公升、網際網路的發展等等因素，我們現在在網際網路上收集的資料量，已經呈指數級的增長。並且業務不再只依賴人做決策，做決策的主體很大部分已轉變為計算機演算法，比如一些智慧型推薦場景等等。所以這個時候決策的週期，就由原來的天級要求提公升到秒級，決策時間是非常短的。在場景上的話，也會面對更多的需要實時資料處理的場景，例如實時的個性化推薦、廣告的場景、甚至一些傳統企業已經開始實時監控加工的產品是否有質量問題，以及金融行業重度依賴的反作弊等等。因此在這樣的乙個背景下，實時數倉就必須被提出來了。
1.2 實時數倉架構
首先跟大家介紹一下實時數倉經典架構 - lambda 架構：
這個架構是 storm 的作者提出來的，其實 lambda 架構的主要思路是在原來脫機數倉架構的基礎上疊加上實時數倉的部分，然後將離線的存量資料與我們 t+0 的實時的資料做乙個 merge，就可以產生資料狀態實時更新的結果。
大家也可以看到這個架構圖中，中間資料倉儲環節有兩個部分，乙個是離線的資料倉儲，乙個是實時的資料倉儲。我們必須要運維兩套（實時計算和離線計算）引擎，並且在**層面，我們也需要去實現實時和離線的業務**。
隨著我們現在實時 olap 技術的一些提公升，有乙個新的實時架構被提了出來，這裡暫且稱為實時 olap 變體。
這個思路是把大量的聚合、分析、計算由實時 olap 引擎來承擔。在實時數倉計算的部分，我們不需要做的特別重，尤其是聚合相關的一些邏輯，然後這樣就可以保障我們在資料應用層能靈活的面對各種業務分析的需求變更，整個架構更加靈活。
最後我們來整體對比一下，實時數倉的這幾種架構：
這是整體三個關於實時數倉架構的乙個對比：
1.3 傳統數倉 vs 實時數倉
然後我們來看一下傳統數倉和實時數倉整體的差異。
首先從時效性來看：脫機數倉是支援小時級和天級的，實時數倉到秒級分鐘級，所以實時數倉時效性是非常高的。
在資料儲存方式來看：脫機數倉它需要存在hdfs和rds上面，實時數倉一般是存在訊息佇列，還有一些kv儲存，像維度資料的話會更多的存在kv儲存上。
在生產加工過程方面，脫機數倉需要依賴離線計算引擎以及離線的排程。但對於實時數倉來說，主要是依賴實時計算引擎。
脫機數倉與實時數倉案例
資料倉儲是乙個面向主題的 subject oriented 整合的 integrate 相對穩定的 non volatile 反映歷史變化 time variant 的資料集合，用於支援管理決策。資料倉儲是伴隨著企業資訊化發展起來的，在企業資訊化的過程中，隨著資訊化工具的公升級和新工具的應用，資料量...
實時數倉與脫機數倉總結 一
精選30 雲產品，助力企業輕鬆上雲！主要內容 數倉基本概念 數倉架構演變 實時數倉和脫機數倉的區別 數倉基本概念 首先說一下資料倉儲的概念，以下簡稱數倉。數倉的發展 數倉有兩個環節 乙個是數倉的建設 另乙個數倉的應用。早期的數倉 傳統數倉 目前 數倉的架構演變 脫機數倉和實時數倉 接下來我會分別介紹...
實時數倉 Lambda架構
在某些場景中，資料的價值隨著時間的推移而逐漸減少。所以在傳統大資料脫機數倉的基礎上，逐漸對資料的實時性提出了更高的要求。其中lambda架構是較早的解決方案，使用流處理和批處理兩種架構進行資料處理。其中流處理部分負責實時資料的處理，但流處理因為資料可靠性並不高，所以需要批處理部分定期進行運算稽查。流...