Apache Airflow最佳实践：（Python）运算符或BashOperators

Question

这些天我正在开发一个新的ETL项目，我想尝试一下Airflow作为工作经理。 我和我的同事都是第一次使用Airflow，我们遵循两种不同的方法：我决定编写python函数（运算符，如apache-airflow项目中包含的那些），而我的同事使用气流来调用外部python脚本通过BashOperator。

我想知道是否有类似“良好实践”的东西，如果这两种方法同样好，或者我应该考虑另一种方法。

对我来说，主要的区别是： - 使用BashOperator，您可以使用特定包的特定python环境调用python脚本 - 使用BashOperator，任务更加独立，如果气流发生，可以手动启动 - 使用BashOperator任务进行任务通信有点难以管理 - 使用BashOperator任务错误和故障更难管理（bash任务如何知道它之前的任务是否失败或成功？）。

您怎么看？

Answer 1

在这些情况下，我个人的偏好是在BashOperator上使用PythonOperator。这就是我的工作和原因：

• 包含我所有DAG的单个回购。此repo还有setup.py，其中包括气流作为依赖项，以及我的DAG所需的任何其他内容。气流服务是从安装这些依赖项的virtualenv运行的。这将处理您提到的有关BashOperator的python环境。
• 我尝试将所有与Airflow无关的Python逻辑放在自己的外部打包的python库中。该代码应该有自己的单元测试，并且还有自己的主要代码，因此可以在独立于Airflow的命令行上调用它。这解决了你关于气流何时发疯的观点！
• 如果逻辑足够小以至于将它分离到自己的库中是没有意义的，我将它放在我的DAG仓库中的utils文件夹中，当然还有单元测试。
• 然后我用PythonOperator在Airflow中调用这个逻辑。与BashOperator模板脚本不同，python callable可以很容易地进行单元测试。这也意味着您可以访问诸如启动Airflow数据库会话，将多个值推送到XCom等等。
• 就像你提到的，Python的错误处理更容易一些。您可以轻松捕获异常并检查返回值。您可以选择使用raise AirflowSkipException将任务标记为已跳过。

对于BashOperator的FYI，如果脚本以错误代码退出，Airflow会将任务标记为失败。

Answer 2

TaskA在源处检查数据可用性。 TaskB处理它。

任务A >>任务B

这两个任务都使用BashOperator调用python脚本。我曾经从TaskA触发的script1返回sys.exit（1）（当源中没有数据时），作为通信Task A的一种方式，因为没有数据并且不需要运行任务B，因此失败了。