0

对于我们公司使用的一些 SaaS 工具，第 3 方管理这些工具并为我们提供每日提要，我们将这些提要加载到我们的数据仓库中。

有时，其中一个提要中的记录会出现错误，需要尽快修复以进行下游报告。但是，第 3 方更正源 SaaS 系统中记录的 SLA 最多可能需要两周时间。“错误”不会破坏任何内容，只是记录在应该保持打开状态时关闭，或者字段的值错误。

过程如下：

  1. 我们数据仓库团队下游的 BI 团队 A 注意到了这种差异。
  2. BI 团队 A 更正其数据库中的记录，其他团队从中使用
  3. 从数据仓库和 BI 团队 A 接收数据的 BI 团队 B 发出警报，因为他们发现我们的输出与他们从团队 A 收到的输出之间存在差异。
  4. 我们（数据仓库团队）必须更正源数据
  5. 上游第 3 方最终更正记录

有没有人有这种情况的最佳实践？有什么方法可以：

A. 使 BI 团队 A 能够在不影响数据仓库团队的情况下尽快更正记录，并且 B. 一旦上游 3rd 方更正了源数据，是否可以回滚？

我的一个想法是使用源代码控制的 csv 文件（如dbt seed表格），如果记录通常不包含 PII，因此无法进行版本控制。

4

1 回答 1

1

我将如何解决这个问题：

  1. 确保您对 DW 进行了控制以捕获任何错误。让您的数据消费者（BI 团队 A）告诉您您的数据是错误的，这不是一个好地方！
  2. 让 1 个团队负责在一个地方修复数据 - 这可确保您拥有控制、一致性和审计。由于数据从 DW 开始，然后向下游移动到其他系统，因此 DW 是修复它的地方。
  3. 建立一个修复数据的标准流程，该流程涉及尽可能少的人工干预，并且已经提前开发和测试。当您遇到错误，并且在客户的压力下修复它时，您最不想做的就是尝试找出如何解决错误，然后开发/运行未经测试的代码
  4. 在高层次上，您的标准流程应该是生产流程的副本，例如临时表的副本（您可以在其中插入不正确记录的更正版本）和加载流程的副本，但指向这个复制的临时桌子 。根据您的生产逻辑，您可能需要修改副本以删除/插入或更新 DW 中的不正确记录。根据您的工具集，您可以使用单独的配置文件而不是复制表/逻辑来实现此目的。
  5. 审计。您应该始终能够追踪记录已被修改、哪些记录受到影响以及发生了哪些变化的事实

显然，您需要确保您对 DW 所做的更改会级联到任何消费系统——无论是在常规更新过程中（如果您的消费者可以等到那时），还是作为一次性过程。同样，您需要确保当最终从第三方收到修改后的记录时，它会正确更新您的 DW，并且您已经审核了错误已得到纠正的事实——大概您希望能够报告第 3 方在其 SLA 中未修复的任何错误？

于 2020-11-04T12:25:50.543 回答