DP-900: 데이터 수집 파이프라인 (ETL·ELT와 Data Factory)

ETL과 ELT를 고르는 기준, Azure Data Factory의 파이프라인·활동·데이터 세트·연결된 서비스·통합 런타임·트리거, Fabric의 Data Factory·바로 가기·미러링, Databricks와 HDInsight까지 DP-900 도메인 4의 데이터 수집을 정리합니다.

DP-900 공식 출제 범위 도메인 4에는 "데이터 수집과 처리에 대한 고려 사항 설명"이 있습니다. 분석은 데이터를 한곳에 모으는 데서 시작하므로, ETL과 ELT의 차이, Azure Data Factory의 파이프라인과 구성 요소, Microsoft Fabric으로 데이터를 가져오는 방법이 꾸준히 출제됩니다. 특히 연결된 서비스, 데이터 세트, 통합 런타임처럼 이름이 비슷한 구성 요소를 구분하는 문제가 자주 나옵니다.

이 글은 DP-900 학습자료 중 대규모 데이터 분석 서비스 편의 보충편입니다. 그 글에서 소개한 ETL·ELT와 Data Factory를 이어받아, 두 방식을 고르는 기준, Data Factory 구성 요소의 역할, Fabric과 Databricks의 수집 방법, 그리고 오래된 자료와 문제에 자주 나오는 HDInsight까지 정리합니다.

---

 

데이터 수집이란? ETL과 ELT 다시 보기

택배 물류센터를 떠올려 보세요. 전국에서 물건을 수거해 오고(추출), 크기와 지역별로 분류하고(변환), 창고 선반에 넣습니다(적재). 분류를 창고에 넣기 전에 하면 ETL, 일단 창고에 다 넣어 두고 창고 안에서 분류하면 ELT입니다.

| 구분 | ETL (추출 → 변환 → 적재) | ELT (추출 → 적재 → 변환) | |------|------|------| | 변환 위치 | 적재 전, 별도의 처리 엔진에서 | 적재 후, 분석 저장소 안에서 | | 원시 데이터 | 변환된 결과만 저장되는 경우가 많음 | 원시 데이터를 그대로 보관한 뒤 필요할 때 변환 | | 잘 맞는 저장소 | 스키마가 정해진 관계형 웨어하우스 | 데이터 레이크, 레이크하우스처럼 강력한 컴퓨팅을 가진 저장소 | | 장점 | 깨끗한 데이터만 들어감 | 대용량에 빠르고, 나중에 다른 방식으로 다시 변환 가능 | | 예 | Data Factory 데이터 흐름으로 정리해 SQL Database에 적재 | 원시 파일을 레이크하우스에 복사한 뒤 Spark·SQL로 변환 |

변환은 보통 여러 노드로 된 분산 시스템에서 병렬로 처리합니다. 변환 중간 결과를 잠시 두는 곳을 스테이징 영역(스테이징 테이블)이라고 부르며, 원본 시스템에 부담을 주지 않고 검증과 정리를 할 수 있게 해 줍니다. 수집에는 정적 데이터를 모아 처리하는 배치와, 이벤트를 바로 처리하는 스트리밍이 모두 포함됩니다.

시험 팁: "데이터를 먼저 분석 저장소에 복사한 뒤, 저장소의 컴퓨팅으로 변환한다" → ELT. "적재 전에 정리하고 형식을 맞춘다" → ETL.

---

 

Azure Data Factory의 구성 요소

Azure Data Factory는 데이터 이동과 변환 워크플로를 만들고 일정에 맞춰 실행하는 클라우드 데이터 통합(ETL) 서비스입니다. 구성 요소의 이름이 비슷해서 시험에서 자주 헷갈리므로, 그림과 표로 역할을 나눠 보세요.

!Azure Data Factory 파이프라인의 구성 요소

| 구성 요소 | 역할 | 비유 | |------|------|------| | 파이프라인 | 하나의 작업 단위를 이루는 활동의 논리적 묶음 | 요리 레시피 한 장 | | 활동 | 파이프라인 안의 처리 단계 하나 | 레시피의 각 단계 | | 데이터 세트 | 활동이 입력·출력으로 쓰는 데이터의 구조와 위치 | 재료 목록 | | 연결된 서비스 | 데이터 저장소나 컴퓨팅 서비스에 연결하는 정보 (연결 문자열과 비슷) | 식료품점 주소와 출입증 | | 통합 런타임 | 활동이 실행되는 컴퓨팅 환경, 활동과 연결된 서비스를 잇는 다리 | 요리하는 주방 | | 트리거 | 파이프라인 실행을 시작하는 조건 | 요리를 시작할 시각 | | 매핑 데이터 흐름 | 코드 없이 그리는 변환 로직, Spark 클러스터에서 자동 실행 | 레시피 그림 설명 |

