分析|Airflow任务调度延时问题分析和优化( 二 ) file|延时|process|分析|优

如果我们的线上dag编写全是py类型文件，在不需要zip文件的场景的操作下，可以将zip操作逻辑注释掉。
zip处理其实在整个dag的处理过程中占用了较多的时间，即使你的项目中没有zip文件，那么对于process_file函数中也会有这样的逻辑判断，这样的话其实对于扫描dag文件而言会存在大量的运算，导致整个调度延时。
小结：根据以上的粗略分析，我们后面可以重点针对dag解析原理和dag编写规范两个方向进行调度延时相关的优化。
磁盘的性能问题对调度延时的影响
在搭建部署airflow的时候，很多企业会采用以下两种方式部署：

文章插图
物理机部署的方式有其自身的优点但是也存在很多缺点。采用物理机方式在dag扫描和加载速度上要比容器化部署的方式快很多。
本质上的区别是：物理机直接从本地磁盘读取dag的内容，而容器化部署的方式则需要从网络磁盘读取内容，网络磁盘则需要走网络的IO。
所以从文件的加载效率上讲，物理机更胜一筹。但是物理机面临的问题也很多，比如资源的动态扩展，进程监控和重启机制等都不如容器化方便和高效。
与之对比，就容器化部署方式来说，目前业界最常用的就是基于k8s方式的部署。这种方式横向扩展airflow特别方便。
只要宿主机的资源比较大，那么对于airflow的web角色、scheduler角色，还是worker角色，扩展机器都是页面点击的操作，特别方便；甚至后面可以探究成自动的扩容和缩容机制。
并且在监控和报警层面k8s本身有自身的优势，包括进程的监控也有其自身独特的重启策略和机制。
对于资源的规划和分配，通过k8s也可以更好的去操作处理。但是k8s方式需要一个全局共享盘。一般来说我们常用的就是一些网络存储组件，无论是阿里的oss，nas还是亚马逊的s3等等，它们都有一个共性就是需要走网络IO，同时存在这数据一致性的风险。
网络IO的延时在T+1调度或者小时级调度粒度上也完全没有太多的问题，但随着业务量的增加比如10w+调度任务，可能就会存在延时问题。
小结：针对airflow的调度方式，我们可以根据自身的业务需要和任务量来选择部署方式，如果线上的任务数量很多，单个集群出现了性能瓶颈可以考虑多集群部署方式，来保证横向扩展解决IO的处理过慢的问题。
airflow的参数配置对调度延时的影响
对于dag延时调度在airflow的参数上也需要注意合理话的配置，一般这些影响参数可以包括如下：
单dag内部task并行度和集群并行度
parallelism：
全局(集群）任务最大并行度,这个值需要根据整体集群的性能配置和单结点worker进程数量进行配置，如果配置的过大，本身集群的性能跟不上也是徒劳的。假设我们的airflow的集群worker节点所启动的默认worker进程是10个，我们有10台机器，理论上讲最大并行度100左右，假设这个值配置200，最大也只能达到100的并发。

【精彩生活】jing111.com小编为您精选以下内容，希望对您有所帮助：