Apache Airflow最佳实践：（Python）Operators还是Bash Operators

Question

这些日子我在做一个新的ETL项目，想尝试一下Airflow作为作业管理器。我和同事都是第一次使用Airflow，并且采用了两种不同的方法：我决定编写Python函数（操作符，就像apache-airflow项目中包含的那些操作符一样），而我的同事则使用Airflow通过BashOperator调用外部的Python脚本。

我想知道是否有类似于“最佳实践”之类的东西，如果这两种方法一样好还是我应该考虑其中一种。

对我来说，主要区别在于： - 使用BashOperator，您可以使用特定的Python环境和特定的包调用Python脚本。 - 使用BashOperator，任务更加独立，如果Airflow出现问题，则可以手动启动任务。 - 使用BashOperator，任务之间的通信稍微难以管理。 - 使用BashOperator，任务错误和失败更难以处理（Bash任务如何知道它之前的任务是失败还是成功？）。

你觉得呢？

- user6300061

Answer 1

在这种情况下，我个人更喜欢使用PythonOperator而不是BashOperator。以下是我的做法和原因：

• 单个包含所有DAG的repo。该repo还具有一个setup.py文件，其中包括airflow作为依赖项以及任何其他DAG所需的内容。Airflow服务从安装这些依赖关系的虚拟环境运行。这处理了您在BashOperator中提到的python环境问题。
• 我尝试将与Airflow无关的所有Python逻辑放在其自己的外部打包的Python库中。该代码应具有其自己的单元测试，并且还具有其自己的主要功能，因此可以独立于Airflow在命令行上调用。这解决了您关于当Airflow出现问题时的问题！
• 如果逻辑很小，无法将其分离成自己的库，则将其放入DAG repo中的utils文件夹中，当然仍然需要进行单元测试。
• 然后我使用PythonOperator在Airflow中调用此逻辑。Python可调用对象可以轻松进行单元测试，而BashOperator模板脚本则无法进行单元测试。这也意味着您可以访问诸如启动Airflow DB会话、向XCom推送多个值等内容。
• 正如您所提到的，使用Python可以更容易地处理错误。您可以轻松捕获异常并检查返回值。您可以选择使用raise AirflowSkipException将任务标记为跳过。

顺便说一句，对于BashOperator，如果脚本以错误代码退出，则Airflow会将任务标记为失败。

- Daniel Huang

---

如果您有 50 多个独立的工作流程，每个工作流程都需要独立的版本和库演进，我不认为单一仓库单一环境能够实际运作。 - nachonachoman

Answer 2

任务A检查源数据的可用性。任务B处理它。

任务A>>任务B

两个任务都使用BashOperator调用python脚本。以前，我会从由任务A触发的脚本1返回sys.exit(1)（当没有源数据时）作为一种通信方式，表示任务A失败，因为没有数据，也不需要运行任务B。

- Vpalakkat