在開源盛世的今天，實時數(shù)倉的建設業(yè)界已經(jīng)有了成熟的方案。技術選型上實時計算、消息隊列都有最優(yōu)解，唯獨在 OLAP 領域，百家爭鳴，各有所長。

大數(shù)據(jù)領域開源 OLAP 引擎包括不限于 Hive、Hawq、Presto、Kylin、Impala、SparkSQL、Druid、Clickhouse、Greeplum 等等。我們就各個常用開源 OLAP 引擎的優(yōu)缺點和使用場景做出詳細對比，讓開發(fā)者進行技術選型時做到心中有數(shù)。

本場 Chat 中，會講到以下內(nèi)容：

為什么要構建實時數(shù)據(jù)倉庫

菜鳥、知乎、美團、網(wǎng)易實時數(shù)倉方案

各個開源 OLAP 數(shù)據(jù)庫的優(yōu)缺點

我們該如何做技術選型

適合人群：大數(shù)據(jù)開發(fā)，數(shù)據(jù)倉庫從業(yè)的技術人員。

聲明：本文參考了阿里巴巴菜鳥網(wǎng)絡，知乎，網(wǎng)易嚴選，美團的實時數(shù)倉設計的公開技術文章，感謝以上各位技術同學無私付出。參考鏈接在文中都已經(jīng)給出。

前言

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

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

首先，在技術上幾乎沒有難點，基于強大的開源中間件實現(xiàn)實時數(shù)據(jù)倉庫的需求已經(jīng)變得沒有那么困難。其次，實時數(shù)倉的建設一定是伴隨著業(yè)務的發(fā)展而發(fā)展，武斷的認為Kappa架構一定是最好的實時數(shù)倉架構是不對的。實際情況中隨著業(yè)務的發(fā)展數(shù)倉的架構變得沒有那么非此即彼。

在整個實時數(shù)倉的建設中，OLAP數(shù)據(jù)庫的選型直接制約實時數(shù)倉的可用性和功能性。本文從業(yè)內(nèi)幾個典型的數(shù)倉建設和發(fā)展情況入手，從架構、技術選型和優(yōu)缺點分別給大家分析現(xiàn)在市場上的開源OLAP引擎，旨在方便大家技術選型過程中能夠根據(jù)實際業(yè)務進行選擇。

管中窺豹-菜鳥/知乎/美團/網(wǎng)易嚴選實時數(shù)倉建設

為什么要構建實時數(shù)據(jù)倉庫

傳統(tǒng)的離線數(shù)據(jù)倉庫將業(yè)務數(shù)據(jù)集中進行存儲后，以固定的計算邏輯定時進行ETL和其它建模后產(chǎn)出報表等應用。離線數(shù)據(jù)倉庫主要是構建T+1的離線數(shù)據(jù)，通過定時任務每天拉取增量數(shù)據(jù)，然后創(chuàng)建各個業(yè)務相關的主題維度數(shù)據(jù)，對外提供T+1的數(shù)據(jù)查詢接口。計算和數(shù)據(jù)的實時性均較差，業(yè)務人員無法根據(jù)自己的即時性需要獲取幾分鐘之前的實時數(shù)據(jù)。數(shù)據(jù)本身的價值隨著時間的流逝會逐步減弱，因此數(shù)據(jù)發(fā)生后必須盡快的達到用戶的手中，實時數(shù)倉的構建需求也應運而生。

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

阿里菜鳥的實時數(shù)倉設計

菜鳥的實時數(shù)倉整體設計如上圖，基于業(yè)務系統(tǒng)的數(shù)據(jù)，數(shù)據(jù)模型是傳統(tǒng)的分層匯總設計（明細/輕度匯總/高度匯總）；計算引擎，選擇的是阿里內(nèi)部的Blink；數(shù)據(jù)訪問用天工接入(天工是一個連接多種數(shù)據(jù)源的工具，目的是屏蔽大量的對各種數(shù)據(jù)庫的直連)；數(shù)據(jù)應用對應的是菜鳥的各個業(yè)務。

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

那么大量的對業(yè)務的直接支撐在哪里？在這里：ADS。

