如何处理ETL任务？

Question

我应该执行ETL，其中源是一个大型且设计不佳的sql 2k数据库和一个设计得更好的sql 2k5数据库。我认为SSIS是要走的路。任何人都可以提出一个待办事项清单或清单或要注意的事情，以便我不会忘记任何事情吗？我应该如何解决这个问题，以便它不会在后面咬我。

Answer 1

那么我正在为我所在的公司开发一个ETL。

我们正在与SSIS合作。 使用api来生成和构建我们自己的dtsx包。

SSIS它不适合管理错误。有时你会得到一个“OleDb错误”，根据上下文可能会有很多不同的含义。

阅读API文档（他们不多说）。

一些链接来帮助你开始有： http://technet.microsoft.com/de-de/library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345167.aspx

http://msdn.microsoft.com/en-us/library/ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2551674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki/ComponentErrorCodes.html

http://www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library/ms187670.aspx

http://msdn.microsoft.com/ja-jp/library/microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http://www.sqlis.com/post/Handling-different-row-types-in-the-same-file.aspx

http://technet.microsoft.com/en-us/library/ms135967(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms137709(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345164(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms141232.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SSIS/Q_23972361.html

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&PostID=1404157

http://msdn.microsoft.com/en-us/library/aa719592(VS.71).aspx

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&ForumID=80

http://blogs.conchango.com/jamiethomson/archive/2005/06/11/SSIS_3A00_-Custom-Logging-Using-Event-Handlers.aspx

http://blogs.conchango.com/jamiethomson/archive/2007/03/13/SSIS_3A00_-Property-Paths-syntax.aspx

http://search.live.com/results.aspx?q=%s&go=Buscar&form=QBJK&q1=macro%3Ajamiet.ssis

http://toddmcdermid.blogspot.com/2008/09/using-performupgrade.html?showComment=1224715020000

http://msdn.microsoft.com/en-us/library/ms136082.aspx

http://support.microsoft.com/kb/839279/en-us

对不起， “垃圾邮件”，但他们对我非常有用的。

Answer 2

我们正在做一个巨大 ETL（移动从传统AS400应用到Oracle EBS客户端），而我们实际上有一个过程，（有修改），我可以推荐：

1. 确定关键目标 表/字段。
2. 确定关键的 源表/字段。
3. 与 商业用户合作将源映射到 目标。
4. 分析 质量问题的源数据。
5. 确定谁是 负责数据质量问题 确定。
6. 有责任方 清理源中的数据。
7. 从步骤开发基于 信息的实际ETL 1 - 3

最棘手的步骤是在我的经验2 & 3 - 它有时很难得到企业用户正确识别所有的位，他们需要一次通过，并且可能更难以正确识别数据来自哪里（虽然这可能与我看到的神秘文件和字段名称有关）。但是，这个过程应该可以帮助你避免重大失误。

Answer 3

我对ETL过程有经验，每天，每周，每月和每年将数据从200多个分布式数据库提取到中央数据库。这是一个大量的数据，并且我们有很多问题具体到我们的情况。但在我看来，有几个项目去想不管形势：

• 确保你把文件锁定的考虑，无论在源和目标端。确保其他进程没有锁定文件（并在必要时删除这些锁，这很有意义）非常重要。

• 为自己锁定文件。请确保，特别是在您拔出数据时锁定文件的源代码，以避免中途更新数据。

• 如果可能的话，拉动deltas，而不是所有的数据。获取数据的副本，然后只取出已更改的行而不是所有的行。数据集越大，这变得越重要。如果需要的话，查看期刊和触发器，但由于在某种基础上获取这些数据变得更重要，这可能是我会给你的头号建议。即使它为项目增加了大量时间。

• 执行日志。确保你知道什么时候工作，什么时候没有工作，并且在过程中抛出特定的错误可以真正帮助调试。

• 文件，文件，文件。如果你建立这个权利，你会建立它，然后长时间没有考虑它。但是你可以保证，你或其他人需要在某个时候回到它来增强它或者修正错误。文档是这些情况下的关键。

HTH，如果我想到其他东西，HTH会更新这个。

Answer 4

一些一般性的ETL提示

