你須要的不是實時數倉 | 你須要的是一款強大的OLAP數據庫(下)

在上一章節中，咱們講到實時數倉的建設，互聯網大數據技術發展到今天，各個領域基本已經成熟，有各式各樣的解決方案能夠供咱們選擇。

在實時數倉建設中，解決方案成熟，消息隊列Kafka、Redis、Hbase鮮有敵手，幾乎已成壟斷之勢。而OLAP的選擇則制約整個實時數倉的能力。開源盛世的今天，能夠供咱們選擇和使用的OLAP數據庫使人眼花繚亂，這章咱們選取了幾個最經常使用的OLAP開源數據引擎進行分析，但願能給正在作技術選型和將來架構升級的你提供一些幫助。

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

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.orghttps://blog.csdn.net/wzy0623/article/details/55047696https://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倍）。原文連接：https://blog.csdn.net/wzy0623/article/details/71479539

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/

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 自己並不存儲數據，可是能夠接入多種數據源，而且支持跨數據源的級聯查詢。

https://blog.csdn.net/u012535605/article/details/83857079Presto沒有使用MapReduce，它是經過一個定製的查詢和執行引擎來完成的。它的全部的查詢處理是在內存中，這也是它的性能很高的一個主要緣由。Presto和Spark SQL有很大的類似性，這是它區別於Hive的最根本的區別。

但Presto因爲是基於內存的，而hive是在磁盤上讀寫的，所以presto比hive快不少，可是因爲是基於內存的計算當多張大表關聯操做時易引發內存溢出錯誤。

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

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、Bzip二、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/84925941https://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系統可以知足各類場景的查詢需求。其本質緣由是，沒有一個系統能同時在數據量、性能、和靈活性三個方面作到完美，每一個系統在設計時都須要在這三者間作出取捨。

歡迎掃碼關注個人公衆號，回覆【JAVAPDF】能夠得到一份200頁秋招面試題！