你須要的不是實時數倉 | 你須要的是一款合適且強大的OLAP數據庫(上)

前言

今年有個現象，實時數倉建設忽然就被你們所關注。我我的在公衆號也寫過和轉載過幾篇關於實時數據倉庫的文章和方案。

可是對於實時數倉的狂熱追求大可沒必要。

首先，在技術上幾乎沒有難點，基於強大的開源中間件實現實時數據倉庫的需求已經變得沒有那麼困難。其次，實時數倉的建設必定是伴隨着業務的發展而發展，武斷的認爲Kappa架構必定是最好的實時數倉架構是不對的。實際狀況中隨着業務的發展數倉的架構變得沒有那麼非此即彼。

在整個實時數倉的建設中，OLAP數據庫的選型直接制約實時數倉的可用性和功能性。本文從業內幾個典型的數倉建設和發展狀況入手，從架構、技術選型和優缺點分別給你們分析如今市場上的開源OLAP引擎，旨在方便你們技術選型過程當中可以根據實際業務進行選擇。

管中窺豹-菜鳥/知乎/美團/網易嚴選實時數倉建設

爲何要構建實時數據倉庫

傳統的離線數據倉庫將業務數據集中進行存儲後，以固定的計算邏輯定時進行ETL和其它建模後產出報表等應用。離線數據倉庫主要是構建T+1的離線數據，經過定時任務天天拉取增量數據，而後建立各個業務相關的主題維度數據，對外提供T+1的數據查詢接口。計算和數據的實時性均較差，業務人員沒法根據本身的即時性須要獲取幾分鐘以前的實時數據。數據自己的價值隨着時間的流逝會逐步減弱，所以數據發生後必須儘快的達到用戶的手中，實時數倉的構建需求也應運而生。

總之就是一句話：時效性的要求。

阿里菜鳥的實時數倉設計

菜鳥的實時數倉總體設計如右圖，基於業務系統的數據，數據模型是傳統的分層彙總設計（明細/輕度彙總/高度彙總）；計算引擎，選擇的是阿里內部的Blink；數據訪問用天工接入(天工是一個鏈接多種數據源的工具，目的是屏蔽大量的對各類數據庫的直連)；數據應用對應的是菜鳥的各個業務。

菜鳥的實時數倉的架構設計是一個很典型很經得起考驗的設計。實時數據接入部分經過消息中間件(開源大數據領域非Kafka莫屬，Pulsar是後起之秀)，Hbase做爲高度彙總的K-V查詢輔助。

那麼大量的對業務的直接支撐在哪裏？在這裏：ADS。

ADS（後改名爲ADB，加入新特性）是阿里巴巴自主研發的海量數據實時高併發在線分析（Realtime OLAP）雲計算數據庫。(https://help.aliyun.com/docum...

經典的實時數據清洗場景

經典的實時數倉場景

在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/...

美團的實時數倉設計

美團實時數倉數據分層架構

美團的技術方案由如下四層構成：

• 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...

總結

咱們經過以上的分析能夠看出，在整個實時數倉的建設中，業界已經有了成熟的方案。總體架構設計經過分層設計爲OLAP查詢分擔壓力，讓出計算空間，複雜的計算統一在實時計算層作，避免給OLAP查詢帶來過大的壓力。彙總計算教給OLAP數據庫進行。咱們能夠這麼說，在整個架構中實時計算通常是Spark+Flink配合，消息隊列Kafka一家獨大，整個大數據領域消息隊列的應用中仍然處理壟斷地位，後來者Pulsar想作出超越難度很大，Hbase、Redis和MySQL都在特定場景下有一席之地。
惟獨在OLAP領域，百家爭鳴，各有所長。大數據領域開源OLAP引擎包括可是不限於Hive、Druid、Hawq、Presto、Impala、Sparksql、Clickhouse、Greenplum等等。下一篇咱們就各個開源OLAP引擎的優缺點和使用場景作出詳細對比，讓開發者進行技術選型時作到心中有數。

歡迎掃碼關注個人公衆號，回覆【JAVAPDF】能夠得到一份200頁秋招面試題！