在運行HIVE Join查詢時，Reducers停止了66.68％的工作

Question

試圖加入6個表，每個表大約有500萬行。 嘗試加入帳戶號碼，該帳號在所有表格中按升序排序。 地圖任務成功完成，減速機停止工作在66.68％。 嘗試增加減少數量的選項，並嘗試其他選項設置hive.auto.convert.join = true; 並設置hive.hashtable.max.memory.usage = 0.9; 並設置hive.smalltable.filesize = 25000000L; 但結果是一樣的。 嘗試少量記錄（如5000行），查詢工作得很好。

請建議可以在這里做些什么來使它工作。

Answer 1

減少66％的人開始做實際減少（0-33％是洗牌，33-66％是排序）。 在與hive的連接中，reducer在兩個數據集之間執行笛卡爾積。

我猜想在所有數據集中至少有一個外鍵頻繁出現。 注意NULL和默認值。

例如，在連接中，假設鍵“abc”在六個表（10 ^ 6）的每一個中出現十次。 這是一個密鑰的百萬輸出記錄。 如果“abc”在一個表中出現1000次，在另一個表中出現1000次，在另一個表中出現1000次，那么在其他三個表中出現兩次，則得到80億條記錄（1000 ^ 3 * 2 ^ 3）。 你可以看到這是如何失控的。 我猜測至少有一個密鑰會產生大量的輸出記錄。

這也是在Hive之外的RDBMS中避免的一般良好做法。 在多對多關系之間進行多個內部聯接可能會給您帶來很多麻煩。

Answer 2

對於現在和將來的調試，您可以使用JobTracker查找和檢查有問題的Reducer的日志。 然后，您可以檢測reduce操作，以便更好地處理正在發生的事情。 小心你當然不要用日志記錄它！ 例如，嘗試查看輸入到reduce操作的記錄數。