logo标签列表

.Net与SSIS：SSIS应该用于什么？

.netsql-serverssis
66
如果我可以选择使用 .Net 并且能够在 .Net 中轻松进行数据转换，那么我什么时候需要使用 SSIS？是否存在某些任务使用 SSIS 更好？透明度的额外好处是否值得？这是不是只是我更加熟悉的问题？如何确定最佳实践？
3
我的经验是，如果你对一个项目的需求非常了解，并且可以使用标准的SSIS组件和最少的脚本轻松地实现这些需求，那么SSIS可能是一个可行的选择。否则，它会很麻烦。 - Steam
是的，你可以使用.NET来转换数据，但是.NET背后的组织也开发了SSIS，这是有原因的。在ETL任务方面，SSIS就像厨师刀一样，完美地磨合和平衡。它是专门为ETL任务而构建的，可以处理多个不同的数据源（文件、数据库、FTP）、事务隔离、数据流逻辑。自己用C#编写这些功能并不容易。然而，如果你面对的ETL任务本身很简单，那么.NET可能就足够了。 - Troy Witthoeft
14个回答
51

很好的问题。

如果数据传输量很大，你是否需要处理多个数据文件并需要在文件系统层和数据库层进行事务处理？你是否需要处理不同位置（例如FTP、本地文件系统、数据库）的多个数据源？

如果上述答案是肯定的，那么可以使用SSIS。基本上，.NET适用于小型数据导入/导出作业，但是当您处理更复杂的任务时，SSIS是明显的优选。

我关注的另一件事是：当SSIS中已经存在所有必要的功能时，是否值得编写.NET代码。（不要误解我-我喜欢编程）但是，任何你编写的东西都需要维护 :-)

我喜欢SSIS。但有时候，.net确实是唯一的选择，在这种情况下，我通常会将我的转换代码直接编写到SSIS包中。对于已经为你完成的工作，是否值得编写代码，我给出+1的肯定答复。 - Dayton Brown
19

我认为项目时间/预算限制和使用标准工具是使用SSIS的最大理由之一。创建SSIS包通常比尝试在.NET中编写类似的代码要快得多。

但话虽如此，似乎SSIS有许多痛点，有时可能会否定这个论点。对我来说，当开发需要在许多不同客户端的不同环境中运行的解决方案时，SSIS看起来太麻烦了。一个经过良好设计的.NET解决方案更容易部署，更可靠，更灵活，更容易理解，并且也可以实现非常好的性能。

在我看来：考虑将SSIS用于只需要部署到一个或两个内部SQL Server环境的项目。否则，.NET方法很快就会变得更有吸引力。

痛点再加1分。SSIS不是一种灵活的ETL工具，非常容易出错，并且使面向对象的101编程实践变得难以实现。 - DetectiveEric
7
@DetectiveEric，你在从关系型数据库中加载数据时不应该使用面向对象的编程实践。 - HLGEM
又一个痛点 - http://social.msdn.microsoft.com/Forums/sqlserver/en-US/946e516b-fdf3-40bd-886d-e70a8dfae46b/assigning-a-sql-null-to-an-ssis-string-a-ssis-flaw-?forum=sqlintegrationservices - Steam
同样的观点在这里也有 - http://www.sqlservercentral.com/Forums/Topic1538944-364-1.aspx - Steam
并且在SO上也有 - http://stackoverflow.com/questions/21616435/assigning-a-sql-null-to-a-ssis-string-a-ssis-flaw - Steam
SSIS 不适合版本控制。 - Ronnie
14

我不使用SSIS的理由如下：

  • 设计全新产品时，应该在项目计划和预算中构建RESTful数据源以进行报告和提取，最好采用像OData这样的标准，以便其他工具可以轻松接入。

  • 数据源应该按需从上游系统和源中提取和转换，这样就可以消除定时任务、定时任务配置、任务运行器虚拟机和运行所有这些不可靠调度工作的人员所带来的影响。

  • RESTful数据源利用HTTP缓存。

  • 数据源/服务/API可以轻松地迁移到弹性扩展云上。

  • SSIS需要找到有SSIS技能且愿意花费数周时间做这种工作的人员。根据我的经验，找到并留住SSIS开发人员是困难且昂贵的，而且找到的人往往表现不佳。

  • SSIS与源代码控制和协同工作不兼容。

  • SSIS不适合代码重用，与微服务和传统代码库不同。

  • SSIS不易版本控制，与REST服务不同。

  • SSIS不适合模块化设计和持续部署许多小更改，它往往是大批量的发布，令人生畏。

  • SSIS促进了存储过程的使用，这会对SQL产生很大的需求。应该选择那些对可缩放、无状态中间层产生需求的设计。

  • 工具使用麻烦且不可靠。

  • 你要受制于Microsoft对SSIS的路线图。

  • 考虑在数据进入应用程序时立即写入支持分析、报告和视图的表格/服务，查看事件溯源和其他应用程序架构模式。

  • 永远不要将Excel作为数据源；要对员工进行培训。

  • 代码至上。

我认为SSIS是企业IT的遗物。我想问一下，“Google会使用SSIS吗？”那么，如何解决这个问题呢？要开动脑筋，寻求其他解决方案。

7

