ETL反模式:未能将ETL逻辑视为源代码

在大多数数据项目中,构建提取-转换-加载(ETL)逻辑会花费大量时间。企业ETL流程必须做得很好:检索足够的数据以满足业务需求,对数据进行任何所需的转换,然后将其加载到目标,而不会中断任何其他业务流程。构建和验证ETL逻辑的工作量很大,这使得生成的代码对企业而言是非常宝贵的资产。

但是,在旅行中,我’我发现那里’许多ETL代码’无法得到应有的照顾。未能将ETL逻辑视为源代码可能是一个代价高昂且耗时的错误。

ETL反模式:无法将ETL逻辑视为源代码

这里’关键在于:ETL代码是源代码。应该对源代码进行版本控制,备份并附加到正式的变更过程中。因此,应始终通过正式的变更过程对ETL代码进行版本控制,备份和约束。

这里的通用模式是ETL代码被视为一种一次性实用程序,可以随时更改,并且在必要时可以轻松地进行重建。我的公司收到了许多来自潜在客户的电话,在这些电话中,对ETL的细微更改和无害更改造成了下游系统的大麻烦。在少数情况下,由于系统升级或代码的无意删除,ETL逻辑的某些部分丢失了。

ETL代码通常比其所驻留的硬件对企业更有价值,因此应将其视为企业资产。 ETL代码是源代码,应这样处理,包括:

  • 使用适当的源代码控制系统来存储和版本控制代码
  • 维护单独的开发和/或测试环境(非生产环境!)以测试更改
  • ETL代码变更控制的正式程序,包括此类变更的预先通知
  • 在将源代码移至生产环境之前,对所有更改进行回归测试和数据验证

是的,这些步骤需要时间和金钱。如果您的企业习惯于将ETL开发作为临时操作来处理,那么将ETL逻辑视为源代码肯定会减慢您的开发过程。但是,这些是保护公司的必要步骤’对数据及其支持数据的过程的投资。

 

 

 

关于作者

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

成为第一个发表评论的人 关于“ ETL反模式:未能将ETL逻辑视为源代码”

发表评论

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