sql server - suzhou - ETL 임무에 접근하는 방법?




suzhou singapore international school (4)

원본이 크고 잘못 설계된 SQL 2k 데이터베이스와 더 잘 설계된 SQL 2k5 데이터베이스 인 ETL을 수행해야합니다. 나는 SSIS가 갈 길이라고 생각합니다. 누구든지 할 일 목록이나 체크리스트 또는 일들을 잊어 버리지 않도록 조심할 것을 제안 할 수 있습니까? 나중에 뒤쪽에서 나를 물지 않도록 어떻게 접근해야합니까?


글쎄, 나는 회사의 ETL을 개발하고있다.

우리는 SSIS와 협력하고 있습니다. API를 사용하여 자체 dtsx 패키지를 생성하고 빌드하십시오.

SSIS는 오류 관리에 친숙하지 않습니다. 가끔은 "OleDb Error"라는 문맥에서 많은 다른 의미를 가질 수 있습니다.

API 문서를 읽으십시오 (많은 내용이 나와 있지는 않습니다).

거기에서 시작하는 데 도움이되는 몇 가지 링크 : http://technet.microsoft.com/de-de/library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345167.aspx

http://msdn.microsoft.com/en-us/library/ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2551674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki/ComponentErrorCodes.html

http://www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library/ms187670.aspx

http://msdn.microsoft.com/ja-jp/library/microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http://www.sqlis.com/post/Handling-different-row-types-in-the-same-file.aspx

http://technet.microsoft.com/ko-kr/library/ms135967(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms137709(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345164(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms141232.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SSIS/Q_23972361.html

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&PostID=1404157

http://msdn.microsoft.com/en-us/library/aa719592(VS.71).aspx

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&ForumID=80

http://blogs.conchango.com/jamiethomson/archive/2005/06/11/SSIS_3A00_-Custom-Logging-Using-Event-Handlers.aspx

http://blogs.conchango.com/jamiethomson/archive/2007/03/13/SSIS_3A00_-Property-Paths-syntax.aspx

http://search.live.com/results.aspx?q=%s&go=Buscar&form=QBJK&q1=macro%3Ajamiet.ssis

http://toddmcdermid.blogspot.com/2008/09/using-performupgrade.html?showComment=1224715020000

http://msdn.microsoft.com/en-us/library/ms136082.aspx

http://support.microsoft.com/kb/839279/en-us

죄송합니다 "스팸",하지만 그들은 나에게 매우 유용합니다.


나는 ETL 프로세스가 200 개 이상의 분산 데이터베이스에서 매일, 매주, 매월 및 매년 기준으로 중앙 데이터베이스로 데이터를 가져 오는 경험이 있습니다. 그것은 엄청난 양의 데이터이며 우리가 처한 상황과 관련하여 많은 문제가 있습니다. 그러나 내가 보았을 때 상황에 관계없이 생각할 몇 가지 항목이 있습니다.

  • 원본 및 대상 모두에서 파일 잠금을 고려해야합니다. 다른 프로세스가 파일을 잠그지 않았는지 확인하고 필요한 경우 잠금을 제거하고 이해하는 것이 중요합니다.

  • 너 자신을 위해 파일을 잠그고. 특히 소스에서 파일을 잠그는 동안 데이터를 가져 와서 업데이트 된 데이터의 절반을 얻지 못하게하십시오.

  • 가능한 모든 데이터가 아니라 델타를 가져옵니다. 데이터 사본을 가져온 다음 모든 항목 대신 변경된 행만 가져옵니다. 데이터 세트가 클수록 더 중요 해집니다. 필 요하면 저널 및 트리거를 살펴보십시오. 그러나 특정 기준에 따라이 데이터를 보유하는 것이 더 중요 해지면 이것이 아마도 제가 당신에게 줄 수있는 최고의 조언 일 것입니다. 프로젝트에 상당한 시간을 추가하더라도.

  • 실행 로그. 그것이 효과가 있었는지, 언제 작동하지 않았는지를 알고 있는지 확인하고 프로세스의 특정 오류를 던지면 디버깅에 실제로 도움이 될 수 있습니다.

  • 문서, 문서, 문서. 당신이이 권리를 쌓는다면, 당신은 그것을 구축하고 그것을 오랫동안 생각하지 않을 것입니다. 그러나 당신은 보장 할 수 있습니다, 당신이나 다른 누군가가 그것을 강화하거나 버그 수정을 위해 어느 시점에서 다시 와야 할 것입니다. 이러한 상황에서는 문서화가 중요합니다.

