1.數(shù)據(jù)倉(cāng)庫(kù)簡(jiǎn)介

數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)面向主題的（Subject Oriented）、集成的（Integrate）、相對(duì)穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合，用于支持管理決策。

數(shù)據(jù)倉(cāng)庫(kù)是伴隨著企業(yè)信息化發(fā)展起來(lái)的，在企業(yè)信息化的過程中，隨著信息化工具的升級(jí)和新工具的應(yīng)用，數(shù)據(jù)量變的越來(lái)越大，數(shù)據(jù)格式越來(lái)越多，決策要求越來(lái)越苛刻，數(shù)據(jù)倉(cāng)庫(kù)技術(shù)也在不停的發(fā)展。

數(shù)據(jù)倉(cāng)庫(kù)的趨勢(shì)：

• 實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)以滿足實(shí)時(shí)化&自動(dòng)化決策需求；
• 大數(shù)據(jù)&數(shù)據(jù)湖以支持大量&復(fù)雜數(shù)據(jù)類型（文本、圖像、視頻、音頻）；

2.數(shù)據(jù)倉(cāng)庫(kù)的發(fā)展

數(shù)據(jù)倉(cāng)庫(kù)有兩個(gè)環(huán)節(jié)：數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)建與數(shù)據(jù)倉(cāng)庫(kù)的應(yīng)用。

早期數(shù)據(jù)倉(cāng)庫(kù)構(gòu)建主要指的是把企業(yè)的業(yè)務(wù)數(shù)據(jù)庫(kù)如ERP、CRM、SCM等數(shù)據(jù)按照決策分析的要求建模并匯總到數(shù)據(jù)倉(cāng)庫(kù)引擎中，其應(yīng)用以報(bào)表為主，目的是支持管理層和業(yè)務(wù)人員決策（中長(zhǎng)期策略型決策）。

隨著業(yè)務(wù)和環(huán)境的發(fā)展，這兩方面都在發(fā)生著劇烈變化。

• 隨著IT技術(shù)走向互聯(lián)網(wǎng)、移動(dòng)化，數(shù)據(jù)源變得越來(lái)越豐富，在原來(lái)業(yè)務(wù)數(shù)據(jù)庫(kù)的基礎(chǔ)上出現(xiàn)了非結(jié)構(gòu)化數(shù)據(jù)，比如網(wǎng)站log，IoT設(shè)備數(shù)據(jù)，APP埋點(diǎn)數(shù)據(jù)等，這些數(shù)據(jù)量比以往結(jié)構(gòu)化的數(shù)據(jù)大了幾個(gè)量級(jí)，對(duì)ETL過程、存儲(chǔ)都提出了更高的要求；
• 互聯(lián)網(wǎng)的在線特性也將業(yè)務(wù)需求推向了實(shí)時(shí)化，隨時(shí)根據(jù)當(dāng)前客戶行為而調(diào)整策略變得越來(lái)越常見，比如大促過程中庫(kù)存管理，運(yùn)營(yíng)管理等（即既有中遠(yuǎn)期策略型，也有短期操作型）；同時(shí)公司業(yè)務(wù)互聯(lián)網(wǎng)化之后導(dǎo)致同時(shí)服務(wù)的客戶劇增，有些情況人工難以完全處理，這就需要機(jī)器自動(dòng)決策。比如欺詐檢測(cè)和用戶審核。

總結(jié)來(lái)看，對(duì)數(shù)據(jù)倉(cāng)庫(kù)的需求可以抽象成兩方面：實(shí)時(shí)產(chǎn)生結(jié)果、處理和保存大量異構(gòu)數(shù)據(jù)。

注：這里不討論數(shù)據(jù)湖技術(shù)。

3.數(shù)據(jù)倉(cāng)庫(kù)建設(shè)方法論

1）面向主題

從公司業(yè)務(wù)出發(fā)，是分析的宏觀領(lǐng)域，比如供應(yīng)商主題、商品主題、客戶主題和倉(cāng)庫(kù)主題

