[[191434]]

與傳統(tǒng)的分析數(shù)據(jù)庫(Greenplum)相比，未經(jīng)修改的基于TPC-DS的性能基準(zhǔn)測試表現(xiàn)出了Impala的領(lǐng)導(dǎo)地位，特別是對(duì)于多用戶并發(fā)工作負(fù)載而言。此外，基準(zhǔn)測試還進(jìn)一步證明了分析數(shù)據(jù)庫與Hive LLAP、Spark SQL和Presto等SQL-on-Hadoop引擎之間存在的顯著性能差距。

過去一年是Apache Impala(正在孵化中)發(fā)展變化***的一年。Impala團(tuán)隊(duì)不僅繼續(xù)努力不斷擴(kuò)大其規(guī)模和穩(wěn)定性，而且還推出了一系列的關(guān)鍵功能，進(jìn)一步鞏固了Impala作為高性能商務(wù)智能(BI)和SQL分析的開放標(biāo)準(zhǔn)地位。對(duì)于云計(jì)算和混合部署而言，Impala現(xiàn)在可以提供云端-本地部署彈性、靈活性，以及直接從Amazon S3對(duì)象存儲(chǔ)中(以及為未來一年制定的其他對(duì)象存儲(chǔ))讀取/寫入的能力。隨著Apache Kudu的GA，用戶現(xiàn)在可以使用Impala對(duì)接收到或更新的數(shù)據(jù)立即進(jìn)行高性能分析。另外，也很容易將現(xiàn)有的商務(wù)智能(BI)工作負(fù)載從傳統(tǒng)分析數(shù)據(jù)庫或數(shù)據(jù)倉庫遷移至由Impala構(gòu)建的Cloudera分析數(shù)據(jù)庫中，同時(shí)可以使用Navigator Optimizer優(yōu)化其性能。而且如同以往一樣，對(duì)于更大的并發(fā)性工作負(fù)載的性能改進(jìn)仍然是全年工作的重中之重。

除了這些性能改進(jìn)之外，隨著越來越多的企業(yè)機(jī)構(gòu)(例如紐約證券交易所(NYSE)和奎斯特診斷公司(Quest Diagnostics))已經(jīng)注意到Cloudera現(xiàn)代分析數(shù)據(jù)庫(而不是傳統(tǒng)分析數(shù)據(jù)庫)的靈活性、可擴(kuò)展性和支持SQL及非SQL工作負(fù)載(例如數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)和操作性工作負(fù)載)的開放式架構(gòu)，Impala的采用率也在不斷增長。

對(duì)于該基準(zhǔn)測試而言，我們使用未經(jīng)修改的多用戶TPC-DS查詢對(duì)具有Impala的Cloudera現(xiàn)代分析數(shù)據(jù)庫與傳統(tǒng)分析數(shù)據(jù)庫(Greenplum)進(jìn)行了性能比較。我們還研究了分析數(shù)據(jù)庫與SQL-on-Hadoop引擎，例如：Hive LLAP、Spark SQL和Presto的對(duì)比?？偟膩碚f，我們發(fā)現(xiàn)：

• Impala相對(duì)于傳統(tǒng)分析數(shù)據(jù)庫而言性能更為先進(jìn)，包括超過8倍的高并發(fā)工作負(fù)載性能。
• 分析數(shù)據(jù)庫和其他SQL-on-Hadoop引擎之間存在顯著的性能差異，使用Impala可以使多用戶工作負(fù)載的性能提高近22倍。
• 其他SQL-on-Hadoop引擎也無法完成大規(guī)模基準(zhǔn)測試來與分析數(shù)據(jù)庫進(jìn)行比較，因此需要一個(gè)簡化的、規(guī)模較小的基準(zhǔn)測試(Hive甚至還需要修改，Presto無法完成多用戶測試)。
• 比較集分析數(shù)據(jù)庫(采用10TB和1TB級(jí)別的數(shù)據(jù)進(jìn)行測試，未經(jīng)修改的查詢)?！?Impala 2.8 from CDH 5.10;
• Greenplum Database 4.3.9.1。

