ETL : 200 개의 테이블에서 추출-SSIS 데이터 흐름 또는 사용자 정의 T-SQL?

필자의 분석에 따르면 데이터웨어 하우스의 전체 차원 모델은 200 개가 넘는 소스 테이블에서 추출해야합니다. 이러한 테이블 중 일부는 증분로드의 일부로 추출되고 다른 테이블은 전체로드입니다.

참고로, 동일한 스키마를 가진 약 225 개의 소스 데이터베이스가 있습니다.

내가 본 것에서 OLE DB 소스 및 OLE DB 대상을 사용하여 SSIS에서 간단한 데이터 흐름을 구축하려면 디자인 타임에 열과 데이터 형식을 결정해야합니다. 이것은 결국 추출만으로 200 개가 넘는 데이터 흐름으로 끝날 것임을 의미합니다.

유지 관리 측면에서 볼 때 이것은 큰 문제로 생각됩니다. 추출 코드를 일종의 스위프 방식으로 변경해야하는 경우 200 개의 서로 다른 데이터 흐름을 수정해야합니다.

대안 옵션으로, 메타 데이터 테이블 세트에서 추출하려는 소스 데이터베이스, 테이블 이름 및 열을 읽는 작은 스크립트를 작성했습니다. 코드는 여러 루프에서 실행되며 동적 SQL을 사용하여 연결된 서버 및 OPENQUERY를 통해 소스 테이블에서 추출합니다.

필자의 테스트에 따르면 OLEDB 소스 및 대상과 함께 SSIS 데이터 흐름을 사용하는 것만 큼 빠르지는 않습니다. 그래서 나는 어떤 종류의 대안이 있는지 궁금합니다. 지금까지 생각은 다음과 같습니다.

1. EZAPI 를 사용하여 간단한 데이터 흐름으로 프로그래밍 방식으로 SSIS 패키지 생성 추출 할 테이블과 열은 앞에서 언급 한 것과 동일한 메타 데이터 테이블에서 가져옵니다.
2. 타사 소프트웨어 구매 (동적 데이터 흐름 구성 요소)

이것에 접근하는 가장 좋은 방법은 무엇입니까? .NET 프로그래밍에 관해서는 초보자입니다. 따라서 기본 사항에 맞추기 위해 필요한 시간도 중요합니다.

단일 패키지에서 200 개의 데이터 흐름을 원하지 않습니다. 개봉하고 확인하는 데 걸리는 시간은 시간이 지나기 전에 늙게 만들 것입니다.

EzAPI는 재미 있지만 .NET 및 SSIS를 처음 사용하는 경우 에는 안됩니다. SSIS 개체 모델에 대해 배우고 실제로 작업을 수행하는 것보다 COM을 처리하는 데 훨씬 더 많은 시간을 할애한다고 생각합니다.

게으 르기 때문에 BIML을 나열하지 않은 무료 옵션으로 연결합니다. SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604 에 대한 답변에서

• Biml 은 재미있는 짐승입니다. Varigence는 Mist에 라이센스를 판매하게되어 기쁘지만 필요하지는 않습니다. 당신이 필요로하는 모든입니다 BIDSHelper 다음을 찾아 BimlScript 사용자의 요구에 가까운 조리법과 모습. 그런 다음 BIDSHelper 및 whoosh에서 상황에 맞는 메뉴 버튼을 클릭하면 패키지가 생성됩니다.

나는 그것이 당신에게도 접근 할 수 있다고 생각합니다. 패키지의 작동 방식을 설명하는 BIML을 정의한 후 생성합니다. 이 시나리오에서는 어디에서 변경을 수행하고 N 패키지를 수정해야하는지 설명합니다. 문제의 정의를 수정하고 패키지를 재생성합니다.

또는 프레임 워크에 익숙해지면 EzAPI와 같은 것을 사용하여 깨진 모든 것을 수정하십시오. 이 태그를 2005로 태그 했으므로 기존 패키지를 대량으로 수정해야하는 경우 PacMan 을 사용해 볼 수도 있습니다 .