2）為多維數(shù)據(jù)分析服務(wù)

數(shù)據(jù)報(bào)表；數(shù)據(jù)立方體，上卷、下鉆、切片、旋轉(zhuǎn)等分析功能。

3）反范式數(shù)據(jù)模型

以事實(shí)表和維度表組成的星型數(shù)據(jù)模型

注：圖片來(lái)自51CTO

4.數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)的演變

數(shù)據(jù)倉(cāng)庫(kù)概念是Inmon于1990年提出并給出了完整的建設(shè)方法。隨著互聯(lián)網(wǎng)時(shí)代來(lái)臨，數(shù)據(jù)量暴增，開始使用大數(shù)據(jù)工具來(lái)替代經(jīng)典數(shù)倉(cāng)中的傳統(tǒng)工具。此時(shí)僅僅是工具的取代，架構(gòu)上并沒有根本的區(qū)別，可以把這個(gè)架構(gòu)叫做離線大數(shù)據(jù)架構(gòu)。

后來(lái)隨著業(yè)務(wù)實(shí)時(shí)性要求的不斷提高，人們開始在離線大數(shù)據(jù)架構(gòu)基礎(chǔ)上加了一個(gè)加速層，使用流處理技術(shù)直接完成那些實(shí)時(shí)性要求較高的指標(biāo)計(jì)算，這便是Lambda架構(gòu)。

再后來(lái)，實(shí)時(shí)的業(yè)務(wù)越來(lái)越多，事件化的數(shù)據(jù)源也越來(lái)越多，實(shí)時(shí)處理從次要部分變成了主要部分，架構(gòu)也做了相應(yīng)調(diào)整，出現(xiàn)了以實(shí)時(shí)事件處理為核心的Kappa架構(gòu)。

4.1離線大數(shù)據(jù)架構(gòu)

數(shù)據(jù)源通過離線的方式導(dǎo)入到離線數(shù)倉(cāng)中。

下游應(yīng)用根據(jù)業(yè)務(wù)需求選擇直接讀取DM或加一層數(shù)據(jù)服務(wù)，比如mysql 或 redis。

數(shù)據(jù)倉(cāng)庫(kù)從模型層面分為三層：

• ODS，操作數(shù)據(jù)層，保存原始數(shù)據(jù)；
• DWD，數(shù)據(jù)倉(cāng)庫(kù)明細(xì)層，根據(jù)主題定義好事實(shí)與維度表，保存最細(xì)粒度的事實(shí)數(shù)據(jù)；
• DM，數(shù)據(jù)集市/輕度匯總層，在DWD層的基礎(chǔ)之上根據(jù)不同的業(yè)務(wù)需求做輕度匯總；

典型的數(shù)倉(cāng)存儲(chǔ)是HDFS/Hive，ETL可以是MapReduce腳本或HiveSQL。

4.2 Lambda架構(gòu)

隨著大數(shù)據(jù)應(yīng)用的發(fā)展，人們逐漸對(duì)系統(tǒng)的實(shí)時(shí)性提出了要求，為了計(jì)算一些實(shí)時(shí)指標(biāo)，就在原來(lái)離線數(shù)倉(cāng)的基礎(chǔ)上增加了一個(gè)實(shí)時(shí)計(jì)算的鏈路，并對(duì)數(shù)據(jù)源做流式改造（即把數(shù)據(jù)發(fā)送到消息隊(duì)列），實(shí)時(shí)計(jì)算去訂閱消息隊(duì)列，直接完成指標(biāo)增量的計(jì)算，推送到下游的數(shù)據(jù)服務(wù)中去，由數(shù)據(jù)服務(wù)層完成離線&實(shí)時(shí)結(jié)果的合并。

注：流處理計(jì)算的指標(biāo)批處理依然計(jì)算，最終以批處理為準(zhǔn)，即每次批處理計(jì)算后會(huì)覆蓋流處理的結(jié)果。（這僅僅是流處理引擎不完善做的折中）

