sql-server - 如何处理 ETL 任务？

Question

我应该执行 ETL，其中源是一个大型且设计糟糕的 sql 2k 数据库和一个设计更好的 sql 2k5 数据库。我认为SSIS是要走的路。谁能建议一个待办事项清单或清单或需要注意的事情，这样我就不会忘记任何事情？我应该如何处理这个问题，这样它就不会在后面咬我。

score 29 · Accepted Answer

一些通用的 ETL 技巧

考虑按目的地组织它（例如，生成客户维度的所有代码都位于同一个模块中，无论来源如何）。这有时被称为面向主题的 ETL。它使查找内容变得更加容易，并将增加代码的可维护性。
如果 SQL2000 数据库一团糟，您可能会发现 SSIS 数据流是一种笨拙的处理数据的方式。通常，ETL 工具的扩展性很差，而且很复杂。金融公司中的所有数据仓库项目中，有一半是使用存储过程代码作为明确的架构决策来完成的——正是出于这个原因。如果必须将大量代码放入 sprocs 中，请考虑将所有代码放入 sprocs 中。

对于涉及大量复杂清理或转换的系统，100% 存储过程方法更易于维护，因为它是将所有转换和业务逻辑放在一个地方的唯一可行方法。使用混合 ETL/sproc 系统，您必须查看多个位置以跟踪、排除故障、调试或更改整个转换。
ETL 工具的最佳点是在您拥有大量数据源且转换相对简单的系统上。
使代码可测试，这样您就可以分离组件并单独测试。只能在 ETL 工具的复杂数据流中间执行的代码更难测试。
使数据提取哑，没有业务逻辑，并复制到暂存区。如果您的业务逻辑分布在提取和转换层中，您将拥有无法单独测试的转换，并且难以追踪错误。如果转换是从暂存区域运行的，则可以减少对源系统的硬依赖，从而再次增强可测试性。这是基于 sproc 的架构的一个特别胜利，因为它允许几乎完全同质的代码库。
构建一个通用的缓慢变化的尺寸处理程序或使用现成的（如果有）。这使得对这个功能进行单元测试变得更容易。如果这可以进行单元测试，则系统测试不必测试所有极端情况，只需测试提供给它的数据是否正确。这并不像听起来那么复杂——我写的最后一个是大约 600 或 700 行 T-SQL 代码。任何通用擦洗功能也是如此。
如果可能，增量加载。
检测您的代码 - 让它生成日志条目，可能会记录诊断信息，例如检查总数或计数。没有这个，故障排除几乎是不可能的。此外，断言检查是一种考虑错误处理的好方法（在 b 中的行数是否相等，A:B 关系真的是 1:1）。
使用合成密钥。使用来自源系统的自然键将您的系统与数据源联系起来，并且难以添加额外的源。系统中的键和关系应始终对齐 - 没有空值。对于错误，“未记录”，在维度表中创建特定的“错误”或“未记录”条目并与之匹配。
如果您构建操作数据存储（许多宗教战争的主题），请不要回收星型模式中的 ODS 密钥。一定要加入 ODS 键来构造维度，但要匹配自然键。这允许您任意删除和重新创建 ODS - 可能会更改其结构 - 而不会干扰星型模式。拥有此功能是真正的维护胜利，因为您可以随时更改 ODS 结构或强力重新部署 ODS。

第 1-2 点和第 4-5 点意味着您可以构建一个系统，其中任何给定子系统（例如单个维度或事实表）的所有代码都位于系统中的一个且仅一个位置。这种类型的架构也更适合大量数据源。

第 3 点与第 2 点相对。基本上，SQL 和 ETL 工具之间的选择是转换复杂性和源系统数量的函数。数据越简单，数据源的数量越多，基于工具的方法就越有说服力。数据越复杂，迁移到基于存储过程的体系结构的理由就越充分。一般来说，最好只使用或几乎完全使用其中之一，但不能同时使用两者。

第 6 点使您的系统更易于测试。测试 SCD 或任何基于更改的功能非常繁琐，因为您必须能够向系统提供多个版本的源数据。如果您将变更管理功能移动到基础架构代码中，您可以使用测试数据集对其进行单独测试。这是测试的胜利，因为它降低了系统测试要求的复杂性。

第 7 点是大数据量时需要观察的一般性能提示。请注意，您可能只需要对系统的某些部分进行增量加载；对于较小的参考表和尺寸，您可能不需要它。

第 8 点与任何无头进程密切相关。如果它在夜间出现问题，您希望有一些战斗机会，看看第二天出了什么问题。如果代码没有正确记录发生的事情并捕获错误，那么您将很难进行故障排除。

第 9 点赋予了数据仓库自己的生命。当仓库拥有自己的密钥时，您可以轻松地添加和删除源系统。仓库键也是实现渐变维度所必需的。

第 10 点是维护和部署的胜利，因为如果您需要添加新系统或更改记录的基数，可以重新构建 ODS。这也意味着可以从 ODS 中的多个位置加载一个维度（想想：添加手动会计调整），而不依赖于 ODS 键。

score 5 · Accepted Answer

我拥有每天、每周、每月和每年将数据从 200 多个分布式数据库中提取到中央数据库的 ETL 流程经验。这是大量的数据，我们遇到了许多针对我们情况的问题。但在我看来，无论情况如何，都需要考虑几项：

确保在源端和目标端都考虑文件锁定。确保其他进程没有锁定文件（并在必要时删除这些锁定并且有意义）很重要。
为自己锁定文件。确保，尤其是在提取数据时锁定文件的源，这样您就不会获得中途更新的数据。
如果可能，请提取增量，而不是所有数据。获取数据的副本，然后只提取已更改的行而不是所有内容。您的数据集越大，这一点就越重要。如果必须，请查看期刊和触发器，但随着在特定基础上拥有这些数据变得越来越重要，这可能是我给你的第一条建议。即使它为项目增加了大量时间。
执行日志。确保你知道它什么时候工作，什么时候没有，并且在这个过程中抛出特定的错误可以真正帮助调试。
文件，文件，文件。如果你建立了这个权利，你将建立它，然后很长一段时间都不会考虑它。但是可以保证，您或其他人将需要在某个时候重新使用它以增强它或进行错误修复。在这些情况下，文档是关键。

HTH，如果我想到别的，我会更新这个。