記錄一下之前遇到的一個問題：一張幾百T按天dt分區(qū)的訂單表，要關(guān)聯(lián)一張幾M的訂單類型快照表，逐月分析。

因為用的時候left join，所以訂單表放在了左邊，但是hive中如果要將兩張表join起來的話，大表放在左邊效率會比較低，如果所有表中只有一張表是小表，那么可以在最大的表通過mapper的時候?qū)⑿”硗耆诺絻?nèi)存中。

Hive可以在map端執(zhí)行連接過程，稱為map-side JOIN，這是因為Hive可以和內(nèi)存中內(nèi)存中的小表進(jìn)行逐一匹配，從而省略掉常規(guī)連接操作所需要的reduce過程。即使對于很小的數(shù)據(jù)集，這個優(yōu)化也明顯地要快于常規(guī)的連接操作，不僅減少了reduce過程，而且有時還可以同時減少map過程的執(zhí)行步驟。

想要使用這個優(yōu)化可以設(shè)置屬性hive.auto.convert.JOIN的值為true：

-- 演示代碼，無實際業(yè)務(wù) set hive.auto.convert.join=true;create table res_table as selecta.*,b.type from ((select*fromorder_tablewhereuser_id is not null and user_id <> ''and dt >= '2021-07-01'and dt <= '2021-07-31') as aleft join (select*fromorder_type_table) as bon a.type_id = b.type_id; )

但是不知道為啥，執(zhí)行的效率還是很滿，只要join表就的花個三個小時左右，我尋思也不應(yīng)該啊，我每次只取了一個月的訂單數(shù)據(jù)，已經(jīng)加了優(yōu)化，怎么可能還跑那么久。

于是沒辦法，只能去求助mentor，結(jié)構(gòu)被一眼打回來了，a表的where篩選條件有問題，因為是dt分區(qū)表，所以應(yīng)該先篩選dt，然后再判斷user_id不為空。

使用dt分區(qū)表時where篩選條件中分區(qū)字段要放在前面

改完了之后，能跑是能跑了，而且?guī)追昼娋团芡炅?#xff0c;map和reduce都到了100%，但是最后要把數(shù)據(jù)寫到表里的時候卻巨慢無比，又花了好幾個小時。

結(jié)果我一看數(shù)據(jù)，我的天，不太對勁，本來a表只有幾億條記錄，結(jié)果寫入res_table之后一下變成十幾億條記錄，這妥妥的是產(chǎn)生笛卡爾積了啊。

然后看了一篇文章：left join 與join都會形成笛卡爾積

確認(rèn)了一下，確實是產(chǎn)生笛卡爾積了，但是type_id應(yīng)該是唯一的啊，一問才知道，原來b表是快照表，限制最新分區(qū)，我沒卡dt，所以才產(chǎn)生了笛卡爾積。

最后改完就好啦：

-- 演示代碼，無實際業(yè)務(wù) set hive.auto.convert.join=true;create table res_table as selecta.*,b.type from ((select*fromorder_tablewheredt >= '2021-07-01'and dt <= '2021-07-31' and user_id <> ''and user_id is not null) as aleft join (select*fromorder_type_tablewheredt = '2021-07-01') as bon a.type_id = b.type_id; ) 與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的【Hive】一次被分区条件和笛卡尔积制裁的经历的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。