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 回答