1. 將表分割槽（Partitioned Table）

通過將表劃分為相互獨立的分割槽，對應於HDFS上相互獨立資料目錄，在查詢時通過指定分割槽列上的條件，將讀取資料的範圍限定在關心的資料上，而不需要讀取全表資料，繼而提升查詢效能；

通過CREATE TABLE語句實現。

2. 分桶（Bucked Table）

所謂分桶就是將表中的內容以某列為基準，對所指定的桶的個數N進行模運算，繼而將資料劃分成N份，對應於HDFS上的N個檔案。桶的劃分進一步細化了檔案讀取的粒度，這樣在做JOIN時，如果兩邊的表使用相同的方式進行了分桶，左邊表的桶就知道所對應右邊表的桶，從而優化讀取過程；如果再在分桶的同時，對分桶列進行排序，那麼這個JOIN過程將會進行高效地合併排序，效能得到進一步提升。

3. 合理使用檔案儲存格式並使用壓縮

目前Hadoop支援很多的檔案儲存格式，面向行的包括原始的TEXT、Avro、SequenceFile；還有面向列的，如Parquet、RCFile、ORCFile等。對於選擇面向行的儲存還是面向列的儲存，需要根據具體的使用場景選擇，如果每次只讀取表中全部列的一小部分那麼，面向列的儲存可能會大幅度減少每次讀取的資料量，反之，使用面向行的資料儲存格式可能效率會更好。

在正確選擇儲存格式的同時，通過壓縮相應的儲存檔案，進一步降低讀取時的IO壓力，會進一步提升執行效率。

4. 對Hive中間結果進行壓縮，減少Map端向Reduce端傳輸的網路IO

MapReduce計算過程中會將Map輸出的中間結果落地，然後通過網路傳輸將中間結果交由Reduce處理，通過壓縮將需要寫入到本地磁碟和通過網路傳輸的資料量大幅減少，繼而提升整個MapReduce過程的效率。

5. 通過使用部分排序而非全域性排序使Reduce階段更加並行化

如果使用ORDER BY進行排序，會對全部的資料進行排序，最終會將排序過程在一個Reduce過程中處理，即便是歸併排序，但這對於資料量較大的情況是非常低效的；通過使用SORT BY可以為每個Reduce生成一個排序檔案。

一般要與DISTRIBUTE BY同時使用，將對應列的每個值的所有的記錄分配到一個分割槽中。

6. 資料量較大時避免使用COUNT DISTINCT

如果最後大量的資料都傾斜到一個Reduce中進行操作，會造成Reduce端的效率低下；建議先進行GROUP BY，然後再在外層進行COUNT(1)計算。

7. 使用Presto並配置Hive資料來源

由於使用了完全不同於MapReduce的計算過程，克服了MapReduce過程中的許多問題，快取的使用，減少資料落地過程的IO，很大地提升了查詢的相應速度。儘管PrestoSQL同HiveSQL有一些不同之處，但是隻需要經過簡單的調整即可。再考慮到，Presto可以對接除Hive之外的其它資料來源，如Kafka、關係資料庫、Redis等，並將其資料置於統一的查詢檢視下，整個資料體系的擴充套件性和靈活性得以提升。