1

我创建了一个 ETL，该 ETL 已经增长到填充大约 250 个表（暂存表、维度表和事实表）。

我从 Stacia Meisner 那里得到了 ETL 设计模式，她的 ETL 设计模式基于创建一个模板包，用于加载临时表、加载维度​​表，然后加载事实表。这个想法是使用您在特定包中设置的变量，然后调用适当的存储过程，创建沿袭和审计数据，使用表达式填充正确的表等，以便您只需将模板包复制并粘贴到您的解决方案中，编辑变量，只要您有存储过程来获取数据和正确的表名，一切都会完美运行。

那是......直到我达到250张桌子。当我在 BIDS 中运行 ETL 时，它会疯狂地消耗 RAM。当我部署 ETL 并在 SQL 中执行它时，它没有。在我的笔记本电脑上运行 ETL 可能会消耗大约 3 到 4 GB 的 RAM，因为它会从父包打开我的每个子包。我的解决方案中现在有 250 个包。

我可以增加笔记本电脑的 RAM（目前为 8GB 或 RAM），但我脑海中肯定会响起警告警报，这让我认为也许 250 个数据流任务会是一个更好的选择。

现在了解这种设计模式的缺陷，我想我的问题如下

  1. BIDS 是否曾经打算在 ETL 中执行如此多的包？
  2. 当我在 IDE 中运行 ETL 时，有什么方法可以减少 RAM 的消耗？
  3. RAM 的消耗是可以预期的，如果是这样，开发人员通常如何处理它。我可以通过从不在我的 IDE 中运行整个 ETL 来轻松解决它，而是对其进行部分测试，然后将其整体部署
  4. 我是否应该放弃每表 1 个包的设计模式并在 3 个包中实现数据流任务（1 个用于加载临时表，1 个用于加载维度，1 个用于加载我的事实表）

感谢您抽出宝贵时间，非常感谢您的意见。

问候，

杰西

4

1 回答 1

1

暂时远离 RAM 问题，我会保留设计模式。当您遇到只需要在部署后运行一个表的 ETL 的情况时，它非常有价值。在 2012+ 中，它还为您提供了更多有用的日志记录信息，因为通过使用父包，它都被视为一次运行的一部分，允许您从 SSISDB 中保存的数据构建有用的监控/报告。您首先列出的采用此模式的所有其他原因也是有效的；该模式确实促进了重用和标准化，并减少了开发时间。它还使其他开发人员很容易获得解决方案，找到解决方案，支持它，对其进行更改等。

回到 RAM：在您的 ETL 解决方案如此庞大的环境中，对于 SSIS 开发机器来说，8 gigs 确实不是一个巨大的数字——如果您可以选择升级，我认为这将是一个好主意。尽管使用了一些相当大的 ETL 解决方案，但我没有遇到您描述的问题，但是我之前的两台开发机器有 32GB 和 16GB 的 RAM。SSIS IDE 远非完美，不过我完全相信您所描述的问题。

还必须注意的是，我不经常在 IDE 中运行整个 ETL 解决方案。我更经常在处理独立部件时运行它们，然后一旦我知道该部件正在工作，我就会部署到开发环境（无论是本地安装还是服务器），并通过代理完成我的全部运行. 鉴于通过代理与在 IDE 内部运行的方式存在差异，我发现尽早部署很有用。我也很欣赏通过代理运行给我的日志信息——它可以帮助我跟踪我所做的更改是否影响了性能。使用 2012+ 部署模型，以这种方式工作也不会耗费时间。

最终，我认为放弃具有许多好处的可靠模式而不是稍微改变工作方式以应对 IDE 的缺陷将是错误的。我认为您在第 3 点中可能已经在很大程度上回答了您自己的问题。

最后一点：如果您的笔记本电脑上有本地开发数据库（而不是仅在本地运行 SSIS，并且数据库位于服务器上），请确保您的本地 SQL Server 实例的最大 RAM 设置相当低。如果你不这样做，它将使用你所有的 RAM 来缓存东西，然后 SQL Server 和 SSIS 最终将争夺 RAM。我已经看到这会导致 SSIS IDE 中的内存错误。我认为这不是您在此处描述的内容，但我提一下以防万一这对您或其他找到此问答的人有所帮助。

于 2016-11-29T13:33:45.553 回答