開源大數(shù)據(jù)OLAP組件，可以分為MOLAP和ROLAP兩類。ROLAP中又可細(xì)分為MPP數(shù)據(jù)庫和SQL引擎兩類。對于SQL引擎又可以再細(xì)分為基于MPP架構(gòu)的SQL引擎和基于通用計(jì)算框架的SQL引擎：
MOLAP一般對數(shù)據(jù)存儲有優(yōu)化，并且進(jìn)行部分預(yù)計(jì)算，因此查詢性能最高。但通常對查詢靈活性有限制。
MPP數(shù)據(jù)庫是個(gè)完整的數(shù)據(jù)庫，通常數(shù)據(jù)需要導(dǎo)入其中才能完成OLAP功能。MPP數(shù)據(jù)庫在數(shù)據(jù)入庫時(shí)對數(shù)據(jù)分布可以做優(yōu)化，雖然入庫效率有一定下降，但是對后期查詢性能的提高有很大幫助。MPP數(shù)據(jù)庫可以提供靈活的即席查詢能力，但一般對查詢數(shù)據(jù)量有一定限制，無法支撐特別大的數(shù)據(jù)量的查詢。
SQL引擎只提供SQL執(zhí)行的能力，本身一般不負(fù)責(zé)數(shù)據(jù)存儲，通?？梢詫佣喾N數(shù)據(jù)儲存，如HDFS、HBase、MySQL等。有的還支持聯(lián)邦查詢能力，可以對多個(gè)異構(gòu)數(shù)據(jù)源進(jìn)行聯(lián)合分析。SQL引擎中，基于MPP架構(gòu)的SQL引擎，一般對在線查詢場景有特殊優(yōu)化，所以端到端查詢性能一般要高于基于通用計(jì)算框架的SQL引擎；但是在容錯(cuò)性和數(shù)據(jù)量方面又會遜于基于通用計(jì)算框架的SQL引擎。
總之，可以說沒有一個(gè)OLAP系統(tǒng)能同時(shí)在處理規(guī)模，靈活性和性能這三個(gè)方面做到完美，用戶需要基于自己的需求進(jìn)行取舍和選型。
2.1 開源MOLAP系統(tǒng)分析
2.1.1 Kylin
Apache Kylin 是一個(gè)開源的分布式分析引擎，提供 Hadoop/Spark 之上的 SQL 查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，它能在亞秒內(nèi)查詢巨大的 Hive 表。Kylin的核心思想是預(yù)計(jì)算，理論基礎(chǔ)是：以空間換時(shí)間。即將多維分析可能用到的度量進(jìn)行預(yù)計(jì)算，將計(jì)算好的結(jié)果保存成Cube并存儲到HBase中，供查詢時(shí)直接訪問。把高復(fù)雜度的聚合運(yùn)算，多表連接等操作轉(zhuǎn)換成對預(yù)計(jì)算結(jié)果的查詢。
Kylin的核心模塊：
REST Server：提供 Restful 接口，例如創(chuàng)建、構(gòu)建、刷新、合并等 Cube 相關(guān)操作，Kylin 的 Projects、Tables 等元數(shù)據(jù)管理，用戶訪問權(quán)限控制，SQL 的查詢等；
Query Engine：使用開源的 Apache Calcite 框架來實(shí)現(xiàn) SQL 解析，可以理解為 SQL 引擎層；
Routing：負(fù)責(zé)將解析 SQL 生成的執(zhí)行計(jì)劃轉(zhuǎn)換成 Cube 緩存的查詢，這部分查詢是可以在秒級甚至毫秒級完成；
Metadata：Kylin 中有大量的元數(shù)據(jù)信息，包括 Cube 的定義、星型模型的定義、Job 和執(zhí)行 Job 的輸出信息、模型的維度信息等等，Kylin 的元數(shù)據(jù)和 Cube 都存儲在 HBase 中，存儲的格式是 json 字符串；
Cube Build Engine：所有模塊的基礎(chǔ)，它主要負(fù)責(zé) Kylin 預(yù)計(jì)算中創(chuàng)建 Cube，創(chuàng)建的過程是首先通過 Hive 讀取原始數(shù)據(jù)，然后通過一些 MapReduce 或 Spark 計(jì)算生成 Htable，最后將數(shù)據(jù) load 到 HBase 表中。
整個(gè)系統(tǒng)分為兩部分：
-
離線構(gòu)建：
數(shù)據(jù)源在左側(cè)，目前主要是 Hadoop Hive，保存著待分析的用戶數(shù)據(jù)；
根據(jù)元數(shù)據(jù)的定義，下方構(gòu)建引擎從數(shù)據(jù)源抽取數(shù)據(jù)，并構(gòu)建 Cube；
數(shù)據(jù)以關(guān)系表的形式輸入，支持星形模型和雪花模型；
2.5 開始 Spark 是主要的構(gòu)建技術(shù)（以前是MapReduce）；
構(gòu)建后的 Cube 保存在右側(cè)的存儲引擎中，一般選用 HBase 作為存儲。
-
在線查詢
用戶可以從上方查詢系統(tǒng)（Rest API、JDBC/ODBC）發(fā)送 SQL 進(jìn)行查詢分析；
無論從哪個(gè)接口進(jìn)入，SQL 最終都會來到 Rest 服務(wù)層，再轉(zhuǎn)交給查詢引擎進(jìn)行處理；
查詢引擎解析 SQL，生成基于關(guān)系表的邏輯執(zhí)行計(jì)劃；
然后將其轉(zhuǎn)譯為基于 Cube 的物理執(zhí)行計(jì)劃；
最后查詢預(yù)計(jì)算生成的 Cube 并產(chǎn)生結(jié)果。
- 優(yōu)點(diǎn)：
亞秒級查詢響應(yīng)；
支持百億、千億甚至萬億級別交互式分析；
無縫與 BI 工具集成；
支持增量刷新；
- 缺點(diǎn)：
由于 Kylin 是一個(gè)分析引擎，只讀，不支持 insert, update, delete 等 SQL 操作，用戶修改數(shù)據(jù)的話需要重新批量導(dǎo)入（構(gòu)建）；
需要預(yù)先建立模型后加載數(shù)據(jù)到 Cube 后才可進(jìn)行查詢
使用 Kylin 的建模人員需要了解一定的數(shù)據(jù)倉庫知識。
2.1.2 Druid
Apache Druid是高性能的實(shí)時(shí)分析數(shù)據(jù)庫，主要提供對大量的基于時(shí)序的數(shù)據(jù)進(jìn)行OLAP查詢能力。支持毫秒級的快速的交互式查詢。
Druid有幾種進(jìn)程類型，簡要描述如下：
Coordinators協(xié)調(diào)器進(jìn)程：負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)服務(wù)器上的Historicals進(jìn)程，將Segments分配給特定的服務(wù)器，并負(fù)責(zé)確保Segments在多個(gè)Historicals之間保持平衡。
Overlords進(jìn)程：負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)服務(wù)器上的MiddleManager進(jìn)程，并控制數(shù)據(jù)獲取任務(wù)的分配。
Broker代理進(jìn)程：處理來自外部客戶端的查詢，將查詢轉(zhuǎn)發(fā)給數(shù)據(jù)服務(wù)器去執(zhí)行，并合并來自多個(gè)數(shù)據(jù)服務(wù)器的結(jié)果，返回給最終用戶。
Routers進(jìn)程：是個(gè)可選進(jìn)程，提供統(tǒng)一的API Gateway，可以將請求路由到Brokers、Overlords和Coordinators。
Historicals進(jìn)程：負(fù)責(zé)處理“歷史數(shù)據(jù)”的查詢。 它會從Deep Storage下載查詢需要的Segments以加速查詢。它不負(fù)責(zé)寫入。
MiddleManager進(jìn)程：負(fù)責(zé)處理獲取到新數(shù)據(jù)，從外部數(shù)據(jù)源讀取數(shù)據(jù)并轉(zhuǎn)換成Segments進(jìn)行存儲。
Druid進(jìn)程可以按照任何方式進(jìn)行部署，但是為了易于部署，一般建議將它們組織為三種服務(wù)器類型：
主服務(wù)器：運(yùn)行Coordinatos和Overlords進(jìn)程，負(fù)責(zé)管理數(shù)據(jù)獲取和數(shù)據(jù)可用性。
查詢服務(wù)器：運(yùn)行Brokers和可選的Routers進(jìn)程，處理來自外部客戶端的查詢。
數(shù)據(jù)服務(wù)器：運(yùn)行Historicals和MiddleManagers進(jìn)程，負(fù)責(zé)執(zhí)行數(shù)據(jù)獲取任務(wù)并存儲所有可查詢的數(shù)據(jù)。
Druid之所以查詢?nèi)绱酥欤c它針對多維數(shù)據(jù)優(yōu)化的組織和存儲方式有很大關(guān)系。它將數(shù)據(jù)索引存儲在Segments文件中，Segment文件按列來存儲，并通過時(shí)間分區(qū)來進(jìn)行橫向分割。Druid將數(shù)據(jù)列分為了三種不同的類型：
對于時(shí)間列和指標(biāo)列處理比較簡單，直接用lz4壓縮存儲。一旦查詢知道去找哪幾行，只需要將它們解壓，然后用相應(yīng)的操作符來操作它們就可以了。
-
對于維度列就沒那么簡單了，因?yàn)樗鼈冃枰С诌^濾和聚合操作，因此每個(gè)維度需要下面三個(gè)數(shù)據(jù)結(jié)構(gòu)：
(1) 一個(gè)map，Key是維度的值，值是一個(gè)整型的id
(2) 一個(gè)存儲列的值得列表，用(1)中的map編碼的list
(3) 對于列中的每個(gè)值對應(yīng)一個(gè)bitmap，這個(gè)bitmap用來指示哪些行包含這個(gè)個(gè)值。
1: 字典
{
"Justin BIeber": 0,
"Ke$ha": 1
}
2. 值的列表
[0,
0,
1,
1]
3. bitMap
value="Justin Bieber": [1, 1, 0, 0]
value="Ke$ha": [0, 0, 1, 1]
為什么要使用這三個(gè)數(shù)據(jù)結(jié)構(gòu)？ map將字符串值映射為整數(shù)id，以便可以緊湊地表示（2）和（3）中的值。 （3）中的bitmap（也被稱為倒排索引）允許快速過濾操作（特別地，bitmap便于快速進(jìn)行AND和OR運(yùn)算），這樣，對于過濾再聚合的場景，無需訪問（2）中的維度值列表。最后，（2）中的值可以被用來支持group by和TopN查詢。
- 優(yōu)點(diǎn)：
為分析而設(shè)計(jì)：為OLAP工作流的探索性分析而構(gòu)建。它支持各種filter、aggregator和查詢類型。
交互式查詢：低延遲數(shù)據(jù)攝取架構(gòu)允許事件在它們創(chuàng)建后毫秒內(nèi)查詢。
高可用：你的數(shù)據(jù)在系統(tǒng)更新時(shí)依然可用、可查詢。規(guī)模的擴(kuò)大和縮小不會造成數(shù)據(jù)丟失。
可伸縮：每天處理數(shù)十億事件和TB級數(shù)據(jù)。
- 缺點(diǎn)：
不支持更新操作，數(shù)據(jù)不可更改
不支持事實(shí)表之間的關(guān)聯(lián)
2.2 開源MPP數(shù)據(jù)庫分析
2.2.1 Greenplum
GreenPlum是基于PostgreSQL的開源MPP數(shù)據(jù)庫，具有良好的線性擴(kuò)展能力，具有高效的并行運(yùn)算和并行存儲特性。
Greenplum的系統(tǒng)架構(gòu)實(shí)際上是多臺PostgreSQL數(shù)據(jù)庫服務(wù)器組成的矩陣，采用無共享(no shareing)的MPP架構(gòu)：
Master節(jié)點(diǎn)：作為數(shù)據(jù)庫的入口，負(fù)責(zé)客服端連接；對客服端的請求生成查詢計(jì)劃，分發(fā)給某個(gè)或者所有的Segment節(jié)點(diǎn)。
Standby節(jié)點(diǎn) : 作為master節(jié)點(diǎn)的備庫，提供高可用性。
Interconnect：是GreenPlum的網(wǎng)絡(luò)層；負(fù)責(zé)每個(gè)節(jié)點(diǎn)之間的通信。
Segment節(jié)點(diǎn)：為數(shù)據(jù)節(jié)點(diǎn)；接收master分發(fā)下來的查詢計(jì)劃；執(zhí)行返回結(jié)果給master節(jié)點(diǎn)。
Mirror Segment節(jié)點(diǎn)： 作為Segment節(jié)點(diǎn)的備庫，提供高可用性；通常跟對應(yīng)的segment節(jié)點(diǎn)不在同一臺機(jī)器上。
- 優(yōu)點(diǎn)：
支持多態(tài)數(shù)據(jù)存儲，允許用戶根據(jù)應(yīng)用定義數(shù)據(jù)分布方式，可提高查詢性能。
具有高效的SQL優(yōu)化器，針對OLAP查詢進(jìn)行優(yōu)化。
- 缺點(diǎn)：
存在“木桶效應(yīng)”，單機(jī)故障會導(dǎo)致性能嚴(yán)重下降，因此集群規(guī)模不能太大。
并發(fā)性能不高，通常無法支持超過30個(gè)并發(fā)。
2.2.2 ClickHouse
ClickHouse是Yandex（號稱俄羅斯的‘百度’）開源的MPP架構(gòu)的列式存儲數(shù)據(jù)庫。
目前ClickHouse公開的資料相對匱乏，比如在架構(gòu)設(shè)計(jì)層面就很難找到完整的資料，甚至連一張整體的架構(gòu)圖都沒有。
- ClickHouse為什么性能這么好？
著眼硬件?；趯⒂布πё畲蠡哪康?，ClickHouse會在內(nèi)存中進(jìn)行GROUP BY；與此同時(shí)，他們非常在意CPU L3級別的緩存，因?yàn)橐淮蜭3的緩存失效會帶來70～100ns的延遲，意味著在單核CPU上，它會浪費(fèi)4000萬次/秒的運(yùn)算。正因?yàn)樽⒁饬诉@些細(xì)節(jié)，所以ClickHouse在基準(zhǔn)查詢中能做到1.75億次/秒的數(shù)據(jù)掃描性能。
注重算法。例如，在字符串搜索方面，針對不同的場景，ClickHouse選擇了多種算法：對于常量，使用Volnitsky算法；對于非常量，使用CPU的向量化執(zhí)行SIMD，暴力優(yōu)化；正則匹配使用re2和hyperscan算法。除了字符串之外，其余的場景也與它類似，ClickHouse會使用最合適、最快的算法。如果世面上出現(xiàn)了號稱性能強(qiáng)大的新算法，ClickHouse團(tuán)隊(duì)會立即將其納入并進(jìn)行驗(yàn)證。
特定場景，特殊優(yōu)化。針對同一個(gè)場景的不同狀況，選擇使用不同的實(shí)現(xiàn)方式，盡可能將性能最大化。對于數(shù)據(jù)結(jié)構(gòu)比較清晰的場景，會通過代碼生成技術(shù)實(shí)現(xiàn)循環(huán)展開，以減少循環(huán)次數(shù)。
向量化執(zhí)行。SIMD被廣泛地應(yīng)用于文本轉(zhuǎn)換、數(shù)據(jù)過濾、數(shù)據(jù)解壓和JSON轉(zhuǎn)換等場景。相較于單純地使用CPU，利用寄存器暴力優(yōu)化也算是一種降維打擊了。
- 優(yōu)點(diǎn)：
- 速度快
- 缺點(diǎn)：
不支持事務(wù)，不支持真正的刪除/更新；
不支持高并發(fā)，Clickhouse快是因?yàn)椴捎昧瞬⑿刑幚頇C(jī)制，即使一個(gè)查詢，也會用服務(wù)器一半的CPU去執(zhí)行。
join性能不高
開源社區(qū)主要是俄語為主.
2.3 基于MPP架構(gòu)的SQL引擎分析
2.3.1 Presto
Presto是Facebook推出分布式SQL交互式查詢引擎，完全基于內(nèi)存的并行計(jì)算，支持任意數(shù)據(jù)源，數(shù)據(jù)規(guī)模GB~PB。
Presto采用典型的Master-Slave架構(gòu)：
coordinator：是presto集群的master節(jié)點(diǎn)。負(fù)責(zé)解析SQL語句，生成執(zhí)行計(jì)劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點(diǎn)執(zhí)行。
worker：是執(zhí)行任務(wù)的節(jié)點(diǎn)。負(fù)責(zé)實(shí)際查詢?nèi)蝿?wù)的計(jì)算和讀寫。
discovery service：是將coordinator和worker結(jié)合在一起服務(wù)。worker節(jié)點(diǎn)啟動后向discovery service服務(wù)注冊，coordinator通過discovery service獲取注冊的worker節(jié)點(diǎn)。
-
connector：presto以插件形式對數(shù)據(jù)存儲層進(jìn)行了抽象，即connector?？赏ㄟ^connector連接多種數(shù)據(jù)源，提取數(shù)據(jù)。
discovery service 將coordinator和worker結(jié)合在一起服務(wù)； worker節(jié)點(diǎn)啟動后向discovery service服務(wù)注冊 coordinator通過discovery service獲取注冊的worker節(jié)點(diǎn)
既然Presto是一個(gè)交互式的查詢引擎，我們最關(guān)心的就是Presto實(shí)現(xiàn)低延時(shí)查詢的原理，我認(rèn)為主要是下面幾個(gè)關(guān)鍵點(diǎn)：
完全基于內(nèi)存的并行計(jì)算
流水線式計(jì)算作業(yè)
本地化計(jì)算
動態(tài)編譯執(zhí)行計(jì)劃
小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)
類BlinkDB的近似查詢
GC控制
-
與Hive的比較：
上圖顯示了MapReduce與Presto的執(zhí)行過程的不同點(diǎn)，MR每個(gè)操作要么需要寫磁盤，要么需要等待前一個(gè)stage全部完成才開始執(zhí)行，而Presto將SQL轉(zhuǎn)換為多個(gè)stage，每個(gè)stage又由多個(gè)tasks執(zhí)行，每個(gè)tasks又將分為多個(gè)split。所有的task是并行的方式進(jìn)行允許，stage之間數(shù)據(jù)是以pipeline形式流式的執(zhí)行，數(shù)據(jù)之間的傳輸也是通過網(wǎng)絡(luò)以Memory-to-Memory的形式進(jìn)行，沒有磁盤io操作。這也是Presto性能比Hive快很多倍的決定性原因。
-
與Spark的比較：
目標(biāo)：Presto強(qiáng)調(diào)查詢，但Spark重點(diǎn)強(qiáng)調(diào)計(jì)算。
架構(gòu)：Presto的體系結(jié)構(gòu)與MPP SQL引擎非常相似。這意味著僅針對SQL查詢執(zhí)行進(jìn)行了高度優(yōu)化，而Spark是一個(gè)通用執(zhí)行框架，能夠運(yùn)行多個(gè)不同的工作負(fù)載，如ETL，機(jī)器學(xué)習(xí)等。
任務(wù)啟動：Presto的查詢沒有太多開銷。Presto協(xié)調(diào)器始終處于啟動狀態(tài)并等待查詢。而Spark驅(qū)動程序啟動需要時(shí)間與集群管理器協(xié)商資源，復(fù)制jar，才開始處理。
任務(wù)提交：Spark提交任務(wù)并在每個(gè)階段實(shí)時(shí)應(yīng)用資源（與presto相比，這種策略可能導(dǎo)致處理速度稍慢）; Presto一次申請所需資源，并且一次提交所有任務(wù)。
數(shù)據(jù)處理：在spark中，數(shù)據(jù)需要在進(jìn)入下一階段之前完全處理。 Presto是流水線式處理模式。只要一個(gè)page完成處理，就可以將其發(fā)送到下一個(gè)task（這種方法大大減少了各種查詢的端到端響應(yīng)時(shí)間）。
內(nèi)存：兩者都是內(nèi)存存儲和計(jì)算，當(dāng)它無法獲得足夠的內(nèi)存時(shí)，spark會將數(shù)據(jù)寫入磁盤，但presto會導(dǎo)致OOM。
容錯(cuò)：如果Spark任務(wù)失敗或數(shù)據(jù)丟失，它將重新計(jì)算。但是presto會導(dǎo)致查詢失敗。
優(yōu)點(diǎn)：
基于內(nèi)存運(yùn)算，減少沒必要的硬盤IO，所以快。
都能夠處理PB級別的海量數(shù)據(jù)分析。（雖然能夠處理PB級別的海量數(shù)據(jù)分析，但不是代表Presto把PB級別都放在內(nèi)存中計(jì)算的。而是根據(jù)場景，如count，avg等聚合運(yùn)算，是邊讀數(shù)據(jù)邊計(jì)算，再清內(nèi)存，再讀數(shù)據(jù)再計(jì)算，這種耗的內(nèi)存并不高。）
能夠連接多個(gè)數(shù)據(jù)源，跨數(shù)據(jù)源關(guān)聯(lián)查詢。
清晰的架構(gòu)，是一個(gè)能夠獨(dú)立運(yùn)行的系統(tǒng)，不依賴于任何其他外部系統(tǒng)。部署簡單。
- 缺點(diǎn)：
不適合多個(gè)大表的join操作，因?yàn)閜resto是基于內(nèi)存的，太多數(shù)據(jù)內(nèi)存放不下的。
Presto的一個(gè)權(quán)衡是不關(guān)心中間查詢?nèi)蒎e(cuò)。如果其中一個(gè)Presto工作節(jié)點(diǎn)出現(xiàn)故障（例如，關(guān)閉），則大多數(shù)情況下正在進(jìn)行的查詢將中止并需要重新啟動。
2.3.2 HAWQ
HAWQ是Pivotal公司開源的一個(gè)Hadoop原生大規(guī)模并行SQL分析引擎，針對的是分析型應(yīng)用。Apache HAWQ 采用主從（Master-Slave）的改進(jìn)MPP架構(gòu)，通過將MPP與批處理系統(tǒng)有效的結(jié)合，克服了MPP的一些關(guān)鍵的限制問題，如短板效應(yīng)、并發(fā)限制、擴(kuò)展性等。其整體架構(gòu)與Pivotal另一開源MPP數(shù)據(jù)庫Greenplum比較相似：
HAWQ Master節(jié)點(diǎn)內(nèi)部有以下幾個(gè)重要組件：
查詢解析器（Parser/Analyzer），負(fù)責(zé)解析查詢，并檢查語法及語義。最終生成查詢樹傳遞給優(yōu)化器。
優(yōu)化器（Optimizer），負(fù)責(zé)接受查詢樹，生成查詢計(jì)劃。針對一個(gè)查詢，可能有數(shù)億個(gè)可能的等價(jià)的查詢計(jì)劃，但執(zhí)行性能差異很大。優(yōu)化器的做用是找出優(yōu)化的查詢計(jì)劃。
資源管理器（Resource Manager），資源管理器經(jīng)過資源代理向全局資源管理器（好比YARN）動態(tài)申請資源。并緩存資源。在不須要的時(shí)候返回資源。
HDFS元數(shù)據(jù)緩存（HDFS Catalog Cache），用于HAWQ確定哪些Segment掃描表的哪些部分。HAWQ是把計(jì)算派發(fā)到數(shù)據(jù)所在的地方。因此要匹配計(jì)算和數(shù)據(jù)的局部性。如果每一個(gè)查詢都訪問HDFS NameNode會形成NameNode的瓶頸。因此在HAWQ Master節(jié)點(diǎn)上創(chuàng)建了HDFS元數(shù)據(jù)緩存。
容錯(cuò)服務(wù)（Fault Tolerance Service），負(fù)責(zé)檢測哪些節(jié)點(diǎn)可用，哪些節(jié)點(diǎn)不可用。不可用的機(jī)器會被排除出資源池。
查詢派遣器（Dispatcher），優(yōu)化器優(yōu)化完查詢之后，查詢派遣器派遣計(jì)劃到各個(gè)節(jié)點(diǎn)上執(zhí)行，并協(xié)調(diào)查詢執(zhí)行的整個(gè)過程。查詢派遣器是整個(gè)并行系統(tǒng)的粘合劑。
元數(shù)據(jù)服務(wù)（Catalog Service），負(fù)責(zé)存儲HAWQ的各類元數(shù)據(jù)，包括數(shù)據(jù)庫和表信息，以及訪問權(quán)限信息等。另外，元數(shù)據(jù)服務(wù)也是實(shí)現(xiàn)分布式事務(wù)的關(guān)鍵。
其余節(jié)點(diǎn)為Slave節(jié)點(diǎn)。每一個(gè)Slave節(jié)點(diǎn)上部署有HDFS DataNode，YARN NodeManager以及一個(gè)HAWQ Segment。HAWQ Segment在執(zhí)行查詢的時(shí)候會啟動多個(gè)QE (Query Executor, 查詢執(zhí)行器)。查詢執(zhí)行器運(yùn)行在資源容器里面。節(jié)點(diǎn)間數(shù)據(jù)交換經(jīng)過Interconnect（高速互聯(lián)網(wǎng)絡(luò)）進(jìn)行。
- 優(yōu)點(diǎn)：
對SQL標(biāo)準(zhǔn)的完善支持：ANSI SQL標(biāo)準(zhǔn)，OLAP擴(kuò)展，標(biāo)準(zhǔn)JDBC/ODBC支持。
支持ACID事務(wù)特性：這是很多現(xiàn)有基于Hadoop的SQL引擎做不到的，對保證數(shù)據(jù)一致性很重要。
動態(tài)數(shù)據(jù)流引擎：基于UDP的高速互聯(lián)網(wǎng)絡(luò)。
多種UDF（用戶自定義函數(shù)）語言支持：java, python, c/c++, perl, R等。
動態(tài)擴(kuò)容：動態(tài)按需擴(kuò)容，按照存儲大小或者計(jì)算需求，秒級添加節(jié)點(diǎn)。
支持MADlib機(jī)器學(xué)習(xí)。
- 缺點(diǎn)：
基于GreenPlum實(shí)現(xiàn)，技術(shù)實(shí)現(xiàn)復(fù)雜，包含多個(gè)組件。比如對于外部數(shù)據(jù)源，需要通過PXF單獨(dú)進(jìn)行處理；
C++實(shí)現(xiàn)，對內(nèi)存的控制比較復(fù)雜，如果出現(xiàn)segmentfault直接導(dǎo)致當(dāng)前node掛掉。
安裝配置復(fù)雜；
2.3.3 Impala
Impala是Cloudera在受到Google的Dremel啟發(fā)下開發(fā)的實(shí)時(shí)交互SQL大數(shù)據(jù)查詢工具。
Impala采用MPP架構(gòu)，與存儲引擎解耦：
impalad（實(shí)例*N）: 接收client、hue、jdbc或者odbc請求。每當(dāng)將查詢提交到特定節(jié)點(diǎn)上的impalad時(shí)，該節(jié)點(diǎn)充當(dāng)該查詢的“協(xié)調(diào)器節(jié)點(diǎn)”，負(fù)責(zé)將Query分發(fā)到其他impalad節(jié)點(diǎn)來并行化查詢，所有查詢結(jié)果返回給中心協(xié)調(diào)節(jié)點(diǎn)。
StateStore（實(shí)例*1）: 負(fù)責(zé)收集分布在各個(gè)Impalad進(jìn)程的資源信息、各節(jié)點(diǎn)健康狀況，同步節(jié)點(diǎn)信息；
Catalog Service（實(shí)例*1）: 分發(fā)表的元數(shù)據(jù)信息到各個(gè)Impalad中，每個(gè)Impala節(jié)點(diǎn)在本地緩存所有元數(shù)據(jù)。
-
與Hive的比較：
Impala 與Hive都是構(gòu)建在Hadoop之上的數(shù)據(jù)查詢工具，各有不同的側(cè)重點(diǎn)， Hive適合于長時(shí)間的批處理查詢分析，而Impala適合于實(shí)時(shí)交互式SQL查詢。
數(shù)據(jù)存儲：使用相同的存儲數(shù)據(jù)池都支持把數(shù)據(jù)存儲于HDFS, HBase。
元數(shù)據(jù)：兩者使用相同的元數(shù)據(jù)。
SQL解釋處理：比較相似都是通過詞法分析生成執(zhí)行計(jì)劃。
-
執(zhí)行計(jì)劃：
Hive: 依賴于MapReduce執(zhí)行框架，執(zhí)行計(jì)劃分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一個(gè)Query會 被編譯成多輪MapReduce，則會有更多的寫中間結(jié)果。由于MapReduce執(zhí)行框架本身的特點(diǎn)，過多的中間過程會增加整個(gè)Query的執(zhí)行時(shí)間。
Impala: 把執(zhí)行計(jì)劃表現(xiàn)為一棵完整的執(zhí)行計(jì)劃樹，可以更自然地分發(fā)執(zhí)行計(jì)劃到各個(gè)Impalad執(zhí)行查詢，而不用像Hive那樣把它組合成管道型的 map->reduce模式，以此保證Impala有更好的并發(fā)性和避免不必要的中間sort與shuffle。
-
數(shù)據(jù)流：
Hive: 采用推的方式，每一個(gè)計(jì)算節(jié)點(diǎn)計(jì)算完成后將數(shù)據(jù)主動推給后續(xù)節(jié)點(diǎn)。
Impala: 采用拉的方式，后續(xù)節(jié)點(diǎn)通過getNext主動向前面節(jié)點(diǎn)要數(shù)據(jù)，以此方式數(shù)據(jù)可以流式的返回給客戶端，且只要有1條數(shù)據(jù)被處理完，就可以立即展現(xiàn)出來，而不用等到全部處理完成，更符合SQL交互式查詢使用。
-
內(nèi)存使用：
Hive: 在執(zhí)行過程中如果內(nèi)存放不下所有數(shù)據(jù)，則會使用外存，以保證Query能順序執(zhí)行完。每一輪MapReduce結(jié)束，中間結(jié)果也會寫入HDFS中，同樣由于MapReduce執(zhí)行架構(gòu)的特性，shuffle過程也會有寫本地磁盤的操作。
Impala: 在遇到內(nèi)存放不下數(shù)據(jù)時(shí)，當(dāng)前版本1.0.1是直接返回錯(cuò)誤，而不會利用外存。這使用得Impala目前處理Query會受到一 定的限制。Impala在多個(gè)階段之間利用網(wǎng)絡(luò)傳輸數(shù)據(jù)，在執(zhí)行過程不會有寫磁盤的操作（insert除外）。
-
調(diào)度：
Hive: 任務(wù)調(diào)度依賴于Hadoop的調(diào)度策略。
Impala: 調(diào)度由自己完成，目前只有一種調(diào)度器simple-schedule，它會盡量滿足數(shù)據(jù)的局部性，掃描數(shù)據(jù)的進(jìn)程盡量靠近數(shù)據(jù)本身所在的物理機(jī)器。調(diào)度器目前還比較簡單，還沒有考慮負(fù)載，網(wǎng)絡(luò)IO狀況等因素進(jìn)行調(diào)度。但目前 Impala已經(jīng)有對執(zhí)行過程的性能統(tǒng)計(jì)分析，應(yīng)該以后版本會利用這些統(tǒng)計(jì)信息進(jìn)行調(diào)度吧。
-
容錯(cuò)：
Hive: 依賴于Hadoop的容錯(cuò)能力。
Impala: 在查詢過程中，沒有容錯(cuò)邏輯，如果在執(zhí)行過程中發(fā)生故障，則直接返回錯(cuò)誤（這與Impala的設(shè)計(jì)有關(guān)，因?yàn)镮mpala定位于實(shí)時(shí)查詢，一次查詢失敗， 再查一次就好了，再查一次的成本很低）。
-
適用面：
Hive: 復(fù)雜的批處理查詢?nèi)蝿?wù)，數(shù)據(jù)轉(zhuǎn)換任務(wù)。
Impala：實(shí)時(shí)數(shù)據(jù)分析，因?yàn)椴恢С諹DF，能處理的問題域有一定的限制。
-
優(yōu)點(diǎn)：
支持SQL查詢，快速查詢大數(shù)據(jù)。
可以對已有數(shù)據(jù)進(jìn)行查詢，減少數(shù)據(jù)的加載，轉(zhuǎn)換。
多種存儲格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。
可以與Hive配合使用。
-
缺點(diǎn)：
不支持用戶定義函數(shù)UDF。
不支持text域的全文搜索。
不支持Transforms。
不支持查詢期的容錯(cuò)。
對內(nèi)存要求高。
2.3.4 Drill
Drill是MapR開源的一個(gè)低延遲的大數(shù)據(jù)集的分布式SQL查詢引擎，是谷歌Dremel的開源實(shí)現(xiàn)。它支持對本地文件、HDFS、HBASE等數(shù)據(jù)進(jìn)行數(shù)據(jù)查詢，也支持對如JSON等schema-free的數(shù)據(jù)進(jìn)行查詢。
從架構(gòu)上看，與同是源自Dremel的Impala比較類似。Drill的核心是DrillBit，它主要負(fù)責(zé)接收客戶端的請求，處理查詢，并將結(jié)果返回給客戶端。 Drill的查詢流程包括以下步驟：
Drill客戶端發(fā)起查詢，任意DrilBit都可以接受來自客戶端的查詢
收到請求的DrillBit成為驅(qū)動節(jié)點(diǎn)（Foreman），對查詢進(jìn)行分析優(yōu)化生成執(zhí)行計(jì)劃，之后將執(zhí)行計(jì)劃劃分成各個(gè)片段（Fragment），并確定合適的節(jié)點(diǎn)來執(zhí)行。
各個(gè)節(jié)點(diǎn)執(zhí)行查詢片段（Fragment），并將結(jié)果返回給驅(qū)動節(jié)點(diǎn)
驅(qū)動節(jié)點(diǎn)將結(jié)果返回給客戶端
- 優(yōu)點(diǎn)：
能夠自動解析數(shù)據(jù)（json，text，parquet）的結(jié)構(gòu)。
支持自定義的嵌套數(shù)據(jù)集，數(shù)據(jù)靈活,，支持查詢復(fù)雜的半結(jié)構(gòu)化數(shù)據(jù)。
與Hive一體化（Hive表和視圖的查詢，支持所有的Hive文件格式和HiveUDFS）。
支持多數(shù)據(jù)源，包括NoSQL數(shù)據(jù)庫。
可以方便的與第三方BI工具對接。
- 缺點(diǎn)：
SQL語法和常規(guī)SQL有區(qū)別,一般是如“select * from 插件名.表名”的形式。
安裝部署比較復(fù)雜。
GC機(jī)制還有待提高。
2.4 基于通用計(jì)算框架的SQL引擎分析
2.4.1 SparkSQL
Spark SQL與傳統(tǒng) DBMS 的查詢優(yōu)化器 + 執(zhí)行器的架構(gòu)較為類似，只不過其執(zhí)行器是在分布式環(huán)境中實(shí)現(xiàn)，并采用的 Spark 作為執(zhí)行引擎：
Spark SQL 的查詢優(yōu)化是Catalyst，Catalyst 將 SQL 語言翻譯成最終的執(zhí)行計(jì)劃，并在這個(gè)過程中進(jìn)行查詢優(yōu)化。這里和傳統(tǒng)不太一樣的地方就在于， SQL 經(jīng)過查詢優(yōu)化器最終轉(zhuǎn)換為可執(zhí)行的查詢計(jì)劃是一個(gè)查詢樹，傳統(tǒng) DB 就可以執(zhí)行這個(gè)查詢計(jì)劃了。而 Spark SQL 最后執(zhí)行還是會在 Spark 內(nèi)將這棵執(zhí)行計(jì)劃樹轉(zhuǎn)換為 Spark 的有向無環(huán)圖DAG 再執(zhí)行。
- 優(yōu)點(diǎn)：
將sql查詢與spar無縫融合
兼容HiveQL
- 缺點(diǎn)：
查詢性能不高
以thrift server方式提供的SparkSQL服務(wù)不支持多種數(shù)據(jù)源，必須使用DataFrame API。
2.4.2 Hive
Hive是一個(gè)構(gòu)建于Hadoop頂層的數(shù)據(jù)倉庫工具。定義了簡單的類似SQL 的查詢語言——HiveQL，可以將HiveQL查詢轉(zhuǎn)換為MapReduce 的任務(wù)在Hadoop集群上執(zhí)行。
- 優(yōu)點(diǎn)：
高可靠、高容錯(cuò)：HiveServer采用集群模式。雙MetaStor。超時(shí)重試機(jī)制。
類SQL：類似SQL語法，內(nèi)置大量函數(shù)。
可擴(kuò)展：自定義存儲格式，自定義函數(shù)。
多接口：Beeline，JDBC，ODBC，Python，Thrift。
- 缺點(diǎn)：
延遲較高：默認(rèn)MR為執(zhí)行引擎，MR延遲較高。
不支持物化視圖：Hive支持普通視圖，不支持物化視圖。Hive不能再視圖上更新、插入、刪除數(shù)據(jù)。
不適用OLTP：暫不支持列級別的數(shù)據(jù)添加、更新、刪除操作。
2.5 各組件性能對比
測試數(shù)據(jù)來源于：開源OLAP引擎測評報(bào)告。通過測試以及相關(guān)調(diào)研編寫了各組件各個(gè)方面的綜合對比分析表，這里采用5分為滿分來比較，如下表：
SparkSQL是Hadoop中另一個(gè)著名的SQL引擎，它以Spark作為底層計(jì)算框架，Spark使用RDD作為分布式程序的工作集合，它提供一種分布式共享內(nèi)存的受限形式。在分布式共享內(nèi)存系統(tǒng)中，應(yīng)用可以向全局地址空間的任意位置進(jìn)行讀寫作，而RDD是只讀的，對其只能進(jìn)行創(chuàng)建、轉(zhuǎn)化和求值等作。這種內(nèi)存操作大大提高了計(jì)算速度。SparkSql的性能相對其他的組件要差一些，多表單表查詢性能都不突出。
Impala官方宣傳其計(jì)算速度是一大優(yōu)點(diǎn)，在實(shí)際測試中我們也發(fā)現(xiàn)它的多表查詢性能和presto差不多，但是單表查詢方面卻不如presto好。而且Impala有很多不支持的地方，例如：不支持update、delete操作，不支持Date數(shù)據(jù)類型，不支持ORC文件格式等等，所以我們查詢時(shí)采用parquet格式進(jìn)行查詢，而且Impala在查詢時(shí)占用的內(nèi)存很大。
Presto綜合性能比起來要比其余組件好一些，無論是查詢性能還是支持的數(shù)據(jù)源和數(shù)據(jù)格式方面都要突出一些，在單表查詢時(shí)性能靠前，多表查詢方面性能也很突出。由于Presto是完全基于內(nèi)存的并行計(jì)算，所以presto在查詢時(shí)占用的內(nèi)存也不少，但是發(fā)現(xiàn)要比Impala少一些，比如多表join需要很大的內(nèi)存，Impala占用的內(nèi)存比presto要多。
HAWQ 吸收了先進(jìn)的基于成本的 SQL 查詢優(yōu)化器，自動生成執(zhí)行計(jì)劃，可優(yōu)化使用hadoop 集群資源。HAWQ 采用 Dynamic pipelining 技術(shù)解決這一關(guān)鍵問題。Dynamic pipelining 是一種并行數(shù)據(jù)流框架，利用線性可擴(kuò)展加速Hadoop查詢，數(shù)據(jù)直接存儲在HDFS上，并且其SQL查詢優(yōu)化器已經(jīng)為基于HDFS的文件系統(tǒng)性能特征進(jìn)行過細(xì)致的優(yōu)化。但是我們發(fā)現(xiàn)HAWQ在多表查詢時(shí)比Presto、Impala差一些；而且不適合單表的復(fù)雜聚合操作，單表測試性能方面要比其余四種組件差很多，hawq環(huán)境搭建也遇到了諸多問題。
ClickHouse 作為目前所有開源MPP計(jì)算框架中計(jì)算速度最快的，它在做多列的表，同時(shí)行數(shù)很多的表的查詢時(shí)，性能是很讓人興奮的，但是在做多表的join時(shí)，它的性能是不如單寬表查詢的。性能測試結(jié)果表明ClickHouse在單表查詢方面表現(xiàn)出很大的性能優(yōu)勢，但是在多表查詢中性能卻比較差，不如presto、impala、hawq的效果好。
GreenPlum作為關(guān)系型數(shù)據(jù)庫產(chǎn)品，它的特點(diǎn)主要就是查詢速度快，數(shù)據(jù)裝載速度快，批量DML處理快。而且性能可以隨著硬件的添加，呈線性增加，擁有非常良好的可擴(kuò)展性。因此，它主要適用于面向分析的應(yīng)用。比如構(gòu)建企業(yè)級ODS/EDW，或者數(shù)據(jù)集市等，GREENPLUM都是不錯(cuò)的選擇。
參考：
