我们正在尝试为包含大约 400M 行的 Data Warehouse Fact 表实现表分区。我们的 ETL 从上一次加载开始向后 50 天从源系统获取数据（新行、修改行、基于源系统时间戳）。因此，在每个 ETL 周期中，都会有新行进入，还有旧行正在更新 Fact 表中的相应行。这个想法是将新行插入 Fact 表并更新修改的行。
分区列将是日期（int，YYYYMMDD），我们正在考虑按月分区。
就我而言，表分区将通过快速分区切换操作简化我们的插入操作。我们可以拆分最近的分区以创建一个新的空闲分区，将新行加载到临时表中（使用日期约束，例如最近一个月），然后使用分区切换操作将新行“移动”到分区的事实表中. 但是我们如何处理修改后的行，这些行应该更新 Fact 表中的相应行？这些行可以包含上个月的数据。分区开关在这里有帮助吗？通常INSERT，UPDATE行由 ETL 工具（例如我们的案例中的 SSIS）或MERGE语句确定。在这种情况下，分区是如何工作的？
我会再看一下设计，并尝试弄清楚是否有办法绕过更新。以下是更新事实表的一些含义：
性能：更新是完全记录的事务。大事实表也有大量数据要读取和写入。
多维数据集：更新事实表需要重新处理受影响的分区。随着您的事实表继续增长，多维数据集处理时间也将继续增长。
预算：快速存储很昂贵。更新大型事实表将需要大量快速读写。
纯粹主义理论：您不应该更改事实表，除非初始值是错误的（即用户输入了 15,000 美元而不是 1,500 美元）。任何非错误情况都将更改最初记录的事务。
有什么变化？变化的部分真的是维度的属性吗？如果是这样，它们是否可以移动到一个维度并使用渐变维度类型任务处理更改？
另一种可能性，这可以通过抵消交易来实现吗？例子：
初始发票金额为 10.00 美元。会计后来增加了 1.25 美元的税款，然后向客户收取了 11.25 美元的费用。不要将值更新为 $11.25，而是插入 $1.25 的记录。发票的总金额仍为 11.25 美元，您可以执行最少记录的插入而不是完全记录的更新来完成。
更新事实表不仅在理论上是一个坏主意，而且随着事实表的增长，它变得非常昂贵且不可扩展。您将读取和写入更多数据，需要来自存储子系统的更多 IOPS。当您准备好进行分析时，多维数据集处理将引发更多问题。
您还必须不断向管理层证明为什么您需要为数据仓库提供如此多的 IOPS。对于不断变化的“事实”表，需要所有这些 IOPS 是否有商业价值/理由？
如果您找不到绕过事实表更新的方法，至少要建立一个截止点，将数据确定为只读。否则，您将永远无法扩展。
切换在这里没有帮助。
也许您可以在不同范围的行上使用多个线程同时执行更新。那可能会加快速度。注意不要触发锁升级，以便获得良好的并发性。
还要确保主要以聚集索引的升序更新行。这有助于磁盘 IO（这种技术可能不适用于多线程）。
更新事实记录的原因与事实中的非识别属性一样多。除非您计划“先删除”然后“插入”，否则您根本无法避免更新。您不能简单地说“将度量增量记录为新事实”。