呼叫結果(call_result)與銷售歷史(sale_history)的join優化：
call_result: 32億條/444g
sale_history:17億條/439g
總體來看，效果都不明顯；hive預設使用reduce side join，當兩個表中有乙個較小的時候可以考慮map join
，但這兩個表都是大表，可以嘗試使用bucket map join；基本處理方法是將兩個表在join key上做hash
bucket，將較小表（sale_history）的bucket設定為較大表（call_result）的數倍。這樣資料就會按照join
key做hash bucket。這樣做的話，小表依然會複製到各個節點上，map
join的時候，小表的每一組bucket載入成hashtable，與對應的大表bucket做區域性join。
如果兩表的join key 都具有唯一性（是主鍵關聯），還可以進一步做sort merge bucket map join
；做法是兩表都做bucket的基礎上，每個bucket內部還要進行排序，這樣做得好處就是在兩邊的bucket要做區域性join的時候，用類似merge
sort演算法中的merge操作一樣把兩個bucket順序遍歷一下即可。
然而以上兩種方法經過測試依然沒有太好的效能表現；穩定在20min之內已經不錯了，又要考慮從源庫抽取資料如何保留等問題，最終無法採用，後經過和業務系統溝通，兩表每天資料量巨大，業務系統不會更新歷史資料，每個表當天的資料是一一對應的，即當天的呼叫和銷售歷史是對應的，因此將程式優化為當天增量資料關聯，資料下降幾個數量級，自然不存在效能問題；
所以，優化無止境，不一定非技術手段不可，首先基於業務邏輯做優化，要做到業務與技術相結合。
兩大表求補集的方法總結
場景 題庫中隨機出題,使用者已經做過的題需要排除掉.方法大概如下 1 oracle資料庫可以直接用minus 2 mysql資料庫需要使用left join，例如 select q.id,q.questionguid from question as q left join select id,qu...
hive大表join空key優化
假如不需要id為null的資料！此時可以將a表中id為null的字段提前過濾，減少mr在執行時，輸入的資料量！解決 將null值過濾，過濾後再執行join select from a where c is not null a left join b on a.c b.ca表中c欄位為null的資料...
Hive中小表與大表關聯 join 的效能分析
經常看到一些hive優化的建議中說當小表與大表做關聯時，把小表寫在前面，這樣可以使hive的關聯速度更快，提到的原因都是說因為小表可以先放到記憶體中，然後大表的每條記錄再去記憶體中檢測，最終完成關聯查詢。這樣的原因看似合理，但是仔細推敲，又站不住腳跟。多小的表算小表？如果所謂的小表在記憶體中放不下怎...