資料倉儲也是公司資料發展到一定規模後必然會提供的一種基礎服務，資料倉儲的建設也是「資料智慧型」中必不可少的一環。本文將從資料倉儲的簡介、經歷了怎樣的發展、如何建設、架構演變、應用案例以及實時數倉與脫機數倉的對比六個方面全面分享關於數倉的詳細內容。
資料倉儲是乙個面向主題的（subject oriented）、整合的（integrate）、相對穩定的（non-volatile）、反映歷史變化（time variant）的資料集合，用於支援管理決策。
資料倉儲是伴隨著企業資訊化發展起來的，在企業資訊化的過程中，隨著資訊化工具的公升級和新工具的應用，資料量變的越來越大，資料格式越來越多，決策要求越來越苛刻，資料倉儲技術也在不停的發展。
資料倉儲的趨勢：
資料倉儲有兩個環節：資料倉儲的構建與資料倉儲的應用。
早期資料倉儲構建主要指的是把企業的業務資料庫如 erp、crm、scm 等資料按照決策分析的要求建模並彙總到資料倉儲引擎中，其應用以報表為主，目的是支援管理層和業務人員決策（中長期策略型決策）。
隨著業務和環境的發展，這兩方面都在發生著劇烈變化。
總結來看，對資料倉儲的需求可以抽象成兩方面：實時產生結果、處理和儲存大量異構資料。
注：這裡不討論資料湖技術。從公司業務出發，是分析的巨集觀領域，比如**商主題、商品主題、客戶主題和倉庫主題
資料包表；資料立方體，上捲、下鑽、切片、旋轉等分析功能。
以事實表和維度表組成的星型資料模型
資料倉儲概念是 inmon 於 1990 年提出並給出了完整的建設方法。隨著網際網路時代來臨，資料量暴增，開始使用大資料工具來替代經典數倉中的傳統工具。此時僅僅是工具的取代，架構上並沒有根本的區別，可以把這個架構叫做離線大資料架構。
後來隨著業務實時性要求的不斷提高，人們開始在離線大資料架構基礎上加了乙個加速層，使用流處理技術直接完成那些實時性要求較高的指標計算，這便是 lambda 架構。
資料來源通過離線的方式匯入到脫機數倉中。下游應用根據業務需求選擇直接讀取 dm 或加一層資料服務，比如 mysql 或 redis。資料倉儲從模型層面分為三層：
典型的數倉儲存是 hdfs/hive，etl 可以是 mapreduce 指令碼或 hivesql。
隨著大資料應用的發展，人們逐漸對系統的實時性提出了要求，為了計算一些實時指標，就在原來脫機數倉的基礎上增加了乙個實時計算的鏈路，並對資料來源做流式改造（即把資料傳送到訊息佇列），實時計算去訂閱訊息佇列，直接完成指標增量的計算，推送到下游的資料服務中去，由資料服務層完成離線&實時結果的合併。
注：流處理計算的指標批處理依然計算，最終以批處理為準，即每次批處理計算後會覆蓋流處理的結果。（這僅僅是流處理引擎不完善做的折中）lambda 架構問題：
另外，隨著資料多樣性的發展，資料倉儲這種提前規定 schema 的模式顯得越來難以支援靈活的探索&分析需求，這時候便出現了一種資料湖技術，即把原始資料全部快取到某個大資料儲存上，後續分析時再根據需求去解析原始資料。簡單的說，資料倉儲模式是 schema on write，資料湖模式是 schema on read。
菜鳥倉配實時資料倉儲本案例參考自菜鳥倉配團隊的分享，涉及全域性設計、資料模型、資料保障等幾個方面。
注：特別感謝緣橋同學的無私分享。整體設計如下圖，基於業務系統的資料，資料模型採用中間層的設計理念，建設倉配實時數倉；計算引擎，選擇更易用、效能表現更佳的實時計算作為主要的計算引擎；資料服務，選擇天工資料服務中介軟體，避免直連資料庫，且基於天工可以做到主備鏈路靈活配置秒級切換；資料應用，圍繞大促全鏈路，從活動計畫、活動備貨、活動直播、活動售後、活動覆盤五個維度，建設倉配大促資料體系。
不管是從計算成本，還是從易用性，還是從復用性，還是從一致性等等，我們都必須避免煙囪式的開發模式，而是以中間層的方式建設倉配實時數倉。與離線中間層基本一致，我們將實時中間層分為兩層。
實時計算訂閱業務資料訊息佇列，然後通過資料清洗、多資料來源 join、流式資料與離線維度資訊等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加資料易用性和復用性，得到最終的實時明細資料。這部分資料有兩個分支，一部分直接落地到 ads，供實時明細查詢使用，一部分再傳送到訊息佇列中，供下層計算使用；
以資料域+業務域的理念建設公共彙總層，與脫機數倉不同的是，這裡彙總層分為輕度彙總層和高度彙總層，並同時產出，輕度彙總層寫入 ads，用於前端產品複雜的 olap 查詢場景，滿足自助分析和產出報表的需求；高度彙總層寫入 hbase，用於前端比較簡單的 kv 查詢場景，提公升查詢效能，比如實時大屏等；
注：
阿里巴巴每年都有雙十一等大促，大促期間流量與資料量都會暴增。實時系統要保證實時性，相對離線系統對資料量要更敏感，對穩定性要求更高。所以為了應對這種場景，還需要在這種場景下做兩種準備：
菜鳥雙11「倉儲配送資料實時化」詳情了解~
在看過前面的敘述與菜鳥案例之後，我們看一下實時數倉與脫機數倉在幾方面的對比：
其次，從建設方法上，實時數倉和脫機數倉基本還是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流資料的 join 有隱藏時間語義，在建設中需注意。
最後，從資料保障看，實時數倉因為要保證實時性，所以對資料量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線資料的乙個較為明顯的區別。
實時數倉1
介紹 丟擲問題有脫機數倉了，做實時數倉，是否能兼顧到以前的指標體系，是不是可以直接替代？類似於畫像體系是否可以在此基礎上進行構建？實時數倉是否可以是實時平台的基礎？架構有沒有明確的定義？框架變化 儲存框架 框架優勢 劣勢mysql 事務查詢 儲存的效能瓶頸 elasticsearch 吞吐量大，快速...
實時數倉 Lambda架構
在某些場景中，資料的價值隨著時間的推移而逐漸減少。所以在傳統大資料脫機數倉的基礎上，逐漸對資料的實時性提出了更高的要求。其中lambda架構是較早的解決方案，使用流處理和批處理兩種架構進行資料處理。其中流處理部分負責實時資料的處理，但流處理因為資料可靠性並不高，所以需要批處理部分定期進行運算稽查。流...
如果你真的想做
如果真的大家要學到東西,就不要各自為戰,從乙個完整的專案開始,1.專案策化開始 專案的目的,使用者群,市場定位,同類產品中的定位等等,現在發展系統很多,沒有好的定位,有什麼用呀 2.需求開發 到底有那些需求,不要以為新聞發布系統就簡單,否則只是重複勞動,我認為從最最簡單的新聞系統入手，不斷完善這個提...