S(*). Architect

ETL vs ELT

학습 목표ETL과 ELT에서 변환이 일어나는 위치를 설명할 수 있다.warehouse layering (staging · intermediate · marts)으로 역할을 나눌 수 있다.dbt가 warehouse 안 SQL DAG·테스트를 담당하는 방식을 설명할 수 있다.orchestration (Airflow·Dagster)과 transform 엔진의 역할 분리를 말할 수 있다.5·6편 Spark 출력을 warehouse 적재와 연결해 설계할 수 있다.문제 상황Spark에서 join·집계 후 JDBC bulk load — warehouse는 거의 idle, 재처리는 Spark만 다시변환된 테이블만 적재 — 원본이 warehouse에 없어 컬럼 추가·replay 때 소스부터 다시Airflow DAG 안에..

Spark Structured Streaming

학습 목표Structured Streaming이 unbounded 입력을 항상 켜진 job으로 처리하는 방식을 설명할 수 있다.micro-batch 실행 모델과 trigger·checkpoint 역할을 구분할 수 있다.event time·watermark로 늦게 도착한 이벤트를 다룰 수 있다.window 집계와 sink output mode를 선택할 수 있다.Kafka → Spark streaming → alert·table 파이프라인 초안을 설계할 수 있다.문제 상황5편 배치로 어제 dt 집계는 되는데 — 1분 단위 이상탐지는 cron으로 불가Kafka consumer lag는 쌓이는데 Spark job은 하루 한 번만 돈다processingTime 윈도우 썼더니 재시작 후 집계가 두 배 — check..

학습 목표Spark가 분산 배치 처리에서 process 레이어를 담당하는 방식을 설명할 수 있다.transformation과 action·lazy 실행을 구분할 수 있다.partition·shuffle이 병렬성·비용에 미치는 영향을 설명할 수 있다.RDD와 DataFrame API 선택 기준을 말할 수 있다.일일 집계·backfill 배치 job 초안을 설계할 수 있다.문제 상황어제 parquet 10TB — 단일 서버 pandas로 OOM, cron 12시간 초과groupBy(user_id) 후 디스크 폭발 — shuffle이 뭔지 모름Spark job 로그에 200 stages — count()마다 전체 재실행partition 1개로 읽고 200 executor — 199개 idleKafka에서 co..

학습 목표topic·partition·offset으로 Kafka 로그 모델을 설명할 수 있다.partition key와 ordering 범위를 설계할 수 있다.consumer group으로 병렬 소비·lag를 이해할 수 있다.retention·replay로 backfill·재처리 경로를 설계할 수 있다.앞 편 ingest 레이어에서 Kafka가 어떤 역할인지 연결할 수 있다.문제 상황앱이 DB에 직접 INSERT — 피크에 WAL·lock 포화, 분석 쿼리와 경합RabbitMQ로 이벤트 보냈는데 한 consumer만 — 처리량 천장, 메시지 유실 걱정“Kafka 썼다” — topic 하나에 파티션 1개, consumer 10개인데 9개 idleorder_id 순서가 중요한데 전역 순서를 기대 — part..

학습 목표bounded·unbounded 데이터를 구분하고 처리 모델을 맞출 수 있다.배치·스트림 파이프라인의 수집·처리·출력 차이를 설명할 수 있다.latency와 throughput 트레이드오프로 도구·스케줄을 선택할 수 있다.리포트·알림·학습·재처리 등 use case에 맞는 쪽을 고를 수 있다.문제 상황야간 전체 SELECT는 잘 되는데 — 5분 안 이상 징후를 잡아야 함Kafka에 실시간 넣었지만 어제 데이터와 합쳐 feature table을 만들어야 함 — 경로가 둘로 갈라짐“스트리밍이 최신”이라 Spark Streaming만 썼더니 — 일일 리포트·backfill이 더 비쌈micro-batch 1분인데 SLA는 10초 — 진짜 스트림인지 배치인지 구분 못 함CDC는 unbounded인데 do..

학습 목표volume·velocity·variety로 OLTP 한계와 분석·ML 경로 분리 필요를 판단할 수 있다.scale-up과 scale-out을 RDB·Kafka·Spark·object storage 관점에서 비교할 수 있다.ingest · process · store · serve 역할 분리로 파이프라인을 설계할 수 있다.중앙 데이터 플랫폼과 data mesh의 트레이드오프를 개요 수준에서 설명할 수 있다.문제 상황일일 2억 행 클릭 로그를 PostgreSQL에 INSERT — WAL·디스크 포화, OLTP 지연 폭증야간 SELECT 리포트가 주문 API와 같은 DB — 피크에 lock·I/O 경합“서버 스펙만 올리자” — 64 vCPU까지 갔는데 쓰기 TPS 천장, 비용만 증가Kafka·Spa..

학습 목표빅데이터 파이프라인과 머신러닝·알고리즘이 하나의 시리즈에서 어떻게 이어지는지 설명할 수 있다.source → ingest → process → feature → train → infer 흐름을 그릴 수 있다.Database·Architecture·ELK·AIOpsMLOps와 본 시리즈의 역할 분리를 설명할 수 있다.Kafka·Spark·lakehouse·sklearn·PyTorch 등 키워드가 로드맵 어느 Part에 있는지 짚을 수 있다.25편 로드맵을 보고 학습 순서를 잡을 수 있다.문제 상황일일 수억 행 이벤트 — PostgreSQL INSERT만으로는 배치 분석·재처리가 버거움CDC로 Kafka에 넣었는데 consumer lag 폭증 — partition·group 설계를 모름Spark j..