ETL(추출, 변환 및 로드)
조직에서는 일반적으로 다양한 형식의 여러 원본에서 데이터를 수집하고 하나 이상의 데이터 저장소로 이동해야 합니다. 대상은 원본과 동일한 형식의 데이터 저장소가 아닐 수 있으며 로드하기 전에 데이터를 셰이핑, 정리 또는 변환해야 하는 경우가 많습니다.
다양한 도구, 서비스 및 프로세스는 이러한 문제를 해결하는 데 도움이 됩니다. 접근 방식에 관계없이 작업을 조정하고 데이터 파이프라인 내에서 데이터 변환을 적용해야 합니다. 다음 섹션에서는 이러한 작업에 대한 일반적인 방법 및 사례를 중점적으로 설명합니다.
ETL(추출, 변환, 로드) 프로세스
ETL(추출, 변환, 로드)은 다양한 원본의 데이터를 통합된 데이터 저장소로 통합하는 데이터 통합 프로세스입니다. 변환 단계에서는 특수 엔진을 사용하여 비즈니스 규칙에 따라 데이터가 수정됩니다. 여기에는 처리되고 궁극적으로 대상에 로드될 때 일시적으로 데이터를 보관하는 스테이징 테이블이 포함되는 경우가 많습니다.
일반적으로 발생하는 데이터 변환에는 필터링, 정렬, 집계, 데이터 조인, 데이터 정리, 중복 제거 및 데이터 유효성 검사 등의 다양한 작업이 포함됩니다.
종종 세 가지 ETL 단계가 병렬로 실행되어 시간을 절약합니다. 예를 들어 데이터를 추출하는 동안 변환 프로세스는 이미 수신된 데이터에 대해 작업하여 로드를 준비할 수 있으며, 로드 프로세스는 전체 추출 프로세스가 완료될 때까지 기다리지 않고 준비된 데이터에 대한 작업을 시작할 수 있습니다. 일반적으로 데이터 파티션 경계(날짜, 테넌트, 분할 키)를 중심으로 병렬 처리를 디자인하여 쓰기 경합을 방지하고 idempotent 재시도를 사용하도록 설정합니다.
관련 서비스:
기타 도구:
ELT(추출, 로드, 변환)
ELT(추출, 로드, 변환)는 변환이 발생하는 곳에서만 ETL과 다릅니다. ELT 파이프라인에서는 대상 데이터 저장소에서 변환이 발생합니다. 별도 변환 엔진을 사용하는 대신, 대상 데이터 저장소의 처리 기능을 사용하여 데이터를 변환합니다. 따라서 파이프라인에서 변환 엔진이 제거되므로 아키텍처가 단순해집니다. 이 방식의 또 다른 이점은 대상 데이터 저장소의 크기를 조정하면 ELT 파이프라인 성능도 조정된다는 것입니다. 그러나 ELT는 대상 시스템이 데이터를 효율적으로 변환할 수 있을 만큼 강력할 때만 효과적입니다.
ELT의 일반적인 사용 사례는 빅 데이터 영역에 포함합니다. 예를 들어 HDFS(Hadoop 분산 파일 시스템), Azure Blob Storage 또는 Azure Data Lake Storage Gen2와 같은 확장 가능한 스토리지의 플랫 파일에 원본 데이터를 추출하여 시작할 수 있습니다. 그런 다음 Spark, Hive 또는 PolyBase와 같은 기술을 사용하여 원본 데이터를 쿼리할 수 있습니다. ELT의 중요한 점은 변형을 수행하는 데 사용된 동일한 데이터 저장소에서 궁극적으로 데이터가 사용된다는 것입니다. 이 데이터 저장소는 데이터를 별도의 스토리지에 로드하는 대신 확장 가능한 스토리지에서 직접 읽습니다. 이 방법은 ETL에 있는 데이터 복사 단계를 건너뜁니다. 이 단계는 대용량 데이터 집합에 시간이 오래 걸릴 수 있습니다. 일부 워크로드는 변환된 테이블 또는 뷰를 구체화하여 쿼리 성능을 개선하거나 거버넌스 규칙을 적용합니다. ELT가 항상 순수하게 가상화된 변환을 의미하지는 않습니다.
ELT 파이프라인의 마지막 단계는 일반적으로 원본 데이터를 지원해야 하는 쿼리 유형에 더 효율적인 형식으로 변환합니다. 예를 들어 데이터는 일반적으로 필터링된 키로 분할될 수 있습니다. ELT는 압축, 조건자 푸시다운 및 효율적인 분석 검사를 사용하도록 데이터를 열별로 구성하는 열 형식 스토리지 형식인 Parquet과 같은 최적화된 스토리지 형식을 사용할 수도 있습니다.
관련 Microsoft 서비스:
ETL 또는 ELT 선택
이러한 방법 중에서 선택하는 방법은 요구 사항에 따라 달라집니다.
다음과 같은 경우 ETL을 선택합니다.
- 제한된 대상 시스템에서 많은 변환을 오프로드해야 합니다.
- 복잡한 비즈니스 규칙에는 특수 변환 엔진이 필요합니다.
- 규정 또는 규정 준수 요구 사항은 로드하기 전에 큐레이팅된 스테이징 감사를 의무화합니다.
다음과 같은 경우 ELT를 선택합니다.
- 대상 시스템은 탄력적 컴퓨팅 스케일링이 있는 최신 데이터 웨어하우스 또는 레이크하우스입니다.
- 예비 분석 또는 향후 스키마 진화를 위해 원시 데이터를 보존해야 합니다.
- 대상 시스템의 네이티브 기능으로 인한 변환 논리 이점
데이터 흐름 및 제어 흐름
데이터 파이프라인의 컨텍스트에서 제어 흐름은 일련의 작업을 순서대로 처리합니다. 이러한 태스크의 올바른 처리 순서를 적용하기 위해 선행 제약 조건이 사용됩니다. 아래 그림에 나와 있는 것처럼, 이러한 제약 조건을 워크플로 다이어그램의 연결선으로 생각할 수 있습니다. 각 태스크에는 성공, 실패 또는 완료와 같은 결과가 있습니다. 후속 작업은 선행 작업이 이러한 결과 중 하나로 완료될 때까지 처리를 시작하지 않습니다.
제어 흐름은 데이터 흐름을 하나의 태스크로 실행합니다. 데이터 흐름 태스크에서 데이터는 원본에서 추출되고, 변형되고, 데이터 저장소에 로드됩니다. 한 데이터 흐름 작업의 출력은 다음 데이터 흐름 작업에 대한 입력이 될 수 있으며 데이터 흐름은 병렬로 실행될 수 있습니다. 제어 흐름과 달리 데이터 흐름의 태스크 간에 제약 조건을 추가할 수 없습니다. 그러나 각 태스크에서 처리되는 데이터를 관찰하기 위해 데이터 뷰어를 추가할 수는 있습니다.
다이어그램에는 제어 흐름 내에 여러 태스크가 있으며, 그 중 하나는 데이터 흐름 태스크입니다. 태스크 중 하나가 컨테이너 내에 중첩되어 있습니다. 컨테이너는 태스크에 구조를 제공하는 데 사용될 수 있으며 작업 단위를 제공합니다. 이러한 예제 중 하나는 폴더 또는 데이터베이스 문의 파일처럼 컬렉션 내에서 요소를 반복하는 경우입니다.
관련 서비스:
ETL 프로세스 역방향 처리
역방향 ETL은 분석 시스템에서 운영 도구 및 애플리케이션으로 변환되고 모델링된 데이터를 이동하는 프로세스입니다. 운영 시스템에서 분석으로 데이터를 흐르는 기존 ETL과 달리 역방향 ETL은 큐레이팅된 데이터를 비즈니스 사용자가 작업할 수 있는 위치로 다시 푸시하여 인사이트를 활성화합니다. 역방향 ETL 파이프라인에서 데이터는 데이터 웨어하우스, 레이크하우스 또는 기타 분석 저장소에서 다음과 같은 운영 시스템으로 흐릅니다.
- CRM(고객 관계 관리) 플랫폼
- 마케팅 자동화 도구
- 고객 지원 시스템
- 워크로드 데이터베이스
이 방법은 여전히 추출, 변환 및 로드 프로세스를 따릅니다. 변환 단계에서는 데이터 웨어하우스 또는 다른 분석 시스템에서 대상 시스템에 맞게 사용하는 특정 형식에서 변환합니다.
예제는 NoSQL용 Azure Cosmos DB를 사용하여 ETL(역방향 추출, 변환 및 로드) 을 참조하세요.
스트리밍 데이터 및 핫 경로 아키텍처
람다 핫 경로 또는 Kappa 아키텍처가 필요한 경우 데이터가 생성될 때 데이터 원본을 구독할 수 있습니다. 예약된 일괄 처리의 데이터 세트에 대해 작동하는 ETL 또는 ELT와 달리 실시간 스트리밍은 도착 시 데이터를 처리하여 즉각적인 인사이트와 작업을 가능하게 합니다.
스트리밍 아키텍처에서 데이터는 이벤트 원본에서 메시지 브로커 또는 이벤트 허브(예: Azure Event Hubs 또는 Kafka)로 수집된 다음 스트림 프로세서(예: 패브릭 Real-Time Intelligence, Azure Stream Analytics 또는 Apache Flink)에서 처리됩니다. 프로세서는 대시보드, 경고 또는 데이터베이스와 같은 다운스트림 시스템으로 결과를 라우팅하기 전에 필터링, 집계, 보강 또는 참조 데이터와의 조인과 같은 변환을 적용합니다.
이 방법은 대기 시간이 짧고 지속적인 업데이트가 중요한 시나리오에 적합합니다. 예를 들면 다음과 같습니다.
- 변칙에 대한 제조 장비 모니터링
- 금융 트랜잭션에서 사기 감지
- 물류 또는 작업을 위한 실시간 대시보드 전원 공급
- 센서 임계값에 따라 경고 트리거
스트리밍에 대한 안정성 고려 사항
- 검사점을 사용하여 최소 한 번 이상의 처리 보장 및 오류 복구
- 잠재적인 중복 처리를 처리하기 위해 idempotent로 변환 디자인
- 늦게 도착하는 이벤트 및 잘못된 순서 처리에 대한 워터마크 구현
- 처리할 수 없는 메시지에 배달 못 한 편지 큐 사용
기술 선택
데이터 저장소:
파이프라인 및 오케스트레이션:
- 파이프라인 오케스트레이션
- Microsoft Fabric Data Factory (최신 오케스트레이션)
- Azure Data Factory (하이브리드 및 비 패브릭 시나리오)
레이크하우스 및 최신 분석: