OLAP開源引擎

本文源自：https://cloud.tencent.com/developer/article/1506782

OLAP開源引擎

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

組件特點和簡介

Hive

https://hive.apache.org/

Hive是基於Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射爲一張數據庫表，並提供完整的sql查詢功能，可以將sql語句轉換爲MapReduce任務進行運行。其優點是學習成本低，可以通過類SQL語句快速實現簡單的MapReduce統計，不必開發專門的MapReduce應用，十分適合數據倉庫的統計分析。

正在上傳…重新上傳取消

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

Hive的優勢是完善的SQL支持，極低的學習成本，自定義數據格式，極高的擴展性可輕鬆擴展到幾千個節點等等。

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

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

Hawq

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

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

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

正在上傳…重新上傳取消

正在上傳…重新上傳取消

網絡上有人對Hawq與Hive查詢性能進行了對比測試，總體來看，使用Hawq內部表比Hive快的多（4-50倍）。

Spark SQL

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

SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成,可以將結構化數據作爲 Spark 的 RDD 進行查詢。SparkSQL作爲Spark生態的一員繼續發展，而不再受限於Hive，只是兼容Hive。

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

轉存失敗重新上傳取消

SparkSQL的架構圖如下：

轉存失敗重新上傳取消

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

Presto

https://prestodb.github.io/

https://blog.csdn.net/u012535605/article/details/83857079

https://www.cnblogs.com/tgzhu/p/6033373.html

Presto is an open source distributed SQL query engine for running interactive analytic queries against data sources of all sizes ranging from gigabytes to petabytes.
Presto allows querying data where it lives, including Hive, Cassandra, relational databases or even proprietary data stores. A single Presto query can combine data from multiple sources, allowing for analytics across your entire organization.
Presto is targeted at analysts who expect response times ranging from sub-second to minutes. Presto breaks the false choice between having fast analytics using an expensive commercial solution or using a slow "free" solution that requires excessive hardware.

這是Presto官方的簡介。Presto 是由 Facebook 開源的大數據分佈式 SQL 查詢引擎，適用於交互式分析查詢，可支持衆多的數據源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口開發數據源連接器。

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

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

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

轉存失敗重新上傳取消

Kylin

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

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

• 傳統OLAP根據數據存儲方式的不同分爲ROLAP（relational olap）以及MOLAP（multi-dimension olap）
• ROLAP 以關係模型的方式存儲用作多爲分析用的數據，優點在於存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數據進行聚合計算，爲了改善短板，ROLAP使用了列存、並行查詢、查詢優化、位圖索引等技術。
• MOLAP 將分析用的數據物理上存儲爲多維數組的形式，形成CUBE結構。維度的屬性值映射成多維數組的下標或者下標範圍，事實以多維數組的值存儲在數組單元中，優勢是查詢快速，缺點是數據量不容易控制，可能會出現維度爆炸的問題。

而Kylin自身就是一個MOLAP系統，多維立方體（MOLAP Cube）的設計使得用戶能夠在Kylin裏爲百億以上數據集定義數據模型並構建立方體進行數據的預聚合。

Apache Kylin™是一個開源的分佈式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由eBay Inc. 開發並貢獻至開源社區。它能在亞秒內查詢巨大的Hive表。

轉存失敗重新上傳取消

Kylin的優勢有：

• 提供ANSI-SQL接口
• 交互式查詢能力
• MOLAP Cube 的概念
• 與BI工具可無縫整合

所以適合Kylin的場景包括：

• 用戶數據存在於Hadoop HDFS中，利用Hive將HDFS文件數據以關係數據方式存取，數據量巨大，在500G以上
• 每天有數G甚至數十G的數據增量導入
• 有10個以內較爲固定的分析維度

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

Impala

https://impala.apache.org/

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

Impala的架構圖如下：

轉存失敗重新上傳取消

Impala的特性包括：

• 支持Parquet、Avro、Text、RCFile、SequenceFile等多種文件格式
• 支持存儲在HDFS、HBase、Amazon S3上的數據操作
• 支持多種壓縮編碼方式：Snappy、Gzip、Deflate、Bzip2、LZO
• 支持UDF和UDAF
• 自動以最有效的順序進行表連接
• 允許定義查詢的優先級排隊策略
• 支持多用戶併發查詢
• 支持數據緩存
• 提供計算統計信息（COMPUTE STATS）
• 提供窗口函數（聚合 OVER PARTITION, RANK, LEAD, LAG, NTILE等等）以支持高級分析功能
• 支持使用磁盤進行連接和聚合，當操作使用的內存溢出時轉爲磁盤操作
• 允許在where子句中使用子查詢
• 允許增量統計——只在新數據或改變的數據上執行統計計算
• 支持maps、structs、arrays上的複雜嵌套查詢
• 可以使用impala插入或更新HBase

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

