開源大資料OLAP元件，可以分為MOLAP和ROLAP兩類。ROLAP中又可細分為MPP資料庫和SQL引擎兩類。對于SQL引擎又可以再細分為基于MPP架構的SQL引擎和基于通用計算架構的SQL引擎：
MOLAP一般對資料存儲有優化，并且進行部分預計算，是以查詢性能最高。但通常對查詢靈活性有限制。
MPP資料庫是個完整的資料庫，通常資料需要導入其中才能完成OLAP功能。MPP資料庫在資料入庫時對資料分布可以做優化，雖然入庫效率有一定下降，但是對後期查詢性能的提高有很大幫助。MPP資料庫可以提供靈活的即席查詢能力，但一般對查詢資料量有一定限制，無法支撐特别大的資料量的查詢。
SQL引擎隻提供SQL執行的能力，本身一般不負責資料存儲，通常可以對接多種資料儲存，如HDFS、HBase、MySQL等。有的還支援聯邦查詢能力，可以對多個異構資料源進行聯合分析。SQL引擎中，基于MPP架構的SQL引擎，一般對線上查詢場景有特殊優化，是以端到端查詢性能一般要高于基于通用計算架構的SQL引擎；但是在容錯性和資料量方面又會遜于基于通用計算架構的SQL引擎。
總之，可以說沒有一個OLAP系統能同時在處理規模，靈活性和性能這三個方面做到完美，使用者需要基于自己的需求進行取舍和選型。
Apache Kylin 是一個開源的分布式分析引擎，提供 Hadoop/Spark 之上的 SQL 查詢接口及多元分析（OLAP）能力以支援超大規模資料，它能在亞秒内查詢巨大的 Hive 表。Kylin的核心思想是預計算，理論基礎是：以空間換時間。即将多元分析可能用到的度量進行預計算，将計算好的結果儲存成Cube并存儲到HBase中，供查詢時直接通路。把高複雜度的聚合運算，多表連接配接等操作轉換成對預計算結果的查詢。
Kylin的核心子產品：
REST Server：提供 Restful 接口，例如建立、建構、重新整理、合并等 Cube 相關操作，Kylin 的 Projects、Tables 等中繼資料管理，使用者通路權限控制，SQL 的查詢等；
Query Engine：使用開源的 Apache Calcite 架構來實作 SQL 解析，可以了解為 SQL 引擎層；
Routing：負責将解析 SQL 生成的執行計劃轉換成 Cube 緩存的查詢，這部分查詢是可以在秒級甚至毫秒級完成；
Metadata：Kylin 中有大量的中繼資料資訊，包括 Cube 的定義、星型模型的定義、Job 和執行 Job 的輸出資訊、模型的次元資訊等等，Kylin 的中繼資料和 Cube 都存儲在 HBase 中，存儲的格式是 json 字元串；
Cube Build Engine：所有子產品的基礎，它主要負責 Kylin 預計算中建立 Cube，建立的過程是首先通過 Hive 讀取原始資料，然後通過一些 MapReduce 或 Spark 計算生成 Htable，最後将資料 load 到 HBase 表中。
整個系統分為兩部分：
離線建構：
資料源在左側，目前主要是 Hadoop Hive，儲存着待分析的使用者資料；
根據中繼資料的定義，下方建構引擎從資料源抽取資料，并建構 Cube；
資料以關系表的形式輸入，支援星形模型和雪花模型；
2.5 開始 Spark 是主要的建構技術（以前是MapReduce）；
建構後的 Cube 儲存在右側的存儲引擎中，一般選用 HBase 作為存儲。
線上查詢
使用者可以從上方查詢系統（Rest API、JDBC/ODBC）發送 SQL 進行查詢分析；
無論從哪個接口進入，SQL 最終都會來到 Rest 服務層，再轉交給查詢引擎進行處理；
查詢引擎解析 SQL，生成基于關系表的邏輯執行計劃；
然後将其轉譯為基于 Cube 的實體執行計劃；
最後查詢預計算生成的 Cube 并産生結果。
優點：
亞秒級查詢響應；
支援百億、千億甚至萬億級别互動式分析；
無縫與 BI 工具內建；
支援增量重新整理；
缺點：
由于 Kylin 是一個分析引擎，隻讀，不支援 insert, update, delete 等 SQL 操作，使用者修改資料的話需要重新批量導入（建構）；
需要預先建立模型後加載資料到 Cube 後才可進行查詢
使用 Kylin 的模組化人員需要了解一定的資料倉庫知識。
Apache Druid是高性能的實時分析資料庫，主要提供對大量的基于時序的資料進行OLAP查詢能力。支援毫秒級的快速的互動式查詢。
Druid有幾種程序類型，簡要描述如下：
Coordinators協調器程序：負責監控資料伺服器上的Historicals程序，将Segments配置設定給特定的伺服器，并負責確定Segments在多個Historicals之間保持平衡。
Overlords程序：負責監控資料伺服器上的MiddleManager程序，并控制資料擷取任務的配置設定。
Broker代理程序：處理來自外部用戶端的查詢，将查詢轉發給資料伺服器去執行，并合并來自多個資料伺服器的結果，傳回給最終使用者。
Routers程序：是個可選程序，提供統一的API Gateway，可以将請求路由到Brokers、Overlords和Coordinators。
Historicals程序：負責處理“曆史資料”的查詢。 它會從Deep Storage下載下傳查詢需要的Segments以加速查詢。它不負責寫入。
MiddleManager程序：負責處理擷取到新資料，從外部資料源讀取資料并轉換成Segments進行存儲。
Druid程序可以按照任何方式進行部署，但是為了易于部署，一般建議将它們組織為三種伺服器類型：
主伺服器：運作Coordinatos和Overlords程序，負責管理資料擷取和資料可用性。
查詢伺服器：運作Brokers和可選的Routers程序，處理來自外部用戶端的查詢。
資料伺服器：運作Historicals和MiddleManagers程序，負責執行資料擷取任務并存儲所有可查詢的資料。
Druid之是以查詢如此之快，與它針對多元資料優化的組織和存儲方式有很大關系。它将資料索引存儲在Segments檔案中，Segment檔案按列來存儲，并通過時間分區來進行橫向分割。Druid将資料列分為了三種不同的類型：
對于時間列和名額列處理比較簡單，直接用lz4壓縮存儲。一旦查詢知道去找哪幾行，隻需要将它們解壓，然後用相應的操作符來操作它們就可以了。
對于次元列就沒那麼簡單了，因為它們需要支援過濾和聚合操作，是以每個次元需要下面三個資料結構：
(1) 一個map，Key是次元的值，值是一個整型的id
(2) 一個存儲列的值得清單，用(1)中的map編碼的list
(3) 對于列中的每個值對應一個bitmap，這個bitmap用來訓示哪些行包含這個個值。
為什麼要使用這三個資料結構？ map将字元串值映射為整數id，以便可以緊湊地表示（2）和（3）中的值。 （3）中的bitmap（也被稱為反向索引）允許快速過濾操作（特别地，bitmap便于快速進行AND和OR運算），這樣，對于過濾再聚合的場景，無需通路（2）中的次元值清單。最後，（2）中的值可以被用來支援group by和TopN查詢。
為分析而設計：為OLAP工作流的探索性分析而建構。它支援各種filter、aggregator和查詢類型。
互動式查詢：低延遲資料攝取架構允許事件在它們建立後毫秒内查詢。
高可用：你的資料在系統更新時依然可用、可查詢。規模的擴大和縮小不會造成資料丢失。
可伸縮：每天處理數十億事件和TB級資料。
不支援更新操作，資料不可更改
不支援事實表之間的關聯
GreenPlum是基于PostgreSQL的開源MPP資料庫，具有良好的線性擴充能力，具有高效的并行運算和并行存儲特性。
Greenplum的系統架構實際上是多台PostgreSQL資料庫伺服器組成的矩陣，采用無共享(no shareing)的MPP架構：
Master節點：作為資料庫的入口，負責客服端連接配接；對客服端的請求生成查詢計劃，分發給某個或者所有的Segment節點。
Standby節點 : 作為master節點的備庫，提供高可用性。
Interconnect：是GreenPlum的網絡層；負責每個節點之間的通信。
Segment節點：為資料節點；接收master分發下來的查詢計劃；執行傳回結果給master節點。
Mirror Segment節點： 作為Segment節點的備庫，提供高可用性；通常跟對應的segment節點不在同一台機器上。
支援多态資料存儲，允許使用者根據應用定義資料分布方式，可提高查詢性能。
具有高效的SQL優化器，針對OLAP查詢進行優化。
存在“木桶效應”，單機故障會導緻性能嚴重下降，是以叢集規模不能太大。
并發性能不高，通常無法支援超過30個并發。
ClickHouse是Yandex（号稱俄羅斯的‘百度’）開源的MPP架構的列式存儲資料庫。
目前ClickHouse公開的資料相對匮乏，比如在架構設計層面就很難找到完整的資料，甚至連一張整體的架構圖都沒有。
ClickHouse為什麼性能這麼好？
着眼硬體。基于将硬體功效最大化的目的，ClickHouse會在記憶體中進行GROUP BY；與此同時，他們非常在意CPU L3級别的緩存，因為一次L3的緩存失效會帶來70～100ns的延遲，意味着在單核CPU上，它會浪費4000萬次/秒的運算。正因為注意了這些細節，是以ClickHouse在基準查詢中能做到1.75億次/秒的資料掃描性能。
注重算法。例如，在字元串搜尋方面，針對不同的場景，ClickHouse選擇了多種算法：對于常量，使用Volnitsky算法；對于非常量，使用CPU的向量化執行SIMD，暴力優化；正則比對使用re2和hyperscan算法。除了字元串之外，其餘的場景也與它類似，ClickHouse會使用最合适、最快的算法。如果世面上出現了号稱性能強大的新算法，ClickHouse團隊會立即将其納入并進行驗證。
特定場景，特殊優化。針對同一個場景的不同狀況，選擇使用不同的實作方式，盡可能将性能最大化。對于資料結構比較清晰的場景，會通過代碼生成技術實作循環展開，以減少循環次數。
向量化執行。SIMD被廣泛地應用于文本轉換、資料過濾、資料解壓和JSON轉換等場景。相較于單純地使用CPU，利用寄存器暴力優化也算是一種降維打擊了。
速度快
不支援事務，不支援真正的删除/更新；
不支援高并發，Clickhouse快是因為采用了并行處理機制，即使一個查詢，也會用伺服器一半的CPU去執行。
join性能不高
開源社群主要是俄語為主.
Presto是Facebook推出分布式SQL互動式查詢引擎，完全基于記憶體的并行計算，支援任意資料源，資料規模GB~PB。
Presto采用典型的Master-Slave架構：
coordinator：是presto叢集的master節點。負責解析SQL語句，生成執行計劃，分發執行任務給Worker節點執行。
worker：是執行任務的節點。負責實際查詢任務的計算和讀寫。
discovery service：是将coordinator和worker結合在一起服務。worker節點啟動後向discovery service服務注冊，coordinator通過discovery service擷取注冊的worker節點。
connector：presto以插件形式對資料存儲層進行了抽象，即connector。可通過connector連接配接多種資料源，提取資料。
discovery service 将coordinator和worker結合在一起服務； worker節點啟動後向discovery service服務注冊 coordinator通過discovery service擷取注冊的worker節點
既然Presto是一個互動式的查詢引擎，我們最關心的就是Presto實作低延時查詢的原理，我認為主要是下面幾個關鍵點：
完全基于記憶體的并行計算
流水線式計算作業
本地化計算
動态編譯執行計劃
小心使用記憶體和資料結構
類BlinkDB的近似查詢
GC控制
與Hive的比較：
上圖顯示了MapReduce與Presto的執行過程的不同點，MR每個操作要麼需要寫磁盤，要麼需要等待前一個stage全部完成才開始執行，而Presto将SQL轉換為多個stage，每個stage又由多個tasks執行，每個tasks又将分為多個split。所有的task是并行的方式進行允許，stage之間資料是以pipeline形式流式的執行，資料之間的傳輸也是通過網絡以Memory-to-Memory的形式進行，沒有磁盤io操作。這也是Presto性能比Hive快很多倍的決定性原因。
與Spark的比較：
目标：Presto強調查詢，但Spark重點強調計算。
架構：Presto的體系結構與MPP SQL引擎非常相似。這意味着僅針對SQL查詢執行進行了高度優化，而Spark是一個通用執行架構，能夠運作多個不同的工作負載，如ETL，機器學習等。
任務啟動：Presto的查詢沒有太多開銷。Presto協調器始終處于啟動狀态并等待查詢。而Spark驅動程式啟動需要時間與叢集管理器協商資源，複制jar，才開始處理。
任務送出：Spark送出任務并在每個階段實時應用資源（與presto相比，這種政策可能導緻處理速度稍慢）; Presto一次申請所需資源，并且一次送出所有任務。
資料處理：在spark中，資料需要在進入下一階段之前完全處理。 Presto是流水線式處理模式。隻要一個page完成處理，就可以将其發送到下一個task（這種方法大大減少了各種查詢的端到端響應時間）。
記憶體：兩者都是記憶體存儲和計算，當它無法獲得足夠的記憶體時，spark會将資料寫入磁盤，但presto會導緻OOM。
容錯：如果Spark任務失敗或資料丢失，它将重新計算。但是presto會導緻查詢失敗。
基于記憶體運算，減少沒必要的硬碟IO，是以快。
都能夠處理PB級别的海量資料分析。（雖然能夠處理PB級别的海量資料分析，但不是代表Presto把PB級别都放在記憶體中計算的。而是根據場景，如count，avg等聚合運算，是邊讀資料邊計算，再清記憶體，再讀資料再計算，這種耗的記憶體并不高。）
能夠連接配接多個資料源，跨資料源關聯查詢。
清晰的架構，是一個能夠獨立運作的系統，不依賴于任何其他外部系統。部署簡單。
不适合多個大表的join操作，因為presto是基于記憶體的，太多資料記憶體放不下的。
Presto的一個權衡是不關心中間查詢容錯。如果其中一個Presto工作節點出現故障（例如，關閉），則大多數情況下正在進行的查詢将中止并需要重新啟動。
HAWQ是Pivotal公司開源的一個Hadoop原生大規模并行SQL分析引擎，針對的是分析型應用。Apache HAWQ 采用主從（Master-Slave）的改進MPP架構，通過将MPP與批處理系統有效的結合，克服了MPP的一些關鍵的限制問題，如短闆效應、并發限制、擴充性等。其整體架構與Pivotal另一開源MPP資料庫Greenplum比較相似：
HAWQ Master節點内部有以下幾個重要元件：
查詢解析器（Parser/Analyzer），負責解析查詢，并檢查文法及語義。最終生成查詢樹傳遞給優化器。
優化器（Optimizer），負責接受查詢樹，生成查詢計劃。針對一個查詢，可能有數億個可能的等價的查詢計劃，但執行性能差異很大。優化器的做用是找出優化的查詢計劃。
資料總管（Resource Manager），資料總管經過資源代理向全局資料總管（好比YARN）動态申請資源。并緩存資源。在不須要的時候傳回資源。
HDFS中繼資料緩存（HDFS Catalog Cache），用于HAWQ确定哪些Segment掃描表的哪些部分。HAWQ是把計算派發到資料所在的地方。是以要比對計算和資料的局部性。如果每一個查詢都通路HDFS NameNode會形成NameNode的瓶頸。是以在HAWQ Master節點上建立了HDFS中繼資料緩存。
容錯服務（Fault Tolerance Service），負責檢測哪些節點可用，哪些節點不可用。不可用的機器會被排除出資源池。
查詢派遣器（Dispatcher），優化器優化完查詢之後，查詢派遣器派遣計劃到各個節點上執行，并協調查詢執行的整個過程。查詢派遣器是整個并行系統的粘合劑。
中繼資料服務（Catalog Service），負責存儲HAWQ的各類中繼資料，包括資料庫和表資訊，以及通路權限資訊等。另外，中繼資料服務也是實作分布式事務的關鍵。
其餘節點為Slave節點。每一個Slave節點上部署有HDFS DataNode，YARN NodeManager以及一個HAWQ Segment。HAWQ Segment在執行查詢的時候會啟動多個QE (Query Executor, 查詢執行器)。查詢執行器運作在資源容器裡面。節點間資料交換經過Interconnect（高速網際網路絡）進行。
對SQL标準的完善支援：ANSI SQL标準，OLAP擴充，标準JDBC/ODBC支援。
支援ACID事務特性：這是很多現有基于Hadoop的SQL引擎做不到的，對保證資料一緻性很重要。
動态資料流引擎：基于UDP的高速網際網路絡。
多種UDF（使用者自定義函數）語言支援：java, python, c/c++, perl, R等。
動态擴容：動态按需擴容，按照存儲大小或者計算需求，秒級添加節點。
支援MADlib機器學習。
基于GreenPlum實作，技術實作複雜，包含多個元件。比如對于外部資料源，需要通過PXF單獨進行處理；
C++實作，對記憶體的控制比較複雜，如果出現segmentfault直接導緻目前node挂掉。
安裝配置複雜；
Impala是Cloudera在受到Google的Dremel啟發下開發的實時互動SQL大資料查詢工具。
Impala采用MPP架構，與存儲引擎解耦：
impalad（執行個體*N）: 接收client、hue、jdbc或者odbc請求。每當将查詢送出到特定節點上的impalad時，該節點充當該查詢的“協調器節點”，負責将Query分發到其他impalad節點來并行化查詢，所有查詢結果傳回給中心協調節點。
StateStore（執行個體*1）: 負責收集分布在各個Impalad程序的資源資訊、各節點健康狀況，同步節點資訊；
Catalog Service（執行個體*1）: 分發表的中繼資料資訊到各個Impalad中，每個Impala節點在本地緩存所有中繼資料。
Impala 與Hive都是建構在Hadoop之上的資料查詢工具，各有不同的側重點， Hive适合于長時間的批處理查詢分析，而Impala适合于實時互動式SQL查詢。
資料存儲：使用相同的存儲資料池都支援把資料存儲于HDFS, HBase。
中繼資料：兩者使用相同的中繼資料。
SQL解釋處理：比較相似都是通過詞法分析生成執行計劃。
執行計劃：
Hive: 依賴于MapReduce執行架構，執行計劃分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一個Query會 被編譯成多輪MapReduce，則會有更多的寫中間結果。由于MapReduce執行架構本身的特點，過多的中間過程會增加整個Query的執行時間。
Impala: 把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的 map->reduce模式，以此保證Impala有更好的并發性和避免不必要的中間sort與shuffle。
資料流：
Hive: 采用推的方式，每一個計算節點計算完成後将資料主動推給後續節點。
Impala: 采用拉的方式，後續節點通過getNext主動向前面節點要資料，以此方式資料可以流式的傳回給用戶端，且隻要有1條資料被處理完，就可以立即展現出來，而不用等到全部處理完成，更符合SQL互動式查詢使用。
記憶體使用：
Hive: 在執行過程中如果記憶體放不下所有資料，則會使用外存，以保證Query能順序執行完。每一輪MapReduce結束，中間結果也會寫入HDFS中，同樣由于MapReduce執行架構的特性，shuffle過程也會有寫本地磁盤的操作。
Impala: 在遇到記憶體放不下資料時，目前版本1.0.1是直接傳回錯誤，而不會利用外存。這使用得Impala目前處理Query會受到一 定的限制。Impala在多個階段之間利用網絡傳輸資料，在執行過程不會有寫磁盤的操作（insert除外）。
排程：
Hive: 任務排程依賴于Hadoop的排程政策。
Impala: 排程由自己完成，目前隻有一種排程器simple-schedule，它會盡量滿足資料的局部性，掃描資料的程序盡量靠近資料本身所在的實體機器。排程器目前還比較簡單，還沒有考慮負載，網絡IO狀況等因素進行排程。但目前 Impala已經有對執行過程的性能統計分析，應該以後版本會利用這些統計資訊進行排程吧。
容錯：
Hive: 依賴于Hadoop的容錯能力。
Impala: 在查詢過程中，沒有容錯邏輯，如果在執行過程中發生故障，則直接傳回錯誤（這與Impala的設計有關，因為Impala定位于實時查詢，一次查詢失敗， 再查一次就好了，再查一次的成本很低）。
适用面：
Hive: 複雜的批處理查詢任務，資料轉換任務。
Impala：實時資料分析，因為不支援UDF，能處理的問題域有一定的限制。
支援SQL查詢，快速查詢大資料。
可以對已有資料進行查詢，減少資料的加載，轉換。
多種存儲格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。
可以與Hive配合使用。
不支援使用者定義函數UDF。
不支援text域的全文搜尋。
不支援Transforms。
不支援查詢期的容錯。
對記憶體要求高。
Drill是MapR開源的一個低延遲的大資料集的分布式SQL查詢引擎，是谷歌Dremel的開源實作。它支援對本地檔案、HDFS、HBASE等資料進行資料查詢，也支援對如JSON等schema-free的資料進行查詢。
從架構上看，與同是源自Dremel的Impala比較類似。Drill的核心是DrillBit，它主要負責接收用戶端的請求，處理查詢，并将結果傳回給用戶端。 Drill的查詢流程包括以下步驟：
Drill用戶端發起查詢，任意DrilBit都可以接受來自用戶端的查詢
收到請求的DrillBit成為驅動節點（Foreman），對查詢進行分析優化生成執行計劃，之後将執行計劃劃分成各個片段（Fragment），并确定合适的節點來執行。
各個節點執行查詢片段（Fragment），并将結果傳回給驅動節點
驅動節點将結果傳回給用戶端
能夠自動解析資料（json，text，parquet）的結構。
支援自定義的嵌套資料集，資料靈活,，支援查詢複雜的半結構化資料。
與Hive一體化（Hive表和視圖的查詢，支援所有的Hive檔案格式和HiveUDFS）。
支援多資料源，包括NoSQL資料庫。
可以友善的與第三方BI工具對接。
SQL文法和正常SQL有差別,一般是如“select * from 插件名.表名”的形式。
安裝部署比較複雜。
GC機制還有待提高。
Spark SQL與傳統 DBMS 的查詢優化器 + 執行器的架構較為類似，隻不過其執行器是在分布式環境中實作，并采用的 Spark 作為執行引擎：
Spark SQL 的查詢優化是Catalyst，Catalyst 将 SQL 語言翻譯成最終的執行計劃，并在這個過程中進行查詢優化。這裡和傳統不太一樣的地方就在于， SQL 經過查詢優化器最終轉換為可執行的查詢計劃是一個查詢樹，傳統 DB 就可以執行這個查詢計劃了。而 Spark SQL 最後執行還是會在 Spark 内将這棵執行計劃樹轉換為 Spark 的有向無環圖DAG 再執行。
将sql查詢與spar無縫融合
相容HiveQL
查詢性能不高
以thrift server方式提供的SparkSQL服務不支援多種資料源，必須使用DataFrame API。
Hive是一個建構于Hadoop頂層的資料倉庫工具。定義了簡單的類似SQL 的查詢語言——HiveQL，可以将HiveQL查詢轉換為MapReduce 的任務在Hadoop叢集上執行。
image-20200803091119996.png
高可靠、高容錯：HiveServer采用叢集模式。雙MetaStor。逾時重試機制。
類SQL：類似SQL文法，内置大量函數。
可擴充：自定義存儲格式，自定義函數。
多接口：Beeline，JDBC，ODBC，Python，Thrift。
延遲較高：預設MR為執行引擎，MR延遲較高。
不支援物化視圖：Hive支援普通視圖，不支援物化視圖。Hive不能再視圖上更新、插入、删除資料。
不适用OLTP：暫不支援列級别的資料添加、更新、删除操作。
測試資料來源于：開源OLAP引擎測評報告。通過測試以及相關調研編寫了各元件各個方面的綜合對比分析表，這裡采用5分為滿分來比較，如下表：
SparkSQL是Hadoop中另一個著名的SQL引擎，它以Spark作為底層計算架構，Spark使用RDD作為分布式程式的工作集合，它提供一種分布式共享記憶體的受限形式。在分布式共享記憶體系統中，應用可以向全局位址空間的任意位置進行讀寫作，而RDD是隻讀的，對其隻能進行建立、轉化和求值等作。這種記憶體操作大大提高了計算速度。SparkSql的性能相對其他的元件要差一些，多表單表查詢性能都不突出。
Impala官方宣傳其計算速度是一大優點，在實際測試中我們也發現它的多表查詢性能和presto差不多，但是單表查詢方面卻不如presto好。而且Impala有很多不支援的地方，例如：不支援update、delete操作，不支援Date資料類型，不支援ORC檔案格式等等，是以我們查詢時采用parquet格式進行查詢，而且Impala在查詢時占用的記憶體很大。
Presto綜合性能比起來要比其餘元件好一些，無論是查詢性能還是支援的資料源和資料格式方面都要突出一些，在單表查詢時性能靠前，多表查詢方面性能也很突出。由于Presto是完全基于記憶體的并行計算，是以presto在查詢時占用的記憶體也不少，但是發現要比Impala少一些，比如多表join需要很大的記憶體，Impala占用的記憶體比presto要多。
HAWQ 吸收了先進的基于成本的 SQL 查詢優化器，自動生成執行計劃，可優化使用hadoop 叢集資源。HAWQ 采用 Dynamic pipelining 技術解決這一關鍵問題。Dynamic pipelining 是一種并行資料流架構，利用線性可擴充加速Hadoop查詢，資料直接存儲在HDFS上，并且其SQL查詢優化器已經為基于HDFS的檔案系統性能特征進行過細緻的優化。但是我們發現HAWQ在多表查詢時比Presto、Impala差一些；而且不适合單表的複雜聚合操作，單表測試性能方面要比其餘四種元件差很多，hawq環境搭建也遇到了諸多問題。
ClickHouse 作為目前所有開源MPP計算架構中計算速度最快的，它在做多列的表，同時行數很多的表的查詢時，性能是很讓人興奮的，但是在做多表的join時，它的性能是不如單寬表查詢的。性能測試結果表明ClickHouse在單表查詢方面表現出很大的性能優勢，但是在多表查詢中性能卻比較差，不如presto、impala、hawq的效果好。
GreenPlum作為關系型資料庫産品，它的特點主要就是查詢速度快，資料裝載速度快，批量DML處理快。而且性能可以随着硬體的添加，呈線性增加，擁有非常良好的可擴充性。是以，它主要适用于面向分析的應用。比如建構企業級ODS/EDW，或者資料集市等，GREENPLUM都是不錯的選擇。
轉載連結：https://www.jianshu.com/p/4b3bcbabad77
來源：簡書
作者的原創文章，轉載須注明出處。原創文章歸作者所有，歡迎轉載，但是保留版權。對于轉載了部落客的原創文章，不标注出處的，作者将依法追究版權，請尊重作者的成果。