ADS（后更名為ADB，加入新特性）是阿里巴巴自主研發(fā)的海量數(shù)據(jù)實時高并發(fā)在線分析（Realtime OLAP）云計算數(shù)據(jù)庫。(https://help.aliyun.com/document_detail/93838.html)

經(jīng)典的實時數(shù)據(jù)清洗場景

經(jīng)典的實時數(shù)倉場景

在ADB的官方文檔中給出了ADB的能力：

快ADB采用MPP+DAG融合引擎，采用行列混存技術、自動索引等技術，可以快速擴容至數(shù)千節(jié)點。

靈活隨意調(diào)整節(jié)點數(shù)量和動態(tài)升降配實例規(guī)格。

易用全面兼容MySQL協(xié)議和SQL

超大規(guī)模全分布式結構，無任何單點設計，方便橫向擴展增加SQL處理并發(fā)。

高并發(fā)寫入小規(guī)模的10萬TPS寫入能力，通過橫向擴容節(jié)點提升至200萬+TPS的寫入能力。實時寫入數(shù)據(jù)后，約1秒左右即可查詢分析。單個表最大支持2PB數(shù)據(jù)，十萬億記錄。

知乎的實時數(shù)倉設計

知乎的實時數(shù)倉實踐以及架構的演進分為三個階段：

實時數(shù)倉 1.0 版本，主題： ETL 邏輯實時化，技術方案：Spark Streaming

實時數(shù)倉 2.0 版本，主題：數(shù)據(jù)分層，指標計算實時化，技術方案：Flink Streaming

實時數(shù)倉未來展望：Streaming SQL 平臺化，元信息管理系統(tǒng)化，結果驗收自動化

實時數(shù)倉 1.0 版本

實時數(shù)倉 2.0 版本

在技術架構上，增加了指標匯總層，指標匯總層是由明細層或者明細匯總層通過聚合計算得到，這一層產(chǎn)出了絕大部分的實時數(shù)倉指標，這也是與實時數(shù)倉 1.0 最大的區(qū)別。

技術選型上，知乎根據(jù)不同業(yè)務場景選擇了HBase 和 Redis 作為實時指標的存儲引擎，在OLAP選型上，知乎選擇了Druid。

知乎實時多維分析平臺架構

Druid 整體架構

Druid是一個高效的數(shù)據(jù)查詢系統(tǒng)，主要解決的是對于大量的基于時序的數(shù)據(jù)進行聚合查詢。數(shù)據(jù)可以實時攝入，進入到Druid后立即可查，同時數(shù)據(jù)是幾乎是不可變。通常是基于時序的事實事件，事實發(fā)生后進入Druid，外部系統(tǒng)就可以對該事實進行查詢。Druid采用的架構:

shared-nothing架構與lambda架構

Druid設計的三個原則:

快速查詢：部分數(shù)據(jù)聚合（Partial Aggregate） + 內(nèi)存化（In-Memory） + 索引（Index）

水平拓展能力：分布式數(shù)據(jù)（Distributed data）+并行化查詢（Parallelizable Query）

實時分析：Immutable Past , Append-Only Future

如果你對Druid不了解，請參考這里：https://zhuanlan.zhihu.com/p/35146892

美團的實時數(shù)倉設計

美團實時數(shù)倉數(shù)據(jù)分層架構

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

ODS 層：Binlog 和流量日志以及各業(yè)務實時隊列。

數(shù)據(jù)明細層：業(yè)務領域整合提取事實數(shù)據(jù)，離線全量和實時變化數(shù)據(jù)構建實時維度數(shù)據(jù)。

數(shù)據(jù)匯總層：使用寬表模型對明細數(shù)據(jù)補充維度數(shù)據(jù)，對共性指標進行匯總。

App 層：為了具體需求而構建的應用層，通過 RPC 框架對外提供服務。

根據(jù)不同業(yè)務場景，實時數(shù)倉各個模型層次使用的存儲方案和OLAP引擎如下：

數(shù)據(jù)明細層 對于維度數(shù)據(jù)部分場景下關聯(lián)的頻率可達 10w+ TPS，我們選擇 Cellar（美團內(nèi)部分布式K-V存儲系統(tǒng)，類似Redis） 作為存儲，封裝維度服務為實時數(shù)倉提供維度數(shù)據(jù)。

數(shù)據(jù)匯總層 對于通用的匯總指標，需要進行歷史數(shù)據(jù)關聯(lián)的數(shù)據(jù)，采用和維度數(shù)據(jù)一樣的方案通過 Cellar 作為存儲，用服務的方式進行關聯(lián)操作。

數(shù)據(jù)應用層 應用層設計相對復雜，再對比了幾種不同存儲方案后。我們制定了以數(shù)據(jù)讀寫頻率 1000 QPS 為分界的判斷依據(jù)。對于讀寫平均頻率高于 1000 QPS 但查詢不太復雜的實時應用，比如商戶實時的經(jīng)營數(shù)據(jù)。采用 Cellar 為存儲，提供實時數(shù)據(jù)服務。對于一些查詢復雜的和需要明細列表的應用，使用 Elasticsearch 作為存儲則更為合適。而一些查詢頻率低，比如一些內(nèi)部運營的數(shù)據(jù)。 Druid 通過實時處理消息構建索引，并通過預聚合可以快速的提供實時數(shù)據(jù) OLAP 分析功能。對于一些歷史版本的數(shù)據(jù)產(chǎn)品進行實時化改造時，也可以使用 MySQL 存儲便于產(chǎn)品迭代。

總之，在OLAP選型上同樣以Druid為主。

網(wǎng)易嚴選的實時數(shù)倉設計

網(wǎng)易嚴選的實時數(shù)倉整體框架依據(jù)數(shù)據(jù)的流向分為不同的層次，接入層會依據(jù)各種數(shù)據(jù)接入工具 收集各個業(yè)務系統(tǒng)的數(shù)據(jù)。消息隊列的數(shù)據(jù)既是離線數(shù)倉的原始數(shù)據(jù)，也是實時計算的原始數(shù)據(jù)，這樣可以保證實時和離線的原始數(shù)據(jù)是統(tǒng)一的。 在計算層經(jīng)過 Flink+實時計算引擎做一些加工處理，然后落地到存儲層中不同存儲介質(zhì)當中。不同的存儲介質(zhì)是依據(jù)不同的應用場景來選擇?？蚣苤羞€有Flink和Kafka的交互，在數(shù)據(jù)上進行一個分層設計，計算引擎從Kafka中撈取數(shù)據(jù)做一些加工然后放回Kafka。在存儲層加工好的數(shù)據(jù)會通過服務層的兩個服務：統(tǒng)一查詢、指標管理，統(tǒng)一查詢是通過業(yè)務方調(diào)取數(shù)據(jù)接口的一個服務，指標管理是對數(shù)據(jù)指標的定義和管理工作。通過服務層應用到不同的數(shù)據(jù)應用，數(shù)據(jù)應用可能是我們的正式產(chǎn)品或者直接的業(yè)務系統(tǒng)。

基于以上的設計，技術選型如下：

對于存儲層會依據(jù)不同的數(shù)據(jù)層的特點選擇不同的存儲介質(zhì)，ODS層和DWD層都是存儲的一些實時數(shù)據(jù)，選擇的是Kafka進行存儲，在DWD層會關聯(lián)一些歷史明細數(shù)據(jù)，會將其放到 Redis 里面。在DIM層主要做一些高并發(fā)維度的查詢關聯(lián)，一般將其存放在HBase里面，對于DIM層比價復雜，需要綜合考慮對于數(shù)據(jù)落地的要求以及具體的查詢引擎來選擇不同的存儲方式。對于常見的指標匯總模型直接放在 MySQL 里面，維度比較多的、寫入更新比較大的模型會放在HBase里面，還有明細數(shù)據(jù)需要做一些多維分析或者關聯(lián)會將其存儲在Greenplum里面，還有一種是維度比較多、需要做排序、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis里面。

網(wǎng)易嚴選選擇了GreenPulm、Hbase、Redis和MySQL作為數(shù)據(jù)的計算和透出層。

GreenPulm的技術特點如下：

支持海量數(shù)據(jù)存儲和處理

支持Just In Time BI：通過準實時、實時的數(shù)據(jù)加載方式，實現(xiàn)數(shù)據(jù)倉庫的實時更新，進而實現(xiàn)動態(tài)數(shù)據(jù)倉庫（ADW），基于動態(tài)數(shù)據(jù)倉庫，業(yè)務用戶能對當前業(yè)務數(shù)據(jù)進行BI實時分析（Just In Time BI）

支持主流的sql語法，使用起來十分方便，學習成本低

擴展性好，支持多語言的自定義函數(shù)和自定義類型等

提供了大量的維護工具，使用維護起來很方便

支持線性擴展：采用MPP并行處理架構。在MPP結構中增加節(jié)點就可以線性提供系統(tǒng)的存儲容量和處理能力

較好的并發(fā)支持及高可用性支持除了提供硬件級的Raid技術外，還提供數(shù)據(jù)庫層Mirror機制保護，提供Master/Stand by機制進行主節(jié)點容錯，當主節(jié)點發(fā)生錯誤時，可以切換到Stand by節(jié)點繼續(xù)服務

支持MapReduce：一種大規(guī)模數(shù)據(jù)分析技術

數(shù)據(jù)庫內(nèi)部壓縮

如果你對GreenPulm不熟悉可以參考這里：https://www.cnblogs.com/wujin/p/6781264.html

總結

我們通過以上的分析可以看出，在整個實時數(shù)倉的建設中，業(yè)界已經(jīng)有了成熟的方案。整體架構設計通過分層設計為OLAP查詢分擔壓力，讓出計算空間，復雜的計算統(tǒng)一在實時計算層做，避免給OLAP查詢帶來過大的壓力。匯總計算教給OLAP數(shù)據(jù)庫進行。我們可以這么說，在整個架構中實時計算一般是Spark+Flink配合，消息隊列Kafka一家獨大，整個大數(shù)據(jù)領域消息隊列的應用中仍然處理壟斷地位，后來者Pulsar想做出超越難度很大，Hbase、Redis和MySQL都在特定場景下有一席之地。唯獨在OLAP領域，百家爭鳴，各有所長。大數(shù)據(jù)領域開源OLAP引擎包括但是不限于Hive、Druid、Hawq、Presto、Impala、Sparksql、Clickhouse、Greenplum等等。下一篇我們就各個開源OLAP引擎的優(yōu)缺點和使用場景做出詳細對比，讓開發(fā)者進行技術選型時做到心中有數(shù)。

參考鏈接：https://yq.aliyun.com/articles/691541https://dwz.cn/qwcuWD4Lhttps://tech.meituan.com/2018/10/18/meishi-data-flink.htmlhttp://lxw1234.com/archives/2017/07/867.htmlhttps://www.codercto.com/a/47662.html

OLAP百家爭鳴

OLAP簡介

OLAP，也叫聯(lián)機分析處理（Online Analytical Processing）系統(tǒng)，有的時候也叫DSS決策支持系統(tǒng)，就是我們說的數(shù)據(jù)倉庫。與此相對的是OLTP（on-line transaction processing）聯(lián)機事務處理系統(tǒng)。

聯(lián)機分析處理 (OLAP) 的概念最早是由關系數(shù)據(jù)庫之父E.F.Codd于1993年提出的。OLAP的提出引起了很大的反響，OLAP作為一類產(chǎn)品同聯(lián)機事務處理 (OLTP) 明顯區(qū)分開來。

Codd認為聯(lián)機事務處理（OLTP）已不能滿足終端用戶對數(shù)據(jù)庫查詢分析的要求，SQL對大數(shù)據(jù)庫的簡單查詢也不能滿足用戶分析的需求。用戶的決策分析需要對關系數(shù)據(jù)庫進行大量計算才能得到結果，而查詢的結果并不能滿足決策者提出的需求。因此，Codd提出了多維數(shù)據(jù)庫和多維分析的概念，即OLAP。

OLAP委員會對聯(lián)機分析處理的定義為：從原始數(shù)據(jù)中轉(zhuǎn)化出來的、能夠真正為用戶所理解的、并真實反映企業(yè)多維特性的數(shù)據(jù)稱為信息數(shù)據(jù)，使分析人員、管理人員或執(zhí)行人員能夠從多種角度對信息數(shù)據(jù)進行快速、一致、交互地存取，從而獲得對數(shù)據(jù)的更深入了解的一類軟件技術。OLAP的目標是滿足決策支持或多維環(huán)境特定的查詢和報表需求，它的技術核心是"維"這個概念，因此OLAP也可以說是多維數(shù)據(jù)分析工具的集合。

OLAP的準則和特性

E.F.Codd提出了關于OLAP的12條準則：

準則1 OLAP模型必須提供多維概念視圖

準則2 透明性準則

準則3 存取能力準則

準則4 穩(wěn)定的報表能力

準則5 客戶/服務器體系結構

準則6 維的等同性準則

準則7 動態(tài)的稀疏矩陣處理準則

準則8 多用戶支持能力準則

準則9 非受限的跨維操作

準則10 直觀的數(shù)據(jù)操縱

準則11 靈活的報表生成

準則12 不受限的維與聚集層次

一言以蔽之：

OLTP系統(tǒng)強調(diào)數(shù)據(jù)庫內(nèi)存效率，強調(diào)內(nèi)存各種指標的命令率，強調(diào)綁定變量，強調(diào)并發(fā)操作，強調(diào)事務性；OLAP系統(tǒng)則強調(diào)數(shù)據(jù)分析，強調(diào)SQL執(zhí)行時長，強調(diào)磁盤I/O，強調(diào)分區(qū)。

OLAP開源引擎

目前市面上主流的開源OLAP引擎包含不限于：Hive、Hawq、Presto、Kylin、Impala、Sparksql、Druid、Clickhouse、Greeplum等，可以說目前沒有一個引擎能在數(shù)據(jù)量，靈活程度和性能上做到完美，用戶需要根據(jù)自己的需求進行選型。

組件特點和簡介

Hive

https://hive.apache.org/

Hive是基于Hadoop的一個數(shù)據(jù)倉庫工具，可以將結構化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供完整的sql查詢功能，可以將sql語句轉(zhuǎn)換為MapReduce任務進行運行。其優(yōu)點是學習成本低，可以通過類SQL語句快速實現(xiàn)簡單的MapReduce統(tǒng)計，不必開發(fā)專門的MapReduce應用，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。

對于hive主要針對的是OLAP應用，其底層是hdfs分布式文件系統(tǒng)，hive一般只用于查詢分析統(tǒng)計，而不能是常見的CUD操作，Hive需要從已有的數(shù)據(jù)庫或日志進行同步最終入到hdfs文件系統(tǒng)中，當前要做到增量實時同步都相當困難。

Hive的優(yōu)勢是完善的SQL支持，極低的學習成本，自定義數(shù)據(jù)格式，極高的擴展性可輕松擴展到幾千個節(jié)點等等。

但是Hive 在加載數(shù)據(jù)的過程中不會對數(shù)據(jù)進行任何處理，甚至不會對數(shù)據(jù)進行掃描，因此也沒有對數(shù)據(jù)中的某些 Key 建立索引。Hive 要訪問數(shù)據(jù)中滿足條件的特定值時，需要暴力掃描整個數(shù)據(jù)庫，因此訪問延遲較高。

Hive真的太慢了。大數(shù)據(jù)量聚合計算或者聯(lián)表查詢，Hive的耗時動輒以小時計算，在某一個瞬間，我甚至想把它開除出OLAP"國籍"，但是不得不承認Hive仍然是基于Hadoop體系應用最廣泛的OLAP引擎。

Hawq

http://hawq.apache.orghttps://blog.csdn.net/wzy0623/article/details/55047696https://www.oschina.net/p/hawq

Hawq是一個Hadoop原生大規(guī)模并行SQL分析引擎，Hawq采用 MPP 架構，改進了針對 Hadoop 的基于成本的查詢優(yōu)化器。除了能高效處理本身的內(nèi)部數(shù)據(jù)，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數(shù)據(jù)源。HAWQ全面兼容 SQL 標準，能編寫 SQL UDF，還可用 SQL 完成簡單的數(shù)據(jù)挖掘和機器學習。無論是功能特性，還是性能表現(xiàn)，HAWQ 都比較適用于構建 Hadoop 分析型數(shù)據(jù)倉庫應用。

一個典型的Hawq集群組件如下：

網(wǎng)絡上有人對Hawq與Hive查詢性能進行了對比測試，總體來看，使用Hawq內(nèi)部表比Hive快的多（4-50倍）。原文鏈接：https://blog.csdn.net/wzy0623/article/details/71479539

Spark SQL

https://spark.apache.org/sql/

SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成,可以將結構化數(shù)據(jù)作為 Spark 的 RDD 進行查詢。SparkSQL作為Spark生態(tài)的一員繼續(xù)發(fā)展，而不再受限于Hive，只是兼容Hive。

Spark SQL在整個Spark體系中的位置如下：

SparkSQL的架構圖如下：

Spark SQL對熟悉Spark的同學來說，很容易理解并上手使用：相比于Spark RDD API，Spark SQL包含了對結構化數(shù)據(jù)和在其上運算的更多信息，Spark SQL使用這些信息進行了額外的優(yōu)化，使對結構化數(shù)據(jù)的操作更加高效和方便。SQL提供了一個通用的方式來訪問各式各樣的數(shù)據(jù)源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。Hive兼容性極好。

Presto

Presto 是由 Facebook 開源的大數(shù)據(jù)分布式 SQL 查詢引擎，適用于交互式分析查詢，可支持眾多的數(shù)據(jù)源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口開發(fā)數(shù)據(jù)源連接器。

Presto支持標準的ANSI SQL，包括復雜查詢、聚合（aggregation）、連接（join）和窗口函數(shù)（window functions)。作為Hive和Pig（Hive和Pig都是通過MapReduce的管道流來完成HDFS數(shù)據(jù)的查詢）的替代者，Presto 本身并不存儲數(shù)據(jù)，但是可以接入多種數(shù)據(jù)源，并且支持跨數(shù)據(jù)源的級聯(lián)查詢。