• Impala不提供任何對序列化和反序列化的支持。
• Impala只能讀取文本文件，而不能讀取自定義二進制文件。
• 每當新的記錄/文件被添加到HDFS中的數據目錄時，該表需要被刷新。這個缺點會導致正在執行的查詢sql遇到刷新會掛起，查詢不動。

Druid

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

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

Druid解決的問題包括：數據的快速攝入和數據的快速查詢。 所以要理解Druid，需要將其理解爲兩個系統，即輸入系統和查詢系統。

Druid的架構如下：

轉存失敗重新上傳取消

轉存失敗重新上傳取消

Druid的特點包括：

• Druid實時的數據消費，真正做到數據攝入實時、查詢結果實時
• Druid支持 PB 級數據、千億級事件快速處理，支持每秒數千查詢併發
• Druid的核心是時間序列，把數據按照時間序列分批存儲，十分適合用於對按時間進行統計分析的場景
• Druid把數據列分爲三類：時間戳、維度列、指標列
• Druid不支持多表連接
• Druid中的數據一般是使用其他計算框架(Spark等)預計算好的低層次統計數據
• Druid不適合用於處理透視維度複雜多變的查詢場景
• Druid擅長的查詢類型比較單一，一些常用的SQL(groupby 等)語句在druid裏運行速度一般
• Druid支持低延時的數據插入、更新，但是比hbase、傳統數據庫要慢很多

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

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

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

Greeplum

https://greenplum.org/

https://blog.csdn.net/yongshenghuang/article/details/84925941

https://www.jianshu.com/p/b5c85cadb362

Greenplum是一個開源的大規模並行數據分析引擎。藉助MPP架構，在大型數據集上執行復雜SQL分析的速度比很多解決方案都要快。

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

GreenPulm的架構如下：

轉存失敗重新上傳取消

GreenPulm的技術特點如下：

• 支持海量數據存儲和處理
• 支持Just In Time BI：通過準實時、實時的數據加載方式，實現數據倉庫的實時更新，進而實現動態數據倉庫（ADW），基於動態數據倉庫，業務用戶能對當前業務數據進行BI實時分析（Just In Time BI）
• 支持主流的sql語法，使用起來十分方便，學習成本低
• 擴展性好，支持多語言的自定義函數和自定義類型等
• 提供了大量的維護工具，使用維護起來很方便
• 支持線性擴展：採用MPP並行處理架構。在MPP結構中增加節點就可以線性提供系統的存儲容量和處理能力
• 較好的併發支持及高可用性支持除了提供硬件級的Raid技術外，還提供數據庫層Mirror機制保護，提供Master/Stand by機制進行主節點容錯，當主節點發生錯誤時，可以切換到Stand by節點繼續服務
• 支持MapReduce
• 數據庫內部壓縮

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

ClickHouse

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

官網對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公司開發。專爲在線數據分析而設計。Yandex是俄羅斯搜索引擎公司。官方提供的文檔表名，ClickHouse 日處理記錄數"十億級"。

特性:採用列式存儲；數據壓縮；支持分片，並且同一個計算任務會在不同分片上並行執行，計算完成後會將結果彙總；支持SQL；支持聯表查詢；支持實時更新；自動多副本同步；支持索引；分佈式存儲查詢。

大家對Nginx不陌生吧，戰鬥民族開源的軟件普遍的特點：輕量級，快快快。

ClickHouse最大的特點就是快，快，快，重要的話說三遍！

與Hadoop、Spark這些巨無霸組件相比，ClickHouse很輕量級，其特點：

• 列式存儲數據庫，數據壓縮
• 關係型、支持SQL
• 分佈式並行計算，把單機性能壓榨到極限
• 高可用
• 數據量級在PB級別
• 實時數據更新
• 索引

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

• 缺少高頻率，低延遲的修改或刪除已存在數據的能力。僅能用於批量刪除或修改數據。
• 沒有完整的事務支持
• 不支持二級索引
• 有限的SQL支持，join實現與衆不同
• 不支持窗口功能
• 元數據管理需要人工干預維護

總結

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

• Hive，Hawq，Impala - 基於SQL on Hadoop
• Presto和Spark SQL類似 - 基於內存解析SQL生成執行計劃
• Kylin - 用空間換時間，預計算
• Druid - 一個支持數據的實時攝入
• ClickHouse - OLAP領域的Hbase，單表查詢性能優勢巨大
• Greenpulm - OLAP領域的Postgresql

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

就像美團在調研Kylin的報告中所說的：

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