ETL：200個源數據庫的抽取策略
每天將大約 200 個 SQL Server 2005 源數據庫（相同架構）載入到暫存區以準備數據倉庫清理、重複數據刪除和轉換的最佳提取策略是什麼？
到目前為止，我已經設想了以下可能性：
- 事務複製：創建 200 個 SQL Server 2008 R2 訂閱者，在 2005 年從各自的發布者提取數據。在訂閱者和影子表中的所需表上啟用更改數據擷取，以便對我們的暫存數據庫執行增量載入。
- Rowversion：在每個所需的源表上添加一個 rowversion 列，並將其與 SSIS 程序結合使用，以將更改數據直接提取到暫存數據庫。
- BCP 文件：創建一個自動化任務，每晚從所有源表中轉儲 BCP 文件。使用 SSIS 將這些表作為完全載入（而不是增量）的一部分載入到臨時數據庫中。
額外的想法：
- 我對在 200 個數據庫上支持全新事務複製拓撲所需的管理和硬體成本感到緊張。
- 數據庫的總組合大小約為 100GB。但其中大部分是事務日誌和其他表的一部分，不會在任何事實或維度中使用。換句話說，BCP 文件不會很大，這就是為什麼我正在考慮一個完整的提取策略，即使我讀過的所有內容都反對它。
- 我願意接受建議、文件等。
如果您有 200 個相同的源，那麼您可以使用數據源參數化 SSIS 包並啟動多個執行緒。這些可以通過 foreach 循環或從使用參數啟動提取器的外部源在包內進行控制。
您可以考慮對相對較小的維度源進行完全載入，對事務數據進行增量載入。這將要求您具有持久的維度，但這對於 MERGE 操作或預載入區域和維度處理程序來說非常簡單，如果您需要緩慢變化的維度。
您可能希望考慮為每個源提供自己的暫存區域（可能是暫存數據庫中每個源的模式）。這消除了臨時表上的鎖定問題。在包含數據源資訊的暫存表（基本上只是對應於每個源表的聯合集）上建構一組視圖。這些可以很容易地生成，因此您不必手動將 200 個不同的查詢剪切並粘貼到聯合中。暫存數據後，ETL 過程可以從視圖中讀取全部內容。
這允許 ETL 一次性執行，儘管您必須想出一個策略來處理來自單個系統的提取故障。為此，您可能希望研究一種能夠優雅地處理遲到數據的架構，以便您可以趕上存在臨時問題的單個提要。
BCP
對於 200 個簡單的提取，BCP 可能是一個不錯的選擇。源都是相同的，因此 BCP 文件在不同源中是相同的。您可以使用 SSIS 建構負載控制器。讓多個執行緒讀取公共列表的頂部將需要您實現對列表的同步訪問。SSIS 程序有一堆在序列容器中並行執行的循環，這些循環彈出下一個項目，執行它並更新相應的狀態。
實現“下一個”函式使用在可序列化事務中執行的儲存過程，該儲存過程將“下一個”合格源從列表中彈出，並將其標記為事務中的“進行中”。這是一個“作為隊列的表”問題，但您不必實現同步插入 - 可以在執行開始時將整個批次推入表中。
建構單個提取過程，以便在第一次嘗試失敗時再嘗試一次或兩次。這將減輕許多由瞬態錯誤引起的故障。如果任務失敗兩次，則使任務失敗，並建構 ETL，使其能夠適應單獨的提取失敗。
增量負載
除非您有一個非常大的維度來顯示真正的性能問題，否則增量載入器可能不值得為維度表煩惱。對於事實表數據源，這可能是值得的。如果您可以使用時間戳列等向應用程序表添加行版本，則可以獲取新的內容。但是，您需要在本地跟踪它以記錄最後一個時間戳。如果數據上有插入或更新日期，您可以使用它來代替。
滿載
什麼可能出錯？
啟動 200 個程序以執行完整負載會在網路和可能的暫存數據庫上造成負載峰值。這可能會導致各種瞬態問題，例如超時。對於小維度表，這可能不是什麼大問題。然而，對於 100GB 來說，存在各種各樣的問題 - WAN 飽和、鎖定（儘管正確的分段架構會減輕這種情況）、資源的可用性。提取過程執行的時間越長，環境因素對過程可靠性的影響就越大。
這裡有很多不可估量的東西，所以 YMMV。如果可能，我建議對較大的表進行增量載入。