系列 | 漫談數(shù)倉(cāng)第五篇NO.5 『OLAP』

一 概念

1.1 什么是OLAP？

OLAP(OnLine Analytical Processing)，即聯(lián)機(jī)分析處理。OLAP對(duì)業(yè)務(wù)數(shù)據(jù)執(zhí)行多維分析，并提供復(fù)雜計(jì)算，趨勢(shì)分析和復(fù)雜數(shù)據(jù)建模的能力。它主要用于支持企業(yè)決策管理分析，是許多商務(wù)智能（BI）應(yīng)用程序背后的技術(shù)。OLAP使最終用戶可以對(duì)多個(gè)維度的數(shù)據(jù)進(jìn)行即席分析，從而獲取他們所需知識(shí)，以便更好地制定決策。OLAP技術(shù)已被定義為實(shí)現(xiàn)“快速訪問(wèn)共享的多維信息”的能力。

1.2 為什么要多維分析？

業(yè)務(wù)其實(shí)是一個(gè)多維活動(dòng)。企業(yè)通過(guò)考慮許多變量來(lái)跟蹤其業(yè)務(wù)活動(dòng)，在電子表格上跟蹤這些變量時(shí)，將它們?cè)O(shè)置在軸（x和y）上。例如，可以在一年的時(shí)間內(nèi)按月跟蹤銷售額，其中可以在y軸上顯示銷售指標(biāo)，而在x軸上可以顯示月份。而要分析業(yè)務(wù)的健康狀況并計(jì)劃未來(lái)的活動(dòng)，必須連續(xù)跟蹤許多變量組或參數(shù)。例如，一個(gè)業(yè)務(wù)至少要考慮以下方面：客戶，地點(diǎn)，期間，銷售人員和產(chǎn)品。這些維度構(gòu)成了公司計(jì)劃，分析和報(bào)告活動(dòng)的基礎(chǔ)。它們共同代表了“整個(gè)”業(yè)務(wù)狀況，為所有業(yè)務(wù)計(jì)劃、分析和報(bào)告活動(dòng)奠定了基礎(chǔ)。

1.3 OLAP的起源

OLAP這個(gè)名詞最早是在1993年，由被稱為“關(guān)系數(shù)據(jù)庫(kù)之父”的Edgar F. Codd在他的白皮書《Providing OLAP to User-Analysts: An IT Mandate》中首次提出的。在這個(gè)白皮書中，他為OLAP產(chǎn)品建立了12條評(píng)估規(guī)則：

1. Multidimensional Conceptual View（多維概念視圖）：在用戶分析師看來(lái)，企業(yè)天然是多維的。例如，可以按地區(qū)，產(chǎn)品，時(shí)間段或方案（例如實(shí)際，預(yù)算或預(yù)測(cè)）查看利潤(rùn)。多維數(shù)據(jù)模型使用戶能夠更直接，更直觀地處理數(shù)據(jù)，包括“分片和分塊”。

2. Transparency（透明性準(zhǔn)則）：OLAP應(yīng)該是開(kāi)放系統(tǒng)體系結(jié)構(gòu)的一部分，該體系結(jié)構(gòu)可以嵌入到用戶期望的任何位置，而不會(huì)影響宿主工具的功能。不應(yīng)把OLAP工具的數(shù)據(jù)源暴露給用戶，數(shù)據(jù)源可能是同構(gòu)的或異構(gòu)的。

3. Accessibility（存取能力推測(cè)）：OLAP工具應(yīng)該能夠應(yīng)用自己的邏輯結(jié)構(gòu)來(lái)訪問(wèn)異構(gòu)數(shù)據(jù)源，并執(zhí)行向用戶呈現(xiàn)連貫視圖所需的任何轉(zhuǎn)換。工具（而不是用戶）應(yīng)關(guān)注物理數(shù)據(jù)的來(lái)源。

4. Consistent Reporting Performance（穩(wěn)定的報(bào)表性能）：隨著維度數(shù)量的增加，OLAP工具的性能不會(huì)受到顯著影響。

5. Client-Server Architecture（客戶/服務(wù)器架構(gòu)）：OLAP工具的服務(wù)器組件應(yīng)該足夠智能，各種客戶端可以輕松地連接它。服務(wù)器應(yīng)該能夠在不同的數(shù)據(jù)庫(kù)之間映射和合并數(shù)據(jù)。

6. Generic Dimensionalityc（維的等同性準(zhǔn)則）：每個(gè)數(shù)據(jù)維度的結(jié)構(gòu)和操作能力都應(yīng)相同。

7. Dynamic Sparse Matrix Handling（動(dòng)態(tài)的稀疏矩陣處理準(zhǔn)則）：OLAP服務(wù)器的物理結(jié)構(gòu)應(yīng)具有最佳的稀疏矩陣處理。

8. Multi-User Support（多用戶支持能力準(zhǔn)則）：OLAP工具必須提供并發(fā)檢索和更新訪問(wèn)，完整性和安全性。

9. Unrestricted Cross-dimensional Operations（非受限的跨維操作）：計(jì)算設(shè)施必須允許跨任意數(shù)量的數(shù)據(jù)維度進(jìn)行計(jì)算和數(shù)據(jù)處理，并且不得限制數(shù)據(jù)單元之間的任何關(guān)系。

10. Intuitive Data Manipulation（直觀的數(shù)據(jù)操作）：合并路徑中固有的數(shù)據(jù)操作，例如向下鉆取或縮小，應(yīng)通過(guò)對(duì)分析模型單元的直接操作來(lái)完成，而不需要使用菜單或跨用戶界面多次行程。

11. Flexible Reporting（靈活的報(bào)告生成）：報(bào)告工具應(yīng)以用戶想要查看的任何方式顯示信息。

12. Unlimited Dimensions and Aggregation Levels（不受限的維度和聚合層次）。

1.4 OLAP的發(fā)展歷史

雖然OLAP的概念是在1993年才提出來(lái)的，但是支持OLAP相關(guān)產(chǎn)品的發(fā)展歷史，最早可追溯到1975年：

1. 第一款OLAP產(chǎn)品Express于1975年問(wèn)世，隨著被Oracle收購(gòu)后繁榮發(fā)展了30余年，最后由繼任者Oracle 9i替代。

2. 1979年，第一個(gè)電子表格應(yīng)用程序VisiCalc投放市場(chǎng)。VisiCalc具有當(dāng)今大多數(shù)電子表格應(yīng)用程序中標(biāo)準(zhǔn)的基本行和列結(jié)構(gòu)。

3. 1982年，Comshare開(kāi)發(fā)了一種新的決策支持系統(tǒng)軟件（System W），這是第一個(gè)金融領(lǐng)域的OLAP工具，也是第一個(gè)在其多維建模中應(yīng)用hypercube方法的工具。

4. 1983年，IBM推出了Lotus 1-2-3。它的結(jié)構(gòu)類似于Visicalc，并迅速取代了Visicalc。Lotus 1-2-3成為Windows之前的主流電子表格應(yīng)用程序。

5. 1984年，第一款ROLAP產(chǎn)品Metaphor發(fā)布。該多維產(chǎn)品建立了新概念，例如客戶/服務(wù)器計(jì)算，關(guān)系數(shù)據(jù)的多維處理，工作組處理，面向?qū)ο蟮拈_(kāi)發(fā)等。

6. 1985年，Excel 1.0誕生。微軟在Excel中集成了數(shù)據(jù)透視表功能可能是Excel產(chǎn)品最重要的增強(qiáng)功能之一，因?yàn)閿?shù)據(jù)透視表已成為多維分析中最流行和使用最廣泛的工具。

1989年，SQL語(yǔ)言標(biāo)準(zhǔn)誕生，它可以從關(guān)系數(shù)據(jù)庫(kù)中提取和處理業(yè)務(wù)數(shù)據(jù)。這可能是個(gè)轉(zhuǎn)折點(diǎn)。在1980‘s年代，電子表格在OLAP應(yīng)用中占絕對(duì)主導(dǎo)地位；而1990’s年代以后，越來(lái)越多的基于數(shù)據(jù)庫(kù)的OLAP應(yīng)用開(kāi)始出現(xiàn)：