Lambda架構(gòu)問題：

• 1.同樣的需求需要開發(fā)兩套一樣的代碼
  這是Lambda架構(gòu)最大的問題，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求，一個(gè)在批處理引擎上實(shí)現(xiàn)，一個(gè)在流處理引擎上實(shí)現(xiàn)，還要分別構(gòu)造數(shù)據(jù)測(cè)試保證兩者結(jié)果一致），后期維護(hù)更加困難，比如需求變更后需要分別更改兩套代碼，獨(dú)立測(cè)試結(jié)果，且兩個(gè)作業(yè)需要同步上線。
• 2.資源占用增多：同樣的邏輯計(jì)算兩次，整體資源占用會(huì)增多（多出實(shí)時(shí)計(jì)算這部分）

4.3 Kappa架構(gòu)

Lambda架構(gòu)雖然滿足了實(shí)時(shí)的需求，但帶來(lái)了更多的開發(fā)與運(yùn)維工作，其架構(gòu)背景是流處理引擎還不完善，流處理的結(jié)果只作為臨時(shí)的、近似的值提供參考。后來(lái)隨著Flink等流處理引擎的出現(xiàn)，流處理技術(shù)很成熟了，這時(shí)為了解決兩套代碼的問題，LickedIn 的Jay Kreps提出了Kappa架構(gòu)

Kappa架構(gòu)可以認(rèn)為是Lambda架構(gòu)的簡(jiǎn)化版（只要移除lambda架構(gòu)中的批處理部分即可）。

在Kappa架構(gòu)中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成。

Kappa架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來(lái)彌補(bǔ)。

Kappa架構(gòu)的重新處理過程

重新處理是人們對(duì)Kappa架構(gòu)最擔(dān)心的點(diǎn)，但實(shí)際上并不復(fù)雜：

• 1.選擇一個(gè)具有重放功能的、能夠保存歷史數(shù)據(jù)并支持多消費(fèi)者的消息隊(duì)列，根據(jù)需求設(shè)置歷史數(shù)據(jù)保存的時(shí)長(zhǎng)，比如Kafka，可以保存全部歷史數(shù)據(jù)。
• 2.當(dāng)某個(gè)或某些指標(biāo)有重新處理的需求時(shí)，按照新邏輯寫一個(gè)新作業(yè)，然后從上游消息隊(duì)列的最開始重新消費(fèi)，把結(jié)果寫到一個(gè)新的下游表中。
• 3.當(dāng)新作業(yè)趕上進(jìn)度后，應(yīng)用切換數(shù)據(jù)源，讀取2中產(chǎn)生的新結(jié)果表。
• 4.停止老的作業(yè)，刪除老的結(jié)果表。

4.4 Lambda架構(gòu)與Kappa架構(gòu)的對(duì)比

對(duì)比項(xiàng)	Lambda架構(gòu)	Kappa架構(gòu)
實(shí)時(shí)性	實(shí)時(shí)	實(shí)時(shí)
計(jì)算資源	批和流同時(shí)運(yùn)行，資源開銷大	只有流處理，僅針對(duì)新需求開發(fā)階段運(yùn)行兩個(gè)作業(yè)，資源開銷小
重新計(jì)算時(shí)吞吐	批式全量處理，吞吐較高	流式全量處理，吞吐較批處理低
開發(fā)、測(cè)試	每個(gè)需求都需要兩套不同代碼，開發(fā)、測(cè)試、上線難度較大	只需實(shí)現(xiàn)一套代碼，開發(fā)、測(cè)試、上線難度相對(duì)較小
運(yùn)維成本	維護(hù)兩套系統(tǒng)（引擎），運(yùn)維成本大	只需維護(hù)一套系統(tǒng)（引擎），運(yùn)維成本小