Presto沒有使用MapReduce，它是通過一個定制的查詢和執(zhí)行引擎來完成的。它的所有的查詢處理是在內(nèi)存中，這也是它的性能很高的一個主要原因。Presto和Spark SQL有很大的相似性，這是它區(qū)別于Hive的最根本的區(qū)別。

但Presto由于是基于內(nèi)存的，而hive是在磁盤上讀寫的，因此presto比hive快很多，但是由于是基于內(nèi)存的計算當多張大表關聯(lián)操作時易引起內(nèi)存溢出錯誤。

Kylin

http://kylin.apache.org/cn/https://www.infoq.cn/article/kylin-apache-in-meituan-olap-scenarios-practice/

提到Kylin就不得不說說ROLAP和MOLAP。

傳統(tǒng)OLAP根據(jù)數(shù)據(jù)存儲方式的不同分為ROLAP（relational olap）以及MOLAP（multi-dimension olap）

ROLAP 以關系模型的方式存儲用作多為分析用的數(shù)據(jù)，優(yōu)點在于存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數(shù)據(jù)進行聚合計算，為了改善短板，ROLAP使用了列存、并行查詢、查詢優(yōu)化、位圖索引等技術。

MOLAP 將分析用的數(shù)據(jù)物理上存儲為多維數(shù)組的形式，形成CUBE結構。維度的屬性值映射成多維數(shù)組的下標或者下標范圍，事實以多維數(shù)組的值存儲在數(shù)組單元中，優(yōu)勢是查詢快速，缺點是數(shù)據(jù)量不容易控制，可能會出現(xiàn)維度爆炸的問題。

