數(shù)據(jù)倉庫概念的提出都要追溯到上世紀了，我們認為在大數(shù)據(jù)元年之前的數(shù)倉可以稱為傳統(tǒng)數(shù)倉，而后隨著海量數(shù)據(jù)不斷增長，以及Hadoop生態(tài)不斷發(fā)展，主要基于Hive/HDFS的離線數(shù)倉架構(gòu)可以興起并延續(xù)至今，近幾年隨著Storm/Spark（Streaming）/Flink等實時處理框架的更新迭代乃至相互取代，各廠都在著力構(gòu)建自己的實時數(shù)倉，特別是近兩年，隨著Flink聲名鵲起，實時數(shù)倉更是名聲在外并且還在不斷快速發(fā)展。
目前大多企業(yè)的數(shù)據(jù)體系都是圍繞數(shù)倉的數(shù)據(jù)平臺架構(gòu)，特別是在著力建設(shè)實時數(shù)倉，或者在建設(shè)離線數(shù)倉與實時數(shù)倉相統(tǒng)一的數(shù)倉體系。本文我們精選了實時數(shù)倉建設(shè)的典型代表，包括美團點評、網(wǎng)易、知乎、OPPO等幾家的實時數(shù)倉架構(gòu)，他們的數(shù)倉實踐肯定對我們有所借鑒或啟迪。筆者這里特別推薦參考他們的分層設(shè)計，存儲與計算引擎的選型。
本文舉的四個代表案例：
美團點評基于 Flink 的實時數(shù)倉平臺實踐
網(wǎng)易基于Flink的嚴選實時數(shù)倉實踐
知乎實時數(shù)倉實踐及架構(gòu)演進
OPPO 實時數(shù)倉揭秘及離線到實時的平滑遷移
從中提煉出最精彩的內(nèi)容。感謝以上文章作者的技術(shù)分享，所有內(nèi)容版權(quán)歸其個人及相關(guān)社區(qū)所有，文末給出了原文鏈接。
美團點評基于Flink的實時數(shù)倉平臺實踐
實時計算平臺架構(gòu)
下圖所示的是美團點評實時計算平臺的架構(gòu)。
最底層是收集層，這一層負責(zé)收集用戶的實時數(shù)據(jù)，包括 Binlog、后端服務(wù)日志以及 IoT 數(shù)據(jù)，經(jīng)過日志收集團隊和 DB 收集團隊的處理，數(shù)據(jù)將會被收集到 Kafka 中。這些數(shù)據(jù)不只是參與實時計算，也會參與離線計算。
收集層之上是存儲層，這一層除了使用 Kafka 做消息通道之外，還會基于 HDFS 做狀態(tài)數(shù)據(jù)存儲以及基于 HBase 做維度數(shù)據(jù)的存儲。
存儲層之上是引擎層，包括 Storm 和 Flink。實時計算平臺會在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持。
在引擎層之上就是平臺層了，平臺層從數(shù)據(jù)、任務(wù)和資源三個視角去管理。
架構(gòu)的最上層是應(yīng)用層，包括了實時數(shù)倉、機器學(xué)習(xí)、數(shù)據(jù)同步以及事件驅(qū)動應(yīng)用等。
從功能角度來看，美團點評的實時計算平臺主要包括作業(yè)和資源管理兩個方面的功能。其中，作業(yè)部分包括作業(yè)配置、作業(yè)發(fā)布以及作業(yè)狀態(tài)三個方面的功能。
在作業(yè)配置方面，則包括作業(yè)設(shè)置、運行時設(shè)置以及拓撲結(jié)構(gòu)設(shè)置；
在作業(yè)發(fā)布方面，則包括版本管理、編譯/發(fā)布/回滾等；
作業(yè)狀態(tài)則包括運行時狀態(tài)、自定義指標和報警以及命令/運行時日志等。
在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力。傳統(tǒng)數(shù)倉模型為了更有效地組織和管理數(shù)據(jù)，數(shù)倉建設(shè)往往會進行數(shù)據(jù)分層，一般自下而上分為四層：ODS（操作數(shù)據(jù)層）、DWD（數(shù)據(jù)明細層）、DWS（匯總層）和應(yīng)用層。即時查詢主要通過 Presto、Hive 和 Spark 實現(xiàn)。
實時數(shù)倉模型
實時數(shù)倉的分層方式一般也遵守傳統(tǒng)數(shù)據(jù)倉庫模型，也分為了 ODS 操作數(shù)據(jù)集、DWD 明細層和 DWS 匯總層以及應(yīng)用層。但實時數(shù)倉模型的處理的方式卻和傳統(tǒng)數(shù)倉有所差別，如明細層和匯總層的數(shù)據(jù)一般會放在 Kafka 上，維度數(shù)據(jù)一般考慮到性能問題則會放在 HBase 或者 Tair 等 KV 存儲上，即席查詢則可以使用 Flink 完成。
準實時數(shù)倉模型
在以上兩種數(shù)倉模型之外，我們發(fā)現(xiàn)業(yè)務(wù)方在實踐過程中還有一種準實時數(shù)倉模型，其特點是不完全基于流去做，而是將明細層數(shù)據(jù)導(dǎo)入到 OLAP 存儲中，基于 OLAP 的計算能力去做匯總并進行進一步的加工。
實時數(shù)倉和傳統(tǒng)數(shù)倉的對比主要可以從四個方面考慮：
第一個是分層方式，離線數(shù)倉為了考慮到效率問題，一般會采取空間換時間的方式，層級劃分會比較多；則實時數(shù)倉考慮到實時性問題，一般分層會比較少，另外也減少了中間流程出錯的可能性。
第二個是事實數(shù)據(jù)存儲方面，離線數(shù)倉會基于 HDFS，實時數(shù)倉則會基于消息隊列（如 Kafka）。
第三個是維度數(shù)據(jù)存儲，實時數(shù)倉會將數(shù)據(jù)放在 KV 存儲上面。
第四個是數(shù)據(jù)加工過程，離線數(shù)倉一般以 Hive、Spark 等批處理為主，而實時數(shù)倉則是基于實時計算引擎如 Storm、Flink 等，以流處理為主。
網(wǎng)易基于Flink的嚴選實時數(shù)倉實踐
整體架構(gòu)
實時數(shù)倉整體框架依據(jù)數(shù)據(jù)的流向分為不同的層次，接入層會依據(jù)各種數(shù)據(jù)接入工具收集各個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，如買點的業(yè)務(wù)數(shù)據(jù)或者業(yè)務(wù)后臺的并購放到消息隊列里面。消息隊列的數(shù)據(jù)既是離線數(shù)倉的原始數(shù)據(jù)，也是實時計算的原始數(shù)據(jù)，這樣可以保證實時和離線的原始數(shù)據(jù)是統(tǒng)一的。有了源數(shù)據(jù)，在計算層經(jīng)過FLink+實時計算引擎做一些加工處理，然后落地到存儲層中不同存儲介質(zhì)當(dāng)中。不同的存儲介質(zhì)是依據(jù)不同的應(yīng)用場景來選擇?？蚣苤羞€有FLink和Kafka的交互，在數(shù)據(jù)上進行一個分層設(shè)計，計算引擎從Kafka中撈取數(shù)據(jù)做一些加工然后放回Kafka。在存儲層加工好的數(shù)據(jù)會通過服務(wù)層的兩個服務(wù)：統(tǒng)一查詢、指標管理，統(tǒng)一查詢是通過業(yè)務(wù)方調(diào)取數(shù)據(jù)接口的一個服務(wù)，指標管理是對數(shù)據(jù)指標的定義和管理工作。通過服務(wù)層應(yīng)用到不同的數(shù)據(jù)應(yīng)用，數(shù)據(jù)應(yīng)用可能是我們的正式產(chǎn)品或者直接的業(yè)務(wù)系統(tǒng)。后面會從數(shù)據(jù)的分層設(shè)計和具體的實現(xiàn)兩個方面介紹。
整體設(shè)計
上面是對數(shù)據(jù)的整體設(shè)計，主要參考了離線數(shù)倉的設(shè)計方案，也參考了業(yè)界同行的一些做法。將數(shù)據(jù)分為四個層次：
首先是ODS層，即操作數(shù)據(jù)層，通過數(shù)據(jù)采集工具收集各個業(yè)務(wù)源數(shù)據(jù)；DWD層，明細數(shù)據(jù)層是按主題域來劃分，通過維度建模方式來組織各個業(yè)務(wù)過程的明細數(shù)據(jù)。中間會有一個DIM層，維度數(shù)據(jù)層主要做一些查詢和關(guān)聯(lián)的操作。最上層是DM層，通過DWD層數(shù)據(jù)做一些指標加工，主要面向一些分析和應(yīng)用匯總的指標或者是做多維分析的明細數(shù)據(jù)。
技術(shù)實現(xiàn)
然后介紹下技術(shù)實現(xiàn)方面的考量，主要分為計算和存儲。對于計算方面，有很多實時計算引擎，有Flink、Storm、Spark Streaming，F(xiàn)link相對于Storm的優(yōu)勢就是支持SQL，相對于Spark Streaming又有一個相對好的性能表現(xiàn)。同時Flink在支持好的應(yīng)用和性能方面還有比較好的語義支持和比較好的容錯機制，因此構(gòu)建實時數(shù)倉Flink是一個比較好的實時計算引擎選擇。技術(shù)實現(xiàn)中
Flink的具體作用：
Flink作為實時的計算引擎，不同的數(shù)據(jù)層（ods->dwd->dm）之間，不同的存儲引擎（kafka->db）都是通過Flink job串聯(lián)的，相關(guān)的etl和關(guān)聯(lián)、聚合等操作也是在Flink中完成。
對于存儲層會依據(jù)不同的數(shù)據(jù)層的特點選擇不同的存儲介質(zhì)，ODS層和DWD層都是存儲的一些實時數(shù)據(jù)，選擇的是Kafka進行存儲，在DWD層會關(guān)聯(lián)一些歷史明細數(shù)據(jù)，會將其放到Redis里面。在DIM層主要做一些高并發(fā)維度的查詢關(guān)聯(lián)，一般將其存放在HBase里面，對于DIM層比價復(fù)雜，需要綜合考慮對于數(shù)據(jù)落地的要求以及具體的查詢引擎來選擇不同的存儲方式。對于常見的指標匯總模型直接放在MySQL里面，維度比較多的、寫入更新比較大的模型會放在HBase里面，還有明細數(shù)據(jù)需要做一些多維分析或者關(guān)聯(lián)會將其存儲在Greenplum里面，還有一種是維度比較多、需要做排序、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis里面。
知乎實時數(shù)倉架構(gòu)實踐與演進
本文主要講述知乎的實時數(shù)倉實踐以及架構(gòu)的演進，這包括以下幾個方面：
實時數(shù)倉 1.0 版本，主題：ETL 邏輯實時化，技術(shù)方案：Spark Streaming。
實時數(shù)倉 2.0 版本，主題：數(shù)據(jù)分層，指標計算實時化，技術(shù)方案：Flink Streaming。
實時數(shù)倉未來展望：Streaming SQL 平臺化，元信息管理系統(tǒng)化，結(jié)果驗收自動化。
上圖：實時數(shù)倉 1.0
第一部分是數(shù)據(jù)采集，由三端 SDK 采集數(shù)據(jù)并通過 Log Collector Server 發(fā)送到 Kafka。第二部分是數(shù)據(jù) ETL，選擇了 Spark Streaming 作為實時數(shù)據(jù)的處理框架，主要完成對原始數(shù)據(jù)的清洗和加工并分實時和離線導(dǎo)入 Druid。第三部分是數(shù)據(jù)可視化，由 Druid 負責(zé)計算指標并通過 Web Server 配合前端完成數(shù)據(jù)可視化。
1.0 版本的實時數(shù)倉有以下幾個不足：
所有的流量數(shù)據(jù)存放在同一個 Kafka Topic 中，如果下游每個業(yè)務(wù)線都要消費，這會導(dǎo)致全量數(shù)據(jù)被消費多次，Kafka 出流量太高無法滿足該需求。
所有的指標計算全部由 Druid 承擔(dān)，Druid 同時兼顧實時數(shù)據(jù)源和離線數(shù)據(jù)源的查詢，隨著數(shù)據(jù)量的暴漲 Druid 穩(wěn)定性急劇下降，這導(dǎo)致各個業(yè)務(wù)的核心報表不能穩(wěn)定產(chǎn)出。
由于每個業(yè)務(wù)使用同一個流量數(shù)據(jù)源配置報表，導(dǎo)致查詢效率低下，同時無法對業(yè)務(wù)做數(shù)據(jù)隔離和成本計算。
隨著數(shù)據(jù)量的暴漲，Druid 中的流量數(shù)據(jù)源經(jīng)常查詢超時同時各業(yè)務(wù)消費實時數(shù)據(jù)的需求也開始增多，如果繼續(xù)沿用實時數(shù)倉 1.0 架構(gòu)，需要付出大量的額外成本。于是，在實時數(shù)倉 1.0 的基礎(chǔ)上，我們建立起了實時數(shù)倉 2.0，梳理出了新的架構(gòu)設(shè)計并開始著手建立實時數(shù)倉體系，新的架構(gòu)如下圖所示。
上圖：實時數(shù)倉 2.0
相比實時數(shù)倉 1.0 以 Spark Streaming 作為主要實現(xiàn)技術(shù)，在實時數(shù)倉 2.0 中，我們將 Flink 作為指標匯總層的主要計算框架。Flink 相比 Spark Streaming 有更明顯的優(yōu)勢，主要體現(xiàn)在：低延遲、Exactly-once 語義支持、Streaming SQL 支持、狀態(tài)管理、豐富的時間類型和窗口計算、CEP 支持等。從實時數(shù)倉 1.0 到 2.0，不管是數(shù)據(jù)架構(gòu)還是技術(shù)方案，我們在深度和廣度上都有了更多的積累。隨著公司業(yè)務(wù)的快速發(fā)展以及新技術(shù)的誕生，實時數(shù)倉也會不斷的迭代優(yōu)化。短期可預(yù)見的我們會從以下方面進一步提升實時數(shù)倉的服務(wù)能力：
Streaming SQL 平臺化。目前 Streaming SQL 任務(wù)是以代碼開發(fā) maven 打包的方式提交任務(wù)，開發(fā)成本高，后期隨著 Streaming SQL 平臺的上線，實時數(shù)倉的開發(fā)方式也會由 Jar 包轉(zhuǎn)變?yōu)?SQL 文件。
實時數(shù)據(jù)元信息管理系統(tǒng)化。對數(shù)倉元信息的管理可以大幅度降低使用數(shù)據(jù)的成本，離線數(shù)倉的元信息管理已經(jīng)基本完善，實時數(shù)倉的元信息管理才剛剛開始。
實時數(shù)倉結(jié)果驗收自動化。對實時結(jié)果的驗收只能借助與離線數(shù)據(jù)指標對比的方式，以 Hive 和 Kafka 數(shù)據(jù)源為例，分別執(zhí)行 Hive SQL 和 Flink SQL，統(tǒng)計結(jié)果并對比是否一致實現(xiàn)實時結(jié)果驗收的自動化。
OPPO 實時數(shù)倉揭秘：從頂層設(shè)計實現(xiàn)離線與實時的平滑遷移
以數(shù)倉為中心的數(shù)據(jù)架構(gòu)
在過去幾年的時間里面，OPPO 內(nèi)部的這套以數(shù)倉為核心的數(shù)據(jù)架構(gòu)已經(jīng)逐漸開始成熟了。
離線到實時數(shù)倉的平滑遷移
OPPO 希望所設(shè)計出來的實時數(shù)倉能夠?qū)崿F(xiàn)從離線到實時的平滑遷移，之前大家如何使用和開發(fā)離線數(shù)倉，如今到了實時數(shù)倉也希望大家如何開發(fā)和使用。通常而言，當(dāng)設(shè)計一款產(chǎn)品或者平臺的時候，可以劃分為兩層，即底層實現(xiàn)和上層抽象。對于底層實現(xiàn)而言，可能會有不同的技術(shù)，從 Hive 到 Flink，從 HDFS 到 Kafka。而在上層抽象而言，則希望對于用戶而言是透明的。
實時數(shù)倉的層級劃分
如下圖所示的是 OPPO 實時數(shù)倉的分層結(jié)構(gòu)，從接入層過來之后，所有的數(shù)據(jù)都是會用 Kafka 來支撐的，數(shù)據(jù)接入進來放到 Kafka 里面實現(xiàn) ODS 層，然后使用 Flink SQL 實現(xiàn)數(shù)據(jù)的清洗，然后就變到了 DWD 層，中間使用 Flink SQL 實現(xiàn)一些聚合操作，就到了 ADS 層，最后根據(jù)不同的業(yè)務(wù)使用場景再導(dǎo)入到ES等系統(tǒng)中去。當(dāng)然，其中的一些維度層位于 MySQL 或者 Hive 中。
SQL一統(tǒng)天下的數(shù)據(jù)架構(gòu)
對于數(shù)倉領(lǐng)域的近期發(fā)展而言，其中很有意思的一點是：無論是離線還是實時的數(shù)據(jù)架構(gòu)，都慢慢演進成了 SQL 一統(tǒng)天下的架構(gòu)。無論是離線還是實時是數(shù)據(jù)倉庫，無論是接入，查詢、開發(fā)還是業(yè)務(wù)系統(tǒng)都是在上面寫 SQL 的方式。
寫在最后的話
總結(jié)下，實時數(shù)倉主要有兩個要點。首先是分層設(shè)計上，一般也是參考離線數(shù)倉的設(shè)計，通常會分為ODS操作數(shù)據(jù)層、DWD明細層、DWS匯總層以及ADS應(yīng)用層，可能還會分出一層DIM維度數(shù)據(jù)層。另外分層設(shè)計上也有不同的思路，比如可以將DWS和ADS歸為DM數(shù)據(jù)集市層，網(wǎng)易嚴選就是這樣設(shè)計的。
技術(shù)選型上，離線數(shù)倉一般依托HDFS或Hive構(gòu)建，選擇MR或Spark計算引擎；實時數(shù)倉存儲層更多是選擇Kafka等消息引擎，通常明細層和匯總層都放在Kafka，計算層則多是選擇Flink/Spark Streaming/Storm，這方面Flink更有優(yōu)勢，社區(qū)也更傾向于選擇Flink。大概總結(jié)這么多，筆者才疏學(xué)淺，有不同看法的同學(xué)歡迎留言討論。
作者：大數(shù)據(jù)技術(shù)架構(gòu)
鏈接：http://www.itdecent.cn/p/5194736aee50
來源：簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
關(guān)注我的公眾號，后臺回復(fù)【JAVAPDF】獲取200頁面試題！
5萬人關(guān)注的大數(shù)據(jù)成神之路，不來了解一下嗎？
5萬人關(guān)注的大數(shù)據(jù)成神之路，真的不來了解一下嗎？
5萬人關(guān)注的大數(shù)據(jù)成神之路，確定真的不來了解一下嗎？
歡迎您關(guān)注《大數(shù)據(jù)成神之路》
[圖片上傳失敗...(image-437cab-1593172867584)]
