ETL：200个源数据库的抽取策略

Question

每天将大约 200 个 SQL Server 2005 源数据库（相同架构）加载到暂存区以准备数据仓库清理、重复数据删除和转换的最佳提取策略是什么？

到目前为止，我已经设想了以下可能性：

1. 事务复制：创建 200 个 SQL Server 2008 R2 订阅者，在 2005 年从各自的发布者那里提取数据。在订阅者和影子表中的所需表上启用变更数据捕获，以便对我们的临时数据库执行增量加载。
2. Rowversion：在每个所需的源表上添加一个 rowversion 列，并将其与 SSIS 过程结合使用以将更改数据直接提取到临时数据库。
3. BCP 文件：创建一个自动化任务，每晚从所有源表中转储 BCP 文件。使用 SSIS 将这些表作为完整加载（而不是增量加载）的一部分加载到临时数据库中。

额外的想法：

1. 我对在 200 个数据库上支持全新事务复制拓扑所需的管理和硬件开销感到紧张。
2. 数据库的总大小约为 100GB。但其中大部分是事务日志和其他表的一部分，不会在任何事实或维度中使用。换句话说，BCP 文件不会很大，这就是为什么我正在考虑完整的提取策略，即使我读过的所有内容都反对它。
3. 我愿意接受建议、文件等。

Answer 1

如果您有 200 个相同的源，那么您可以使用数据源参数化 SSIS 包并启动多个线程。这些可以通过 foreach 循环或从使用参数启动提取器的外部源在包内进行控制。

您可以考虑对相对较小的维度源进行完全加载，对事务数据进行增量加载。这将要求您拥有持久的维度，但如果您需要缓慢更改维度，这对于 MERGE 操作或预加载区域和维度处理程序来说相当简单。

您可能希望考虑为每个源提供自己的暂存区（可能是暂存数据库中每个源的模式）。这消除了临时表上的锁定问题。在包含数据源信息的临时表上构建一组视图（本质上只是一组对应于每个源表的联合）。这些可以很容易地生成，因此您不必手动将 200 个不同的查询剪切并粘贴到联合中。一旦您暂存了数据，那么 ETL 过程就可以从视图中读取全部内容。

这允许 ETL 一次性运行，尽管您必须想出一种策略来处理从单个系统中提取失败的问题。为此，您可能希望研究一种能够优雅地处理迟到数据的架构，以便您可以赶上存在瞬态问题的单个提要。

BCP

对于 200 个简单的提取，BCP 可能是一个不错的方法。来源都是相同的，因此 BCP 文件在来源之间是相同的。您可以使用 SSIS 构建负载控制器。让多个线程读取公共列表的顶部需要您实现对列表的同步访问。SSIS 进程有一堆在序列容器中并行运行的循环，它们弹出下一个项目，执行它并更新相应的状态。

实现“next”函数使用在可序列化事务中运行的 sproc，它从列表中弹出“next”合格源并将其在事务中标记为“in progress”。这是一个“表作为队列”的问题，但您不必实现同步插入 - 可以在运行开始时将整批推送到表中。

构建单独的提取过程，以便在第一次尝试失败时再次尝试一次或两次。这将减轻由瞬态错误引起的许多故障。如果任务失败两次，则使任务失败，并构建 ETL 以使其对单个提取失败具有弹性。

增量负载

增量加载器可能不值得为维度表烦恼，除非您有一个非常大的维度来显示真正的性能问题。对于事实表数据源，它可能是值得的。如果您可以使用时间戳列或类似列向应用程序表添加行版本，则可以获取新内容。但是，您需要在本地跟踪它以记录最后的时间戳。如果数据上有插入或更新日期，您可以改用它。

满载

什么可能出错？

200 个进程开始执行满载，从而使网络和暂存数据库的负载激增。这可能会导致各种暂时性问题，例如超时。对于小维度表，这可能不是什么大问题。然而，对于 100GB，存在各种各样的问题 - WAN 饱和、锁定（尽管正确的暂存架构会缓解这种情况）、资源的可用性。提取过程运行的时间越长，环境因素对过程可靠性的影响就越大。

这里有很多不可估量的东西，所以YMMV。如果可能，我建议为较大的表增加负载。