你需要的不是實時數倉 | 你需要的是一款強大的OLAP資料庫(下)

• 2019 年 10 月 4 日
• 筆記

本文版權個人所有，未經作者本人允許不得轉載。

前言

在上一章節《你需要的不是實時數倉 | 你需要的是一款強大的OLAP資料庫(上)》，我們講到實時數倉的建設，互聯網大數據技術發展到今天，各個領域基本已經成熟，有各式各樣的解決方案可以供我們選擇。

在實時數倉建設中，解決方案成熟，消息隊列Kafka、Redis、Hbase鮮有敵手，幾乎已成壟斷之勢。而OLAP的選擇則制約整個實時數倉的能力。

開源盛世的今天，可以供我們選擇和使用的OLAP資料庫令人眼花繚亂，這章我們選取了幾個最常用的OLAP開源數據引擎進行分析，希望能給正在做技術選型和未來架構升級的你提供一些幫助。

本文給出了常用的開源OLAP引擎的性能測評： https://blog.csdn.net/oDaiLiDong/article/details/86570211

阿里巴巴F4 · A band鎮貼

OLAP百家爭鳴

OLAP簡介

OLAP，也叫聯機分析處理（Online Analytical Processing）系統，有的時候也叫DSS決策支援系統，就是我們說的數據倉庫。與此相對的是OLTP（on-line transaction processing）聯機事務處理系統。

聯機分析處理 (OLAP) 的概念最早是由關係資料庫之父E.F.Codd於1993年提出的。OLAP的提出引起了很大的反響，OLAP作為一類產品同聯機事務處理 (OLTP) 明顯區分開來。

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

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

OLAP的準則和特性

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

• 準則1 OLAP模型必須提供多維概念視圖
• 準則2 透明性準則
• 準則3 存取能力準則
• 準則4 穩定的報表能力
• 準則5 客戶/伺服器體系結構
• 準則6 維的等同性準則
• 準則7 動態的稀疏矩陣處理準則
• 準則8 多用戶支援能力準則
• 準則9 非受限的跨維操作
• 準則10 直觀的數據操縱
• 準則11 靈活的報表生成
• 準則12 不受限的維與聚集層次

一言以蔽之：

OLTP系統強調資料庫記憶體效率，強調記憶體各種指標的命令率，強調綁定變數，強調並發操作，強調事務性； OLAP系統則強調數據分析，強調SQL執行時長，強調磁碟I/O，強調分區。

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