調整Hive查詢的性能

Question

我有一個Hive查詢，它選擇了大約30列和大約400,000條記錄並將它們插入另一個表中。 我在SQL子句中有一個連接，它只是一個內連接。

由於超出了Java GC開銷限制，查詢失敗。

奇怪的是，如果我刪除join子句並只選擇表中的數據（略高的音量），那么查詢工作正常。

我對Hive很新。 我無法理解為什么這個連接導致內存異常。

關於如何編寫Hive查詢以便它們不會導致這些問題，我是否應該注意一些事項？ 任何人都可以解釋為什么連接可能會導致此問題，但選擇更大的數據量和相同數量的列不會。

感謝你對此的看法。 謝謝

Answer 1

根據Hive的版本和您的配置，您的問題的答案可能會有所不同。 如果您可以與兩個表的create語句共享您的確切查詢以及它們的大小估計會更容易。

為了更好地理解這個問題，讓我們來看看Hive中“常規”內連接的工作原理。

Hive加入MapReduce：

以下是如何將Hive中的內部聯接編譯為MapReduce的簡化說明。 通常，如果您有兩個表t1和t2，並且連接查詢如下：

SELECT
   t1.key, t1.value, t2.value
FROM
   t1
   JOIN
   t2 (ON t1.key = t2.key);

其中，t1具有以下內容：

k_1    v1_1
k_2    v1_2
k_3    v1_3

其中，t2具有以下內容：

k_2    v2_2
k_3    v2_3
k_4    v2_4

我們希望連接結果是

k_2    v1_2    v2_2
k_3    v1_3    v2_3

假設表存儲在HDFS上，它們的內容將被拆分為File Splits。 映射器將文件拆分為輸入，並將密鑰作為表的鍵列發出，值作為表的值列和標志的復合（表示記錄來自哪個表，即t1或t2）。

對於t1：

k_1, <v1_1, t1>
k_2, <v1_2, t1>
k_3, <v1_3, t1>

對於t2：

k_2, <v2_2, t2>
k_3, <v2_3, t2>
k_4, <v2_4, t2>

現在，這些發出的記錄經過洗牌階段，其中具有相同鍵的所有記錄被組合在一起並被發送到減速器。 每個reduce操作的上下文是一個鍵和一個包含與該鍵對應的所有值的列表。 在實踐中，一個減速器將執行幾個減速操作。

在上面的示例中，我們將獲得以下分組：

k_1, <<v1_1, t1>>
k_2, <<v1_2, t1>, <v2_2, t2>>
k_3, <<v1_3, t1>, <v2_3, t2>>
k_4, <<v2_4, t2>>

以下是減速機中發生的情況。 對於值列表中的每個值，如果值對應於不同的表，則reducer將執行乘法運算。

對於k_1，t2沒有值，也沒有發出任何值。

對於k_2，發出值的乘法 - k_2，v1_2，v2_2（因為每個表中有一個值，1x1 = 1）

對於k_3，發出值的乘法 - k_3，v1_3，v2_3（因為每個表中有一個值，1x1 = 1）

對於k_4，t1沒有值，也沒有發出任何值。 因此，您可以獲得內部聯接所期望的結果。

好的，我該怎么辦？

您的數據可能存在偏差。 換句話說，當reducer獲取數據時，對應於某個鍵的值列表非常長，這會導致錯誤。 要解決此問題，您可以嘗試增加JVM可用的內存。 您可以通過設置這樣做mapred.child.java.opts到的值等-Xmx512M在蜂房的site.xml。 您可以通過set mapred.child.java.opts;查詢此參數的當前值set mapred.child.java.opts; 在你的Hive shell中。
您可以嘗試使用“常規”連接的替代方法，例如地圖連接。 上面的連接說明適用於常規連接，其中連接發生在reducers中。 根據您使用的Hive的版本，Hive可以自動將常規連接轉換為更快的地圖連接（因為連接發生在地圖階段）。 要啟用優化，請將hive.auto.convert.join設置為true 。 該屬性是在Hive 0.7中引入的
除了將hive.auto.convert.join設置為true ，您還可以將hive.optimize.skewjoin設置為true 。 這將解決1中描述的數據問題的偏差。

Answer 2

非常感謝Mark的回應。 非常感激。

幾個小時后，我終於發現join語句中表的順序有所不同。 為了獲得最佳性能和內存管理，最后一個連接應該是最大的表。

在join語句中更改表的順序解決了問題。

您上面的解釋也非常有用。 非常感謝