网易云音乐大 Flow 任务优化实践

导读: 最近接了一个大 flow 优化任务,这个任务是用来做新用户的归属,属于比较重要的任务,但是任务产出时间比较晚,一般要到 15 点之后才能完成,非常影响数据分析。和这个任务有关联的 flow 有 4 个,主 flow 有 67 个节点和其他 flow 加在一起超过了 100+ 节点。

Flow 优化过程包括:

  • 长时间 Job 优化
  • 关键节点 Job 优化
  • 调度优化
  • 队列优化

1 长时间 Job 优化

遇到优化整个 flow 的情况,第一个想法肯定是优化其中执行时间最长的任务,下面介绍两个优化明显的例子。

例子 1:优化业务逻辑实现方式
image.png

看到这俩任务心里一喜图片

因为这个执行时间太异常了,超过了 10 个小时,即使数据很大也不太可能单个 job 需要执行这么久,基本认定是代码写的有问题,找到这俩任务对应的代码,扫了一遍果然发现了问题,简化代码逻辑如下:

图片

这段代码有两个问题:

  • 数据是 append 到目录中的,如果任务执行到一半失败了,并不会清除目录中写成功的数据,重新回跑任务就会造成数据重复;
  • 每次 for 循环会触发一次 spark job 执行,所有 job 是串行的,任务越多执行时间越慢。

针对这两个问题做了如下优化:

每次 for 循环不触发 spark job,而是生成一张 TempView 再 union all 所有的 view 表触发一次 spark job,这样串行 job 就变成了并行的 stage,而且最终结果可以用 overwriter 一次性写入到目的路径中。

图片

** 例子 2:优化分区使用方式**

图片

这个任务中有一块逻辑用到了一张超大的分区表,业务只需要读取其中两个分区,简化代码实现如下:

图片

这块代码用了 activeclick/adclick 两个分区,但是用 or 做连接,在 spark2.3.2 action = 'a' or (action = 'b' and ${filter})会读取所有分区的数据, 并不是只读 a b 两个分区耗时很长。

图片

优化代码如下:



图片

图片

2 关键节点 Job 优化

什么是关键节点呢?下图中的 A 就是关键节点,这里的关键节点不是说任务很重要,而是在 flow 图的结构中很关键,优化这个节点可以直接提升整个 flow 的产出时间,关键节点有两个特点:

  • 这个任务的结束时间决定下一级任务的开始执行时间;
  • 执行时间较长。也就是说有一段时间整个 flow 只有这一个任务在执行,优化这个任务就能很明显提升整个 flow 的时间。

图片

在我优化的这个 flow 里面就有几个关键节点,举一个例子说一说。resource 节点在 8:20 - 8:53 这个时间点整个 Flow 只有这一个任务在执行,如果能优化这个任务就能直接提前下一级任务开始时间。

图片

分析任务代码和日志后发现这个任务是有优化点的,这个任务使用了动态分区,数据写入花费了将近 1h 时间,占了整个任务之间的 2/3。然后分析了依赖这个分区表的任务,大部分任务都没用到动态的那个分区,只有一个小任务用到了第二分区,且非必须。所以打算把动态分区取消掉,只保留日期分区。

图片

3 调度优化

优化完上面两个任务后,又分析了下其他执行时间较长的任务,并没有发现明显的优化点,但是在过程中发现了一个新的问题,flow 中的任务并没有按照调度时间被调度起来,而是延迟了 1h,如下 A_Dep, B_Dep, C_Job 都已经满足调度条件,但是只有 A_Dep, B_Dep 被调度了 C_Job 1h 后才开始调度。

图片

这个问题把同优先级的并行任务变成了串行任务,严重影响了执行时长,基于这个问题去看了 azkaban 官网然后询问了相关同学,发现 flow 的 job 并行度默认是 10,而我这个 flow 同时需要执行的任务是超过 10 个的,然后做了下面的调整,把并行度调整到了 30,所有的任务都能被正确的调度起来。

图片

4 队列优化

做了上面这些优化之后,任务的完成时间已经优化到了 11 点半左右,其他能优化的点短期也找不到更多了,接下来就把目标放到了队列资源上,分析了一波任务的启动日志,很明显的发现资源是不足的,如下 outside 节点从 6:45 开始调度,7:37 才真正申请到资源。

图片

图片

图片

这种情况没有别的更好的办法了,于是又从其他队列申请了部分新资源加入到了这个任务队列中来缓解资源不足的情况。

5 结果

现在这个任务已经连续几天可以在 10 点半之前产出了,优化任务先告一段落,后面还会持续对这个 flow 关注和优化。

作者简介

中帅,网易云音乐资深数据开发工程师,长期从事大数据开发相关工作。曾在华为从事 spark 框架开发优化,spark 社区 contributor;在云音乐先后负责风控反爬虫和实时计算平台的搭建,当前专注于大数据产品的开发,负责用户画像系统、用户行为分析系统、推歌系统、数据服务等数据产品的开发工作。


本文地址:https://www.6aiq.com/article/1626890691669
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出