繁体   English   中英

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

[英].Net vs SSIS: What should SSIS be used for?

如果我可以选择使用.Net并且可以在 .Net 中很好地进行数据transformations ,那么我什么时候需要SSIS 是否有特定的任务SSIS会更好? 透明度带来的额外好处值得吗? 这只是我更舒服的吗? 确定这一点的最佳做法是什么?

好问题。

如果数据传输量巨大? 您是否正在处理多个数据文件并需要事务(在文件系统级别和数据库级别)? 您是否在不同位置处理多个数据源(例如 ftp、本地文件系统、数据库)?

如果以上的答案是肯定的,那么继续 ssis。 基本上 .net 对小数据导入/导出工作很酷,但是当你有更复杂的事情时,ssis 绝对是赢家

我看到的另一件事是 - 当 ssis 中的所有内容都可用时,是否值得编写 .net 代码。 (不要误会我 - 我喜欢编码)但是,你编码的任何东西,你都需要维护:-)

我认为项目时间/预算限制和标准工具的使用是使用 SSIS 的一些最大论据。 在大多数情况下,创建 SSIS 包比尝试在 .NET 中编写类似代码要快得多。

但话虽如此,似乎 SSIS 有很多 痛点,有时可能会使这个论点无效。 在开发需要在许多不同客户端的不同环境中运行的解决方案时,它对我有用。 SSIS 只是看起来太痛苦了,我对它的项目评估得越多。 正确架构的 .NET 解决方案更易于部署、更可靠、更灵活、更易于理解,并且还可以获得非常好的性能。

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

我不使用 SSIS 的论点是:

  • 设计绿地产品,使它们具有 RESTful 数据馈送,用于报告和提取内置到项目计划和预算中,最好是像 OData 这样的标准,以便其他工具可以直接插入。

  • 数据馈送应从上游系统和按需馈送中提取和转换; 这样调度任务、调度任务的配置、任务运行器虚拟机和人员来运行所有这些不可靠的调度内容都被否定了。

  • RESTful 数据馈送利用 HTTP 缓存。

  • Feeds/services/APIs 可以很容易地移动到弹性规模的云中。

  • SSIS 需要找到具有 SSIS 技能并且喜欢做这些事情数周的人。 根据我的经验,寻找和留住 SSIS 开发人员既困难又昂贵,而且找到的人往往低于标准。

  • SSIS 不适用于源代码控制和协作工作。

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

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

  • SSIS 不适合模块化设计和许多小更改的持续部署,它往往是大批量的,发布时很吓人。

  • SSIS 提倡使用存储过程,这对作为热点的 SQL 提出了很多要求。 青睐对可扩展、无状态的中间层提出要求的设计。

  • 工具笨重且不可靠。

  • 您受制于 Microsoft 的 SSIS 路线图。

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

  • 永远不要使用 Excel 作为数据 培训员工。

  • 代码为王。

最终,我将 SSIS 视为企业 IT 的遗物。 我想问,“Google 会使用 SSIS 吗?” 问题还能怎么解决? 创造性思考。

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

从小型项目到大型复杂 ETL,我在 SSIS 方面拥有丰富的经验。 不深入细节,这是我对您的指导:

  • 如果您是一名 DBA 并且不熟悉 .NET,或者您是一位非常熟悉 SSIS 的开发人员,那么您可以将 SSIS 用于小型、简单、相当直接的提取、转换、加载 (ETL) 任务。

  • SSIS 非常古怪,有很多陷阱、陷阱和可能被认为是彻头彻尾的错误。 如果您非常熟悉,它会非常强大。

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

  • 如果您想做一些不重要的事情,并且如果您可以使用 .NET 技能,请使用 .NET 而不是 SSIS。

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

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

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

  1. 阻塞转换 - 只有当上述转换完成时才能传递数据,获取所有行并完成所需的计算。
  2. 半阻塞变换 - 可以传递部分数据
  3. 非阻塞 - 准备好后立即处理该行