而Kylin自身就是一個MOLAP系統(tǒng)，多維立方體（MOLAP Cube）的設計使得用戶能夠在Kylin里為百億以上數(shù)據(jù)集定義數(shù)據(jù)模型并構建立方體進行數(shù)據(jù)的預聚合。

Apache Kylin?是一個開源的分布式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，最初由eBay Inc. 開發(fā)并貢獻至開源社區(qū)。它能在亞秒內(nèi)查詢巨大的Hive表。

Kylin的優(yōu)勢有：

提供ANSI-SQL接口

交互式查詢能力

MOLAP Cube 的概念

與BI工具可無縫整合

所以適合Kylin的場景包括：

用戶數(shù)據(jù)存在于Hadoop HDFS中，利用Hive將HDFS文件數(shù)據(jù)以關系數(shù)據(jù)方式存取，數(shù)據(jù)量巨大，在500G以上

每天有數(shù)G甚至數(shù)十G的數(shù)據(jù)增量導入

有10個以內(nèi)較為固定的分析維度

簡單來說，Kylin中數(shù)據(jù)立方的思想就是以空間換時間，通過定義一系列的緯度，對每個緯度的組合進行預先計算并存儲。有N個緯度，就會有2的N次種組合。所以最好控制好緯度的數(shù)量，因為存儲量會隨著緯度的增加爆炸式的增長，產(chǎn)生災難性后果。

