2000 년에 SQL Server DTS 패키지로 일부 ETL 개발을 수행했습니다. 디자이너를 사용하여 패키지를 만들었지 만 SQLDMO (Database Mgt Objects) 라이브러리를 사용하여 패키지를 동적으로 생성함으로써 결국 해결되었습니다. 상위 레벨에서 생성 된 패키지는 입력 파일을 읽고 스테이징 테이블로 데이터를 전송합니다. 예상되는 컬럼 데이터 유형을 준수하지 않은 레코드는 오류 레코드로 추출되고 레코드가 유효성 검증에 실패한 이유에 대한 오류 메시지 레코드가 발}되었습니다. 이 코드는 일반적으로 한 번 작성되었습니다.SSIS "불량"데이터를 처리하기위한 권장 사례
데이터를 플랫 CSV 레이아웃 소스 파일에서 테이블의 열이 입력 파일의 열과 일치하는 "형식화되지 않은"dest 테이블로 처음 DTS 변환되었지만 열이 모두 varchar (255)로 정의되었습니다. . 의도는 먼저 원시 데이터를 테이블로 가져 와서 동적으로 생성 된 SQL을 형식화되지 않은 테이블에 대해 실행하여 예상 데이터 유형으로 변환하지 못하는 데이터를 식별 할 수있게하는 것이 었습니다. 잘못된 유형이나 길이의 레코드는 자동으로 입력 파일과 동일한 레이아웃의 오류 테이블로 쫓겨납니다. 그런 다음 공통 처리 라이브러리는 DTS 패키지를 동적으로 생성하여 나머지 레코드를 "유형이 지정된"테이블로 전송합니다. 여기서 모든 열은 varchar가 아닌 예상 된 유형이었습니다. 이러한 모든 테이블은 런타임시에도 예상되는 파일 레이아웃의 정의를 기반으로 동적으로 생성되었습니다.
이 초기 단계 이후에도 데이터가 너무 많았지 만 데이터를 데이터베이스로 가져 와서 "불량"데이터를 확인하고 각 레코드가 나쁜 이유를 기록하는 것은 이번에도 새로운 시스템의 초점이되었습니다. 이번에는 SSIS 패키지. 저는 2000 년에 SQLMO를 사용하여 SSIS 패키지를 생성하고 .NET을 사용하여이 프로세스를 처리 할 공통 라이브러리를 만드는 방법을 생각해 보았습니다. 그러나 나는 다른 사람들이하고있는 일에 대해 조언을 얻고 싶었습니다.
제가 개인적으로 선호하는 도구는 시각적 인 방법을 사용하여 디자이너와 SSIS 패키지를 개발하는 것입니다. 개인적으로 .NET을 사용하여 전체 프로세스를 추상화하고 파일 시스템, SSIS 및 SQL Serve를 활용하면서 풍부한 개발 언어를 사용하는 재사용 가능한 라이브러리를 만드는 데있어 가장 뛰어난 제어 및 최상의 개발 환경을 갖추고 있다고 생각합니다.
필자는 파일 정의를 테이블에 두는 것이 모든 종류의 부수적 인 이점을 갖음을 발견했습니다. 예를 들어, 모든 파일 정의에는 구문 분석에 사용해야하는 파일 형식을 고유하게 식별하는 표준 헤더가 있어야한다고 결정했습니다. 그런 다음 파일의 내용을 표에 표시하고 편집을 허용하거나 DTS 패키지를 동적으로 생성하는 편집기를 작성하여 테이블에 데이터를 전송하여 독립 실행 형 도구로 데이터에 대한 쿼리를 허용했습니다. 또한 파일 레이아웃을 문서로 보여주는 Word 문서를 생성하고 표준 도구에서 지정된 형식의 데이터를 추출하여이를 사용하는 소스 시스템이 데이터를 올바른 형식으로 제공하도록 보장 할 수있는 라이브러리를 만들었습니다.
그래서, 마지막으로, 내 질문 :
- 마이크로 소프트가 잘못된 데이터를 처리하고 처리하는 방법이이 모든 패키지에 바퀴를 개혁하지 않고 수행 할 수 있습니다 것이 좋습니다 않는 방법? 나는 SSIS 신참이다.
-1 : 매우 자주 묻는 질문 –