HTH, 내가 다른 것을 생각하면 아프다.


이 스레드는 오래되었지만 ConcernedOfTunbridgeWells의 대답에주의를 환기시키고 싶습니다. 그것은 모든 점에서 매우 훌륭한 조언입니다. 나는 몇 가지를 되풀이 할 수는 있지만 나머지는 줄어들 것입니다. 그리고 그들은 모두 가깝게 공부할 자격이 있습니다.


일반적인 ETL 팁

  1. 대상을 기준으로 구성하는 것을 고려하십시오. 예를 들어, Customer 차원을 생성하는 모든 코드는 소스에 관계없이 동일한 모듈에 있습니다. 이는 주제 중심 ETL이라고도합니다. 물건을 찾는 것이 훨씬 쉬우 며 코드의 유지 보수성이 향상됩니다.

  2. SQL2000 데이터베이스가 복잡하다면 SSIS 데이터 흐름이 데이터를 처리하기에 어색한 방법이라는 것을 알게 될 것입니다. 일반적으로 ETL 도구는 복잡성으로 인해 확장이 어렵습니다. 금융 회사의 모든 데이터웨어 하우스 프로젝트 중 절반은 명시 적 아키텍처 결정으로 저장 프로 시저 코드로 수행됩니다. 정확하게이 이유 때문입니다. sprocs에 많은 양의 코드를 넣어야하는 경우 모든 코드를 sprocs에 두는 것을 고려하십시오.

    복잡한 스크러빙이나 변형이 많은 시스템의 경우, 모든 변환과 비즈니스 로직을 한 곳에 모으는 유일한 방법은 100 % sproc 접근법입니다. 혼합 ETL / sproc 시스템을 사용하면 전체 변환을 추적, 문제 해결, 디버그 또는 변경하기 위해 여러 위치를 조사해야합니다.

  3. ETL 도구의 가장 좋은 점은 상대적으로 간단한 변환으로 더 많은 수의 데이터 소스를 사용하는 시스템에 있습니다.

  4. 코드를 테스트 할 수있게 만들면 구성 요소를 따로 분리하여 테스트 할 수 있습니다. ETL 도구에서 복잡한 데이터 흐름의 중간에서 실행될 수있는 코드는 테스트하기가 훨씬 더 어렵습니다.

  5. 비즈니스 로직없이 데이터를 바보로 만들고 준비 영역으로 복사하십시오. 비즈니스 논리가 추출 및 변환 계층에 퍼져있는 경우 별도로 테스트 할 수없는 변형이 발생하고 버그를 추적하기가 어려워집니다. 변환이 스테이징 영역에서 실행되는 경우 원본 시스템에 대한 강력한 종속성이 줄어들어 다시 테스트 가능성이 향상됩니다. 이것은 거의 완전히 동질적인 코드 기반을 허용하기 때문에 sproc 기반 아키텍처에서 특히 유리합니다.

  6. 천천히 변화하는 일반적인 치수 처리기를 만들거나 가능한 경우 선반에서 꺼냅니다. 이렇게하면이 기능을 단위 테스트하기가 더 쉬워집니다. 이것이 단위 테스트가 될 수 있다면 시스템 테스팅은 모든 모서리 사례를 테스트 할 필요가 없습니다. 단지 제시된 데이터가 정확한지 여부입니다. 이것은 소리가 나는 것처럼 복잡하지 않습니다. 제가 작성한 마지막 문장은 600 줄 또는 700 줄의 T-SQL 코드입니다. 일반 스크러빙 기능에도 동일하게 적용됩니다.

  7. 가능한 경우 점진적으로로드하십시오.

  8. 귀하의 코드를 계측하십시오 - 로그 엔트리를 만드십시오. 아마도 합계 또는 수표와 같은 진단을 기록하십시오. 이것이 없으면 문제 해결은 불가능합니다. 또한 어설 션 검사는 오류 처리를 생각하는 좋은 방법입니다 (b의 행 수가 동일하면 A : B 관계는 실제로 1 : 1입니다).

  9. 합성 키를 사용하십시오. 소스 시스템의 자연 키를 사용하면 시스템이 데이터 소스에 연결되므로 추가 소스를 추가하기가 어려워집니다. 시스템의 키와 관계는 항상 정렬되어야하며 null이 없어야합니다. '기록되지 않음'오류의 경우 차원 테이블에 특정 '오류'또는 '기록되지 않은'항목을 작성하고 일치시킵니다.

  10. 운영 데이터 저장소 (많은 종교 전쟁의 대상)를 구축하면 스타 스키마의 ODS 키를 재활용하지 마십시오. 꼭 ODS 키에 가입하여 차원을 구성하지만 자연스러운 키와 일치시킵니다. 이를 통해 스타 스키마를 방해하지 않고 임의로 ODS를 삭제하고 다시 구조를 변경할 수 있습니다. ODS 구조를 변경하거나 언제 어디서나 ODS를 무차별 재배포 할 수 있기 때문에이 기능을 보유하면 진정한 유지 보수가 가능합니다.