1. 1992年：Hyperion Solution發(fā)布Essbase（擴(kuò)展電子表格數(shù)據(jù)庫(kù)），在1997年成為市場(chǎng)上主要的OLAP服務(wù)器產(chǎn)品。

2. 1997年：PARIS Technologies推出PowerOLAP：集成電子表格和事務(wù)數(shù)據(jù)庫(kù)，以便在電子表格應(yīng)用程序（例如Excel）中即時(shí)更新數(shù)據(jù)。

3. 1999年：Microsoft OLAP服務(wù)發(fā)布，并于2000年成為Microsoft Analysis Services

4. 2012年：PARIS Technologies發(fā)布了OLATION，它將關(guān)系和多維數(shù)據(jù)庫(kù)技術(shù)（在SQL Server，SAP HANA，Oracle等中）融合在一起，確保對(duì)實(shí)際數(shù)據(jù)和計(jì)劃數(shù)據(jù)進(jìn)行“真正的在線”數(shù)據(jù)更新。

1.5 OLAP的核心概念和基本操作

1.5.1 核心概念

維度(Dimension)：維度是描述與業(yè)務(wù)主題相關(guān)的一組屬性，單個(gè)屬性或?qū)傩约峡梢詷?gòu)成一個(gè)維。如時(shí)間、地理位置、年齡和性別等都是維度。

維的層次（Level of Dimension）：一個(gè)維往往可以具有多個(gè)層次，例如時(shí)間維度分為年、季度、月和日等層次，地區(qū)維可以是國(guó)家、地區(qū)、省、市等層次。這里的層次表示數(shù)據(jù)細(xì)化程度，對(duì)應(yīng)概念分層。后面介紹的上卷操作就是由低層概念映射到高層概念。概念分層除了可以根據(jù)概念的全序和偏序關(guān)系確定外，還可以通過(guò)對(duì)數(shù)據(jù)進(jìn)行離散化和分組實(shí)現(xiàn)。

維的成員(Member of Dimension)：若維是多層次的，則不同的層次的取值構(gòu)成一個(gè)維成員。部分維層次同樣可以構(gòu)成維成員，例如“某年某季度”、“某季某月”等都可以是時(shí)間維的成員。

度量(Measure)：表示事實(shí)在某一個(gè)維成員上的取值。例如開(kāi)發(fā)部門漢族男性有39人，就表示在部門、民族、性別三個(gè)維度上，企業(yè)人數(shù)的事實(shí)度量。

1.5.2 基本操作

OLAP的操作是以查詢——也就是數(shù)據(jù)庫(kù)的SELECT操作為主，但是查詢可以很復(fù)雜，比如基于關(guān)系數(shù)據(jù)庫(kù)的查詢可以多表關(guān)聯(lián)，可以使用COUNT、SUM、AVG等聚合函數(shù)。OLAP正是基于多維模型定義了一些常見(jiàn)的面向分析的操作類型是這些操作顯得更加直觀。

OLAP的多維分析操作包括：鉆取（Drill-down）、上卷（Roll-up）、切片（Slice）、切塊（Dice）以及旋轉(zhuǎn)（Pivot）**，下面還是以數(shù)據(jù)立方體為例來(lái)逐一解釋下：

鉆?。―rill-down）：在維的不同層次間的變化，從上層降到下一層，或者說(shuō)是將匯總數(shù)據(jù)拆分到更細(xì)節(jié)的數(shù)據(jù)，比如通過(guò)對(duì)2010年第二季度的總銷售數(shù)據(jù)進(jìn)行鉆取來(lái)查看2010年第二季度4、5、6每個(gè)月的消費(fèi)數(shù)據(jù)，如上圖；當(dāng)然也可以鉆取浙江省來(lái)查看杭州市、寧波市、溫州市……這些城市的銷售數(shù)據(jù)。

上卷（Roll-up）：鉆取的逆操作，即從細(xì)粒度數(shù)據(jù)向高層的聚合，如將江蘇省、上海市和浙江省的銷售數(shù)據(jù)進(jìn)行匯總來(lái)查看江浙滬地區(qū)的銷售數(shù)據(jù)，如上圖。

切片（Slice）：選擇維中特定的值進(jìn)行分析，比如只選擇電子產(chǎn)品的銷售數(shù)據(jù)，或者2010年第二季度的數(shù)據(jù)。

切塊（Dice）：選擇維中特定區(qū)間的數(shù)據(jù)或者某批特定值進(jìn)行分析，比如選擇2010年第一季度到2010年第二季度的銷售數(shù)據(jù)，或者是電子產(chǎn)品和日用品的銷售數(shù)據(jù)。

旋轉(zhuǎn)（Pivot）：即維的位置的互換，就像是二維表的行列轉(zhuǎn)換，如圖中通過(guò)旋轉(zhuǎn)實(shí)現(xiàn)產(chǎn)品維和地域維的互換。

1.6 OLAP的分類

按數(shù)據(jù)存儲(chǔ)方式分類，可分為MOLAP、ROLAP、HOLAP。

1.6.1 Multidimensional OLAP （MOLAP）

MOLAP是OLAP的經(jīng)典形式。MOLAP將數(shù)據(jù)存儲(chǔ)在優(yōu)化的多維數(shù)組中，而不是關(guān)系數(shù)據(jù)庫(kù)中。維的屬性值被映射成多維數(shù)組的下標(biāo)值或下標(biāo)的范圍，而度量數(shù)據(jù)作為多維數(shù)組的值存儲(chǔ)在數(shù)組的單元中。由于MOLAP采用了新的存儲(chǔ)結(jié)構(gòu)，從物理層實(shí)現(xiàn)，因此又稱為物理OLAP（PhysicalOLAP）；而 ROLAP主要通過(guò)一些軟件工具或中間軟件實(shí)現(xiàn)，物理層仍采用關(guān)系數(shù)據(jù)庫(kù)的存儲(chǔ)結(jié)構(gòu)，因此稱為虛擬OLAP（VirtualOLAP）。

一些MOLAP工具要求對(duì)數(shù)據(jù)進(jìn)行預(yù)計(jì)算和存儲(chǔ)，這樣的MOLAP工具通常利用被稱為“數(shù)據(jù)立方體”的預(yù)先計(jì)算的數(shù)據(jù)集。數(shù)據(jù)立方體包含給定范圍的問(wèn)題的所有可能答案。因此，它們對(duì)查詢的響應(yīng)非?？?。另一方面，根據(jù)預(yù)計(jì)算的程度，更新可能需要很長(zhǎng)時(shí)間。預(yù)計(jì)算也可能導(dǎo)致所謂的數(shù)據(jù)爆炸。

1.6.2 Relational OLAP（ROLAP）

ROLAP將分析用的多維數(shù)據(jù)存儲(chǔ)在關(guān)系數(shù)據(jù)庫(kù)中。這種方式依賴SQL語(yǔ)言實(shí)現(xiàn)傳統(tǒng)OLAP的切片和切塊功能，本質(zhì)上，切片和切塊等動(dòng)作都等同于在SQL語(yǔ)句中添加“ WHERE”子句。ROLAP工具不使用預(yù)先計(jì)算的多維數(shù)據(jù)集，而是對(duì)標(biāo)準(zhǔn)關(guān)系數(shù)據(jù)庫(kù)及其表進(jìn)行查詢，以獲取回答問(wèn)題所需的數(shù)據(jù)。ROLAP工具具有詢問(wèn)任何問(wèn)題的能力，因?yàn)樵摲椒ǎ⊿QL）不僅限于多維數(shù)據(jù)集的內(nèi)容。

盡管ROLAP使用關(guān)系數(shù)據(jù)庫(kù)作為底層存儲(chǔ)，但這些數(shù)據(jù)庫(kù)一般要針對(duì)ROLAP進(jìn)行相應(yīng)優(yōu)化，比如并行存儲(chǔ)、并行查詢、并行數(shù)據(jù)管理、基于成本的查詢優(yōu)化、位圖索引、SQL的OLAP擴(kuò)展（cube,rollup）等等。專為OLTP設(shè)計(jì)的數(shù)據(jù)庫(kù)不能像ROLAP數(shù)據(jù)庫(kù)一樣正常工作。

1.6.3 Hybrid OLAP（HOLAP）

