資料倉儲是乙個面向主題的(subject oriented)、整合的(integrate)、相對穩定的(non-volatile)、反映歷史變化(time variant)的資料集合，用於支援管理決策。
資料倉儲是伴隨著企業資訊化發展起來的，在企業資訊化的過程中，隨著資訊化工具的公升級和新工具的應用，資料量變的越來越大，資料格式越來越多，決策要求越來越苛刻，資料倉儲技術也在不停的發展。
資料倉儲的趨勢：
資料倉儲有兩個環節：資料倉儲的構建與資料倉儲的應用。
早期資料倉儲構建主要指的是把企業的業務資料庫如erp、crm、scm等資料按照決策分析的要求建模並彙總到資料倉儲引擎中，其應用以報表為主，目的是支援管理層和業務人員決策（中長期策略型決策）。
隨著業務和環境的發展，這兩方面都在發生著劇烈變化。
總結來看，對資料倉儲的需求可以抽象成兩方面：實時產生結果、處理和儲存大量異構資料。
從公司業務出發，是分析的巨集觀領域，比如**商主題、商品主題、客戶主題和倉庫主題
資料包表；資料立方體，上捲、下鑽、切片、旋轉等分析功能。
以事實表和維度表組成的星型資料模型
資料倉儲概念是inmon於2023年提出並給出了完整的建設方法。隨著網際網路時代來臨，資料量暴增，開始使用大資料工具來替代經典數倉中的傳統工具。此時僅僅是工具的取代，架構上並沒有根本的區別，可以把這個架構叫做離線大資料架構。
後來隨著業務實時性要求的不斷提高，人們開始在離線大資料架構基礎上加了乙個加速層，使用流處理技術直接完成那些實時性要求較高的指標計算，這便是lambda架構。
資料來源通過離線的方式匯入到脫機數倉中。
下游應用根據業務需求選擇直接讀取dm或加一層資料服務，比如mysql 或 redis。
資料倉儲從模型層面分為三層：
典型的數倉儲存是hdfs/hive，etl可以是mapreduce指令碼或hivesql。
隨著大資料應用的發展，人們逐漸對系統的實時性提出了要求，為了計算一些實時指標，就在原來脫機數倉的基礎上增加了乙個實時計算的鏈路，並對資料來源做流式改造（即把資料傳送到訊息佇列），實時計算去訂閱訊息佇列，直接完成指標增量的計算，推送到下游的資料服務中去，由資料服務層完成離線&實時結果的合併。
注：流處理計算的指標批處理依然計算，最終以批處理為準，即每次批處理計算後會覆蓋流處理的結果。（這僅僅是流處理引擎不完善做的折中）
lambda架構問題：
1.同樣的需求需要開發兩套一樣的**
這是lambda架構最大的問題，兩套**不僅僅意味著開發困難（同樣的需求，乙個在批處理引擎上實現，乙個在流處理引擎上實現，還要分別構造資料測試保證兩者結果一致），後期維護更加困難，比如需求變更後需要分別更改兩套**，獨立測試結果，且兩個作業需要同步上線。
2.資源占用增多：同樣的邏輯計算兩次，整體資源占用會增多（多出實時計算這部分）
1.選擇乙個具有重放功能的、能夠儲存歷史資料並支援多消費者的訊息佇列，根據需求設定歷史資料儲存的時長，比如kafka，可以儲存全部歷史資料。
2.當某個或某些指標有重新處理的需求時，按照新邏輯寫乙個新作業，然後從上游訊息佇列的最開始重新消費，把結果寫到乙個新的下游表中。
3.當新作業趕上進度後，應用切換資料來源，讀取2中產生的新結果表。
4.停止老的作業，刪除老的結果表。
對比項lambda架構
實時性實時
實時計算資源
批和流同時執行，資源開銷大
只有流處理，僅針對新需求開發階段執行兩個作業，資源開銷小
重新計算時吞吐
批式全量處理，吞吐較高
流式全量處理，吞吐較批處理低
開發、測試
每個需求都需要兩套不同**，開發、測試、上線難度較大
只需實現一套**，開發、測試、上線難度相對較小
運維成本
維護兩套系統（引擎），運維成本大
只需維護一套系統（引擎），運維成本小
另外，隨著資料多樣性的發展，資料倉儲這種提前規定schema的模式顯得越來難以支援靈活的探索&分析需求，這時候便出現了一種資料湖技術，即把原始資料全部快取到某個大資料儲存上，後續分析時再根據需求去解析原始資料。簡單的說，資料倉儲模式是schema on write，資料湖模式是schema on read。（3）
本案例參考自菜鳥倉配團隊的分享，涉及全域性設計、資料模型、資料保障等幾個方面。
5.1 整體設計
整體設計如右圖，基於業務系統的資料，資料模型採用中間層的設計理念，建設倉配實時數倉；計算引擎，選擇更易用、效能表現更佳的實時計算作為主要的計算引擎；資料服務，選擇天工資料服務中介軟體，避免直連資料庫，且基於天工可以做到主備鏈路靈活配置秒級切換；資料應用，圍繞大促全鏈路，從活動計畫、活動備貨、活動直播、活動售後、活動覆盤五個維度，建設倉配大促資料體系。
5.2 資料模型
不管是從計算成本，還是從易用性，還是從復用性，還是從一致性……，我們都必須避免煙囪式的開發模式，而是以中間層的方式建設倉配實時數倉。與離線中間層基本一致，我們將實時中間層分為兩層。
第一層dwd公共實時明細層
實時計算訂閱業務資料訊息佇列，然後通過資料清洗、多資料來源join、流式資料與離線維度資訊等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加資料易用性和復用性，得到最終的實時明細資料。這部分資料有兩個分支，一部分直接落地到ads，供實時明細查詢使用，一部分再傳送到訊息佇列中，供下層計算使用；
第二層dws公共實時彙總層
以資料域+業務域的理念建設公共彙總層，與脫機數倉不同的是，這裡彙總層分為輕度彙總層和高度彙總層，並同時產出，輕度彙總層寫入ads，用於前端產品複雜的olap查詢場景，滿足自助分析和產出報表的需求；高度彙總層寫入hbase，用於前端比較簡單的kv查詢場景，提公升查詢效能，比如實時大屏等；
注：1.ads是一款提供olap分析服務的引擎。開源提供類似功能的有，elastic search、kylin、druid等；
2.案例中選擇把資料寫入到hbase供kv查詢，也可根據情況選擇其他引擎，比如資料量不多，查詢壓力也不大的話，可以用mysql
3.因主題建模與業務關係較大，這裡不做描述
5.3 資料保障
集團每年都有雙十一等大促，大促期間流量與資料量都會暴增。
實時系統要保證實時性，相對離線系統對資料量要更敏感，對穩定性要求更高。
所以為了應對這種場景，還需要在這種場景下做兩種準備：
在看過前面的敘述與菜鳥案例之後，我們看一下實時數倉與脫機數倉在幾方面的對比：
其次，從建設方法上，實時數倉和脫機數倉基本還是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流資料的join有隱藏時間語義，在建設中需注意。
最後，從資料保障看，實時數倉因為要保證實時性，所以對資料量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線資料的乙個較為明顯的區別。
**：
實時數倉與脫機數倉總結 一
精選30 雲產品，助力企業輕鬆上雲！主要內容 數倉基本概念 數倉架構演變 實時數倉和脫機數倉的區別 數倉基本概念 首先說一下資料倉儲的概念，以下簡稱數倉。數倉的發展 數倉有兩個環節 乙個是數倉的建設 另乙個數倉的應用。早期的數倉 傳統數倉 目前 數倉的架構演變 脫機數倉和實時數倉 接下來我會分別介紹...
脫機數倉到實時數倉的架構演變
1.實時數倉的相關概述 1.1 實時數倉產生背景 我們先來回顧一下資料倉儲的概念。資料倉儲的概念是於 90 年代由 bill inmon 提出,當時的背景是傳統的 oltp 資料庫無法很好的支援長週期分析決策場景，所以資料倉儲概念的 4 個核心點，我們要結合著 oltp 資料庫當時的狀態來對比理解。...
實時數倉1
介紹 丟擲問題有脫機數倉了，做實時數倉，是否能兼顧到以前的指標體系，是不是可以直接替代？類似於畫像體系是否可以在此基礎上進行構建？實時數倉是否可以是實時平台的基礎？架構有沒有明確的定義？框架變化 儲存框架 框架優勢 劣勢mysql 事務查詢 儲存的效能瓶頸 elasticsearch 吞吐量大，快速...