- 각 이해관계자들에게 왜 필요한지, 실사례를 잘 소개함.
- 각 단계나 방식을 비유로 잘 설명해줌. 상황별 데이터 파이프라인 툴을 추천 굿.
- 각 단계별 코드 예시 있음.
*내가 참고하려고 요약함. 정확한 내용은 원문 참고
1. 데이터 파이프라인이란?
- 자동으로 데이터를 하나 이상의 소스에서 하나 이상의 목적지로 이동하는 시스템.
- 그 과정에서 transforming, cleaning, enriching이 동반됨.
2. 주요 구성 요소
- Sources: Customer database(CRM 등), website analytics, API, cloud storage, IoT devices
- Pipeline engine: the middleware layer
- Destinations: Data warehouses, real-time dashboards, SaaS tools
3. 주요 작동 방식
Capture → Transform → Deliver → Monitor
1. Capture (Data Ingestion)
- source system에서 data extraction
- Database
- SaaS tool(Salelsforce, Shopify)
- Event streams(Kafka)
- Cloud storage(AWS S3)
- Batch 방식, Real-time 방식이 있음.
2. Transformation
- Cleaning: 중복값 제거, 오타 fixing, 결측값 handling
- Formatting: 날짜 형식 변경, 이름 정규화, consistency 보장, predfined schema에 field mapping하기
- Enriching: 계산된 필드 합치기, joining table 합치기
- Filtering: 필요한 데이터만 유지, 무관한 정보 제거
3. Delivery
- Data warehouse(Snowflake, BigQuery, Redshift)
- Data lake(Delta Lake, Iceberg)
- BI dashboards, operational tools
- Operational database(MySQL)
- Automated reports, alerts
- ML models for predictions
4. Monitoring & Observability
- Data quality check 필수임. 파이프라인은 시끄럽게 실패하는 게 조용히 잘못된 데이터 내놓는 것보다 나음..
- Row count, Null rate, Freshness, Schema drift 등등
- Population Stability Index (PSI) for distribution monitoring: 두 시점의 데이터 분포가 얼마나 달라졌는지를 하나의 숫자로 나타내는 지표
4. ETL vs. ELT: process 순서에 따른 접근
1. ETL
- Extract → Transform → Load
- Raw data를 transform한 후에, destination으로 들어감
- data transformation이 복잡하고 안정적인 경우
- 저장 용량 제한된 경우
2. ELT
- Extract → Transform → Load
- Raw data가 warehouse 먼저 들어감, 이후에 transformation
- big data 혹은 real-time stream으로 작업하는 경우
- 저장 비용은 저렴, compute 비용은 비싼 경우
- 다양하게 데이터 분석 원하는 경우
- dbt, Snowflake, BigQuery, Redshift 등 클라우드 플랫폼 쓰는 경우
5. Batch vs. Real-Time: process 방식
1. Batch pipelines
- 계획된 주기마다 process data in chunks(e.g., daily, weekly, hourly)
- trigger: 특정 시각
- 높은 data latency(hours or more)
- compute-intensive 할 수 있음 / cloud 비용 높거나
- 예시: Daily sales reports, Monthly financial summaries, CRM data 1일 1회 syncing, Weekly model retraining, Daily feature generation for ML
2. Real-Time(Streaming) Pipelines
- 계속 돌아감
- trigger: event(transaction, 유저 클릭, 센서의 리딩)
- 밀리sec or sec 정도 latency
- 예시: fruad detection, real-time segmentation / recommendation engines, IoT sensor monitoring, Live dashboards
3. Micro-batch Pipelines
- batch, real-time의 중간
- 5-15분마다 process data
오늘 인사이트, 느낀 점
- 어제 읽었던 컬리, 토스증권 아티클이 좀 더 이해됨. 다시 읽어봐야지..
- MVP 프로젝트: 리뷰 태깅 확실히 배치가 적절한 듯 + 전에 했던 프로젝트랑 연관지을 수 있어서 재밌었음
- 툴과 솔루션이 굉장히 많다. 일단 비기너로서, Make랑 Zapier 사부작거려야겠다.
- 오늘 배운 것들:
- ensuring uptime, scalability
- marketing attribution
- timely data
- CRM, ERP
- CDC, Kafka event stream
- But without a way to reliably move data across systems, all that information becomes siloed, stale, or unusable
- Marketing teams use pipelines to pull fresh data from platforms like Meta Ads, Google Ads, and Shopify into dashboards for near-instant reporting
- painfully manual and error-prone
- on-premises servers
- Customer churn analysis
- Pulling the data from the source — querying a database, calling an API endpoint, reading a file
- ACID-compliant data lake tables