撤消/回滚数据处理管道的效果

Question

我有一个工作流程，我将描述如下：

[  Dump(query)  ] ---+
                     |
                     +---> [ Parquet(dump, schema) ] ---> [ Hive(parquet) ]
                     |
[ Schema(query) ] ---+

哪里：

• query是对RDBMS的查询
• Dump将结果query转储到CSV文件dump
• Schema运行query并xcoms其架构schema
• Parquet读取csv并使用schema创建Parquet文件parquet
• Hive基于Parquet文件parquet创建一个Hive表

这种错综复杂的工作流程背后的原因是由于无法解决的限制并且超出了问题的范围（但是，理想情况下，它会比这简单得多）。

我的问题是在发生故障时回滚管道的影响 。

这些是我希望在不同条件下发生的回滚：

• 无论管道的最终结果如何，都应始终删除dump
• 如果由于某种原因，Hive表创建失败，则应删除parquet

在工作流程中代表这一点，我可能会这样说：

[  Dump(query)  ] ---+
                     |
                     +---> [ Parquet(dump, schema) ] ---> [ Hive(parquet) ]
                     |                |                          |
[ Schema(query) ] ---+                |                          |
                                      v                          v
                            [ DeleteParquetOutput ] --> [ DeleteDumpOutput ]

从Parquet到DeleteParquetOutput的转换仅在发生错误并且进入DeleteDumpOutput的转换发生时忽略其依赖项中的任何失败。

这应该解决它，但我相信更复杂的管道可能会因此错误处理逻辑而增加复杂性 。

在继续讨论更多细节之前，我的问题是： 在处理Airflow管道中的错误时，这可能被认为是一种很好的做法吗？ 什么可能是一种不同的（可能更可持续的）方法？

如果您对我希望如何解决此问题感兴趣，请继续阅读，否则随时回答和/或评论。

---

我对管道中的错误处理有所了解

理想情况下，我想做的是：

• 为每个相关的阶段定义回滚过程
• 对于每个回滚过程，定义是否应该仅在发生故障或在任何情况下发生
• 当管道完成时，反转依赖关系，并从上一个成功的任务开始，遍历反向的DAG并运行相关的回滚过程（如果适用）
• 应记录回滚过程中的错误，但不要将其考虑在内以完成整个管道的回滚
• 对于前一个要点，每个任务应定义一个效果，可以在不引用其他任务的情况下描述其回滚过程

让我们用给定的管道做几个例子。

场景1：成功

我们反转DAG并用其强制回滚过程（如果有的话）填充每个任务，得到这个

                                         +---> [ Dump: UNDO ]
                                         |
[ Hive: None ] ---> [ Parquet: None ] ---+
^                                        |
|                                        +---> [ Schema: None ]
+--- Start here

场景2： Hive发生故障

                                                 +---> [ Dump: UNDO ]
                                                 |
[ Hive: None ] ---> [ Parquet: UNDO (error) ] ---+
                    ^                            |
                    |                            +---> [ Schema: None ]
                    +--- Start here

有没有办法在Airflow中表示这样的东西？ 如果他们能够采用这种方法，我也愿意评估不同的工作流程自动化解决方案。

Answer 1

所有运算符和传感器派生自的BaseOperator类都支持回调： on_success_callback ， on_retry_callback和on_failure_callback - 也许这些将有所帮助。

Answer 2

似乎是一种处理错误的复杂方法。 我认为最好将错误视为简单地停止DAG的当前运行，以便您可以解决任何问题并从停止的位置重新启动它。 当然，您可以清理由特定任务创建的部分创建的文件，但由于某些下游问题，我不会收回整个管道。

以我的工作为例，不可否认，它使用的是不同的技术，但我认为是同样的工作流程：

1. 从源数据库中提取特定时间间隔的增量，并将其压缩到Airlfow工作服务器上
2. 将此压缩文件移动到S3位置
3. 将S3文件复制到Snowflake数据仓库中。

使用我们当前的设置 - 如果有人意外更改Snowflake表的结构，我们将S3文件加载到唯一将失败的任务是最后一个（步骤3），因为表结构不再与CSV结构匹配。 要解决这个问题，我们只需要将表的结构恢复到原来的状态，然后重新运行失败的任务。 然后Airflow将文件从S3重新复制到Snowflake并成功。

你提出的设置将会发生什么？ 如果最后一个任务失败，它将回滚整个管道并从s3存储桶中删除CSV文件; 我们必须再次从源数据库下载该文件。 如果我们简单地重新运行从s3复制到Snowflake的任务会更好，从而省去了必须运行整个DAG的麻烦。