연결된 서비스는 "어디에 어떻게 접속하는가", 데이터 세트는 "그 안의 어떤 데이터인가"입니다. 예를 들어 스토리지 계정 연결 문자열은 연결된 서비스에, 그 안의 특정 컨테이너와 폴더는 데이터 세트에 정의합니다.

활동의 세 가지 종류

데이터 이동 활동: Copy 활동으로 온프레미스와 클라우드의 데이터 저장소 사이에서 데이터를 복사합니다. 데이터 변환 활동: 매핑 데이터 흐름, Databricks 노트북, 저장 프로시저, HDInsight Hive 쿼리 등으로 데이터를 가공합니다. 제어 활동: 순서대로 이어 붙이기, If 조건 분기, ForEach 반복, 다른 파이프라인 실행처럼 흐름을 제어합니다.

통합 런타임과 트리거

| 통합 런타임 | 쓰임 | |------|------| | Azure | 클라우드의 데이터 저장소 사이 이동과 데이터 흐름 실행 | | 자체 호스팅 | 온프레미스나 프라이빗 네트워크 안의 데이터에 접근 | | Azure-SSIS | 기존 SSIS(SQL Server Integration Services) 패키지를 그대로 실행 |

| 트리거 | 실행 시점 | |------|------| | 일정 | 정해진 시각과 주기 (예: 매일 새벽 2시) | | 연속 창 (tumbling window) | 겹치지 않는 고정 간격, 과거 구간 재실행 가능 | | 스토리지 이벤트 | Blob이 만들어지거나 삭제될 때 | | 사용자 지정 이벤트 | Event Grid의 사용자 지정 이벤트가 도착할 때 |

트리거 없이 바로 실행하는 수동(주문형) 실행도 가능합니다. 파이프라인은 Azure DevOps나 GitHub와 연결해 CI/CD로 배포하고, Azure Monitor로 성공·실패를 모니터링합니다.

시험 팁: "온프레미스 SQL Server의 데이터를 Data Factory로 복사" → 자체 호스팅 통합 런타임. "연결 정보를 담는 구성 요소" → 연결된 서비스. "파일이 업로드되면 파이프라인 실행" → 스토리지 이벤트 트리거.

---

 

Microsoft Fabric에서 데이터를 가져오는 방법

Fabric은 데이터를 OneLake로 가져오는 방법을 여러 가지 제공합니다. 데이터를 실제로 복사하는지, 계속 동기화하는지가 고르는 기준입니다.

| 방법 | 하는 일 | 데이터 복사 | 이럴 때 | |------|------|------|------| | Fabric Data Factory 파이프라인 | 여러 단계의 이동·변환을 순서·병렬로 조율 | 함 | 일반적인 배치 ETL·ELT | | Dataflow Gen2 | Power Query로 만드는 노코드 변환 | 함 | 코드 없이 재사용 가능한 변환 | | OneLake 바로 가기 | ADLS Gen2, Amazon S3, Google Cloud Storage 등을 참조만 함 | 안 함 | 데이터를 원래 위치에 둬야 할 때 | | 미러링 | Azure SQL Database, Cosmos DB, Snowflake 등을 거의 실시간으로 계속 복제 | 함 (자동) | 파이프라인 없이 운영 DB를 분석용으로 | | Eventstream | Event Hubs, Kafka, IoT Hub 이벤트를 실시간 수집 | 함 | 스트리밍 데이터 | | 노트북 | PySpark·Python·SQL 코드로 직접 수집·변환 | 함 | 커넥터가 없거나 로직이 복잡할 때 |

Fabric Data Factory는 Azure Data Factory의 다음 세대로, 같은 파이프라인 모델을 쓰므로 기술이 그대로 이어집니다. 차이는 Azure Data Factory가 연결된 서비스를 쓰는 곳에서 Fabric은 연결(connection)을 쓴다는 점입니다. 목적지가 Azure SQL Database 같은 Fabric 밖의 서비스이거나 Fabric을 쓰지 않는 하이브리드 환경이라면 독립 서비스인 Azure Data Factory를 씁니다.

시험 팁: "Amazon S3의 데이터를 복사하지 않고 Fabric 레이크하우스에서 조회" → OneLake 바로 가기. "운영 중인 Azure SQL Database를 파이프라인 없이 OneLake에 계속 복제" → 미러링.

---

 

Azure Databricks와 HDInsight의 수집·처리

Azure Databricks

Azure Databricks에서는 Lakeflow 파이프라인으로 결과 테이블이 담아야 할 내용을 선언하면, 실행 순서·의존성·증분 처리를 Databricks가 알아서 관리합니다. 운영용 배치·스트리밍 수집에 맞습니다. 탐색이나 일회성 수집은 PySpark·SQL 노트북으로 REST API, JDBC 원본, 클라우드 저장소를 읽어 Delta Lake 테이블에 씁니다.

Azure HDInsight

