问题描述
对于公司使用的一些SaaS工具，由第三方管理该工具并向我们提供每日供稿，然后将其加载到数据仓库中。
有时，其中一个提要中的一条记录会有一个错误，需要尽快修复该错误才能进行下游报告。但是，第三者纠正源SaaS系统中记录的SLA可能需要长达两周的时间。 “错误”不会破坏任何东西，仅仅是当一条记录应该保持打开状态时关闭，或者某个字段的值错误。
过程如下：
- 数据仓库团队下游的BI团队A注意到差异。
- BI小组A更正其数据库中的记录，其他团队从中使用
- 从数据仓库接收数据的BI团队B和BI团队A发出警报，因为他们看到我们的输出与他们从A团队收到的输出之间存在差异。
- 我们（数据仓库团队）必须更正源数据
- 上游第三方最终更正记录
有人针对这种情况有最佳实践吗？什么方法可以做到：
A。使BI团队A在不影响数据仓库团队的情况下尽快纠正记录，并且 B.上游第三方更正源数据后是否可以回滚？
我曾经的一个想法是使用源代码控制的csv文件（例如dbt seed表），因为记录通常不包含PII，因此不能进行版本控制。
解决方法
我将如何处理：
- 确保在DW上具有控件以捕获任何错误。让您的数据使用者（BI团队A）告诉您您的数据是错误的，不是一个好地方！
- 拥有1个负责在1个地方修复数据的团队-这确保您具有控制，一致性和审核性。当数据从DW开始，然后向下游移动到其他系统时，DW是修复它的地方。
- 建立用于修复数据的标准流程，该流程涉及尽可能少的人工干预，并且已预先开发和测试。当您遇到错误，并且在客户的压力下进行修复时，您想要做的最后一件事就是尝试找出解决错误的方法，然后开发/运行未经测试的代码
- 从高层次上讲，您的标准流程应该是生产流程的副本，例如登台表的副本（您可以在其中插入不正确记录的更正版本）和加载过程的副本，但指向该复制的登台表。根据生产逻辑，您可能需要修改副本以删除/插入或更新DW中的错误记录。根据工具集的不同，您也许可以使用单独的配置文件来实现此目的，而不必复制表/逻辑。
- 审核。您应该始终能够跟踪记录已被修改，哪些记录已受到影响以及进行了哪些更改的事实
很显然，您需要确保对DW所做的更改可级联到任何使用中的系统-在常规更新过程中（如果使用者可以等到那时）或作为一次性过程。同样，您需要确保在最终从第三方收到修订记录后，它可以正确更新您的DW，并且您已经审核了错误已得到纠正的事实-大概您希望能够进行报告第三方未在他们的SLA中修复任何错误？