若是你也想作實時數倉…

做者：郭華（付空）

數據倉庫也是公司數據發展到必定規模後必然會提供的一種基礎服務，數據倉庫的建設也是「數據智能」中必不可少的一環。本文將從數據倉庫的簡介、經歷了怎樣的發展、如何建設、架構演變、應用案例以及實時數倉與離線數倉的對比六個方面全面分享關於數倉的詳細內容。

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 架構的對比

1. 在真實的場景中，不少時候並非徹底規範的 Lambda 架構或 Kappa 架構，能夠是二者的混合，好比大部分實時指標使用 Kappa 架構完成計算，少許關鍵指標（好比金額相關）使用 Lambda 架構用批處理從新計算，增長一次校對過程。
2. Kappa 架構並非中間結果徹底不落地，如今不少大數據系統都須要支持機器學習（離線訓練），因此實時中間結果須要落地對應的存儲引擎供機器學習使用，另外有時候還須要對明細數據查詢，這種場景也須要把實時明細層寫出到對應的引擎中。參考後面的案例。
3. 另外，隨着數據多樣性的發展，數據倉庫這種提早規定 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「倉儲配送數據實時化」詳情瞭解~

6. 實時數倉與離線數倉的對比

在看過前面的敘述與菜鳥案例以後，咱們看一下實時數倉與離線數倉在幾方面的對比：

• 首先，從架構上，實時數倉與離線數倉有比較明顯的區別，實時數倉以 Kappa 架構爲主，而離線數倉以傳統大數據架構爲主。Lambda 架構能夠認爲是二者的中間態。
• 其次，從建設方法上，實時數倉和離線數倉基本仍是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流數據的 join 有隱藏時間語義，在建設中需注意。
• 最後，從數據保障看，實時數倉由於要保證明時性，因此對數據量的變化較爲敏感。在大促等場景下須要提早作好壓測和主備保障工做，這是與離線數據的一個較爲明顯的區別。

---

▼ Apache Flink 社區推薦 ▼

Apache Flink 及大數據領域頂級盛會 Flink Forward Asia 2019 重磅開啓，目前正在徵集議題，限量早鳥票優惠ing。瞭解 Flink Forward Asia 2019 的更多信息，請查看：

https://developer.aliyun.com/...

首屆 Apache Flink 極客挑戰賽重磅開啓，聚焦機器學習與性能優化兩大熱門領域，40萬獎金等你拿，加入挑戰請點擊：

https://tianchi.aliyun.com/ma...