development

.Net 대 SSIS : SSIS는 무엇에 사용해야합니까?

big-blog 2020. 11. 21. 09:34
반응형

.Net 대 SSIS : SSIS는 무엇에 사용해야합니까?


.Net 사용 옵션이 있고 .Net에서 데이터 변환을 제대로 수행 할 수 있다면 언제 SSIS가 필요합니까? SSIS가 더 나은 특정 작업이 있습니까? 투명성의 추가 이점은 그만한 가치가 있습니까? 내가 더 편한 것입니까? 이를 결정하기위한 모범 사례는 무엇입니까?


좋은 질문.

데이터 전송량이 엄청나다면? 여러 데이터 파일을 처리하고 있고 트랜잭션이 필요합니까 (파일 시스템 수준 및 데이터베이스 수준 모두)? 다른 위치 (예 : ftp, 로컬 파일 시스템, 데이터베이스)에서 여러 데이터 소스를 다루고 있습니까?

위의 답변이 예이면 ssis로 진행하십시오. 기본적으로 .net은 작은 데이터 가져 오기 / 내보내기 작업으로 멋지지만 더 복잡한 것이 있으면 ssis가 확실한 승자입니다.

내가 보는 또 다른 것은-모든 것이 ssis 내부에서 사용 가능할 때 .net 코드를 작성할 가치가 있다는 것입니다. (나를 착각하지 마십시오-나는 코딩을 좋아합니다) 그러나 당신이 코딩하는 것은 무엇이든 유지해야합니다 :-)


프로젝트 시간 / 예산 제약과 표준 도구의 사용이 SSIS 사용에 대한 가장 큰 논거라고 생각합니다. SSIS 패키지를 만드는 것은 .NET에서 비슷한 코드를 작성하는 것보다 대부분 빠릅니다.

그러나 SSIS에는 때때로이 주장을 무효화 할 수 있는 많은 문제점 이있는 것 같습니다 . 여러 클라이언트의 다양한 환경에서 실행해야하는 솔루션을 개발할 때 저에게 도움이되었습니다. SSIS는 프로젝트에 대해 더 많이 평가할수록 너무 고통스러워 보였습니다. 적절하게 설계된 .NET 솔루션은 배포가 더 쉽고, 더 안정적이며, 더 유연하고, 이해하기 쉬우 며, 또한 매우 우수한 성능을 얻을 수 있습니다.

IMHO : 하나 또는 두 개의 사내 SQL Server 환경에만 배포해야하는 프로젝트에 SSIS를 사용하는 것이 좋습니다. 그렇지 않으면 .NET 접근 방식이 빠르게 더 매력적이 될 것입니다.


SSIS를 사용하지 않는 것에 대한 내 주장은 다음과 같습니다.

  • 보고 및 추출을위한 RESTful 데이터 피드를 프로젝트 계획 및 예산, 가급적이면 OData와 같은 표준에 내장하여 다른 도구가 바로 연결할 수 있도록 그린 필드 제품을 설계합니다.

  • 데이터 피드는 필요에 따라 업스트림 시스템 및 피드에서 가져오고 변환해야합니다. 따라서 일정 작업, 예약 된 작업 구성, 작업 실행자 VM 및이 모든 신뢰할 수없는 일정 작업을 실행하는 직원이 무효화됩니다.

  • RESTful 데이터 피드는 HTTP 캐싱을 활용합니다.

  • 피드 / 서비스 / API는 탄력적 규모의 클라우드로 쉽게 이동할 수 있습니다.

  • SSIS를 사용하려면 SSIS 기술을 가진 사람이 몇 주 동안 그 일을 즐기는 사람을 찾아야합니다. 내 경험상 SSIS 개발자를 찾고 유지하는 것은 어렵고 비용이 많이 들고 발견 된 사람들은 수준 이하인 경향이 있습니다.

  • SSIS는 소스 제어 및 공동 작업에서 잘 작동하지 않습니다.

  • SSIS는 마이크로 서비스 및 기존 코드 라이브러리와 달리 코드 재사용에 적합하지 않습니다.

  • SSIS는 REST 서비스와 달리 쉽게 버전을 지정하지 않습니다.

  • SSIS는 모듈 식 디자인과 많은 작은 변경 사항의 지속적인 배포에 적합하지 않으며 무서운 릴리스가 포함 된 대규모 배치 경향이 있습니다.

  • SSIS는 핫스팟 인 SQL을 많이 요구하는 저장 프로 시저의 사용을 촉진합니다. 확장 가능한 상태 비 저장 중간 계층에 대한 요구 사항이있는 디자인을 선호하십시오.

  • 툴링은 투박하고 신뢰할 수 없습니다.

  • 당신은 SSIS에 대한 Microsoft의 로드맵에 달려 있습니다.

  • 데이터가 애플리케이션에 들어 오자마자 분석,보고 및보기를 지원하는 테이블 / 서비스에 쓰기를 고려하십시오. CQRS 및 기타 애플리케이션 아키텍처 패턴을 참조하십시오.

  • Excel을 데이터 소스 로 사용하지 마십시오 . 직원을 교육하십시오.

  • 코드는 왕입니다.

