背景:每天大数据平台核心就是出报表,而核心的中间表底层是大量的报表都会依赖它运行,我们称这个报表为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在机器繁忙时候多次排队过程造成等待时间过长)。测试上线没问题,后续出数正常