在真實(shí)的場(chǎng)景中，很多時(shí)候并不是完全規(guī)范的Lambda架構(gòu)或Kappa架構(gòu)，可以是兩者的混合，比如大部分實(shí)時(shí)指標(biāo)使用Kappa架構(gòu)完成計(jì)算，少量關(guān)鍵指標(biāo)（比如金額相關(guān)）使用Lambda架構(gòu)用批處理重新計(jì)算，增加一次校對(duì)過程。（1）

Kappa架構(gòu)并不是中間結(jié)果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機(jī)器學(xué)習(xí)（離線訓(xùn)練），所以實(shí)時(shí)中間結(jié)果需要落地對(duì)應(yīng)的存儲(chǔ)引擎供機(jī)器學(xué)習(xí)使用，另外有時(shí)候還需要對(duì)明細(xì)數(shù)據(jù)查詢，這種場(chǎng)景也需要把實(shí)時(shí)明細(xì)層寫出到對(duì)應(yīng)的引擎中。（2）參考后面的案例

另外，隨著數(shù)據(jù)多樣性的發(fā)展，數(shù)據(jù)倉(cāng)庫(kù)這種提前規(guī)定schema的模式顯得越來(lái)難以支持靈活的探索&分析需求，這時(shí)候便出現(xiàn)了一種數(shù)據(jù)湖技術(shù)，即把原始數(shù)據(jù)全部緩存到某個(gè)大數(shù)據(jù)存儲(chǔ)上，后續(xù)分析時(shí)再根據(jù)需求去解析原始數(shù)據(jù)。簡(jiǎn)單的說(shuō)，數(shù)據(jù)倉(cāng)庫(kù)模式是schema on write，數(shù)據(jù)湖模式是schema on read。（3）

5.實(shí)時(shí)數(shù)倉(cāng)案例

菜鳥倉(cāng)配實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)

本案例參考自菜鳥倉(cāng)配團(tuán)隊(duì)的分享，涉及全局設(shè)計(jì)、數(shù)據(jù)模型、數(shù)據(jù)保障等幾個(gè)方面。

注：特別感謝緣橋同學(xué)的無(wú)私分享。

5.1 整體設(shè)計(jì)

整體設(shè)計(jì)如右圖，基于業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，數(shù)據(jù)模型采用中間層的設(shè)計(jì)理念，建設(shè)倉(cāng)配實(shí)時(shí)數(shù)倉(cāng)；計(jì)算引擎，選擇更易用、性能表現(xiàn)更佳的實(shí)時(shí)計(jì)算作為主要的計(jì)算引擎；數(shù)據(jù)服務(wù)，選擇天工數(shù)據(jù)服務(wù)中間件，避免直連數(shù)據(jù)庫(kù)，且基于天工可以做到主備鏈路靈活配置秒級(jí)切換；數(shù)據(jù)應(yīng)用，圍繞大促全鏈路，從活動(dòng)計(jì)劃、活動(dòng)備貨、活動(dòng)直播、活動(dòng)售后、活動(dòng)復(fù)盤五個(gè)維度，建設(shè)倉(cāng)配大促數(shù)據(jù)體系。

5.2 數(shù)據(jù)模型

不管是從計(jì)算成本，還是從易用性，還是從復(fù)用性，還是從一致性……，我們都必須避免煙囪式的開發(fā)模式，而是以中間層的方式建設(shè)倉(cāng)配實(shí)時(shí)數(shù)倉(cāng)。與離線中間層基本一致，我們將實(shí)時(shí)中間層分為兩層。

第一層DWD公共實(shí)時(shí)明細(xì)層

