主流開源分析引擎梳理，看看你最中意誰？| StoneDB數(shù)據(jù)庫觀察
編者薦語：
本文來自石原子合伙人祁國輝老師，主要對主流的開源分析引擎進行詳盡的分析，干貨滿滿，歡迎大家閱讀學(xué)習(xí)。
以下文章來源于ITPUB?，作者祁國輝
最近一段時間，我重新梳理了一下目前市面上主流的數(shù)據(jù)分析引擎， 發(fā)現(xiàn)真是琳瑯滿目， 令人眼花繚亂。靜下心來花了兩周時間橫向看了一下， 學(xué)習(xí)過程中， 記了一些筆記， 希望能夠幫到大家。
作者?|?祁國輝
責(zé)編?|?韓? ?楠
封面&編輯?| 宇亭
總體來講，分析下來， 基本脈絡(luò)來自兩個方向：一個是MPP數(shù)據(jù)庫的大規(guī)模并行；另外一個方向來自于SQL on Hadoop。
結(jié)合這兩條主線， 各個產(chǎn)品在不同地方做了一些優(yōu)化和取舍， 比如Kylin和Mesa的預(yù)計算， 比如大家ClickHouse的大寬表。
當(dāng)然各家也都有一些共性，可謂是八仙過海， 各顯神通。比如大家都開始盡量向標(biāo)準(zhǔn)SQL靠攏， 以屏蔽底層的技術(shù)復(fù)雜性。另外基于表組的ORC或者parquet的列式數(shù)據(jù)存儲，提高OLAP查詢時的IO效率，基于松耦合集群的架構(gòu)，來支持海量數(shù)據(jù)下的橫向擴展能力。說明在OLAP分析中的關(guān)鍵技術(shù)也基本上開始趨同。
而下一代的技術(shù)比如向量化執(zhí)行， AI4DB、serverless、內(nèi)存池化等基于最新技術(shù)的云化數(shù)倉， 也將成為下一階段大家發(fā)力的方向。
01 Greenplum
業(yè)界最著名的開源MPP數(shù)據(jù)庫，基于PostgreSQL，其架構(gòu)核心是采用無共享的MPP架構(gòu)，主要用于數(shù)據(jù)分析OLAP。2010年被EMC收購，于2015年開源，擁有完整的生態(tài)。
圖源：Docs.greenplum.org
Greenplum主要由Master節(jié)點、Segment節(jié)點、interconnect三大部分組成。
Greenplum master是Greenplum數(shù)據(jù)庫系統(tǒng)的入口，接受客戶端連接及提交的SQL語句，將工作負(fù)載分發(fā)給其他數(shù)據(jù)庫實例（segment實例），由它們存儲和處理數(shù)據(jù)。
Greenplum interconnect負(fù)責(zé)不同PostgreSQL實例之間的通信。
Greenplum segment是獨立的PostgreSQL數(shù)據(jù)庫，每個segment存儲一部分?jǐn)?shù)據(jù)。大部分查詢處理都由segment完成。每個Segment存放一部分用戶數(shù)據(jù)，但是用戶不能直接訪問Segment，所有對Segment的訪問都必須經(jīng)過Master。
Master節(jié)點不存放任何用戶數(shù)據(jù)，只是對客戶端進行訪問控制以及存儲表分布邏輯的元數(shù)據(jù)，Segment節(jié)點負(fù)責(zé)數(shù)據(jù)的存儲，可以對分布鍵進行優(yōu)化以充分利用Segment節(jié)點的IO性能來擴展整集群的IO性能，Segment節(jié)點越多，數(shù)據(jù)就會打得越散，處理速度就越快。
存儲方式可以根據(jù)數(shù)據(jù)熱度 或者訪問模式的不同而使用不同的存儲方式。一張表的不同數(shù)據(jù)可以使用不同的物理存儲方式：行存儲、列存儲、外部表。
GreenPlum 屬于比較早期開源的數(shù)據(jù)倉庫產(chǎn)品， 使用的用戶很多， 優(yōu)缺點簡要分析如下：
優(yōu)點：
支持標(biāo)準(zhǔn)SQL 語法，使用簡單，與上下游工具無縫集成，利用PG生態(tài)， 易于運維管理；
支持行列混存， 支持?jǐn)?shù)據(jù)壓縮；
性能優(yōu)異，利用MPP架構(gòu)， 充分發(fā)揮并行能力。
缺點：
多個PG數(shù)據(jù)庫的組合， 部署在開放平臺上，穩(wěn)定性不足；
查詢沒有利用到分片鍵， 可能導(dǎo)致大量數(shù)據(jù)跨節(jié)點傳輸， 性能會有所下降；
因為任何一個任務(wù)都會在每個節(jié)點并行執(zhí)行， 整個系統(tǒng)并發(fā)能力受單節(jié)點處理能力影響。
02 HAWQ
談到GreeenPlum ，就不得不提一下HAWQ， 因為HAWQ是和GreenPlum同源的， 都是由Pivotal公司研發(fā)的， 為什么叫HAWQ， 是因為它的名字叫Hadoop with Query。它是用Hadoop替換了GreenPlum中的MPP和sharenothing的數(shù)據(jù)存儲。
HAWQ是一個Hadoop原生大規(guī)模并行SQL分析引擎，目前大家使用的是Apache開源的最新的2.0 Alpha版本，數(shù)據(jù)直接存儲在HDFS上，并且SQL查詢優(yōu)化器中已經(jīng)為基于HDFS的文件系統(tǒng)性能特征進行過細(xì)致的優(yōu)化。
SQL on Hadoop的主要設(shè)計目標(biāo)是：在Hadoop上執(zhí)行SQL連接時，最大程度地降低數(shù)據(jù)傳輸?shù)拈_銷。HAWQ 采用Dynamic pipelining來解決這一關(guān)鍵要求，使基于HDFS的數(shù)據(jù)適用于交互式查詢。HAWQ要比現(xiàn)有Hadoop查詢引擎快一或兩個數(shù)量級。這些性能改進主要歸功于Dynamic pipelining和HAWQ內(nèi)基于成本的查詢優(yōu)化器的強大功能。
圖源：https://hawq.apache.org/docs/
Apache HAWQ 采用主從（Master-Segment）的改進MPP架構(gòu)。一個典型的Apache HAWQ集群是分布式部署在多個服務(wù)器節(jié)點上，如多個物理機或多個虛擬機。在HAWQ Master端，Apache HAWQ提供集中的元數(shù)據(jù)管理并接受所有客戶端連接的請求，當(dāng)一個客戶端的數(shù)據(jù)計算請求以SQL形式發(fā)送到Master后，被優(yōu)化的分布式執(zhí)行計劃被生成并派發(fā)到多個Segment服務(wù)器運行，計算由多個執(zhí)行器進程（QE）實現(xiàn)并行計算。
存儲由Hadoop HDFS提供服務(wù)，絕大多數(shù)情況下Segment服務(wù)器將使用本地HDFS DataNode服務(wù)實現(xiàn)數(shù)據(jù)存取。集群的計算資源由Master端的資源管理器統(tǒng)一調(diào)度，并以資源容器的形式在Segment端體現(xiàn)。
HAWQ的主要優(yōu)缺點總結(jié)如下：
優(yōu)點：
完善的Sql支持；
原生Hadoop支持，利用YARN，能和各類Hadoop生態(tài)組件進行整合，支持各類常見的文件格式；
優(yōu)異的OLAP查詢性能， 利用 Pivotal Orca優(yōu)化器， 性能上表現(xiàn)不錯；
先進的架構(gòu)， 對比傳統(tǒng)MPP， 天生存算分離。
缺點：
安裝配置復(fù)雜；
內(nèi)部技術(shù)實現(xiàn)復(fù)雜， 要達到最佳性能， 還是需要內(nèi)部表。
03 Hive
Hive是基于Hadoop構(gòu)建的一套數(shù)據(jù)倉庫分析系統(tǒng)，它提供了豐富的SQL查詢方式來分析存儲在Hadoop分布式文件系統(tǒng)中的數(shù)據(jù)。由Facebook研發(fā)。
Hive 的計算基于 Hadoop 實現(xiàn)的一個特別的計算模型 MapReduce，它可以將計算任務(wù)分割成多個處理單元，然后分散到一批家用或服務(wù)器級別的硬件機器上，降低成本并提高水平擴展性。
Hive 的數(shù)據(jù)存儲在 Hadoop 一個分布式文件系統(tǒng)上，即 HDFS。用戶輸入SQL后，Hive會將其翻譯成MapReduce或者Spark任務(wù)，提交到Y(jié)arn上面執(zhí)行，執(zhí)行成功將返回結(jié)果。
圖源：https://cwiki.apache.org/confluence/display/Hive/Design
Hive比較適合離線處理，因為它把SQL轉(zhuǎn)MapReduce執(zhí)行響應(yīng)速度較慢，Hive 發(fā)展很快，例如查詢優(yōu)化方面采用了 CBO，在執(zhí)行引擎方面用 Tez 來替換 MapReduce，通過 LLAP 來 cache 查詢結(jié)果做優(yōu)化，利用DAG減少落盤次數(shù)來提速，以及 ORC 存儲不斷演進。
不過相比較而言，這些新技術(shù)從市場應(yīng)用來說還不算成熟穩(wěn)定，Hive 仍然被大量用戶定義為可靠的 ETL 工具而非即時查詢產(chǎn)品。
Hive在0.14以后的版本支持事務(wù)，前提是文件格式為 orc 格式，同時必須分桶，還必須顯式聲明 transactional=true。
優(yōu)缺點分析：
優(yōu)點：
最基礎(chǔ)的一款Hadoop數(shù)據(jù)倉庫產(chǎn)品，更夠部署在所有Hadoop發(fā)行版本之上；
目前大多數(shù)其他技術(shù)都搭建在Hive之上，基于MR之上， 封裝了SQL支持；
系統(tǒng)穩(wěn)定， HQL使用者眾多。
缺點：
Hive不支持事務(wù)，一般用于讀多寫少的情況，不建議改動數(shù)據(jù)，因為數(shù)據(jù)存儲在HDFS中，而HDFS的文件不支持修改；
Hive延遲比較大，因其底層是MapReduce，執(zhí)行效率較慢。但當(dāng)數(shù)據(jù)規(guī)模較大的情況下，Hive的并行計算優(yōu)勢就體現(xiàn)出來了；
Hive不支持索引，查詢的時候是全表掃描，這也是其延遲大的原因之一。
Hive 雖然存在性能上的問題，直接使用不多，但是現(xiàn)在基本上作為SQL on Hadoop的基礎(chǔ)組件， 在大數(shù)據(jù)家族中使用非常廣泛。
04 Impala
Impala由Cloudera公司開發(fā)，提供SQL語義，可查詢存儲在Hadoop和HBase上的PB級海量數(shù)據(jù)。
Impala作為新一代開源大數(shù)據(jù)分析引擎，最初參照Dremel（由Google開發(fā)的交互式數(shù)據(jù)分析系統(tǒng)），支持實時計算，提供與Hive類似的功能，在性能上高出Hive3~30倍。Impala可能會超過Hive的使用率能成為Hadoop上最流行的實時計算平臺。
Impala采用與商用并行關(guān)系數(shù)據(jù)庫類似的分布式查詢引擎，可直接從HDFS、HBase中用SQL語句查詢數(shù)據(jù)，不需把SQL語句轉(zhuǎn)換成MR任務(wù)，降低延遲，可很好地滿足實時查詢需求。
Impala不能替換Hive，可提供一個統(tǒng)一的平臺用于實時查詢。Impala的運行依賴于Hive的元數(shù)據(jù)（Metastore）。Impala和Hive采用相同的SQL語法、ODBC驅(qū)動程序和用戶接口，可統(tǒng)一部署Hive和Impala等分析工具，同時支持批處理和實時查詢。
Impala經(jīng)常搭配存儲引擎Kudu一起提供服務(wù)，這么做最大的優(yōu)勢是查詢比較快，并且支持?jǐn)?shù)據(jù)的Update和Delete。
Impala是采用MPP架構(gòu)的查詢引擎，本身不存儲任何數(shù)據(jù)，直接使用內(nèi)存進行計算，兼顧數(shù)據(jù)倉庫，具有實時、批處理、多并發(fā)等優(yōu)點。
圖源?https://www.w3cschool.cn/impala/impala_architecture.html
上圖是Impala系統(tǒng)結(jié)構(gòu)圖，Impala和Hive、HDFS、HBase統(tǒng)一部署在Hadoop平臺上。Impala由Impalad、State Store和Interfaces幾個部分組成。
Implalad：是Impala的一個進程，負(fù)責(zé)協(xié)調(diào)客戶端提供的查詢執(zhí)行，給其他Impalad分配任務(wù)，以及收集其他Impalad的執(zhí)行結(jié)果進行匯總。Impalad也會執(zhí)行其他Impalad給其分配的任務(wù)，主要是對本地HDFS和HBase里的部分?jǐn)?shù)據(jù)進行操作。Impalad進程主要含Query Planner、Query Coordinator和Query Exec Engine三個模塊，與HDFS的數(shù)據(jù)節(jié)點（HDFS DataNode）運行在同一節(jié)點上，且完全分布運行在MPP（大規(guī)模并行處理系統(tǒng)）架構(gòu)上。
State Store：收集分布在集群上各個Impalad進程的資源信息，用于查詢的調(diào)度，它會創(chuàng)建一個statestored進程，來跟蹤集群中的Impalad的健康狀態(tài)及位置信息。State stored進程通過創(chuàng)建多個線程來處理Impalad的注冊訂閱以及與多個Impalad保持心跳連接，此外，各Impalad都會緩存一份State Store中的信息。當(dāng)State Store離線后，Impalad一旦發(fā)現(xiàn)State Store處于離線狀態(tài)時，就會進入恢復(fù)模式，并進行返回注冊。當(dāng)State Store重新加入集群后，自動恢復(fù)正常，更新緩存數(shù)據(jù)。
Interfaces：Interfaces給用戶提供了執(zhí)行查詢的命令行工具。Impala還提供了Hue、shell、JDBC及ODBC使用接口。
Impala的查詢過程也是典型的MPP架構(gòu)，當(dāng)用戶提交查詢前，Impala先創(chuàng)建一個Impalad進程來負(fù)責(zé)協(xié)調(diào)客戶端提交的查詢，該進程會向State Store提交注冊訂閱信息，State Store會創(chuàng)建一個statestored進程，statestored進程通過創(chuàng)建多個線程來處理Impalad的注冊訂閱信息。通過CLI提交一個查詢到Impalad進程，Impalad的Query Planner對SQL語句解析，生成解析樹；Planner將解析樹變成若干PlanFragment，發(fā)送到Query Coordinator。
圖源?https://www.cnblogs.com/mephisto/p/6921663.html
其中PlanFragment由PlanNode組成，能被分發(fā)到單獨的節(jié)點上執(zhí)行，每個PlanNode表示一個關(guān)系操作和對其執(zhí)行優(yōu)化需要的信息。Query Coordinator從MySQL元數(shù)據(jù)庫中獲取元數(shù)據(jù)（即查詢需要用到哪些數(shù)據(jù)），從HDFS的名稱節(jié)點中獲取數(shù)據(jù)地址（即數(shù)據(jù)被保存到哪個數(shù)據(jù)節(jié)點上），從而得到存儲這個查詢相關(guān)數(shù)據(jù)的所有數(shù)據(jù)節(jié)點。
Query Coordinator初始化相應(yīng)的Impalad上的任務(wù)，即把查詢?nèi)蝿?wù)分配給所有存儲這個查詢相關(guān)數(shù)據(jù)的數(shù)據(jù)節(jié)點。Query Executor通過流式交換中間輸出，并由Query Coordinator匯聚來自各個Impalad的結(jié)果。
最后Query Coordinator把匯總后的結(jié)果返回給CLI客戶端。
優(yōu)缺點分析：
優(yōu)點：
基于內(nèi)存運算，不需要把中間結(jié)果寫入磁盤，省掉了大量的I/O開銷；
無需轉(zhuǎn)換為Mapreduce，直接訪問存儲在HDFS，HBase中的數(shù)據(jù)進行作業(yè)調(diào)度；
速度快。使用了支持Data locality的I/O調(diào)度機制，盡可能地將數(shù)據(jù)和計算分配在同一臺機器上進行，減少了網(wǎng)絡(luò)開銷；
支持各種文件格式，如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet?？梢栽L問Hive的metastore，對hive數(shù)據(jù)直接做數(shù)據(jù)分析。
缺點：
對內(nèi)存的依賴大，且完全依賴于Hive；
實踐中，分區(qū)過大會造成性能嚴(yán)重下降；
只能讀取文本文件，不能直接讀取自定義二進制文件。
05 Spark
2009年，加州大學(xué)伯克利分校的AMP實驗室，誕生了一個叫做Spark的項目。該項目在2013年成為了Apache的孵化項目，并以極快的速度成為了一個備受歡迎和關(guān)注的頂級項目。
Spark項目的初衷是為了代替MapReduce，提供一種既可以極大批量地處理分布式的數(shù)據(jù)，又有足夠的容錯能力，且上手容易，速度快，可以讓人實現(xiàn)實時交互分析的解決方案。既支持作業(yè)任務(wù)處理，又支持流處理（SparkStreaming）和SQL（SparkSQL），以及機器學(xué)習(xí)和圖處理，社區(qū)生態(tài)活躍。
Hive是提供了一個SQL on hadoop的機制， 使得基于Hadoop的查詢變得容易很多， 但是因為Hive底層仍然是使用Map/Reduce的方法， 所以在過程中需要把大量的中間結(jié)果保存在磁盤中，因而整體的性能偏慢。
而 Spark 沒有像 Hive 一樣使用磁盤讀寫，而轉(zhuǎn)用性能高得多的內(nèi)存存儲輸入數(shù)據(jù)、處理中間結(jié)果，以及存儲最終結(jié)果。在大數(shù)據(jù)的場景中，很多計算都有循環(huán)往復(fù)的特點，像 Spark 這樣允許在內(nèi)存中緩存輸入輸出，上一個 job 的結(jié)果馬上可以被下一個使用，性能自然要比 Hive 好得多。
Spark的技術(shù)核心點在于 彈性分布式數(shù)據(jù)集(RDD，Resilient Distributed Datasets)。RDD是一種分布式的內(nèi)存抽象，允許在大型集群上執(zhí)行基于內(nèi)存的計算(In-Memory Computing)，Spark RDD能夠?qū)?shù)據(jù)cache到內(nèi)存中，省去了從磁盤加載的過程，同時Spark shuffle過程中的數(shù)據(jù)也是直接放在內(nèi)存中的。
RDD是一個分區(qū)的只讀記錄的集合，用戶可以控制RDD的其他兩個方面：持久化和分區(qū)。
一方面用戶可以選擇重用哪個RDD，并為其制定存儲策略(比如，內(nèi)存存儲)， Spark提供了三種對持久化RDD的存儲策略：未序列化Java對象存于內(nèi)存中、序列化后的數(shù)據(jù)存于內(nèi)存、序列化后的數(shù)據(jù)存于磁盤存儲。
另一方面可以讓RDD中的數(shù)據(jù) 根據(jù)記錄的key 分布到集群的多個機器上， 實現(xiàn)分布式內(nèi)存計算。
后來Spark 繼續(xù)擴展，數(shù)據(jù)存儲模式也有了不同的選擇， 數(shù)據(jù)可以存儲成為parquet， 也可存儲在數(shù)據(jù)庫， 當(dāng)然也可以存儲在Hive表上。
通常認(rèn)為，與MR相比spark通過內(nèi)存計算來顯著提速。Spark社區(qū)非常成熟，后面提到的很多平臺或大數(shù)據(jù)組件，都與Spark實現(xiàn)無縫集成。
優(yōu)缺點分析：
優(yōu)點：
速度更快：因為使用內(nèi)存引擎， 數(shù)據(jù)不落地，Spark性能表現(xiàn)非常優(yōu)異；
易用性：提供豐富的API，支持JAVA、Scala、Python和R四種語言；
通用性：Spark提供了大量的庫，包括SQL、DataFrames、MLlib、GraphX和Spark Streaming。開發(fā)人員可以在同一個應(yīng)用程序中無縫地組合這些庫。
缺點：
穩(wěn)定性， 因為大量數(shù)據(jù)在內(nèi)存中計算， 完全依賴java的內(nèi)存回收機制， 長時間運行容易出現(xiàn)故障；
無法支持海量數(shù)據(jù)， 因為要在內(nèi)存中生成RDD， 所以數(shù)據(jù)量受內(nèi)存限制；
不能像SQL一樣， 支持復(fù)雜統(tǒng)計分析。
06 Kylin
Kylin是一個開源的分布式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，最初由eBay Inc. 開發(fā)并貢獻至開源社區(qū)。它能在亞秒內(nèi)查詢巨大的Hive表。核心是預(yù)加載和構(gòu)建cube，cube指定度量維度，Kylin的核心思想是預(yù)計算，利用空間換時間來加速查詢模式固定的OLAP查詢。
Kylin 的理論基礎(chǔ)是 Cube 理論，每一種維度組合稱之為 Cuboid，所有 Cuboid 的集合是 Cube。其中由所有維度組成的 Cuboid 稱為 Base Cuboid，圖中（time，item，location，supplier）即為 Base Cuboid，所有的 Cuboid 都可以基于 Base Cuboid 計算出來。Cuboid 我們可以理解為就是一張預(yù)計算過后的大寬表，在查詢時，Kylin 會自動選擇滿足條件的最合適的 Cuboid來進行加速。
圖源：Apache Kylin | Apache kylin4 新架構(gòu)分享
下圖所示內(nèi)容則描述了Kylin和周邊生態(tài)產(chǎn)品共存的關(guān)系， 以及Kylin內(nèi)部數(shù)據(jù)獲取， 構(gòu)建Cube， 用戶查詢交互和SQL 解析優(yōu)化的全流程。
圖源：Apache Kylin | 大數(shù)據(jù)分析型數(shù)據(jù)倉庫
在目前開源版本的實現(xiàn)中，構(gòu)建完的數(shù)據(jù)是存儲在 HBase 中的，而Hbase的缺點造成很多的局限：
-?運維困難，一旦 HBase 性能不好，那么Kylin的性能也會受到影響。
- HBase 的資源隔離能力也比較弱，Kylin 的性能會受到Hbase上其他大負(fù)載的影響。
- HBase 里存儲的都是經(jīng)過編碼后的 Byte Array 類型，性能優(yōu)化比較困難。
Kylin 4.0中引入了新的架構(gòu)， 支持Spark+ parquet， 通過Spark的并行能力提升性能，不過只在商業(yè)版本中使用， 此處就不再贅述了。
優(yōu)缺點分析：
優(yōu)點：
支持標(biāo)準(zhǔn)SQL接口；
支持超大數(shù)據(jù)集；
超高性能，通過預(yù)計算達到亞秒級響應(yīng)。
缺點：
集群依賴較多，如HBase和Hive等，屬于重量級方案，因此運維成本也較高；
維度變化需要重新刷新數(shù)據(jù)，不適合即席查詢分析；
維度多容易出現(xiàn)數(shù)據(jù)爆炸。
07 Apache Kudu
Kudu是Cloudera開源的運行在hadoop平臺上的列式存儲系統(tǒng)（fast analytics on fast data），核心C++編寫。
它比HDFS和Hbase的優(yōu)勢在于以下亮點：
一是kudu的表結(jié)構(gòu)與關(guān)系型數(shù)據(jù)庫類似，使用簡單；
二是提供高效插入/更新機制，大量隨機讀性能要顯著超過Hbase。
因此可以適用于近實時的分析，快速分析那些快速變化的數(shù)據(jù)。
圖源：Apache Kudu - Introducing Apache Kudu
kudu由master server與tablet server兩部分組成：
master server負(fù)責(zé)集群管理、元數(shù)據(jù)管理等管理工作；
tablet server提供數(shù)據(jù)存儲、數(shù)據(jù)讀寫功能。
上圖顯示了一個具有三個 master 和多個tablet server的Kudu集群，每個服務(wù)器都支持多個tablet。它說明了如何使用 Raft 共識來允許master和tablet server的leader和follow。
此外，tablet server 可以成為某些 tablet 的 leader，也可以是其他 tablet follower。leader以金色顯示，而 follower 則顯示為藍(lán)色。
和HBase采用的LSM方案不同的是，Kudu對同一行的數(shù)據(jù)更新記錄的合并工作是在更新的時候進行，在Kudu中一行數(shù)據(jù)只會存在于一個DiskRowSet中，避免讀操作時的比較合并工作。在Kudu中，對于Flush到磁盤上的DiskRowSet（DRS）數(shù)據(jù)，實際上是分兩種形式存在的：
一種是Base的數(shù)據(jù)，按列式存儲格式存在，一旦生成，就不再修改；
另一種是Delta文件，存儲Base數(shù)據(jù)中有變更的數(shù)據(jù)，一個Base文件可以對應(yīng)多個Delta文件，更新、刪除操作需要記錄到特殊的數(shù)據(jù)結(jié)構(gòu)里，保存在內(nèi)存中的DeltaMemStore或磁盤上的DeltaFIle里面。DeltaMemStore是B-Tree實現(xiàn)的，因此速度快，而且可修改。磁盤上的DeltaFIle是二進制的列式的塊，當(dāng)數(shù)據(jù)頻繁刪改的時候，磁盤上會有大量的DeltaFiles文件，Kudu會定期對這些文件進行合并。??
優(yōu)缺點分析：
優(yōu)點：
使用簡單，kudu的表結(jié)構(gòu)與關(guān)系型數(shù)據(jù)庫類似；
支持高效插入/更新機制，大量隨機讀性能要顯著超過Hbase。
缺點：
并發(fā)支持能力不足；
一般和Impala結(jié)合使用，架構(gòu)復(fù)雜；
國內(nèi)用戶不多。
08 ClickHouse
ClickHouse 是由俄羅斯的第一大搜索引擎 Yandex 公司開源的列存數(shù)據(jù)庫。
ClickHouse 作為開源 OLAP 引擎，因其出色的性能表現(xiàn)在大數(shù)據(jù)生態(tài)中得到了廣泛的應(yīng)用。它使用本地盤來自己管理數(shù)據(jù)，官方推薦使用 SSD 作為存儲介質(zhì)來提升性能。
相比傳統(tǒng)的大數(shù)據(jù)解決方案，ClickHouse 有以下的優(yōu)點：
配置豐富，只依賴于 Zookeeper線性可擴展性；
可以通過添加服務(wù)器擴展集群容錯性高；
不同分片間采用異步多主復(fù)制單表性能極佳；
采用向量計算；
支持采樣和近似計算等優(yōu)化手段功能強大；
支持多種表引擎。
圖源：https://help.aliyun.com/document_detail/167448.html?spm=a2c4g.11174283.6.542.2acb49afFy52rZ
優(yōu)缺點分析：
優(yōu)點：
速度快。ClickHouse性能超過了市面上大部分的列式存儲數(shù)據(jù)庫，相比傳統(tǒng)的數(shù)據(jù)ClickHouse要快100~1000倍，ClickHouse還是有非常大的優(yōu)勢。
功能多。ClickHouse支持?jǐn)?shù)據(jù)統(tǒng)計分析各種場景，支持類SQL查詢，支持多庫函數(shù)（例如 IP轉(zhuǎn)化，URL分析等，預(yù)估計算/HyperLoglog等）支持?jǐn)?shù)組(Array)和嵌套數(shù)據(jù)結(jié)構(gòu)(Nested Data Structure)，支持?jǐn)?shù)據(jù)庫異地復(fù)制部署。
獨立技術(shù)架構(gòu)，部署簡單，可以在目前任何具有x86_64，AArch64或PowerPC64LE CPU架構(gòu)的Linux，F(xiàn)reeBSD或Mac OS X上運行。
缺點：
模型簡單， 因為Clickhouse 對join支持不好，所以一般都是把數(shù)據(jù)拼成一個大寬表來執(zhí)行， 那么一旦需求變換， 或者數(shù)據(jù)分析維度變化， 表中的數(shù)據(jù)必須重新刷新， 帶來巨大的工作量， 同時這種大寬表帶來巨大的數(shù)據(jù)膨脹。
并發(fā)支持不足， Clickhouse 并發(fā)支持能力弱， 在OLAP場景中，一旦出現(xiàn)多個用戶并發(fā)查詢， 查詢性能會受到巨大影響。甚至導(dǎo)致無法返回結(jié)果。
ClickHouse 不支持事務(wù)性的 DDL 與 DML 操作，而且多副本模式的元數(shù)據(jù)管理強依賴于 ZooKeeper，表結(jié)構(gòu)變更時常常出現(xiàn)不同副本之間元數(shù)據(jù)不一致的問題。
多種表引擎帶來選擇困難癥， Clickhouse 提供28種表引擎， 不同表引擎適合不同場景， 不利于新手上手學(xué)習(xí)。
09 Druid
Apache Druid，由美國MetaMarkets公司開發(fā)，后來Apache 基金會孵化而出。它具有如下特性：
實時可見：消息攝入后分鐘級查詢可見；
交互查詢：查詢延時在秒級，核心思想為內(nèi)存計算和并行計算；
維度靈活：支持幾十個維度任意組合，僅在索引時指定的維度查詢可見；
易于變更：需求變更后調(diào)整索引配置立馬生效；
流批一體：新版本 KIS 模式可實現(xiàn) Exactly Once 語義。
圖源：Design · Apache Druid
Druid有幾種不同的Services：
Coordinator 負(fù)責(zé)在集群環(huán)境中的數(shù)據(jù)可用性；
Overlord 控制數(shù)據(jù)裝載workload的分派；
Broker 負(fù)責(zé)承接用戶請求；
Router 可選，負(fù)責(zé)請求的路由， 把響應(yīng)請求分別路由到Broker, Coordinators, 和Overlords；
Historical 負(fù)責(zé)存儲查詢數(shù)據(jù)；
MiddleManager 負(fù)責(zé)數(shù)據(jù)裝載。
Druid 服務(wù)可以按照用戶需求隨意部署，但是為了便于部署， 一般建議按照上圖來部署， 分成幾種服務(wù)器類型: Master, Query, Data。
Master：運行 Coordinator 和 Overlord 服務(wù), 負(fù)責(zé)數(shù)據(jù)的持久化保存和數(shù)據(jù)的裝載的分派；
Query：運行 Broker 和可選的路由服務(wù), 負(fù)責(zé)處理來自客戶端的查詢；
Data：運行Historical 和 MiddleManager 服務(wù)，執(zhí)行數(shù)據(jù)裝載任務(wù)和存儲所有數(shù)據(jù)。
Druid還包含3個外部依賴：
Metadata：存儲Druid中的各種metadata（里面的數(shù)據(jù)都是Druid自身創(chuàng)建和插入的），包含3張表：”druid_config”（通常是空的）, “druid_rules”（coordinator nodes使用的一些規(guī)則信息，比如哪個segment從哪個node去load）和“druid_segments”（存儲每個segment的metadata信息）。
Deep storage：存儲segments，Druid目前已經(jīng)支持本地磁盤，NFS掛載磁盤，HDFS，S3等。Deep Storage的數(shù)據(jù)有2個來源，一個是Batch，另一個是real-time nodes。
ZooKeeper：被Druid用于管理當(dāng)前cluster的狀態(tài)，比如記錄哪些segments從Real-time nodes移到了Historical nodes。
優(yōu)缺點分析：
優(yōu)點：
高性能，低延遲。Druid 能夠?qū)v史和實時數(shù)據(jù)提供亞秒級別的查詢，Druid 支持低延時的數(shù)據(jù)攝取，靈活的數(shù)據(jù)探索分析，高性能的數(shù)據(jù)聚合。
簡便的水平擴展。適用于數(shù)據(jù)量大，可擴展能力要求高的分析型查詢系統(tǒng)。
支持實時數(shù)據(jù)攝入。其機制將熱點和實時數(shù)據(jù)存儲在實時節(jié)點（Realtime Node）內(nèi)存中，將歷史數(shù)據(jù)存儲在歷史節(jié)點（history node）的硬盤中，實時+偽實時的結(jié)構(gòu)，保證查詢基本都在毫秒級。
缺點：
配置和查詢都比較復(fù)雜和繁瑣，維度變更復(fù)雜。
不支持SQL或類SQL接口。對SQL支持的不夠完善， 不支持Join。
支持時序?qū)崟r攝入， 對update支持不足。
10 Presto（Trino）
Presto是由FaceBook開源的一個基于內(nèi)存的MPP計算引擎，主要用以解決 Facebook 海量 Hadoop 數(shù)據(jù)倉庫的低延遲交互分析問題。
Facebook版本的Presto更多的是以解決企業(yè)內(nèi)部需求功能為主，也叫Presto DB，后來，Presto其中的幾個人出來創(chuàng)建了更通用的Presto分支，取名Presto SQL，這個開源版本也是更為被大家通用的版本。再后來，為了更好地與Facebook的Presto DB進行區(qū)分，Presto SQL改名為Trino。?
Presto 適用于交互式分析查詢，可支持眾多的數(shù)據(jù)源，包括 HDFS、RDBMS、KAFKA 等，而且提供了非常友好的接口開發(fā)數(shù)據(jù)源連接器。數(shù)據(jù)規(guī)?？梢灾С諫B到PB級，主要應(yīng)用于處理秒級查詢的場景。
圖源：Presto_SQL_on_Everything.pdf (trino.io)
組件工作模式：
Coordinator ：是一個中心的查詢角色，它主要的一個作用是接受查詢請求，將他們轉(zhuǎn)換成各種各樣的任務(wù)，將任務(wù)拆解后分發(fā)到多個worker去執(zhí)行各種任務(wù)的節(jié)點 ：
解析SQL語句；
生成執(zhí)行計劃 ；
分發(fā)執(zhí)?任務(wù)給Worker節(jié)點執(zhí)行。
Worker ：是一個真正的計算的節(jié)點，執(zhí)行任務(wù)的節(jié)點，它接收到task后，就會到對應(yīng)的數(shù)據(jù)源里面，去把數(shù)據(jù)提取出來；
Connector：負(fù)責(zé)實際執(zhí)?查詢?nèi)蝿?wù)， 通過不同的connector去適配不同的數(shù)據(jù)源；
Discover Services：是將coordinator和woker結(jié)合到一起的服務(wù)，上圖中的Metadata和 Data Location：
Worker節(jié)點啟動后向Discovery Server服務(wù)注冊；
Coordinator從Discovery Server獲得Worker節(jié)點。
Presto是通過connector plugin獲取數(shù)據(jù)和元信息的，它不是一個數(shù)據(jù)存儲引擎，不需要有數(shù)據(jù)，presto為其他數(shù)據(jù)存儲系統(tǒng)提供了SQL能?，客戶端協(xié)議是HTTP+JSON。
優(yōu)缺點分析：
優(yōu)點：
Presto/Trino支持內(nèi)存并行處理、跨集群節(jié)點管線執(zhí)行、多線程執(zhí)行模型、高效的扁平內(nèi)存數(shù)據(jù)結(jié)構(gòu)(最小化Java的垃圾回收)、Java字節(jié)碼生成。超過了Impala和Spark SQL。
支持多源聯(lián)邦查詢，我們的數(shù)據(jù)會儲存在各種各樣的數(shù)據(jù)庫中，以前都需要經(jīng)過ETL抽取到數(shù)據(jù)倉庫中，現(xiàn)在用Presto/Trino在一條SQL中就能直接查詢多個不同數(shù)據(jù)源實現(xiàn)聯(lián)邦查詢，而且SQL語法兼容大部分HiveQL。
支持湖倉一體，減少數(shù)據(jù)倉庫復(fù)雜度：可以去除數(shù)倉的ODS、DWD層，甚至可以不用DWM層，用Presto/Trino連接各種數(shù)據(jù)源，直接清洗出DWS大寬表層。而且維度表也可以使用Presto/Trino直接從源數(shù)據(jù)庫讀取，并使用Presto/Trino向ADS數(shù)據(jù)應(yīng)用層提供服務(wù)。
缺點：
join查詢時，都要使用臨時表。此時就會產(chǎn)生大量的臨時數(shù)據(jù)，所以速度會變慢。
不適合計算太大的數(shù)據(jù)量。
不關(guān)心中間查詢?nèi)蒎e，如果某個節(jié)點失敗，整個查詢也將失敗。
11 Google Mesa
Mesa是一個分布式、多副本的、高可用的數(shù)據(jù)處理、存儲和查詢系統(tǒng)，針對結(jié)構(gòu)化數(shù)據(jù)。一般數(shù)據(jù)從上游服務(wù)產(chǎn)生（比如一個批次的spark streaming作業(yè)產(chǎn)生），在內(nèi)部做數(shù)據(jù)的聚合和存儲。支持近實時更新（與Cube方案比），數(shù)據(jù)分維度列和指標(biāo)列，指標(biāo)列指定聚合函數(shù)。
Mesa能滿足復(fù)雜和具有挑戰(zhàn)性的用戶與系統(tǒng)需求，包括近實時數(shù)據(jù)提取和查詢，同時在海量數(shù)據(jù)和查詢量中保持高可用性、可靠性、容錯率和擴展性。Mesa每秒能處理數(shù)百萬行更新，每天進行數(shù)十億查詢抓取數(shù)萬億行數(shù)據(jù)。Mesa能進行跨數(shù)據(jù)中心復(fù)制，即使在整個數(shù)據(jù)中心故障時，也能以低延遲返回一致和可重復(fù)的查詢結(jié)果。
它的特色類似MOLAP， 對各種關(guān)鍵維度（Key）進行預(yù)先聚合， 用戶查詢直接訪問聚合后的數(shù)據(jù)， 對于數(shù)據(jù)的持續(xù)更新，會在后臺以Micro-batch的方式進行更新， 所有的更新會保存在Delta中， 后臺會根據(jù)一定條件對預(yù)聚合的數(shù)據(jù)核Delta 進行compaction。主要用于Google AD部門。
優(yōu)缺點分析：
優(yōu)點：
近實時的更新吞吐量。支持持續(xù)的更新，每秒支持?jǐn)?shù)百萬行的更新。
同時支持低時延查詢性能和批量大量查詢。99%的查詢在幾百毫秒之內(nèi)返回。
跨數(shù)據(jù)中心備份。
缺點：
僅在Google內(nèi)部使用， 專為Google 廣告業(yè)務(wù)服務(wù)。
市面上相關(guān)材料不多， 用戶也不多。?
Google Mesa的數(shù)據(jù)模型，后來也被百度的廣告部門所采用， 也就產(chǎn)生了下面要提到的這一產(chǎn)品，Apache Doris。
12 Apache Doris
前身是百度2017年開源系統(tǒng)PALO，后貢獻給Apache更名為Doris。Doris 是一個 MPP 的 OLAP 系統(tǒng)，主要整合了 Google Mesa(數(shù)據(jù)模型)，Apache Impala(MPP Query Engine)和 Apache ORCFile (存儲格式，編碼和壓縮) 的技術(shù)。高度兼容Mysql協(xié)議。
元數(shù)據(jù)管理對impala的p2p模式做了更新，Doris 采用 Paxos 協(xié)議以及 Memory + Checkpoint + Journal 的機制來確保元數(shù)據(jù)的高性能及高可靠。
2020 年 2 月，百度 Doris 團隊的開發(fā)人員離職創(chuàng)業(yè)，基于 Apache Doris 之前的版本做了自己的商業(yè)化產(chǎn)品 DorisDB ，后改名為StarRocks。后來StarRocks 也開源了， 所以在此認(rèn)為這兩個產(chǎn)品同源。
圖源：Introduction to Apache Doris - Apache Doris
部署架構(gòu)：分為 FE（前端）和 BE（后端）兩個組件。
圖源：Introduction to Apache Doris - Apache Doris
- FE 負(fù)責(zé)接受用戶請求、優(yōu)化、調(diào)度查詢，由 Java 編寫；對于所有的元數(shù)據(jù)， 保存在內(nèi)置的BerkeleyDB， 并且通過多副本實現(xiàn)高可用。
- BE 負(fù)責(zé)存儲數(shù)據(jù)、執(zhí)行 MPP 計劃中的各個片段，類似于 Worker 的角色，由 C++ 編寫。
優(yōu)缺點分析：
優(yōu)點：
良好的架構(gòu)設(shè)計，支持高并發(fā)低延時的查詢服務(wù)，支持高吞吐量的交互式分析。多FE均可對外提供服務(wù)，并發(fā)增加時，線性擴充FE和BE即可支持高并發(fā)的查詢請求。
性能優(yōu)異：高效的列式存儲引擎，同時 提供豐富的索引結(jié)構(gòu)來加速數(shù)據(jù)讀取與過濾，利用分區(qū)分桶裁剪功能支持在線服務(wù)業(yè)務(wù)的超高并發(fā)，單節(jié)點最高可支持上千 QPS。更進一步，結(jié)合向量化執(zhí)行引擎來提升效率，同時利用物化視圖技術(shù)實現(xiàn)預(yù)聚合加速，同時進行基于規(guī)劃和基于代價的查詢優(yōu)化。
支持批量數(shù)據(jù)load和流式數(shù)據(jù)load，支持?jǐn)?shù)據(jù)更新。支持Update/Delete語法，unique/aggregate數(shù)據(jù)模型，支持動態(tài)更新數(shù)據(jù)，實時更新聚合指標(biāo)。
提供了高可用，容錯處理，高擴展的企業(yè)級特性。FE Leader錯誤異常，F(xiàn)E Follower秒級切換為新Leader繼續(xù)對外提供服務(wù)。支持?jǐn)?shù)據(jù)多副本存儲，集群具備自愈功能，自身的分布式管理框架可以自動管理數(shù)據(jù)副本的分布、修復(fù)和均衡，副本損壞時系統(tǒng)可以自動感知并進行修復(fù)。
支持聚合表和物化視圖。多種數(shù)據(jù)模型，支持aggregate, replace等多種數(shù)據(jù)模型，支持創(chuàng)建rollup表，支持創(chuàng)建物化視圖。rollup表和物化視圖支持動態(tài)更新，無需用戶手動處理。
MySQL協(xié)議兼容，支持直接使用MySQL客戶端連接，非常易用的數(shù)據(jù)應(yīng)用對接。
缺點：
目前Doris 比較搶眼， 尤其是推出全向量化支持之后，但是本身成熟度還有待考驗。
目前國內(nèi)有多個基于Doris的產(chǎn)品， 各自獨立演進，可能會對后期有影響。
13 總結(jié)
開源分析引擎發(fā)展十多年來， 不斷有新的思想加入， 也不斷有新的技術(shù)和產(chǎn)品被世人所接受，每個產(chǎn)品之所以能夠得到大家的認(rèn)可， 必然具有其獨到的一些特點。當(dāng)然，開源產(chǎn)品的共同特色就是優(yōu)點和缺點都非常明顯；在學(xué)習(xí)開源引擎的過程中， 建議大家多去做一些橫向?qū)Ρ龋ㄟ^對比，就可以理解每個產(chǎn)品的優(yōu)勢和短板， 進一步對產(chǎn)品原理有更深入的體會。
下面通過一個簡單的表格來示例：
補充一點：部分資料和架構(gòu)圖均來自網(wǎng)上， 如有侵權(quán)，將做刪除處理。
參考資料：
[1]https://docs.vmware.com/en/VMware-Tanzu-Greenplum/6/greenplum-database/GUID-admin_guide-intro-arch_overview.html
[2]https://hawq.apache.org/docs/userguide/2.3.0.0-incubating/overview/HAWQArchitecture.html
[3]https://cwiki.apache.org/confluence/display/Hive/Design
[4]https://www.w3cschool.cn/impala/impala_architecture.html
[5]Apache Kylin | 大數(shù)據(jù)分析型數(shù)據(jù)倉庫
[6]Apache Kylin | Apache kylin4 新架構(gòu)分享
[7]Apache Kudu - Introducing Apache Kudu
[8]https://help.aliyun.com/document_detail/167448.html?spm=a2c4g.11174283.6.542.2acb49afFy52rZ
[9]Design · Apache Druid
[10]Presto_SQL_on_Everything.pdf (trino.io)
[11]Introduction to Apache Doris - Apache Doris
▼
作者介紹
祁國輝
前 Oracle 云平臺事業(yè)部電信行業(yè)技術(shù)總監(jiān)現(xiàn)任杭州石原子科技有限公司合伙人
【作者介紹】網(wǎng)名"atiger"，前 Oracle 云平臺事業(yè)部電信行業(yè)技術(shù)總監(jiān)。擁有超過25年數(shù)據(jù)庫和數(shù)據(jù)倉庫HK經(jīng)驗。曾創(chuàng)辦著名數(shù)據(jù)倉庫網(wǎng)站：www.dwway.com (數(shù)據(jù)倉庫之路）。
