前言
今年有個現象，實時數倉建設突然就被大家所關注。我個人在公衆號也寫過和轉載過幾篇關於實時數據倉庫的文章和方案。
但是對於實時數倉的狂熱追求大可不必。
首先，在技術上幾乎沒有難點，基於強大的開源中間件實現實時數據倉庫的需求已經變得沒有那麼困難。其次，實時數倉的建設一定是伴隨着業務的發展而發展，武斷的認爲Kappa架構一定是最好的實時數倉架構是不對的。實際情況中隨着業務的發展數倉的架構變得沒有那麼非此即彼。
在整個實時數倉的建設中，OLAP數據庫的選型直接制約實時數倉的可用性和功能性。本文從業內幾個典型的數倉建設和發展情況入手，從架構、技術選型和優缺點分別給大家分析現在市場上的開源OLAP引擎，旨在方便大家技術選型過程中能夠根據實際業務進行選擇。
管中窺豹-菜鳥/知乎/美團/網易嚴選實時數倉建設
爲什麼要構建實時數據倉庫
傳統的離線數據倉庫將業務數據集中進行存儲後，以固定的計算邏輯定時進行ETL和其它建模後產出報表等應用。離線數據倉庫主要是構建T+1的離線數據，通過定時任務每天拉取增量數據，然後創建各個業務相關的主題維度數據，對外提供T+1的數據查詢接口。計算和數據的實時性均較差，業務人員無法根據自己的即時性需要獲取幾分鐘之前的實時數據。數據本身的價值隨着時間的流逝會逐步減弱，因此數據發生後必須儘快的達到用戶的手中，實時數倉的構建需求也應運而生。
總之就是一句話：時效性的要求。
阿里菜鳥的實時數倉設計
菜鳥的實時數倉整體設計如右圖，基於業務系統的數據，數據模型是傳統的分層彙總設計（明細/輕度彙總/高度彙總）；計算引擎，選擇的是阿里內部的Blink；數據訪問用天工接入(天工是一個連接多種數據源的工具，目的是屏蔽大量的對各種數據庫的直連)；數據應用對應的是菜鳥的各個業務。
菜鳥的實時數倉的架構設計是一個很典型很經得起考驗的設計。實時數據接入部分通過消息中間件(開源大數據領域非Kafka莫屬，Pulsar是後起之秀)，Hbase作爲高度彙總的K-V查詢輔助。
那麼大量的對業務的直接支撐在哪裏？在這裏：ADS。
ADS（後更名爲ADB，加入新特性）是阿里巴巴自主研發的海量數據實時高併發在線分析（Realtime OLAP）雲計算數據庫。(https://help.aliyun.com/document_detail/93838.html)
經典的實時數據清洗場景
經典的實時數倉場景
在ADB的官方文檔中給出了ADB的能力：
快
ADB採用MPP+DAG融合引擎，採用行列混存技術、自動索引等技術，可以快速擴容至數千節點。
靈活
隨意調整節點數量和動態升降配實例規格。
易用
全面兼容MySQL協議和SQL
超大規模
全分佈式結構，無任何單點設計，方便橫向擴展增加SQL處理併發。
高併發寫入
小規模的10萬TPS寫入能力，通過橫向擴容節點提升至200萬+TPS的寫入能力。實時寫入數據後，約1秒左右即可查詢分析。單個表最大支持2PB數據，十萬億記錄。
知乎的實時數倉設計
知乎的實時數倉實踐以及架構的演進分爲三個階段：
- 實時數倉 1.0 版本，主題： ETL 邏輯實時化，技術方案：Spark Streaming
- 實時數倉 2.0 版本，主題：數據分層，指標計算實時化，技術方案：Flink Streaming
- 實時數倉未來展望：Streaming SQL 平臺化，元信息管理系統化，結果驗收自動化
實時數倉 1.0 版本
實時數倉 2.0 版本
在技術架構上，增加了指標彙總層，指標彙總層是由明細層或者明細彙總層通過聚合計算得到，這一層產出了絕大部分的實時數倉指標，這也是與實時數倉 1.0 最大的區別。
技術選型上，知乎根據不同業務場景選擇了HBase 和 Redis 作爲實時指標的存儲引擎，在OLAP選型上，知乎選擇了Druid。
知乎實時多維分析平臺架構
Druid 整體架構
Druid是一個高效的數據查詢系統，主要解決的是對於大量的基於時序的數據進行聚合查詢。數據可以實時攝入，進入到Druid後立即可查，同時數據是幾乎是不可變。通常是基於時序的事實事件，事實發生後進入Druid，外部系統就可以對該事實進行查詢。
Druid採用的架構:
- shared-nothing架構與lambda架構
Druid設計的三個原則:
- 快速查詢：部分數據聚合（Partial Aggregate） + 內存化（In-Memory） + 索引（Index）
- 水平拓展能力：分佈式數據（Distributed data）+並行化查詢（Parallelizable Query）
- 實時分析：Immutable Past , Append-Only Future
如果你對Druid不瞭解，請參考這裏：https://zhuanlan.zhihu.com/p/35146892
美團的實時數倉設計
美團實時數倉數據分層架構
美團的技術方案由以下四層構成：
- ODS 層：Binlog 和流量日誌以及各業務實時隊列。
- 數據明細層：業務領域整合提取事實數據，離線全量和實時變化數據構建實時維度數據。
- 數據彙總層：使用寬表模型對明細數據補充維度數據，對共性指標進行彙總。
- App 層：爲了具體需求而構建的應用層，通過 RPC 框架對外提供服務。
根據不同業務場景，實時數倉各個模型層次使用的存儲方案和OLAP引擎如下：
數據明細層 對於維度數據部分場景下關聯的頻率可達 10w+ TPS，我們選擇 Cellar（美團內部分佈式K-V存儲系統，類似Redis） 作爲存儲，封裝維度服務爲實時數倉提供維度數據。
數據彙總層 對於通用的彙總指標，需要進行歷史數據關聯的數據，採用和維度數據一樣的方案通過 Cellar 作爲存儲，用服務的方式進行關聯操作。
數據應用層 應用層設計相對複雜，再對比了幾種不同存儲方案後。我們制定了以數據讀寫頻率 1000 QPS 爲分界的判斷依據。對於讀寫平均頻率高於 1000 QPS 但查詢不太複雜的實時應用，比如商戶實時的經營數據。採用 Cellar 爲存儲，提供實時數據服務。對於一些查詢複雜的和需要明細列表的應用，使用 Elasticsearch 作爲存儲則更爲合適。而一些查詢頻率低，比如一些內部運營的數據。 Druid 通過實時處理消息構建索引，並通過預聚合可以快速的提供實時數據 OLAP 分析功能。對於一些歷史版本的數據產品進行實時化改造時，也可以使用 MySQL 存儲便於產品迭代。
總之，在OLAP選型上同樣以Druid爲主。
網易嚴選的實時數倉設計
網易嚴選的實時數倉整體框架依據數據的流向分爲不同的層次，接入層會依據各種數據接入工具 收集各個業務系統的數據。消息隊列的數據既是離線數倉的原始數據，也是實時計算的原始數據，這樣可以保證實時和離線的原始數據是統一的。 在計算層經過 Flink+實時計算引擎做一些加工處理，然後落地到存儲層中不同存儲介質當中。不同的存儲介質是依據不同的應用場景來選擇。框架中還有Flink和Kafka的交互，在數據上進行一個分層設計，計算引擎從Kafka中撈取數據做一些加工然後放回Kafka。在存儲層加工好的數據會通過服務層的兩個服務：統一查詢、指標管理，統一查詢是通過業務方調取數據接口的一個服務，指標管理是對數據指標的定義和管理工作。通過服務層應用到不同的數據應用，數據應用可能是我們的正式產品或者直接的業務系統。
基於以上的設計，技術選型如下：
對於存儲層會依據不同的數據層的特點選擇不同的存儲介質，ODS層和DWD層都是存儲的一些實時數據，選擇的是Kafka進行存儲，在DWD層會關聯一些歷史明細數據，會將其放到 Redis 裏面。在DIM層主要做一些高併發維度的查詢關聯，一般將其存放在HBase裏面，對於DIM層比價複雜，需要綜合考慮對於數據落地的要求以及具體的查詢引擎來選擇不同的存儲方式。對於常見的指標彙總模型直接放在 MySQL 裏面，維度比較多的、寫入更新比較大的模型會放在HBase裏面，還有明細數據需要做一些多維分析或者關聯會將其存儲在Greenplum裏面，還有一種是維度比較多、需要做排序、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis裏面。
網易嚴選選擇了GreenPulm、Hbase、Redis和MySQL作爲數據的計算和透出層。
GreenPulm的技術特點如下：
- 支持海量數據存儲和處理
- 支持Just In Time BI：通過準實時、實時的數據加載方式，實現數據倉庫的實時更新，進而實現動態數據倉庫（ADW），基於動態數據倉庫，業務用戶能對當前業務數據進行BI實時分析（Just In Time BI）
- 支持主流的sql語法，使用起來十分方便，學習成本低
- 擴展性好，支持多語言的自定義函數和自定義類型等
- 提供了大量的維護工具，使用維護起來很方便
- 支持線性擴展：採用MPP並行處理架構。在MPP結構中增加節點就可以線性提供系統的存儲容量和處理能力
- 較好的併發支持及高可用性支持除了提供硬件級的Raid技術外，還提供數據庫層Mirror機制保護，提供Master/Stand by機制進行主節點容錯，當主節點發生錯誤時，可以切換到Stand by節點繼續服務
- 支持MapReduce：一種大規模數據分析技術
- 數據庫內部壓縮
如果你對GreenPulm不熟悉可以參考這裏：
https://www.cnblogs.com/wujin/p/6781264.html
總結
我們通過以上的分析可以看出，在整個實時數倉的建設中，業界已經有了成熟的方案。整體架構設計通過分層設計爲OLAP查詢分擔壓力，讓出計算空間，複雜的計算統一在實時計算層做，避免給OLAP查詢帶來過大的壓力。彙總計算教給OLAP數據庫進行。我們可以這麼說，在整個架構中實時計算一般是Spark+Flink配合，消息隊列Kafka一家獨大，整個大數據領域消息隊列的應用中仍然處理壟斷地位，後來者Pulsar想做出超越難度很大，Hbase、Redis和MySQL都在特定場景下有一席之地。
唯獨在OLAP領域，百家爭鳴，各有所長。大數據領域開源OLAP引擎包括但是不限於Hive、Druid、Hawq、Presto、Impala、Sparksql、Clickhouse、Greenplum等等。下一篇我們就各個開源OLAP引擎的優缺點和使用場景做出詳細對比，讓開發者進行技術選型時做到心中有數。
歡迎掃碼關注我的公衆號，回覆【JAVAPDF】可以獲得一份200頁秋招面試題！
