what is etl extract
이 ETL 프로세스에 대한 심층 자습서에서는 데이터웨어 하우스의 ETL (추출, 변환 및로드) 프로세스와 관련된 프로세스 흐름 및 단계를 설명합니다.
시리즈의이 자습서에서는 다음을 설명합니다. ETL 프로세스 란? 데이터 추출, 변환,로드, 플랫 파일, 스테이징이란? ETL주기 등
시작하자!!
=> 여기에서 완벽한 데이터웨어 하우징 교육 가이드를 확인하십시오.
학습 내용 :
ETL (추출, 변환,로드) 프로세스 기본 사항
대상 청중
- 데이터웨어 하우스 / ETL 개발자 및 테스터.
- 데이터베이스 개념에 대한 기본 지식이있는 데이터베이스 전문가.
- 데이터웨어 하우스 / ETL 영역을 이해하고자하는 데이터베이스 관리자 / 빅 데이터 전문가.
- 데이터웨어 하우스 일자리를 찾고있는 대학 졸업자 / 신입생.
데이터웨어 하우스의 ETL 프로세스는 무엇입니까?
우리 모두는 데이터웨어 하우스가 비즈니스 인텔리전스 도구의 도움을 받아 비즈니스 사용자에게 정보를 제공하는 방대한 양의 데이터 모음이라는 것을 알고 있습니다.
이를 위해 DW는 정기적으로로드되어야합니다. 시스템으로의 데이터는 하나 이상의 운영 체제, 플랫 파일 등에서 수집됩니다. 데이터를 DW로 가져 오는 프로세스를 ETL 프로세스라고합니다. . 추출, 변환 및로드는 ETL의 작업입니다.
# 1) 추출 : 데이터베이스, 애플리케이션 및 플랫 파일과 같은 다양한 소스 시스템의 모든 기본 데이터가 식별되고 추출됩니다. 업무 외 시간에 작업을 실행하여 데이터 추출을 완료 할 수 있습니다.
# 2) 변환 : 추출 된 데이터의 대부분은 대상 시스템에 직접로드 할 수 없습니다. 비즈니스 규칙에 따라 데이터를로드하기 전에 일부 변환을 수행 할 수 있습니다.
예를 들어, 대상 열 데이터는 두 개의 소스 열이 연결된 데이터를 입력으로 예상 할 수 있습니다. 마찬가지로 전문 지식이 필요한 데이터 변환을위한 복잡한 논리가있을 수 있습니다. 변환이 필요하지 않은 일부 데이터는 대상 시스템으로 직접 이동할 수 있습니다.
변환 프로세스는 또한 데이터를 수정하고 잘못된 데이터를 제거하며 데이터를로드하기 전에 데이터의 오류를 수정합니다.
# 3) 로딩 : 수집 된 모든 정보는 대상 데이터웨어 하우스 테이블에로드됩니다.
데이터 추출
데이터 추출은 성공적인 DW 시스템 설계에 중요한 역할을합니다. 소스 시스템마다 데이터의 특성이 다를 수 있으며 ETL 프로세스는 데이터를 추출하는 동안 이러한 차이를 효과적으로 관리합니다.
' 논리 데이터 맵 ”는 데이터 추출을위한 기본 문서입니다. 이는 어떤 소스 데이터가 어떤 대상 테이블로 이동해야하는지, 그리고 소스 필드가 ETL 프로세스의 각 대상 테이블 필드에 매핑되는 방식을 보여줍니다.
다음은 논리 데이터 맵 설계 중에 수행해야하는 단계입니다.
- 데이터웨어 하우스 설계자는 논리적 데이터 맵 문서를 디자인합니다.
- 이 문서를 참조하여 ETL 개발자는 ETL 작업을 생성하고 ETL 테스터는 테스트 케이스를 생성합니다.
- 비즈니스 의사 결정을 지원하는 모든 특정 데이터 소스와 각 데이터 요소가이 문서에서 언급됩니다. 이러한 데이터 요소는 추출 프로세스 중에 입력으로 작동합니다.
- 모든 소스 시스템의 데이터가 분석되고 모든 종류의 데이터 이상이 문서화되어 잘못된 데이터를 DW로 추출하지 못하도록 올바른 비즈니스 규칙을 설계하는 데 도움이됩니다. 이러한 데이터는 여기서 자체적으로 거부됩니다.
- ETL 설계자와 비즈니스 분석가가 최종 소스 및 대상 데이터 모델을 설계하면 ETL 개발자 및 테스터와 함께 안내 할 수 있습니다. 이를 통해 추출, 변환 및로드의 각 단계에서 비즈니스 규칙을 수행하는 방법을 명확하게 이해할 수 있습니다.
- 이 문서의 매핑 규칙을 살펴보면 ETL 설계자, 개발자 및 테스터는 각 테이블에서 차원, 팩트 및 기타 테이블로 데이터가 흐르는 방식을 잘 이해하고 있어야합니다.
- 잘못된 데이터 추출을 방지하기 위해 모든 종류의 데이터 조작 규칙 또는 공식도 여기에 언급됩니다. 예를 들면 최근 40 일 동안의 데이터 만 추출합니다.
- DW에로드 할 모든 유용한 소스 시스템, 테이블 및 열 데이터를 가져 오기 위해 비즈니스 요구 사항에 따라 데이터를 드릴 다운하는 것은 ETL 팀의 책임입니다.
논리 데이터 맵 문서는 일반적으로 다음 구성 요소를 보여주는 스프레드 시트입니다.
( ''표를 찾을 수 없음 /)추출 흐름도 :
추출주기 동안 소스 데이터가 누락되지 않도록 미리 각 소스 시스템에 작업을 실행하는 시간 창에 대해 설명합니다.
위의 단계를 통해 추출은 다양한 소스의 다양한 형식의 데이터를 단일 DW 형식으로 변환하는 목표를 달성하여 전체 ETL 프로세스에 도움이됩니다. 이러한 논리적으로 배치 된 데이터는 더 나은 분석에 더 유용합니다.
데이터웨어 하우스의 추출 방법
원본 및 대상 데이터 환경과 비즈니스 요구 사항에 따라 DW에 적합한 추출 방법을 선택할 수 있습니다.
# 1) 논리적 추출 방법
데이터웨어 하우스 시스템에서 데이터 추출은 처음에 수행되는 일회성 전체로드 일 수 있습니다 (또는 지속적 업데이트로 매번 발생하는 증분로드 일 수 있음).
Java에서 float를 사용하는 방법
- 전체 추출 : 이름 자체에서 알 수 있듯이 소스 시스템 데이터는 대상 테이블로 완전히 추출됩니다. 이러한 종류의 추출이 마지막으로 추출 된 타임 스탬프를 고려하지 않고 전체 현재 소스 시스템 데이터를로드 할 때마다. 가급적이면 데이터가 적은 테이블이나 초기로드에 대해 전체 추출을 사용할 수 있습니다.
- 증분 추출 : 특정 날짜부터 추가 / 수정 된 데이터는 증분 추출 대상으로 간주됩니다. 이 날짜는 마지막 추출 된 날짜 (또는) 마지막 주문 날짜 등과 같이 비즈니스에 따라 다릅니다. 소스 테이블 자체에서 타임 스탬프 열을 참조하거나 추출 날짜 세부 정보 만 추적하기 위해 별도의 테이블을 만들 수 있습니다. 타임 스탬프를 참조하는 것은 증분 추출 중에 중요한 방법입니다. 타임 스탬프가없는 논리는 DW 테이블에 큰 데이터가있는 경우 실패 할 수 있습니다.
# 2) 물리적 추출 방법
소스 시스템의 기능과 데이터의 한계에 따라 소스 시스템은 온라인 추출 및 오프라인 추출로 추출 할 데이터를 물리적으로 제공 할 수 있습니다. 이는 모든 논리적 추출 유형을 지원합니다.
- 온라인 추출 :: 연결 문자열을 사용하여 모든 소스 시스템 데이터베이스에 직접 연결하여 소스 시스템 테이블에서 직접 데이터를 추출 할 수 있습니다.
- 오프라인 추출 :: 여기서는 소스 시스템 데이터베이스에 직접 연결하지 않고 대신 소스 시스템이 미리 정의 된 구조로 데이터를 명시 적으로 제공합니다. 소스 시스템은 플랫 파일, 덤프 파일, 아카이브 로그 및 테이블 스페이스의 형태로 데이터를 제공 할 수 있습니다.
ETL 도구는 비용이 많이 들지만 DW에 대해 여러 번 복잡한 데이터 추출을 수행하는 데 가장 적합합니다.
변경된 데이터 추출
초기로드가 완료되면 소스 시스템에서 변경된 데이터를 추가로 추출하는 방법을 고려하는 것이 중요합니다. ETL 프로세스 팀은 프로젝트 자체를 시작할 때 초기로드 및 증분로드에 대한 추출을 구현하는 방법에 대한 계획을 설계해야합니다.
대부분의 경우 데이터 변경 사항을 캡처하기 위해 증분로드에 대한 '감사 열'전략을 고려할 수 있습니다. 일반적으로 소스 시스템 테이블에는 각 삽입 (또는) 수정에 대한 타임 스탬프를 저장하는 감사 열이 포함될 수 있습니다.
타임 스탬프는 애플리케이션 자체의 데이터베이스 트리거 (또는)에 의해 채워질 수 있습니다. 증분로드에 대해 변경된 데이터를 놓치지 않도록 감사 열의 데이터가 어떤 방식 으로든로드 되더라도 정확성을 보장해야합니다.
증분로드 중에 마지막로드가 발생한 최대 날짜 및 시간을 고려하고 마지막로드 타임 스탬프보다 큰 타임 스탬프를 사용하여 소스 시스템에서 모든 데이터를 추출 할 수 있습니다.
데이터를 추출하는 동안 :
- 쿼리를 최적으로 사용하여 필요한 데이터 만 검색하십시오.
- 쿼리 성능을 저하 시키므로 Distinct 절을 많이 사용하지 마십시오.
- Union, Minus, Intersect와 같은 SET 연산자는 성능을 저하 시키므로 신중하게 사용하십시오.
- substr (), to_char () 등과 같은 함수보다는 like, between 등과 같은 비교 키워드를 where 절에 사용하십시오.
데이터 변환
변환은 소스 시스템 데이터를 대상 시스템에 직접로드하기 전에 추출 된 데이터에 일련의 규칙을 적용하는 프로세스입니다. 추출 된 데이터는 원시 데이터로 간주됩니다.
일련의 표준을 사용하는 변환 프로세스는 다양한 소스 시스템의 모든 이기종 데이터를 DW 시스템의 사용 가능한 데이터로 가져옵니다. 데이터 변환은 데이터의 품질을 목표로합니다. 모든 논리적 변환 규칙에 대한 데이터 매핑 문서를 참조 할 수 있습니다.
소스 데이터가 지침을 충족하지 않는 경우 변환 규칙에 따라 이러한 소스 데이터는 대상 DW 시스템에로드되기 전에 거부되고 거부 파일 또는 거부 테이블에 배치됩니다.
소스에서 대상으로의 직선로드 열 데이터 (변경할 필요 없음)에 대해 변환 규칙이 지정되지 않았습니다. 따라서 데이터 변환은 단순하고 복잡한 것으로 분류 할 수 있습니다. 데이터 변환에는 열 변환, 데이터 구조 재 형식화 등이 포함될 수 있습니다.
다음은 데이터 변환 중에 수행해야하는 몇 가지 작업입니다.
# 1) 선택 : 소스 시스템에서 전체 테이블 데이터 또는 특정 열 데이터 세트를 선택할 수 있습니다. 데이터 선택은 일반적으로 추출 자체에서 완료됩니다.
소스 시스템이 추출 단계에서 특정 열 데이터 세트를 선택하는 것을 허용하지 않은 경우 전체 데이터를 추출하고 변환 단계에서 선택을 수행 할 수 있습니다.
# 2) 분할 / 결합 : 선택한 데이터를 분할하거나 결합하여 조작 할 수 있습니다. 변환하는 동안 선택한 소스 데이터를 더 많이 분할하라는 메시지가 표시됩니다.
예를 들면 전체 주소가 소스 시스템의 하나의 큰 텍스트 필드에 저장되는 경우 DW 시스템은 주소를 도시, 주, 우편 번호 등의 별도 필드로 분할하도록 요청할 수 있습니다. 이는 각 주소를 기반으로 색인화 및 분석이 쉽습니다. 구성 요소를 개별적으로.
두 개 이상의 열 데이터 결합 / 병합은 DW 시스템의 변환 단계에서 널리 사용됩니다. 이것은 두 필드를 단일 필드로 병합하는 것을 의미하지 않습니다.
예를 들어, 특정 엔티티에 대한 정보가 여러 데이터 소스에서 오는 경우 정보를 단일 엔티티로 수집하는 것을 데이터 결합 / 병합이라고 할 수 있습니다.
# 3) 변환 : 추출 된 소스 시스템 데이터는 각 데이터 유형에 대해 다른 형식 일 수 있으므로 추출 된 모든 데이터는 변환 단계에서 표준화 된 형식으로 변환되어야합니다. 같은 종류의 형식은 이해하기 쉽고 비즈니스 결정에 사용하기 쉽습니다.
# 4) 요약 : 경우에 따라 DW는 소스 시스템에서 낮은 수준의 세부 데이터가 아닌 요약 된 데이터를 찾습니다. 낮은 수준의 데이터는 비즈니스 사용자의 분석 및 쿼리에 가장 적합하지 않기 때문입니다.
예를 들면 모든 체크 아웃에 대한 판매 데이터는 DW 시스템에서 필요하지 않을 수 있으며, 매장의 일일 판매 부산물 (또는) 일일 판매가 유용합니다. 따라서 비즈니스 요구 사항에 따라 변환 단계에서 데이터 요약을 수행 할 수 있습니다.
# 5) 강화 : 여러 레코드에서 하나 이상의 열을 결합하여 DW 열이 형성되면 데이터 강화는 DW 시스템에서 데이터를 더 잘 볼 수 있도록 필드를 다시 정렬합니다.
# 6) 형식 수정 : 형식 수정은 변환 단계에서 가장 자주 발생합니다. 데이터 유형과 길이는 각 열에 대해 수정됩니다.
예를 들면 한 소스 시스템의 열은 숫자 일 수 있고 다른 소스 시스템의 동일한 열은 텍스트 일 수 있습니다. 이를 표준화하기 위해 변환 단계에서이 열의 데이터 유형이 텍스트로 변경됩니다.
# 7) 필드 디코딩 : 여러 소스 시스템에서 데이터를 추출 할 때 다양한 시스템의 데이터가 다르게 디코딩 될 수 있습니다.
예를 들면 하나의 소스 시스템은 고객 상태를 AC, IN 및 SU로 나타낼 수 있습니다. 다른 시스템은 1, 0 및 -1과 동일한 상태를 나타낼 수 있습니다.
데이터 변환 단계에서 이러한 코드를 비즈니스 사용자가 이해할 수있는 적절한 값으로 디코딩해야합니다. 따라서 위 코드는 Active, Inactive 및 Suspended로 변경할 수 있습니다.
# 8) 계산 및 파생 값 : 소스 시스템 데이터를 고려하여 DW는 계산을 위해 추가 열 데이터를 저장할 수 있습니다. DW에 저장하기 전에 비즈니스 로직을 기반으로 계산을 수행해야합니다.
# 9) 날짜 / 시간 변환 : 이것은 집중해야 할 주요 데이터 유형 중 하나입니다. 날짜 / 시간 형식은 여러 소스 시스템에서 다를 수 있습니다.
예를 들면 한 소스는 1997 년 11 월 10 일로 날짜를 저장할 수 있습니다. 다른 소스는 1997 년 11 월 10 일 형식으로 동일한 날짜를 저장할 수 있습니다. 따라서 데이터 변환 중에 모든 날짜 / 시간 값을 표준 형식으로 변환해야합니다.
# 10) 중복 제거 : 소스 시스템에 중복 레코드가있는 경우 하나의 레코드 만 DW 시스템에로드되었는지 확인하십시오.
변환 흐름도 :
변환을 구현하는 방법?
데이터 변환의 복잡성에 따라 수동 방법, 변환 도구 (또는) 둘 중 효과적인 방법의 조합을 사용할 수 있습니다.
# 1) 수동 기법
수동 기술은 소규모 DW 시스템에 적합합니다. 데이터 분석가와 개발자는 데이터를 수동으로 변환하는 프로그램과 스크립트를 만듭니다. 이 방법은 코드의 모든 부분에 대한 자세한 테스트가 필요합니다.
데이터 양의 증가에 따른 오류 발생 가능성으로 인해 비즈니스 규칙 (또는)에서 발생하는 변경으로 인해 유지 관리 비용이 높아질 수 있습니다. 처음에는 메타 데이터를 처리해야하며 변환 규칙에서 발생하는 모든 변경 사항도 처리해야합니다.
# 2) 변환 도구
대부분의 변환 프로세스를 자동화하려는 경우 프로젝트에 사용할 수있는 예산 및 시간 프레임에 따라 변환 도구를 채택 할 수 있습니다. 자동화하는 동안 도구를 선택하고 구성, 설치 및 DW 시스템과 통합하는 데 좋은 시간을 투자해야합니다.
도구 자체를 사용한 실질적인 완전한 변환은 수동 개입 없이는 불가능합니다. 그러나 도구로 변환 된 데이터는 확실히 효율적이고 정확합니다.
이를 위해 적절한 매개 변수, 데이터 정의 및 규칙을 변환 도구에 입력으로 입력해야합니다. 제공된 입력에서 도구 자체가 메타 데이터를 기록하고이 메타 데이터가 전체 DW 메타 데이터에 추가됩니다.
비즈니스 규칙에 변경 사항이있는 경우 해당 변경 사항을 도구에 입력하기 만하면 나머지 변환 수정 사항은 도구 자체에서 처리됩니다. 따라서 두 가지 방법의 조합을 사용하는 것이 효율적입니다.
데이터 로딩
추출 및 변환 된 데이터는 ETL 프로세스의로드 단계 중에 대상 DW 테이블에로드됩니다. 비즈니스는 각 테이블에 대해로드 프로세스가 발생하는 방식을 결정합니다.
로드 프로세스는 다음과 같은 방법으로 발생할 수 있습니다.
- 초기로드 : 데이터를로드하여 처음으로 각 DW 테이블을 채 웁니다.
- 증분 부하 : DW 테이블이로드되면 진행중인 나머지 변경 사항이 주기적으로 적용됩니다.
- 완전 새로 고침 : 사용중인 테이블을 새로 고쳐야하는 경우 해당 테이블의 현재 데이터가 완전히 제거 된 다음 다시로드됩니다. 다시로드는 초기로드와 유사합니다.
ETL의로드 프로세스를 더 잘 이해하려면 아래 예를 참조하십시오.
제품 ID | 상품명 | 판매 일 |
---|---|---|
1 | 문법 책 | 2007 년 6 월 3 일 |
두 | 채점자 | 2007 년 6 월 3 일 |
삼 | 백 백 | 2007 년 6 월 4 일 |
4 | 캡 | 2007 년 6 월 4 일 |
5 | 신발 | 2007 년 6 월 5 일 |
#1) 초기로드시 3에 판매 된 데이터rd위 테이블의 초기 데이터이므로 2007 년 6 월 DW 대상 테이블에로드됩니다.
#두) 증분로드 중에는 3 일 이후에 판매되는 데이터를로드해야합니다.rd2007 년 6 월. 판매 날짜가 다음 날 이전 날짜 (>)보다 큰 모든 레코드를 고려해야합니다. 따라서 4일2007 년 6 월, 판매 날짜가 3보다 큰 모든 레코드를 가져옵니다.rd2007 년 6 월 쿼리를 사용하여 위의 테이블에서 두 레코드 만로드합니다.
5에일2007 년 6 월, 판매 날짜가 4보다 큰 모든 레코드 가져 오기일2007 년 6 월 및 위 표에서 하나의 레코드 만로드합니다.
#삼) 전체 새로 고침 중에 위의 모든 테이블 데이터는 판매 날짜에 관계없이 한 번에 DW 테이블에로드됩니다.
로드 된 데이터는 각 차원 (또는) 팩트 테이블에 저장됩니다. 데이터는 다음과 같이 DW 테이블에로드, 추가 또는 병합 할 수 있습니다.
# 4) 부하 : 데이터가 비어있는 경우 대상 테이블에로드됩니다. 테이블에 일부 데이터가있는 경우 기존 데이터가 제거 된 다음 새 데이터로로드됩니다.
예를 들면
기존 테이블 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 리드 |
단발 | 대리 |
Ronald | 개발자 |
변경된 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
로한 | 감독 |
체탄 | AVP |
그만큼 | VP |
로드 후 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
로한 | 감독 |
체탄 | AVP |
그만큼 | VP |
# 5) 추가 : Append는 이미 데이터가있는 기존 테이블에서 작동하므로 위의로드를 확장 한 것입니다. 대상 테이블에서 Append는 기존 데이터에 더 많은 데이터를 추가합니다. 입력 데이터와 함께 중복 레코드가 발견되면 중복으로 추가되거나 거부 될 수 있습니다.
예를 들어,
기존 테이블 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 리드 |
변경된 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
로한 | 감독 |
체탄 | AVP |
그만큼 | VP |
추가 후 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 리드 |
로한 | 감독 |
체탄 | AVP |
그만큼 | VP |
# 6) 파괴적인 병합 : 여기서 들어오는 데이터는 기본 키를 기반으로 기존 대상 데이터와 비교됩니다. 일치하는 항목이 있으면 기존 대상 레코드가 업데이트됩니다. 일치하는 항목이 없으면 새 레코드가 대상 테이블에 삽입됩니다.
예를 들어,
기존 테이블 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 리드 |
변경된 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 감독 |
체탄 | AVP |
그만큼 | VP |
건설적 병합 후 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 감독 |
체탄 | AVP |
그만큼 | VP |
# 7) 건설적인 간다 : 파괴적 병합과 달리 기존 레코드와 일치하는 항목이 있으면 기존 레코드를 그대로두고 들어오는 레코드를 삽입하고 해당 기본 키에 대한 최신 데이터 (타임 스탬프)로 표시합니다.
예를 들면
기존 테이블 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 리드 |
변경된 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 감독 |
체탄 | AVP |
그만큼 | VP |
건설적 병합 후 데이터
직원 이름 | 역할 |
---|---|
남자 | 매니저 |
Revanth | 감독*** |
Revanth | 리드 |
체탄 | AVP |
그만큼 | VP |
기술적으로 새로 고침은 데이터를 업데이트하는 것보다 쉽습니다. 업데이트에는 특정 변경 사항 만 추출하여 DW 시스템에 적용하는 특별한 전략이 필요하지만 새로 고침은 데이터 만 대체합니다. 그러나 데이터 새로 고침은 데이터 볼륨에 따라 더 오래 걸립니다.
매일 실행할 이러한 새로 고침 작업이있는 경우 데이터를로드하려면 DW 시스템을 종료해야 할 수 있습니다. 매번 데이터를로드하기 위해 전체 DW 시스템을 다운시키는 대신 몇 개의 파일 형태로 데이터를 분할하고로드 할 수 있습니다.
테스트하는 동안 각로드의 실행 시간을 기록해 둡니다. 키 불일치 등으로 인해 데이터를 DW 시스템에로드 할 수없는 경우 이러한 종류의 데이터를 처리 할 수있는 방법을 제공하십시오. 로드 된 데이터를 철저히 테스트해야합니다.
로딩 흐름도 :
플랫 파일
플랫 파일은 서로 다른 소스 운영 체제 및 서로 다른 소스 데이터베이스 시스템에서 데이터웨어 하우스 애플리케이션으로 이기종 시스템간에 데이터를 교환하는 데 널리 사용됩니다. 플랫 파일은 동종 시스템에서도 가장 효율적이고 관리하기 쉽습니다.
플랫 파일은 주로 다음 용도로 사용됩니다.
# 1) 소스 데이터 제공 : 보안상의 이유로 DW 사용자가 데이터베이스에 액세스하는 것을 허용하지 않는 소스 시스템이 거의 없을 수 있습니다. 이러한 경우 데이터는 플랫 파일을 통해 전달됩니다.
마찬가지로 데이터는 기본적으로 플랫 파일 형식으로 외부 공급 업체 또는 메인 프레임 시스템에서 가져 오며 ETL 사용자가 FTP를 통해 제공합니다.
# 2) 작업 / 준비 테이블 : ETL 프로세스는 내부 용도로 스테이징 테이블을 생성합니다. 파일 시스템에 대한 읽기 및 쓰기가 데이터베이스를 삽입하고 쿼리하는 것보다 빠르기 때문에 스테이징 테이블과 플랫 파일의 연관은 DBMS보다 훨씬 쉽습니다.
# 3) 벌크로드 준비 : 추출 및 변환 프로세스가 완료되면 인스 트림 대량로드가 ETL 도구에서 지원되지 않는 경우 (또는) 데이터를 아카이브하려는 경우 플랫 파일을 생성 할 수 있습니다. 이 플랫 파일 데이터는 프로세서에서 읽고 데이터를 DW 시스템에로드합니다.
플랫 파일은 '고정 길이 플랫 파일'과 '구분 된 플랫 파일'의 두 가지 방법으로 만들 수 있습니다. 플랫 파일은 소스 시스템에서 작업하는 프로그래머가 만들 수 있습니다.
이러한 플랫 파일을 어떻게 처리하는지 살펴 보겠습니다.
고정 길이 플랫 파일 처리
일반적으로 플랫 파일은 고정 길이 열이므로 위치 플랫 파일이라고도합니다. 다음은 파일에서 정확한 필드와 위치를 보여주는 플랫 파일의 레이아웃입니다.
분야 명 | 길이 | 스타트 | 종료 | 유형 | 코멘트 |
---|---|---|---|---|---|
이름 | 10 | 1 | 10 | 본문 | 고객의 이름 |
중간 이름 | 5 | 열한 | 열 다섯 | 본문 | 고객의 중간 이름 |
성 | 10 | 16 | 25 | 본문 | 고객의 성 |
레이아웃에는 필드 이름, 길이, 시작 위치 필드 문자가 시작되는 위치, 필드 문자가 끝나는 끝 위치, 텍스트, 숫자 등의 데이터 유형 및 주석 (있는 경우).
데이터 위치에 따라 ETL 테스트 팀은 고정 길이 플랫 파일에서 데이터의 정확성을 검증합니다.
구분 된 플랫 파일 처리
구분 된 플랫 파일에서 각 데이터 필드는 구분 기호로 구분됩니다. 이 구분 기호는 각 필드의 시작 및 끝 위치를 나타냅니다. 일반적으로 쉼표는 구분 기호로 사용되지만 다른 기호 나 기호 집합을 사용할 수 있습니다.
구분 된 파일은 .CSV 확장자 (또는) .TXT 확장자 (또는 확장자 없음) 일 수 있습니다. ETL 파일을 만드는 개발자는 해당 파일을 처리 할 실제 구분 기호를 표시합니다. 구분 된 파일 레이아웃에서 첫 번째 행은 열 이름을 나타낼 수 있습니다.
위치 플랫 파일과 마찬가지로 ETL 테스트 팀은 구분 된 플랫 파일 데이터의 정확성을 명시 적으로 검증합니다.
가상 현실 비디오를 얻을 수있는 곳
준비 영역의 목적
스테이징 영역의 주요 목적은 ETL 프로세스를 위해 임시로 데이터를 저장하는 것입니다. 스테이징 영역은 DW 시스템의 백룸이라고합니다. ETL 아키텍트는 스테이징 영역에 데이터를 저장할지 여부를 결정합니다.
스테이징은 소스 시스템에서 데이터를 매우 빠르게 가져 오는 데 도움이됩니다. 동시에 DW 시스템에 장애가 발생하는 경우 스테이징 데이터가 이미있는 경우 소스 시스템에서 데이터를 수집하여 프로세스를 다시 시작할 필요가 없습니다.
데이터 추출 프로세스 후 DW 시스템에서 데이터를 준비하는 이유는 다음과 같습니다.
# 1) 복구 가능성 : 채워진 스테이징 테이블은 DW 데이터베이스 자체에 저장되거나 파일 시스템으로 이동 될 수 있으며 별도로 저장 될 수 있습니다. 어떤 시점에서 변환 또는로드 단계가 실패하면 스테이징 데이터가 복구 데이터로 작동 할 수 있습니다.
소스 시스템이 ETL에 사용 된 데이터를 덮어 쓸 가능성이 있으므로 추출 된 데이터를 스테이징에 보관하면 참조에 도움이됩니다.
# 2) 백업 : 방대한 양의 DW 데이터베이스 테이블을 백업하는 것은 어렵습니다. 그러나 백업은 모든 재해 복구에 필수입니다. 따라서 추출 된 데이터 인 스테이징 데이터가있는 경우 변환 및로드를 위해 작업을 실행할 수 있으므로 충돌 한 데이터를 다시로드 할 수 있습니다.
스테이징 데이터를 백업하기 위해 스테이징 데이터를 파일 시스템으로 자주 이동하여 네트워크에서 쉽게 압축하고 저장할 수 있습니다. 파일의 압축을 풀어야 할 때마다 스테이징 테이블로로드하고 작업을 실행하여 DW 테이블을 다시로드하십시오.
# 3) 감사 : 때때로 ETL 시스템에서 감사가 발생하여 소스 시스템과 대상 시스템 간의 데이터 연결을 확인할 수 있습니다. 감사자는 변환 규칙에 따라 출력 데이터에 대해 원본 입력 데이터의 유효성을 검사 할 수 있습니다.
스테이징 데이터와 백업은 소스 시스템에 사용 가능한 데이터가 있든 없든 여기에서 매우 유용합니다. 감사는 현재 (또는) 과거 데이터의 모든 기간에 대해 언제든지 발생할 수 있습니다. 준비 구역의 구조는 잘 계획되어야합니다.
스테이징 영역 설계
데이터웨어 하우스에서 준비 영역 데이터는 다음과 같이 설계 할 수 있습니다.
준비 테이블에 데이터를 새로로드 할 때마다 기존 데이터를 삭제 (또는) 참조를 위해 기록 데이터로 유지할 수 있습니다. 데이터가 삭제 된 경우이를 '임시 준비 영역'이라고합니다.
데이터가 히스토리로 유지되는 경우이를 '영구 스테이징 영역'이라고합니다. 위의 두 가지 유형 인 '하이브리드'를 조합하여 스테이징 영역을 디자인 할 수도 있습니다.
다음은 준비 영역을 디자인하는 동안 알아야 할 기본 규칙입니다.
- ETL 팀만 데이터 준비 영역에 액세스 할 수 있어야합니다. 스테이징 데이터 쿼리는 다른 사용자로 제한됩니다.
- 스테이징 영역의 테이블은 다른 사용자의 개입없이 ETL 데이터 설계자가 추가, 수정 또는 삭제할 수 있습니다. 스테이징 영역은 보고서를 생성하는 프리젠 테이션 영역이 아니므로 워크 벤치 역할을합니다.
- ETL 설계자는 DBA 및 OS 관리자에게 세부 정보를 제공하기 위해 스테이징 영역의 데이터 스토리지 측정 값을 추정해야합니다. 관리자는 스테이징 데이터베이스, 파일 시스템, 디렉토리 등에 대한 공간을 할당합니다.
스테이징 영역과 DW 데이터베이스가 동일한 서버를 사용하는 경우 데이터를 DW 시스템으로 쉽게 이동할 수 있습니다. 서버가 다른 경우 FTP (또는) 데이터베이스 링크를 사용하십시오.
ETL 프로세스 흐름
표준 ETL주기는 아래 프로세스 단계를 거칩니다.
- ETL주기를 시작하여 작업을 순서대로 실행합니다.
- 모든 메타 데이터가 준비되었는지 확인하십시오.
- ETL주기는 다양한 소스에서 데이터를 추출하는 데 도움이됩니다.
- 추출 된 데이터를 검증하십시오.
- 스테이징 테이블이 사용되는 경우 ETL주기는 데이터를 스테이징으로로드합니다.
- ETL은 비즈니스 규칙을 적용하고 집계를 생성하여 변환을 수행합니다.
- 오류가있는 경우 ETL주기는 보고서 형식으로이를 통지합니다.
- 그런 다음 ETL주기는 데이터를 대상 테이블에로드합니다.
- 기록 참조를 위해 저장해야하는 이전 데이터는 보관됩니다.
- 저장할 필요가없는 나머지 데이터는 정리됩니다.
ETL 프로세스 흐름도 :
결론
이 자습서에서는 데이터웨어 하우스의 ETL 프로세스의 주요 개념에 대해 배웠습니다. 이제 데이터 추출, 데이터 변환, 데이터로드 및 ETL 프로세스 흐름이 무엇인지 이해할 수있을 것입니다.
데이터웨어 하우스 테스트에 대해 자세히 알아 보려면 다가오는 자습서를 읽으십시오 !!
=> 독점 데이터웨어 하우징 시리즈를 보려면 여기를 방문하십시오.