业务背景
用户轨迹工程的性能瓶颈一直是etract_track_info,其中耗时大户主要在于trackinfo与pm_info进行左关联的环节,trackinfo与pm_info两张表均为GB级别,左关联代码块如下:
from trackinfo a
left outer join pm_info b
on (a.ext_field7 = b.id)
使用以上代码块需要耗时1.5小时。
优化流程
第一次优化
考虑到pm_info表的id是bigint类型,trackinfo表的ext_field7是string类型,其关联时数据类型不一致,默认的hash操作会按bigint型的id进行分配,这样会导致所有string类型的ext_field7集中到一个reduce里面,因此,改为如下:
from trackinfo a
left outer join pm_info b
on (cast(a.ext_field7 as bigint) = b.id)
改动为上面代码后,效果仍然不理想,耗时为1.5小时。
第二次优化
考虑到trackinfo表的ext_field7字段缺失率很高(为空、字段长度为零、字段填充了非整数)情况,做进行左关联时空字段的关联操作实际上没有意义,因此,如果左表关联字段ext_field7为无效字段,则不需要关联,因此,改为如下:
from trackinfo a
left outer join pm_info b
on (a.ext_field7 is not null