1. 考虑 目的地组织它（例如，所有的 代码生成客户 尺寸住在同一模块中，无论其来源）。 这有时被称为 面向主题的ETL。它使 找到更容易的东西，并将 增加您的 代码的可维护性。

2. 如果SQL2000数据库是一个烂摊子， 你可能会发现，SSIS 数据流处理 与数据的笨拙方式。通常，ETL工具 规模较小且复杂; 类似于所有数据的一半 财务仓库项目 公司已完成存储 程序代码作为明确的 架构决策 - 正是出于这个原因。如果您有 需要在 sprocs中输入大量代码，请考虑将代码中的所有代码放在sprocs中。
   
   对于涉及大量复杂清理或转换的系统，100％sproc方法更具可维护性，因为它是将所有转换和业务逻辑放在一个位置的唯一可行方法。使用混合的ETL/sproc系统，您必须查看多个位置才能跟踪，排除故障，调试或更改整个转换。

3. ETL工具的甜蜜之处在于您拥有大量数据源且具有相对简单转换的系统。

4. 使代码成为可测试的，因此您可以将 拆开组件并单独测试 。只能在ETL工具的复杂数据流中执行的代码很难测试。

5. 使数据提取哑而没有 业务逻辑，并复制到 临时区域。如果您的业务逻辑分布在提取层和 变换层中，那么您将有 转换，这些转换无法孤立地进行测试 ，并且很难 跟踪错误。如果转换是从分段区域运行的 ，那么您将减少对源系统的严重依赖，从而再次增强可测试性。这是基于sproc架构的一个特别的胜利，因为它允许几乎完全同质的代码库。

6. 建立一个通用的缓慢变化的 尺寸处理程序或使用一个关闭 货架（如果可用）。这使得它更易于单元测试这个 的功能。如果这样可以对单元 进行测试，系统测试并不是 必须测试所有的角落情况， 仅仅是数据呈现给 它是正确的。这并不像听起来那么复杂 - 我写的最后一个是大约600或700行的T-SQL代码。任何通用清理功能都是一样的。

7. 如果可能的话，增量加载。

8. 仪器的代码 - 让它做日志条目，可能记录诊断，如检查总数或计数。没有这个，故障排除几乎是不可能的。此外，断言检查是考虑错误处理的好方法（在b中的行计数是否相等，A：B关系实际上是1：1）。

9. 使用合成键。使用源系统中的自然键将您的系统绑定到数据源，并且很难添加额外的源。系统中的关键和关系应始终排队 - 无空位。对于错误，“未记录”，请在维度表中制作特定的“错误”或“未记录”条目并与其匹配。

10. 如果构建Operational Data Store（许多宗教战争的主题），请不要回收星型模式中的ODS密钥。通过一切手段加入ODS键来构建维度，但匹配一个自然键。这使您可以任意删除和重新创建ODS - 可能会更改其结构 - 而不会干扰星型模式。拥有这种能力是一个真正的维护胜利，因为您可以随时更改ODS结构或在任何时候对ODS进行暴力重新部署。

点1-2和4-5的意思是，你可以建立一个系统，如果对于任何给定子系统的代码所有（例如一维或事实表）住在一个只有一个地方系统。这种类型的体系结构对于大量的数据源也更好。

点3是点2的对应点。基本上，SQL和ETL工具之间的选择是转换复杂性和源系统数量的函数。数据越简单，数据来源越多，基于工具的方法的情况就越强烈。数据越复杂，转移到基于存储过程的体系结构的情况越强烈。一般来说，最好是完全或几乎完全使用一种或另一种，但不能同时使用两种。

点6使您的系统更容易测试。测试SCD或任何基于更改的功能都很麻烦，因为您必须能够向系统呈现多个版本的源数据。如果将变更管理功能移到基础结构代码中，则可以使用测试数据集独立进行测试。这是测试中的一个胜利，因为它降低了系统测试要求的复杂性。

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

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

第9点给数据仓库自己的生活。当仓库拥有自己的密钥时，您可以轻松添加和删除源系统。仓库密钥也是实现缓慢变化的维度所必需的。

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

Answer 5

此线程旧，但我想提请您注意ConcernedOfTunbridgeWells的答案。在所有方面，这是非常好的建议。我可以重申一些，但这会减少其余的，他们都值得仔细研究。