cesium加载倾斜优化_数据开发必经之路-数据倾斜

前沿

数据倾斜是数据开发中最常见的问题，同时也是面试中必问的一道题。那么何为数据倾斜？什么时候会出现数据倾斜？以及如何解决呢？

何为数据倾斜：数据倾斜其本质就是数据分配不均匀，部分任务处理大量的数据量导致整体job的执行时间拉长。

什么时候出现数据倾斜：无论是spark,还是mapreduce，数据倾斜大部分都是出现在shuffle阶段，也就是所谓的洗牌，由于使用的洗牌策略不一样，那么数据划分也就不一样，一般常用的也就是hash算法了。

基于上面两个问题的解答，对于数据倾斜的解决方案其本质就是如何把数据分配均匀。

笔者认为根据优化策略可以分为业务层面的优化和技术层面的优化

首先业务层面的优化就是结合实际的业务场景和数据特性进行优化，而技术层面的优化其本质就是对存储和计算两大组件的优化，然后根据不同的技术(hive,spark)使用不同的参数或者函数方法。

接下来将分别对这两种策略进行详细讲解

技术层面优化

Hive

这里讨论的是仍然是以mapreduce为底层引擎，hive on tez这种模式不做讲解，其优化思想还有参数大多数都是一样的。

1.参数优化

这里给出一些关于数据倾斜相关的参数配置，一般只能起到缓解的作用，不能完全解决倾斜问题。其中有些优化参数暂时未涉及(如map端，reduce端,jvm,压缩等有优化点)

2.Sql优化

数据倾斜出现的原因一方面是数据特性，另一方面是人为导致的,sql开发较粗糙导致的(占主要部分)。这里给出几个常见的sql倾斜的场景以及解决思路

2.1 Join优化

hive根据join key进行划分并发生shuffle，所以选用的key尽量分布均匀。目前出现的场景无非就是大表和小表关联，小表和小表关联(一般不会出现倾斜)，大表和大表关联，这里针对这几种情况分别进行讲解

2.1.1 大表join小表-MapJoin

这里的大小表是相对来说的，如果一个A表数据量有1亿，而B表有1千万，那么B表就是一个小表。当B表中的key分布比较集中，那么在进行shuffle的时候就会有一个或者某几个reduce上的数据量较高于平均