Impala

https://impala.apache.org/

Impala也是一個SQL on Hadoop的查詢工具，底層采用MPP技術，支持快速交互式SQL查詢。與Hive共享元數(shù)據(jù)存儲。Impalad是核心進程，負責接收查詢請求并向多個數(shù)據(jù)節(jié)點分發(fā)任務。statestored進程負責監(jiān)控所有Impalad進程，并向集群中的節(jié)點報告各個Impalad進程的狀態(tài)。catalogd進程負責廣播通知元數(shù)據(jù)的最新信息。

Impala的架構圖如下：

Impala的特性包括：

支持Parquet、Avro、Text、RCFile、SequenceFile等多種文件格式

支持存儲在HDFS、HBase、Amazon S3上的數(shù)據(jù)操作

支持多種壓縮編碼方式：Snappy、Gzip、Deflate、Bzip2、LZO

支持UDF和UDAF

自動以最有效的順序進行表連接

允許定義查詢的優(yōu)先級排隊策略

支持多用戶并發(fā)查詢

支持數(shù)據(jù)緩存

提供計算統(tǒng)計信息（COMPUTE STATS）

提供窗口函數(shù)（聚合 OVER PARTITION, RANK, LEAD, LAG, NTILE等等）以支持高級分析功能

支持使用磁盤進行連接和聚合，當操作使用的內(nèi)存溢出時轉(zhuǎn)為磁盤操作

