任务耗时太长怎么办？（如何优化数据任务）
任务耗时太长怎么办？
开发完需求之后，并不是万事大吉了。因为离线任务每天要运行，任务维护的工作，有时候比开发成本还高。
比较常见的问题是任务占据大量资源，耗时太久，无法按时产出，或者直接因资源不足失败。
如果只是个别任务占用过多资源，增加维护成本，还好解决。大不了拆分任务，或者直接下线任务。
最怕的是开发任务的时候，没有考虑过任务运行效率，导致整体资源不足以维护任务稳定按时产出，各种意外频发，防不胜防。那就不是处理个别任务就能解决的问题了。
而此时，要么财大气粗，直接加倍扩容。否则只能投入额外的人力对任务进行优化。
任务优化目的是为了任务减少资源（主要指计算资源）占用，减少任务耗时。
单纯的用资源换时间或时间换资源，，我认为只是换了一种任务运行方案，不算是优化任务，除非对应资源多到不用是浪费的程度。
提到任务优化，不少人第一时间考虑的是技术上的，是不是数据倾斜？是不是小文件过多？是不是reduce数量太少？
但我觉得，在考虑如何使用技术手段之前，还有更应该考虑的问题
- 任务是否能下线？下线的任务优化程度是100%。
- 任务能不能降低频率？原来15min一次的能不能改成60min？能释放某些时段的资源。
- 任务能不能延后运行，放到资源空闲时期运行？空闲的计算资源基本上等于浪费，能用就是多出来的。
- 任务读取的数据量能不能减少？比如原来任务要取近30天的数据，能不能只取15天。减少一半数据量，会减少大量的计算时间。
- 任务能不能先筛选，后JOIN？与其JOIN完后再where 筛选掉 is null的数据，不如先筛选掉，这部分数据就不会参与计算。
- 任务join的时候是否产生了笛卡尔积？能否避免这种情况？
- 任务能不能不在where后使用函数？如果先用确定的条件筛选掉一批数据后，再使用函数计算作为条件筛选，筛选掉的数据不会参与函数计算。如果筛选掉的数据量大，函数计算量大，效果更明显。
- 任务能不能把一段SQL分成多段SQL，中间数据存到临时表里？如果一段SQL有多次JOIN和大量嵌套计算，可以将join和嵌套分成多个独立SQL，计算后存到临时表中。后续计算读取临时表的数据，很多时候速度会快上好几倍。估计是一段SQL如果有多次计算，数据会存到内存中，内存不足会使用硬盘存储，但自动存储的效率可能太低。如果拆分成多个SQL，每次运算临时数据都是内存，结果在硬盘，应该会减少硬盘的存储和读取次数。
- 然后再考虑是否数据倾斜（map端、reduce端）、是否小文件过多、是否reduce过少、是否读取了不需要的列、是否distinct导致的问题、是否资源被限制、是否配置有问题等等。（数据倾斜是任务耗较长最常见的技术问题，但仅能减少单个任务耗时，无法释放资源）
根据我历史优化任务的经验，下线任务能解决80%的资源占用问题，减少任务读取的数据量能解决80%任务耗时长的问题。
技术人员，确实应该使用技术手段解决问题。可如果技术手段不是最有效手段时，执着于技术，就像拿着锤子的人，看到什么都是钉子。
点击 数据文章目录 查看更多
注： 以上所有内容不确保正确准确， 仅是个人思考的结果， 欢迎交流沟通
V1.0 2020年10月21日
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！