附加的SQL-on-Hadoop引擎(采用1TB級(jí)別的數(shù)據(jù)進(jìn)行測試，并對(duì)Hive進(jìn)行了一些查詢修改)。

• Spark SQL 2.1;
• Presto 0.160;
• Hive 2.1 with LLAP from HDP 2.5。

配置每一個(gè)集群由七個(gè)工作節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)采用以下配置：● CPU：2 塊E5-2698 v4 @ 2.20GHz;

• 存儲(chǔ)器：8 塊2TB硬盤;
•  內(nèi)存：256GB內(nèi)存。

我們配置了三個(gè)由相同硬件組成的集群，其中一個(gè)用于Impala、Spark和Presto(負(fù)責(zé)運(yùn)行CDH)，另一個(gè)用于Greenplum，還有一個(gè)用于具有LLAP(負(fù)責(zé)運(yùn)行HDP)的Hive。每個(gè)集群都裝載了相同的TPC-DS數(shù)據(jù)：針對(duì)Impala和Spark的Parquet/Snappy，以及針對(duì)Hive和Presto的ORCFile/Zlib，而Greenplum使用內(nèi)部的柱狀格式與QuickLZ壓縮文件。

查詢工作負(fù)載：● 數(shù)據(jù)：TPC-DS 10TB和1TB(比例系數(shù));

• 查詢：TPC-DS v2.4查詢模板(未經(jīng)修改的TPC-DS)。
• 我們運(yùn)行了77個(gè)查詢，所有引擎的運(yùn)行都具有語言支持，無需修改TPC-DS規(guī)范(Hive除外)。1其中22個(gè)已排除的查詢都使用以下幾個(gè)不常見的SQL功能：
• 使用ROLLUP進(jìn)行的11個(gè)查詢(TPC-DS允許的變體在本測試中未使用);
• 3個(gè)INTERSECT或EXCEPT查詢;
• 8個(gè)具有高級(jí)子查詢位置的查詢(例如HAVING子句中的子查詢等)。

由于Hive對(duì)子查詢位置的更大限制，我們被迫進(jìn)行了一些修改以創(chuàng)建語義上等同的查詢。我們針對(duì)Hive運(yùn)行了這些經(jīng)過修改的查詢。

雖然Greenplum、Presto和Spark SQL也聲稱支持所有99個(gè)未經(jīng)修改的查詢，但是即使沒有并發(fā)執(zhí)行，Spark SQL和Presto也無法成功完成10TB級(jí)別的99個(gè)查詢。Greenplum隨著多用戶并發(fā)性的增加而出現(xiàn)越來越多的查詢失敗(詳見下文)。

分析數(shù)據(jù)庫基準(zhǔn)測試結(jié)果10 TB級(jí)別上Impala與Greenplum的比較我們使用常見的77個(gè)未修改的TPC-DS查詢?cè)?0TB級(jí)別數(shù)據(jù)下對(duì)Impala和Greenplum進(jìn)行了測試。在單用戶測試和更實(shí)際的多用戶測試集上比較了兩個(gè)、四個(gè)和八個(gè)并發(fā)流?？偨Y(jié)如下：● 總體來說，Impala在單用戶和多用戶并發(fā)測試方面優(yōu)于Greenplum。

• 相比Greenplum而言，Impala 線性擴(kuò)展表現(xiàn)更優(yōu)異，隨著并發(fā)度增加，Impala與Greenplum的性能比率從2倍上升到了8.3倍，，同時(shí)保持了更高的成功率。

在單用戶測試中，當(dāng)比較查詢中的幾何平均值時(shí)，Impala的性能是Greenplum的2.8倍;完成查詢流的總時(shí)間是Greenplum的1.8倍：