由于MOLAP和ROLAP有著各自的優(yōu)點(diǎn)和缺點(diǎn)，且它們的結(jié)構(gòu)迥然不同，這給分析人員設(shè)計(jì)OLAP結(jié)構(gòu)提出了難題。為此一個(gè)新的OLAP 結(jié)構(gòu)——混合型OLAP（HOLAP）被提出，這種工具通過(guò)允許同時(shí)使用多維數(shù)據(jù)庫(kù)（MDDB）和關(guān)系數(shù)據(jù)庫(kù)（RDBMS）作為數(shù)據(jù)存儲(chǔ)來(lái)彌合這兩種產(chǎn)品的技術(shù)差距。它允許模型設(shè)計(jì)者決定將哪些數(shù)據(jù)存儲(chǔ)在MDDB中，哪些存儲(chǔ)在RDBMS中， 例如，將大量詳單數(shù)據(jù)存儲(chǔ)在關(guān)系表中，而預(yù)先計(jì)算的聚合數(shù)據(jù)存儲(chǔ)在多維數(shù)據(jù)集中。目前整個(gè)行業(yè)對(duì)于“混合OLAP”的還沒(méi)有達(dá)成明確的共識(shí)。

1.6.4 MOLAP與ROLAP對(duì)比分析

1.7 OLAP與其他概念的關(guān)系

1.7.1 OLAP vs OLTP

兩者設(shè)計(jì)的目標(biāo)是完全不同的：

1. OLTP（On-Line Transaction Processing），聯(lián)機(jī)事務(wù)處理，一般用于業(yè)務(wù)系統(tǒng)。OLTP對(duì)事務(wù)性處理的要求非常高，一般都是高可用的在線系統(tǒng)，主要基于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)。其上的應(yīng)用，一般以小的事務(wù)以及小的查詢?yōu)橹鳌Ｔu(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的Transaction以及SQL的數(shù)量。在這樣的系統(tǒng)中，單個(gè)數(shù)據(jù)庫(kù)每秒處理的Transaction（增、刪、改）往往達(dá)到幾百上千個(gè)，Select查詢語(yǔ)句的執(zhí)行量每秒幾千甚至幾萬(wàn)個(gè)。典型的OLTP系統(tǒng)有電子商務(wù)系統(tǒng)、銀行交易系統(tǒng)、證券交易系統(tǒng)等。

2. OLAP，一般用于分析系統(tǒng)。其上的應(yīng)用，一般以大數(shù)據(jù)量的查詢?yōu)橹鳎薷暮蛣h除的操作較少。在這樣的系統(tǒng)中，SQL語(yǔ)句的執(zhí)行量不是考核指標(biāo)，因?yàn)橐粭l語(yǔ)句的執(zhí)行時(shí)間可能會(huì)很長(zhǎng)，讀取的數(shù)據(jù)也非常多。所以，評(píng)估其系統(tǒng)的時(shí)候，往往是看系統(tǒng)的吞吐量、復(fù)雜查詢響應(yīng)時(shí)間、數(shù)據(jù)裝載性能等。

二者詳細(xì)對(duì)比如下：

1.7.2 OLAP vs 數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)集市

數(shù)據(jù)倉(cāng)庫(kù)的建模方式有多種：

1. ER模型（實(shí)體-關(guān)系模型）

2. Data Vault模型

3. Anchor模型

4. 維度模型

前面三種模型主要致力將各個(gè)業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)整合到統(tǒng)一的數(shù)據(jù)倉(cāng)庫(kù)中，并進(jìn)行一致性處理，提供滿足第三范式或更高范式的數(shù)據(jù)模型和原子數(shù)據(jù)。這種數(shù)據(jù)倉(cāng)庫(kù)被稱為CIF（Corporate Information Factory，企業(yè)信息工廠）架構(gòu)下的企業(yè)數(shù)據(jù)倉(cāng)庫(kù)。這種數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)是數(shù)據(jù)倉(cāng)庫(kù)之父Inmon所推崇的。但由于使用了規(guī)范化模型，這使得對(duì)這些原子數(shù)據(jù)進(jìn)行查詢變得很困難，這種架構(gòu)并不能很好地直接用于支撐分析決策。為了更好的支持分析，在這種架構(gòu)下，通常需要在數(shù)據(jù)倉(cāng)庫(kù)的基礎(chǔ)上，按主題建立一些數(shù)據(jù)子集，也就是數(shù)據(jù)集市。這些數(shù)據(jù)集市通常采用維度模型，OLAP工具就可以基于數(shù)據(jù)集市而工作。數(shù)據(jù)集市通常就是基于OLAP系統(tǒng)而構(gòu)建。

第四種模型（維度模型）是另一位數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域的大師Kimball提出的，是目前數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域最流行的建模方式。維度模型可以很好地支撐分析決策需求，同時(shí)還有較好的大規(guī)模復(fù)雜查詢的響應(yīng)性能。維度模型可以直接使用OLAP工具與其對(duì)接。Kimball所推崇的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)如下，基于這種架構(gòu)建立的數(shù)據(jù)倉(cāng)庫(kù)，可以直接提供OLAP能力。這樣建立的數(shù)據(jù)倉(cāng)庫(kù)本身也就成為了一個(gè)OLAP系統(tǒng)。

1.7.3 OLAP vs BI工具

BI是Business Intelligence的英文縮寫，中文解釋為商務(wù)智能，是利用數(shù)據(jù)提高決策質(zhì)量的技術(shù)集合，是從大量的數(shù)據(jù)中鉆取信息與知識(shí)的過(guò)程。OLAP和BI常常在一起出現(xiàn)，OLAP是BI工具的一種底層技術(shù)。BI工具通?？梢詫?duì)接OLAP系統(tǒng)，但不限于此，也可以直接與其他數(shù)據(jù)庫(kù)、存儲(chǔ)系統(tǒng)對(duì)接。

1.7.4 OLAP vs 即席查詢

Ad hoc是一個(gè)拉丁文常用短語(yǔ)，意思是“特設(shè)的、特定目的的（地）、臨時(shí)的、專案的”。即席查詢（Ad Hoc Queries）是指用戶根據(jù)自己的需求動(dòng)態(tài)創(chuàng)建的查詢，與預(yù)定義查詢相反。

即席查詢對(duì)數(shù)據(jù)模型沒(méi)有要求，只要能提供動(dòng)態(tài)查詢的能力即可；而OLAP系統(tǒng)，一般要求數(shù)據(jù)模型是多維數(shù)據(jù)模型。對(duì)于ROLAP系統(tǒng)，通常都能提供即席查詢能力，二者之間差別很小，所以經(jīng)?；煊?。

二 開(kāi)源組件

開(kāi)源大數(shù)據(jù)OLAP組件，可以分為MOLAP和ROLAP兩類。ROLAP中又可細(xì)分為MPP數(shù)據(jù)庫(kù)和SQL引擎兩類。對(duì)于SQL引擎又可以再細(xì)分為基于MPP架構(gòu)的SQL引擎和基于通用計(jì)算框架的SQL引擎：

1. MOLAP一般對(duì)數(shù)據(jù)存儲(chǔ)有優(yōu)化，并且進(jìn)行部分預(yù)計(jì)算，因此查詢性能最高。但通常對(duì)查詢靈活性有限制。

2. MPP數(shù)據(jù)庫(kù)是個(gè)完整的數(shù)據(jù)庫(kù)，通常數(shù)據(jù)需要導(dǎo)入其中才能完成OLAP功能。MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)入庫(kù)時(shí)對(duì)數(shù)據(jù)分布可以做優(yōu)化，雖然入庫(kù)效率有一定下降，但是對(duì)后期查詢性能的提高有很大幫助。MPP數(shù)據(jù)庫(kù)可以提供靈活的即席查詢能力，但一般對(duì)查詢數(shù)據(jù)量有一定限制，無(wú)法支撐特別大的數(shù)據(jù)量的查詢。

3. SQL引擎只提供SQL執(zhí)行的能力，本身一般不負(fù)責(zé)數(shù)據(jù)存儲(chǔ)，通常可以對(duì)接多種數(shù)據(jù)儲(chǔ)存，如HDFS、HBase、MySQL等。有的還支持聯(lián)邦查詢能力，可以對(duì)多個(gè)異構(gòu)數(shù)據(jù)源進(jìn)行聯(lián)合分析。SQL引擎中，基于MPP架構(gòu)的SQL引擎，一般對(duì)在線查詢場(chǎng)景有特殊優(yōu)化，所以端到端查詢性能一般要高于基于通用計(jì)算框架的SQL引擎；但是在容錯(cuò)性和數(shù)據(jù)量方面又會(huì)遜于基于通用計(jì)算框架的SQL引擎。

