ETL反模式:无错误处理逻辑

ETL反模式:无错误处理逻辑我通常避免绝对谈论技术,但是在这里’我可以毫无保留地分享一个:在足够长的时间内,每个ETL流程最终都会失败。您的ETL设计是否旨在处理故障?

我看到太多的SSIS包,ADF数据工厂和其他数据移动应用程序都以100%成功的假设构建而没有失败的准备。在此ETL反模式文章中,我’将讨论在ETL流程中跳过错误处理逻辑的愚蠢行为。

ETL反模式:无错误处理逻辑

想象一下一个场景,其中您正在为公司构建数据加载过程以跟踪其公司车辆上的遥测。在这种情况下,您导入每辆车’遥测数据到报告数据库中的公用表中,公司’的用户可以报告车辆的最后见过地点,行进的速度以及静止状态的空闲时间。

现在片刻’假设在加载此数据期间,网络故障会在将数据移至报告表的过程中暂时造成连接中断。有些数据已加载,有些则没有’t。负责检查此加载状态的人员发现该加载失败,再次运行,然后成功加载。

因为在之前的加载中,部分(但不是全部)数据已加载,所以它’可能目标表现在具有重复项:失败期间加载的部分数据集,以及后续成功加载后的全部数据集。结果是数据使用者现在将看到该车辆的多个遥测记录。至少,这将是一个麻烦。

现在想象一下数据是’车辆遥测,但银行交易或总分类账条目。如果您的数据由于ETL错误而出错,那么客户,投资者和监管机构将非常宽容。

设计失败的ETL

即使是最强大的提取-转换-加载过程也会在某些时候失败。即使ETL代码中没有缺陷,但仍有一些超出该过程控制范围的因素–网络,身份验证和DNS,仅举几例–可能会破坏负载。在构建ETL加载逻辑时,必须简单地思考成功的有效载荷应该是什么样子,但是如果该加载的任何组件失败,将会发生什么。

在我的 培训班,我指导人们考虑ETL流程中的错误处理是功能的核心部分,而不是事后思考。由于数据移动和转换的本质,错误的处理必须成为首要考虑的问题,而不仅仅是在开发周期结束时加紧处理。

拥有旨在解决故障的ETL有两个明显的好处:

  • 当发生错误时,它为解决问题提供了更清晰的途径
  • 它有助于防止发生故障时使目标端点处于不一致的部分加载状态

错误处理模式

ETL错误处理通常属于以下类别之一:

没有错误处理(只是让过程失败)

这是最常见的模式,因为它是默认行为。请记住,这是某些负载的有效设计模式–例如,如果您要截断并加载登台表,则在那里’通常只会在发生错误时让加载失败,因此危害不大。您可以再次重新运行相同的加载,因为它每次都会截断并重新加载登台表。

撤消负载所做的更改

使用这种设计模式,您可以以这样的方式构建ETL逻辑:如果发生故障,它将撤消所做的任何更改。这通常是通过显式事务(在关系数据库端点的情况下)或脚本执行的,该脚本将删除或还原失败加载期间所做的更改。

错误后继续加载

在某些情况下,即使遇到一个或多个错误,您也可能发现让负载运行到完成还有更大的价值。这通常是在行或源级别配置的,以允许单个行或源失败,同时允许其余的后续行或步骤完成。

对于这些设计模式中的任何一种,您都应确保所有错误或异常 正确记录.

诚然,考虑到失败而构建ETL流程是一种悲观的方法。但是,由于数据专业人员的首要任务是保护数据的完整性,因此应该始终在进行ETL设计时要了解这些过程中的每个过程都会在某个时刻失败。

关于作者

Tim Mitchell
Tim Mitchell is a 数据架构师和顾问 专门研究摆脱数据痛点的人。 在数据仓库,ETL,报告或以下方面需要帮助 训练?如果是这样, 联系蒂姆 进行30分钟的无义务聊天。

发表评论

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.