編輯導(dǎo)讀：在數(shù)據(jù)分析中，實(shí)時(shí)數(shù)據(jù)倉庫很重要，它決定了報(bào)表和BI到底能不能實(shí)時(shí)展現(xiàn)數(shù)據(jù)。但很多人可能都對(duì)它不夠了解，本文作者結(jié)合自己的工作實(shí)踐，從7個(gè)方面分享了數(shù)據(jù)倉庫建設(shè)的相關(guān)步驟和需要注意的問題，一起來看看~

之前發(fā)了一篇數(shù)據(jù)倉庫的文章，發(fā)現(xiàn)大家對(duì)數(shù)據(jù)倉庫還是非常感興趣的。今天再和大家一起聊聊實(shí)時(shí)數(shù)倉吧！

實(shí)時(shí)數(shù)倉可謂是決定性的東西，能決定什么？決定你的報(bào)表和BI到底能不能實(shí)時(shí)展現(xiàn)數(shù)據(jù)。

01 數(shù)據(jù)倉庫的發(fā)展趨勢(shì)

1.1 數(shù)據(jù)倉庫的趨勢(shì)

關(guān)于數(shù)據(jù)倉庫的概念就不多介紹了。

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

數(shù)據(jù)倉庫的趨勢(shì)：

• 實(shí)時(shí)數(shù)據(jù)倉庫以滿足實(shí)時(shí)化&自動(dòng)化決策需求
• 大數(shù)據(jù)&數(shù)據(jù)可以支持大量&復(fù)雜數(shù)據(jù)類型

1.2 數(shù)據(jù)倉庫的發(fā)展

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

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

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

隨著IT技術(shù)走向互聯(lián)網(wǎng)、移動(dòng)化，數(shù)據(jù)源變得越來越豐富，在原來業(yè)務(wù)數(shù)據(jù)庫的基礎(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)整策略變得越來越常見，比如大促過程中庫存管理，運(yùn)營管理等（即既有中遠(yuǎn)期策略型，也有短期操作型）；同時(shí)公司業(yè)務(wù)互聯(lián)網(wǎng)化之后導(dǎo)致同時(shí)服務(wù)的客戶劇增，有些情況人工難以完全處理，這就需要機(jī)器自動(dòng)決策，比如欺詐檢測(cè)和用戶審核。

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

02 數(shù)據(jù)倉庫架構(gòu)的演變

從1990年 Inmon 提出數(shù)據(jù)倉庫概念到今天，數(shù)據(jù)架構(gòu)經(jīng)歷了最初的傳統(tǒng)數(shù)倉架構(gòu)——離線數(shù)倉庫——離線大數(shù)據(jù)架構(gòu)、Lambda 架構(gòu)、Kappa 架構(gòu)以及 Flink 的火熱帶出的流批一體架構(gòu)，數(shù)據(jù)架構(gòu)技術(shù)不斷演進(jìn)，本質(zhì)是在往流批一體的方向發(fā)展，讓用戶能以最自然、最小的成本完成實(shí)時(shí)計(jì)算。

2.1 傳統(tǒng)數(shù)倉架構(gòu)

這是比較傳統(tǒng)的一種方式，結(jié)構(gòu)或半結(jié)構(gòu)化數(shù)據(jù)通過離線ETL定期加載到離線數(shù)據(jù)，之后通過計(jì)算引擎取得結(jié)果，供前端使用。這里的離線數(shù)倉+計(jì)算引擎，通常是使用大型商業(yè)數(shù)據(jù)庫來承擔(dān)，例如Oracle、DB2、Teradata等。

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

隨著數(shù)據(jù)規(guī)模的不斷增大，傳統(tǒng)數(shù)倉方式難以承載海量數(shù)據(jù)。隨著大數(shù)據(jù)技術(shù)的普及，采用大數(shù)據(jù)技術(shù)來承載存儲(chǔ)與計(jì)算任務(wù)。當(dāng)然，也可以使用傳傳統(tǒng)數(shù)據(jù)庫集群或MPP架構(gòu)數(shù)據(jù)庫來完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

2.3 Lambda架構(gòu)

隨著業(yè)務(wù)的發(fā)展，隨著業(yè)務(wù)的發(fā)展，人們對(duì)數(shù)據(jù)實(shí)時(shí)性提出了更高的要求。此時(shí)，出現(xiàn)了Lambda架構(gòu)，其將對(duì)實(shí)時(shí)性要求高的部分拆分出來，增加條實(shí)時(shí)計(jì)算鏈路。從源頭開始做流式改造，將數(shù)據(jù)發(fā)送到消息隊(duì)列中，實(shí)時(shí)計(jì)算引擎消費(fèi)隊(duì)列數(shù)據(jù)，完成實(shí)時(shí)數(shù)據(jù)的增量計(jì)算。

與此同時(shí)，批量處理部分依然存在，實(shí)時(shí)與批量并行運(yùn)行。最終由統(tǒng)一的數(shù)據(jù)服務(wù)層合并結(jié)果給予前端。一般是以批量處理結(jié)果為準(zhǔn)，實(shí)時(shí)結(jié)果主要為快速響應(yīng)。