HDInsight는 Apache Spark, Hive, LLAP, Kafka, HBase, Hadoop 같은 오픈소스 빅데이터 프레임워크를 Azure에서 관리형 클러스터로 실행하는 서비스입니다. 현재 출제 범위에는 이름이 나오지 않지만, 오래된 학습 자료와 문제에는 "기존 Hadoop 생태계를 그대로 클라우드로 옮긴다"는 상황으로 자주 등장합니다.

| 서비스 | 특징 | 이럴 때 | |------|------|------| | Azure Data Factory | 노코드 파이프라인, 다양한 내장 커넥터, 하이브리드 연결 | Fabric 밖의 데이터 통합, 온프레미스 원본 | | Fabric Data Factory | Fabric 안의 파이프라인과 Dataflow Gen2 | OneLake로 가져와 Fabric에서 분석 | | Azure Databricks | Spark 기반, Lakeflow 파이프라인과 노트북 | 코드 중심 대규모 처리, Delta Lake | | Azure HDInsight | 오픈소스 프레임워크의 관리형 클러스터 | 기존 Hadoop·Hive·Kafka 작업을 그대로 이전 |

시험 팁: "기존 Hadoop과 Hive 작업을 최소 변경으로 Azure 관리형 클러스터에서 실행" → HDInsight. "코드 없이 여러 원본의 데이터를 정해진 시간에 복사·변환" → Data Factory.

---

 

시나리오로 연습하기

먼저 답을 떠올린 뒤 오른쪽 열을 확인해 보세요.

| 문제 상황 | 정답 | 판단 근거 | |------|------|------| | 원시 로그를 먼저 레이크에 다 넣어 두고, 필요할 때 Spark로 변환한다 | ELT | 적재 후 저장소 안에서 변환 | | 매일 밤 2시에 판매 데이터를 복사하는 파이프라인 실행 | 일정 트리거 | 정해진 시각 | | 1시간 단위로 끊어서 처리하고, 장애로 빠진 과거 구간도 다시 돌린다 | 연속 창(tumbling window) 트리거 | 겹치지 않는 고정 간격 | | 사내 데이터센터의 Oracle 데이터를 Azure로 복사 | 자체 호스팅 통합 런타임 | 프라이빗 네트워크 접근 | | 이미 쓰고 있는 SSIS 패키지를 클라우드에서 실행 | Azure-SSIS 통합 런타임 | SSIS 리프트 앤 시프트 | | 코드 없이 Spark 기반 변환 로직을 시각적으로 설계 | 매핑 데이터 흐름 | Spark 클러스터 자동 관리 | | 다른 클라우드의 데이터를 이동 없이 Fabric에서 조회 | OneLake 바로 가기 | 참조만, 복사 없음 | | Cosmos DB 운영 데이터를 ETL 없이 거의 실시간으로 Fabric에 반영 | 미러링 | 자동 연속 복제 |

---

 

시험 핵심 정리

시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.

| 구분 | 핵심 암기 사항 | |------|------| | ETL | 적재 전에 변환, 깨끗한 데이터만 저장소로 | | ELT | 먼저 적재하고 저장소 안에서 변환, 대용량·레이크에 적합 | | 파이프라인 | 활동의 논리적 묶음, 순서·병렬 실행 | | 활동 3종 | 데이터 이동(Copy), 데이터 변환, 제어 | | 데이터 세트 vs 연결된 서비스 | 데이터의 구조·위치 vs 접속 정보(연결 문자열) | | 통합 런타임 | Azure / 자체 호스팅(온프레미스) / Azure-SSIS | | 트리거 | 일정, 연속 창, 스토리지 이벤트, 사용자 지정 이벤트, 수동 실행 | | 매핑 데이터 흐름 | 노코드 변환, Spark에서 자동 실행 | | Fabric Data Factory | 파이프라인 + Dataflow Gen2, 연결된 서비스 대신 연결 | | OneLake 바로 가기 | 외부 저장소를 복사 없이 참조 | | 미러링 | 운영 DB를 OneLake에 거의 실시간 연속 복제 | | HDInsight | 오픈소스(Hadoop·Spark·Hive·Kafka) 관리형 클러스터 |

---

 

다음 단계

수집 파이프라인을 정리했다면, 데이터가 도착한 뒤의 모습을 이어서 보세요. 분석 플랫폼 전체 그림은 대규모 데이터 분석 서비스, 저장소 안에서 데이터를 팩트와 차원으로 정리하는 방법은 스타 스키마와 분석 데이터 모델, 스트리밍 수집은 Fabric 실시간 인텔리전스와 Spark Structured Streaming에서 다룹니다.

실전 감각을 익히고 싶다면 DP-900 모의고사로 수집 파이프라인 문제를 직접 풀어 보세요. 이름이 비슷한 구성 요소는 문제 속 상황과 함께 기억할 때 가장 오래 남습니다.

블로그 목록으로 돌아가기