SQL Server中是否有用于编程ETL的标准语言/界面?


10

我目前正在为我们的数据仓库创建ETL。我们正在使用SSIS 2008,但是我们遇到了问题,其中最大的就是难以重用组件。每个表都有单独的程序包,每个程序包都将父程序包中的多个变量作为输入。当我们对这些输入变量进行更改时,我们需要进入每个程序包(现在有15个左右,但是这个数字将大大增加)并修改程序包以应对这些更改。还有其他问题,包括无法为我们的提取运行任意SQL,不良的日志记录功能等。

如果有一种方法可以开发代码中的ETL,实现代码重用,通用库,更好的单元测试等,那么整个过程将更加健壮。是否存在用于SQL Server的事实上的标准ETL语言/ API?我希望尽可能避免使用GUI工具。

编辑:我应该提到我的背景。我不是DBA,也没有正式(或非正式)的DBA培训,随着我的发展,我基本上已经了解了这些内容,因此,我很可能尝试使用SSIS进行不合适的工作或尝试使用此ETL。从错误的角度投射。另外,我目前在州政府工作,所以任何需要购买新软件包的解决方案都不在可能范围之内。


这是我们的任务之一。我们正在使用一个SSIS包来加载仓库中的每个表。每个Fact程序包和Dimension程序包通常都相同,只是它们的区别在于

  • 从源数据库中提取
  • 数据流中的操作
  • 合并到目标表

我想做的(我发现在SSIS中很难做)

  • 从文本文件加载提取查询。当开发人员编写和测试其提取查询时,我不必在SSIS运行它之前以任何方式操纵他们的查询,也不必将查询剪切并粘贴到DB Source对象中。
  • 分别测试每个组件。我应该能够独立地测试单个表的完整ETL过程,而与其他表负载无关。
  • 在一处修改共享逻辑,而不必编辑每个单独的程序包。每个包都以相同的方式将数据加载到审核表中,如果我想更改已加载已审核的数据,则不需要编辑所有15个包(随着时间的推移,这个数量会变得更大)。

如果适当地使用共享代码以编程方式完成,则整个过程感觉将更容易实现,并且更加健壮。


4
我不是SSIS的非常大的用户,但是在这里可以理解陡峭的学习曲线。我鼓励您看一下该领域专家安迪·伦纳德(Andy Leonard),杰米·汤普森(Jamie Thompson)和布莱恩·奈特(Brian Knight)的一些视频/博客,并获得一些指导。请查看sqlpass.org网站,以获取pass Summit和sqlblog.com,pragmaticworks.com的免费视频-Sankar
Reddy

我认为学习曲线不是问题。我知道如何做我想在SSIS中完成的任务。我正在寻找一个新的流程,因为我发现的解决方案是重复性的,脆弱的并且不必要的复杂。
kubi 2011年

Kubi,如果您可以添加有关所指组件的详细信息,我会请人来为您解答。目前,您的问题太广泛了,无法回答。
Sankar Reddy

4
@kubi-您触及了BI行业肮脏的小秘密之一。ETL工具在抽象和可重用逻辑方面非常非常差。结果,随着域复杂性的增加,它们的伸缩性非常差。
ConcernedOfTunbridgeWells 2012年

1
我拥有相当好的权威,银行和保险业的某个行业垂直产品(由您所听说过的公司制造,通常用特定颜色表示)的大约一半客户做出了明确的技术决策来建立他们的正是由于这个原因,存储过程中的ETL处理提示。
ConcernedOfTunbridgeWells 2012年

Answers:



6

阅读本文后,我立即想到了推荐Varigence的工具。但是,我看到Varigence的一位首席建筑师John Welch来到了我面前。

Varigence的工具是SSIS之上的抽象层。提供的优点是能够定义可重复使用的“东西”,从而在多个包装之间提供一致性。您可以定义软件包的结构,以及各个软件包之间的区别-Varigence工具的“已编译”输出是SSIS软件包。

可以将其视为适用于SSIS包的Dynamic SQL。带有GUI。真的很酷。


3

我尝试了几次使用SSIS,并放弃了。IMO可以轻松完成我在C#中需要做的所有事情。SSIS太复杂了,它有太多陷阱,这是不值得的。花更多的时间在提高C#技能上比花在学习SSIS上的时间更好-您将获得更多的培训回报。我不需要在这里详细介绍-Ayende撰写了一篇很棒的总结,没有什么好补充的

在VS解决方案中查找和维护功能也非常容易。使用VS进行单元测试很容易。我需要做的就是在Subversion中检入源代码,并验证其加载方式。温和地说,单元测试SSIS包非常复杂。

此外,在某些情况下,SSIS默默地未能填充某些行中的某些列,只是跳过它们而没有引发异常。我们花了很多时间进行故障排除并弄清楚发生了什么。用C#开发替代解决方案用了不到一个小时的时间,并且两年没有任何问题。

此外犀牛ETL似乎真的很酷。

关于stackoverflow也有一些类似的讨论


2

我个人使用SQL处理尽可能多的ETL过程。我使用SSIS从FTP站点或Excel之类的奇异数据源中导入,但这只是将原始数据导入数据库,而其余的则由SQL完成。

我当前的情况相对简单,因为大多数数据位于其他MS SQL数据库中,可以与我建立链接服务器。如果必须连接到其他平台,建议使用OPENQUERYBULK INSERT。如有必要,可以通过编程方式构造它们,并且在两者之间可以连接大多数类型的数据。

我使用SQL是因为它是我最了解的,但是它具有一些客观优势。最值得注意的是,它已经被使用:无需学习或购买新工具。这是一项广泛使用的技能,对您的老板来说应该很重要。由于它在数据库中运行,因此记录很容易。它基于纯文本代码,因此易于搜索,并且可以与源代码控制一起很好地工作。它非常稳定,几乎没有供应商更改产品和破坏向后兼容性的机会。它可能至少和任何RBAR语言一样快。

如果您需要更多,我推荐.NET(仅因为它在SSIS和SQLCLR中使用)。我使用C#应用程序来管理整个ETL过程-开始子步骤,监视其输出,发送电子邮件。但是几乎所有这些都可以通过SQL Agent,dbmail等完成。

有什么原因不能将SQL用于ETL?它无法为您做什么?


实际上,我们使用SSIS将原始数据转储到临时数据库中,然后使用TSQL定义了如何对其进行T和L处理。
保罗
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.