【與資料同行】已開通綜合、資料倉庫、資料分析、産品經理、資料治理及機器學習六大專業群，加微信号frank61822702 為好友後入群。新開招聘交流群，請關注【與資料同行】公衆号，背景回複“招聘”後獲得入群方法。
正文開始
資料倉庫也是公司資料發展到一定規模後必然會提供的一種基礎服務，資料倉庫的建設也是“資料智能”中必不可少的一環。本文将從資料倉庫的簡介、經曆了怎樣的發展、如何建設、架構演變、應用案例以及實時數倉與離線數倉的對比六個方面全面分享關于數倉的詳細内容。
1.資料倉庫簡介
資料倉庫是一個面向主題的（Subject Oriented）、內建的（Integrate）、相對穩定的（Non-Volatile）、反映曆史變化（Time Variant）的資料集合，用于支援管理決策。
資料倉庫是伴随着企業資訊化發展起來的，在企業資訊化的過程中，随着資訊化工具的更新和新工具的應用，資料量變的越來越大，資料格式越來越多，決策要求越來越苛刻，資料倉庫技術也在不停的發展。
資料倉庫的趨勢：
- 實時資料倉庫以滿足實時化&自動化決策需求；
- 大資料&資料湖以支援大量&複雜資料類型（文本、圖像、視訊、音頻）；
2.資料倉庫的發展
資料倉庫有兩個環節：資料倉庫的建構與資料倉庫的應用。
早期資料倉庫建構主要指的是把企業的業務資料庫如 ERP、CRM、SCM 等資料按照決策分析的要求模組化并彙總到資料倉庫引擎中，其應用以報表為主，目的是支援管理層和業務人員決策（中長期政策型決策）。
随着業務和環境的發展，這兩方面都在發生着劇烈變化。
- 随着IT技術走向網際網路、移動化，資料源變得越來越豐富，在原來業務資料庫的基礎上出現了非結構化資料，比如網站 log，IoT 裝置資料，APP 埋點資料等，這些資料量比以往結構化的資料大了幾個量級，對 ETL 過程、存儲都提出了更高的要求；
- 網際網路的線上特性也将業務需求推向了實時化，随時根據目前客戶行為而調整政策變得越來越常見，比如大促過程中庫存管理，營運管理等（即既有中遠期政策型，也有短期操作型）；同時公司業務網際網路化之後導緻同時服務的客戶劇增，有些情況人工難以完全處理，這就需要機器自動決策。比如欺詐檢測和使用者稽核。
總結來看，對資料倉庫的需求可以抽象成兩方面：實時産生結果、處理和儲存大量異構資料。
注：這裡不讨論資料湖技術。
3.資料倉庫建設方法論
3.1 面向主題
從公司業務出發，是分析的宏觀領域，比如供應商主題、商品主題、客戶主題和倉庫主題
3.2 為多元資料分析服務
資料報表；資料立方體，上卷、下鑽、切片、旋轉等分析功能。
3.3 反範式資料模型
以事實表和次元表組成的星型資料模型
注：圖檔來自 51 CTO
4.資料倉庫架構的演變
資料倉庫概念是 Inmon 于 1990 年提出并給出了完整的建設方法。随着網際網路時代來臨，資料量暴增，開始使用大資料工具來替代經典數倉中的傳統工具。此時僅僅是工具的取代，架構上并沒有根本的差別，可以把這個架構叫做離線大資料架構。
後來随着業務實時性要求的不斷提高，人們開始在離線大資料架構基礎上加了一個加速層，使用流處理技術直接完成那些實時性要求較高的名額計算，這便是 Lambda 架構。
再後來，實時的業務越來越多，事件化的資料源也越來越多，實時處理從次要部分變成了主要部分，架構也做了相應調整，出現了以實時事件處理為核心的 Kappa 架構。
4.1 離線大資料架構
資料源通過離線的方式導入到離線數倉中。下遊應用根據業務需求選擇直接讀取 DM 或加一層資料服務，比如 MySQL 或 Redis。資料倉庫從模型層面分為三層：
- ODS，操作資料層，儲存原始資料；
- DWD，資料倉庫明細層，根據主題定義好事實與次元表，儲存最細粒度的事實資料；
- DM，資料集市/輕度彙總層，在 DWD 層的基礎之上根據不同的業務需求做輕度彙總；
典型的數倉存儲是 HDFS/Hive，ETL 可以是 MapReduce 腳本或 HiveSQL。
4.2 Lambda 架構
随着大資料應用的發展，人們逐漸對系統的實時性提出了要求，為了計算一些實時名額，就在原來離線數倉的基礎上增加了一個實時計算的鍊路，并對資料源做流式改造（即把資料發送到消息隊列），實時計算去訂閱消息隊列，直接完成名額增量的計算，推送到下遊的資料服務中去，由資料服務層完成離線&實時結果的合并。
注：流處理計算的名額批處理依然計算，最終以批處理為準，即每次批處理計算後會覆寫流處理的結果。（這僅僅是流處理引擎不完善做的折中）
Lambda 架構問題：
- 同樣的需求需要開發兩套一樣的代碼：這是 Lambda 架構最大的問題，兩套代碼不僅僅意味着開發困難（同樣的需求，一個在批處理引擎上實作，一個在流處理引擎上實作，還要分别構造資料測試保證兩者結果一緻），後期維護更加困難，比如需求變更後需要分别更改兩套代碼，獨立測試結果，且兩個作業需要同步上線。
- 資源占用增多：同樣的邏輯計算兩次，整體資源占用會增多（多出實時計算這部分
4.3 Kappa 架構
Lambda 架構雖然滿足了實時的需求，但帶來了更多的開發與運維工作，其架構背景是流處理引擎還不完善，流處理的結果隻作為臨時的、近似的值提供參考。後來随着 Flink 等流處理引擎的出現，流處理技術很成熟了，這時為了解決兩套代碼的問題，LickedIn 的 Jay Kreps 提出了 Kappa 架構。
- Kappa 架構可以認為是 Lambda 架構的簡化版（隻要移除 lambda 架構中的批處理部分即可）。
- 在 Kappa 架構中，需求修改或曆史資料重新處理都通過上遊重放完成。
- Kappa 架構最大的問題是流式重新處理曆史的吞吐能力會低于批處理，但這個可以通過增加計算資源來彌補。
Kappa 架構的重新處理過程：
重新處理是人們對 Kappa 架構最擔心的點，但實際上并不複雜：
- 選擇一個具有重放功能的、能夠儲存曆史資料并支援多消費者的消息隊列，根據需求設定曆史資料儲存的時長，比如 Kafka，可以儲存全部曆史資料。
- 當某個或某些名額有重新處理的需求時，按照新邏輯寫一個新作業，然後從上遊消息隊列的最開始重新消費，把結果寫到一個新的下遊表中。
- 當新作業趕上進度後，應用切換資料源，讀取 2 中産生的新結果表。
- 停止老的作業，删除老的結果表。
4.4 Lambda 架構與 Kappa 架構的對比
- 在真實的場景中，很多時候并不是完全規範的 Lambda 架構或 Kappa 架構，可以是兩者的混合，比如大部分實時名額使用 Kappa 架構完成計算，少量關鍵名額（比如金額相關）使用 Lambda 架構用批處理重新計算，增加一次校對過程。
- Kappa 架構并不是中間結果完全不落地，現在很多大資料系統都需要支援機器學習（離線訓練），是以實時中間結果需要落地對應的存儲引擎供機器學習使用，另外有時候還需要對明細資料查詢，這種場景也需要把實時明細層寫出到對應的引擎中。參考後面的案例。
- 另外，随着資料多樣性的發展，資料倉庫這種提前規定 schema 的模式顯得越來難以支援靈活的探索&分析需求，這時候便出現了一種資料湖技術，即把原始資料全部緩存到某個大資料存儲上，後續分析時再根據需求去解析原始資料。簡單的說，資料倉庫模式是 schema on write，資料湖模式是 schema on read。
5.實時數倉案例
菜鳥倉配實時資料倉庫本案例參考自菜鳥倉配團隊的分享，涉及全局設計、資料模型、資料保障等幾個方面。
注：特别感謝緣橋同學的無私分享。
5.1 整體設計
整體設計如下圖，基于業務系統的資料，資料模型采用中間層的設計理念，建設倉配實時數倉；計算引擎，選擇更易用、性能表現更佳的實時計算作為主要的計算引擎；資料服務，選擇天工資料服務中間件，避免直連資料庫，且基于天工可以做到主備鍊路靈活配置秒級切換；資料應用，圍繞大促全鍊路，從活動計劃、活動備貨、活動直播、活動售後、活動複盤五個次元，建設倉配大促資料體系。
5.2 資料模型
不管是從計算成本，還是從易用性，還是從複用性，還是從一緻性等等，我們都必須避免煙囪式的開發模式，而是以中間層的方式建設倉配實時數倉。與離線中間層基本一緻，我們将實時中間層分為兩層。
- 第一層 DWD 公共實時明細層
實時計算訂閱業務資料消息隊列，然後通過資料清洗、多資料源 join、流式資料與離線次元資訊等的組合，将一些相同粒度的業務系統、維表中的次元屬性全部關聯到一起，增加資料易用性和複用性，得到最終的實時明細資料。這部分資料有兩個分支，一部分直接落地到 ADS，供實時明細查詢使用，一部分再發送到消息隊列中，供下層計算使用；
- 第二層 DWS 公共實時彙總層
以資料域+業務域的理念建設公共彙總層，與離線數倉不同的是，這裡彙總層分為輕度彙總層和高度彙總層，并同時産出，輕度彙總層寫入 ADS，用于前端産品複雜的 olap 查詢場景，滿足自助分析和産出報表的需求；高度彙總層寫入 Hbase，用于前端比較簡單的 kv 查詢場景，提升查詢性能，比如實時大屏等；
注：
- ADS 是一款提供 OLAP 分析服務的引擎。開源提供類似功能的有，Elastic Search、Kylin、Druid 等；
- 案例中選擇把資料寫入到 Hbase 供 KV 查詢，也可根據情況選擇其他引擎，比如資料量不多，查詢壓力也不大的話，可以用 MySQL；
- 因主題模組化與業務關系較大，這裡不做描述；
5.3 資料保障
阿裡巴巴每年都有雙十一等大促，大促期間流量與資料量都會暴增。實時系統要保證明時性，相對離線系統對資料量要更敏感，對穩定性要求更高。是以為了應對這種場景，還需要在這種場景下做兩種準備：
- 大促前的系統壓測；
- 大促中的主備鍊路保障；
菜鳥雙11「倉儲配送資料實時化」詳情了解：
https://yq.aliyun.com/articles/658787?spm=a2c4e.11153940.0.0.449f1d531ZoDbX
6. 實時數倉與離線數倉的對比
在看過前面的叙述與菜鳥案例之後，我們看一下實時數倉與離線數倉在幾方面的對比：
- 首先，從架構上，實時數倉與離線數倉有比較明顯的差別，實時數倉以 Kappa 架構為主，而離線數倉以傳統大資料架構為主。Lambda 架構可以認為是兩者的中間态。
- 其次，從建設方法上，實時數倉和離線數倉基本還是沿用傳統的數倉主題模組化理論，産出事實寬表。另外實時數倉中實時流資料的 join 有隐藏時間語義，在建設中需注意。
- 最後，從資料保障看，實時數倉因為要保證明時性，是以對資料量的變化較為敏感。在大促等場景下需要提前做好壓測和主備保障工作，這是與離線資料的一個較為明顯的差別。
《與資料同行》為您提供最好的文章！
長按二維碼關注“與資料同行”
猜你想看更多的文章????
相伴十六載，講講我和資料倉庫的故事（二）
相伴十六載，講講我和資料倉庫的故事（一）
業務為王，這兩年我們采用的那些資料産品和技術引擎
大資料架構如何做到流批一體？
美團點評基于 Flink 的實時數倉平台實踐
“做好大資料測試，我是認真的！”
辨析BI、資料倉庫、資料湖和資料中台内涵及差異點(建議收藏)
一文讀懂非關系型資料庫（NoSQL）
如何深入淺出的了解資料倉庫模組化？
痛苦與變革，如何避免大資料PaaS平台建設中的這些“坑”？
如何打造靈活的資料挖掘能力？
解讀雲栖大會的《阿裡巴巴資料服務産品開發及大資料體系》
一個傳統企業大資料發展的編年史
為什麼選擇這樣的大資料平台架構？
重新認識資料可視化
看上去很美, 談談阿裡雲的大資料平台「數加」
浙江移動大資料平台踐行之路（下）
要看更多，請點選左下角閱讀原文即可閱讀整理好的所有文章！