Brain304. 배치 처리 파이프라인
핵심 인사이트 (3줄 요약)
- 본질: 배치 처리 파이프라인(Batch Processing Pipeline)은 대규모 데이터를 일정 주기로まとめて処理하는 시스템으로, Hadoop MapReduce, Apache Spark, Cron + Shell, Workflow Orchestration 도구(Airflow, Dagster 등) 등이 있다.
- 가치: 대량 데이터의 효율적処理, 재현 가능하고 자동화된 데이터 파이프라인, 스케줄링 기반의周期적 실행이 가능하다.
- 융합: Hadoop, Spark, Airflow, ETL, DW, 데이터 레이크, 워크플로우 오케스트레이션과 밀접하게 연관된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
배치 처리 파이프라인(Batch Processing Pipeline)은 대규모 데이터셋을Collectして一定량또는 일정 주기로 Processed하는 시스템이다. 배치 처리的特点是大量データを一括して処理，因此在处理完成后才生成结果，适用于对实时性要求不高的业务场景（如日终处理、月度报告、数据仓库ETL等）。주요 기술로는 Hadoop MapReduce, Apache Spark (배치 모드), Cron + Shell 스크립트, 그리고 이러한 잡을orchestrate하는 워크플로우 도구(Airflow, Dagster, Prefect, Luigi 등)가 있다.
필요성
실시간 스트림 처리가 모든 시나리오에 적합한 것은 아니다. 수십 GB~수 TB의 대규모 데이터를 처리해야 하는 경우, 스트림处理는非효율적일 수 있다. 예를 들어,DW에 대한 일일 집계, 재무 보고서 생성, 규제 보고서作成などの业务场景では、データを一旦蓄積してからバッチ处理を実行する方が理にかなっている。また、バッチ处理は系统负载低谷時間帯に実行することで、资源利用率を最適化できる。
배경
배치 처리의歴史는 1960년대 mainframe 데이터 처리에서 시작되었다. 이후 Hadoop MapReduce(2004년 Google 논문发表, 2006년 Apache Hadoopとして公開)가 대규모 분산 배치 처리의 사실상 표준이 되었다. MapReduce는 복잡하지만 강력한 프레임워크이지만,随即出现了より简单な抽象化を提供するApache Spark（2014年）が後継として注目された。 Sparkはメモリ内処理によりMapReduceより大幅に高速であり、今日では大数据処理の主力フレームワークとなっている。 또한 워크플로우 오케스트레이션 도구인 Apache Airflow（2017年SpotifyがGitHubで公開）がvens已经成为バッチパイプラインの事実上の標準的なオーケストレーションツールとなっている。
비유
배치 처리는大型호텔의ousse 정리 담당자와 같다. 매주|月曜 아침에 담당자가 Seluruh 객실을 순회하여 bed sheet를 교체하고(not 실시간, 특정 시점) housekeeping을 수행한다. 하루가 아니라 특정 주기마다, 객실 데이터를 수집(Extract)하고, cleaning하고(Transform), fresh bed sheet를 설치(Load)한다. 실시간 청식은不可能하지만,全体 결과를 효율적으로処理할 수 있다.
📢 섹션 요약: 배치 처리 파이프라인은 대규모 데이터를 일정 주기로 수집·처리하는 시스템으로, Hadoop, Spark, Airflow 등이 핵심 기술이다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
배치 처리 아키텍처
┌─────────────────────────────────────────────────────────────────────────────┐
│ 배치 처리 파이프라인 아키텍처 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [배치 처리 파이프라인 구조] │
│ ────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 일별 DW 적재 배치 파이프라인 예시 │ │
│ │ ──────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 소스 DB │ │ Extract │ │Transform │ │ DW 적재 │ │ │
│ │ │ (OLTP) │──▶│ (Raw CSV)│──▶│ (Spark) │──▶│ (Redshift)│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │ │ │
│ │ │ 야간 배치 (00:00 ~ 06:00) │ │ │
│ │ │ ※ 시스템负载가 낮은 시간대에 실행 │ │ │
│ │ ▼ ▼ │ │
│ │ ┌─────────────────────────────────────────────────────────────┐ │ │
│ │ │ Airflow DAG: daily_etl │ │ │
│ │ │ ─────────────────────────────────────────────────────── │ │ │
│ │ │ │ │ │
│ │ │ t1: ExtractCustomers () │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ t2: ExtractOrders () ──────▶ [t1 완료 후 실행] │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ t3: TransformData () ─────▶ [t1, t2 완료 후 실행] │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ t4: LoadToWarehouse () ───▶ [t3 완료 후 실행] │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ t5: SendNotification () ───▶ [t4 완료 후 실행] │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Hadoop MapReduce vs Apache Spark
┌─────────────────────────────────────────────────────────────────────────────┐
│ Hadoop MapReduce vs Apache Spark 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 특성 │ Hadoop MapReduce │ Apache Spark │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 처리 모델 │ Map → Shuffle → Reduce │ Transform (RDD, │ │
│ │ │ (디스크 기반) │ DataFrame) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 데이터 저장 │ HDFS (디스크) │ HDFS, S3, etc. │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 처리 속도 │ 상대적으로 느림 │ 메모리 내 처리로 수십배 │ │
│ │ │ (디스크 I/O 발생) │ 高速 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 메모리 사용 │ 낮음 │ 높음 (설정 조절 가능) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 장애 복구 │ Task 재실행 │ Lineage 기반 RDD 복구 │ │
│ │ │ (완벽한) │ (高速だが制限적) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ Iterative 처리 │ 비효율적 │ 효율적 (메모리 재使用) │ │
│ │ (ML 알고리즘) │ (매번 디스크读写) │ │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 사용 난이도 │ 높음 ( Boilerplate多) │ 낮음 (풍부한 API) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 적합场景 │ 수TB 이상의超大規模処理, | 중간 규모 (수GB~수백GB), │ │
│ │ │ 단순한 ETL, 저비용 │ 빠른 处理, ML/交互分析 │ │
│ └────────────────┴────────────────────────┴────────────────────────┘ │
│ │
│ [Spark 처리 단계] │
│ ───────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ // Spark DataFrame 예시 │ │
│ │ ──────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ val df = spark.read.parquet("s3://datalake/sales/") │ │
│ │ │ │
│ │ val result = df │ │
│ │ .filter(col("year") === 2024) │ │
│ │ .groupBy("region", "category") │ │
│ │ .agg( │ │
│ │ sum("sales_amt").as("total_sales"), │ │
│ │ avg("profit_amt").as("avg_profit") │ │
│ │ ) │ │
│ │ .orderBy(desc("total_sales")) │ │
│ │ │ │
│ │ result.write.mode("overwrite").parquet("s3://datalake/output/") │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
워크플로우 오케스트레이션 도구
┌─────────────────────────────────────────────────────────────────────────────┐
│ 워크플로우 오케스트레이션 도구 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬──────────┬──────────┬──────────┬──────────┐ │
│ │ 특성 │Airflow │Dagster │Prefect │ Luigi │ │
│ │ │ │ │ │ │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 개발사/출시 │Apache │Elementl │Prefect │Spotify │ │
│ │ │(2017) │(2018) │(2018) │(2014) │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 정의 방식 │Python │Python │Python │Python │ │
│ │ │DAGs │Defs + │Flows │TaskGraph │ │
│ │ │ │Ops+Jobs │ │ │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ UI/대시보드 │✓ │✓ │✓ │△ │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 스케줄링 │Cron 기반 │Cron + │Cron + │Cron 기반 │ │
│ │ │ │Scheduler │Scheduler │ │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 재실행/재개 │✓ │✓ │✓ │✓ │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 분산 실행 │Executor │ │ │ │ │
│ │ │의해 │Dask, K8s │Dask, K8s │ 자체 │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ ml Pipelines │△ │✓ │✓ │△ │ │
│ │ 지원 │ │Native │Native │ │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 학습 곡선 │중간 │중간 │낮음 │높음 │ │
│ ├────────────────┼──────────┼──────────┼──────────┼──────────┤ │
│ │ 커뮤니티/ │매우 큼 │성장 중 │성장 중 │상대적으로 │ │
│ │ 채택도 │(사실표준) │ │ │작음 │ │
│ └────────────────┴──────────┴──────────┴──────────┴──────────┘ │
│ │
│ [Apache Airflow DAG 예시] │
│ ──────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ from airflow import DAG │ │
│ │ from airflow.operators.python import PythonOperator │ │
│ │ from datetime import datetime, timedelta │ │
│ │ │ │
│ │ dag = DAG( │ │
│ │ 'daily_sales_etl', │ │
│ │ start_date=datetime(2024, 1, 1), │ │
│ │ schedule_interval='0 2 * * *', # 매일 새벽 2시 │ │
│ │ catchup=False │ │
│ │ ) │ │
│ │ │ │
│ │ t1 = PythonOperator(task_id='extract', python_callable=extract) │ │
│ │ t2 = PythonOperator(task_id='transform', python_callable=transform)│ │
│ │ t3 = PythonOperator(task_id='load', python_callable=load) │ │
│ │ │ │
│ │ t1 >> t2 >> t3 # t1 → t2 → t3 의존성 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
배치 vs 스트림 처리 선택 기준
┌─────────────────────────────────────────────────────────────────────────────┐
│ 배치 vs 스트림 처리 선택 기준 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [배치 처리가 적합한场景] │
│ ─────────────────── │
│ ✅ 대용량 데이터 처리 (수십 GB ~ 수 TB 이상) │
│ ✅ 실시간성이 중요하지 않은 경우 (수시간延迟可) │
│ ✅ 복잡한 join, aggregation, ML 모델 훈련 │
│ ✅ 일일/주별/月별 보고서, 집계 │
│ ✅ 야간 배치, 주말 배치 │
│ ✅ 데이터 품질 검증, 정규화 같은 Compute-intensive 작업 │
│ │
│ [스트림 처리가 적합한场景] │
│ ─────────────────── │
│ ✅ 수 밀리초~수 초 내 결과 필요 │
│ ✅ 지속적인 모니터링, 이상 탐지 │
│ ✅金融 사기 탐지, 네트워크 침입 감지 │
│ ✅ 실시간 추천, 광고 최적화 │
│ ✅ IoT 센서 데이터 모니터링 │
│ ✅ Event-driven 마이크로서비스 │
│ │
│ [Lambda 아키텍처: 배치 + 스트림 Hybrid] │
│ ───────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Lambda 아키텍처 │ │
│ │ ──────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ ┌───────────┐ ┌───────────┐ │ │
│ │ │ Source │──────────▶│ Stream │ │ │
│ │ │ Data │ │ Layer │ │ │
│ │ │ │ │ (Speed) │ │ │
│ │ │ │ │ 실시간 결과 │ │ │
│ │ │ │ └─────┬─────┘ │ │
│ │ │ │ │ │ │
│ │ └─────┬────┘ │ │ │
│ │ │ │ 합침 (Merge) │ │
│ │ ▼ ▼ │ │
│ │ ┌───────────┐ ┌───────────┐ │ │
│ │ │ Batch │ │ Serving │ │ │
│ │ │ Layer │──────────▶│ Layer │ │ │
│ │ │ (정확한 결과)│ │ (최종 결과)│ │ │
│ │ └───────────┘ └───────────┘ │ │
│ │ │ │
│ │ ※ 배치: 정확하지만 느린 결과 / 스트림: 빠르지만 근사치 결과 │ │
│ │ ※ Kappa 아키텍처: 배치 대신 스트림만 사용 (단순화) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 배치 처리는 대용량 데이터의 효율적 처리에 적합하고, 스트림 처리는 극低 지연이 필요한場合に選択する。Lambda 아키텍처는 배치의 정확성과 스트림의高速성을 모두 취하는Hybrid方式이지만、実装の複雑さが欠点である。Kappa 아키텍처는 이를简化하여 배치 대신 스트림만 사용하는方式이다。워크플로우 오케스트레이션 도구中、Airflow가 사실상의 표준이지만、Dagster나 Prefect도 점점 인기를얻고 있다。
📢 섹션 요약: 배치 처리는 대용량 데이터의 효율적処理에 적합하고, 스트림 처리는 극低 지연이 필요한场景에 선택하며, Lambda/Kappa 아키텍처는 둘의 hybrid 접근이다.
Ⅲ. 결론
배치 처리 파이프라인은 대규모 데이터를 일정 주기로 수집·처리하는 핵심 데이터 엔지니어링 기술이다. Hadoop MapReduce는 대규모 분산 처리의 기반이 되었고, Apache Spark는 메모리 내 처리를 통해より高速な処理を提供している。Airflow는 배치 파이프라인의 오케스트레이션을 위한 사실상의 표준 도구이다. 배치 처리와 스트림 처리는各々の장단점이 있으며, Lambda/Kappa 아키텍처를 통해 hybrid 접근도 가능하다.用様に応じて適切な処理方式を選択することが重要である。
📢 섹션 요약: 배치 처리 파이프라인은 대규모 데이터의 효율적 처리에 필수적이며, Spark, Airflow 등이 핵심 기술이고, 배치와 스트림은场景에 따라 선택하거나 hybrid로 활용한다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ Batch Processing Pipeline Concept Map │
│ │
│ ┌─────────────────────────────────┐ │
│ Batch Processing Pipeline │ │
│ (배치 처리 파이프라인) │ │
└───────────────┬─────────────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Hadoop │ │Apache Spark │ │ Airflow / │ │
│ │ MapReduce │ │ (배치 모드) │ │ Dagster │ │
│ │ (대규모 处理)│ │ (고속 처리) │ │ (오케스트레이션)│ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ └────────────────────┼────────────────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Lambda / Kappa │ │
│ │ (Hybrid 접근) │ │
│ └─────────────────────┘ │
│ │
│ 배치 적합: 대용량 | 지연容忍 | 복잡한 处理 | 주기적 보고서 │
│ 스트림 적합: 저지연 | 실시간 분석 | 모니터링 | 이상 탐지 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- 배치 처리 파이프라인은 대규모 데이터를 일정 주기로処理한다.
- Hadoop MapReduce는 대규모 분산 처리의 기반 기술이다.
- Apache Spark는 메모리 내 처리로より高速である。
- Airflow는 배치 파이프라인 오케스트레이션의 사실상 표준이다.
- 배치와 스트림은 장단점이 있어用様に応じて選択한다.
- Lambda/Kappa 아키텍처는 hybrid 접근 방식이다.
- 스케줄링, 의존성 管理, 장애 복구 기능이 필수적이다.