允許在where子句中使用子查詢

允許增量統(tǒng)計——只在新數(shù)據(jù)或改變的數(shù)據(jù)上執(zhí)行統(tǒng)計計算

支持maps、structs、arrays上的復雜嵌套查詢

可以使用impala插入或更新HBase

同樣，Impala經(jīng)常會和Hive、Presto放在一起做比較，Impala的劣勢也同樣明顯：

Impala不提供任何對序列化和反序列化的支持。

Impala只能讀取文本文件，而不能讀取自定義二進制文件。

每當新的記錄/文件被添加到HDFS中的數(shù)據(jù)目錄時，該表需要被刷新。這個缺點會導致正在執(zhí)行的查詢sql遇到刷新會掛起，查詢不動。

Druid

https://druid.apache.org/https://blog.csdn.net/warren288/article/details/80629909

Druid 是一種能對歷史和實時數(shù)據(jù)提供亞秒級別的查詢的數(shù)據(jù)存儲。Druid 支持低延時的數(shù)據(jù)攝取，靈活的數(shù)據(jù)探索分析，高性能的數(shù)據(jù)聚合，簡便的水平擴展。適用于數(shù)據(jù)量大，可擴展能力要求高的分析型查詢系統(tǒng)。

Druid解決的問題包括：數(shù)據(jù)的快速攝入和數(shù)據(jù)的快速查詢。所以要理解Druid，需要將其理解為兩個系統(tǒng)，即輸入系統(tǒng)和查詢系統(tǒng)。

