Open Joldnine opened 6 years ago
用Hive做ETL的时候,经常会遇到数据倾斜(Data Stew)的问题,记录总结一下。
平时大概率遇到的可能有以下几类:
join时的数据倾斜一般是因为某些key对应的数据量比较大。思路一般是:
我们有2个表,一个pv表,一个seller表。 dwd_pv 流量表字段: visit_time, product_id, seller_id 假设有10亿行 dim_seller 卖家表字段: seller_id, seller_name 假设有一千万行
Query:
SELECT visit_time, product_id, pv.seller_id, seller_name FROM dwd_pv AS pv LEFT OUTER JOIN dim_seller AS slr ON pv.seller_id = slr.seller_id;
这就是一个普通的补字段SQL,但是在某些个seller流量特别大的情况下会发生数据倾斜。 为了解决这个问题,我们先了解一下HIVE里的join(Shuffle Join)发生了什么:
group by 造成的数据倾斜和join类似,group by里的某个字段数据量太大。思路一般是:
思路: key splitting。
用Hive做ETL的时候,经常会遇到数据倾斜(Data Stew)的问题,记录总结一下。
分类
平时大概率遇到的可能有以下几类:
解决办法
join
join时的数据倾斜一般是因为某些key对应的数据量比较大。思路一般是:
1. 数据去重或者裁剪
2. 如果是大表join小表,使用mapjoin
3. 如果知道热点的key的具体值,可以用skewjoin。
4. 思考业务上这样join是不是必须的,这种大量数据的key进行笛卡尔积(Cartesian product)是否合理,有没有变通方法
5. 在特定情况下,以上四种方法都没办法解决,需要具体情况具体分析。这里,我们可以挑一个大商家的经典例子分析一下。
我们有2个表,一个pv表,一个seller表。 dwd_pv 流量表字段: visit_time, product_id, seller_id 假设有10亿行 dim_seller 卖家表字段: seller_id, seller_name 假设有一千万行
Query:
这就是一个普通的补字段SQL,但是在某些个seller流量特别大的情况下会发生数据倾斜。 为了解决这个问题,我们先了解一下HIVE里的join(Shuffle Join)发生了什么:
group by
group by 造成的数据倾斜和join类似,group by里的某个字段数据量太大。思路一般是:
count distinct
思路: key splitting。