궁극적으로 SSIS는 엔터프라이즈 IT의 유물이라고 생각합니다. "Google이 SSIS를 사용할까요?"라고 묻고 싶습니다. 문제를 어떻게 해결할 수 있습니까? 상자 밖에서 생각하십시오.


당신이하는 일에 달려 있다고 생각합니다. SSIS는 이전 DTS처럼 매우 강력합니다. 많은 항목을로드하고 지속적으로 변경 될 것으로 예상되는 경우 SSIS로 이동합니다. 몇 가지 항목 만로드하려는 경우 많은 고객을위한 것이라면 코드에 넣을 것입니다. 사내 ETL 프로세스에 SSIS를 선호하지만 레거시 시스템에서 SQL 데이터베이스로 데이터를로드해야 할 때 클라이언트 상점에서 .Net을 사용합니다. 이전에 언급했듯이로드 할 변환과 다양한 데이터 사일로가 많으면 .Net에서이 작업을 수행하는 것이 미쳐있을 것이라고 생각하고 SSIS로 이동합니다. 로드 할 항목이 몇 개 밖에없고 단일 애플리케이션 용이고 다양한 클라이언트에서 애플리케이션의 일부로 설치 될 수있는 경우 .Net으로 이동합니다. 내 2 센트.


저는 소규모 프로젝트에서 크고 복잡한 ETL에 이르기까지 SSIS에 대한 많은 경험을 가지고 있습니다. 세부 사항을 다루지 않고 이것은 당신을위한 나의 지침입니다.

  • DBA이고 .NET에 익숙하지 않거나 SSIS에 대해 잘 알고있는 개발자 인 경우 작고 단순하며 상당히 간단한 ETL (추출, 변환,로드) 작업에 SSIS를 사용할 수 있습니다.

  • SSIS는 매우 기발하며 많은 함정, 문제 및 명백한 버그로 간주 될 수있는 것이 있습니다. 당신이 친밀하다면 매우 강력합니다.

  • 이제 C #에는 TPL Dataflow가 있습니다. 간단한 성능 테스트는 SSIS보다 앞서 있습니다. (예 : http://mymemoryleaks.blogspot.cz/2013/10/ssis-vs-tpldataflow.html )

  • 사소한 것 이상의 일을하고 싶고 .NET 기술을 사용할 수 있다면 SSIS 대신 .NET을 사용하십시오.


SSIS에는 다양한 데이터 원본에서 변환을 수행하는 여러 가지 방법이 있으며이를 매우 사용자 지정 가능한 방식으로 함께 연결할 수 있습니다. 그들은 그들을 빠르게 만드는 최적화 기능을 내장했습니다.

.NET을 사용하여 사용자 지정 변환을 만들어 SSIS 작업의 속도와 반복성을 활용할 수도 있습니다.


가장 큰 장점은 전체 프로그래밍 구조를 시각적으로 정의하는 것입니다. SSIS 패키지를 살펴보면 거의 자체 설명이 가능합니다. SSIS와 SQL과의 긴밀한 통합을 통해 백업 예약 및 엄청난 이점을 위해 SQL의 일부가 될 수 있습니다.

많은 데이터 조작을하고 있다면 모두가 설명했듯이 좋은 도구입니다. SQL이 있으면 무료이며 VS 2008 BIDS로 배우기가 매우 쉽습니다.


이 질문에 답하기에는 조금 늦었지만 가치가 있기를 바랍니다.

SSIS는 프로그래밍 언어와 비교할 때 종종 오해를받습니다. SSIS는 프레임 워크 인 반면 C #은 .NET Framework의 언어입니다. (MSBI 제품군)을 사용하여 대규모 데이터웨어 하우징 솔루션을 처리하고 개발하는 데 폭 넓은 경험이 있으며 대규모 웹 사이트 (ASP.NET)도 개발 했으므로 편견을 가질 수 없습니다.

