① 究竟是什麼讓Redshift比Hive快10倍
究竟是什麼原因產生了如此懸殊的速度，有網友在Quora上提出了這個問題，並得到了Reynold Xin的解答：
Redshift採用了專有的叫做ParAccel的並行資料庫實現機制。我想在很多工作情境中，你會發現大多數並行資料庫引擎要比Hive快。接下來，我將給出答案，並解釋其中的某些原因。請注意的是，雖然該答案針對的是ParAccel，其中的大部分因素也適用於Vertica、Greenplum、OracleRAC等並行資料庫。
在答案中呢，我將使用三個可互換的術語「並行資料庫」、「關系型資料庫」和「分析型資料庫」。
比起並行資料庫，Hive在可擴展性、靈活度方面遙遙領先。例如，Facebook使用Hive數據倉庫跨越成千上萬個節點。說起靈活度，Hive設計的初衷是與一些系列存儲系統（HDFS、HBase、S3）配合使用，並能夠支持多種輸入格式（壓縮、未壓縮、Avro、純文本、JSON）。
易擴展和高靈活度在給你帶來便利的同時，卻也阻礙了你構建性能更好的查詢引擎。接下來，我將列舉哪些特徵會影響查詢性能：
數據格式：數據以類似純文本文件，相對未優化的形式存儲在HDFS中。Hive 作業在處理數據之前，需要先花大量時間從硬碟中讀取數據，再反序列化這些數據。
發起任務的系統開銷：Hadoop MapRece 使用心跳機制（heartbeats）制定作業計劃，每項任務作為一獨立的JVM過程發起。在Hadoop MapRece 中，僅僅是發起一項作業就需要幾十秒鍾，在秒級時間單位內，是無法運行任何進程的。相反，並行資料庫擁有持續進程或線程池，它們能夠大大減少任務安排及發起所需要的系統開銷。
中間數據物化 vs數據傳輸：Hive 使用擁有二階模型(Map和Rece)的MapRece來執行。通常一個復雜的SQL查詢被映射為MapRece的多個階段，不同階段的中間數據在硬碟上物化。並行資料庫內置有用於執行SQL查詢的引擎，執行查詢時，該引擎在查詢操作符和數據流（steram data）之間跨節點傳遞數據。
列數據格式：列資料庫將數據按照列式的格式進行存儲。在典型的數據倉庫中，每張數據表能夠存儲成百上千列，而大多數查詢僅查找少數列。讓我們來考慮一下如下查詢，要查找的是沃爾瑪每家店的營業額。它僅需要查找兩三列（商店的編號、每件商品的零售價，或者還有銷售日期）。以列式存儲數據，執行查詢時，引擎可以跳過不相關的列。這樣可以減少上百次的硬碟I/O。此外，按列存儲數據能夠大大增加壓縮比率。
列查詢引擎：除了上面提到的按列式存儲的數據格式，還可以按列構建查詢執行引擎，該引擎在分析型工作負載方面得到了較好的優化。其中的技巧包括：晚期物化（late materialization）、直接操作壓縮過的數據、利用現代CPU提供的向量化操作（SIMD）。
更快的S3連接：在這里我將給出一個大膽的猜測：AWS可能已經為他們的Redshift實例實現了一個比普通S3能夠提供的更高帶寬的S3整體負載。
我需要申明，我們剛剛討論的這些因素是基於Hive當前版本（2013年2月）。毫無置疑，Hive社區將會推進開發工作，並解決其中的一些難題。