Druid的架構如下：

Druid的特點包括：

Druid實時的數(shù)據(jù)消費，真正做到數(shù)據(jù)攝入實時、查詢結果實時

Druid支持 PB 級數(shù)據(jù)、千億級事件快速處理，支持每秒數(shù)千查詢并發(fā)

Druid的核心是時間序列，把數(shù)據(jù)按照時間序列分批存儲，十分適合用于對按時間進行統(tǒng)計分析的場景

Druid把數(shù)據(jù)列分為三類：時間戳、維度列、指標列

Druid不支持多表連接

Druid中的數(shù)據(jù)一般是使用其他計算框架(Spark等)預計算好的低層次統(tǒng)計數(shù)據(jù)

Druid不適合用于處理透視維度復雜多變的查詢場景

Druid擅長的查詢類型比較單一，一些常用的SQL(groupby 等)語句在druid里運行速度一般

Druid支持低延時的數(shù)據(jù)插入、更新，但是比hbase、傳統(tǒng)數(shù)據(jù)庫要慢很多

與其他的時序數(shù)據(jù)庫類似，Druid在查詢條件命中大量數(shù)據(jù)情況下可能會有性能問題，而且排序、聚合等能力普遍不太好，靈活性和擴展性不夠，比如缺乏Join、子查詢等。

我個人對Druid的理解在于，Druid保證數(shù)據(jù)實時寫入，但查詢上對SQL支持的不夠完善(不支持Join)，適合將清洗好的記錄實時錄入，然后迅速查詢包含歷史的結果，在我們目前的業(yè)務上沒有實際應用。

Druid的應用可以參考：《Druid 在有贊的使用場景及應用實踐》https://blog.csdn.net/weixin_34273481/article/details/89238947

Greeplum

https://greenplum.org/https://blog.csdn.net/yongshenghuang/article/details/84925941http://www.itdecent.cn/p/b5c85cadb362

Greenplum是一個開源的大規(guī)模并行數(shù)據(jù)分析引擎。借助MPP架構，在大型數(shù)據(jù)集上執(zhí)行復雜SQL分析的速度比很多解決方案都要快。

GPDB完全支持ANSI SQL 2008標準和SQL OLAP 2003 擴展；從應用編程接口上講，它支持ODBC和JDBC。完善的標準支持使得系統(tǒng)開發(fā)、維護和管理都大為方便。支持分布式事務，支持ACID。保證數(shù)據(jù)的強一致性。做為分布式數(shù)據(jù)庫，擁有良好的線性擴展能力。GPDB有完善的生態(tài)系統(tǒng)，可以與很多企業(yè)級產(chǎn)品集成，譬如SAS，Cognos，Informatic，Tableau等；也可以很多種開源軟件集成，譬如Pentaho,Talend 等。

GreenPulm的架構如下：

GreenPulm的技術特點如下：

支持海量數(shù)據(jù)存儲和處理

支持Just In Time BI：通過準實時、實時的數(shù)據(jù)加載方式，實現(xiàn)數(shù)據(jù)倉庫的實時更新，進而實現(xiàn)動態(tài)數(shù)據(jù)倉庫（ADW），基于動態(tài)數(shù)據(jù)倉庫，業(yè)務用戶能對當前業(yè)務數(shù)據(jù)進行BI實時分析（Just In Time BI）