總之，可以說(shuō)沒(méi)有一個(gè)OLAP系統(tǒng)能同時(shí)在處理規(guī)模，靈活性和性能這三個(gè)方面做到完美，用戶需要基于自己的需求進(jìn)行取舍和選型。

2.1 開(kāi)源MOLAP系統(tǒng)分析

2.1.1 Kylin

Apache Kylin 是一個(gè)開(kāi)源的分布式分析引擎，提供 Hadoop/Spark 之上的 SQL 查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，它能在亞秒內(nèi)查詢巨大的 Hive 表。Kylin的核心思想是預(yù)計(jì)算，理論基礎(chǔ)是：以空間換時(shí)間。即將多維分析可能用到的度量進(jìn)行預(yù)計(jì)算，將計(jì)算好的結(jié)果保存成Cube并存儲(chǔ)到HBase中，供查詢時(shí)直接訪問(wèn)。把高復(fù)雜度的聚合運(yùn)算，多表連接等操作轉(zhuǎn)換成對(duì)預(yù)計(jì)算結(jié)果的查詢。

Kylin的核心模塊：

1. REST Server：提供 Restful 接口，例如創(chuàng)建、構(gòu)建、刷新、合并等 Cube 相關(guān)操作，Kylin 的 Projects、Tables 等元數(shù)據(jù)管理，用戶訪問(wèn)權(quán)限控制，SQL 的查詢等；

2. Query Engine：使用開(kāi)源的 Apache Calcite 框架來(lái)實(shí)現(xiàn) SQL 解析，可以理解為 SQL 引擎層；

3. Routing：負(fù)責(zé)將解析 SQL 生成的執(zhí)行計(jì)劃轉(zhuǎn)換成 Cube 緩存的查詢，這部分查詢是可以在秒級(jí)甚至毫秒級(jí)完成；

4. Metadata：Kylin 中有大量的元數(shù)據(jù)信息，包括 Cube 的定義、星型模型的定義、Job 和執(zhí)行 Job 的輸出信息、模型的維度信息等等，Kylin 的元數(shù)據(jù)和 Cube 都存儲(chǔ)在 HBase 中，存儲(chǔ)的格式是 json 字符串；

5. Cube Build Engine：所有模塊的基礎(chǔ)，它主要負(fù)責(zé) Kylin 預(yù)計(jì)算中創(chuàng)建 Cube，創(chuàng)建的過(guò)程是首先通過(guò) Hive 讀取原始數(shù)據(jù)，然后通過(guò)一些 MapReduce 或 Spark 計(jì)算生成 Htable，最后將數(shù)據(jù) load 到 HBase 表中。

整個(gè)系統(tǒng)分為兩部分：

1. 離線構(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 開(kāi)始 Spark 是主要的構(gòu)建技術(shù)（以前是MapReduce）；

• 構(gòu)建后的 Cube 保存在右側(cè)的存儲(chǔ)引擎中，一般選用 HBase 作為存儲(chǔ)。

2. 在線查詢

• 用戶可以從上方查詢系統(tǒng)（Rest API、JDBC/ODBC）發(fā)送 SQL 進(jìn)行查詢分析；

• 無(wú)論從哪個(gè)接口進(jìn)入，SQL 最終都會(huì)來(lái)到 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)：

1. 亞秒級(jí)查詢響應(yīng)；

2. 支持百億、千億甚至萬(wàn)億級(jí)別交互式分析；

3. 無(wú)縫與 BI 工具集成；

4. 支持增量刷新；

• 缺點(diǎn)：

1. 由于 Kylin 是一個(gè)分析引擎，只讀，不支持 insert, update, delete 等 SQL 操作，用戶修改數(shù)據(jù)的話需要重新批量導(dǎo)入（構(gòu)建）；

2. 需要預(yù)先建立模型后加載數(shù)據(jù)到 Cube 后才可進(jìn)行查詢

3. 使用 Kylin 的建模人員需要了解一定的數(shù)據(jù)倉(cāng)庫(kù)知識(shí)。

2.1.2 Druid

Apache Druid是高性能的實(shí)時(shí)分析數(shù)據(jù)庫(kù)，主要提供對(duì)大量的基于時(shí)序的數(shù)據(jù)進(jìn)行OLAP查詢能力。支持毫秒級(jí)的快速的交互式查詢。

Druid有幾種進(jìn)程類型，簡(jiǎn)要描述如下：

1. 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之間保持平衡。

2. Overlords進(jìn)程：負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)服務(wù)器上的MiddleManager進(jìn)程，并控制數(shù)據(jù)獲取任務(wù)的分配。

3. Broker代理進(jìn)程：處理來(lái)自外部客戶端的查詢，將查詢轉(zhuǎn)發(fā)給數(shù)據(jù)服務(wù)器去執(zhí)行，并合并來(lái)自多個(gè)數(shù)據(jù)服務(wù)器的結(jié)果，返回給最終用戶。

4. Routers進(jìn)程：是個(gè)可選進(jìn)程，提供統(tǒng)一的API Gateway，可以將請(qǐng)求路由到Brokers、Overlords和Coordinators。

5. Historicals進(jìn)程：負(fù)責(zé)處理“歷史數(shù)據(jù)”的查詢。它會(huì)從Deep Storage下載查詢需要的Segments以加速查詢。它不負(fù)責(zé)寫入。

6. MiddleManager進(jìn)程：負(fù)責(zé)處理獲取到新數(shù)據(jù)，從外部數(shù)據(jù)源讀取數(shù)據(jù)并轉(zhuǎn)換成Segments進(jìn)行存儲(chǔ)。

Druid進(jìn)程可以按照任何方式進(jìn)行部署，但是為了易于部署，一般建議將它們組織為三種服務(wù)器類型：

1. 主服務(wù)器：運(yùn)行Coordinatos和Overlords進(jìn)程，負(fù)責(zé)管理數(shù)據(jù)獲取和數(shù)據(jù)可用性。

2. 查詢服務(wù)器：運(yùn)行Brokers和可選的Routers進(jìn)程，處理來(lái)自外部客戶端的查詢。

3. 數(shù)據(jù)服務(wù)器：運(yùn)行Historicals和MiddleManagers進(jìn)程，負(fù)責(zé)執(zhí)行數(shù)據(jù)獲取任務(wù)并存儲(chǔ)所有可查詢的數(shù)據(jù)。

Druid之所以查詢?nèi)绱酥?，與它針對(duì)多維數(shù)據(jù)優(yōu)化的組織和存儲(chǔ)方式有很大關(guān)系。它將數(shù)據(jù)索引存儲(chǔ)在Segments文件中，Segment文件按列來(lái)存儲(chǔ)，并通過(guò)時(shí)間分區(qū)來(lái)進(jìn)行橫向分割。Druid將數(shù)據(jù)列分為了三種不同的類型：

1. 對(duì)于時(shí)間列和指標(biāo)列處理比較簡(jiǎn)單，直接用lz4壓縮存儲(chǔ)。一旦查詢知道去找哪幾行，只需要將它們解壓，然后用相應(yīng)的操作符來(lái)操作它們就可以了。

