4) Stinger Initiative（Tez optimized Hive）：Hortonworks開源了一個DAG計算框架Tez，Tez可以理解為Google Pregel的開源實(shí)現(xiàn)，該框架可以像Map-Reduce一樣，可以用來設(shè)計DAG應(yīng)用程序，但需要注意的是，Tez只能運(yùn)行在YARN上。Tez的一 個重要應(yīng)用是優(yōu)化Hive和PIG這種典型的DAG應(yīng)用場景，它通過減少數(shù)據(jù)讀寫IO，優(yōu)化DAG流程使得Hive速度提供了很多倍。
5) Presto：FaceBook于2013年11月份開源了Presto，一個分布式SQL查詢引擎，它被設(shè)計為用來專門進(jìn)行高速、實(shí)時的數(shù) 據(jù)分析。它支持標(biāo)準(zhǔn)的ANSI SQL，包括復(fù)雜查詢、聚合（aggregation）、連接（join）和窗口函數(shù)（window functions)。Presto設(shè)計了一個簡單的數(shù)據(jù)存儲的抽象層，來滿足在不同數(shù)據(jù)存儲系統(tǒng)（包括HBase、HDFS、Scribe等）之上都可 以使用SQL進(jìn)行查詢。
圖3. Hive架構(gòu)
Impala架構(gòu)
Impala是Cloudera在受到Google的Dremel啟發(fā)下開發(fā)的實(shí)時交互SQL大數(shù)據(jù)查詢工具，它可以看成是Google Dremel架構(gòu)和MPP (Massively Parallel Processing)結(jié)構(gòu)的結(jié)合體。Impala沒有再使用緩慢的Hive&Map-Reduce批處理，而是通過使用與商用并行關(guān)系數(shù)據(jù)庫中 類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統(tǒng)計函數(shù)查詢數(shù)據(jù)，從而大大降低了延遲，其架構(gòu)如圖4所 示，Impala主要由Impalad，State Store和CLI組成。Impalad與DataNode運(yùn)行在同一節(jié)點(diǎn)上，由Impalad進(jìn)程表示，它接收客戶端的查詢請求（接收查詢請求的 Impalad為Coordinator，Coordinator通過JNI調(diào)用java前端解釋SQL查詢語句，生成查詢計劃樹，再通過調(diào)度器把執(zhí)行計 劃分發(fā)給具有相應(yīng)數(shù)據(jù)的其它Impalad進(jìn)行執(zhí)行），讀寫數(shù)據(jù)，并行執(zhí)行查詢，并把結(jié)果通過網(wǎng)絡(luò)流式的傳送回給Coordinator，由 Coordinator返回給客戶端。同時Impalad也與State Store保持連接，用于確定哪個Impalad是健康和可以接受新的工作。Impala State Store跟蹤集群中的Impalad的健康狀態(tài)及位置信息，由state-stored進(jìn)程表示，它通過創(chuàng)建多個線程來處理Impalad的注冊訂閱和 與各Impalad保持心跳連接，各Impalad都會緩存一份State Store中的信息，當(dāng)State Store離線后，因?yàn)镮mpalad有State Store的緩存仍然可以工作，但會因?yàn)橛行㊣mpalad失效了，而已緩存數(shù)據(jù)無法更新，導(dǎo)致把執(zhí)行計劃分配給了失效的Impalad，導(dǎo)致查詢失敗。 CLI提供給用戶查詢使用的命令行工具，同時Impala還提供了Hue，JDBC，ODBC，Thrift使用接口。
圖4. Impala架構(gòu)
Shark架構(gòu)
Shark是UC Berkeley AMPLAB開源的一款數(shù)據(jù)倉庫產(chǎn)品，它完全兼容Hive的HQL語法，但與Hive不同的是，Hive的計算框架采用Map-Reduce，而 Shark采用Spark。所以，Hive是SQL border="0" alt="6" />
圖5. Shark架構(gòu)
Spark是UC Berkeley AMP lab所開源的類Hadoop Map-Reduce的通用的并行計算框架，Spark基于Map-Reduce算法實(shí)現(xiàn)的分布式計算，擁有Hadoop Map-Reduce所具有的優(yōu)點(diǎn)；但不同于Map-Reduce的是Job中間輸出和結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫HDFS，因此Spark 能更好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的Map-Reduce的算法。其架構(gòu)如圖6所示：
圖6. Spark架構(gòu)
與Hadoop的對比，Spark的中間數(shù)據(jù)放到內(nèi)存中，對于迭代運(yùn)算效率更高，因此Spark適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場合。需要反復(fù)操作的 次數(shù)越多，所需讀取的數(shù)據(jù)量越大，受益越大，數(shù)據(jù)量小但是計算密集度較大的場合，受益就相對較小。Spark比Hadoop更通用，Spark提供的數(shù)據(jù) 集操作類型有很多種（map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort，partionBy等），而Hadoop只提供了Map和Reduce兩種操作。Spark可以直接對HDFS進(jìn)行數(shù)據(jù)的讀寫，同樣支持 Spark border="0" alt="8" />
圖7. Stinger架構(gòu)
Presto架構(gòu)
2013年11月Facebook開源了一個分布式SQL查詢引擎Presto，它被設(shè)計為用來專門進(jìn)行高速、實(shí)時的數(shù)據(jù)分析。它支持標(biāo)準(zhǔn)的 ANSI SQL子集，包括復(fù)雜查詢、聚合、連接和窗口函數(shù)。其簡化的架構(gòu)如圖8所示，客戶端將SQL查詢發(fā)送到Presto的協(xié)調(diào)器。協(xié)調(diào)器會進(jìn)行語法檢查、分析 和規(guī)劃查詢計劃。調(diào)度器將執(zhí)行的管道組合在一起，將任務(wù)分配給那些里數(shù)據(jù)最近的節(jié)點(diǎn)，然后監(jiān)控執(zhí)行過程?？蛻舳藦妮敵龆沃袑?shù)據(jù)取出，這些數(shù)據(jù)是從更底層 的處理段中依次取出的。Presto的運(yùn)行模型與Hive有著本質(zhì)的區(qū)別。Hive將查詢翻譯成多階段的Map-Reduce任務(wù)，一個接著一個地運(yùn)行。 每一個任務(wù)從磁盤上讀取輸入數(shù)據(jù)并且將中間結(jié)果輸出到磁盤上。然而Presto引擎沒有使用Map-Reduce。它使用了一個定制的查詢執(zhí)行引擎和響應(yīng) 操作符來支持SQL的語法。除了改進(jìn)的調(diào)度算法之外，所有的數(shù)據(jù)處理都是在內(nèi)存中進(jìn)行的。不同的處理端通過網(wǎng)絡(luò)組成處理的流水線。這樣會避免不必要的磁盤 讀寫和額外的延遲。這種流水線式的執(zhí)行模型會在同一時間運(yùn)行多個數(shù)據(jù)處理段，一旦數(shù)據(jù)可用的時候就會將數(shù)據(jù)從一個處理段傳入到下一個處理段。 這樣的方式會大大的減少各種查詢的端到端響應(yīng)時間。同時，Presto設(shè)計了一個簡單的數(shù)據(jù)存儲抽象層，來滿足在不同數(shù)據(jù)存儲系統(tǒng)之上都可以使用SQL進(jìn) 行查詢。存儲連接器目前支持除Hive/HDFS外，還支持HBase、Scribe和定制開發(fā)的系統(tǒng)。