對(duì)于多用戶吞吐量比較，我們使用TPC-DS dsqgen工具運(yùn)行同一組77個(gè)未修改的查詢來生成并發(fā)查詢流。每個(gè)查詢流由隨機(jī)排序的77個(gè)通用查詢組成，并且每個(gè)查詢流使用不同的查詢替換值。我們運(yùn)行了多個(gè)測試，增加了超過系統(tǒng)飽和點(diǎn)的查詢流數(shù)量，并且測量了各個(gè)并發(fā)級(jí)別的所有后續(xù)查詢的吞吐量。

如下圖所示，與Greenplum相比，Impala的性能指標(biāo)隨著并發(fā)速度從2個(gè)查詢流2倍的速度提升加速到8個(gè)查詢流8.3倍的速度提升。

鑒于集群的規(guī)模與數(shù)據(jù)集大小和并發(fā)性相比較而言較小，對(duì)于Impala和Greenplum這兩個(gè)系統(tǒng)而言，預(yù)期在并發(fā)性增加時(shí)會(huì)發(fā)現(xiàn)一些查詢失敗。Impala和Greenplum這兩個(gè)系統(tǒng)在兩個(gè)查詢流測試中達(dá)到了100%的成功率。對(duì)于四個(gè)和八個(gè)查詢流測試，Impala系統(tǒng)的平均成功率為97%，而Greenplum系統(tǒng)的成功率下降到50%。如果這些測試在大于7節(jié)點(diǎn)集群的集群上運(yùn)行，則可以預(yù)期這兩個(gè)系統(tǒng)的成功率都會(huì)相應(yīng)提高。分析數(shù)據(jù)庫與SQL-on-Hadoop引擎1TB基準(zhǔn)測試我們已經(jīng)嘗試針對(duì)SQL-on-Hadoop引擎使用相同的77個(gè)查詢和10TB級(jí)別基準(zhǔn)測試，但是，Hive、Presto和Spark SQL都無法成功完成77個(gè)未修改查詢中的大多數(shù)查詢，甚至僅僅是單用戶結(jié)果也未能成功，因此無法在10TB級(jí)上進(jìn)行比較。因此，我們?cè)?TB規(guī)模下運(yùn)行了單獨(dú)的比較，將分析數(shù)據(jù)庫引擎與其余的SQL-on-Hadoop引擎進(jìn)行比較。除了Hive之外，所有的引擎都使用相同的77個(gè)TPC-DS查詢，但是需要進(jìn)行一些修改，以尋找方法去繞過這些限制條件，從而解決無法解析的子查詢。

通過這些簡化的標(biāo)準(zhǔn)(對(duì)于其他SQL-on-Hadoop引擎來說是非常必要的)，我們?cè)俅螌?duì)所有五個(gè)引擎進(jìn)行了單用戶測試和更為真實(shí)環(huán)境的多用戶測試。測試結(jié)果匯總?cè)缦拢?/p>

• 分析數(shù)據(jù)庫 – Impala和Greenplum系統(tǒng)在各個(gè)并發(fā)級(jí)別展現(xiàn)出的性能都優(yōu)于所有的SQL-on-Hadoop引擎。
• 隨著并發(fā)性的提高，再次看到Impala在性能方面拔得頭籌，是其他引擎的8.5倍 – 21.6倍。
• 在所有引擎中，Presto在單用戶測試中表現(xiàn)出最慢的性能，甚至無法完成多用戶測試。

在該單用戶測試中，我們?cè)俅慰吹?，在幾何平均值方面相較而言Impala仍然保持了其性能優(yōu)勢，但是，Greenplum在總時(shí)間上略有下降。這兩個(gè)分析數(shù)據(jù)庫的性能顯著優(yōu)于其他引擎，與其他SQL-on-Hadoop引擎相比，Impala在幾何平均值方面性能優(yōu)勢在3.6倍至13倍之間，在總時(shí)間方面性能優(yōu)勢在2.8倍-8.3倍之間。

Presto對(duì)除了過濾、分組和聚合的簡單單表掃描之外的其他常見的 SQL 查詢表現(xiàn)的很掙扎。對(duì)于非常簡單的查詢類型，它更符合Spark SQL的性能，但是如上所述，對(duì)于使用更多標(biāo)準(zhǔn)SQL(包括連接)的更典型的商務(wù)智能(BI)查詢，是執(zhí)行效果最差的SQL-on-Hadoop集群。

