我仍在部署Airflow的过程中，我已经感到有必要将合并 operator一起。最常见的用例是 coupling 运算符和相应的sensor。例如，人们可能想将EmrStepOperator和EmrStepSensor链接在一起。
我正在创建自己的DAG programmatically，其中最大的一个包含150多个（相同）分支，每个分支在不同的位置执行相同的一系列操作数据位（表）。因此，将DAG中构成一个逻辑步骤的任务组合在一起会很有帮助。
这里有两个我的项目中有争议的示例，为我的论证提供了动力。
1。从S3路径中删除数据，然后写入新数据
此步骤包括2个运算符
DeleteS3PathOperator：从BaseOperator扩展并使用S3Hook HadoopDistcpOperator：从SSHOperator延伸 2。在MSCK REPAIR表上有条件地执行Hive
此步骤包含4个运算符
BranchPythonOperator：检查Hive表是否已分区 MsckRepairOperator：从HiveOperator扩展并在（Dummy(Branch)Operator：组成备用分支路径到MsckRepairOperator（对于未分区的表）Dummy(Join)Operator：组成两个分支的 join步骤 在 isolate 中使用运算符当然可以提供较小的模块，并提供更多的细粒度日志记录/调试功能，但是在大型DAG中，减少混乱可能是可取的。根据我目前的理解，有两种方法可以将运营商链接在一起
Hook s
在钩子中编写实际的处理逻辑，然后在单个运算符中使用任意数量的钩子（在我看来，这当然是更好的方法）
SubDagOperator
一种risky和controversial的处理方式；此外，还有SubDagOperator makes me frown的命名约定。
我的问题是
答案 0 :(得分：2)
我已经结合各种挂钩来根据自己的需要创建一个Single运算符。一个简单的例子是，我将gcs的delete，copy，list方法和get_size方法合并在一起，以创建一个名为GcsDataValidationOperator的单个运算符。经验法则是具有幂等，即，如果您多次运行，它将产生相同的结果。
应该完全组成运算符，还是最好是离散的 步骤？
唯一的陷阱是可维护性，有时当master分支中的钩子发生变化时，如果有任何重大更改，您将需要手动更新所有操作员。
有什么陷阱，可以改进上述方法吗？
您可以使用PythonOperator并通过.execute方法使用内置的钩子，但是DAG文件中仍然有很多细节。因此，我仍然会寻求一种新的运算符方法
还有其他将运算符组合在一起的方法吗？
挂钩只是到外部平台和数据库（如Hive，GCS等）的接口，并为操作员构成了构建块。这样可以创建新的运算符。另外，这意味着您可以自定义模板字段，在新操作员内部的每个细化步骤上添加松弛通知，并拥有自己的日志记录详细信息。
在气流分类法中，挂钩的主要动机是否与上述相同，或者它们是否还用于其他目的？
FWIW：我是PMC成员，也是Airflow项目的贡献者。