에어플로우 없이, 끊겨도 자동으로 이어받는 신뢰성 높은 ETL을 설계한 이야기 1. 만들게 된 이유 국립중앙도서관(NLK) 은 서지정보API를 통해 한국에 등록된 모든 도서의 서지 데이터를 공개하고 있다. 나는 2000년 1월부터 2024년 12월까지, 즉 25년치 전체 데이터를 PostgreSQL(Supabase) 에 저장해 보고 싶었다. 처음엔 단순히 “API를 루프 돌리면 되겠지” 싶었다. 하지만 실제로는 아래 문제들을 해결해야 했다. 호출 제한(rate limit)과 연결 끊김(timeout) 25년 × 12개월 = 300개월 분량의 데이터 EC2 연결이 중간에 끊기는 문제 수백만 건 JSON의 중복 삽입 방지 2. NLK API 이해하기 참고: 국립중앙도서관 서지정보 API 문서 ...
역할 dbt가 잘함 Python이 더 낫다 정형 데이터 정제 (staging) ✅ 가능은 하지만 불편함 마트 테이블 구조 설계 ✅ 가능은 함 사용자별로 달라지는 계산 ❌ 불편함 ✅ 매우 유연함 점수화, 조건 매칭, if-else 로직 ❌ 매우 번거로움 ✅ 적합 사용자 입력 기반 필터링 ❌ 불가능 ✅ 핵심 기능 추천 이유 설명, 로직 튜닝 ❌ ✅ 완전 맞춤형 구현 가능 예를 들어 -- dbt에서는 이런 로직이 아주 힘들다... SELECT CASE WHEN user.age BETWEEN policy.min_age AND policy.max_age THEN 30 ELSE 0 END + CASE WHEN user.income < policy.income_ceiling THEN 25 ELSE 0 END + ... dbt에서는 “user”란 존재 자체가 없음 dbt는 “모든 사용자에게 동일하게 적용되는 모델”을 설계하는 도구 반면 Python에서는 사용자가 입력할 때마다 추천 결과가 달라지게 만들 수 있음 👉 dbt는 정적(Static) 모델링에 적합하지만 사용자 입력 기반의 동적(Dynamic) 추천 시스템은 Python이 더 났다. ...
✨ 프로젝트 개요 핀테크 회사를 가정해, 카드사 데이터를 자동으로 집계 → 정제 → 분석하는 배치 파이프라인을 구축해보았다. 실제 데이터를 사용할 수는 없었기에 Faker를 활용해 가상의 거래 데이터를 생성했지만, 전체적인 데이터 흐름과 구조를 설계하는 데에는 충분하다고 생각된다. 🎯 목표 “Airflow를 활용해 현실적인 금융 데이터를 Spark로 처리하고, 저장 및 분석까지 가능한 자동화된 파이프라인을 만들어보자.” 단계 설명 작업 데이터 생성 원시 데이터 준비 Faker로 신용카드 거래 데이터 생성 데이터 수집 저장 위치로 이동 S3에 업로드 (raw) 데이터 처리 정제, 집계 PySpark로 지역별 거래금액 집계 데이터 저장 가공 후 저장 S3에 Parquet 저장 (processed) 데이터 분석 쿼리용 구조 구성 Athena로 테이블 생성 및 SQL 가능 자동화 반복 처리 가능하게 설정 Airflow로 DAG 작성 🔧 기술 스택 오케스트레이션: Apache Airflow 가상 데이터 생성: Python, Faker 데이터 처리: Apache Spark (PySpark) 데이터 저장: AWS S3 데이터 쿼리: AWS Athena 인프라: Docker, Terraform 🧩 아키텍처 구성 가상 데이터 생성 → S3 업로드 → Spark 변환 → S3 저장 → Athena로 쿼리 Python의 Faker 라이브러리로 가상의 신용카드 거래 데이터 CSV 생성 ...