2. 對(duì)于維度列就沒(méi)那么簡(jiǎn)單了，因?yàn)樗鼈冃枰С诌^(guò)濾和聚合操作，因此每個(gè)維度需要下面三個(gè)數(shù)據(jù)結(jié)構(gòu)：

   (1) 一個(gè)map，Key是維度的值，值是一個(gè)整型的id

   (2) 一個(gè)存儲(chǔ)列的值得列表，用(1)中的map編碼的list

   (3) 對(duì)于列中的每個(gè)值對(duì)應(yīng)一個(gè)bitmap，這個(gè)bitmap用來(lái)指示哪些行包含這個(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（也被稱為倒排索引）允許快速過(guò)濾操作（特別地，bitmap便于快速進(jìn)行AND和OR運(yùn)算），這樣，對(duì)于過(guò)濾再聚合的場(chǎng)景，無(wú)需訪問(wèn)（2）中的維度值列表。最后，（2）中的值可以被用來(lái)支持group by和TopN查詢。

• 優(yōu)點(diǎn)：

1. 為分析而設(shè)計(jì)：為OLAP工作流的探索性分析而構(gòu)建。它支持各種filter、aggregator和查詢類型。
2. 交互式查詢：低延遲數(shù)據(jù)攝取架構(gòu)允許事件在它們創(chuàng)建后毫秒內(nèi)查詢。
3. 高可用：你的數(shù)據(jù)在系統(tǒng)更新時(shí)依然可用、可查詢。規(guī)模的擴(kuò)大和縮小不會(huì)造成數(shù)據(jù)丟失。
4. 可伸縮：每天處理數(shù)十億事件和TB級(jí)數(shù)據(jù)。

• 缺點(diǎn)：

1. 不支持更新操作，數(shù)據(jù)不可更改
2. 不支持事實(shí)表之間的關(guān)聯(lián)

2.2 開(kāi)源MPP數(shù)據(jù)庫(kù)分析

2.2.1 Greenplum

GreenPlum是基于PostgreSQL的開(kāi)源MPP數(shù)據(jù)庫(kù)，具有良好的線性擴(kuò)展能力，具有高效的并行運(yùn)算和并行存儲(chǔ)特性。

Greenplum的系統(tǒng)架構(gòu)實(shí)際上是多臺(tái)PostgreSQL數(shù)據(jù)庫(kù)服務(wù)器組成的矩陣，采用無(wú)共享(no shareing)的MPP架構(gòu)：

1. Master節(jié)點(diǎn)：作為數(shù)據(jù)庫(kù)的入口，負(fù)責(zé)客服端連接；對(duì)客服端的請(qǐng)求生成查詢計(jì)劃，分發(fā)給某個(gè)或者所有的Segment節(jié)點(diǎn)。
2. Standby節(jié)點(diǎn) : 作為master節(jié)點(diǎn)的備庫(kù)，提供高可用性。
3. Interconnect：是GreenPlum的網(wǎng)絡(luò)層；負(fù)責(zé)每個(gè)節(jié)點(diǎn)之間的通信。
4. Segment節(jié)點(diǎn)：為數(shù)據(jù)節(jié)點(diǎn)；接收master分發(fā)下來(lái)的查詢計(jì)劃；執(zhí)行返回結(jié)果給master節(jié)點(diǎn)。
5. Mirror Segment節(jié)點(diǎn)：作為Segment節(jié)點(diǎn)的備庫(kù)，提供高可用性；通常跟對(duì)應(yīng)的segment節(jié)點(diǎn)不在同一臺(tái)機(jī)器上。

• 優(yōu)點(diǎn)：

1. 支持多態(tài)數(shù)據(jù)存儲(chǔ)，允許用戶根據(jù)應(yīng)用定義數(shù)據(jù)分布方式，可提高查詢性能。
2. 具有高效的SQL優(yōu)化器，針對(duì)OLAP查詢進(jìn)行優(yōu)化。

• 缺點(diǎn)：

1. 存在“木桶效應(yīng)”，單機(jī)故障會(huì)導(dǎo)致性能嚴(yán)重下降，因此集群規(guī)模不能太大。
2. 并發(fā)性能不高，通常無(wú)法支持超過(guò)30個(gè)并發(fā)。

2.2.2 ClickHouse

ClickHouse是Yandex（號(hào)稱俄羅斯的‘百度’）開(kāi)源的MPP架構(gòu)的列式存儲(chǔ)數(shù)據(jù)庫(kù)。

目前ClickHouse公開(kāi)的資料相對(duì)匱乏，比如在架構(gòu)設(shè)計(jì)層面就很難找到完整的資料，甚至連一張整體的架構(gòu)圖都沒(méi)有。

• ClickHouse為什么性能這么好？

1. 著眼硬件?；趯⒂布πё畲蠡哪康?，ClickHouse會(huì)在內(nèi)存中進(jìn)行GROUP BY；與此同時(shí)，他們非常在意CPU L3級(jí)別的緩存，因?yàn)橐淮蜭3的緩存失效會(huì)帶來(lái)70～100ns的延遲，意味著在單核CPU上，它會(huì)浪費(fèi)4000萬(wàn)次/秒的運(yùn)算。正因?yàn)樽⒁饬诉@些細(xì)節(jié)，所以ClickHouse在基準(zhǔn)查詢中能做到1.75億次/秒的數(shù)據(jù)掃描性能。
2. 注重算法。例如，在字符串搜索方面，針對(duì)不同的場(chǎng)景，ClickHouse選擇了多種算法：對(duì)于常量，使用Volnitsky算法；對(duì)于非常量，使用CPU的向量化執(zhí)行SIMD，暴力優(yōu)化；正則匹配使用re2和hyperscan算法。除了字符串之外，其余的場(chǎng)景也與它類似，ClickHouse會(huì)使用最合適、最快的算法。如果世面上出現(xiàn)了號(hào)稱性能強(qiáng)大的新算法，ClickHouse團(tuán)隊(duì)會(huì)立即將其納入并進(jìn)行驗(yàn)證。
3. 特定場(chǎng)景，特殊優(yōu)化。針對(duì)同一個(gè)場(chǎng)景的不同狀況，選擇使用不同的實(shí)現(xiàn)方式，盡可能將性能最大化。對(duì)于數(shù)據(jù)結(jié)構(gòu)比較清晰的場(chǎng)景，會(huì)通過(guò)代碼生成技術(shù)實(shí)現(xiàn)循環(huán)展開(kāi)，以減少循環(huán)次數(shù)。
4. 向量化執(zhí)行。SIMD被廣泛地應(yīng)用于文本轉(zhuǎn)換、數(shù)據(jù)過(guò)濾、數(shù)據(jù)解壓和JSON轉(zhuǎn)換等場(chǎng)景。相較于單純地使用CPU，利用寄存器暴力優(yōu)化也算是一種降維打擊了。

• 優(yōu)點(diǎn)：

1. 速度快

• 缺點(diǎn)：

1. 不支持事務(wù)，不支持真正的刪除/更新；
2. 不支持高并發(fā)，Clickhouse快是因?yàn)椴捎昧瞬⑿刑幚頇C(jī)制，即使一個(gè)查詢，也會(huì)用服務(wù)器一半的CPU去執(zhí)行。
3. join性能不高
4. 開(kāi)源社區(qū)主要是俄語(yǔ)為主.

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)：

1. coordinator：是presto集群的master節(jié)點(diǎn)。負(fù)責(zé)解析SQL語(yǔ)句，生成執(zhí)行計(jì)劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點(diǎn)執(zhí)行。
2. worker：是執(zhí)行任務(wù)的節(jié)點(diǎn)。負(fù)責(zé)實(shí)際查詢?nèi)蝿?wù)的計(jì)算和讀寫。
3. discovery service：是將coordinator和worker結(jié)合在一起服務(wù)。worker節(jié)點(diǎn)啟動(dòng)后向discovery service服務(wù)注冊(cè)，coordinator通過(guò)discovery service獲取注冊(cè)的worker節(jié)點(diǎn)。
4. connector：presto以插件形式對(duì)數(shù)據(jù)存儲(chǔ)層進(jìn)行了抽象，即connector?？赏ㄟ^(guò)connector連接多種數(shù)據(jù)源，提取數(shù)據(jù)。
   discovery service  將coordinator和worker結(jié)合在一起服務(wù)；worker節(jié)點(diǎn)啟動(dòng)后向discovery service服務(wù)注冊(cè)  coordinator通過(guò)discovery service獲取注冊(cè)的worker節(jié)點(diǎn)

既然Presto是一個(gè)交互式的查詢引擎，我們最關(guān)心的就是Presto實(shí)現(xiàn)低延時(shí)查詢的原理，我認(rèn)為主要是下面幾個(gè)關(guān)鍵點(diǎn)：

1. 完全基于內(nèi)存的并行計(jì)算
2. 流水線式計(jì)算作業(yè)
3. 本地化計(jì)算
4. 動(dòng)態(tài)編譯執(zhí)行計(jì)劃
5. 小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)
6. 類BlinkDB的近似查詢
7. GC控制

