spark 数据倾斜解决方案 聚合源数据以及过滤导致倾斜的key_spark中groupby倾斜key

数据倾斜的解决，跟之前讲解的性能调优，有一点异曲同工之妙。
性能调优，跟大家讲过一个道理，“重剑无锋”。性能调优，调了半天，最有效，最直接，最简单的方式，
就是加资源，加并行度，注意RDD架构（复用同一个RDD，加上cache缓存）；shuffle、jvm等，次要的。

数据倾斜，解决方案，第一个方案和第二个方案，一起来讲。最朴素、最简谱、最直接、最有效、
最简单的，解决数据倾斜问题的方案。

第一个方案：聚合源数据
第二个方案：过滤导致倾斜的key

重剑无锋。后面的五个方案，尤其是最后4个方案，都是那种特别炫酷的方案。
双重group聚合方案；sample抽样分解聚合方案；如果碰到了数据倾斜的问题。
上来就先考虑考虑第一个和第二个方案，能不能做，如果能做的话，后面的5个方案，都不用去搞了。

有效。简单。直接。效果是非常之好的。彻底根除了数据倾斜的问题。

第一个方案：聚合源数据

1，每个KEY在HIVE ETL中变成一条数据，彻底解决spark都不用做groupByKey
2，如果有好几个力度，尽量粗粒度的聚合一下，减轻症状，spark聚合的时候减轻症状

咱们现在，做一些聚合的操作，groupByKey、reduceByKey；groupByKey，说白了，
就是拿到每个key对应的values；reduceByKey，说白了，就是对每个key对应的values执行一定的计算。

现在这些操作，比如groupByKey和reduceByKey，包括之前说的join。都是在spark作业中执行的。

spark作业的数据来源，通常是哪里呢？90%的情况下，数据来源都是hive表
（hdfs，大数据分布式存储系统）。hdfs上存储的大数据。hive表，hive表中的数据，
通常是怎么出来的呢？

有了spark以后，hive比较适合做什么事情？hive就是适合做离线的，
晚上凌晨跑的，ETL（extract transform load，数据的采集、清洗、导入），hive sql，
去做这些事情，从而去形成一个完整的hive中的数据仓库；说白了，数据仓库，就是一堆表。

spark作业的源表，hive表，其实通常情况下来说，也是通过某些hive etl生成的。
hive etl可能是晚上凌晨在那儿跑。今天跑昨天的数据。

数据倾斜，某个key对应的80万数据，某些key对应几百条，某些key对应几十条；现在，
咱们直接在生成hive表的hive etl中，对数据进行聚合。比如按key来分组，将key对应的所有的values，
全部用一种特殊的格式，拼接到一个字符串里面去，
比如“key=sessionid, value:
action_seq=1|user_id=1|search_keyword=火锅|category_id=001;
action_seq=2|user_id=1|search_keyword=涮肉|category_id=001”

对key进行group，在spark中，拿到key=sessionid，values；
hive etl中，直接对key进行了聚合。那么也就意味着，每个key就只对应一条数据。
在spark中，就不需要再去执行groupByKey+map这种操作了。直接对每个key对应的values字符串，
map操作，进行你需要的操作即可。key,values串。

spark中，可能对这个操作，就不需要执行shffule操作了，也就根本不可能导致数据倾斜。
或者是，对每个key在hive etl中进行聚合，对所有values聚合一下，不一定是拼接起来，
可能是直接进行计算。reduceByKey，计算函数，应用在hive etl中，每个key的values。

聚合源数据方案，第二种做法

你可能没有办法对每个key，就聚合出来一条数据；
那么也可以做一个妥协；对每个key对应的数据，10万条；有好几个粒度，比如10万条里面包含了
几个城市、几天、几个地区的数据，现在放粗粒度；直接就按照城市粒度，做一下聚合，
几个城市，几天、几个地区粒度的数据，都给聚合起来。比如说
city_id date area_id
select … from … group by city_id
尽量去聚合，减少每个key对应的数量，也许聚合到比较粗的粒度之后，原先有10万数据量的key，
现在只有1万数据量。减轻数据倾斜的现象和问题。

上面讲的第一种方案，其实这里没法讲的太具体和仔细；只能给一个思路。但是我觉得，
思路已经讲的非常清晰了；一般来说，大家只要有一些大数据（hive）。经验，我觉得都是可以理解的。

具体怎么去在hive etl中聚合和操作，就得根据你碰到数据倾斜问题的时候，
你的spark作业的源hive表的具体情况，具体需求，具体功能，具体分析。

对于我们的程序来说，完全可以将aggregateBySession()这一步操作，放在一个hive etl中来做，
形成一个新的表。对每天的用户访问行为数据，都按session粒度进行聚合，写一个hive sql。

在spark程序中，就不要去做groupByKey+mapToPair这种算子了。直接从当天的session聚合表中，
用Spark SQL查询出来对应的数据，即可。这个RDD在后面就可以使用了。

第二个方案：过滤导致倾斜的key

如果你能够接受某些数据，在spark作业中直接就摒弃掉，不使用。比如说，总共有100万个key。
只有2个key，是数据量达到10万的。其他所有的key，对应的数量都是几十。
这个时候，你自己可以去取舍，如果业务和需求可以理解和接受的话，在你从hive表查询源数据的时候，
直接在sql中用where条件，过滤掉某几个key。
那么这几个原先有大量数据，会导致数据倾斜的key，被过滤掉之后，那么在你的spark作业中，
自然就不会发生数据倾斜了。因为其它的量都很小当然就不会倾斜了。
and session_id not in ( , , )

如果你没有什么维度可以让key去聚合，还有就是没有什么key可以去被过滤掉，那么就是后面5种方案！