大型SSIS ETL项目中的版本控制

Question

我们即将使用SSIS将数据从一个系统转换到另一个系统。我们是四个人，他们将继续为此工作两年，因此我们需要某种版本控制系统。我们不能使用团队基础。我们目前正在配置一个SVN服务器，但是我已经看到了一些很大的风险。

似乎解决方案存储在一个巨大的XML文件中。这在SSIS组合的代码/拖放环境中一定是个大问题，因为SVN无法正确合并更改，每当我们在提交时遇到错误，我们都必须查看那个巨大的XML文件，手动纠正​​错误。

解决此问题的一种方法是在SSIS中创建许多解决方案项目。然而，这并不是我们想要的设置，因为我们正在创建一个大型怪物，它将有2天的执行时间，我们希望在执行时跟踪其进度。如果我们必须创建多个解决方案，是否有方法可以链接它们的执行，并且仍然可以直观地了解正在进行的操作以及执行的执行情况？

是否有人遇到类似问题和/或您对如何解决这些问题有任何建议？

Answer 1

你在说什么包？如果它是数百个包，那么您要避免的具体问题是什么？根据您的帖子，您可能会尝试避免以下几点：

1. BIDS启动时的解决方案和项目加载时间较慢。我想这可能会不时发出刺激。但如果你让BIDS全天开放，这似乎每天都要花费一次。

2. 从版本控制系统获取最新的解决方案定义时，解决方案和项目加载时间会很慢。同样，我认为这可能会不时发生激怒，但您需要多久刷新整个解决方案？如果将解决方案分解为单独的项目，则只需刷新项目。如果您想要访问解决方案中的新项目，则只需刷新整个解决方案。

“一个巨大的XML文件”是什么意思？解决方案文件是一个跟踪项目的XML文件。每个项目文件都是一个XML文件，用于跟踪其SSIS包。因此，如果您在1个解决方案中的10个项目中均匀分布了1,000个SSIS包，则每个文件的跟踪对象不超过100个。我可以从经验告诉你，我的Reporting Services项目包含的RDL文件比这个更多，只需几秒钟就可以在BIDS中正确加载解决方案。正如@revelator指出的那样，实际的SSIS包是他们自己的XML文件。任何版本控制系统都应将这些文件作为单独的文件进行跟踪，并且不会将它们组合成“一个巨大的XML文件”。如果你澄清了这一点你的意思，那么我认为你会在这个问题上得到更好的帮助。

无论您是运行一个软件包还是1,000个软件包，您都不会从BIDS以交互方式执行此操作。您可能首先将软件包部署到服务器，然后让服务器运行软件包。如果是这种情况，那么您将需要使用SQL Server代理作业调用这些包。无论是通过使每个包调用另一个包来链接包，还是通过让作业将每个包作为单独的作业步骤来链接包，您仍然可以通过记录来跟踪链中的位置。如果您使用作业调用包，则可以使用作业步骤跟踪它。我运行一个包含大量软件包的数据仓库，我主要依赖于将流程分成每个包含一个或多个包的作业。我还使用启动作业命令链接作业，以便我可以更轻松地监视逻辑加载组的性能。此外，每个包在步骤级别的作业历史记录中显示其执行时间。此外，我在每个存储过程和包中都有自定义日志记录，显示单个数据加载或存储过程所花费的秒数和行数，以便我可以解决性能瓶颈问题。

无论您做什么，都不要依赖于以交互方式运行包作为跟踪性能的方法！您无法在计算机上运行ETL的最佳性能，更不用说使用GUI运行它。在服务器而不是桌面上的作业中运行包。交互式运行软件包只是帮助构建和排除各个软件包的故障，而不是管理每日ETL。

如果要构建基于参数更改其目标和源的通用包，则可能需要在跟踪进度的数据库中构建控制表。如果您只是将数据从一个大型系统移动到另一个大型系统作为一次性事件，那么您可能会将负载划分为少量软件包并为每个软件包分别创建单独的作业，以便您可以更轻松地管理从故障中恢复。如果你打算构建一些定期运行以移动数据的东西，那么一个进程的2天持续运行怎么可能有意义呢？听起来基础数据会在2天内发生变化......

如果您担心使用哪个版本控制系统来管理SSIS包项目，那么我可以说几乎任何一个都可以。我在不同的公司使用过Visual SourceSafe和Perforce，它们都具有相同的基本功能，即检查和检查单个包。我确信任何与Visual Studios集成的版本控制系统都会为您完成此任务。

希望您在上面找到有用的东西并祝您好运。

Answer 2

版本控制可以让多个人一起开发并处理同一个项目。如果我正在处理某些事情，那么ETL开发人员将无法检查它并对其进行更改，直到我完成更改并检查这些更改。这解决了一个开发人员的项目工件和代码更改的常见情况另一个开发者意外地破坏了它。

http://blog.sqlauthority.com/2011/08/10/sql-server-who-needs-etl-version-control/

Answer 3

我工作的大多数ETL项目都使用SVN作为源代码控制存储库。我发现的最好的方法是将每个项目或解决方案分解为更小，不同（通常可独立运行）的包。例如，假设您有一个名为ManufacturingImport的流程，这可能是您的项目。在这之内你将拥有一个Master包，然后根据需要调用其他包。这意味着团队成员可以处理不同的包或工作，而不是每个人都试图编辑相同的包并进入合并的麻烦情况。