• 與Hive的比較：
  

上圖顯示了MapReduce與Presto的執(zhí)行過(guò)程的不同點(diǎn)，MR每個(gè)操作要么需要寫磁盤，要么需要等待前一個(gè)stage全部完成才開(kāi)始執(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ù)之間的傳輸也是通過(guò)網(wǎng)絡(luò)以Memory-to-Memory的形式進(jìn)行，沒(méi)有磁盤io操作。這也是Presto性能比Hive快很多倍的決定性原因。

• 與Spark的比較：
1. 目標(biāo)：Presto強(qiáng)調(diào)查詢，但Spark重點(diǎn)強(qiáng)調(diào)計(jì)算。
2. 架構(gòu)：Presto的體系結(jié)構(gòu)與MPP SQL引擎非常相似。這意味著僅針對(duì)SQL查詢執(zhí)行進(jìn)行了高度優(yōu)化，而Spark是一個(gè)通用執(zhí)行框架，能夠運(yùn)行多個(gè)不同的工作負(fù)載，如ETL，機(jī)器學(xué)習(xí)等。
3. 任務(wù)啟動(dòng)：Presto的查詢沒(méi)有太多開(kāi)銷。Presto協(xié)調(diào)器始終處于啟動(dòng)狀態(tài)并等待查詢。而Spark驅(qū)動(dòng)程序啟動(dòng)需要時(shí)間與集群管理器協(xié)商資源，復(fù)制jar，才開(kāi)始處理。
4. 任務(wù)提交：Spark提交任務(wù)并在每個(gè)階段實(shí)時(shí)應(yīng)用資源（與presto相比，這種策略可能導(dǎo)致處理速度稍慢）; Presto一次申請(qǐng)所需資源，并且一次提交所有任務(wù)。
5. 數(shù)據(jù)處理：在spark中，數(shù)據(jù)需要在進(jìn)入下一階段之前完全處理。Presto是流水線式處理模式。只要一個(gè)page完成處理，就可以將其發(fā)送到下一個(gè)task（這種方法大大減少了各種查詢的端到端響應(yīng)時(shí)間）。
6. 內(nèi)存：兩者都是內(nèi)存存儲(chǔ)和計(jì)算，當(dāng)它無(wú)法獲得足夠的內(nèi)存時(shí)，spark會(huì)將數(shù)據(jù)寫入磁盤，但presto會(huì)導(dǎo)致OOM。
7. 容錯(cuò)：如果Spark任務(wù)失敗或數(shù)據(jù)丟失，它將重新計(jì)算。但是presto會(huì)導(dǎo)致查詢失敗。
• 優(yōu)點(diǎn)：

1. 基于內(nèi)存運(yùn)算，減少?zèng)]必要的硬盤IO，所以快。
2. 都能夠處理PB級(jí)別的海量數(shù)據(jù)分析。（雖然能夠處理PB級(jí)別的海量數(shù)據(jù)分析，但不是代表Presto把PB級(jí)別都放在內(nèi)存中計(jì)算的。而是根據(jù)場(chǎng)景，如count，avg等聚合運(yùn)算，是邊讀數(shù)據(jù)邊計(jì)算，再清內(nèi)存，再讀數(shù)據(jù)再計(jì)算，這種耗的內(nèi)存并不高。）
3. 能夠連接多個(gè)數(shù)據(jù)源，跨數(shù)據(jù)源關(guān)聯(lián)查詢。
4. 清晰的架構(gòu)，是一個(gè)能夠獨(dú)立運(yùn)行的系統(tǒng)，不依賴于任何其他外部系統(tǒng)。部署簡(jiǎn)單。

• 缺點(diǎn)：

1. 不適合多個(gè)大表的join操作，因?yàn)閜resto是基于內(nèi)存的，太多數(shù)據(jù)內(nèi)存放不下的。
2. Presto的一個(gè)權(quán)衡是不關(guān)心中間查詢?nèi)蒎e(cuò)。如果其中一個(gè)Presto工作節(jié)點(diǎn)出現(xiàn)故障（例如，關(guān)閉），則大多數(shù)情況下正在進(jìn)行的查詢將中止并需要重新啟動(dòng)。

2.3.2 HAWQ

HAWQ是Pivotal公司開(kāi)源的一個(gè)Hadoop原生大規(guī)模并行SQL分析引擎，針對(duì)的是分析型應(yīng)用。Apache HAWQ 采用主從（Master-Slave）的改進(jìn)MPP架構(gòu)，通過(guò)將MPP與批處理系統(tǒng)有效的結(jié)合，克服了MPP的一些關(guān)鍵的限制問(wèn)題，如短板效應(yīng)、并發(fā)限制、擴(kuò)展性等。其整體架構(gòu)與Pivotal另一開(kāi)源MPP數(shù)據(jù)庫(kù)Greenplum比較相似：

HAWQ Master節(jié)點(diǎn)內(nèi)部有以下幾個(gè)重要組件：

1. 查詢解析器（Parser/Analyzer），負(fù)責(zé)解析查詢，并檢查語(yǔ)法及語(yǔ)義。最終生成查詢樹(shù)傳遞給優(yōu)化器。
2. 優(yōu)化器（Optimizer），負(fù)責(zé)接受查詢樹(shù)，生成查詢計(jì)劃。針對(duì)一個(gè)查詢，可能有數(shù)億個(gè)可能的等價(jià)的查詢計(jì)劃，但執(zhí)行性能差異很大。優(yōu)化器的做用是找出優(yōu)化的查詢計(jì)劃。
3. 資源管理器（Resource Manager），資源管理器經(jīng)過(guò)資源代理向全局資源管理器（好比YARN）動(dòng)態(tài)申請(qǐng)資源。并緩存資源。在不須要的時(shí)候返回資源。
4. HDFS元數(shù)據(jù)緩存（HDFS Catalog Cache），用于HAWQ確定哪些Segment掃描表的哪些部分。HAWQ是把計(jì)算派發(fā)到數(shù)據(jù)所在的地方。因此要匹配計(jì)算和數(shù)據(jù)的局部性。如果每一個(gè)查詢都訪問(wèn)HDFS NameNode會(huì)形成NameNode的瓶頸。因此在HAWQ Master節(jié)點(diǎn)上創(chuàng)建了HDFS元數(shù)據(jù)緩存。
5. 容錯(cuò)服務(wù)（Fault Tolerance Service），負(fù)責(zé)檢測(cè)哪些節(jié)點(diǎn)可用，哪些節(jié)點(diǎn)不可用。不可用的機(jī)器會(huì)被排除出資源池。
6. 查詢派遣器（Dispatcher），優(yōu)化器優(yōu)化完查詢之后，查詢派遣器派遣計(jì)劃到各個(gè)節(jié)點(diǎn)上執(zhí)行，并協(xié)調(diào)查詢執(zhí)行的整個(gè)過(guò)程。查詢派遣器是整個(gè)并行系統(tǒng)的粘合劑。
7. 元數(shù)據(jù)服務(wù)（Catalog Service），負(fù)責(zé)存儲(chǔ)HAWQ的各類元數(shù)據(jù)，包括數(shù)據(jù)庫(kù)和表信息，以及訪問(wèn)權(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í)候會(huì)啟動(dòng)多個(gè)QE (Query Executor, 查詢執(zhí)行器)。查詢執(zhí)行器運(yùn)行在資源容器里面。節(jié)點(diǎn)間數(shù)據(jù)交換經(jīng)過(guò)Interconnect（高速互聯(lián)網(wǎng)絡(luò)）進(jìn)行。

• 優(yōu)點(diǎn)：

1. 對(duì)SQL標(biāo)準(zhǔn)的完善支持：ANSI SQL標(biāo)準(zhǔn)，OLAP擴(kuò)展，標(biāo)準(zhǔn)JDBC/ODBC支持。
2. 支持ACID事務(wù)特性：這是很多現(xiàn)有基于Hadoop的SQL引擎做不到的，對(duì)保證數(shù)據(jù)一致性很重要。
3. 動(dòng)態(tài)數(shù)據(jù)流引擎：基于UDP的高速互聯(lián)網(wǎng)絡(luò)。
4. 多種UDF（用戶自定義函數(shù)）語(yǔ)言支持：java, python, c/c++, perl, R等。
5. 動(dòng)態(tài)擴(kuò)容：動(dòng)態(tài)按需擴(kuò)容，按照存儲(chǔ)大小或者計(jì)算需求，秒級(jí)添加節(jié)點(diǎn)。
6. 支持MADlib機(jī)器學(xué)習(xí)。

