摘要：本文主要介紹了主流開源的OLAP引擎：Hive、Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等，逐一介紹了每一款開源 OLAP 引擎，包含架構、優缺點、使用場景等，希望可以給大家有所啓發。
PS: 文章較長，建議收藏慢慢看。
說起 OLAP 要追溯到 1993 年。
OLAP 準則
準則1 OLAP模型必須提供多維概念視圖
準則2 透明性準則
準則3 存取能力準則
準則4 穩定的報表能力
準則5 客戶/服務器體系結構
準則6 維的等同性準則
準則7 動態的稀疏矩陣處理準則
準則8 多用戶支持能力準則
準則9 非受限的跨維操作
準則10 直觀的數據操縱
準則11 靈活的報表生成
準則12 不受限的維與聚集層次
OLAP場景的關鍵特徵
大多數是讀請求
數據總是以相當大的批(> 1000 rows)進行寫入
不修改已添加的數據
每次查詢都從數據庫中讀取大量的行，但是同時又僅需要少量的列
寬表，即每個表包含着大量的列
較少的查詢(通常每臺服務器每秒數百個查詢或更少)
對於簡單查詢，允許延遲大約50毫秒
列中的數據相對較小：數字和短字符串(例如，每個URL 60個字節)
處理單個查詢時需要高吞吐量（每個服務器每秒高達數十億行）
事務不是必須的
對數據一致性要求低
每一個查詢除了一個大表外都很小
查詢結果明顯小於源數據，換句話說，數據被過濾或聚合後能夠被盛放在單臺服務器的內存中
與OLAP 不同的是，OLTP系統強調數據庫內存效率，強調內存各種指標的命令率，強調綁定變量，強調併發操作，強調事務性。
OLAP系統則強調數據分析，強調SQL執行時長，強調磁盤I/O，強調分區。
OLAP開源引擎
目前市面上主流的開源OLAP引擎包含不限於：Hive、Spark SQL、Presto、Kylin、Impala、Druid、Clickhouse、Greeplum等，可以說目前沒有一個引擎能在數據量，靈活程度和性能上做到完美，用戶需要根據自己的需求進行選型。
從事數據開發工作的小夥伴，大概率用過以上的幾種甚至全部。所以下面就開門見山了，默認大家熟悉大數據的專業名詞和生態環境。
Hive hive.apache.org
Hive 是基於 Hadoop 的一個數據倉庫工具，可以將結構化的數據文件映射爲一張數據庫表，並提供完整的 sql 查詢功能，可以將 sql 語句轉換爲 MapReduce 任務進行運行。其優點是學習成本低，可以通過類SQL語句快速實現簡單的MapReduce統計，不必開發專門的MapReduce應用，十分適合數據倉庫的統計分析。
Spark SQL spark.apache.org/sql
SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成,可以將結構化數據作爲 Spark 的 RDD 進行查詢。SparkSQL作爲Spark生態的一員繼續發展，而不再受限於Hive，只是兼容Hive。
幾點說明：
1）Spark SQL的應用並不侷限於SQL；
2）訪問hive、json、parquet等文件的數據；
3）SQL只是Spark SQL的一個功能而已；
4）Spark SQL這個名字起的並不恰當；
Spark SQL在整個Spark體系中的位置如下
看圖說話，分成三個部分，第一部分是前端的，第二部分是後端的，對三個部分是中間的Catalyst，這個Catalyst是整個架構的核心。
關於架構的流程總結，下面引用知乎@ysiwgtus 的內容
1、首先我們看前端。前端有不同種的訪問方式。
1）典型的我們可以使用hive，你hive過來就是一個SQL語句，SQL語句就是一個字符串，那麼這個字符串如何才能夠被Catalyst進行解析呢，或者說如何將一個SQL語句翻譯成spark的作業呢，他要經過解析的，有一個抽象語法樹，這是第一種訪問方式。
2）第二種訪問方式，我們可以通過spark的應用程序，編程的方式來操作，編程的時候我們可以使用SQL，也可以使用dataframe或者是dataset api。
3）第三種是Streaming SQL，也就是說流和SQL綜合起來使用。
2、我們看Catalyst
1）前端三個訪問方式，當前端過來以後他首先會生成一個Unresolved Logical Plan，也就是一個沒有徹底解析完的一個執行計劃，這個執行計劃會和我們的元數據，也就是metastore裏面的schema一個表信息進行整合然後生成一個Logical Plan（邏輯執行計劃）。
2）那麼這個邏輯執行計劃是最原始的，中間還會做各種優化也很多規則作用上去，也就是圖中的Optimization Rules，然後進行優化以後生成優化過後的邏輯執行計劃，就是圖中的Optimized Logical Plan。
3）那麼邏輯執行計劃生成完了以後，纔會生成物理執行計劃，也就是我們spark的一個作業。
那麼從你的SQL語句解析成抽象語法樹之後後續的部分全部交給Catalyst來完成，包括你邏輯執行計劃的生成，邏輯執行計劃的優化都是由Catalyst完成的，我們再回顧一下shark，他的解析然後邏輯執行計劃的生成和優化全部都是依賴於hive的，那麼這就是sparkSQL和hive典型的一個區別從抽象語法樹之後，也就是圖上AST之後完全由sparkSQL裏的Catalyst接管以後，由他來生成物理執行計劃，並最終提交到生產上面去運行就行了。
3、以上就是sparkSQL架構的整體的流程，這個流程當中主要有幾個部分，語法樹、邏輯執行計劃、優化之後的邏輯執行計劃、物理執行計劃。如果熟悉SQL的執行流程或者瞭解hive的SQL語句是怎麼樣從SQL翻譯成mapreduce作業的話，那麼其實你會看出來整個流程都是非常相似的，那麼在SQL on hadoop框架裏面的那麼多框架，只要是基於SQL的，他的大概流程都是這樣子的，從SQL解析過後成爲一個抽象語法樹，然後再到了邏輯執行計劃，然後邏輯執行計劃優化，再到物理執行計劃，再到物理執行計劃的優化，最終生成你對應框架的作業，有可能是mapreduce作業，可能是spark作業，提交到對應的集羣上運行就可以了。
Presto prestodb.io
Presto支持標準的ANSI SQL，包括複雜查詢、聚合（aggregation）、連接（join）和窗口函數（window functions)。作爲Hive和Pig（Hive和Pig都是通過MapReduce的管道流來完成HDFS數據的查詢）的替代者，Presto 本身並不存儲數據，但是可以接入多種數據源，並且支持跨數據源的級聯查詢。
Presto沒有使用MapReduce，它是通過一個定製的查詢和執行引擎來完成的。它的所有的查詢處理是在內存中，這也是它的性能很高的一個主要原因。Presto和Spark SQL有很大的相似性，這是它區別於Hive的最根本的區別。
Presto由於是基於內存的，而 Hive 是在磁盤上讀寫的，因此 presto 比hive快很多，但是由於是基於內存的計算當多張大表關聯操作時易引起內存溢出錯誤。
Apache Kylin™ kylin.apache.org/cn
Apache Kylin™是一個開源的、分佈式的分析型數據倉庫，提供Hadoop/Spark 之上的 SQL 查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由 eBay 開發並貢獻至開源社區。它能在亞秒內查詢巨大的表。
Kylin 提供與多種數據可視化工具的整合能力，如 Tableau，PowerBI 等，令用戶可以使用 BI 工具對 Hadoop 數據進行分析。
簡單的講解一下上面的架構圖，以Hive或者Kafka作爲數據源，裏面保存着真實表，而Kylin做的就是將數據進行抽象，通過引擎實現Cube的構建。將Hbase作爲數據的倉庫，存放Cube。因爲Hbase的直接讀取比較複雜，所以Kylin提供了近似SQL和HQL的形式，滿足了數據讀取的基本需求。對外提供了RestApi和JDBC/ODBC方便操作。
Kylin自身就是一個MOLAP系統，多維立方體（MOLAP Cube）的設計使得用戶能夠在Kylin裏爲百億以上數據集定義數據模型並構建立方體進行數據的預聚合。立方體的設計，我的理解是就是以空間換時間，通過定義一系列的緯度，對每個緯度的組合進行預先計算並存儲。有N個緯度，就會有2的N次種組合。所以最好事先控制好緯度的數量，因爲存儲量會隨着緯度的增加爆炸式的增長，產生災難性後果。
Impala impala.apache.org
Impala 是 Cloudera 公司推出，提供對 HDFS、Hbase 數據的高性能、低延遲的交互式 SQL 查詢功能。Impala 使用 Hive的元數據, 完全在內存中計算。是CDH 平臺首選的 PB 級大數據實時查詢分析引擎。
執行流程
1、基於內存進行計算，能夠對PB級數據進行交互式實時查詢、分析
2、無需轉換爲MR，直接讀取HDFS及Hbase數據 ,從而大大降低了延遲。
Impala沒有MapReduce批處理，而是通過使用與商用並行關係數據庫中類似的分佈式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成
3、C++編寫，LLVM統一編譯運行
在底層對硬件進行優化， LLVM：編譯器，比較穩定，效率高
4、兼容HiveSQL
支持hive基本的一些查詢等，hive中的一些複雜結構是不支持的
5、具有數據倉庫的特性，可對hive數據直接做數據分析
6、支持Data Local
數據本地化：無需數據移動，減少數據的傳輸
7、支持列式存儲
可以和Hbase整合：因爲Hive可以和Hbasez整合
8、支持JDBC/ODBC遠程訪問
Impala劣勢
1、對內存依賴大
只在內存中計算，官方建議128G(一般64G基本滿足)，可優化: 各個節點彙總的節點(服務器)內存選用大的，不彙總節點可小點
2、C++編寫 開源 ？
對於java, C++可能不是很瞭解
3、完全依賴hive
4、實踐過程中分區超過1w 性能嚴重下下降
定期刪除沒有必要的分區，保證分區的個數不要太大
5、穩定性不如hive
因完全在內存中計算，內存不夠，會出現問題, hive內存不夠，可使用外存
Impala不提供任何對序列化和反序列化的支持。
Impala只能讀取文本文件，而不能讀取自定義二進制文件。
每當新的記錄/文件被添加到HDFS中的數據目錄時，該表需要被刷新。
Druid druid.apache.org
說起 Druid，大家首先想到的是阿里的 Druid 數據庫連接池，而本文介紹的 Druid 是一個在大數據場景下的解決方案，是需要在複雜的海量數據下進行交互式實時數據展現的 BI/OLAP 工具。
Druid 的架構是 Lambda 架構，分成實時層( Overlord、 MiddleManager )和批處理層( Broker 和 Historical )。
更多關於架構的描述，可以看官方文檔或者 《Druid在有讚的實踐》
目前 Druid 廣泛應用在國內外各個公司，比如阿里，滴滴，知乎，360，eBay，Hulu 等。Druid 之所以能夠在 OLAP 家族中佔據一席之地，主要依賴其強大的 MPP 架構設計。初次之外，它還運用到了四點重要的技術，分別是：預聚合、列式存儲、字典編碼、位圖索引。
常見的應用場景：（https://druid.apache.org/use-cases）
點擊流分析（網絡和移動分析）
風險/欺詐分析
網絡遙測分析（網絡性能監控）
服務器指標存儲
供應鏈分析（製造指標）
應用程序性能指標
商業智能/ OLAP
Druid的核心設計結合了數據倉庫，時間序列數據庫和搜索系統的思想，以創建一個統一的系統，用於針對各種用例的實時分析。Druid將這三個系統中每個系統的關鍵特徵合併到其接收層，存儲格式，查詢層和核心體系結構中。
（https://druid.apache.org/technology）
什麼樣的業務適合用 Druid?
建議如下：
時序化數據：Druid 可以理解爲時序數據庫，所有的數據必須有時間字段。
實時數據接入可容忍丟數據(tranquility)：目前 tranquility 有丟數據的風險，所以建議實時和離線一起用，實時接當天數據，離線第二天把今天的數據全部覆蓋，保證數據完備性。
OLAP 查詢而不是 OLTP 查詢：Druid 查詢併發有限，不適合 OLTP 查詢。
非精確的去重計算：目前 Druid 的去重都是非精確的。
無 Join 操作：Druid 適合處理星型模型的數據，不支持關聯操作。
數據沒有 update 更新操作，只對 segment 粒度進行覆蓋：由於時序化數據的特點，Druid 不支持數據的更新。
Clickhouse clickhouse.tech
Clickhouse 由俄羅斯 yandex 公司開發。專爲在線數據分析而設計。Yandex是俄羅斯搜索引擎公司。官方提供的文檔表名，ClickHouse 日處理記錄數"十億級"。
這個列式存儲數據庫的跑分要超過很多流行的商業MPP數據庫軟件，例如Vertica。
特性：
1.真正的面向列的DBMS
2.數據壓縮
3.磁盤存儲的數據
覽量和會話。
4.多核並行處理
5.在多個服務器上分佈式處理
6.SQL支持
7.向量化引擎
8.實時數據更新
9.索引
10.支持在線查詢
11.支持近似計算
12.數據複製和對數據完整性的支持。
使用ClickHouse也有其本身的限制，包括：
缺少高頻率，低延遲的修改或刪除已存在數據的能力。僅能用於批量刪除或修改數據。
沒有完整的事務支持
不支持二級索引
有限的SQL支持，join實現與衆不同
不支持窗口功能
元數據管理需要人工干預維護
目前還沒有一個OLAP系統能夠滿足各種場景的查詢需求。其本質原因是，沒有一個系統能同時在數據量、性能、和靈活性三個方面做到完美，每個系統在設計時都需要在這三者間做出取捨。
參考
https://xie.infoq.cn/article/77ec0d231d36c963a8e6d1630
https://www.jianshu.com/p/26c18e6a30c3
https://www.jianshu.com/p/4d0e0b42a3b0
https://www.jianshu.com/p/257ff24db397
https://www.cnblogs.com/tgzhu/p/6033373.html
https://zhuanlan.zhihu.com/p/29385628
https://blog.csdn.net/yongshenghuang/article/details/84925941https://www.jianshu.com/p/b5c85cadb362
https://clickhouse.yandex/docs/zh/development/architecture/
http://www.clickhouse.com.cn
https://www.jianshu.com/p/a5bf490247ea
https://blog.csdn.net/weixin_34273481/article/details/89238947
https://blog.csdn.net/warren288/article/details/80629909
更多大數據文章，歡迎關注我。
-
2020 年 Flink 最佳學習路線，學習的路上，你，並不孤單
-
Apache Flink OLAP引擎性能優化及應用
-
【乾貨】趣頭條基於 Flink+ClickHouse 構建實時數據分析平臺
-
來了來了，2020 首場 Meetup ，可！
-
本地Spark連接遠程集羣Hive(Scala/Python)Spark 性能優化指南(官網文檔)
關注我，帶你不同角度看數據架構