1-2 점과 4-5 점은 특정 하위 시스템 (예 : 단일 차원 또는 팩트 테이블)에 대한 모든 코드가 시스템의 단 하나의 장소에 존재하는 시스템을 구축 할 수 있음을 의미합니다. 이러한 유형의 아키텍처는 더 많은 수의 데이터 소스에 적합합니다.

포인트 3은 포인트 2에 대한 대위법입니다. 기본적으로 SQL과 ETL 툴링 사이의 선택은 변환의 복잡성과 소스 시스템의 수의 함수입니다. 데이터가 간단하고 데이터 소스 수가 많을수록 도구 기반 접근 방식의 경우가 강해집니다. 데이터가 복잡할수록 저장 프로 시저를 기반으로하는 아키텍처로 이동하는 경우가 더 강력합니다. 일반적으로 독점적으로 또는 거의 독점적으로 하나 또는 둘 다를 사용하는 것이 낫지 만 둘 다를 사용하지 않는 것이 좋습니다.

포인트 6은 시스템을 테스트하기 쉽게 만듭니다. SCD 또는 변경 기반 기능을 테스트하는 것은 여러 버전의 소스 데이터를 시스템에 제공 할 수 있어야하기 때문에 까다로운 작업입니다. 변경 관리 기능을 인프라 코드로 옮기면 테스트 데이터 세트를 사용하여 별도로 테스트 할 수 있습니다. 이는 시스템 테스트 요구 사항의 복잡성을 줄이므로 테스트에서 승리합니다.

포인트 7은 대규모 데이터 볼륨을 관찰하는 데 필요한 일반 성능 정보입니다. 시스템의 일부분 만 증분 로딩이 필요할 수도 있습니다. 더 작은 참조 테이블과 치수는 필요하지 않을 수 있습니다.

포인트 8은 헤드리스 프로세스와 밀접한 관련이 있습니다. 밤에 가슴이 뻐근 해지면 다음날 무슨 일이 잘못되었는지 보는 기회가 필요합니다. 코드가 무슨 일이 일어나고 있는지를 제대로 기록하지 못하면 오류를 잡아내는 것이 훨씬 어렵습니다.

포인트 9는 데이터웨어 하우스에 고유 한 수명을 제공합니다. 웨어 하우스에 자체 키가있는 경우 소스 시스템을 쉽게 추가하고 h 제할 수 있습니다. 천천히 변화하는 차원을 구현하려면웨어 하우스 키가 필요합니다.

새로운 시스템을 추가하거나 레코드의 카디널리티를 변경해야하는 경우 ODS를 다시 구조화 할 수 있으므로 Point 10은 유지 관리 및 배포에서 유리합니다. 또한 ODS 키에 종속되지 않고 ODS의 여러 위치에서 차원을로드 할 수 있습니다 (수동 회계 조정 추가).





etl