반응형
AWS DEA-C01
Domain 1
데이터 수집 수행
Kinesis · Glue · MSK
배치 · 스트리밍 · 5V
AWS Skill Builder
AWS DEA-C01 Domain 1 — 데이터 수집 수행(Perform Data Ingestion) 완전 정리
AWS Skill Builder 공식 강의 기반. 데이터 엔지니어링 수명 주기의 수집(Ingestion) 단계를 중심으로 배치 vs 스트리밍, 푸시 vs 풀, 데이터 5V, 멱등성, 재처리 설계, Kinesis 핫 샤드 해결, Redshift COPY 최적화, 스테이트풀 vs 스테이트리스와 AWS 수집 서비스 전체를 도식·비교표로 완전 정리합니다.
01 데이터 엔지니어링 수명 주기 복습 — 이번 강의 위치
5단계 수명 주기 중 Domain 1의 초점 = 수집(Ingestion, 3단계). 이 전에 생성·저장 단계를 먼저 이해해야 합니다.
01
생성
Generation
02
저장
Storage
03 ★
수집
Ingestion
04
변형
Transformation
05
제공
Serving
💡 데이터 엔지니어링 수명 주기는 전체 데이터 수명 주기의 하위 집합. 전체 수명 주기에는 보안·오케스트레이션·데이터 아키텍처·소프트웨어 엔지니어링·운영이 추가로 포함됩니다.
02 생성 단계 (Generation) — 소스 시스템 이해
🌐 소스 시스템 (Source System)
데이터가 발생하는 위치. 데이터 엔지니어는 데이터를 사용하지만 소스 시스템을 직접 제어하지 않음
- IoT (Internet of Things) 디바이스
- 트랜잭션 데이터베이스 (Transactional DB)
- 애플리케이션 메시지 대기열 (Message Queue)
❓ 생성 단계 핵심 질문
- 데이터의 특성은 무엇인가?
- 소스 시스템에서 데이터가 유지되는 방식은?
- 중복 데이터가 존재하는가?
- 소스 데이터의 스키마(Schema)는 무엇이고, 변경되는가?
- 데이터 생성 빈도 및 속도는?
- 생성되는 데이터의 유형은?
03 수집 단계 (Ingestion) — 핵심 질문 & 2대 개념
소스 파악 → 저장 계획 완료 후, 실제 데이터를 수집하는 단계
❓ 수집 단계 핵심 질문
- 수집 데이터의 사용 사례는?
- 수집 후 데이터는 어디로 이동하는가?
- 데이터 수집 빈도 및 볼륨은?
- 데이터의 형식(Format)은?
🔑 시험 필수 이해 2대 개념
① 배치(Batch) vs 스트리밍(Streaming)
② 푸시(Push) vs 풀(Pull)
→ 각각의 개념과 차이점을 시험에서 반드시 이해해야 함
04 배치(Batch) vs 스트리밍(Streaming) / 푸시(Push) vs 풀(Pull)
| 구분 | 배치 (Batch) | 스트리밍 (Streaming) |
|---|---|---|
| 처리 방식 | 일정 주기로 대량 처리 (시간·일·주 단위 예약) |
실시간 또는 거의 실시간으로 연속 처리 |
| 이벤트 크기 | 큰 이벤트 페이로드 (Large payload) | 소용량 이벤트 대규모 처리 (예: 1KB 페이로드 지속 스트림) |
| 데이터 온도 | Cold Data 즉시 처리 불필요 | Hot Data 즉시 처리 필요 |
| 예약·트리거 | CRON 작업 등 예약(Scheduled) 실행 | 이벤트 기반(Event-Driven) 자동 트리거 |
| 처리 바인딩 | 데이터 경계를 소스 기준으로 설정 | 시간·이벤트 양·세그먼트별로 처리 바인딩 |
| AWS 서비스 | Amazon EMR AWS Glue | Amazon Kinesis Amazon MSK |
| 구분 | 푸시 (Push) | 풀 (Pull) |
|---|---|---|
| 주체 | 소스 시스템이 능동적으로 전송 | 수집 시스템이 소스에서 능동적으로 가져옴 |
| 특징 | 이벤트 발생 즉시 전달, 낮은 지연 | 주기적 폴링(Polling), 수집 시스템 주도 |
| AWS 예시 | Kinesis Enhanced Fan-Out EventBridge Push |
Kinesis 기본 폴링 Glue JDBC 연결 쿼리 |
05 수집 프로세스 흐름 — 생산자 → 수집 → 소비자
생산자 (Producer)
DB·모바일·앱
DB·모바일·앱
→
수집 도구 (Ingestion Tool)
Kinesis·Glue·DMS 등
Kinesis·Glue·DMS 등
→
소비자 (Consumer)
EC2·Lambda·DB·S3
EC2·Lambda·DB·S3
📋 S3 데이터 레이크 수집 예시 — TSV → 분석 파이프라인
애플리케이션이 고객 상호 작용·리뷰 데이터를 TSV(Tab-Separated Values) 형식으로 S3 버킷에 지속 기록
앱 → S3 (TSV)
→
Amazon Athena로 임시 SQL 쿼리
TSV 데이터
→
Apache Parquet 변환 (열 기반·쿼리 최적화)
→
성능 향상
S3 TSV
→
Amazon Redshift 삽입
+
Redshift Spectrum (S3 레이크 직접 쿼리)
💡 Athena 테이블 자동 업데이트: 새 데이터가 S3에 도착하면 AWS Glue + Glue 크롤러(Crawler)를 사용하여 스키마 자동 업데이트
06 데이터 수집 파이프라인 재처리 설계 원칙 (모범 사례)
파이프라인 로직의 실패·업데이트·변경 발생 시 데이터를 재처리하기 위한 설계 방법
-
1이벤트 기반 설계 (Event-Driven Architecture) 권장새 데이터 도착·데이터 변경 시 자동 트리거. 활용 AWS 서비스: Amazon S3 Amazon Kinesis Amazon EventBridge
-
2멱등성 검증 (Idempotency Validation)동일한 데이터를 여러 번 처리해도 데이터 중복·불일치 없이 일관된 결과를 보장. 다양한 시뮬레이션·재처리 시나리오로 테스트하여 검증
-
3체크포인트 메커니즘 구성 (Checkpoint Mechanism)파이프라인 처리의 진행 상황·상태를 추적. 마지막 성공 처리 포인트 저장 → 오류·중단 시 해당 포인트부터 재개
-
4데이터 버전 관리 + 내구적 스토리지원시(Raw) 또는 중간(Intermediate) 데이터를 Amazon S3에 저장. 규정 준수·데이터 거버넌스 정책·재재생(Replay)을 위해 일정 기간 보존
-
5로깅 및 모니터링 추가 (Logging & Monitoring)진행 상황 추적·실패 식별·파이프라인 동작 분석을 위한 로그·오류·지표(Metrics) 캡처
-
6코드형 인프라 (IaC: Infrastructure as Code)파이프라인 배포·구성 자동화. 활용 서비스: AWS CloudFormation AWS CDK (Cloud Development Kit)
07 데이터의 5V — 수집 솔루션 선택 기준
V1
Variety
다양성
데이터의 유형
정형·반정형·비정형
로그·사진·센서·IoT
정형·반정형·비정형
로그·사진·센서·IoT
V2
Volume
볼륨
전송 데이터의 양
일/월/연 증가량
서비스 크기 제한 주의
일/월/연 증가량
서비스 크기 제한 주의
V3
Velocity
속도
소스→대상 수집·처리 속도
실시간 vs 준실시간
빈도·처리량 고려
실시간 vs 준실시간
빈도·처리량 고려
V4
Veracity
정확성·유효성
데이터 품질·완전성·정확도
불완전·불일관 가능
IoT 오프라인 = 누락
불완전·불일관 가능
IoT 오프라인 = 누락
V5
Value
가치
가장 중요한 V
비즈니스 부가가치
창출 여부 반드시 확인
비즈니스 부가가치
창출 여부 반드시 확인
📦 볼륨(Volume) AWS 서비스
Amazon S3 Amazon EBS
Amazon Redshift Amazon DynamoDB
Amazon Redshift Amazon DynamoDB
EBS: Elastic Block Store
⚡ 속도(Velocity) AWS 서비스
가변 트래픽·대량 수집 처리
Amazon Kinesis Amazon MSK
Amazon OpenSearch AWS Lambda
Amazon Kinesis Amazon MSK
Amazon OpenSearch AWS Lambda
🧩 다양성(Variety) AWS 서비스
정형·반정형·비정형 처리
Amazon RDS Amazon S3
AWS Glue Amazon Comprehend
Amazon RDS Amazon S3
AWS Glue Amazon Comprehend
08 사용 사례별 AWS 데이터 서비스 맵
🏞️ 데이터 레이크 (Data Lake)
Amazon S3
장점: 사전 정의된 스키마 불필요, 정형·비정형 모두 저장 가능
장점: 사전 정의된 스키마 불필요, 정형·비정형 모두 저장 가능
🏢 데이터 웨어하우스 / 레이크하우스
Amazon Redshift + Redshift Spectrum
데이터 이동 없이 정형·비정형 대상 SQL·복잡한 분석 쿼리 실행
데이터 이동 없이 정형·비정형 대상 SQL·복잡한 분석 쿼리 실행
🐘 빅데이터 처리 (Big Data Processing)
Amazon EMR (Elastic MapReduce)
데이터 엔지니어링·데이터 과학 개발·협업. 방대한 데이터를 쉽고 빠르게 처리
데이터 엔지니어링·데이터 과학 개발·협업. 방대한 데이터를 쉽고 빠르게 처리
🌊 실시간 분석 (Real-Time Analytics)
Amazon Kinesis — 스트리밍 데이터 수집·처리·분석, 실시간 대응
Amazon MSK — Apache Kafka 관리형, 스트리밍 실시간 수집·처리
Amazon MSK — Apache Kafka 관리형, 스트리밍 실시간 수집·처리
📊 운영 분석 (Operational Analytics)
Amazon OpenSearch Service
앱 모니터링·로그 분석·클릭스트림 분석. 거의 실시간으로 검색·탐색·필터링·집계·시각화
앱 모니터링·로그 분석·클릭스트림 분석. 거의 실시간으로 검색·탐색·필터링·집계·시각화
🗄️ 트랜잭션 데이터 (Transactional Data)
소량 데이터의 신속한 저장·검색 필요
Amazon DynamoDB + Amazon RDS
수집: AWS DMS (Database Migration Service)
Amazon DynamoDB + Amazon RDS
수집: AWS DMS (Database Migration Service)
09 스트리밍 수집 AWS 서비스 상세 비교
| 서비스 (약어) | 풀네임 | 특징 및 설명 | 주요 대상 스토리지 |
|---|---|---|---|
| Kinesis Data Firehose | Amazon Kinesis Data Firehose | 스트리밍 데이터 수집 → 버퍼링(구성 가능 기간) → 대상 기록. 완전관리형 | S3 Redshift OpenSearch |
| Kinesis Data Streams | Amazon Kinesis Data Streams | 실시간 수집. 낮은 지연(Low Latency). 사용자 지정 앱으로 수신 데이터 처리 가능. 샤드(Shard) 단위 관리 | 사용자 정의 처리 후 다양한 대상 |
| Managed Svc for Flink | Amazon Managed Service for Apache Flink (구: Amazon Kinesis Data Analytics) |
스트리밍 소스에서 데이터 읽기. SQL 문 또는 Apache Flink 코드로 스트림 분석 수행 | Kinesis 스트림·S3·기타 |
| Kinesis Video Streams | Amazon Kinesis Video Streams | 스트리밍 비디오·오디오 및 시계열 데이터 처리. 열 화상·레이더 데이터 등 포함 | ML·영상 분석 파이프라인 |
| Kinesis Agent | Amazon Kinesis Agent | 파일 데이터를 Kinesis Data Streams 또는 Kinesis Data Firehose에 기록하도록 돕는 에이전트 | 로그 파일·온프레미스 데이터 |
| Amazon MSK | Amazon Managed Streaming for Apache Kafka | 기존 Apache Kafka 클러스터 대체 가능. 클러스터 비용 상시 발생 (데이터 전송 여부 무관) | Kafka 기반 파이프라인 |
💡 Kinesis vs MSK 선택 기준: Kinesis는 서버리스 + 데이터 처리량만 과금 → 새 솔루션에 적합. MSK는 클러스터 비용 상시 발생 → 기존 Kafka 클러스터 대체 용도
10 Kinesis 쓰기 성능 저하 & 핫 샤드(Hot Shard) 해결
🎯 시험 출제 시나리오
Kinesis Data Streams로 매일 대량의 실시간 데이터를 수집 중. 쓰기 성능이 크게 감소하고 쓰기 요청이 제한(Throttling)되고 있음. 파이프라인을 어떻게 업데이트해야 하는가?
원인: 각 스트림은 하나 이상의 샤드(Shard)로 구성 → 워크로드 증가 시 샤드 용량 초과 → 핫 샤드(Hot Shard) 발생
해결책 1:
해결책 2: 무작위 파티션 키(Random Partition Key) 사용 → 해시 키 공간을 샤드 전체에 균등 배포
모니터링: 스트림 지표 모니터링 + 경보 임계값(Alarm Threshold) 설정 → 크기 조정 결정 가시성 확보
해결책 1:
UpdateShardCount 작업으로 스트림 크기 확장 (샤드 수 증가)해결책 2: 무작위 파티션 키(Random Partition Key) 사용 → 해시 키 공간을 샤드 전체에 균등 배포
모니터링: 스트림 지표 모니터링 + 경보 임계값(Alarm Threshold) 설정 → 크기 조정 결정 가시성 확보
11 Amazon Redshift COPY 명령 최적화
🎯 시험 출제 시나리오
여러 소스의 대량 파일 → 매일 단일 gzip 파일로 병합·압축 → S3 업로드 → Redshift 클러스터 로드. COPY 프로세스를 더 빠르게 실행하려면?
핵심 원리: COPY 명령은 Redshift의 MPP(Massive Parallel Processing, 대규모 병렬 처리) 아키텍처를 사용하여 S3 파일에서 병렬로 데이터를 읽고 로드
해결책: 단일 gzip 파일을 파일 수 = Redshift 클러스터 내 슬라이스(Slice) 수의 배수가 되도록 더 작은 파일로 분할 → Redshift가 데이터를 병렬로 슬라이스에 로드 → 전체 로드 시간 향상
추가: 데이터를 여러 파일로 분할 + 테이블에 배포 키(Distribution Key) 설정 → 병렬 처리 극대화
해결책: 단일 gzip 파일을 파일 수 = Redshift 클러스터 내 슬라이스(Slice) 수의 배수가 되도록 더 작은 파일로 분할 → Redshift가 데이터를 병렬로 슬라이스에 로드 → 전체 로드 시간 향상
추가: 데이터를 여러 파일로 분할 + 테이블에 배포 키(Distribution Key) 설정 → 병렬 처리 극대화
12 배치 수집 (Batch Ingestion) AWS 서비스
🐘 Amazon EMR (Elastic MapReduce)
일반적인 Hadoop 프레임워크 배포. 데이터베이스 수집 도구 포함
EMR에서 Apache Spark 실행 + JDBC(Java Database Connectivity) 드라이버로 관계형 DB 연결 → 데이터 레이크에 로드
EMR에서 Apache Spark 실행 + JDBC(Java Database Connectivity) 드라이버로 관계형 DB 연결 → 데이터 레이크에 로드
🔄 AWS Glue
완전관리형 ETL(Extract, Transform, Load) 서비스
JDBC 소스에 연결 → 다양한 DB 엔진 지원
데이터 스토어·스트림 간 처리·개선·마이그레이션
Glue 대화형 세션: 데이터 분석·처리
Glue Studio: 시각적 ETL 워크플로 개발·실행·모니터링
JDBC 소스에 연결 → 다양한 DB 엔진 지원
데이터 스토어·스트림 간 처리·개선·마이그레이션
Glue 대화형 세션: 데이터 분석·처리
Glue Studio: 시각적 ETL 워크플로 개발·실행·모니터링
13 기타 수집 AWS 서비스 — 목적별 선택 가이드
| 서비스 | 풀네임 | 사용 목적 / 사용 사례 | 프로토콜·방식 |
|---|---|---|---|
| Amazon AppFlow | Amazon AppFlow | SaaS(Software as a Service) 서비스에서 데이터 수집 → 변환 → S3·Redshift·다른 SaaS 기록 | SaaS 네이티브 커넥터 (60개 이상) |
| AWS Transfer Family | AWS Transfer Family | 일반적인 파일 전송 프로토콜을 사용하여 Amazon S3에 직접 파일 전송 | FTP (File Transfer Protocol) SFTP (Secure File Transfer Protocol) |
| AWS DataSync | AWS DataSync | 온프레미스(On-premises) 스토리지에 저장된 데이터 수집·이전 | NFS (Network File System) SMB (Server Message Block) |
| AWS Snow Family | AWS Snow Family (Snowcone·Snowball·Snowmobile) |
대량의 데이터 물리적 이전·수집. 네트워크 대역폭 제한 환경 | 물리적 디바이스 배송 |
| AWS DMS | AWS Database Migration Service | 기존 DB → 새 DB 엔진 마이그레이션 (예: Oracle → Aurora). S3 데이터 레이크로 연속 복제(CDC: Change Data Capture) | 트랜잭션 로그 파일 캡처·전송 |
14 스테이트풀(Stateful) vs 스테이트리스(Stateless) 데이터 트랜잭션
| 구분 | 스테이트풀 (Stateful) | 스테이트리스 (Stateless) |
|---|---|---|
| 정의 | 현재 상태(State)에 대한 정보를 저장 | 데이터·세션을 저장하지 않음. 과거 상태에 의존하지 않음 |
| 특징 | 이전 요청과의 연관성 유지. 세션 지속적 관리 | 각 요청이 독립적·자기 완결적 |
| AWS 서비스 |
Amazon ElastiCache for Redis Amazon RDS |
AWS Lambda Amazon API Gateway Amazon S3 |
15 Domain 1 수집 단계 전체 AWS 서비스 한눈에 보기
📥 Domain 1 · Perform Data Ingestion — AWS Services Overview
🌊Kinesis
Data Streams실시간 수집·저지연
Data Streams실시간 수집·저지연
🔥Kinesis
Data Firehose버퍼링 전달
Data Firehose버퍼링 전달
🎬Kinesis
Video Streams비디오 스트림
Video Streams비디오 스트림
📊Managed Svc
for Flink스트림 SQL 분석
for Flink스트림 SQL 분석
🤖Kinesis
Agent파일→스트림
Agent파일→스트림
🐘Amazon MSKKafka 관리형
🔄AWS GlueETL 완전관리형
🐘Amazon EMR빅데이터·Hadoop
🔌Amazon
AppFlowSaaS 통합
AppFlowSaaS 통합
🔀AWS DMSDB 마이그레이션·CDC
📁AWS Transfer
FamilyFTP·SFTP→S3
FamilyFTP·SFTP→S3
🔗AWS
DataSync온프레미스→AWS
DataSync온프레미스→AWS
❄️AWS Snow
Family대량 물리 이전
Family대량 물리 이전
⚡Amazon
EventBridge이벤트 기반 트리거
EventBridge이벤트 기반 트리거
🗄️Amazon S3데이터 레이크·버전관리
반응형
'Stack > AWS' 카테고리의 다른 글
| [AWS DEA] 문제로 공부하기 20 - OpenSearch (0) | 2026.03.16 |
|---|---|
| [AWS DEA] Domain 1 데이터 변환 및 처리 완전 정리 (1) | 2026.03.16 |
| [AWS DEA] Data Engineering Fundamentals (with AWS Toolkit) (0) | 2026.03.15 |
| [AWS DEA] 문제로 공부하기 19 - AppFlow (0) | 2026.03.15 |
| [AWS DEA] 문제로 공부하기 18 - S3-IA + Glacier Flexible Retrieval + 삭제 (0) | 2026.03.15 |