背景：每天大数据平台核心就是出报表，而核心的中间表底层是大量的报表都会依赖它运行，我们称这个报表为142.（因为报表我们这边编号是142）。预计依赖于它的报表有几十个展示。
问题现象：每天142报表的运行时间达到10---15小时。导致底层报表计算大量延迟。于是进行报表排查和重整sql逻辑。
分析sql过程发现除了普通查询和计算，核心有6个left join。于是进行left join每个测试。发现最后两个left join分别耗时3--7小时，于是定位到需要优化的点。
倾斜点分析：首先跑hive 起MR的时候到yarn观察，发现其中会出现一些容器跑得很久，初步判断是数据倾斜。于是对left join的关联key进行分布分析。发现总体确实均匀，但是个别key达到其他普通量的百倍。再次定位到了数据倾斜的点了。
问题解决：
1.和业务商量，这些大量倾斜的数据是否需要归入计算，能否筛除，业务那边是说不行。
2.将最后两个left做成了分段sql。因为每次left join倾斜部分是关联不上的，于是将这部分数据先查询到中间表temp1.数据计算后，将temp1多余字段补null然后两部分unionall起来，这时候left join的结果值是一致的，只是数据顺序性变了（询问了sql开发顺序变不会对报表造成影响），其实即使需要left join纳入计算，筛选出来后再去计算也会比直接丢一个sql里面数据倾斜块，因为key不会选择关联的内容。）
优化后报表30分钟出数，生产繁忙情况是2小时（优化的带来不好的地方，多段sql 容易起多个MR。而MR队列机制会导致某个MR在机器繁忙时候多次排队过程造成等待时间过长）。测试上线没问题，后续出数正常