SSIS를 제대로 사용하지 않으면 성능이 저하 될 수 있습니다. SSIS 패키지에는 세 가지 종류의 변환이 있습니다.

  1. 블로킹 변환-위의 변환이 완료되어 모든 행을 가져오고 필요한 계산을 완료 한 경우에만 데이터를 전달할 수 있습니다.
  2. 반 차단 변환-부분 데이터를 전달할 수 있음
  3. 비 차단-준비되는 즉시 행을 처리합니다.

SSIS works exceptionally good with non blocking transformation with proper setting on control flow and data flow. I have used it on larger (over 2 TB of data warehouse) and I can guarantee that it was the fastest load experience. You can check Microsoft blog about We Loaded 1TB in 30 Minutes with SSIS, and So Can You

I agree that SSIS degraded performance when dealing with blocking transformation and they should be carried by T-SQL whenever required.

Coming to C#, I accept that SSIS uses .NET framework and data provider to accomplish task. But C#, as a language is bit more logical and must be treated to deal with business logic. For example, If we have to run exe with different parameter based on condition, you can write a package which will consider parameters and then logically decide what parameter needs to be passed to run an exe file. It would be lengthy process to do that in SSIS while I can do that easily in C# because logical thing can be easily done in language instead of a framework.

Now the point here is what is more convenient approach to solve your problem statement. SSIS is a sure winner loading large amount of records loading data from source to destination while C# is perfect for writing logic. Even if you like C#, I won't recommend you to choose for doing ETL (Extract Transform Load) operation on large data warehouse systems.


SSIS is generally used for ETL (Extract Transform Load). Specific use cases are the pre-processing of SSAS (SQL Server Analysis Services) cubes; and enhanced extraction using Data Change Capture.

It can do typical automation, including FTP, and email. There is the programming aspect using script-tasks (C# or Visual Basic), so SSIS has functionality beyond it's included controls...

Packages can be programmed to use conditional control-flow path. For example, do a certain task Monday thru Friday, and a different task Saturday & Sundays. Or refuse to perform ETL if certain conditions are not met.

SSIS packages can call other SSIS packages. That keeps the code modular, allowing re-use.

It can work with various Data Sources, and perform simple transformation using the Derived Column control. This is versus doing transformation on the source server (which could be Oracle or Hadoop for example- something you don't have control of with your local SQL Server).


As the name suggests, SSIS is an integration system. It can be very difficult in .net to handle connectors to disparate data sources such as excel, teradata, oracle etc and also to live up to the responsibility to gracefully close those connections, garbage collection, handling memory issues.

So, SSIS is out of the box product perfect for scenarios where data not only needs to be pulled from, say, two different sources, but then a series lookups, transformations, merges, derivations and calculations need to be performed before writing it to a target location(be it sql server, a flat file or another db system).

SSIS also has checkpoints where, if the package fails due to any reason, it will pick up from where it left off (it needs to be configured as this is not default behavior).

In addition, SSIS will save you a lot of time because its tasks are reusable and its deployment process is fairly easy to implement and schedule, supported by great event handling.


Basically SSIS has many advantages like splitting data transfer from point A to point B in smaller blocks and debug them in individually, able to access SQL Server Tables easily, work on XML data, API calls using c# scripts and saving data on DB, Read DB data and FTP on remote server and many more.
Apart from bunch of already existing BI blocks, you can also create your own customized tasks with its own parameters and outputs.
Hope I was able to add some points to the already existing answers.


Day-to-Day Tasks , which are used by a SSIS Deveoper and are relatively easy as compared to .Net can include :

Data Comparison between the tables.

Conditional Splitting,data blocking the data on the basis of some logic.

Data Conversion,look up , merge , unionall , relatively easy to use.

File Handling(Modifying , validations).

Error Handing , Email Alerts.

Containers , FOR/FOReach loops are easy to use.

Posting data on web services is easy using the WebService task.

Checkpointing,Re-runablity of the data loads is easy to handle.

Debugging is easy in ssis - can be done on conatiner lever , package level.

Scripting can also be done , if the task is not available. Also , you can customize your own tasks


Whatever folks say in previous answers are correct but I think that the most important aspect of using SSIS instead of coding is to have easy maintenance process and also a reusable product.


SSIS is great for BI applications, you can manipulate the data on Stage Table and than make avaiable on DataWarehouse tables to be used for BI.

I can connect on SAP, Oracle to get employee information and make avaiable on PowerBI, QlikView, etc...

Its a nice tool if you know where and why use it. Use ir because its cool you will have troubles.

참고URL : https://stackoverflow.com/questions/690123/net-vs-ssis-what-should-ssis-be-used-for

반응형