歡迎掃碼關注我的公眾號，回復【JAVAPDF】可以獲得一份200頁秋招面試題！

前言

今年有個現象，實時數倉建設突然就被大家所關注。我個人在公眾號也寫過和轉載過幾篇關于實時數據倉庫的文章和方案。

但是對于實時數倉的狂熱追求大可不必。

首先，在技術上幾乎沒有難點，基于強大的開源中間件實現實時數據倉庫的需求已經變得沒有那么困難。其次，實時數倉的建設一定是伴隨著業務的發展而發展，武斷的認為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引擎的優缺點和使用場景做出詳細對比，讓開發者進行技術選型時做到心中有數。

所有文章首發VX公眾號，頭條文章較為落后并且不全~

歡迎掃碼關注我的公眾號，回復【JAVAPDF】可以獲得一份200頁秋招面試題！

總結

以上是生活随笔為你收集整理的adb实时获取屏幕_实时数仓 | 你需要的是一款合适且强大的OLAP数据库(上)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。