支持主流的sql語法，使用起來十分方便，學習成本低

擴展性好，支持多語言的自定義函數(shù)和自定義類型等

提供了大量的維護工具，使用維護起來很方便

支持線性擴展：采用MPP并行處理架構。在MPP結構中增加節(jié)點就可以線性提供系統(tǒng)的存儲容量和處理能力

較好的并發(fā)支持及高可用性支持除了提供硬件級的Raid技術外，還提供數(shù)據(jù)庫層Mirror機制保護，提供Master/Stand by機制進行主節(jié)點容錯，當主節(jié)點發(fā)生錯誤時，可以切換到Stand by節(jié)點繼續(xù)服務

支持MapReduce

數(shù)據(jù)庫內(nèi)部壓縮

一個重要的信息：Greenplum基于Postgresql，也就是說GreenPulm和TiDB的定位類似，想要在OLTP和OLAP上進行統(tǒng)一。

ClickHouse

https://clickhouse.yandex/https://clickhouse.yandex/docs/zh/development/architecture/http://www.clickhouse.com.cn/http://www.itdecent.cn/p/a5bf490247ea

官網(wǎng)對ClickHouse的介紹：

ClickHouse is an open source column-oriented database management system capable of real time generation of analytical data reports using SQL queries.

Clickhouse由俄羅斯yandex公司開發(fā)。專為在線數(shù)據(jù)分析而設計。Yandex是俄羅斯搜索引擎公司。官方提供的文檔表名，ClickHouse 日處理記錄數(shù)"十億級"。

特性:采用列式存儲；數(shù)據(jù)壓縮；支持分片，并且同一個計算任務會在不同分片上并行執(zhí)行，計算完成后會將結果匯總；支持SQL；支持聯(lián)表查詢；支持實時更新；自動多副本同步；支持索引；分布式存儲查詢。

大家都Nginx不陌生吧，戰(zhàn)斗民族開源的軟件普遍的特點包括：輕量級，快。

ClickHouse最大的特點就是快，快，快，重要的話說三遍！與Hadoop、Spark這些巨無霸組件相比，ClickHouse很輕量級，其特點：

列式存儲數(shù)據(jù)庫，數(shù)據(jù)壓縮

關系型、支持SQL

分布式并行計算，把單機性能壓榨到極限

高可用

數(shù)據(jù)量級在PB級別

實時數(shù)據(jù)更新

索引

使用ClickHouse也有其本身的限制，包括：

缺少高頻率，低延遲的修改或刪除已存在數(shù)據(jù)的能力。僅能用于批量刪除或修改數(shù)據(jù)。

沒有完整的事務支持

不支持二級索引

有限的SQL支持，join實現(xiàn)與眾不同

不支持窗口功能

元數(shù)據(jù)管理需要人工干預維護

總結

上面給出了常用的一些OLAP引擎，它們各自有各自的特點，我們將其分組：

Hive，Hawq，Impala - 基于SQL on Hadoop

Presto和Spark SQL類似 - 基于內(nèi)存解析SQL生成執(zhí)行計劃

Kylin - 用空間換時間，預計算

Druid - 一個支持數(shù)據(jù)的實時攝入

ClickHouse - OLAP領域的Hbase，單表查詢性能優(yōu)勢巨大

Greenpulm - OLAP領域的Postgresql

如果你的場景是基于HDFS的離線計算任務，那么Hive，Hawq和Imapla就是你的調(diào)研目標；如果你的場景解決分布式查詢問題，有一定的實時性要求，那么Presto和SparkSQL可能更符合你的期望；如果你的匯總維度比較固定，實時性要求較高，可以通過用戶配置的維度+指標進行預計算，那么不妨嘗試Kylin和Druid；ClickHouse則在單表查詢性能上獨領風騷，遠超過其他的OLAP數(shù)據(jù)庫；Greenpulm作為關系型數(shù)據(jù)庫產(chǎn)品，性能可以隨著集群的擴展線性增長，更加適合進行數(shù)據(jù)分析。

就像美團在調(diào)研Kylin的報告中所說的：

目前還沒有一個OLAP系統(tǒng)能夠滿足各種場景的查詢需求。其本質(zhì)原因是，沒有一個系統(tǒng)能同時在數(shù)據(jù)量、性能、和靈活性三個方面做到完美，每個系統(tǒng)在設計時都需要在這三者間做出取舍。