2.4 Kappa架構(gòu)

Lambda架構(gòu)，一個(gè)比較嚴(yán)重的問題就是需要維護(hù)兩套邏輯。一部分在批量引擎實(shí)現(xiàn)，一部分在流式引擎實(shí)現(xiàn)，維護(hù)成本很高。此外，對(duì)資源消耗也較大。而后面誕生的Kappa架構(gòu)，正是為了解決上述問題。其在數(shù)據(jù)需要重新處理或數(shù)據(jù)變更時(shí)，可通過歷史數(shù)據(jù)重新處理來完成。

方式是通過上游重放完成(從數(shù)據(jù)源拉取數(shù)據(jù)重新計(jì)算)。Kappa架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來彌補(bǔ)。

2.5混合架構(gòu)

上述架構(gòu)各有其適應(yīng)場(chǎng)景，有時(shí)需要綜合使用上述架構(gòu)組合滿足實(shí)際需求。當(dāng)然這也必將帶來架構(gòu)的復(fù)雜度。用戶應(yīng)根據(jù)自身需求，有所取舍。在一般大多數(shù)場(chǎng)景下，是可以使用單一架構(gòu)解決問題?，F(xiàn)在很多產(chǎn)品在流批一體、海量、實(shí)時(shí)性方面也有非常好的表現(xiàn)，可以考慮這種“全能手”解決問題。

03 三種大數(shù)據(jù)數(shù)據(jù)倉庫架構(gòu)

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

數(shù)據(jù)源通過離線的方式導(dǎo)入到離線數(shù)據(jù)中。下游應(yīng)用根據(jù)業(yè)務(wù)需求選擇直接讀取 DM 或加一層數(shù)據(jù)服務(wù)，比如 MySQL 或 Redis。數(shù)據(jù)倉庫從模型層面分為三層：

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

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

3.2 Lambda 架構(gòu)

Lambda 架構(gòu)問題：

同樣的需求需要開發(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è)需要同步上線。

資源占用增多：同樣的邏輯計(jì)算兩次，整體資源占用會(huì)增多，多出實(shí)時(shí)計(jì)算這部分。

3.3 Kappa 架構(gòu)

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

Kappa 架構(gòu)可以認(rèn)為是 Lambda 架構(gòu)的簡化版（只要移除 lambda 架構(gòu)中的批處理部分即可）。
在 Kappa 架構(gòu)中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成。
Kappa 架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來彌補(bǔ)。

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

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

在真實(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ì)過程。

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)的引擎中。后面案例會(huì)涉及到。

04 實(shí)時(shí)數(shù)倉建設(shè)思路

• 計(jì)算框架選型：storm/flink等實(shí)時(shí)計(jì)算框架，強(qiáng)烈推薦flink，其『批量合一』的特性及活躍的開源社區(qū)，有逐漸替代spark的趨勢(shì)。
• 數(shù)據(jù)存儲(chǔ)選型：首要考慮查詢效率，其次是插入、更新等問題，可選擇apache druid，不過在數(shù)據(jù)更新上存在缺陷，選型時(shí)注意該問題頻繁更新的數(shù)據(jù)建議不要采用該方案。當(dāng)然存儲(chǔ)這塊需要具體問題具體分析，不同場(chǎng)景下hbase、redis等都是可選項(xiàng)。
• 實(shí)時(shí)數(shù)倉分層：為更好的統(tǒng)一管理數(shù)據(jù)，實(shí)時(shí)數(shù)倉可采用離線數(shù)倉的數(shù)據(jù)模型進(jìn)行分層處理，可以分為實(shí)時(shí)明細(xì)層寫入druid等查詢效率高的存儲(chǔ)方便下游使用；輕度匯總層對(duì)數(shù)據(jù)進(jìn)行匯總分析后供下游使用。
• 數(shù)據(jù)流轉(zhuǎn)方案：實(shí)時(shí)數(shù)倉的數(shù)據(jù)來源可以為kafka消息隊(duì)列，這樣可以做到隊(duì)列中的數(shù)據(jù)即可以寫入數(shù)據(jù)湖用于批量分析，也可以實(shí)時(shí)處理，下游可以寫入數(shù)據(jù)集市供業(yè)務(wù)使。

05 菜鳥實(shí)時(shí)數(shù)倉案例

最后分享菜鳥倉配實(shí)時(shí)數(shù)據(jù)倉庫的案例本，涉及全局設(shè)計(jì)、數(shù)據(jù)模型、數(shù)據(jù)保障等幾個(gè)方面。

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

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

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