我认为这取决于你正在做什么。SSIS非常强大，就像旧的DTS一样。如果你正在加载大量项目并希望进行持续更改，我建议全部使用SSIS。如果你只想加载少量项目，并且是为很多客户服务，那就用代码实现。在内部ETL流程中，我更喜欢使用SSIS，但当我需要从遗留系统加载数据到SQL数据库时，我会在客户端商店使用.Net。现在，正如我之前所说的，如果你有许多转换和许多不同的数据存储库需要加载，我认为你要在.Net中这样做是很疯狂的，所以我会选择SSIS。如果你只需要加载少量项目，并且这是单个应用程序的一部分，可能会安装在各种客户端上，那我会全部使用.Net。这只是我的意见。

4

我在从小型项目到大型复杂ETL方面都有着丰富的SSIS经验。以下是我的建议：

  • 如果你是DBA并不熟悉.NET，或者你是非常熟悉SSIS的开发人员，则可以使用SSIS来处理小型、简单、相当直接的抽取、转换、加载(ETL)任务。

  • SSIS非常古怪，存在许多陷阱、意外之处和被认为是明显错误的地方。如果你非常熟悉它，它会极其强大。

  • C#现在拥有TPL数据流。简单的性能测试将其置于SSIS之前。（例如http://mymemoryleaks.blogspot.cz/2013/10/ssis-vs-tpldataflow.html）

  • 如果想要做任何超越琐碎的事情，并且能够使用.NET技能，请使用.NET而不是SSIS。

先生，我想通过编程从数据源（如Oracle、MySQL或Excel）复制数据库到我的SQL Server实例。我有一个网站想要这样做。请问我应该使用SSIS还是其他什么工具来完成这个任务？ - Learning-Overthinker-Confused
2

SSIS通常用于ETL（提取转换加载）。具体的用例是预处理SSAS（SQL Server分析服务）立方体；并使用数据更改捕获进行增强提取。

它可以执行典型的自动化，包括FTP和电子邮件。还有使用脚本任务（C#或Visual Basic）的编程方面，因此SSIS具有超出其包含的控件的功能...

程序包可以编程为使用条件控制流路径。例如，周一到周五执行某个任务，周六和周日执行不同的任务。或者如果不满足某些条件，则拒绝执行ETL。

SSIS程序包可以调用其他SSIS程序包。这使得代码模块化，允许重复使用。

它可以与各种数据源配合使用，并使用Derived Column控件执行简单的转换。这与在源服务器上进行转换（例如Oracle或Hadoop-您无法控制本地SQL Server的内容）相比。

2

我认为主要优势在于以可视化的方式定义整个编程结构。任何人查看SSIS包都可以很容易地理解它。与SQL紧密集成，允许您参与SQL的备份调度，这是一个巨大的优势。

正如每个人所解释的，如果您正在进行大量的数据操作，这是一个好工具。如果您拥有SQL，则可以免费使用，并且非常容易学习，配合VS 2008 BIDS使用更佳。

2
有点晚回答这个问题，但我希望它值得一提，
SSIS经常被误解为编程语言。SSIS是一个框架，而C#是.NET Framework上的一种语言。我有处理和开发大型数据仓库解决方案（MSBI套件）的丰富经验，也开发过大型网站（ASP.NET）-所以我不能有偏见。
如果不正确使用，SSIS可能会降低性能。SSIS包有三种转换类型：
1. 阻塞转换-只有在上面的转换完成获取所有行并完成所需计算后才能传递数据。 2. 半阻塞转换-可以传递部分数据 3. 非阻塞-一旦准备好就立即处理行
通过对控制流和数据流进行适当设置，SSIS与非阻塞转换配合使用效果非常好。我曾在更大的数据仓库中使用它（超过2TB），我可以保证它是最快的加载体验。你可以查看微软的博客We Loaded 1TB in 30 Minutes with SSIS, and So Can You。
我同意SSIS在处理阻塞转换时性能下降，因此应该在必要时使用T-SQL来处理它们。
至于C#，我认为SSIS使用.NET框架和数据提供程序来完成任务。但是，作为一种语言，C#更加逻辑化，必须用于处理业务逻辑。例如，如果我们必须根据条件运行不同参数的exe文件，则可以编写一个包，该包将考虑参数，然后根据逻辑决定需要传递什么参数以运行exe文件。在SSIS中做这件事情会很繁琐，而在C#中可以轻松完成，因为逻辑上的事情可以在语言中轻松完成，而不是在框架中。
现在问题是解决问题陈述的最方便方法是什么。 SSIS是在从源到目的地加载大量记录的情况下的绝对赢家，而C＃则非常适合编写逻辑。即使您喜欢C＃，我也不建议您选择在大型数据仓库系统上执行ETL（提取转换加载）操作。
2

SSIS具有许多内置的方式，可以从不同的数据源进行转换，并且您可以将它们串联在一起，使其非常可定制化。它们具有内置的优化功能，使它们快速。

您还可以使用.NET创建自己的自定义转换，以利用SSIS作业的速度和可重复性。

1
正如其名称所示，SSIS是一个集成系统。在.NET中处理来自不同数据源的连接器（如Excel、Teradata、Oracle等）以及负责优雅关闭这些连接、垃圾回收和处理内存问题可能非常困难。
因此，SSIS是一个开箱即用的产品，非常适合需要从两个不同的源中提取数据，然后执行一系列查找、转换、合并、派生和计算操作，最后将数据写入目标位置（无论是SQL Server、平面文件还是另一个数据库系统）的情况。
此外，SSIS还具有检查点功能，如果包由于任何原因失败，它将从上次离开的地方继续执行（需要配置，因为这不是默认行为）。
另外，SSIS可以节省您大量时间，因为它的任务是可重用的，而且部署过程相当容易实现和调度，并且支持出色的事件处理。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接