들어가며이전 포스팅에서는 로컬 Kafka를 띄우고 Producer가 메시지를 보내는 것 까지 검증했다.하지만 그 상태에는 두 가지 한계가 있었다. Producer를 사람이 직접 실행한다 - 터미널에서 `python dummy_generator.py`를 쳐야하고, 터미널을 닫으면 죽는다.토픽을 사람이 직접 생성한다 - `./kafka-topics.sh`를 수동으로 실행해야 한다.실시간으로 데이터가 계속 흘러야 하는 시스템에서 사람이 매번 명령을 친다는 건 운영 관점에서 약점이다.이번 포스팅에서는 이 둘을 컨테이너로 만들어 `docker compose up`한 번으로 전체 파이프라인 입구가 자동으로 뜨게 만든다. 목표 구성:docker compose up -d→ Kafka 기동→ (healthy 대기) → ..
들어가며이전 포스팅에서 두 가지 원천 데이터 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..
0. 강의 목차1. Airflow 3.0 Architecture 핵심: 역할 분리 철학, 전체 학습 로드맵2. DAG Parsing, Execution: "언제 읽히고, 언제 실행 되는가?"3. 왜 Docker로 Airflow를 실행하는가?: 실무 관점에서 Docker를 써야 하는 이유4. Docker & Docker Compose 설치: 개발 환경 구성5. Airflow 3.0 Docker Compose 실행: Airflow Docker 컨테이너들 띄우기6. Web UI 접속 & Scheduler 로그 확인: Web UI 구조, Scheduler 로그로 실행 흐름추적 Airflow 3.0 Architecture 핵심1-1. Control Plane & Execution Plane (역할 분리)Airfl..
- Total
- Today
- Yesterday
- Prodcuder DAG
- Unity Catalog
- Glue
- docker
- DAG
- RDD
- Backfill
- 데이터파이프라인
- Daynamic Task
- lakehouse
- elasticip
- spark
- lake house
- Data Pipeline
- DataSet
- Data Engineerring
- Consumer DAG
- catchup
- Spark structured streaming
- iceberg
- Databricks
- s3
- Glue ETL
- AWS
- airflow
- AWS Glue Catalog
- de
- kafka
- Data Dngineering
- Data engineering
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
