反转（或撤消）仓库事实表的大量负载
目前，我们计划为加载的每批事实记录一个“批次 ID”。 这样，我们就可以在发现问题时取消负载。
我们是否应该考虑跟踪维度行上的批次 ID？
看起来维度行有不同的规则。 如果我们将它们视为缓慢变化，并使用一种保留历史记录的 SCD 算法，那么重新加载并没有多大意义。
典型场景。 符合尺寸，处理SCD。 加载事实。 完毕。
扩大。 符合尺寸，处理SCD。 加载事实。 发现问题。 删除该批事实。 解决问题。 重新加载事实。 完毕。
可能的情况。 符合尺寸，处理SCD。 加载事实。 发现问题。 删除该批事实和维度行。 解决问题。 符合尺寸，处理SCD。 加载事实。 完毕。
跟踪尺寸变化似乎没有多大帮助。 有关如何最好地处理数据仓库负载的“撤消”或“回滚”的任何指导？
我们的 ETL 工具完全是自制的 Python 应用程序。
Currently, we plan to record a "batch id" for each batch of facts we load. That way, we can back out the load in case we find problems.
Should we consider tracking the batch id on the dimension rows, also?
It seems like dimension rows have different rules. If we treat them as slowly-changing, and use one of the SCD algorithms that preserves history, then a reload doesn't really mean much.
Typical Scenario. Conform dimension, handling SCD. Load facts. Done.
Extension. Conform dimension, handling SCD. Load facts. Find a problem. Delete the batch of facts. Fix the problem. Reload facts. Done.
Possible Scenario. Conform dimension, handling SCD. Load facts. Find a problem. Delete the batch of facts and the dimension rows. Fix the problem. Conform dimension, handling SCD. Load facts. Done.
It doesn't seem like tracking dimension changes helps very much at all. Any guidance on how best to handle an "undo" or "rollback" of a data warehouse load?
Our ETL tools are entirely home-grown Python applications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从我的角度来看，只要您不滥用维度（例如跟踪时间到毫秒），通过跟踪回滚维度就不会获得太多收益。 您还可以构建一个工具来每月清理一次未引用的维度。
From my perspective as long as you are not abusing your dimensions (like tracking time to the millisecond) there is not a lot of gain to be had by tracking dimensions for a rollback. Also you can build a tool to cleanup unreferenced dimensions once a month.