自從Google在2006年之前的幾篇論文奠定雲計算領域基礎，尤其是GFS、Map-Reduce、 Bigtable被稱為雲計算底層技術三大基石。GFS、Map-Reduce技術直接支持了Apache Hadoop項目的誕生。Bigtable和Amazon Dynamo直接催生了NoSQL這個嶄新的數據庫領域，撼動了RDBMS在商用數據庫和數據倉庫方面幾十年的統治性地位。FaceBook的Hive項目是建立在Hadoop上的數據倉庫基礎構架，提供了一系列用於存儲、查詢和分析大規模數據的工具。當我們還浸淫在GFS、Map-Reduce、 Bigtable等Google技術中，並進行理解、掌握、模仿時，Google在2009年之后，連續推出多項新技術，包括：Dremel、 Pregel、Percolator、Spanner和F1。其中，Dremel促使了實時計算系統的興起，Pregel開辟了圖數據計算這個新方向，Percolator使分布式增量索引更新成為文本檢索領域的新標准，Spanner和F1向我們展現了跨數據中心數據庫的可能。在Google的第二波技術浪潮中，基於Hive和Dremel，新興的大數據公司Cloudera開源了大數據查詢分析引擎Impala，Hortonworks開源了 Stinger，Fackbook開源了Presto。類似Pregel，UC Berkeley AMPLAB實驗室開發了Spark圖計算框架，並以Spark為核心開源了大數據查詢分析引擎Shark。由於某電信運營商項目中大數據查詢引擎選型需求，本文將會對Hive、Impala和Presto這三類主流的開源大數據查詢分析引擎進行簡要介紹以及性能比較。
按照查詢類型划分，一般分為即席查詢和固化查詢：
即席查詢:通過手寫sql完成一些臨時的數據分析需求，這類sql形式多變、邏輯復雜，對查詢時間沒有嚴格要求
固化查詢：指的是一些固化下來的取數、看數需求，通過數據產品的形式提供給用戶，從而提高數據分析和運營的效率。這類的sql固定模式，對響應時間有較高要求。
按照計算引擎主要分為：
1、mapreduce計算模型(hive/pig等)。披着SQL外衣的Map-Reduce，為方便用戶使用，編碼門檻底，就有了應用性更好的hive，它的應用場景比Map-Reduce更窄，有些計算SQL難以表達，比如一些數據挖掘算法，推薦算法、圖像識別算法等，這些仍只能通過編寫Map-Reduce完成。
2、MPP架構系統(Presto/Impala/SparkSQL/Drill等)。這種架構主要還是從查詢引擎入手，使用分布式查詢引擎，而不是使用hive+mapreduce架構，提高查詢效率。
搜索引擎架構的系統(es，solr等)，在入庫時將數據轉換為倒排索引，采用Scatter-Gather計算模型，犧牲了靈活性換取很好的性能，在搜索類查詢上能做到亞秒級響應。但是對於掃描聚合為主的查詢，隨着處理數據量的增加，響應時間也會退化到分鍾級。
3、預計算系統（Druid/Kylin等）則在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。
4、基於lucene外部索引的，比如ElasticSearch和Solr,能夠滿足的的查詢場景遠多於傳統的數據庫存儲，但對於日志、行為類時序數據，所有的搜索請求都也必須搜索所有的分片，另外，對於聚合分析場景的支持也是軟肋
Hive架構
Hive是基於Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射為一張數據庫表，並提供完整的SQL查詢功能，可以將SQL語句轉換為 Map-Reduce任務進行運行，十分適合數據倉庫的統計分析。其架構如圖1所示，Hadoop和Map-Reduce是Hive架構的根基。Hive 架構包括如下組件：CLI(Command Line Interface)、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)。正因使用Map-Reduce計算模型，將一個算法抽象成Map和Reduce兩個階段進行處理，非常適合數據密集型計算。雖然非常穩定，冗余的mr模型和中間結果寫入hdfs減慢了計算查詢的效率，后來Apache開源的支持DAG作業的計算框架，它直接源於MapReduce框架，核心思想是將Map和Reduce兩個操作進一步拆分，即Map被拆分成Input、Processor、Sort、Merge和Output， Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等，這樣，這些分解后的元操作可以任意靈活組合，產生新的操作，這些操作經過一些控制程序組裝后，可形成一個大的DAG作業。
總結起來，Tez有以下特點（圖二所示）
（1）Apache二級開源項目
（2）運行在YARN之上
（3） 適用於DAG（有向圖）應用（同Impala、Dremel和Drill一樣，可用於替換Hive/Pig等）
Hadoop是基礎，其中的HDFS提供文件存儲，Yarn進行資源管理。在這上面可以運行MapReduce、Spark、Tez等計算框架。
傳統的MR（包括Hive，Pig和直接編寫MR程序）。假設有四個有依賴關系的MR作業（1個較為復雜的Hive SQL語句或者Pig腳本可能被翻譯成4個有依賴關系的MR作業）或者用Oozie描述的4個有依賴關系的作業，運行過程如下（其中，綠色是Reduce Task，需要寫HDFS）：
雲狀表示寫屏蔽（write barrier，一種內核機制，持久寫）
Tez可以將多個有依賴的作業轉換為一個作業（這樣只需寫一次HDFS，且中間節點較少），從而大大提升DAG作業的性能
Impala架構
Impala是Cloudera在受到Google的Dremel啟發下開發的實時交互SQL大數據查詢工具，它可以看成是Google Dremel架構和MPP (Massively Parallel Processing)結構的結合體。Impala沒有再使用緩慢的Hive&Map-Reduce批處理，而是通過使用與商用並行關系數據庫中類似的分布式查詢引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分組成)，可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲，其架構如圖4所示，Impala主要由Impalad，State Store和CLI組成。Impalad與DataNode運行在同一節點上，由Impalad進程表示，它接收客戶端的查詢請求(接收查詢請求的 Impalad為Coordinator，Coordinator通過JNI調用java前端解釋SQL查詢語句，生成查詢計划樹，再通過調度器把執行計划分發給具有相應數據的其它Impalad進行執行)，讀寫數據，並行執行查詢，並把結果通過網絡流式的傳送回給Coordinator，由 Coordinator返回給客戶端。同時Impalad也與State Store保持連接，用於確定哪個Impalad是健康和可以接受新的工作。Impala State Store跟蹤集群中的Impalad的健康狀態及位置信息，由state-stored進程表示，它通過創建多個線程來處理Impalad的注冊訂閱和與各Impalad保持心跳連接，各Impalad都會緩存一份State Store中的信息，當State Store離線后，因為Impalad有State Store的緩存仍然可以工作，但會因為有些Impalad失效了，而已緩存數據無法更新，導致把執行計划分配給了失效的Impalad，導致查詢失敗。 CLI提供給用戶查詢使用的命令行工具，同時Impala還提供了Hue，JDBC，ODBC，Thrift使用接口。
Presto架構
2013年11月Facebook開源了一個分布式SQL查詢引擎Presto，它被設計為用來專門進行高速、實時的數據分析。它支持標准的 ANSI SQL子集，包括復雜查詢、聚合、連接和窗口函數。其簡化的架構如圖8所示，客戶端將SQL查詢發送到Presto的協調器。協調器會進行語法檢查、分析和規划查詢計划。調度器將執行的管道組合在一起，將任務分配給那些里數據最近的節點，然后監控執行過程。客戶端從輸出段中將數據取出，這些數據是從更底層的處理段中依次取出的。Presto的運行模型與Hive有着本質的區別。Hive將查詢翻譯成多階段的Map-Reduce任務，一個接着一個地運行。每一個任務從磁盤上讀取輸入數據並且將中間結果輸出到磁盤上。然而Presto引擎沒有使用Map-Reduce。它使用了一個定制的查詢執行引擎和響應操作符來支持SQL的語法。除了改進的調度算法之外，所有的數據處理都是在內存中進行的。不同的處理端通過網絡組成處理的流水線。這樣會避免不必要的磁盤讀寫和額外的延遲。這種流水線式的執行模型會在同一時間運行多個數據處理段，一旦數據可用的時候就會將數據從一個處理段傳入到下一個處理段。這樣的方式會大大的減少各種查詢的端到端響應時間。同時，Presto設計了一個簡單的數據存儲抽象層，來滿足在不同數據存儲系統之上都可以使用SQL進行查詢。存儲連接器目前支持除Hive/HDFS外，還支持HBase、Scribe和定制開發的系統。
總結：數倉架構的選型需要從以下三個方面考慮：數據存儲和構建、安裝搭建、開發成本。各組件hive/presto/Druid各有優缺點，都有相應的應用場景，比如hive更適合大數據量，密集型計算，有較好的穩定性與擴展，而presto這種mpp計算模型交互性更好，響應時間可以達到秒級，更適合實時查詢分析，最后是Druid/Kylin則在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。最后基於這些組件構建公司級數據中台，並能夠穩定/有序/高效的運轉，是建立數倉重要的第一步