hive數(shù)據(jù)傾斜解決辦法？數(shù)據(jù)向下的原因：在進行shuffle的時候，要將各個節(jié)點上相同的key拉取到某個節(jié)點上的一個task來進行處理，諸如按照key并且聚合或join等操作。此時假如某個key對應

hive數(shù)據(jù)傾斜解決辦法？

數(shù)據(jù)向下的原因：在進行shuffle的時候，要將各個節(jié)點上相同的key拉取到某個節(jié)點上的一個task來進行處理，諸如按照key并且聚合或join等操作。此時假如某個key對應的數(shù)據(jù)量而且大的話，都會不可能發(fā)生數(shù)據(jù)向下。諸如大部分key不對應10條數(shù)據(jù)，只不過個別key卻不對應了100萬條數(shù)據(jù)，那就大部分task肯定就只會分配到10條數(shù)據(jù)，接著1秒鐘就不運行完了；但是其它task可能先分配到了100萬數(shù)據(jù)，要正常運行一兩個小時。

解決方案：

第一點：真接過濾處理掉那些過多下沉的Key。這種方法很簡單的，呢既然你傾斜，那我你不你就好了。比如，共有有100萬個key。只有2個key，是數(shù)據(jù)量提升到10萬的。其他所有的key，按的數(shù)量都是幾十，那樣join后會紊亂向外傾斜。此時此刻，自己是可以去取舍，如果沒有業(yè)務和需求這個可以明白和給予的話，在從hive表查詢源數(shù)據(jù)的時候，真接在sql中用where條件，過濾掉某幾個key。這樣這幾個原來有大量數(shù)據(jù)，會導致數(shù)據(jù)向外傾斜的key，被過濾后掉之后，那么在的spark作業(yè)中，自然就不會再一次發(fā)生數(shù)據(jù)傾斜了。

第二點：HiveETL做處理

通過HiveETL作好對數(shù)據(jù)聽從key參與聚合，也可以是預先和其他表并且join，接著在Spark作業(yè)中是對的數(shù)據(jù)源就不是原來的Hive表了，只是預處理后的Hive表。此時由于數(shù)據(jù)已經(jīng)預先參與過聚合或join操作了，這樣的話在Spark作業(yè)中也就不不需要可以使用原先的shuffle類算子負責執(zhí)行這類能操作了。Hive ETL中通過group by或是join等shuffle操作時，我還是會直接出現(xiàn)數(shù)據(jù)傾斜，造成Hive ETL的速度很慢。我們只不過是把數(shù)據(jù)偏轉的發(fā)生晚幾天到了HiveETL中。

第三點：能提高shuffle的操作分頭并進度在對RDD不能執(zhí)行shuffle算子時，給shuffle算子傳去一個參數(shù)，比如reducebykey(1000)，該參數(shù)就系統(tǒng)設置了這個shuffle算子執(zhí)行時shufflereadtask的數(shù)量。對此SparkSQL中的shuffle類語句，.例如group by、join等。

如何查看hive的元數(shù)據(jù)存儲位置？

可以不在hive的配置文件中欄里點，hive在安裝好前要配置元數(shù)據(jù)的存儲