1. hive多個insert union起來效率會高嗎
Union因為要進行重復值掃描，所以效率低。如果合並沒有刻意要刪除重復行，那麼就使用Union All 兩個要聯合的sql語句 欄位個數必須一樣，而且欄位類型要「相容」
2. 用kettle將mysql數據導入到hive中為什麼執行效率很低
資料庫機制不一樣，整個庫導入是不可能的。如果數據不多，你用 plsql developper 的tool->export tables 選擇sql insert導出數據好了。這將生成一般的sql insert 語句。
3. 影響數據檢索效率的幾個因素
影響數據檢索效率的幾個因素
數據檢索有兩種主要形態。第一種是純資料庫型的。典型的結構是一個關系型數據，比如 mysql。用戶通過 SQL 表達出所需要的數據，mysql 把 SQL 翻譯成物理的數據檢索動作返回結果。第二種形態是現在越來越流行的大數據玩家的玩法。典型的結構是有一個分區的數據存儲，最初這種存儲就是原始的 HDFS，後來開逐步有人在 HDFS 上加上索引的支持，或者乾脆用 Elasticsearc 這樣的數據存儲。然後在存儲之上有一個分布式的實時計算層，比如 Hive 或者 Spark SQL。用戶用 Hive SQL 提交給計算層，計算層從存儲里拉取出數據，進行計算之後返回給用戶。這種大數據的玩法起初是因為 SQL 有很多 ad-hoc 查詢是滿足不了的，乾脆讓用戶自己寫 map/rece 想怎麼算都可以了。但是後來玩大了之後，越來越多的人覺得這些 Hive 之類的方案查詢效率怎麼那麼低下啊。於是一個又一個項目開始去優化這些大數據計算框架的查詢性能。這些優化手段和經典的資料庫優化到今天的手段是沒有什麼兩樣的，很多公司打著搞計算引擎的旗號干著重新發明資料庫的活。所以，回歸本質，影響數據檢索效率的就那麼幾個因素。我們不妨來看一看。
數據檢索乾的是什麼事情
定位 => 載入 => 變換
找到所需要的數據，把數據從遠程或者磁碟載入到內存中。按照規則進行變換，比如按某個欄位group by，取另外一個欄位的sum之類的計算。
影響效率的四個因素
讀取更少的數據
數據本地化，充分遵循底層硬體的限制設計架構
更多的機器
更高效率的計算和計算的物理實現
原則上的四點描述是非常抽象的。我們具體來看這些點映射到實際的資料庫中都是一些什麼樣的優化措施。
讀取更少的數據
數據越少，檢索需要的時間當然越少了。在考慮所有技術手段之前，最有效果的恐怕是從業務的角度審視一下我們是否需要從那麼多的數據中檢索出結果來。有沒有可能用更少的數據達到同樣的效果。減少的數據量的兩個手段，聚合和抽樣。如果在入庫之前把數據就做了聚合或者抽樣，是不是可以極大地減少查詢所需要的時間，同時效果上並無多少差異呢？極端情況下，如果需要的是一天的總訪問量，比如有1個億。查詢的時候去數1億行肯定快不了。但是如果統計好了一天的總訪問量，查詢的時候只需要取得一條記錄就可以知道今天有1個億的人訪問了。
索引是一種非常常見的減少數據讀取量的策略了。一般的按行存儲的關系型資料庫都會有一個主鍵。用這個主鍵可以非常快速的查找到對應的行。KV存儲也是這樣，按照Key可以快速地找到對應的Value。可以理解為一個Hashmap。但是一旦查詢的時候不是用主鍵，而是另外一個欄位。那麼最糟糕的情況就是進行一次全表的掃描了，也就是把所有的數據都讀取出來，然後看要的數據到底在哪裡，這就不可能快了。減少數據讀取量的最佳方案就是，建立一個類似字典一樣的查找表，當我們找 username=wentao 的時候，可以列舉出所有有 wentao 作為用戶名的行的主鍵。然後拿這些主鍵去行存儲（就是那個hashmap）里撈數據，就一撈一個准了。
談到索引就不得不談一下一個查詢使用了兩個欄位，如何使用兩個索引的問題。mysql的行為可以代表大部分主流資料庫的處理方式：
基本上來說，經驗表明有多個單欄位的索引，最後資料庫會選一最優的來使用。其餘欄位的過濾仍然是通過數據讀取到內存之後，用predicate去判斷的。也就是無法減少數據的讀取量。
在這個方面基於inverted index的數據就非常有特點。一個是Elasticsearch為代表的lucene系的資料庫。另外一個是新銳的druid資料庫。
效果就是，這些資料庫可以把單欄位的filter結果緩存起來。多個欄位的查詢可以把之前緩存的結果直接拿過來做 AND 或者 OR 操作。
索引存在的必要是因為主存儲沒有提供直接的快速定位的能力。如果訪問的就是資料庫的主鍵，那麼需要讀取的數據也就非常少了。另外一個變種就是支持遍歷的主鍵，比如hbase的rowkey。如果查詢的是一個基於rowkey的范圍，那麼像hbase這樣的資料庫就可以支持只讀取到這個范圍內的數據，而不用讀取不再這個范圍內的額外數據，從而提高速度。這種加速的方式就是利用了主存儲自身的物理分布的特性。另外一個更常見的場景就是 partition。比如 mysql 或者 postgresql 都支持分區表的概念。當我們建立了分區表之後，查找的條件如果可以過濾出分區，那麼可以大幅減少需要讀取的數據量。比 partition 更細粒度一些的是 clustered index。它其實不是一個索引（二級索引），它是改變了數據在主存儲內的排列方式，讓相同clustered key的數據彼此緊挨著放在一起，從而在查詢的時候避免掃描到無關的數據。比 partition 更粗一些的是分庫分表分文件。比如我們可以一天建立一張表，查詢的時候先定位到表，再執行 SQL。比如 graphite 給每個 metric 創建一個文件存放採集來的 data point，查詢的時候給定metric 就可以定位到一個文件，然後只讀取這個文件的數據。
另外還有一點就是按行存儲和按列存儲的區別。按列存儲的時候，每個列是一個獨立的文件。查詢用到了哪幾個列就打開哪幾個列的文件，沒有用到的列的數據碰都不會碰到。反觀按行存儲，一張中的所有欄位是彼此緊挨在磁碟上的。一個表如果有100個欄位，哪怕只選取其中的一個欄位，在掃描磁碟的時候其餘99個欄位的數據仍然會被掃描到的。
考慮一個具體的案例，時間序列數據。如何使用讀取更少的數據的策略來提高檢索的效率呢？首先，我們可以保證入庫的時間粒度，維度粒度是正好是查詢所需要的。如果查詢需要的是5分鍾數據，但是入庫的是1分鍾的，那麼就可以先聚合成5分鍾的再存入資料庫。對於主存儲的物理布局選擇，如果查詢總是針對一個時間范圍的。那麼把 timestamp 做為 hbase 的 rowkey，或者 mysql 的 clustered index 是合適。這樣我們按時間過濾的時候，選擇到的是一堆連續的數據，不用讀取之後再過濾掉不符合條件的數據。但是如果在一個時間范圍內有很多中數據，比如1萬個IP，那麼即便是查1個IP的數據也需要把1萬個IP的數據都讀取出來。所以可以把 IP 維度也編碼到 rowkey 或者 clustered index 中。但是假如另外還有一個維度是 OS，那麼查詢的時候 IP 維度的 rowkey 是沒有幫助的，仍然是要把所有的數據都查出來。這就是僅依靠主存儲是無法滿足各種查詢條件下都能夠讀取更少的數據的原因。所以，二級索引是必要的。我們可以把時間序列中的所有維度都拿出來建立索引，然後查詢的時候如果指定了維度，就可以用二級索引把真正需要讀取的數據過濾出來。但是實踐中，很多資料庫並不因為使用了索引使得查詢變快了，有的時候反而變得更慢了。對於 mysql 來說，存儲時間序列的最佳方式是按時間做 partition，不對維度建立任何索引。查詢的時候只過濾出對應的 partition，然後進行全 partition 掃描，這樣會快過於使用二級索引定位到行之後再去讀取主存儲的查詢方式。究其原因，就是數據本地化的問題了。
[page]
數據本地化
數據本地化的實質是軟體工程師們要充分尊重和理解底層硬體的限制，並且用各種手段規避問題最大化利用手裡的硬體資源。本地化有很多種形態
最常見的最好理解的本地化問題是網路問題。我們都知道網路帶寬不是無限的，比本地磁碟慢多了。如果可能盡量不要通過網路去訪問數據。即便要訪問，也應該一次抓取多一些數據，而不是一次搞一點，然後搞很多次。因為網路連接和來回的開銷是非常高的。這就是 data locality 的問題。我們要把計算盡可能的靠近數據，減少網路上傳輸的數據量。
這種帶寬引起的本地化問題，還有很多。網路比硬碟慢，硬碟比內存慢，內存比L2緩存慢。做到極致的資料庫可以讓計算完全發生在 L2 緩存內，盡可能地避免頻繁地在內存和L2之間倒騰數據。
另外一種形態的問題化問題是磁碟的順序讀和隨機讀的問題。當數據彼此靠近地物理存放在磁碟上的時候，順序讀取一批是非常快的。如果需要隨機讀取多個不連續的硬碟位置，磁頭就要來回移動從而使得讀取速度快速下降。即便是 SSD 硬碟，順序讀也是要比隨機讀快的。
基於盡可能讓數據讀取本地化的原則，檢索應該盡可能地使用順序讀而不是隨機讀。如果可以的話，把主存儲的row key或者clustered index設計為和查詢提交一樣的。時間序列如果都是按時間查，那麼按時間做的row key可以非常高效地以順序讀的方式把數據拉取出來。類似地，按列存儲的數據如果要把一個列的數據都取出來加和的話，可以非常快地用順序讀的方式載入出來。
二級索引的訪問方式典型的隨機讀。當查詢條件經過了二級索引查找之後得到一堆的主存儲的 key，那麼就需要對每個 key 進行一次隨機讀。即便彼此僅靠的key可以用順序讀做一些優化，總體上來說仍然是隨機讀的模式。這也就是為什麼時間序列數據在 mysql 里建立了索引反而比沒有建索引還要慢的原因。
為了盡可能的利用順序讀，人們就開始想各種辦法了。前面提到了 mysql 里的一行數據的多個列是彼此緊靠地物理存放的。那麼如果我們把所需要的數據建成多個列，那麼一次查詢就可以批量獲得更多的數據，減少隨機讀取的次數。也就是把之前的一些行變為列的方式來存放，減少行的數量。這種做法的經典案例就是時間序列數據，比如可以一分鍾存一行數據，每一秒的值變成一個列。那麼行的數量可以變成之前的1/60。
但是這種行變列的做法在按列存儲的資料庫里就不能直接照搬了，有些列式資料庫有column family的概念，不同的設置在物理上存放可能是在一起的也可能是分開的。對於 Elasticsearch 來說，要想減少行的數量，讓一行多pack一些數據進去，一種做法就是利用 nested document。內部 Elasticsearch 可以保證一個 document 下的所有的 nested document是物理上靠在一起放在同一個 lucene 的 segment 內。
網路的data locality就比較為人熟知了。map rece的大數據計算模式就是利用map在數據節點的本地把數據先做一次計算，往往計算的結果可以比原數據小很多。然後再通過網路傳輸匯總後做 rece 計算。這樣就節省了大量網路傳輸數據的時間浪費和資源消耗。現在 Elasticsearch 就支持在每個 data node 上部署 spark。由 spark 在每個 data node 上做計算。而不用把數據都查詢出來，用網路傳輸到 spark 集群里再去計算。這種資料庫和計算集群的混合部署是高性能的關鍵。類似的還有 storm 和 kafka 之間的關系。
網路的data locality還有一個老大難問題就是分布式大數據下的多表join問題。如果只是查詢一個分布式表，那麼把計算用 map rece 表達就沒有多大問題了。但是如果需要同時查詢兩個表，就意味著兩個表可能不是在物理上同樣均勻分布的。一種最簡單的策略就是找出兩張表中最小的那張，然後把表的內容廣播到每個節點上，再做join。復雜一些的是對兩個單表做 map rece，然後按照相同的 key 把部分計算的結果匯集在一起。第三種策略是保證數據分布的方式，讓兩張表查詢的時候需要用到的數據總在一起。沒有完美的方案，也不大可能有完美的方案。除非有一天網路帶寬可以大到忽略不計的地步。
更多的機器
這個就沒有什麼好說的了。多一倍的機器就多一倍的 CPU，可以同時計算更多的數據。多一倍的機器就多一倍的磁頭，可以同時掃描更多的位元組數。很多大數據框架的故事就是講如何如何通過 scale out解決無限大的問題。但是值得注意的是，集群可以無限大，數據可以無限多，但是口袋裡的銀子不會無限多的。堆機器解決問題比升級大型機是要便宜，但是機器堆多了也是非常昂貴的。特別是 Hive 這些從一開始就是分布式多機的檢索方案，剛開始的時候效率並不高。堆機器是一個乘數，當資料庫本來單機性能不高的時候，乘數大並不能起到決定性的作用。
更高效的計算和計算實現
檢索的過程不僅僅是磁碟掃描，它還包括一個可簡單可復雜的變換過程。使用 hyperloglog，count min-sketch等有損演算法可以極大地提高統計計算的性能。資料庫的join也是一個經常有演算法創新的地方。
計算實現就是演算法是用C++實現的還是用java，還是python實現的。用java是用大Integer實現的，還是小int實現的。不同的語言的實現方式會有一些固定的開銷。不是說快就一定要C++，但是 python 寫 for 循環是顯然沒有指望的。任何數據檢索的環節只要包含 python/ruby 這些語言的逐條 for 循環就一定快不起來了。
結論
希望這四點可以被記住，成為一種指導性的優化數據檢索效率的思維框架。無論你是設計一個mysql表結構，還是優化一個spark sql的應用。從這四個角度想想，都有哪些環節是在拖後腿的，手上的工具有什麼樣的參數可以調整，讓隨機讀變成順序讀，表結構怎麼樣設計可以最小化數據讀取的量。要做到這一點，你必須非常非常了解工具的底層實現。而不是盲目的相信，xx資料庫是最好的資料庫，所以它一定很快之類的。如果你不了解你手上的資料庫或者計算引擎，當它快的時候你不知道為何快，當它慢的時候你就更加無從優化了。
4. Hive 和資料庫的異同
1.
查詢語言。由於 SQL 被廣泛的應用在數據倉庫中，因此，專門針對 Hive 的特性設計了類 SQL 的查詢語言 HQL。熟悉 SQL 開發的開發者可以很方便的使用 Hive 進行開發。
2. 數據存儲位置。Hive 是建立在 Hadoop 之上的，所有 Hive 的數據都是存儲在 HDFS 中的。而資料庫
則可以將數據保存在本地文件系統中。
3. 數據格式。Hive 中沒有定義專門的數據格式，數據格式可以由用戶指定，用戶定義數據格式需要指定三
個屬性：列分隔符（通常為空格、」\t」、」\x001″）、行分隔符（」\n」）以及讀取文件數據的方法（Hive 中默認有三個文件格式 TextFile，SequenceFile 以及 RCFile）。由於在載入數據的過程中，不需要從用戶數據格式到 Hive 定義的數據格式的轉換，因此，Hive 在載入的過程中不會對數據本身進行任何修改，而只是將數據內容復制或者移動到相應的 HDFS 目錄中。而在資料庫中，不同的資料庫有不同的存儲引擎，定義了自己的數據格式。所有數據都會按照一定的組織存儲，因此，資料庫載入數據的過程會比較耗時。
4. 數據更新。由於 Hive 是針對數據倉庫應用設計的，而數據倉庫的內容是讀多寫少的。因此，Hive 中不
支持對數據的改寫和添加，所有的數據都是在載入的時候中確定好的。而資料庫中的數據通常是需要經常進行修改的，因此可以使用 INSERT INTO ... VALUES 添加數據，使用 UPDATE ...
SET 修改數據。
5. 索引。之前已經說過，Hive 在載入數據的過程中不會對數據進行任何處理，甚至不會對數據進行掃描，
因此也沒有對數據中的某些 Key 建立索引。Hive 要訪問數據中滿足條件的特定值時，需要暴力掃描整個數據，因此訪問延遲較高。由於 MapRece 的引入， Hive 可以並行訪問數據，因此即使沒有索引，對於大數據量的訪問，Hive 仍然可以體現出優勢。資料庫中，通常會針對一個或者幾個列建立索引，因此對於少量的特定條件的數據的訪問，資料庫可以有很高的效率，較低的延遲。由於數據的訪問延遲較高，決定了 Hive 不適合在線數據查詢。
6. 執行。Hive 中大多數查詢的執行是通過 Hadoop 提供的 MapRece 來實現的（類似 select * from tbl
的查詢不需要 MapRece）。而資料庫通常有自己的執行引擎。
7. 執行延遲。之前提到，Hive 在查詢數據的時候，由於沒有索引，需要掃描整個表，因此延遲較高。另外
一個導致 Hive 執行延遲高的因素是 MapRece 框架。由於 MapRece 本身具有較高的延遲，因此在利用 MapRece 執行 Hive 查詢時，也會有較高的延遲。相對的，資料庫的執行延遲較低。當然，這個低是有條件的，即數據規模較小，當數據規模大到超過資料庫的處理能力的時候，Hive 的並行計算顯然能體現出優勢。
8. 可擴展性。由於 Hive 是建立在 Hadoop 之上的，因此 Hive 的可擴展性是和 Hadoop 的可擴展性是
一致的（世界上最大的 Hadoop 集群在 Yahoo!，2009年的規模在 4000 台節點左右）。而資料庫由於 ACID 語義的嚴格限制，擴展行非常有限。目前最先進的並行資料庫 Oracle 在理論上的擴展能力也只有 100 台左右。
9. 數據規模。由於 Hive 建立在集群上並可以利用 MapRece 進行並行計算，因此可以支持很大規模的
數據；對應的，資料庫可以支持的數據規模較小。
5. 怎麼查看hive sql map rece情況
map的數量
map的數量通常是由hadoop集群的DFS塊大小確定的，也就是輸入文件的總塊數，正常的map數量的並行規模大致是每一個Node是10~100個，對於CPU消耗較小的作業可以設置Map數量為300個左右，但是由於hadoop的每一個任務在初始化時需要一定的時間，因此比較合理的情況是每個map執行的時間至少超過1分鍾。具體的數據分片是這樣的，InputFormat在默認情況下會根據hadoop集群的DFS塊大小進行分片，每一個分片會由一個map任務來進行處理，當然用戶還是可以通過參數mapred.min.split.size參數在作業提交客戶端進行自定義設置。還有一個重要參數就是mapred.map.tasks，這個參數設置的map數量僅僅是一個提示，只有當InputFormat
決定了map任務的個數比mapred.map.tasks值小時才起作用。同樣，Map任務的個數也能通過使用JobConf
的conf.setNumMapTasks(int
num)方法來手動地設置。這個方法能夠用來增加map任務的個數，但是不能設定任務的個數小於Hadoop系統通過分割輸入數據得到的值。當然為了提高集群的並發效率，可以設置一個默認的map數量，當用戶的map數量較小或者比本身自動分割的值還小時可以使用一個相對交大的默認值，從而提高整體hadoop集群的效率。
2 reece的數量
rece在運行時往往需要從相關map端復制數據到rece節點來處理，因此相比於map任務。rece節點資源是相對比較缺少的，同時相對運行較慢，正確的rece任務的個數應該是0.95或者1.75
*（節點數
×mapred.tasktracker.tasks.maximum參數值）。如果任務數是節點個數的0.95倍，那麼所有的rece任務能夠在
map任務的輸出傳輸結束後同時開始運行。如果任務數是節點個數的1.75倍，那麼高速的節點會在完成他們第一批rece任務計算之後開始計算第二批
rece任務，這樣的情況更有利於負載均衡。同時需要注意增加rece的數量雖然會增加系統的資源開銷，但是可以改善負載勻衡，降低任務失敗帶來的負面影響。同樣，Rece任務也能夠與
map任務一樣，通過設定JobConf 的conf.setNumReceTasks(int num)方法來增加任務個數。
3 rece數量為0
有些作業不需要進行歸約進行處理，那麼就可以設置rece的數量為0來進行處理，這種情況下用戶的作業運行速度相對較高，map的輸出會直接寫入到 SetOutputPath(path)設置的輸出目錄，而不是作為中間結果寫到本地。同時Hadoop框架在寫入文件系統前並不對之進行排序。
6. 如何用sql來寫動態sql，本文主要是hiveql
動態SQL語句在編譯時，並不知道SQL語句的內容，SQL語句的內容「不確定」，只有在運行時，才建立、解析並執行SQL語句。利用動態SQL，在存儲過程中，可以動態創建表、視圖、觸發器等。
動態SQL主要用在以下兩種場景：
編譯時，無法確定SQL語句的內容
靜態SQL不支持的SQL語句，就比如上面代碼中的create
我們可以看到，靜態SQL在編譯時就已經提前檢查了SQL正確性，以及涉及的資料庫對象和對應的許可權關系，而動態SQL則需要在運行的時候才能判斷，所以，靜態SQL的效率高於動態SQL。說了這么多概念的東西，我們現在就來實際看看如何編寫動態SQL，以及如何運行動態SQL。
7. hive sql里，幫我描述一個簡單的sql的原理
select a.id,a.info,b.num from a join b on a.id=b.id and where b.num>=10
兩個表做關聯，首先where會過濾掉不需要的數據。
至於表怎麼做map和rece操作，在hive里的表是虛擬的，其實還是對hdfs文件進行操作，你可以在hdfs:///user/hive/warehouse路徑下找到以表名來命名的文件，裡面就是表的內容，可以執行-cat命令查看。所以，它的map操作很簡單，就是按行讀文件，然後會根據hive的默認分隔符\001對每行進行切分。切分完成後就會按照你SQL指定的邏輯進行合並，最後再輸出成hdfs文件，只不過在hive裡面看它是以表的形式展現的。
job數會在你執行sql語句之後緊接著有相應的日誌記錄，
Total MapRece jobs = 2
Launching Job 1 out of 2
Number of rece tasks not specified. Estimated from input data size: 2
In order to change the average load for a recer (in bytes):
set hive.exec.recers.bytes.per.recer=<number>
In order to limit the maximum number of recers:
set hive.exec.recers.max=<number>
In order to set a constant number of recers:
這樣就是有兩個job，正在執行第一個job。
Hadoop job information for Stage-1: number of mappers: 5; number of recers: 2
而這個就會告訴你有多少個mapper和recer。
像你寫的這個sql有join操作，而且是hiveSQL裡面最普通的join，那麼一定會有recer參與，如果數據量很大，比如上千萬條記錄，join就會特別慢，job進度就會一直卡在rece操作。可以改成mapjoin或者sort merge bucket mapjoin。
其實hive效率不高，不適合實時查詢，即使一個表為空，用hive進行查詢也會很耗時，因為它要把sql語句翻譯成MR任務。雖然簡化了分布式編程，但是效率上就會付出代價。
你的這句sql應該會翻譯成一個JOB來執行，就是簡單地map和rece。
maprece就是按行讀文件，然後切分，合並，輸出成文件。
8. hive sql 優化的常用手段有哪些
1、join連接時的優化：當三個或多個以上的表進行join操作時，如果每個on使用相同的欄位連接時只會產生一個maprece。
2、join連接時的優化：當多個表進行查詢時，從左到右表的大小順序應該是從小到大。原因：hive在對每行記錄操作時會把其他表先緩存起來，直到掃描最後的表進行計算
3、在where字句中增加分區過濾器。
4、當可以使用left semi join 語法時不要使用inner join，前者效率更高。原因：對於左表中指定的一條記錄，一旦在右表中找到立即停止掃描。
9. hive運行sql rece 為1 ，跑不動怎麼處理
1.jpg 優化可以從幾個方面著手：1. 好的模型設計事半功倍。2. 解決數據傾斜問題。3. 減少job數。4. 設置合理的map rece的task數，能有效提升性能。(比如，10w+級別的計算，用160個rece，那是相當的浪費，1個足夠)。5. 自己動手寫sql解決數據傾斜問題是個不錯的選擇。set hive.groupby.skewindata=true;這是通用的演算法優化，但演算法優化總是漠視業務，習慣性提供通用的解決方法。 Etl開發人員更了解業務，更了解數據，所以通過業務邏輯解決傾斜的方法往往更精確，更有效。6. 對count(distinct)採取漠視的方法，尤其數據大的時候很容易產生傾斜問題，不抱僥幸心理。自己動手，豐衣足食。7. 對小文件進行合並，是行至有效的提高調度效率的方法，假如我們的作業設置合理的文件數，對雲梯的整體調度效率也會產生積極的影響。8. 優化時把握整體，單個作業最優不如整體最優。
10. hive中sql運算出現傾斜的情況，主要原因有哪些
1. Mapjoin是一種避免避免數據傾斜的手段
允許在map階段進行join操作，MapJoin把小表全部讀入內存中，在map階段直接拿另外一個表的數據和內存中表數據做匹配，由於在map是進行了join操作，省去了rece運行的效率也會高很多
在《hive：join遇到問題》有具體操作
在對多個表join連接操作時，將小表放在join的左邊，大表放在Jion的右邊，
在執行這樣的join連接時小表中的數據會被緩存到內存當中,這樣可以有效減少發生內存溢出錯誤的幾率
2. 設置參數
hive.map.aggr = true
hive.groupby.skewindata=true 還有其他參數
3.SQL語言調節
比如： group by維度過小時：採用sum() group by的方式來替換count(distinct)完成計算
4.StreamTable
將在recer中進行join操作時的小table放入內存，而大table通過stream方式讀取