.Net vs SSIS:SSIS应该用于什么?

如果我有使用.Net的选项,并且可以在.Net中进行数据转换,那么我什么时候需要SSIS? SSIS会更好吗? 透明度的附加好处值得吗? 这只是我更舒服吗? 确定这个的最佳实践是什么?

好问题。

如果数据传输量巨大? 你正在处理多个数据文件,并需要交易(在文件系统级别和数据库级别)? 你在不同的位置处理多个数据源(例如,ftp,本地文件系统,数据库)?

如果上面的答案是肯定的,那么继续ssis。 基本上.net对于小数据导入/导出工作很酷,但是当你有更复杂的东西时,ssis是一个明确的赢家

另一件我看到的是 – 当ssis中有一切可用的时候,值得写.net代码。 (不要误会我 – 我喜欢编码)但是,任何你编码,你需要保持:-)

我认为项目时间/预算限制以及标准工具的使用是使用SSIS的一些最重要的参数。 创build一个SSIS包大部分时间比在.NET中编写类似代码更快。

但有了这个说法,似乎SSIS有很多痛点 ,有时可能会使这个论点无效。 它为我开发了一个需要在不同的环境下运行的解决scheme。 SSIS看起来太痛苦了,我对这个项目的评价越多。 一个适当架构的.NET解决scheme更容易部署,更可靠,更灵活,更容易理解,也可以实现非常好的性能。

恕我直言:考虑使用SSIS的项目,你只需要部署到一个或两个内部的SQL Server环境。 否则,.NET方法将很快变得更具吸引力。

我想这取决于你在做什么。 SSIS非常强大,就像老式的DTS一样。 如果你正在加载大量的项目,并期望有不断的变化,我会一直去SSIS。 如果你正在寻找只加载几个项目,这是很多客户,我会把它放在代码中。 我更喜欢在内部ETL过程中使用SSIS,但是当我需要从传统系统将数据加载到SQL数据库时,我在客户端使用.Net。 现在,正如我之前所说,如果你有很多转换和许多不同的数据孤岛加载,我想你会疯狂在.Net做这个,我会去SSIS。 如果你只有一些项目需要加载,而且是单个应用程序,并且可能作为应用程序的一部分安装在不同的客户端上,我会一路去.Net。 只是我2美分。

从小项目到大型,复杂的ETL,我有很多SSIS的经验。 没有深入细节,这是我对你的指导:

  • 如果你是一个DBA,并且你不熟悉.NET,或者你是一个熟悉SSIS的开发者,那么你可以使用SSIS来进行一些简单,相当简单的提取,转换,加载(ETL)任务。

  • SSIS非常古怪,还有许多陷阱,陷阱和可能被认为是直接的错误。 如果你非常熟悉,这是非常强大的。

  • C#现在有TPL数据stream。 简单的性能testing让它领先于SSIS。 (例如http://mymemoryleaks.blogspot.cz/2013/10/ssis-vs-tpldataflow.html

  • 如果你想做的事情不是微不足道的,而且如果你可以使用.NET的技能,使用.NET而不是SSIS。

SSIS有许多内置的方法可以从不同的数据源进行转换,您可以将它们串联在一起,使其非常具有可定制性。 他们已经build立了优化,使他们快速。

您还可以使用.NET进行自定义转换,以利用SSIS作业的速度和可重复性。

我不使用SSIS的理由是:

  • devise绿地产品,使他们拥有RESTful数据源,用于项目计划和预算内置的报告和提取,最好是OData等标准,以便其他工具可以直接插入。

  • 数据馈送应该从上游系统拉动并转换,并按需提供; 这样计划任务,计划任务的configuration,任务运行者虚拟机和员工运行所有这些不可靠的调度的东西被否定。

  • RESTful数据提要利用HTTPcaching。

  • Feeds / services / API可以轻松移动到弹性云端。

  • SSIS要求find具有SSIS技能的人员,他们可以享受几周的时间。 根据我的经验,find并保留SSIS开发者是困难和昂贵的,发现的人往往是低于标准的。

  • SSIS在源代码控制和协同工作方面效果不佳。

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

  • 与REST服务不同,SSIS不易于版本化。

  • SSIS不适用于模块化devise和许多小的变化的持续部署,它往往是大批量和可怕的版本。

  • SSIS推动使用存储过程,这对于热点地区的SQL提出了很多需求。 喜欢devise的地方要求可扩展,无状态的中间层。

  • 工具笨重,不可靠。

  • 你是微软SSIS路线图的摆布。

  • 考虑在数据进入应用程序后尽快写入支持分析,报告和视图的表/服务; 请参阅CQRS和其他应用程序体系结构模式。

  • 切勿使用Excel作为数据 ; 培训员工。

  • 代码是国王。

最终,我将SSIS看作企业IT的遗迹。 我想问一下,“Google会使用SSIS吗? 如何解决问题呢? 创造性思考。

我认为主要优点是直观地定义整个编程结构。 任何一个看SSIS包都是非常自我解释的。 与SQL的SSIS紧密集成使您可以成为SQL的一部分,用于备份调度和巨大的优势。

正如每个人所解释的,如果你正在做大量的数据操作,这是一个很好的工具。 如果你拥有SQL,那么你可以免费使用VS 2008 BIDS

有点迟到回答这个问题,但我希望它值得,

与编程语言相比,SSIS经常被误解。 SSIS是一个框架,而C#是.NET Framework上的一种语言。 我在使用(MSBI套件)处理和开发大型数据仓库解决scheme方面拥有丰富的经验,并且还开发了大型网站(ASP.NET) – 所以我不能偏颇。

如果SSIS使用不当,可能会降低性能。 SSIS包有三种转换:

  1. 阻塞转换 – 只有在完成上述转换后才能传递数据,并获取所有行并完成所需的计算。
  2. 半块转换 – 可以传递部分数据
  3. 非阻塞 – 一旦准备就绪即可处理该行

SSIS在非阻塞转换的情况下工作得非常好,控制stream和数据stream的设置都是正确的。 我已经在更大的(超过2TB的数据仓库)上使用它,我可以保证这是最快的负载体验。 你可以用SSIS在30分钟内检查微博客的“ 我们装载1TB”,你也可以

我同意SSIS在处理阻塞转换时降低了性能,并且在需要时应该由T-SQL执行。

来到C#,我接受SSIS使用.NET框架和数据提供者来完成任务。 但是,作为一种语言,C#更合乎逻辑,必须处理好处理业务逻辑。 例如,如果我们必须根据条件运行不同的参数,则可以编写一个将考虑参数的包,然后在逻辑上决定运行一个exe文件需要传递哪个参数。 在SSIS中这样做会很漫长,而我可以在C#中轻松完成,因为逻辑上的事情可以用语言而不是框架轻松完成。

现在这里的重点是解决你的问题陈述的更方便的方法。 SSIS是一个肯定的赢家,加载大量的logging从源代码到目的地加载数据,而C#是完美的写逻辑。 即使您喜欢C#,我也不build议您select在大型数据仓库系统上执行ETL(提取转换加载)操作。