육각형개발자

들어가며우선 Silver 레이어 구축은 다른 레이어보다 고려해야할 부분들이 많고,중요한 기능들이 있기에, 여러 포스팅으로 나눠 적어볼 예정이다. (현재 작성 시점으론 3개 포스팅 계획중) Bronze에서 raw 데이터를 S3에 영구 저장했다.하지만 그 데이터는 분석에 바로 쓸 수 없는 상태이다. Bronze에 저장된 것:value = '{"campaign_id":10046,...}' (dummy)value = '{"campaign":9100690,"cost":0.00003,"cat1":...}' (criteo) → JSON 문자열 덩어리, 두 원천의 모양이 다름 Silver의 일은 이 raw를 분석 가능한 깨끗한 테이블로 바꾸는 것이다.Bronze(받아서 쌓기)나 Gold(집계)보다 신경 쓸 게 많..

들어가며Bronze 레이어를 만들면서 설정에 이런 줄이 있었다..config("spark.sql.catalog.glue.catalog-impl", "org.apache.iceberg.aws.glue.GlueCatalog")데이터는 S3에 parquet로 저장되고,Iceberg는 `metadata.json`에 스키마, 파티션, 파일목록을 다 가지고 있다. 그래서 자연스러운 의문이 들었다.Iceberg가 metadata에 테이블 정보를 다 들고 있는데, Glue Catalog가 왜 또 필요하지?이 의문이 사실 카탈로그의 본질을 찌른다고 한다. (**와우 정말 핵심을**)결론부터 말하면 - 카탈로그가 아는 것과 metadata.json이 아는 것은 다르다. 이 글은 그 차이를 푼 기록이다. 솔직히..

들어가며이전 단계까지 Producer가 Kafka로 이벤트를 보내는 것을 확인했다.하지만 Kafka는 버퍼일 뿐이라, retension이 지나면 메시지가 사라진다. 데이터를 가지고 분석을 하려면 Kafka의 이벤트를 어딘가에 영구 저장해야 한다. 이번 포스팅은 그 첫 영구 저장 계층인 Bronze 레이어를 만든 과정이다.Producer → Kafka → 현재 단계: [Bronze] → Silver → GoldBronze의 원칙은 단 하나 - raw 그대로 저장.변환-정제는 다음 계층(silver)의 몫이다.1. 핵심 결정 ① - 컨슈머를 어디서 돌릴 것인가처음엔 막연히 AWS Glue Streaming으로 적재하면 될거라고 생각했다.다만 근본적인 문제에 부딪혔다.클라우드의 Glue는 내 맥북의 `loca..

들어가며이전 포스팅에서는 로컬 Kafka를 띄우고 Producer가 메시지를 보내는 것 까지 검증했다.하지만 그 상태에는 두 가지 한계가 있었다. Producer를 사람이 직접 실행한다 - 터미널에서 `python dummy_generator.py`를 쳐야하고, 터미널을 닫으면 죽는다.토픽을 사람이 직접 생성한다 - `./kafka-topics.sh`를 수동으로 실행해야 한다.실시간으로 데이터가 계속 흘러야 하는 시스템에서 사람이 매번 명령을 친다는 건 운영 관점에서 약점이다.이번 포스팅에서는 이 둘을 컨테이너로 만들어 `docker compose up`한 번으로 전체 파이프라인 입구가 자동으로 뜨게 만든다. 목표 구성:docker compose up -d→ Kafka 기동→ (healthy 대기) → ..

내가 헷갈린 지점프로젝트에서 Kafka 메시지를 S3에 적재하는 단계를 설계하면서 이런 생각이 들었다."Kafka → S3 적재에 Spark Structured Streaming을 쓰려고 했는데 왜 AI는 Glue Streaming Job을 쓰라고하지?" Glue라는 이름만 보고 Spark와 관계없는 별도 기술처럼 보였고, 둘이 다른 기술이라고 착각했다.결론부터 말하면 Glue Structured Streaming Job은 Spark Structured Streaming 위에서 동작한다.대립 관계가 아니라 포함 관계다.Spark Structured Streaming이란Apache Spark의 스트리밍 처리 API다.Kafka 같은 메시지 큐에서 데이터를 읽어 실시간으로 처리하고 저장하는 코드를 작성하는 ..

들어가며이전 포스팅에서 두 가지 원천 데이터 Producer를 완성했다.`dummy_generator.py` - OpenRTB 형식의 합성 광고 이벤트 생성기`criteo_producer.py` - Criteo Attribution Dataset 재생기이번 포스팅에서는 이 Producer들이 실제로 메시지를 보낼 Kafka 환경을 로컬에 구성하고, 메시지가 정상적으로 흐르는지 end-to-end로 검증한다.왜 로컬 Kafka인가최종 목표는 EKS 위에 Kafka 클러스터를 올리는 것이다.하지만 개발 단계에서 매번 클라우드 환경에 배포하면 검증 사이클이 느려진다. (그리고 비싸다...)로컬 Docker로 먼저 검증하고, 이후 전환할 때는 config.py의 몇가지 설정만 바꾸면 된다. KRaft vs Zo..

학습 내용메달리온 아키텍쳐 중 Bronze - Silver 단계까지 만든건 아래 파이프라인이다.Kafka (ad-events) ↓ [Spark Structured Streaming]Raw Zone (Parquet 파일) ← Bronze ↓ [Spark Batch - raw_to_processed]processed_events (Iceberg) ← Silver ↓ [Spark Batch - processed_to_campaign_summary]campaign_summary (Iceberg) ← Gold광고 이벤트 데이터가 Kafka에서 시작해서 3개 계층을 거쳐 최종 KPI 지표가 되는 흐름문제conversion(전환)이 며칠 뒤에 도착하는 문제가 발생한다...

원천 데이터 구성원천 데이터는 두 가지다.소스역할Criteo Attribution DatasetHuggingFace 제공, 약 1,650만 건의 클릭 데이터. 실시간처럼 재생한다.더미 이벤트 생성기Python 스크립트로 OpenRTB 형식의 이벤트를 합성 생성. 파이프라인의 주요 볼륨 소스.웹 이벤트는 처음에 후보로 올랐지만 제거했다.실제 유저가 클릭해야 이벤트가 발생하기 때문에 대용량 파이프라인 검증에 적합하지 않다.파일 구성producers/├── common/│ ├── init.py # Python 패키지 인식용 (이 파일이 없으면 import 불가)│ └── schema.py # 공통 이벤트 스키마 (두 Producer가 공유)├── config.py # 모든 설정값 중앙 관리├── dummy_g..