我們正在嘗試爲包含大約400M行的數據倉庫事實表執行表分區。我們的ETL從前一次加載中將源系統中的數據向後50天（基於源系統時間戳的新行，修改後的行）取回。因此，在每個ETL週期中都有新行進入，還有舊行正在更新Fact表中的相應行。這個想法是將新行插入Fact表並更新修改過的行。事實表分區：如何處理ETL中的更新？
分區列將是date（int，YYYYMMDD），我們正在考慮按月分區。
就我而言，表分區將通過fast partition switch operations緩解我們的插入。我們可以拆分最近的分區來創建一個新的空閒分區，將新的行加載到臨時表（使用日期約束，例如最近一個月），然後使用分區切換操作將新行「移動」到分區事實表中。但是，我們如何處理修改後的行，它應該更新Fact表中的相應行？這些行可以包含上個月的數據。分區切換在這裏有幫助嗎？通常，INSERT和UPDATE行由ETL工具（例如本例中的SSIS）或MERGE聲明確定。在這種情況下分區是如何工作的？
我想再看看這個設計，並試圖弄清楚是否有解決方案。以下是更新事實表的一些含義：
性能：更新是完全記錄的事務。大事實表也有大量的數據可讀和寫。
多維數據集：更新事實表需要重新處理受影響的分區。隨着事實數據表的不斷增長，多維數據集處理時間也將繼續保持。
預算：快速存儲是昂貴的。更新大事實表將需要大量的快速讀取和寫入。
純理論：除非初始值爲錯誤（即用戶輸入$ 15,000而不是$ 1,500），否則不應更改事實表。任何非錯誤情況都會改變最初記錄的交易。
什麼在改變？變化的部分真的是一個維度的屬性嗎？如果是這樣，可以將它們移動到一個維度並使用漸變維度類型任務處理更改？
另一種可能性，這可以通過抵消交易來完成嗎？示例：
初始InvoiceAmount爲$ 10.00。會計後來增加了1.25美元的稅收，然後以11.25美元的價格收取了客戶的費用。將價值更新至$ 11.25，而不是將價格記錄爲1.25美元。發票金額仍然是11.25美元，你可以做一個最低限度的日誌插入，而不是一個完全記錄的更新來完成。
不僅在理論上更新事實表是一個壞主意，它隨着事實表的增長而變得非常昂貴並且不可擴展。您將讀取和寫入更多數據，需要存儲子系統中的更多IOPS。當您準備好分析時，多維數據集處理將會帶來更多問題。
您還必須不斷向管理層證明您爲什麼需要如此多的IOPS用於數據倉庫。對於不斷變化的「事實」表，需要所有這些IOPS是否有商業價值/理由？
如果在事實表上找不到更新的方法，至少要建立一個數據以只讀方式確定的分界點。否則，你將永遠無法擴展。
切換在這裏沒有幫助。
也許你可以在不同範圍的行上使用多個線程同時執行更新。這可能會加快速度。小心不要觸發鎖定升級，以便獲得良好的併發性。
此外，請確保您更新的行大多按聚集索引的升序排序。這對磁盤IO有幫助（這種技術可能不適用於多線程）。