S(*). Architect

Lakehouse 개요

학습 목표data lake·warehouse·lakehouse의 차이와 선택 기준을 설명할 수 있다.medallion (bronze · silver · gold) 계층을 설계할 수 있다.Delta Lake·Apache Iceberg 같은 open table format이 parquet 위에 주는 ACID를 설명할 수 있다.5·6편 Spark·7편 warehouse와 lakehouse 경계를 맞출 수 있다.문제 상황S3에 parquet 수천 개 — dt=2026-08-01 폴더만 지웠는데 다른 job이 깨진 스냅샷 읽음Snowflake에 raw·mart 둘 다 — 스토리지 비용 폭증, Spark는 export 다시동시 write 두 job — 같은 경로에 overwrite — 행 반쯤 섞인 파일5편 gol..

학습 목표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..

학습 목표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..