“任务执行缓慢”通常是指任务的执行时间超过10个小时，且不能满足数据使用方对数据及时性的要求。比如业务方需早上就能够查看T-1的数据，但是因为任务延时，业务方只能等到下午或者傍晚才能查询、浏览T-1的数据，从而无法及时发现经营问题、进行高效决策。因此，对缓慢任务进行优化成了ETL工程师必不可少的一项工作。

在长期的大数据实践中，我们发现，缓慢任务往往具有一定的共性。只要我们能找到问题所在，并对症下药，就能将任务执行时间大大缩短。个推将任务执行缓慢的常见问题归纳为以下四点：逻辑冗余，数据倾斜、大表复用，慢执行器。接下来会对每个痛点进行详细阐述。

1、逻辑冗余

“逻辑冗余”往往是因为ETL工程师进行数据处理和计算时更关注处理结果是否满足预期，而未深入考虑是否存在更高效的处理方式，导致原本可通过简单逻辑进行处理的任务，在实际中却使用了复杂逻辑来执行。

减少“逻辑冗余”更多地依赖开发者经验的积累和逻辑思维以及代码能力的提升。这里分享一些高级函数，希望能够帮助开发者进一步提升数据处理效率。

分组统计函数。这个函数可以实现在一段SQL中输出不同维度的统计数据，避免出现执行多段SQL的情况，具体写法如下：

一行转多行函数。这个函数只能处理array格式数据，需要配合split()函数使用，具体写法如下：

还有其他一些函数、函数名及功能如下，具体用法需要读者自行查询（可登录hive官网查询函数大全）：

• find_in_set() ：查找特定字符串在指定字符串中的位置

• get_json_object()：从json串中抽取指定数据

• regexp_extract()：抽取符合正则表达的指定字符

• regexp_replace() ：替换符合正则替换指定字符

• reverse()：字符串反转

“数据倾斜”是指在MR计算的过程中某些Map job需要处理的数据量太大、耗时太长，从而导致整个进程长时间无法结束，任务处理进度长时间卡在99%的现象。

针对数据倾斜的情况，开发者们可通过代码层面进行修改，具体操作如下：

• 使用group by方式替换count(distinct id ) 方式进行去重统计

• 进行大小表关联时使用mapjoin操作或子查询操作，来替换 join操作

• group by出现倾斜需要将分组字段值随机切分成随机值+原始值

• join操作避免出现笛卡尔积，即关联字段不要出现大量重复

在之前的文章中，个推详细解读了Hive数据倾斜的原因及解决方案，感兴趣的同学可点击了解：深入浅出Hive数据倾斜

“大表复用”，是指对上亿甚至几十亿的大表数据进行重复遍历之后得到类似的结果。避免大表复用就要求ETL工程师进行系统化的思考，能够通过低频的遍历将几十亿的大表数据瘦身到可重复使用的中间小表，且同时支持后续的计算。

因此，工程师需要在工程开发之初就将整体的工程结构考虑进去，并且坚持“大表仅使用一次”的原则，以提升整个工程的执行效率。

这里介绍一个实战中的例子，供读者参考：