實(shí)時(shí)計(jì)算訂閱業(yè)務(wù)數(shù)據(jù)消息隊(duì)列，然后通過數(shù)據(jù)清洗、多數(shù)據(jù)源join、流式數(shù)據(jù)與離線維度信息等的組合，將一些相同粒度的業(yè)務(wù)系統(tǒng)、維表中的維度屬性全部關(guān)聯(lián)到一起，增加數(shù)據(jù)易用性和復(fù)用性，得到最終的實(shí)時(shí)明細(xì)數(shù)據(jù)。這部分?jǐn)?shù)據(jù)有兩個(gè)分支，一部分直接落地到ADS，供實(shí)時(shí)明細(xì)查詢使用，一部分再發(fā)送到消息隊(duì)列中，供下層計(jì)算使用；

第二層DWS公共實(shí)時(shí)匯總層

以數(shù)據(jù)域+業(yè)務(wù)域的理念建設(shè)公共匯總層，與離線數(shù)倉(cāng)不同的是，這里匯總層分為輕度匯總層和高度匯總層，并同時(shí)產(chǎn)出，輕度匯總層寫入ADS，用于前端產(chǎn)品復(fù)雜的olap查詢場(chǎng)景，滿足自助分析和產(chǎn)出報(bào)表的需求；高度匯總層寫入Hbase，用于前端比較簡(jiǎn)單的kv查詢場(chǎng)景，提升查詢性能，比如實(shí)時(shí)大屏等；

注：

1.ADS是一款提供OLAP分析服務(wù)的引擎。開源提供類似功能的有，Elastic Search、Kylin、Druid等；
2.案例中選擇把數(shù)據(jù)寫入到Hbase供KV查詢，也可根據(jù)情況選擇其他引擎，比如數(shù)據(jù)量不多，查詢壓力也不大的話，可以用mysql
3.因主題建模與業(yè)務(wù)關(guān)系較大，這里不做描述

5.3 數(shù)據(jù)保障

集團(tuán)每年都有雙十一等大促，大促期間流量與數(shù)據(jù)量都會(huì)暴增。

實(shí)時(shí)系統(tǒng)要保證實(shí)時(shí)性，相對(duì)離線系統(tǒng)對(duì)數(shù)據(jù)量要更敏感，對(duì)穩(wěn)定性要求更高。

所以為了應(yīng)對(duì)這種場(chǎng)景，還需要在這種場(chǎng)景下做兩種準(zhǔn)備：

• 大促前的系統(tǒng)壓測(cè)；
• 大促中的主備鏈路保障；

6. 實(shí)時(shí)數(shù)倉(cāng)與離線數(shù)倉(cāng)的對(duì)比

在看過前面的敘述與菜鳥案例之后，我們看一下實(shí)時(shí)數(shù)倉(cāng)與離線數(shù)倉(cāng)在幾方面的對(duì)比：

首先，從架構(gòu)上，實(shí)時(shí)數(shù)倉(cāng)與離線數(shù)倉(cāng)有比較明顯的區(qū)別，實(shí)時(shí)數(shù)倉(cāng)以Kappa架構(gòu)為主，而離線數(shù)倉(cāng)以傳統(tǒng)大數(shù)據(jù)架構(gòu)為主。Lambda架構(gòu)可以認(rèn)為是兩者的中間態(tài)。

其次，從建設(shè)方法上，實(shí)時(shí)數(shù)倉(cāng)和離線數(shù)倉(cāng)基本還是沿用傳統(tǒng)的數(shù)倉(cāng)主題建模理論，產(chǎn)出事實(shí)寬表。另外實(shí)時(shí)數(shù)倉(cāng)中實(shí)時(shí)流數(shù)據(jù)的join有隱藏時(shí)間語(yǔ)義，在建設(shè)中需注意。

最后，從數(shù)據(jù)保障看，實(shí)時(shí)數(shù)倉(cāng)因?yàn)橐ＷC實(shí)時(shí)性，所以對(duì)數(shù)據(jù)量的變化較為敏感。在大促等場(chǎng)景下需要提前做好壓測(cè)和主備保障工作，這是與離線數(shù)據(jù)的一個(gè)較為明顯的區(qū)別。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的数据仓库介绍与实时数仓案例的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。