數據倉庫概念的提出都要追溯到上世紀了，我們認為在大數據元年之前的數倉可以稱為傳統數倉，而后隨着海量數據不斷增長，以及Hadoop生態不斷發展，主要基於Hive/HDFS的離線數倉架構可以興起並延續至今，近幾年隨着Storm/Spark（Streaming）/Flink等實時處理框架的更新迭代乃至相互取代，各廠都在着力構建自己的實時數倉，特別是近兩年，隨着Flink聲名鵲起，實時數倉更是名聲在外並且還在不斷快速發展。
目前大多企業的數據體系都是圍繞數倉的數據平台架構，特別是在着力建設實時數倉，或者在建設離線數倉與實時數倉相統一的數倉體系。本文我們精選了實時數倉建設的典型代表，包括美團點評、網易、知乎、OPPO等幾家的實時數倉架構，他們的數倉實踐肯定對我們有所借鑒或啟迪。筆者這里特別推薦參考他們的分層設計，存儲與計算引擎的選型。
本文舉的四個代表案例：
- 美團點評基於 Flink 的實時數倉平台實踐
- 網易基於Flink的嚴選實時數倉實踐
- 知乎實時數倉實踐及架構演進
- OPPO 實時數倉揭秘及離線到實時的平滑遷移
從中提煉出最精彩的內容。感謝以上文章作者的技術分享，所有內容版權歸其個人及相關社區所有，文末給出了原文鏈接。
美團點評基於Flink的實時數倉平台實踐
實時計算平台架構
下圖所示的是美團點評實時計算平台的架構。
- 最底層是收集層，這一層負責收集用戶的實時數據，包括 Binlog、后端服務日志以及 IoT 數據，經過日志收集團隊和 DB 收集團隊的處理，數據將會被收集到 Kafka 中。這些數據不只是參與實時計算，也會參與離線計算。
- 收集層之上是存儲層，這一層除了使用 Kafka 做消息通道之外，還會基於 HDFS 做狀態數據存儲以及基於 HBase 做維度數據的存儲。
- 存儲層之上是引擎層，包括 Storm 和 Flink。實時計算平台會在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持。
- 在引擎層之上就是平台層了，平台層從數據、任務和資源三個視角去管理。
- 架構的最上層是應用層，包括了實時數倉、機器學習、數據同步以及事件驅動應用等。
從功能角度來看，美團點評的實時計算平台主要包括作業和資源管理兩個方面的功能。其中，作業部分包括作業配置、作業發布以及作業狀態三個方面的功能。
- 在作業配置方面，則包括作業設置、運行時設置以及拓撲結構設置；
- 在作業發布方面，則包括版本管理、編譯/發布/回滾等；
- 作業狀態則包括運行時狀態、自定義指標和報警以及命令/運行時日志等。
在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力。
傳統數倉模型
為了更有效地組織和管理數據，數倉建設往往會進行數據分層，一般自下而上分為四層：ODS（操作數據層）、DWD（數據明細層）、DWS（匯總層）和應用層。即時查詢主要通過 Presto、Hive 和 Spark 實現。
實時數倉模型
實時數倉的分層方式一般也遵守傳統數據倉庫模型，也分為了 ODS 操作數據集、DWD 明細層和 DWS 匯總層以及應用層。但實時數倉模型的處理的方式卻和傳統數倉有所差別，如明細層和匯總層的數據一般會放在 Kafka 上，維度數據一般考慮到性能問題則會放在 HBase 或者 Tair 等 KV 存儲上，即席查詢則可以使用 Flink 完成。
准實時數倉模型
在以上兩種數倉模型之外，我們發現業務方在實踐過程中還有一種准實時數倉模型，其特點是不完全基於流去做，而是將明細層數據導入到 OLAP 存儲中，基於 OLAP 的計算能力去做匯總並進行進一步的加工。
實時數倉和傳統數倉的對比主要可以從四個方面考慮：
- 第一個是分層方式，離線數倉為了考慮到效率問題，一般會采取空間換時間的方式，層級划分會比較多；則實時數倉考慮到實時性問題，一般分層會比較少，另外也減少了中間流程出錯的可能性。
- 第二個是事實數據存儲方面，離線數倉會基於 HDFS，實時數倉則會基於消息隊列（如 Kafka）。
- 第三個是維度數據存儲，實時數倉會將數據放在 KV 存儲上面。
- 第四個是數據加工過程，離線數倉一般以 Hive、Spark 等批處理為主，而實時數倉則是基於實時計算引擎如 Storm、Flink 等，以流處理為主。
網易基於Flink的嚴選實時數倉實踐
整體架構
實時數倉整體框架依據數據的流向分為不同的層次，接入層會依據各種數據接入工具收集各個業務系統的數據，如買點的業務數據或者業務后台的並購放到消息隊列里面。消息隊列的數據既是離線數倉的原始數據，也是實時計算的原始數據，這樣可以保證實時和離線的原始數據是統一的。有了源數據，在計算層經過FLink+實時計算引擎做一些加工處理，然后落地到存儲層中不同存儲介質當中。不同的存儲介質是依據不同的應用場景來選擇。框架中還有FLink和Kafka的交互，在數據上進行一個分層設計，計算引擎從Kafka中撈取數據做一些加工然后放回Kafka。在存儲層加工好的數據會通過服務層的兩個服務：統一查詢、指標管理，統一查詢是通過業務方調取數據接口的一個服務，指標管理是對數據指標的定義和管理工作。通過服務層應用到不同的數據應用，數據應用可能是我們的正式產品或者直接的業務系統。后面會從數據的分層設計和具體的實現兩個方面介紹。
整體設計
上面是對數據的整體設計，主要參考了離線數倉的設計方案，也參考了業界同行的一些做法。將數據分為四個層次：
首先是ODS層，即操作數據層，通過數據采集工具收集各個業務源數據；DWD層，明細數據層是按主題域來划分，通過維度建模方式來組織各個業務過程的明細數據。中間會有一個DIM層，維度數據層主要做一些查詢和關聯的操作。最上層是DM層，通過DWD層數據做一些指標加工，主要面向一些分析和應用匯總的指標或者是做多維分析的明細數據。
技術實現
然后介紹下技術實現方面的考量，主要分為計算和存儲。對於計算方面，有很多實時計算引擎，有Flink、Storm、Spark Streaming，Flink相對於Storm的優勢就是支持SQL，相對於Spark Streaming又有一個相對好的性能表現。同時Flink在支持好的應用和性能方面還有比較好的語義支持和比較好的容錯機制，因此構建實時數倉Flink是一個比較好的實時計算引擎選擇。
技術實現中Flink的具體作用：
Flink作為實時的計算引擎，不同的數據層（ods->dwd->dm）之間，不同的存儲引擎（kafka->db）都是通過Flink job串聯的，相關的etl和關聯、聚合等操作也是在Flink中完成。
對於存儲層會依據不同的數據層的特點選擇不同的存儲介質，ODS層和DWD層都是存儲的一些實時數據，選擇的是Kafka進行存儲，在DWD層會關聯一些歷史明細數據，會將其放到Redis里面。在DIM層主要做一些高並發維度的查詢關聯，一般將其存放在HBase里面，對於DIM層比價復雜，需要綜合考慮對於數據落地的要求以及具體的查詢引擎來選擇不同的存儲方式。對於常見的指標匯總模型直接放在MySQL里面，維度比較多的、寫入更新比較大的模型會放在HBase里面，還有明細數據需要做一些多維分析或者關聯會將其存儲在Greenplum里面，還有一種是維度比較多、需要做排序、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis里面。
知乎實時數倉架構實踐與演進
本文主要講述知乎的實時數倉實踐以及架構的演進，這包括以下幾個方面：
- 實時數倉 1.0 版本，主題：ETL 邏輯實時化，技術方案：Spark Streaming。
- 實時數倉 2.0 版本，主題：數據分層，指標計算實時化，技術方案：Flink Streaming。
- 實時數倉未來展望：Streaming SQL 平台化，元信息管理系統化，結果驗收自動化。
實時數倉 1.0
第一部分是數據采集，由三端 SDK 采集數據並通過 Log Collector Server 發送到 Kafka。第二部分是數據 ETL，選擇了 Spark Streaming 作為實時數據的處理框架，主要完成對原始數據的清洗和加工並分實時和離線導入 Druid。第三部分是數據可視化，由 Druid 負責計算指標並通過 Web Server 配合前端完成數據可視化。
1.0 版本的實時數倉有以下幾個不足：
- 所有的流量數據存放在同一個 Kafka Topic 中，如果下游每個業務線都要消費，這會導致全量數據被消費多次，Kafka 出流量太高無法滿足該需求。
- 所有的指標計算全部由 Druid 承擔，Druid 同時兼顧實時數據源和離線數據源的查詢，隨着數據量的暴漲 Druid 穩定性急劇下降，這導致各個業務的核心報表不能穩定產出。
- 由於每個業務使用同一個流量數據源配置報表，導致查詢效率低下，同時無法對業務做數據隔離和成本計算。
隨着數據量的暴漲，Druid 中的流量數據源經常查詢超時同時各業務消費實時數據的需求也開始增多，如果繼續沿用實時數倉 1.0 架構，需要付出大量的額外成本。於是，在實時數倉 1.0 的基礎上，我們建立起了實時數倉 2.0，梳理出了新的架構設計並開始着手建立實時數倉體系，新的架構如下圖所示。
實時數倉 2.0
相比實時數倉 1.0 以 Spark Streaming 作為主要實現技術，在實時數倉 2.0 中，我們將 Flink 作為指標匯總層的主要計算框架。Flink 相比 Spark Streaming 有更明顯的優勢，主要體現在：低延遲、Exactly-once 語義支持、Streaming SQL 支持、狀態管理、豐富的時間類型和窗口計算、CEP 支持等。
從實時數倉 1.0 到 2.0，不管是數據架構還是技術方案，我們在深度和廣度上都有了更多的積累。隨着公司業務的快速發展以及新技術的誕生，實時數倉也會不斷的迭代優化。短期可預見的我們會從以下方面進一步提升實時數倉的服務能力：
- Streaming SQL 平台化。目前 Streaming SQL 任務是以代碼開發 maven 打包的方式提交任務，開發成本高，后期隨着 Streaming SQL 平台的上線，實時數倉的開發方式也會由 Jar 包轉變為 SQL 文件。
- 實時數據元信息管理系統化。對數倉元信息的管理可以大幅度降低使用數據的成本，離線數倉的元信息管理已經基本完善，實時數倉的元信息管理才剛剛開始。
- 實時數倉結果驗收自動化。對實時結果的驗收只能借助與離線數據指標對比的方式，以 Hive 和 Kafka 數據源為例，分別執行 Hive SQL 和 Flink SQL，統計結果並對比是否一致實現實時結果驗收的自動化。
OPPO 實時數倉揭秘：從頂層設計實現離線與實時的平滑遷移
以數倉為中心的數據架構
在過去幾年的時間里面，OPPO 內部的這套以數倉為核心的數據架構已經逐漸開始成熟了。
離線到實時數倉的平滑遷移
OPPO 希望所設計出來的實時數倉能夠實現從離線到實時的平滑遷移，之前大家如何使用和開發離線數倉，如今到了實時數倉也希望大家如何開發和使用。通常而言，當設計一款產品或者平台的時候，可以划分為兩層，即底層實現和上層抽象。對於底層實現而言，可能會有不同的技術，從 Hive 到 Flink，從 HDFS 到 Kafka。而在上層抽象而言，則希望對於用戶而言是透明的。
實時數倉的層級划分
如下圖所示的是 OPPO 實時數倉的分層結構，從接入層過來之后，所有的數據都是會用 Kafka 來支撐的，數據接入進來放到 Kafka 里面實現 ODS 層，然后使用 Flink SQL 實現數據的清洗，然后就變到了 DWD 層，中間使用 Flink SQL 實現一些聚合操作，就到了 ADS 層，最后根據不同的業務使用場景再導入到ES等系統中去。當然，其中的一些維度層位於 MySQL 或者 Hive 中。
SQL一統天下的數據架構
對於數倉領域的近期發展而言，其中很有意思的一點是：無論是離線還是實時的數據架構，都慢慢演進成了 SQL 一統天下的架構。無論是離線還是實時是數據倉庫，無論是接入，查詢、開發還是業務系統都是在上面寫 SQL 的方式。
寫在最后的話
總結下，實時數倉主要有兩個要點。首先是分層設計上，一般也是參考離線數倉的設計，通常會分為ODS操作數據層、DWD明細層、DWS匯總層以及ADS應用層，可能還會分出一層DIM維度數據層。另外分層設計上也有不同的思路，比如可以將DWS和ADS歸為DM數據集市層，網易嚴選就是這樣設計的。
技術選型上，離線數倉一般依托HDFS或Hive構建，選擇MR或Spark計算引擎；實時數倉存儲層更多是選擇Kafka等消息引擎，通常明細層和匯總層都放在Kafka，計算層則多是選擇Flink/Spark Streaming/Storm，這方面Flink更有優勢，社區也更傾向於選擇Flink。大概總結這么多，筆者才疏學淺，有不同看法的同學歡迎留言討論。
參考：
[3] 知乎實時數倉實踐及架構演進：https://zhuanlan.zhihu.com/p/56807637
[4] OPPO 實時數倉揭秘：從頂層設計實現離線與實時的平滑遷移
本文分享自微信公眾號 - 大數據技術架構（bigdata-tech），作者：社區精選
原文出處及轉載信息見文內詳細說明，如有侵權，請聯系 yunjia_community@tencent.com 刪除。
原始發表時間：2020-04-15
本文參與騰訊雲自媒體分享計划，歡迎正在閱讀的你也加入，一起分享。
相關文章
-
-
B站實時平台的架構與實踐
本文來自B站實時平台負責人鄭志升在 Flink Forward Asia 2019 上的技術分享，重點介紹了B站基於 Apache Flink 的流式計算平台建...
-
Hudi原理 | Apache Hudi 典型應用場景介紹
將數據從外部源如事件日志、數據庫提取到Hadoop數據湖中是一個很常見的問題。在大多數Hadoop部署中，一般使用混合提取工具並以零散的方式解決該問題，盡管這些...
-
美團點評基於 Flink 的實時數倉平台實踐
摘要：數據倉庫的建設是“數據智能”必不可少的一環，也是大規模數據應用中必然面臨的挑戰，而 Flink 實時數倉在數據鏈路中扮演着極為重要的角色。本文中，美團點評...
-
-
黑客風雲錄：眼前的黑不是黑 你說的白是什么白
如果把互聯網比作江湖，那么黑客就是江湖中的“風雲兒女”，攻守交錯，正邪不兩立，吃瓜群眾多以帽子的顏色來給他們划分善惡與派系，比如，“黑帽子黑客”、“白帽子黑客”...
-
[linux][net]網卡多隊列對vm exit的影響
前言： 虛擬機性能調試的時候，遇到了external irq對vm造成了exit。 分析： 1，網卡多隊列 ? enp130s0f0是Intel Corpor...
-
Python自動回復微信好友新年祝福
馬上就要過年了，好多小伙伴都已經順利到家，准備過新年，公眾號也將暫停更新，今天這篇文章是年前最后一篇原創文章。在這提前祝大家：新年快樂。公眾號會在除夕夜給大家發...
-
-
我來說兩句