SSIS 在控制流和数据流的正确设置下,在非阻塞转换方面表现得非常好。 我已经在更大的(超过 2 TB 的数据仓库)上使用过它,我可以保证它是最快的加载体验。 您可以查看 Microsoft 博客,了解我们使用 SSIS 在 30 分钟内加载了 1TB,您也可以

我同意 SSIS 在处理阻塞转换时会降低性能,并且它们应该在需要时由 T-SQL 承载。

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

现在的重点是什么是更方便的方法来解决您的问题陈述。 SSIS 是加载大量记录的肯定赢家,将数据从源加载到目标,而 C# 非常适合编写逻辑。 即使你喜欢C#,我也不建议你选择在大型数据仓库系统上做ETL(Extract Transform Load)操作。

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

正如每个人所解释的,如果您正在进行大量数据操作,它是一个很好的工具。 如果你有 SQL 的话,它是免费的,而且很容易用 VS 2008 BIDS 学习

SSIS 一般用于 ETL(提取转换加载)。 具体用例是SSAS(SQL Server Analysis Services)多维数据集的预处理; 并使用 Data Change Capture 增强提取。

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

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

SSIS 包可以调用其他 SSIS 包。 这使代码保持模块化,允许重用。

它可以处理各种数据源,并使用派生列控件执行简单的转换。 这与在源服务器上进行转换(例如,可以是 Oracle 或 Hadoop - 您无法使用本地 SQL Server 进行控制)相反。

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

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

顾名思义,SSIS 是一个集成系统。 在 .net 中处理不同数据源(如 excel、teradata、oracle 等)的连接器以及履行正常关闭这些连接、垃圾收集、处理内存问题的责任可能非常困难。

因此,SSIS 是开箱即用的产品,非常适合这样的场景:不仅需要从两个不同的源中提取数据,而且还需要在将其写入数据之前执行一系列查找、转换、合并、派生和计算目标位置(无论是 sql server、平面文件还是其他数据库系统)。

SSIS 也有检查点,如果包由于任何原因失败,它将从它停止的地方恢复(它需要配置,因为这不是默认行为)。

此外,SSIS 将为您节省大量时间,因为它的任务是可重用的,并且它的部署过程相当容易实施和安排,并有出色的事件处理支持。

基本上,SSIS 具有许多优点,例如将数据从 A 点传输到 B 点并分成较小的块并单独进行调试,能够轻松访问 SQL Server 表,处理 XML 数据,使用 c# 脚本调用 API 并将数据保存在 DB 上,读取 DB远程服务器上的数据和 FTP 等等。
除了一堆现有的 BI 块外,您还可以使用自己的参数和输出创建自己的自定义任务。
希望我能够为现有的答案添加一些要点。

由 SSIS 开发人员使用并且与 .Net 相比相对容易的日常任务可以包括

表之间的数据比较。

Conditional Splitting,数据根据某种逻辑阻塞数据。

数据转换,查找,合并,unionall,比较好用。

文件处理(修改、验证)。

错误处理,电子邮件警报。

Containers 、 FOR/FOReach 循环很容易使用。

使用 WebService 任务可以轻松地在 Web 服务上发布数据。

检查点,数据加载的可重新运行性很容易处理。

在 ssis 中调试很容易 - 可以在容器级别、包级别完成。

如果任务不可用,也可以编写脚本。 此外,您可以自定义您自己的任务

无论人们在以前的答案中说什么都是正确的,但我认为使用 SSIS 而不是编码的最重要方面是易于维护过程和可重复使用的产品。

SSIS 非常适合 BI 应用程序,您可以操作 Stage Table 上的数据,而不是在 DataWarehouse 表上提供可用于 BI 的数据。

我可以连接到 SAP、Oracle 以获取员工信息并在 PowerBI、QlikView 等上可用...

如果您知道在哪里以及为什么使用它,它是一个不错的工具。 使用 ir 因为它很酷你会遇到麻烦。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM