闲聊调度系统 Apache Airflow
开始之前
Apache Airflow 是一个由开源社区维护的，专职于调度和监控工作流的 Apache 项目，于2014年10月由 Airbnb 开源，2019年1月从 Apache 基金会毕业，成为新的 Apache 顶级项目。
Apache Airflow（以下简称 Airfolw ）的概念相对比较复杂，比较核心的有 DAG 、Operators 、Tasks 三个概念。DAG 表示的是由很多个 Task 组成有向无环图，可以理解为 DAG 里面的一个节点，Task 的由 Operators 具体执行，Operators 有很多种，比如运行 Bash 任务的 Operators 。
网上关于 Apache Airflow 的文章汗牛充栋，那为什么我还要写这篇文章呢？写这篇文章的初衷很简单，Apache Airflow 在我们团队稳定地运行了一年半，线上有着三百多个调度 DAG ，一两千个 Task ，有长时间运行的流任务，也有定时调度任务，所以写一篇文章，回顾下这一年的使用感受。
本文属于闲聊，自然不会牵扯到复杂的技术细节和名词，单纯聊下感受。
源起
刚开始的时候，团队一直都在使用 Linux 系统自带的定时任务（Crontab），Crontab 开发起来非常简单，可能唯一的难点就是 cron 语法。在团队的早期，使用 Crontab 毫无问题，但是随着调度任务开始变多，Crontab 这种简单的方式开始出现问题了。例如有一个任务每天定时从 FTP 服务器取数据到数据库里，有时候上游没有把数据及时放到 FTP 服务器，或者是数据库那天出了啥问题，开发者如何得知任务失败了，如何方便地获得日志等等；再者，任务变多之后，如何管理这么多的任务也变得棘手起来等等，除了这个以外，还有一个至关重要的数据安全问题，即如何统一管理连接信息，而不是明文写在脚本里。
因为出现了问题，那么便要解决问题。于是就开始调研有没有合适的调度系统去解决这些问题。
选型
现在的开源调度系统分为两类：以 Quartz 为代表的定时类调度系统和以 DAG 为核心的工作流调度系统。首先看看定时类调度系统，它们的设计核心是定时运行、数据分片和弹性扩容，但是对依赖关系支持的不太友好，更适用于后端业务开发，其代表为 XXL-JOB 、Elastic-Job 。而数据团队最常见的操作是的 ETL （抽取、转换和加载数据），更强调的是任务的依赖关系，所以关注点便是以 DAG 为核心的工作流调度系统了。
目前主流的工作流调度系统有 Oozie、Azkaban、Airflow、Luigi、Dagobah 和 Pinball，除了这些以外还有今年十月开源的新的 Apache 孵化项目 Apache dolphinscheduler。另外还有一个专门收集 Pipeline 系统的 Github 项目：https://github.com/pditommaso/awesome-pipeline。网上的比较各类工作流调度系统的文章很多，在此不多赘述，仅仅讲述当时选型时对各个调度系统的看法：
- Oozie：Oozie 是基于 XML 格式进行开发的，后续集成到 Hue 里可以可视化配置，但是缺点也很明显，版本管理、日志收集都不太友好，开发灵活性很差，可调度的任务也很少，另外定义过于复杂，维护成本很高。当然最核心还是没有共用变量和共用连接信息的概念。
- Azkaban：和 Oozie 差不多，缺点也很明显，最核心的问题还是没有共用变量和共用连接信息的概念。
- Luigi、Dagobah 和 Pinball：基本上已经不维护，所以不再考虑了。
- Airflow：安装和部署都非常简单，后续会进行详述。
- dolphinscheduler：这个是国人开发和贡献的，比 Airflow 略差一些，但是胜在中文支持比较好。另外：如果 dolphinscheduler 能在2018年开源，可能就会选择这个了。
- 其它：从 Github 列表里选择了几个工作流系统测试，发现很多系统功能都不完善，例如监控、任务流依赖、日志收集等或多或少有缺失，所以不再考虑了。
Apache Airflow 缺点
优点后面再说，先聊聊缺点。
The DAG definition is code
The DAG definition is code，即是优点，也是缺点。优点在于写代码意味着可维护性、版本管理、可测试性和协作性更好，但是 Python 本身相对于其它编程语言入门是难度较低，不过比起写 SQL 来还是有一定难度。
时区问题
时区问题真的是一言难尽。当时 Airflow 从 1.9 版本开始全局统一使用 UTC 时间，虽然后续版本可以配置化了，但是当时的 1.9 版本还不能进行更改。虽然我理解这种设计是为了解决当 Airflow 集群分布在不同时区的时候内部时间依然是相同的，不会出现时间不同步的情况。但是我们的节点只有一个，即使后面扩展为集群，集群内部的时间也会是同一个时区。如果不用本地时区的话，使用 UTC 时间很容易对开发者造成困惑。当时又不想降版本到 1.8 ，因为 1.9 新增的很多功能都是很有意义的。最后是在 Github 上发现孵化中的 2.0 版本时区已经可以配置化了，我们就直接使用 Github 上的孵化版本了。
执行时间的概念
Airflow 的执行时间（execute date）的概念，有点反常识。一般人认为调度任务的执行时间就是运行时间，但是 Airflow 的执行时间是与调度周期有关，指的是前一个运行周期的运行时间。与常识不同，但是符合数据处理的逻辑。
Backfill
Airflow 有一个 backfill 的功能，可以支持重跑历史任务，但是只能在命令行执行，要是在 WebUI 上就需要一个个 clear 掉状态，有时候挺痛苦的。
为什么选择 Airflow 呢？
前面说了这么多缺点，那为什么还是选择了 Airflow 呢？就像 Airflow 的官网写的，Airflow 有很多优点，并且像阿里等大公司也有许多实践案例证明 Airflow 是经得起复杂的生产环境的考验。相关文章很多，在此不赘叙，仅聊聊下它解决了我们的哪些痛点。
- 共用连接信息和共用变量 因为我们公司有定期修改数据库密码诸如此类的安全要求，有了 Airflow 的共用连接信息的功能，每次改密码都只需要在网页上更新密码，而不需要像之前那样一个个手工找到各个脚本去更改密码。除了这个以外，还有各种好处，真的极大的提高了开发效率。
- Airflow 有着非常完备的 UI 界面和监控手段。
- 本身具有的 Operators 就很多，再者，扩展 Airflow 的 Operators 相当方便。这意味着我们可以调度任意类型的任务。
参考资料
学习和使用 Airflow 最好的资料就是它的官方文档：https://airflow.apache.org/ Github 上有一些很多的教程，比如：https://gtoonstra.github.io/etl-with-airflow/great.html 中文的实践可以参考阿里写的Maat：https://yq.aliyun.com/articles/609299
最后
可以这么说，Airflow 是一个非常成熟的工作流调度系统，基本上把数据处理中会遇到的坑都填上了。如果你们的团队的编程语言是以 Python 为主的，那么选择 Airflow 准不会错。