이번 포스트에는 batch job에 사용될 수 있는 다양한 데이터파이프라인 조합과 그에 따른 장단점과 고려 사항을 정리해보겠습니다.
아래의 항목들이 포함한 특징을 같이 적어보겠습니다.
- 상황별 배치 파이프라인 구성
- 장단점
- 조직의 규모 및 구성
- 비용
- 확장성
- 백업, 모니터
1. 각 데이터 파이프라인의 구성
흔히 말하는 E(Extract), T(Transform), L(Load) 하는 소스며, 프레임워크며, 저장 장소가 정말 다양하고 비용과 성능 그리고 필요한 비지니스 요건에 따라 달라집니다. 우선 그 종류에 대해서 파악해보고 장단점을 하나씩 확인해보겠습니다.
1) 다양한 소스의 구성
| 소스 |
특징 / 설명 |
예시 |
| RDBMS |
구조화된 정형 데이터 |
MySQL, PostgreSQL, Oracle, MSSQL |
| 로그 데이터 |
반정형/비정형 이벤트 데이터 |
Web server logs, App logs |
| 파일 기반 |
주기적으로 수집되는 데이터 |
CSV, JSON, Parquet, Excel |
| 메시지 큐 |
실시간 스트리밍도 가능하나 batch 적재도 존재 |
Kafka, Kinesis, RabbitMQ |
| API |
외부/내부 시스템 데이터 |
REST API, GraphQL |
| 클라우드 저장소 |
다양한 서비스에서 내보낸 export 데이터 |
S3, GCS, Azure Blob Storage |
2) 다양한 데이터 처리 방법
| 프레임워크 |
특징 / 설명 |
예시 |
| pandas |
직관적이며, 적은 데이터(수GB이내) 처리, 병렬 처리 불가 |
- |
| polars |
병렬 처리가능, rust 기반, 빠르다, lazy execution |
- |
| SQL |
적재 후 마트를 만드는 개념의 SQL로써 사용 가능하며, ANSI SQL이며 각 제품들의 엔진에 따른 SQL 문법이며 function도 사용 가능함 |
AWS Athena, AWS Redshift, GCP Bigquery, Azure Synapse |
| Spark |
병렬 처리 가능하며, sparkSQL로 SQL지원도 가능, 대용량 데이터에 적합 |
AWS EMR, AWS EMR Serverless,
AWS Glue ETL, Azure Data Factory, Azure Databricks, Databricks |
| Hive |
속도가 느린 편이며, 대용량 데이터 안전하게 처리하기에 적합, SQL과 비슷한 HiveQL을 통해 데이터를 처리 |
AWS EMR, AWS EMR Serverless, Azure Data Factory |
| dbt |
SQL중심의 조직인 경우 적합 |
- |
| Python Script |
ETL을 구현한 python script로써 비교적 자유로운 구성이 가능 |
- |
3) 다양한 데이터 저장소
| 데이터 저장소 |
특징 / 설명 |
예시 |
| Data Lake |
ELT 개념에서 우선 적재에 사용되는 개념, S3,Blob 같은 object storage기반으로 파일형태의 데이터를 중간 저장소로 사용 |
AWS S3, Azure Data Lake, GCS |
| Data Warehouse |
MPP DB로 분석을 위한 용도로 높은 쿼리 성능과 일정수준의 트랜잭션 제어 가능 |
GCP BigQuery, AWS Redshift, Azure synapse,SnowFlake |
| Hadoop(HDFS) |
hadoop base의 온프렘 환경의 시스템인 경우 기존의 자원을 활용하는 HDFS를 저장소로써 사용 가능 |
AWS EMR |
| NoSQL |
비정형 또는 반정형 데이터, 빠른 쓰기 성능, 수평 확장성 등을 요구하는 경우에 특히 적합 |
MongoDB, AWS DynamoDB, Cassandra, redis, neo4j |
4) 오케스트레이션 및 스케줄링 도구
| 도구 |
특징 / 설명 |
사용 예시 |
| Airflow |
Python(코드) 기반 DAG 워크플로우 정의, 풍부한 커넥터, 시각화, 강력한 커뮤니티, 3.0버전으로 올라가면서 DAG versioning, 대규모 backfill, 다중 스케줄링, 다중 언어 지원 등 가능해짐 |
on-premise, cloud 환경 어디에서나 사용 가능, 복잡한 파이프라인 관 |
| Dagster |
모듈화된 파이프라인, 타입 시스템, 테스트 지원, UI 제공 |
데이터 품질 관리 중시 팀 |
| Oozie |
Hadoop 에코시스템에 특화된 워크플로우, XML 기반 선언형 정의,UI로 의존성 설정 가능 |
Hadoop, Hive, Spark 등 Hadoop 기반 배치처리에 집중된 환경 |
| AWS Glue |
서버리스, AWS 통합 |
AWS 중심, 자동화된 ETL |
| Crontab |
단순 스케줄링 도구, 시간 기반 트리거 |
조직의 규모가 작을 때, 간단한 스크립트 정기 실행, 복잡한 의존성 없을 때 |
| Argoflow |
쿠버네티스 네이티브 |
k8s 환경 컨테이너 파이프라인 관리 |
| Prefect |
코드 중심, 오류 처리 강화 |
Airflow 대안, 간단 설치 원할 때 |
| Luigi |
Python 간단 파이프라인 |
의존성 단순한 파이프라인 |
| KubeFlow |
ML 특화, k8s 기반 |
머신러닝 워크플로우 자동화 |
5) 모니터링 도구
| 도구 |
특징 / 설명 |
| prometheus & grafana |
사용자 정의 메트릭(성공/실패 카운터 등) 수집, 알림 설정 가능 |
| Cloud managed monitoring Dashboards(CloudWatch, Stackdriver 등) |
각 클라우드 서비스의 작업 상태 메트릭과 알람 제공 |
| ELK Stack (Elasticsearch+Kibana) |
로그에서 실패, 에러 탐지 및 대시보드 작성 가능 |
6) 분석을 위한 도구
| 도구 |
특징 / 설명 |
예시 |
| AWS Athena |
서버리스 제품, Presto 엔진 기반, ANSI SQL 지원, scan당 비용 |
|
| Data Warehouse |
비싼 편이나, 쿼리 성능이 좋음, Redshift Specturm의 경우 scan 당 비용 |
AWS Redshift, GCP BigQuery, Azure synapse, SnowFlake |
| Presto(Trino) |
정기적으로 많은 분석이 필요로 하는 경우 스캔당 비용 청구보다 예측가능한 비용이 값싸게 먹힐 수 있음 |
EMR 내의 Presto(Trino)지원 |
| AWS EMR(+ notebook, zeppelin) |
EMR 기반의 notebook환경에서 spark 엔진을 사용하여 분석 가능 |
상시 EMR + zeppelin or EMR serverless + jupyter notebook |
| Databricks SQL |
모든 쿼리는 내부적으로 모두 Spark 엔진 기반 |
Databricks SQL Editor (웹 기반 쿼리 에디터), Databricks Notebook |
7) 시각화 및 대시보드
자주 쓰이는 툴
| 툴 |
특징 |
추천 사용처 |
| Redash |
다양한 DB 연동, 쿼리 + 시각화 + 공유 대시보드 |
SQL 친숙한 분석팀, 스타트업 |
| Apache Superset |
SQL 없이도 시각화, 대규모 사용자 대응 가능 |
오픈소스 BI, 조직 내 시각화 문화 확산 |
| Metabase |
No-code 시각화 + SQL 분석 모두 지원 |
기술 비숙련자도 접근 가능한 BI 도구 |
| Tableau |
정교한 시각화, 슬라이싱/필터링 강력 |
분석 전문 조직, 경영층 보고서 |
| Power BI |
Microsoft Office 연동에 강함 |
Excel 기반 조직, MS 환경 |
| AWS |
Amazon QuickSight |
서버리스 BI, Redshift/S3/Athena 연동 |
| Databricks |
Databricks Dashboard |
Databricks SQL 기반 쿼리 시각화 |
상황별 맞춤 툴
| 상황 |
툴 |
| SQL 기반 실무자 중심 |
Redash, Superset, Mode |
| 비기술자도 사용하는 조직 |
Metabase, Power BI |
| 조직 전체 Self-service BI 구축 |
Looker, Superset |
| 복잡한 시각화/정형 보고서 |
Tableau, Power BI |
| 클라우드 중심 파이프라인 |
Looker Studio (GCP), QuickSight (AWS) |
| Databricks 환경 통합 |
Databricks Dashboards |
8) CDC 및 데이터 정합성
CDC 지원 툴
| 툴 |
특징 |
사용 시점 |
| Debezium |
Kafka 기반 오픈소스 CDC 프레임워크, MySQL/PostgreSQL 등 지원 |
실시간 데이터 레이크 적재 |
| AWS DMS |
AWS 전용 CDC 솔루션, Snapshot + CDC 동시 지원 |
RDS, Aurora, Redshift 등 백업/마이그레이션 |
| AWS ZeroETL |
DB간 데이터 동기화 |
DB간 동기화가 필요할 때 사용 |
| Oracle GoldenGate |
Oracle 전용 고성능 CDC 솔루션 |
Oracle 환경 실시간 데이터 복제 |
데이터 정합성 체크 툴
| 툴 |
특징 |
용도 |
| Great Expectations |
Python 기반 데이터 검증 테스트 작성 (expectations) |
컬럼 범위, NULL 검사, 스키마 검증 |
| Deequ (by AWS) |
Scala/Spark 기반 데이터 품질 검사 |
대규모 데이터 품질 Rule 검증 |
9) 데이터 백업 수단
- 데이터 레이크의 파일 데이터 경우라면, S3 Tiering을 통해 Glacier, Glacier Deep Archive로 백업을 하는 것을 추천
- 이외의 데이터베이스는 스냅샷과 같은 방법을 활용
10) 메타데이터, 데이터 거버넌스 및 데이터 리니지
| 분류 |
툴 |
비고 |
| 메타데이터 |
DataHub, Amundsen, OpenMetadata, Collibra |
데이터 검색, 문서화, 테이블 정의 관리 |
| 거버넌스 |
Collibra, Alation, BigID, Lake Formation |
접근 제어, 정책, 인증 통제 |
| 리니지 |
Marquez, OpenLineage, dbt, Monte Carlo |
컬럼/테이블/쿼리 수준 연계 추적 |
2. 배치 데이터파이프라인 조합
자주 보이는 패턴의 파이프라인 5가지 정도로 조합해서 정리 해보면 아래와 같습니다.
| 파이프라인 유형 |
장점 |
단점 |
적합 조직 |
비용 |
확장성 |
| EMR (Spark) + Airflow + S3/Redshift |
대규모 처리에 강함, 유연한 구성 |
운영 복잡 (인프라 관리 필요) |
엔지니어링 중심의 중대형 조직 |
중간~높음 (자동화 설정 여부에 따라) |
높음 (Auto-scaling 구성 시 유연) |
| Databricks All-in-One (Spark) |
관리 간편, 협업 및 성능 우수, Photon 엔진 |
비용 높음, 클라우드 종속성 |
ML/데이터 협업 조직 |
높음 (편의성+성능 대가) |
매우 높음 (클러스터/워크스페이스 기반 수평 확장) |
| DBT + Airflow + BigQuery |
SQL 기반 협업, 빠른 분석, 운영 간단 |
Spark 대비 대규모 처리 성능↓ |
분석 중심 조직, 빠른 실행 필요 |
중간 (서버리스 쿼리 기반) |
중간~높음 (쿼리 단위 확장 가능) |
| Glue + Athena (Spark) |
완전 서버리스, 비용 자동화, 설정 쉬움 |
성능 한계, 제어 어려움 |
소규모 또는 초기 조직 |
낮음 (사용한 만큼 과금) |
낮음~중간 (파일 단위 처리 한계) |
| K8s + Argo + custom Spark |
완전한 커스터마이징, 멀티워크로드 처리 가능 |
인프라 운영 복잡, 관리 부담 |
자체 인프라 보유한 대기업 |
중간 (BYO 인프라 기반) |
매우 높음 (K8s 기반 무제한 확장 가능) |
1) AWS (대규모 처리)
[Data Orchestrator]
Airflow
------------------------------------------------------------------------------------------
[Data Source]
RDBMS, 외부데이터
↓ (CDC - Debezium + Kafka) + (Monitoring - ELK, Prometheus, Cloudwatch)
[ELT, 정합성]
Spark + Great Expectation
↓
[Data Storage]
S3(Data Lake)
↓ (Backup - S3 lifecycle, tiering, Glacier) + (Data Catalog - Glue Data Catalog - glue table, Iceberg)
[DW]
Redshift
↓
[시각화, 대시보드]
tableau, AWS Quicksight
2) Databricks
[Data Orchestrator]
Databricks Jobs, Airflow
------------------------------------------------------------------------------------------
[Data Source]
RDBMS, 외부데이터
↓ (CDC - Debezium + Kafka) + (Monitoring - Databricks Monitor, Prometheus, ELK, Datadog, CloudWatch)
[ELT, 정합성]
Spark(Photon engine) + Great Expectation
↓
[Data Storage]
S3,GCS(Data Lake)
↓ (Backup - Delta Time Travel, S3 versioning) + (Data Catalog - Unity Catalog - delta lake) + (Governance - Unity Catalog: RBAC, Lineage, Tagging, Audit Log)
[Analytics]
Databricks SQL, Notebook
↓
[시각화, 대시보드]
Databricks Dashboard
Spark engine 변천사
Spark 2.x → Tungsten (DataFrame, SQL 최적화 중심)
↓
Spark 3.x → Adaptive Query Execution (AQE), Catalyst 개선
↓
Databricks Runtime → Photon (C++ 기반 Spark SQL 대체 엔진)
3) DBT + Bigquery
[Data Orchestrator]
Airflow
------------------------------------------------------------------------------------------
[Data Source]
RDBMS, 외부데이터
↓ (CDC - raw_change_events, incremental model + merge) + (Monitoring - Cloud Monitoring, ELK)
[Extract & Load, 정합성]
Airbyte, Fivetran
↓
[Data Storage]
Bigquery(raw,Staging,DW,Lake)
↓ (Backup - BigQuery Snapshots, GCS)
[Transform]
DBT
↓
[Data Storage]
Bigquery(DM, Marts)
↓
[시각화, 대시보드]
Looker, Looker Studio, Tableau
Airbyte, Fivetran이 Bigquery랑 잘 맞는 이유
| 항목 |
설명 |
| 커넥터 다양성 |
MySQL, PostgreSQL, Stripe, Salesforce, Shopify 등 다양한 소스에서 BigQuery로 바로 연동 가능 |
| 자동 테이블 생성 |
스키마를 분석해서 BigQuery에 테이블 자동 생성 (raw.users, raw.orders 등) |
| 증분 수집 (CDC) |
updated_at, id, binlog 기반으로 증분 방식으로 적재 가능 |
| 자동 적재 일정 관리 |
매 시간, 매일 등 간편하게 설정 가능 |
| 에러 핸들링 및 Retry |
실패 시 자동 재시도, 로깅까지 지원 |
| 스키마 변경 대응 |
컬럼 추가/삭제 자동 반영 (옵션 설정 가능) |
| GCP IAM 연동 |
BigQuery 서비스 계정 연결이 쉬움 (보안) |
4) AWS (레이크 위주의 간단한 구성)
[Data Orchestrator]
Glue Workflows(Glue ETL)
------------------------------------------------------------------------------------------
[Data Source]
RDBMS, 외부데이터
↓ (Monitoring - Cloudwatch)
[ELT]
Spark + DMS
↓
[Data Storage]
S3(Data Lake)
↓ (Backup - S3 Lifecycle, S3 tiering, Glacier) + (Data Catalog - Glue Data Catalog - glue table, AWS Lake Formation)
[Anayltics]
Athena
↓
[시각화, 대시보드]
AWS Quicksight
5) k8s
[Data Orchestrator]
Airflow, Argo WorkFlow
------------------------------------------------------------------------------------------
[Data Source]
RDBMS, 외부데이터
↓ (CDC - Debezium + Kafka) + (Monitoring - ELK, Prometheus, Cloudwatch)
[ETL, 정합성]
Spark(Spark Operator, custom spark) + Great Expectation
↓
[Data Storage]
S3, GCS, MinIO(Data Lake)
↓ (Backup - S3 Lifecycle, S3 tiering, Glacier) + (Data Catalog - Glue Data Catalog - glue table, Iceberg)
[DW]
Redshift, bigquery, snowflake
↓
[시각화, 대시보드]
Superset, Redash, Tableau
댓글