SSIS 디자인 고려 사항

일반적으로 패키지는 단일 작업 (판매 데이터로드)을 해결하는 데 중점을 둡니다. 2 개의 데이터 흐름이 필요한 경우에도 마찬가지입니다. 상속을 싫어하는 것은 가져 오기 내보내기 마법사의 패키지로 단일 패키지에 많은 관련없는 데이터 흐름이 있습니다. 그것들을 매우 특정한 문제를 해결하는 것으로 분해하십시오. 표면적이 줄어들면 향후 개선 사항의 위험이 줄어 듭니다. 추가 혜택은 DimProducts미니언이로드 SnowflakeFromHell패키지를 처리 하는 동안 로드 작업을 할 수 있다는 것 입니다.

그런 다음 마스터 패키지를 사용하여 하위 워크 플로우를 조정하십시오. 나는 당신이 2005 년에 있다는 것을 알고 있지만 SQL Server 2012의 SSIS 릴리스는 고양이의 잠옷입니다. 나는 프로젝트 배포 모델과 패키지간에 허용되는 긴밀한 통합을 좋아합니다.

TSQL 대 SSIS (내 이야기)

순수한 TSQL 접근 방식은 이전 작업에서 73 단계 작업을 사용하여 모든 Informix 데이터를 SQL Server로 복제했습니다. 일반적으로 약 9 시간이 걸렸지 만 12 시간 정도 늘어날 수있었습니다. 새로운 SAN을 구입 한 후 약 7 시간 이상으로 줄었습니다. SSIS로 다시 작성된 동일한 논리적 프로세스는 일관된 2 시간 미만이었습니다. 그 시간을 단축시키는 가장 쉬운 요인은 SSIS를 사용하여 얻은 "무료"병렬화였습니다. 에이전트 작업은 이러한 모든 작업을 순차적으로 실행했습니다. 마스터 패키지는 기본적으로 테이블을 처리 단위 ( "실행 복제 테이블 1 실행", 테이블 2 등의 5 개의 직렬화 된 일련의 작업 세트)로 나누었습니다. 이로 인해 60 개 정도의 참조 참조 테이블이 빠르게 채워지고 ""에 도달하면 처리 속도가 느려집니다.

SSIS를 사용하는 또 다른 이점은 "자유로운"구성, 로깅 및 둥근 구멍에 bash 해야하는 사각형 데이터의 .NET 라이브러리에 대한 액세스 권한이 있다는 것입니다. 짐승의 그래픽 특성으로 인해 순수한 TSQL 접근 방식보다 SSIS 패키지를 유지 관리하는 것이 더 쉬울 수 있다고 생각합니다.

항상 그렇듯이 마일리지는 다를 수 있습니다.

200 개의 소스 테이블과 225 개의 데이터베이스가 있다고 언급했습니다. 200 개의 소스 테이블이 225 개의 모든 데이터베이스의 모든 테이블 수라고 가정합니다 (각 데이터베이스에 200 개의 테이블이 있으면 총 테이블 수는 45000이됩니다). 또한 데이터베이스의 스키마가 225 개의 데이터베이스와 동일하다고 언급했습니다.

먼저 1 개의 데이터베이스에 대해서만 SSIS 패키지를 구축 한 다음 작업을 예약 할 때 패키지 구성을 사용하여 데이터베이스 연결 문자열을 변경할 수 있습니다 (SQL 2005의 경우 패키지 배포 모델을 사용함). 이전 응답에서 언급했듯이 SQL 2012에는 프로젝트 배포 모델을 사용하여 매개 변수를 구성하는 새로운 방법이 있습니다.

SSIS를 사용하여 패키지 구성에 대한 자세한 내용은 http://www.sql-server-performance.com/2007/package-configuration-2005/를 참조 하십시오 .

/programming/15206184/how-to-configure-ssis-2012-project-to-run-under-different-environment-configurat 에서 프로젝트 매개 변수 사용에 대한 자세한 정보를 얻을 수 있습니다.