• 缺點(diǎn)：

1. 基于GreenPlum實(shí)現(xiàn)，技術(shù)實(shí)現(xiàn)復(fù)雜，包含多個(gè)組件。比如對(duì)于外部數(shù)據(jù)源，需要通過(guò)PXF單獨(dú)進(jìn)行處理；
2. C++實(shí)現(xiàn)，對(duì)內(nèi)存的控制比較復(fù)雜，如果出現(xiàn)segmentfault直接導(dǎo)致當(dāng)前node掛掉。
3. 安裝配置復(fù)雜；

2.3.3 Impala

Impala是Cloudera在受到Google的Dremel啟發(fā)下開(kāi)發(fā)的實(shí)時(shí)交互SQL大數(shù)據(jù)查詢工具。

Impala采用MPP架構(gòu)，與存儲(chǔ)引擎解耦：

1. impalad（實(shí)例*N）: 接收client、hue、jdbc或者odbc請(qǐng)求。每當(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)來(lái)并行化查詢，所有查詢結(jié)果返回給中心協(xié)調(diào)節(jié)點(diǎn)。
2. StateStore（實(shí)例*1）: 負(fù)責(zé)收集分布在各個(gè)Impalad進(jìn)程的資源信息、各節(jié)點(diǎn)健康狀況，同步節(jié)點(diǎn)信息；
3. 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適合于長(zhǎng)時(shí)間的批處理查詢分析，而Impala適合于實(shí)時(shí)交互式SQL查詢。
• Hive: 復(fù)雜的批處理查詢?nèi)蝿?wù)，數(shù)據(jù)轉(zhuǎn)換任務(wù)。
• Impala：實(shí)時(shí)數(shù)據(jù)分析，因?yàn)椴恢С諹DF，能處理的問(wèn)題域有一定的限制。
• Hive: 依賴于Hadoop的容錯(cuò)能力。
• Impala: 在查詢過(guò)程中，沒(méi)有容錯(cuò)邏輯，如果在執(zhí)行過(guò)程中發(fā)生故障，則直接返回錯(cuò)誤（這與Impala的設(shè)計(jì)有關(guān)，因?yàn)镮mpala定位于實(shí)時(shí)查詢，一次查詢失敗， 再查一次就好了，再查一次的成本很低）。
• Hive: 任務(wù)調(diào)度依賴于Hadoop的調(diào)度策略。
• Impala: 調(diào)度由自己完成，目前只有一種調(diào)度器simple-schedule，它會(huì)盡量滿足數(shù)據(jù)的局部性，掃描數(shù)據(jù)的進(jìn)程盡量靠近數(shù)據(jù)本身所在的物理機(jī)器。調(diào)度器目前還比較簡(jiǎn)單，還沒(méi)有考慮負(fù)載，網(wǎng)絡(luò)IO狀況等因素進(jìn)行調(diào)度。但目前 Impala已經(jīng)有對(duì)執(zhí)行過(guò)程的性能統(tǒng)計(jì)分析，應(yīng)該以后版本會(huì)利用這些統(tǒng)計(jì)信息進(jìn)行調(diào)度吧。
• Hive: 在執(zhí)行過(guò)程中如果內(nèi)存放不下所有數(shù)據(jù)，則會(huì)使用外存，以保證Query能順序執(zhí)行完。每一輪MapReduce結(jié)束，中間結(jié)果也會(huì)寫入HDFS中，同樣由于MapReduce執(zhí)行架構(gòu)的特性，shuffle過(guò)程也會(huì)有寫本地磁盤的操作。
• Impala: 在遇到內(nèi)存放不下數(shù)據(jù)時(shí)，當(dāng)前版本1.0.1是直接返回錯(cuò)誤，而不會(huì)利用外存。這使用得Impala目前處理Query會(huì)受到一 定的限制。Impala在多個(gè)階段之間利用網(wǎng)絡(luò)傳輸數(shù)據(jù)，在執(zhí)行過(guò)程不會(huì)有寫磁盤的操作（insert除外）。
• Hive: 采用推的方式，每一個(gè)計(jì)算節(jié)點(diǎn)計(jì)算完成后將數(shù)據(jù)主動(dòng)推給后續(xù)節(jié)點(diǎn)。
• Impala: 采用拉的方式，后續(xù)節(jié)點(diǎn)通過(guò)getNext主動(dòng)向前面節(jié)點(diǎn)要數(shù)據(jù)，以此方式數(shù)據(jù)可以流式的返回給客戶端，且只要有1條數(shù)據(jù)被處理完，就可以立即展現(xiàn)出來(lái)，而不用等到全部處理完成，更符合SQL交互式查詢使用。
• Hive: 依賴于MapReduce執(zhí)行框架，執(zhí)行計(jì)劃分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一個(gè)Query會(huì) 被編譯成多輪MapReduce，則會(huì)有更多的寫中間結(jié)果。由于MapReduce執(zhí)行框架本身的特點(diǎn)，過(guò)多的中間過(guò)程會(huì)增加整個(gè)Query的執(zhí)行時(shí)間。
• Impala: 把執(zhí)行計(jì)劃表現(xiàn)為一棵完整的執(zhí)行計(jì)劃樹(shù)，可以更自然地分發(fā)執(zhí)行計(jì)劃到各個(gè)Impalad執(zhí)行查詢，而不用像Hive那樣把它組合成管道型的 map->reduce模式，以此保證Impala有更好的并發(fā)性和避免不必要的中間sort與shuffle。
1. 數(shù)據(jù)存儲(chǔ)：使用相同的存儲(chǔ)數(shù)據(jù)池都支持把數(shù)據(jù)存儲(chǔ)于HDFS, HBase。
2. 元數(shù)據(jù)：兩者使用相同的元數(shù)據(jù)。
3. SQL解釋處理：比較相似都是通過(guò)詞法分析生成執(zhí)行計(jì)劃。
4. 執(zhí)行計(jì)劃：
5. 數(shù)據(jù)流：
6. 內(nèi)存使用：
7. 調(diào)度：
8. 容錯(cuò)：
9. 適用面：
• 優(yōu)點(diǎn)：
1. 支持SQL查詢，快速查詢大數(shù)據(jù)。
2. 可以對(duì)已有數(shù)據(jù)進(jìn)行查詢，減少數(shù)據(jù)的加載，轉(zhuǎn)換。
3. 多種存儲(chǔ)格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。
4. 可以與Hive配合使用。
• 缺點(diǎn)：
1. 不支持用戶定義函數(shù)UDF。
2. 不支持text域的全文搜索。
3. 不支持Transforms。
4. 不支持查詢期的容錯(cuò)。
5. 對(duì)內(nèi)存要求高。

2.3.4 Drill

Drill是MapR開(kāi)源的一個(gè)低延遲的大數(shù)據(jù)集的分布式SQL查詢引擎，是谷歌Dremel的開(kāi)源實(shí)現(xiàn)。它支持對(duì)本地文件、HDFS、HBASE等數(shù)據(jù)進(jìn)行數(shù)據(jù)查詢，也支持對(duì)如JSON等schema-free的數(shù)據(jù)進(jìn)行查詢。

從架構(gòu)上看，與同是源自Dremel的Impala比較類似。Drill的核心是DrillBit，它主要負(fù)責(zé)接收客戶端的請(qǐng)求，處理查詢，并將結(jié)果返回給客戶端。Drill的查詢流程包括以下步驟：

1. Drill客戶端發(fā)起查詢，任意DrilBit都可以接受來(lái)自客戶端的查詢
2. 收到請(qǐng)求的DrillBit成為驅(qū)動(dòng)節(jié)點(diǎn)（Foreman），對(duì)查詢進(jìn)行分析優(yōu)化生成執(zhí)行計(jì)劃，之后將執(zhí)行計(jì)劃劃分成各個(gè)片段（Fragment），并確定合適的節(jié)點(diǎn)來(lái)執(zhí)行。
3. 各個(gè)節(jié)點(diǎn)執(zhí)行查詢片段（Fragment），并將結(jié)果返回給驅(qū)動(dòng)節(jié)點(diǎn)
4. 驅(qū)動(dòng)節(jié)點(diǎn)將結(jié)果返回給客戶端

