마지막 주차다. 오늘은 시험 비중이 가장 큰 두 영역을 한 흐름으로 복습한다. 개별 서비스 암기보다 "데이터가 들어와 적재되고 변환되어 저장되는 파이프라인"으로 묶어 보는 것이 합격의 핵심이다. 전형적인 시험 시나리오는 아래 다섯 칸 중 한두 칸을 비워 놓고 묻는다.
수집 : Kinesis/Firehose(스트리밍) 또는 DMS(CDC) → S3 raw 존카탈로그 : Glue 크롤러가 스키마 추론 → Data Catalog 등록변환 : Glue 잡(북마크로 증분) 또는 EMR → S3 curated 존(Parquet)저장/조회 : Athena 로 즉석 쿼리, 또는 Redshift 로 로드해 BI거버넌스 : Lake Formation 으로 팀별 세분화 권한
시험 가이드는 두 도메인을 여덟 개 태스크로 나눈다. 이 트랙의 어느 주차가 어느 태스크에 닿는지 알면 약한 곳을 골라 되돌아갈 수 있다.
시험 가이드 태스크 묻는 것 되돌아갈 곳 1.1 데이터 수집 스트림·배치 원천 읽기, 스케줄·이벤트 트리거, 스로틀 대응, 팬아웃, 재생 가능성 Week 2·3 1.2 변환·처리 엔진 선택(EMR·Glue·Lambda·Redshift), 포맷 변환, 비용, 변환 실패 진단 Week 4·5 1.3 파이프라인 오케스트레이션 Step Functions·MWAA·Glue 워크플로·EventBridge, 알림(SNS·SQS) Week 5 Day 3 1.4 프로그래밍 개념 IaC, CI/CD, Lambda 동시성, SAM, 분산 컴퓨팅 아래 "태스크 1.4" 절 2.1 스토어 선택 비용·성능·접근 패턴별 스토어, Spectrum·페더레이션·구체화 뷰, 오픈 테이블 포맷, 벡터 인덱스 Week 6·7 2.2 카탈로그 Glue Data Catalog, 크롤러, 파티션 동기화 Week 4 Day 1 2.3 수명주기 COPY/UNLOAD, S3 Lifecycle, 버저닝, DynamoDB TTL Week 6 Day 4 2.4 모델·스키마 진화 Redshift·DynamoDB 스키마 설계, 스키마 변환, 파티셔닝·압축 Week 1 Day 4, Week 4 Day 4
수집은 크게 스트리밍 과 배치 로 나뉜다. 시험은 "실시간/초 단위 지연"이라는 키워드가 보이면 스트리밍, "주기적/대량/시간 단위"가 보이면 배치를 묻는다.
요구사항 키워드 적합 서비스 이유 실시간 스트리밍, 커스텀 컨슈머, 순서 보장 Kinesis Data Streams 샤드 기반, 보존 후 재처리 가능 스트리밍을 S3/Redshift로 무관리 적재 Data Firehose 완전관리형, 버퍼링·변환·배달 Kafka 호환 스트리밍 Amazon MSK 오픈소스 Kafka 마이그레이션 대량 파일 일괄 적재 S3 + Glue 배치 ETL의 기본 DB 변경분(CDC) 실시간 복제 AWS DMS 소스 DB → 타깃 지속 복제
💡 관련 이론 : Kinesis Data Streams는 "직접 소비·재처리·순서"가 필요할 때, Firehose는 "무관리 적재"가 목적일 때 고른다. Firehose는 샤드/컨슈머 개념이 없고 버퍼 크기·시간으로 목적지에 자동 배달한다.
수집 서비스를 고른 순간 재생 가능 범위 도 함께 정해진다. 시험 가이드가 "수집 파이프라인의 재생 가능성(replayability)"을 따로 적어 둔 이유다.
수집 경로 과거 데이터를 다시 흘릴 수 있는가 근거 Kinesis Data Streams 보존 기간 안에서 가능 기본 24시간, 최대 365일 MSK 토픽 보존 설정 안에서 가능 오프셋을 되감아 다시 읽는다 DynamoDB Streams 24시간까지만 보존 기간을 늘릴 수 없다 Data Firehose 불가 보존·재처리 기능이 없다. 소스를 KDS 로 두거나 S3 원본에서 다시 처리한다 DMS CDC 원본 DB 의 로그 보존 범위 안에서 트랜잭션 로그를 읽는 구조다 S3 raw 존 언제든 가능 원본을 불변으로 보관하는 이유
재처리 요구가 보존 기간을 넘으면 답은 스트림이 아니라 S3 원본 + 배치 재처리 다. 그래서 "실시간 분석 + 원본 보관" 조합(KDS → 실시간 소비, 같은 스트림을 Firehose 가 S3 로 적재)이 반복해서 정답으로 나온다.
변환 엔진 선택은 "서버리스 여부 + 데이터 규모 + 코드 스타일"로 갈린다.
AWS Glue : 서버리스 Spark ETL. 작은~중간 규모, 스케줄·트리거 기반 ETL의 기본 선택. Glue 북마크(job bookmark) 로 이미 처리한 데이터를 건너뛰는 증분 ETL이 핵심 기능.Amazon EMR : 관리형 Hadoop/Spark 클러스터. 대규모, 세밀한 튜닝, 기존 Spark/Hive 코드 재사용 시. 비용 최적화는 Spot 인스턴스 + 인스턴스 플릿.Glue Studio / DataBrew : 시각적/노코드 변환. DataBrew는 분석가용 데이터 정제·프로파일링.
# Glue 북마크: 마지막 실행 이후 신규 데이터만 처리 (증분 ETL) job.init(args[ 'JOB_NAME' ], args) dyf = glueContext.create_dynamic_frame.from_catalog( database = "raw" , table_name = "events" , transformation_ctx = "dyf" # 북마크가 이 ctx 기준으로 상태 추적 ) # ... 변환 ... job.commit() # commit 시점에 북마크 상태 저장
💡 관련 이론 : Glue 북마크는 transformation_ctx와 job.commit()이 함께 있어야 동작한다. "증분 ETL", "이미 처리한 데이터 재처리 방지", "스케줄 잡이 매번 전체를 다시 읽음" 같은 문제는 북마크 활성화로 푸는 것이 정답이다.
북마크를 정답으로 고르기 전에 확인할 조건이 세 가지 있다(Week 4 Day 2).
북마크 옵션의 기본값은 Disable 이다. 코드에 transformation_ctx와 job.commit()이 있어도 옵션이 꺼져 있으면 매번 전체를 읽는다.
S3 소스는 객체의 최종 수정 시각 으로, JDBC 소스는 북마크 키 로 신규분을 가린다. 그래서 JDBC 기존 행의 UPDATE·DELETE 는 잡지 못한다. "변경까지 반영"이면 DMS CDC 다.
job.commit() 전에 실패하면 상태가 갱신되지 않아 다음 실행이 같은 입력을 다시 읽는다. 북마크도 본질은 at-least-once 이므로 출력은 덮어쓰기나 MERGE 처럼 멱등하게 설계한다.
이 트랙에서 따로 주차를 두지 않은 태스크다. 문법이 아니라 "어떤 도구가 무슨 일을 하는가"를 묻는다. 시험 가이드는 특정 언어의 문법 지식을 범위 밖으로 명시한다.
주제 알아 둘 것 IaC CloudFormation 은 템플릿으로, CDK 는 프로그래밍 언어로 스택을 정의한다. 같은 파이프라인을 환경마다 반복 배포하는 수단이다 AWS SAM Lambda·Step Functions·DynamoDB 테이블 같은 서버리스 리소스를 짧은 문법으로 묶어 패키징·배포한다. 배포 결과는 CloudFormation 스택이다 CI/CD 파이프라인 코드의 구현·테스트·배포 자동화. 데이터 파이프라인도 버전 관리와 테스트의 대상이다 Lambda 동시성 예약 동시성은 함수가 쓸 수 있는 동시 실행 수의 상한이자 확보분이고, 프로비저닝된 동시성은 실행 환경을 미리 데워 콜드 스타트를 없앤다 Lambda 스토리지 임시 저장은 /tmp(512MB~10,240MB), 호출 간에 공유할 파일은 EFS 를 마운트한다(VPC 연결 필요) 스로틀 대응 DynamoDB·RDS·Kinesis 의 한도 초과는 지수 백오프와 지터를 넣은 재시도, 배치 크기 조절, 용량 모드 변경으로 다룬다
하류 시스템(RDS 등)이 감당할 수 있는 연결 수가 작다면 Lambda 의 예약 동시성으로 상한을 건다. 동시성을 무제한으로 두면 Lambda 가 늘어나는 만큼 DB 연결이 고갈된다.
스토어는 "구조/접근 패턴/쿼리 방식"으로 매핑한다.
요구사항 서비스 핵심 비정형/반정형 레이크, 무한 확장, 저렴 Amazon S3 데이터 레이크 기반 스토리지 대규모 분석 쿼리, 컬럼형 MPP DW Amazon Redshift 페타바이트급 OLAP S3 직접 SQL 쿼리, 서버리스 Amazon Athena Trino(구 Presto) 기반, 인프라 무관리 키-값 초저지연, 서버리스 DynamoDB 단일 자릿수 ms 지연 관계형 OLTP RDS / Aurora 트랜잭션 처리
Redshift는 시험에서 분배 키와 정렬 키를 다룬다.
분배 스타일(DISTSTYLE) : KEY(조인 컬럼 기준 동일 노드 배치로 셔플 감소), ALL(작은 차원 테이블 전체 복제), EVEN(균등 분산), AUTO(Redshift가 자동 선택).정렬 키(SORTKEY) : 범위 필터·시간 범위 쿼리 가속. 존 맵으로 블록 스킵.Redshift Spectrum : S3의 외부 데이터를 로드 없이 Redshift에서 쿼리. 핫 데이터는 Redshift, 콜드 데이터는 S3에 두는 계층 분리.
CREATE TABLE fact_sales ( sale_id bigint , customer_id bigint , sale_ts timestamp , amount decimal ( 10 , 2 ) ) DISTSTYLE KEY DISTKEY (customer_id) -- 고객 차원과 조인 최적화 SORTKEY (sale_ts); -- 시간 범위 쿼리 가속 큰 팩트 테이블과 작은 차원 테이블 조인에서 차원이 작으면 DISTSTYLE ALL, 두 큰 테이블 조인이면 공통 조인 키로 양쪽에 DISTKEY를 둬 노드 간 데이터 이동(셔플)을 없앤다.
네 가지 분배 스타일과 두 가지 정렬 키가 실제로 어떻게 동작하는지 한 단계 더 들어간다.
항목 동작 치르는 값 AUTO분배 스타일을 지정하지 않으면 적용되는 기본값. 작은 테이블은 ALL 로 시작하고, 커지면 KEY 로, 마땅한 키가 없으면 EVEN 으로 백그라운드에서 바꾼다 직접 통제하지 않는다 EVEN컬럼 값과 무관하게 라운드 로빈으로 나눈다. 조인에 참여하지 않는 테이블에 맞다 조인 시 재분배 KEY같은 키 값을 같은 슬라이스에 둔다. 양쪽 테이블을 조인 컬럼으로 분배하면 조인이 로컬에서 끝난다 키가 쏠리면 특정 슬라이스만 커진다 ALL테이블 전체를 모든 노드에 복사한다 저장 공간이 노드 수만큼 곱해지고 적재·갱신이 느려진다. 자주 바뀌지 않는 테이블에만 쓴다 복합(Compound) 정렬 키 기본값. 조건이 정렬 키 컬럼의 앞쪽부터 쓰일 때 효율적이다 뒤쪽 컬럼만 쓰는 조건에는 효과가 작다 인터리브(Interleaved) 정렬 키 각 컬럼에 같은 가중치를 준다. 조건이 어느 컬럼으로 들어와도 된다. 최대 8개 컬럼 VACUUM REINDEX가 오래 걸린다. 자주 갱신되는 테이블에는 복합이 권장된다
존 맵의 실체: Redshift 는 컬럼 데이터를 1MB 블록 으로 저장하고 블록마다 최솟값·최댓값을 메타데이터로 둔다. 범위 조건이 들어오면 그 값만 보고 블록을 통째로 건너뛴다. 정렬되어 있지 않으면 값이 여러 블록에 흩어져 건너뛸 블록이 없다.
AWS 는 SORTKEY AUTO와 DISTSTYLE AUTO로 만들어 자동 테이블 최적화에 맡기는 것을 권장한다. 다만 시험 지문이 "노드 간 데이터 이동을 줄여라"처럼 원인을 짚으면 분배 키를 직접 고르는 보기가 답이다.
ALL의 단서는 "작다"만이 아니라 "작고 잘 바뀌지 않는다" 다. 큰 테이블이나 자주 갱신되는 테이블에 ALL 을 주는 보기는 오답이다.
데이터 레이크의 권한·메타데이터 관리다.
Glue Data Catalog : Athena·Redshift Spectrum·EMR이 공유하는 중앙 메타스토어. 크롤러가 스키마를 자동 추론.Lake Formation : 데이터 레이크의 중앙 집중식 세분화 권한 . 테이블·컬럼·행·셀 수준 권한과 LF-Tag 기반 정책. S3 객체별 IAM 정책을 일일이 쓰는 대신 중앙에서 데이터 권한을 관리.
"여러 팀이 S3 데이터 레이크를 공유하는데 컬럼/행 단위로 접근을 통제하고 한곳에서 관리하고 싶다"는 시나리오의 정답은 거의 항상 Lake Formation이다. IAM 버킷 정책만으로는 컬럼·행 수준 제어가 불가능하다.
"Redshift 에 데이터를 넣는다"는 지문은 원천과 신선도에 따라 답이 갈린다.
길 쓰는 때 기억할 점 COPY (S3 → Redshift)배치 적재의 기본 파일이 여러 개이거나 분할 가능하면 병렬로 적재한다. GZIP 으로 압축한 CSV·JSON 은 자동 분할이 안 되므로 비슷한 크기로 여러 개로 나누고, 파일 수를 슬라이스 수의 배수로 맞춘다 Firehose → Redshift 스트림을 코드 없이 적재 내부적으로 S3 에 쌓은 뒤 COPY 를 실행한다 스트리밍 수집 KDS·MSK 를 낮은 지연으로 직접 조회 S3 를 거치지 않고 구체화 뷰로 들어온다. 뷰를 새로 고칠 때 스트림을 읽는다 Spectrum S3 데이터를 로드하지 않고 조회 외부 테이블은 Glue Data Catalog 를 쓴다. 프로비저닝 클러스터에서는 스캔한 데이터 양으로 과금된다 페더레이션 쿼리 운영 RDS/Aurora 의 최신 데이터를 옮기지 않고 조인 원격 DB 에 쿼리 부하가 간다 구체화 뷰 반복되는 무거운 집계를 미리 계산 결과를 저장해 두고 새로 고친다 UNLOAD (Redshift → S3)결과를 레이크로 내보내기 Parquet 으로 내보내면 Athena·Spectrum 이 바로 읽는다
큰 파일 하나를 COPY 하는 것이 느린 이유: 분할할 수 없는 파일은 한 슬라이스가 직렬로 읽는다. Redshift 의 병렬성을 쓰지 못한다.
"핫은 Redshift, 콜드는 S3"의 완성형은 UNLOAD로 오래된 데이터를 Parquet 으로 내보내고 Spectrum 외부 테이블로 이어 붙이는 것이다.
저장소 장치 동작 S3 Lifecycle 전환 정해진 날이 지나면 더 싼 스토리지 클래스로 옮긴다 S3 Lifecycle 만료 정해진 날이 지나면 객체를 삭제한다. 버저닝 버킷에서는 이전 버전 만료 규칙을 따로 둔다 S3 Intelligent-Tiering 접근 패턴을 몰라도 30일·90일 미접근 객체를 자동으로 싼 계층에 둔다 DynamoDB TTL 항목에 적어 둔 만료 시각이 지나면 자동 삭제한다 Kinesis Data Streams 보존 기간 지나면 레코드가 만료된다 Redshift UNLOAD 후 삭제자동 만료가 없으므로 내보내고 지우는 작업을 직접 만든다
S3 스토리지 클래스는 최소 보관 기간 이 함정이다. 그 전에 지우거나 옮기면 남은 기간만큼 요금이 붙는다.
스토리지 클래스 조회 지연 최소 보관 기간 그 밖의 과금 요소 S3 Standard 밀리초 없음 — S3 Standard-IA / One Zone-IA 밀리초 30일 GB 당 조회 요금, 128KB 미만 객체는 128KB 로 과금. One Zone-IA 는 가용 영역 하나에만 저장 S3 Intelligent-Tiering 밀리초(기본 계층) 없음 객체당 모니터링 요금, 조회 요금 없음. 128KB 미만 객체는 자동 계층화 대상이 아니다 S3 Glacier Instant Retrieval 밀리초 90일 GB 당 조회 요금 S3 Glacier Flexible Retrieval 분~시간(복원 필요) 90일 복원 요금 S3 Glacier Deep Archive 시간(복원 필요) 180일 복원 요금
Lifecycle 전환은 위에서 아래로만 흐른다(폭포수 모델). Glacier Deep Archive 에서 다른 클래스로는 규칙으로 되돌릴 수 없고, 복원한 사본을 복사해야 한다.
128KB 보다 작은 객체는 기본적으로 Lifecycle 전환 대상에서 빠진다. 전환 요청 요금이 절감액보다 클 수 있기 때문이다(2024년 9월에 바뀐 기본 동작이므로 옛 자료에는 "Glacier 로는 전환된다"고 나올 수 있다).
Athena 는 Glacier Flexible Retrieval·Deep Archive 에 보관된 객체를 복원 없이 읽지 못한다. "가끔이라도 SQL 로 조회한다"가 조건이면 curated 존을 아카이브 클래스로 내리는 보기는 탈락이다.
2025년 12월에 공개된 시험 가이드 1.1 판은 도메인 2 에 벡터와 오픈 테이블 포맷을 추가했다. 깊이보다 용어 구분을 묻는 수준으로 대비한다.
주제 한 줄 요약 오픈 테이블 포맷(Apache Iceberg) S3 의 파일 묶음을 ACID·시간 여행·행 단위 갱신이 되는 테이블로 다룬다. 컴팩션과 스냅샷 만료 같은 유지보수가 필요하다 Amazon S3 Tables Iceberg 테이블 전용 버킷. 컴팩션 같은 테이블 유지보수를 S3 가 대신한다 벡터화 텍스트 등을 숫자 벡터(임베딩)로 바꿔 의미가 비슷한 것을 찾는다. Amazon Bedrock 지식 기반이 문서를 쪼개고 임베딩해 벡터 저장소에 넣는 과정이 예시다 HNSW 그래프 기반 벡터 인덱스. 검색이 빠르고 재현율이 높은 대신 메모리를 많이 쓰고 구축이 느리다. Aurora PostgreSQL(pgvector)에서 쓸 수 있다 IVF 벡터를 군집으로 나눠 가까운 군집만 뒤지는 인덱스. 메모리를 덜 쓰고 구축이 빠른 대신 탐색 범위 설정에 따라 재현율이 달라진다 Amazon MemoryDB 내구성을 갖춘 인메모리 키-값 저장소. 빠른 키-값 접근이 단서다 비즈니스 데이터 카탈로그 Glue Data Catalog 가 기술 메타데이터(스키마·위치)를 담는다면, Amazon SageMaker Catalog 는 용어·소유자·설명 같은 업무 맥락을 담는다
증상 원인 조치 스케줄 Glue 잡이 매번 전체를 다시 읽는다 북마크가 Disable(기본값)이거나 transformation_ctx·job.commit() 누락 세 조건을 모두 갖춘다 Athena 에서 어제 데이터가 안 보인다 새 파티션이 Catalog 에 없다 크롤러, ALTER TABLE ADD PARTITION, 또는 파티션 프로젝션 Athena 요금이 데이터 증가보다 빨리 는다 행형 포맷, 파티션 필터 없는 쿼리 Parquet 변환, 날짜 파티션, WHERE 에 파티션 컬럼 Firehose 적재 후 Athena 가 느려졌다 버퍼가 작아 작은 파일이 쏟아진다 버퍼 크기·간격 확대, 주기적 컴팩션 Redshift 조인이 노드 간 재분배로 느리다 조인 컬럼과 분배 키가 어긋났다 양쪽 테이블을 조인 컬럼으로 DISTKEY, 작고 정적인 차원은 ALL Redshift 의 날짜 범위 쿼리가 전체를 스캔한다 정렬 키가 없거나 정렬이 흐트러졌다 날짜 컬럼을 정렬 키로, 흐트러진 정렬은 VACUUM 으로 복구 COPY 가 예상보다 훨씬 느리다 압축된 큰 파일 하나를 직렬로 읽는다 여러 파일로 분할(슬라이스 수의 배수) KDS 특정 샤드만 스로틀 파티션 키 쏠림 카디널리티 높은 키로 변경. 샤드 증설·온디맨드로는 풀리지 않는다 DMS 전체 적재 후 변경분이 오지 않는다 원본 DB 의 로그 설정 누락 binlog ROW·논리 복제·supplemental logging 활성화 30일도 안 된 객체를 IA 로 내렸더니 요금이 늘었다 최소 보관 기간과 조회 요금 접근 패턴을 모르면 Intelligent-Tiering
연습 문제와 겹치지 않는 상황으로, 조건 하나가 바뀌면 답이 달라지는 쌍을 붙였다.
시나리오 결정적 단서 정답 클릭 이벤트를 S3 에 쌓기만 한다 소비자 없음, 운영 최소 Data Firehose 같은 이벤트를 사기 탐지 앱과 추천 앱이 각자 읽는다 여러 소비자, 독립 소비 Kinesis Data Streams(필요하면 향상된 팬아웃) 추가만 되는 주문 로그 테이블에서 신규 행만 매일 가져온다 증가하는 키, 추가 전용 Glue 잡 + 북마크 같은 테이블에서 상태 컬럼이 수시로 바뀐다 기존 행의 변경 DMS CDC 한 달에 몇 번 로그를 SQL 로 조사한다 간헐적, 클러스터 없음 Athena 수백 명이 종일 같은 대시보드를 본다 상시·동시성·예측 가능한 성능 Redshift Redshift 에서 운영 Aurora 의 현재 재고와 조인한다 복제 없이 최신 값 페더레이션 쿼리 Redshift 에서 3년 전 주문을 가끔 조회한다 콜드 데이터, 저장 비용 S3 + Spectrum 세션 데이터를 7일 뒤 자동으로 지운다(DynamoDB) 항목 단위 자동 만료 TTL 접근 빈도를 예측할 수 없는 레이크 객체의 저장 비용을 줄인다 패턴 미상, 운영 최소 S3 Intelligent-Tiering 규정상 7년 보관하되 조회는 거의 없다 장기 보관, 복원 지연 허용 Lifecycle → Glacier Deep Archive 레이크 테이블에서 특정 고객 행만 지우고 갱신한다 행 단위 갱신·삭제, ACID Iceberg 테이블
내일은 이렇게 만든 파이프라인을 안정적으로 운영하고 안전하게 보호하는 도메인 3·4 를 묶어 본다.
재생 가능성(replayability) : 이미 지나간 데이터를 다시 흘려 재처리할 수 있는 성질. 보존 기간이 그 범위를 정한다.북마크 키 : Glue 북마크가 JDBC 소스에서 "어디까지 읽었는지"를 기억하는 기준 컬럼.슬라이스 : Redshift 컴퓨트 노드를 나눈 병렬 처리 단위. 분배 스타일은 행을 어느 슬라이스에 둘지 정한다.셔플(재분배) : 조인·집계를 위해 노드 사이로 행을 옮기는 일. 분배 키가 맞으면 생기지 않는다.존 맵 : 블록마다 저장해 둔 최솟값·최댓값. 조건에 맞지 않는 블록을 읽지 않고 건너뛰게 해 준다.구체화 뷰 : 쿼리 결과를 미리 계산해 저장해 둔 뷰. 새로 고침으로 최신 상태를 따라간다.페더레이션 쿼리 : 데이터를 옮기지 않고 다른 데이터베이스에 있는 테이블을 직접 조회하는 쿼리.최소 보관 기간 : 스토리지 클래스가 요구하는 최소 저장 일수. 그 전에 지우거나 옮겨도 남은 기간만큼 과금된다.TTL : 항목에 적어 둔 만료 시각이 지나면 자동으로 삭제하는 DynamoDB 기능.임베딩 : 텍스트나 이미지를 의미가 반영된 숫자 벡터로 바꾼 것. 벡터 인덱스가 검색 대상으로 삼는다. 📝 연습 문제 선택지를 클릭하면 정답·해설이 펼쳐집니다.
스케줄로 매시간 실행되는 Glue 잡이 S3의 신규 파일만 처리해야 하는데, 매번 전체 데이터를 다시 읽어 비용과 시간이 과도하다. 가장 적절한 해결책은?
A EMR 클러스터로 전환한다 B Glue 잡 북마크를 활성화하고 transformation_ctx와 job.commit()을 사용한다 C S3 버킷을 매시간 비운다 D Athena CTAS로 매번 전체를 다시 만든다 여러 분석 팀이 동일한 S3 데이터레이크를 공유하면서, 특정 테이블의 일부 컬럼(예: 주민번호)은 일부 팀에게만 보이도록 중앙에서 통제하려 한다. 가장 적합한 서비스는?
A S3 버킷 정책에 팀별 컬럼 규칙을 작성 B AWS Lake Formation의 컬럼 수준 권한 C EC2 보안 그룹 D CloudFront 서명 URL 초당 수만 건의 IoT 이벤트를 실시간으로 받아 추가 인프라 관리 없이 자동으로 S3에 Parquet로 버퍼링·변환·적재하려 한다. 가장 적합한 서비스는?
A Amazon Data Firehose B Amazon RDS C AWS Batch D Amazon SQS 표준 큐 페타바이트급 팩트 테이블을 작은 날짜 차원 테이블과 자주 조인한다. 노드 간 데이터 이동(셔플)을 최소화하기 위한 Redshift 분배 설정으로 가장 적절한 것은?
A 두 테이블 모두 DISTSTYLE EVEN B 모든 테이블에 SORTKEY만 지정 C 작은 차원 테이블에 DISTSTYLE ALL D 팩트 테이블을 DynamoDB로 이전 데이터 분석가가 S3에 저장된 로그를 클러스터나 서버를 띄우지 않고 표준 SQL로 즉석 조회하려 한다. 비용은 스캔한 데이터량 기준으로만 내고 싶다. 가장 적합한 서비스는?
A Amazon EMR B Amazon EC2에 직접 설치한 Presto C AWS Glue 크롤러 D Amazon Athena