初始化 Key FACT\DIM 表时如何保持参照完整性答案

【问题标题】：How to preserve Referential Integrity when initializing Key FACT\DIM tables初始化 Key FACT\DIM 表时如何保持参照完整性
【发布时间】：2019-03-17 22:06:55
【问题描述】：

在我工作的地方，我们会在需要的极少数情况下初始化（“INIT”=> 截断和加载）一个 Fact\Dimension 表。

这种“INIT”要求所有引用已初始化对象的对象随后都被初始化，以保持 RI（参照完整性）。

示例 – 我们在属性丰富的 (~25) SCD Dim_Employees 中发现了一个错误，该错误将更改每条记录的生效日期。这要求所有引用对象重新计算它们的外键。

你有同样的情况吗？如果有，你是怎么处理的？

【问题讨论】：

标签： data-warehouse snowflake-cloud-data-platform sql-data-warehouse

【解决方案1】：

当我们从 SCD2/SCD1 更改为 SCD6 或发现其中一个数据流有问题时，我们已经多次重新调整数据维度，就像您提到的那样。

重新映射数据并不难，您只需要在 INIT 步骤中截断数据之前进行克隆，（或在时间旅行窗口内克隆）然后将事实表加入到旧维度旧维度键，然后通过旧维度外键和时间加入新维度，现在您知道新键映射的旧键。现在它成为您更新的来源，如果您在所有其他 ETL 操作暂停的情况下执行此操作，您就可以保持数据完整性。

如果您无法暂停实时 ETL 流程，您将进行多步骤更新，您将拥有新的分区表和旧的分区表，并对两者进行正常映射，并修复读取以合并结果，然后执行一次您的新事实正确映射到新维度，转身并用 ND 键回填所有旧事实，然后您没有 ND 间隙，然后您可以停止 OD/ND 合并，然后停止 OD 映射并丢弃OD 列...

【讨论】：

谢谢西蒙！我正在查看您提出的解决方案，似乎在像 DIM_CUSTOMER 这样的关键维度上执行 INIT 需要手动处理至少几十个 FACT 表。这是一个巨大的风险和耗时。您是否在现有 ETL 映射中内置了某种逻辑来解决这种情况？
重映射很昂贵，我们走第一条路，我们的 ETL 编排工具（内部）为这些任务（或者我们认为需要更大）建立一个超大的仓库，并更新任务块正常数据入口。因此，我们为某些数据引入了一些滞后/延迟，但流程更简单，并且我们的开发团队发布窗口是我们经理客户地理区域的停机时间。