• 優(yōu)點(diǎn)：

1. 能夠自動(dòng)解析數(shù)據(jù)（json，text，parquet）的結(jié)構(gòu)。
2. 支持自定義的嵌套數(shù)據(jù)集，數(shù)據(jù)靈活,，支持查詢復(fù)雜的半結(jié)構(gòu)化數(shù)據(jù)。
3. 與Hive一體化（Hive表和視圖的查詢，支持所有的Hive文件格式和HiveUDFS）。
4. 支持多數(shù)據(jù)源，包括NoSQL數(shù)據(jù)庫(kù)。
5. 可以方便的與第三方BI工具對(duì)接。

• 缺點(diǎn)：

1. SQL語(yǔ)法和常規(guī)SQL有區(qū)別,一般是如“select * from 插件名.表名”的形式。
2. 安裝部署比較復(fù)雜。
3. GC機(jī)制還有待提高。

2.4 基于通用計(jì)算框架的SQL引擎分析

2.4.1 SparkSQL

Spark SQL與傳統(tǒng) DBMS 的查詢優(yōu)化器 + 執(zhí)行器的架構(gòu)較為類似，只不過(guò)其執(zhí)行器是在分布式環(huán)境中實(shí)現(xiàn)，并采用的 Spark 作為執(zhí)行引擎：

Spark SQL 的查詢優(yōu)化是Catalyst，Catalyst 將 SQL 語(yǔ)言翻譯成最終的執(zhí)行計(jì)劃，并在這個(gè)過(guò)程中進(jìn)行查詢優(yōu)化。這里和傳統(tǒng)不太一樣的地方就在于， SQL 經(jīng)過(guò)查詢優(yōu)化器最終轉(zhuǎn)換為可執(zhí)行的查詢計(jì)劃是一個(gè)查詢樹(shù)，傳統(tǒng) DB 就可以執(zhí)行這個(gè)查詢計(jì)劃了。而 Spark SQL 最后執(zhí)行還是會(huì)在 Spark 內(nèi)將這棵執(zhí)行計(jì)劃樹(shù)轉(zhuǎn)換為 Spark 的有向無(wú)環(huán)圖DAG 再執(zhí)行。

• 優(yōu)點(diǎn)：

1. 將sql查詢與spar無(wú)縫融合
2. 兼容HiveQL

• 缺點(diǎn)：

1. 查詢性能不高
2. 以thrift server方式提供的SparkSQL服務(wù)不支持多種數(shù)據(jù)源，必須使用DataFrame API。

2.4.2 Hive

Hive是一個(gè)構(gòu)建于Hadoop頂層的數(shù)據(jù)倉(cāng)庫(kù)工具。定義了簡(jiǎn)單的類似SQL 的查詢語(yǔ)言——HiveQL，可以將HiveQL查詢轉(zhuǎn)換為MapReduce 的任務(wù)在Hadoop集群上執(zhí)行。

• 優(yōu)點(diǎn)：

1. 高可靠、高容錯(cuò)：HiveServer采用集群模式。雙MetaStor。超時(shí)重試機(jī)制。
2. 類SQL：類似SQL語(yǔ)法，內(nèi)置大量函數(shù)。
3. 可擴(kuò)展：自定義存儲(chǔ)格式，自定義函數(shù)。
4. 多接口：Beeline，JDBC，ODBC，Python，Thrift。

• 缺點(diǎn)：

1. 延遲較高：默認(rèn)MR為執(zhí)行引擎，MR延遲較高。
2. 不支持物化視圖：Hive支持普通視圖，不支持物化視圖。Hive不能再視圖上更新、插入、刪除數(shù)據(jù)。
3. 不適用OLTP：暫不支持列級(jí)別的數(shù)據(jù)添加、更新、刪除操作。

2.5 各組件性能對(duì)比

測(cè)試數(shù)據(jù)來(lái)源于：開(kāi)源OLAP引擎測(cè)評(píng)報(bào)告。通過(guò)測(cè)試以及相關(guān)調(diào)研編寫了各組件各個(gè)方面的綜合對(duì)比分析表，這里采用5分為滿分來(lái)比較，如下表：

1. SparkSQL是Hadoop中另一個(gè)著名的SQL引擎，它以Spark作為底層計(jì)算框架，Spark使用RDD作為分布式程序的工作集合，它提供一種分布式共享內(nèi)存的受限形式。在分布式共享內(nèi)存系統(tǒng)中，應(yīng)用可以向全局地址空間的任意位置進(jìn)行讀寫作，而RDD是只讀的，對(duì)其只能進(jìn)行創(chuàng)建、轉(zhuǎn)化和求值等作。這種內(nèi)存操作大大提高了計(jì)算速度。SparkSql的性能相對(duì)其他的組件要差一些，多表單表查詢性能都不突出。
2. Impala官方宣傳其計(jì)算速度是一大優(yōu)點(diǎn)，在實(shí)際測(cè)試中我們也發(fā)現(xiàn)它的多表查詢性能和presto差不多，但是單表查詢方面卻不如presto好。而且Impala有很多不支持的地方，例如：不支持update、delete操作，不支持Date數(shù)據(jù)類型，不支持ORC文件格式等等，所以我們查詢時(shí)采用parquet格式進(jìn)行查詢，而且Impala在查詢時(shí)占用的內(nèi)存很大。
3. Presto綜合性能比起來(lái)要比其余組件好一些，無(wú)論是查詢性能還是支持的數(shù)據(jù)源和數(shù)據(jù)格式方面都要突出一些，在單表查詢時(shí)性能靠前，多表查詢方面性能也很突出。由于Presto是完全基于內(nèi)存的并行計(jì)算，所以presto在查詢時(shí)占用的內(nèi)存也不少，但是發(fā)現(xiàn)要比Impala少一些，比如多表join需要很大的內(nèi)存，Impala占用的內(nèi)存比presto要多。
4. HAWQ 吸收了先進(jìn)的基于成本的 SQL 查詢優(yōu)化器，自動(dòng)生成執(zhí)行計(jì)劃，可優(yōu)化使用hadoop 集群資源。HAWQ 采用 Dynamic pipelining 技術(shù)解決這一關(guān)鍵問(wèn)題。Dynamic pipelining 是一種并行數(shù)據(jù)流框架，利用線性可擴(kuò)展加速Hadoop查詢，數(shù)據(jù)直接存儲(chǔ)在HDFS上，并且其SQL查詢優(yōu)化器已經(jīng)為基于HDFS的文件系統(tǒng)性能特征進(jìn)行過(guò)細(xì)致的優(yōu)化。但是我們發(fā)現(xiàn)HAWQ在多表查詢時(shí)比Presto、Impala差一些；而且不適合單表的復(fù)雜聚合操作，單表測(cè)試性能方面要比其余四種組件差很多，hawq環(huán)境搭建也遇到了諸多問(wèn)題。
5. ClickHouse 作為目前所有開(kāi)源MPP計(jì)算框架中計(jì)算速度最快的，它在做多列的表，同時(shí)行數(shù)很多的表的查詢時(shí)，性能是很讓人興奮的，但是在做多表的join時(shí)，它的性能是不如單寬表查詢的。性能測(cè)試結(jié)果表明ClickHouse在單表查詢方面表現(xiàn)出很大的性能優(yōu)勢(shì)，但是在多表查詢中性能卻比較差，不如presto、impala、hawq的效果好。
6. GreenPlum作為關(guān)系型數(shù)據(jù)庫(kù)產(chǎn)品，它的特點(diǎn)主要就是查詢速度快，數(shù)據(jù)裝載速度快，批量DML處理快。而且性能可以隨著硬件的添加，呈線性增加，擁有非常良好的可擴(kuò)展性。因此，它主要適用于面向分析的應(yīng)用。比如構(gòu)建企業(yè)級(jí)ODS/EDW，或者數(shù)據(jù)集市等，GREENPLUM都是不錯(cuò)的選擇。