使用TPC-DS通過四個(gè)、八個(gè)和十六個(gè)并發(fā)流運(yùn)行更具代表性的多用戶比較測試，以生成與上述的10TB分析數(shù)據(jù)庫比較一樣的隨機(jī)查詢流。除Presto之外，所有引擎都能夠在三個(gè)并發(fā)級(jí)別的1TB級(jí)別下完成流，而不會(huì)出現(xiàn)任何查詢失敗。即使只運(yùn)行四個(gè)并發(fā)查詢，Presto也可能由于內(nèi)存不足錯(cuò)誤而使大多數(shù)查詢失敗。

對(duì)于能夠成功完成多用戶并發(fā)測試的引擎，分析數(shù)據(jù)庫組群和SQL-on-Hadoop組群之間的性能差異變得更加明顯。Impala在每一個(gè)并發(fā)級(jí)別上都展示出了優(yōu)異的吞吐量 – 不僅比Greenplum快1.3-2.8倍，與Spark SQL相比，其速度快達(dá)6.5-21.6倍，并且比Hive快8.5-19.9倍。

結(jié)論各企業(yè)機(jī)構(gòu)越來越期待現(xiàn)代化改造其系統(tǒng)架構(gòu)，但是不愿意犧牲重要商務(wù)智能(BI)和SQL分析所需的交互式、多用戶性能。Impala作為Cloudera公司平臺(tái)的一部分，能夠獨(dú)特地提供一個(gè)現(xiàn)代化分析數(shù)據(jù)庫。通過設(shè)計(jì)，Impala可以靈活地支持更多種類的數(shù)據(jù)和使用案例，而無需任何前期建模工作;Impala可以有彈性地和成本高效地在公司內(nèi)部部署和云端部署方式下按需進(jìn)行擴(kuò)展;并且，作為共享平臺(tái)的一部分，這些相同的數(shù)據(jù)可用于其他團(tuán)隊(duì)和工作負(fù)載，而不僅僅只是SQL分析，因此可以進(jìn)一步拓展其價(jià)值。此外，從上述基準(zhǔn)測試結(jié)果可以看出，與傳統(tǒng)分析數(shù)據(jù)庫相比，Impala還提供了領(lǐng)先的性能。無論整體性能還是大規(guī)模運(yùn)算以及不斷激增的并發(fā)性工作負(fù)載能力方面，分析數(shù)據(jù)庫群(Impala、Greenplum)和SQL-on-Hadoop組群(Hive，Presto，Spark)之間的差異也變得非常明顯。雖然其他SQL-on-Hadoop引擎不能滿足分析數(shù)據(jù)庫工作負(fù)載的要求，但這并不意味著對(duì)其他工作負(fù)載沒有價(jià)值。事實(shí)上，絕大多數(shù)Cloudera客戶充分利用平臺(tái)的開放架構(gòu)，通過Hive準(zhǔn)備數(shù)據(jù)，通過Spark建立和測試模型，通過Impala運(yùn)行商務(wù)智能(BI)并提供報(bào)告，而無需在不同的孤島中復(fù)制數(shù)據(jù)。

在接下來的一年中，我們將以Impala為核心繼續(xù)推動(dòng)現(xiàn)代化分析數(shù)據(jù)庫的重大性能改進(jìn)，包括增加商務(wù)智能(BI)體驗(yàn)的智能化和自動(dòng)化，并且不斷擴(kuò)大云計(jì)算支持，進(jìn)一步提高多租戶能力和可擴(kuò)展性。請(qǐng)點(diǎn)擊此博客了解更多詳情。

像往常一樣，我們鼓勵(lì)您通過基于開放式基準(zhǔn)測試工具包運(yùn)行您自己的基準(zhǔn)測試以獨(dú)立驗(yàn)證這些結(jié)果。