Sql server 如何设计数据仓库来处理延迟到达的数据源？

您好，我正在为一位客户开发MS SQL Server 2017标准版数据仓库，遇到了一个挑战，我正在寻求建议

我有一个相当大的事实表，记录零售交易（大约每天250万行，有3年的历史）。事实表的大部分都来自一个单一的来源——till系统。因此，我们目前有一个ETL过程，从这个系统加载数据，对其进行建模以查找代理键等，并每小时加载到一个事实表中。该表具有聚集的列存储索引，以确保BI工具的良好性能

现在，客户有了他们想要集成的忠诚度应用程序系统。该系统每天向我们发送CSV提取数据。摘录包含应用交易的详细信息和通过应用获取的相关优惠，并包含一个与事实表中已有的交易ID相匹配的通用交易ID

如果这些数据源一起到达，我将对一个新的维度表（DimAppOffer或类似的维度表）进行建模，并使用这两个数据源查找与每个事务相关联的报价，并在事实表上显示AppOfferKey。但由于该CSV文件每天只到达一次，并且每小时加载一次事务，因此在我从忠诚度应用程序获取数据时，所有关联事务都已存在于事实表中

你认为我应该如何在ETL中处理这个问题？如果可以避免的话，我并不特别想对聚集的columnstore索引运行大型更新，但我看不到其他解决方法？如有任何建议，将不胜感激

如果可以避免的话，我并不特别想对聚集的columnstore索引运行大型更新，但我看不到其他解决方法

您可以在维度键中加载带有null或“缺少成员”的事实，或者在ETL期间添加带有null/unknown非键属性的新维度成员，并将该事实链接到该事实，如下所示：

如果在事实到达时创建新维度成员，则只需在数据到达时更新维度

如果可以避免的话，我并不特别想对聚集的columnstore索引运行大型更新，但我看不到其他解决方法

您可以在维度键中加载带有null或“缺少成员”的事实，或者在ETL期间添加带有null/unknown非键属性的新维度成员，并将该事实链接到该事实，如下所示：

---

如果您在事实到达时为新维度成员创建一个表，那么您只需在数据到达时更新维度。

在这种情况下，我更愿意创建第二个带有事务id和应用程序提供详细信息的无事实事实表（与您的AppOffer维度类似，但仅使用事务id作为键）

---

然后，您可以使用LEFT join for analytics为您的主要事实和这个新表创建一个视图。

在这种情况下，我更喜欢使用事务id和应用程序提供的详细信息创建第二个无事实的事实表（类似于您的AppOffer维度，但只使用事务id作为键）

---

然后，您可以使用LEFT join for analytics为您的主要事实和这个新表创建一个视图。

但这有任何性能问题吗？它本质上意味着创建一个雪花模式而不是星型模式，不是吗？星型模式并不意味着良好的性能，因为您需要加入这些维度表。您也可以跳过视图，只使用事实表，那么您是说，事实表到无事实事实表要作为数据模型进行维？只要查询性能没有太大的降低，这就可以工作。但是这有任何性能问题吗？它本质上意味着创建一个雪花模式而不是星型模式，不是吗？星型模式并不意味着良好的性能，因为您需要加入这些维度表。您也可以跳过视图，只使用事实表，那么您是说，事实表到无事实事实表要作为数据模型进行维？只要查询性能不会降低太多，这就可以工作。问题是，在数据到达之前，我没有维度业务密钥。维度将不基于事务编号，而是基于与CSV文件中的事务编号关联的OfferID。所以在这个例子中我不能使用延迟到达的维度建议，问题是在数据到达之前我没有维度业务密钥。维度将不基于事务编号，而是基于与CSV文件中的事务编号关联的OfferID。所以我不能在这个例子中使用迟到维度建议。