不管是從計(jì)算成本，還是從易用性，還是從復(fù)用性，還是從一致性等等，都必須避免煙囪式的開發(fā)模式，而是以中間層的方式建設(shè)倉配實(shí)時(shí)數(shù)倉。與離線中間層基本一致，將實(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ù)倉不同的是，這里匯總層分為輕度匯總層和高度匯總層，并同時(shí)產(chǎn)出，輕度匯總層寫入 ADS，用于前端產(chǎn)品復(fù)雜的 olap 查詢場(chǎng)景，滿足自助分析和產(chǎn)出報(bào)表的需求；高度匯總層寫入 Hbase，用于前端比較簡單的 kv 查詢場(chǎng)景，提升查詢性能，比如實(shí)時(shí)大屏等。

06 美團(tuán)點(diǎn)評(píng)基于Flink的實(shí)時(shí)數(shù)倉平臺(tái)實(shí)踐

最底層是收集層，這一層負(fù)責(zé)收集用戶的實(shí)時(shí)數(shù)據(jù)，包括 Binlog、后端服務(wù)日志以及 IoT 數(shù)據(jù)，經(jīng)過日志收集團(tuán)隊(duì)和 DB 收集團(tuán)隊(duì)的處理，數(shù)據(jù)將會(huì)被收集到 Kafka 中。這些數(shù)據(jù)不只是參與實(shí)時(shí)計(jì)算，也會(huì)參與離線計(jì)算。

收集層之上是存儲(chǔ)層，這一層除了使用 Kafka 做消息通道之外，還會(huì)基于 HDFS 做狀態(tài)數(shù)據(jù)存儲(chǔ)以及基于 HBase 做維度數(shù)據(jù)的存儲(chǔ)。

存儲(chǔ)層之上是引擎層，包括 Storm 和 Flink。實(shí)時(shí)計(jì)算平臺(tái)會(huì)在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持。

在引擎層之上就是平臺(tái)層了，平臺(tái)層從數(shù)據(jù)、任務(wù)和資源三個(gè)視角去管理。

架構(gòu)的最上層是應(yīng)用層，包括了實(shí)時(shí)數(shù)倉、機(jī)器學(xué)習(xí)、數(shù)據(jù)同步以及事件驅(qū)動(dòng)應(yīng)用等。

從功能角度來看，美團(tuán)點(diǎn)評(píng)的實(shí)時(shí)計(jì)算平臺(tái)主要包括作業(yè)和資源管理兩個(gè)方面的功能。其中，作業(yè)部分包括作業(yè)配置、作業(yè)發(fā)布以及作業(yè)狀態(tài)三個(gè)方面的功能。

• 在作業(yè)配置方面，則包括作業(yè)設(shè)置、運(yùn)行時(shí)設(shè)置以及拓?fù)浣Y(jié)構(gòu)設(shè)置；
• 在作業(yè)發(fā)布方面，則包括版本管理、編譯/發(fā)布/回滾等；
• 作業(yè)狀態(tài)則包括運(yùn)行時(shí)狀態(tài)、自定義指標(biāo)和報(bào)警以及命令/運(yùn)行時(shí)日志等。

在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力。

07 實(shí)時(shí)數(shù)倉與離線數(shù)倉的對(duì)比

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

• 首先，從架構(gòu)上，實(shí)時(shí)數(shù)倉與離線數(shù)倉有比較明顯的區(qū)別，實(shí)時(shí)數(shù)倉以 Kappa 架構(gòu)為主，而離線數(shù)倉以傳統(tǒng)大數(shù)據(jù)架構(gòu)為主。Lambda 架構(gòu)可以認(rèn)為是兩者的中間態(tài)。
• 其次，從建設(shè)方法上，實(shí)時(shí)數(shù)倉和離線數(shù)倉基本還是沿用傳統(tǒng)的數(shù)倉主題建模理論，產(chǎn)出事實(shí)寬表。另外實(shí)時(shí)數(shù)倉中實(shí)時(shí)流數(shù)據(jù)的 join 有隱藏時(shí)間語義，在建設(shè)中需注意。
• 最后，從數(shù)據(jù)保障看，實(shí)時(shí)數(shù)倉因?yàn)橐ＷC實(shí)時(shí)性，所以對(duì)數(shù)據(jù)量的變化較為敏感。在大促等場(chǎng)景下需要提前做好壓測(cè)和主備保障工作，這是與離線數(shù)據(jù)的一個(gè)較為明顯的區(qū)別。

綜上，實(shí)時(shí)數(shù)倉主要解決數(shù)據(jù)時(shí)效性問題，結(jié)合機(jī)器學(xué)習(xí)框架可以處理實(shí)時(shí)推薦、實(shí)時(shí)獲取廣告投放效果等智能化業(yè)務(wù)場(chǎng)景。實(shí)時(shí)數(shù)倉的建設(shè)應(yīng)早日提上日程，未來企業(yè)對(duì)數(shù)據(jù)時(shí)效性的要求會(huì)越來越高，實(shí)時(shí)數(shù)倉會(huì)很好的解決該問題。

作者：李啟方，專注數(shù)據(jù)分析和企業(yè)數(shù)據(jù)化管理 公眾號(hào)：數(shù)據(jù)分析不是個(gè)事兒

本文由 @李啟方 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議