Processing Types

데이터 처리 방식은 시스템의 요구 사항에 따라 배치 (Batch), 스트림 (Stream), 하이브리드 (Hybrid) 로 구분된다. Batch Processing 은 데이터의 대량 집계와 정확성에 적합하고, Stream Processing 은 실시간 응답성과 낮은 지연 시간에 유리하다. Hybrid Processing 은 Lambda Architecture 처럼 두 방식을 조합해 실시간성과 정확성을 모두 확보하려는 전략이다. 각각은 처리량, 지연 시간, 아키텍처 복잡도 등에서 상호 보완적이며, 시스템 목적에 따라 선택 또는 병행된다.

핵심 개념

구분Batch ProcessingStream ProcessingHybrid Processing
정의일정량의 데이터를 모아서 일괄 처리데이터가 생성되는 즉시 실시간으로 처리배치와 스트림 방식을 병행하여 처리
지향점정확성, 정합성 중심실시간성, 즉시 반응 중심정확성과 실시간성의 균형
처리 방식고정 주기 실행 (예: 하루 1 회)이벤트 기반으로 연속 처리배치 레이어 + 스피드 레이어 (Lambda) / 통합 레이어 (Kappa)
주요 특징지연 허용, 대용량 처리, 분석 최적화낮은 지연, 빠른 대응, 상태 기반 처리 가능복합적 요구 대응, 운영 복잡도 증가
활용 분야리포트 생성, ETL, 통계 분석실시간 알림, 이상 탐지, 모니터링금융 거래 분석, 사용자 행동 예측, 마케팅 실시간 반응 시스템 등

실무 기술 스택 매핑

구성 요소BatchStreamHybrid (Lambda/Kappa)
엔진Apache Spark, Hadoop MapReduce, HiveApache Flink, Kafka Streams, Spark StreamingLambda: Spark + Storm / Kappa: Flink 단독 사용
메시징 시스템Kafka, Amazon KinesisKafka, Pulsar, RabbitMQKafka (공통 메시지 버퍼링), Kinesis
저장소HDFS, Amazon S3, RDBMSNoSQL, Elasticsearch, Redis데이터 레이크 + 실시간 인덱싱 레이어
스케줄링Airflow, OozieKafka Consumer, Flink Job조합: Airflow + Flink / Kappa 구조에서는 Flink 단독 사용
서빙 레이어Presto, Druid, BI 도구Redis, ElasticsearchRedis + Druid/ES 통합 서빙

실무 적용 사례 및 고려 사항

구분적용 사례처리 우선순위적합성 설명
Batch월간 리포트 생성, 로그 정제 및 보관정합성 우선대량 데이터 처리에 적합하며, 처리 지연 허용 가능
Stream실시간 트래픽 분석, 센서 데이터 모니터링반응 속도 우선지연이 적고 상태 기반 처리가 필요한 실시간 이벤트 처리에 적합
Hybrid광고 클릭 분석, 이상 금융 거래 탐지정합성 + 실시간성정확성과 즉시 반응이 동시에 필요한 복합적 시스템에 최적화

하위 처리 기준 비교

기준BatchStreamHybrid
지연 허용 여부있음 (분 ~ 시 단위)없음 (ms ~ s 단위)부분 허용
정확성
실시간성
구현 복잡도낮음보통높음
운영 복잡도단순보통복잡

아키텍처 연계 요약

처리 방식연계 아키텍처설명
BatchETL Pipeline, Data Warehouse데이터 수집 → 변환 → 적재 → 분석 (정기적 리포트 등)
StreamEvent-Driven, Reactive실시간 이벤트 수신 및 처리, CEP 등 이벤트 흐름 중심 구조
HybridLambda, Kappa ArchitectureLambda: 배치 + 스피드 레이어 / Kappa: 단일 스트림 기반 배치 + 실시간 통합 구조

Batch Processing vs. Stream Processing vs. Hybrid Processing 비교

각 처리 방식은 데이터의 시간적 특성과 비즈니스 요구사항에 따라 선택된다. 배치 처리는 정확성과 효율성을, 스트림 처리는 실시간성과 반응성을, 하이브리드 처리는 두 방식의 균형을 추구한다.

구분Batch ProcessingStream ProcessingHybrid Processing
정의데이터를 일정 시간 단위로 일괄 처리이벤트가 발생하는 즉시 데이터를 처리배치와 스트림을 결합하여 필요에 따라 병행 처리
데이터 처리 단위파일, 레코드 집합, 배치 단위개별 이벤트, 메시지배치 + 스트림 (이중 경로 또는 통합 경로)
지연 시간 (Latency)수 분 ~ 수 시간 수준수 밀리초 ~ 수 초 수준상황에 따라 조절 가능 (실시간 + 정합성 보완)
정확성 보장높음 (완전한 데이터 기반, 중복 제거 용이)낮음/중간 (중복 처리, 지연 데이터 문제 발생 가능)높음 (정확성 요구 처리는 배치로 보완)
시스템 복잡성상대적으로 단순 (단일 파이프라인, 순차 처리)복잡 (상태 관리, 시간 윈도우, 백프레셔 등)가장 복잡 (2 가지 처리 방식 병행, 아키텍처 설계 중요)
운영 효율성주기적 실행으로 운영 예측 용이지속 실행, 운영자 개입 빈도 높음자동화 없이는 운영 부담 높음
확장성수평 확장 쉬움 (Spark, MapReduce 등 지원)고난이도 (상태 공유, Backpressure 등 관리 필요)스트림 처리 확장을 위한 추가 설계 필요
데이터 일관성강한 일관성 확보 가능 (ACID 기반 설계 용이)약한 일관성 (Eventually Consistent or At-least-once)CQRS, 이벤트 소싱, 보상 트랜잭션 등 필요
장애 대응력체크포인트 및 재실행 용이복잡한 복구 메커니즘 필요 (Offset, State, Watermark 등)복합적인 장애 처리 체계 요구
사용 사례리포팅, 데이터 웨어하우징, 오프라인 ML 학습IoT 센서 처리, 실시간 알림, Fraud Detection실시간 모니터링 + 백데이터 정합성 확보가 필요한 서비스
대표 기술 스택Spark, Hadoop, AWS Glue, AirflowApache Flink, Kafka Streams, NiFiLambda/Kappa Architecture, Spark+Flink, Flink Reprocessing
코스트 효율성저비용 (스팟 인스턴스, 야간 처리 등 활용 가능)고비용 (상시 실행, 메모리/CPU 소비 큼)구조 설계에 따라 비용 급증 또는 절감 가능
성능 최적화 포인트병렬 처리, 파티셔닝, 스케줄링 최적화윈도우 크기 조정, 워터마크 튜닝, 백프레셔 제어흐름 제어, 경로 분기, Serving Layer 최적화
패턴/아키텍처Batch Sequential, Pipe-and-FilterStream Dataflow, Stateful PipelineLambda, Kappa, Micro-Batch

강점

비교 항목배치 처리 강점스트림 처리 강점하이브리드 처리 강점
처리 효율성높은 처리량, 리소스 효율성낮은 지연시간, 즉시 반응요구사항별 최적 방식 선택
정확성완전한 데이터로 정확한 결과부분 데이터로 근사 결과배치로 정확성, 스트림으로 즉시성
복잡성단순한 아키텍처중간 수준 복잡성높은 복잡성
비용낮은 인프라 비용높은 실시간 처리 비용중간 수준 비용

약점

비교 항목배치 처리 약점스트림 처리 약점하이브리드 처리 약점
실시간성높은 지연시간상태 관리 복잡성일관성 관리 어려움
유연성낮은 실시간 대응력제한적 히스토리 분석중복 로직 유지 필요
장애 처리배치 실패 시 재처리 부담메시지 손실 가능성다중 레이어 장애 처리

구조 및 아키텍처

아래 다이어그램은 각 처리 방식의 데이터 흐름과 구조를 시각적으로 보여준다.

flowchart TD
    subgraph Batch Processing
        A1[데이터 수집]
        A2[일괄 처리]
        A3[결과 저장 및 제공]
        A1 --> A2 --> A3
    end

    subgraph Hybrid Processing
        B1[데이터 수집]
        B2[배치 처리]
        B3[스트림 처리]
        B4[결과 통합 및 제공]
        B1 --> B2
        B1 --> B3
        B2 --> B4
        B3 --> B4
    end

    subgraph Stream Processing
        C1[데이터 수집]
        C2[실시간 처리]
        C3[결과 저장 및 제공]
        C1 --> C2 --> C3
    end
구성 요소
구성 요소Batch ProcessingStream ProcessingHybrid Processing (Lambda 등)
데이터 소스DB, 로그, 파일이벤트 스트림 (Kafka, MQTT 등)이벤트 + 배치 대상
처리 엔진Spark, HadoopFlink, Kafka StreamsSpark + Flink / Storm
저장소DWH, RDBMS, S3Redis, Elastic, CassandraHBase, Druid, 통합 DB
스케줄러Airflow, Cron지속 실행 or Trigger 기반Batch: 주기 실행 / Stream: 지속 실행
사용자 응답계층BI 도구, Data Studio실시간 대시보드, Alert응답 인터페이스에서 통합된 결과 제공

작동 원리 및 데이터 흐름

Batch Processing
sequenceDiagram
    participant Source
    participant Collector
    participant BatchEngine
    participant Storage
    participant BI

    Source->>Collector: Raw Data 수집 (Log, DB, File)
    Collector->>BatchEngine: 주기적 전달
    BatchEngine->>Storage: 결과 저장
    BI->>Storage: 쿼리

배치 처리 작동 원리:

  1. 데이터 축적: 일정 기간 동안 데이터 수집 및 저장
  2. 배치 생성: 처리 단위로 데이터 그룹화
  3. 병렬 처리: 다수 노드에서 동시 처리
  4. 결과 통합: 개별 결과를 최종 결과로 병합
  5. 결과 저장: 처리된 데이터를 목적지에 저장
Stream Processing
sequenceDiagram
    participant EventSource
    participant StreamProcessor
    participant Storage
    participant Dashboard

    EventSource->>StreamProcessor: 실시간 이벤트 전송
    StreamProcessor->>Storage: 처리 결과 저장
    Dashboard->>Storage: 실시간 데이터 조회

스트림 처리 작동 원리:

  1. 연속 수집: 실시간으로 데이터 스트림 수신
  2. 윈도우 처리: 시간 또는 크기 기반 윈도우 적용
  3. 상태 관리: 과거 이벤트 정보 유지 및 활용
  4. 즉시 처리: 수신과 동시에 처리 로직 적용
  5. 실시간 출력: 처리 결과 즉시 전달
Hybrid Processing
sequenceDiagram
    participant Source
    participant BatchLayer
    participant SpeedLayer
    participant Serving
    participant Client

    Source->>BatchLayer: 주기적 배치 데이터 전달
    Source->>SpeedLayer: 실시간 데이터 전달
    BatchLayer-->>Serving: 정확한 결과
    SpeedLayer-->>Serving: 실시간 결과
    Client->>Serving: 통합 결과 요청
    Serving-->>Client: 응답

구현 기법 비교

처리 방식구현 기법핵심 구성 요소주요 목적대표 예시
BatchMapReduceMapper, Reducer, Shuffling대규모 데이터 집계 및 분산 처리Hadoop, Hive 로그 분석
Batch Window시간/이벤트 기준 배치 윈도우정해진 주기 데이터 처리Spark Batch Job, Flume Sink
Micro-Batch짧은 간격의 배치 윈도우 + 배치 엔진배치와 실시간의 절충Spark Streaming (DStream), Azure Stream Analytics
StreamEvent Time ProcessingTimestamp, Watermark, Allowed Lateness이벤트 발생 기준의 정확한 시간 처리Flink Event Time 집계, 실시간 금융 거래 처리
Windowing (Tumbling/Sliding)고정 또는 중첩된 시간창 (Fixed/Sliding Window)시간 또는 이벤트 기준 집계5 분 매출 집계, IoT 스트림 데이터
Stateful Processing상태 저장소, State Backend, Checkpoint, Recovery상태 기반 처리, 세션 집계, 중복 제거Kafka Streams Session Store, Flink Keyed State
Backpressure HandlingBuffer, Flow Control, Async I/O처리 속도 초과 제어 및 안정성 확보Flink, Akka Streams
HybridLambda ArchitectureBatch Layer + Speed Layer + Serving Layer정확성 (배치) + 최신성 (실시간) 병행Spark + Storm / Spark Streaming + Kafka
Kappa Architecture단일 스트림 레이어 + Event Replay 기반 처리단순화된 구조에서 재처리까지 일관성 처리Kafka + Flink 기반 전체 파이프라인
Replay-Based ProcessingKafka Offset Reset, Stateless Processor비즈니스 로직 변경 시 재처리 지원모델 교체 후 전체 예측 재계산
Unified Stream-Batch EngineStreaming-first 엔진에서 배치 지원 (Flink, Beam 등)두 처리 방식의 일관된 실행 모델 구현Flink Unified Pipeline, Apache Beam

실무적 고려 요소 포함

구현 기법실무 고려사항
Micro-Batch정확한 실시간성은 부족하나 운영이 용이하고 기존 배치 구조와의 호환성이 좋음
Event Time Processing타임스탬프 신뢰도, 워터마크 설정 전략 등 운영 파라미터의 신중한 조정 필요
Stateful Processing상태의 크기 증가와 복구 전략, 상태 저장소 구성 등 복잡한 운영 고려 필요
Replay-Based Processing데이터 손실 없이 유연한 재처리 가능하나, 저장 비용 및 재처리 지연 시간 고려 필요
Lambda/Kappa 구조장단점 명확, 목적에 따라 선택 필요 (정확성 우선이면 Lambda, 단순성 우선이면 Kappa)

Batch Processing

Spark Batch (PySpark)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
from pyspark.sql import SparkSession

# Spark 세션 생성
spark = SparkSession.builder.appName("BatchExample").getOrCreate()

# CSV 데이터 로드
df = spark.read.csv("data.csv", header=True, inferSchema=True)

# 그룹 집계
result = df.groupBy("category").sum("amount")

# 결과 저장
result.write.csv("output/result.csv")

Stream Processing

Kafka 소비 + 상태 관리 (Python + Kafka-python + Redis)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
from kafka import KafkaConsumer
import redis
import json

# Kafka 소비자 설정
consumer = KafkaConsumer(
    'sensor-data',
    bootstrap_servers='localhost:9092',
    value_deserializer=lambda m: json.loads(m.decode('utf-8'))
)

# Redis로 상태 저장
r = redis.StrictRedis(host='localhost', port=6379, db=0)

for message in consumer:
    data = message.value
    sensor_id = data["sensor_id"]
    value = float(data["value"])

    # Redis에 누적값 저장
    prev = float(r.get(sensor_id) or 0)
    r.set(sensor_id, prev + value)

    print(f"Sensor {sensor_id} Total: {prev + value}")
Node.js 스트림 처리 (중첩 슬라이딩 윈도우)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
const { Transform } = require('stream');

let buffer = [];

const slidingWindow = new Transform({
  objectMode: true,
  transform(chunk, encoding, callback) {
    buffer.push(chunk);

    if (buffer.length > 5) buffer.shift();

    const average = buffer.reduce((acc, val) => acc + Number(val), 0) / buffer.length;
    console.log("Moving Average:", average.toFixed(2));
    callback(null, chunk);
  }
});

// 예시 스트림
require('fs')
  .createReadStream('data.txt')
  .pipe(require('split')()) // 한 줄씩
  .pipe(slidingWindow);

Hybrid Processing

Lambda Architecture 구성 예 (Batch + Stream)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# Batch Layer: Spark로 집계
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("BatchAggregation").getOrCreate()
batch_df = spark.read.json("historical_data.json")
agg = batch_df.groupBy("user_id").count()
agg.write.parquet("batch_output/")

# Stream Layer: 실시간 Kafka 스트림 처리
from kafka import KafkaConsumer
for msg in KafkaConsumer('realtime-data', bootstrap_servers='localhost:9092'):
    # Kafka 메시지 실시간 처리
    print("Streaming msg:", msg.value)
Replay-Based (Kafka 기반 재처리)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
from kafka import KafkaConsumer

consumer = KafkaConsumer(
    'events',
    bootstrap_servers='localhost:9092',
    auto_offset_reset='earliest',  # 과거부터 다시 읽기
    enable_auto_commit=False
)

for message in consumer:
    event = message.value.decode("utf-8")
    print(f"Reprocessing Event: {event}")

실무 사용 예시

처리 방식산업/도메인활용 목적주요 기술/구성기대 효과
배치 처리금융일일 정산, 회계 보고서 생성Spark, Hadoop, Airflow, BigQuery정확한 집계, 규정 준수, 비용 효율성
미디어대규모 콘텐츠 분석EMR, Spark, Cloud Storage리소스 절약, 비동기 분석, 스케일 아웃 최적화
이커머스전일 구매 트렌드 분석Dataflow, Snowflake전략적 의사결정 지원, 대규모 데이터 정합성 보장
스트림 처리금융실시간 사기 탐지Kafka, Flink, Redis즉시 차단, 사용자 보호, 손실 최소화
제조장비 상태 예측 정비Flink, MQTT, Grafana고장 방지, 유지보수 비용 절감
통신네트워크 품질 모니터링Kafka, Flink, Prometheus실시간 장애 감지 및 SLA 유지
의료환자 생체 신호 실시간 모니터링Kafka, InfluxDB, Telegraf응급 상황 대응, 생명 보호
IoT센서 데이터 실시간 분석Spark Streaming, AWS Kinesis지연 없는 제어, 트렌드 기반 반응
하이브리드 처리이커머스개인화 추천, 사용자 행동 분석Lambda Architecture (Kafka + Spark + Flink)실시간 반응성과 모델 정밀도 동시 확보
광고캠페인 성과 분석Kafka Streams + Batch Aggregator실시간 클릭 분석 + 배치 보고
헬스케어환자 기록 + 실시간 모니터링Kappa 또는 Lambda 기반 처리장기 기록 보존 + 즉각 경보
금융거래 이상 탐지 + 규제 보고서 생성Flink + Spark + PostgreSQL Outbox Pattern지속 모니터링 + 배치 기반 분석 보정

도전 과제 및 해결 방안

카테고리도전 과제주요 원인영향해결 방안 요약
데이터 일관성스트림 처리의 정확성 확보실시간 처리 중 네트워크 지연, 장애, 병렬성 이슈중복 처리, 누락 처리, 잘못된 비즈니스 인사이트체크포인트, Exactly-once 보장, 이벤트 소싱, 트랜잭션 관리
하이브리드 간 동기화배치 - 스트림 간 처리 시간/정책 차이데이터 충돌, 보정 작업 증가CQRS, Materialized View, 보상 트랜잭션, 이벤트 재처리 기반 정합성 확보
성능 최적화지연 시간 최적화I/O 병목, 상태 관리 비용, 과도한 처리량 요구SLA 미달성, 사용자 체감 속도 저하백프레셔 관리, 파티셔닝, 캐싱, 직렬화 최적화, 수평 확장
실시간 처리 병목계산 복잡성 증가, 메모리 압박, 이벤트 버스트처리량 저하, 장애 가능성슬라이딩 윈도우 조정, 워터마크 튜닝, 워커 확장, 리소스 기반 자동 스케일링
복잡성 관리운영 복잡도 증가배치/스트림 이중 관리, 다중 기술 스택 도입운영비 증가, 변경 비용 상승구조 표준화, 통합 관찰성 (Observability), 아키텍처 단순화, 문서화
장애 대응 복잡성상호 의존 서비스, 비표준 오류 처리장애 전파, MTTR 증가분산 추적, 장애 시뮬레이션 (Chaos), Circuit Breaker, 자동 장애 격리
비용/자원 효율화인프라 낭비고정된 리소스 할당, 오버프로비저닝비용 초과, 확장 제약오토스케일링, 예약 인스턴스, 클라우드 네이티브 기반 아키텍처, 비용 추적 도구 활용
중복 인프라 구성Lambda 스타일 구조의 이중 저장, 이중 처리ROI 저하, 운영 부담Kappa 기반 구조 전환, Data Lake 활용, ETL+Stream 통합
운영 안정성복구/재처리 어려움상태 관리 미비, 로그 미보존, 무상태 처리데이터 손실, 복구 지연Kafka 기반 리플레이, 이벤트 로그 장기 저장, 체크포인트/스냅샷 기반 복구
테스트/배포 리스크데이터 의존적 연산, 시간 민감 로직릴리즈 실패, 데이터 훼손Canary Release, Blue-Green Deployment, 데이터 샘플 기반 테스트

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

카테고리고려 항목설명권장 사항
적용 전략데이터 특성 분석데이터 발생 패턴 (주기성, 폭증 등) 과 실시간 요구 수준 분석요구사항에 따라 Batch, Stream, Hybrid 중 적절히 선택
정합성 요구 수준데이터 정확도/일관성 우선인지 속도 우선인지 판단회계/금융 등은 Batch or Hybrid, 사용자 반응성은 Stream 우선
재처리 가능성 여부과거 데이터의 정정 또는 반복 처리 요구 여부Stream 은 로그 기반 보존 전략 필수, Hybrid 는 Batch 로 보완
운영/안정성장애 복구 전략시스템 장애 발생 시 데이터 손실 없이 복구 가능 구조 설계Stream 처리 시 Checkpoint, DLQ 구성 필수, Batch 는 재처리 기반
상태 관리 전략상태 기반 필터 사용 시 복구 가능한 외부 상태 저장소 확보Flink StateBackend, Kafka Offset Commit, DB 기반 상태 외부화
운영 복잡도시스템 관리/배포/모니터링의 복잡성에 대한 감내 가능성 분석리소스 부족 시 단순 구조 선호 (ex. 단일 처리 방식), 운영팀 규모 고려
성능처리량 최적화대용량 처리 시 배치 크기, 파티셔닝, 병렬성 등 조정 필요병렬 처리 최적화, 적절한 리소스 사용률 유지 (예: CPU 80% 이하)
지연시간 관리서비스 수준 협약 (SLA) 을 만족시키기 위한 반응 시간 기준 설정실시간성 요구 시 Stream, 지연 허용 시 Batch, 보완은 Hybrid 로
확장성수평 확장 지원 여부데이터 증가 시 노드 추가로 처리량 확장 가능 구조 설계Kafka/Flink 기반 수평 확장 구조 설계, 자동 스케일링 정책 적용
리소스 사용 최적화CPU, 메모리, 네트워크 등 리소스 활용률 조절 및 동적 할당Auto-scaling, Container 기반 격리 구조, 리소스 모니터링 필수
모니터링상태 추적 / 로깅실시간 데이터 흐름/에러 상황 추적 및 분석 가능성 확보Prometheus, Grafana, Jaeger 등으로 Pipeline 상태 시각화
SLA 기반 감시 체계시스템 장애 및 성능 저하 시 자동 경고/회복 처리 가능 구조 필요임계값 초과 시 알람, 복구 자동화 구성 (e.g., Flink Job Failure Recovery)

최적화 고려사항 및 주의점

카테고리항목설명권장사항
리소스 최적화메모리 관리메모리 부족으로 인한 GC 지연 및 OOM 방지메모리 프로파일링, GC 튜닝, Stateful 연산 최소화
CPU 활용연산 집중 로직 병목 해소, 멀티코어 활용 극대화비효율적 알고리즘 제거, 연산 분산, 연산 우선순위 기반 재구성
리소스 스케일링처리 부하에 따라 자원 동적 조정 필요Auto Scaling, Container Orchestration, 워커 조정
네트워크 최적화데이터 이동 최소화노드 간 네트워크 트래픽이 성능에 미치는 영향 큼데이터 로컬리티 최적화, 압축, 캐시 전략 도입
저장소 최적화스토리지 효율성디스크 I/O 병목 제거 및 조회 최적화 필요파티셔닝, 버킷화, 인덱싱, 컬럼형 저장소 (Parquet, ORC 등) 도입
파이프라인 설계처리 파이프라인 최적화병목 지점 제거 및 작업 흐름 재조정병렬 처리 도입, DAG 구조 최적화, backpressure 핸들링
배치 스케줄링Job 실행 시기, 우선순위에 따라 전체 처리 지연 발생 가능SLA 기반 우선순위 조정, 리소스 예약 기반 스케줄링
스트림 전략윈도우 처리 전략슬라이딩/텀블링 윈도우에 따라 처리량과 지연 차이 존재처리 목적에 따른 윈도우 선택 및 크기 조절
파티셔닝 전략Key skew 가 발생할 경우 성능 급감해시 기반 파티셔닝, 키 분산 전략, 리밸런싱 로직 도입
체크포인팅 주기너무 짧으면 오버헤드↑, 너무 길면 장애 복구 느림이벤트량 기반 주기 조정, Incremental Checkpointing
정합성 & 복구데이터 정합성 유지스트림 & 배치 병합 시 일관성 확보 필요버전 관리된 서빙 레이어, CDC + 보정 파이프라인 구축
장애 복구실패 시 지점 복구 및 중복 방지 필요Exactly-once, Checkpoint + State Backend 설계
성능 지표 관리처리 지연 최소화낮은 지연 보장 위해 처리 경로와 연산 최적화 필요비동기 처리, 워커 수 조정, 연산 재구성
처리량 (Throughput) 개선단위 시간당 처리량 증가로 전체 성능 향상병렬도 증가, 연산 분할, Kafka partition tuning
백프레셔 대응처리 속도 불균형 시 시스템 불안정 발생Flink 의 backpressure 모니터링, 처리 속도 기반 동적 버퍼 조절

주제별 주목할 내용

카테고리항목내용 요약
처리 구조처리 경로Batch: 일괄 처리Stream: 실시간 처리Hybrid: 배치 + 스트림 통합 (예: Lambda, Kappa 구조)
실시간성스트림 처리 방식이 지연 시간과 반응성이 가장 우수
복잡성하이브리드는 복잡한 운영 관리 및 동기화 로직 필요 (운영 난이도 ↑)
일관성배치 및 하이브리드는 고정된 스케줄과 데이터 스냅샷으로 상대적으로 높은 데이터 품질 보장
아키텍처 패턴Lambda Architecture배치 + 스트림 레이어를 각각 운용하며 정확성과 실시간성을 모두 확보하는 구조
Kappa Architecture단일 스트림 경로로 단순한 구조, 유지보수 용이
핵심 기술 스택Apache Kafka고신뢰 이벤트 브로커, 모든 처리 방식의 중심 기술 (Event Sourcing / Reprocessing 기반)
Apache Flink진정한 실시간 처리 및 상태 기반 처리 지원. Hybrid 처리에 적합
Apache Spark마이크로배치 기반의 스트림 처리도 가능한 통합형 프레임워크
처리 패러다임이벤트 시간 처리 (Event Time)정확한 시간 기반 분석을 위해 이벤트 발생 시각 기준 처리
상태 관리Stateful 처리로 과거 이벤트/상태 기반의 정밀한 연산 가능 (예: 세션 집계, 중복 제거)
운영 특성체크포인팅상태 저장 및 복구를 위한 메커니즘. 장애 대비 필수 구성요소
정확히 한 번 처리“Exactly-Once” 보장 처리로 데이터 중복 방지 및 일관성 유지
백프레셔 제어처리량 초과 시 흐름을 제어하여 안정적 운영을 보장 (Flink, Kafka 등에서 기본 지원)

반드시 학습해야할 내용

카테고리주제핵심 항목설명
기초 이론데이터 처리 모델Batch vs Stream vs Hybrid각 처리 방식의 원리, 장단점, 처리 흐름 구조 비교
분산 시스템 이론CAP 정리일관성 (Consistency), 가용성 (Availability), 분할 내성 (Partition Tolerance) 간 트레이드오프
시간 처리 모델Event Time vs Processing Time이벤트 정확한 시계열 분석 및 지연 시간 처리의 차이 이해
이벤트 기반 설계Event Sourcing, CQRS상태 저장 방식과 읽기/쓰기 분리 구조 이해
아키텍처 스타일데이터 플로우 아키텍처Pipe-and-Filter, Stream, Lambda/Kappa데이터 흐름 기반 처리 스타일, 계층별 처리 방식 설계 전략
마이크로서비스 설계서비스 분해, 메시징, 경량화각 서비스 독립 실행 및 배포 가능하게 구성, 메시지 기반 연결
기술 스택스트림 처리 프레임워크Kafka Streams, Flink, Spark Streaming실시간 데이터 분석 및 이벤트 기반 처리 엔진
배치 처리 프레임워크Spark, Hadoop, Airflow대량 데이터 집계, ETL, 정합성 기반 처리 프레임워크
메시지 브로커Kafka, RabbitMQ, Pulsar비동기 메시지 큐 및 실시간 데이터 파이프라인 구축 도구
운영 및 장애 대응장애 복구 전략Checkpointing, Replay, DLQ스트림 중단 없이 복구 가능한 구조 설계, 메시지 재처리 전략
운영 관측 가능성Metrics, Logs, Tracing성능 모니터링 및 장애 분석을 위한 관측 지표 활용 (e.g., Kafka Lag, Flink Job Status 등)
리소스 사용량 최적화Auto-scaling, Partitioning처리량에 따라 동적으로 확장 및 분할 처리 설계
성능 최적화병렬 처리 전략Multi-threading, Worker Pool필터 및 파이프라인 단위 병렬 처리 설계
캐싱 전략Local/Distributed Cache지연시간 감소 및 반복 연산 회피용 캐시 활용
데이터 파티셔닝Key 기반 분산 처리데이터를 논리적 단위로 나누어 확장성과 병렬성 확보
배치 최적화윈도우 기반 처리, Batch Size 조정처리 단위 최적화를 통한 처리 효율성 향상

용어 정리

대분류소분류용어설명
처리 방식주요 처리 유형Batch Processing데이터를 일정 주기로 모아 일괄 처리하는 방식. 지연이 허용되는 대용량 처리에 적합
Stream Processing데이터가 도착하자마자 실시간으로 처리하는 방식. 지연에 민감한 시스템에 적합
Hybrid ProcessingBatch 와 Stream 을 통합하여 정확성과 지연 시간의 균형을 추구
세부 처리 기술Micro-Batch소규모 배치를 사용해 준실시간 처리를 수행하는 방식. Spark Streaming 등에서 사용
시간 단위 처리Tumbling Window고정 시간 간격으로 데이터를 집계하는 윈도우 방식
Sliding Window중첩된 시간 구간으로 연속적인 집계를 수행하는 방식
시간 기준Event Time데이터가 실제 발생한 시간 기준으로 처리
Processing Time시스템이 데이터를 수신 및 처리한 시간 기준
Watermark늦게 도착한 이벤트 처리를 위해 정의하는 시간 기준점
아키텍처패턴 및 구조Lambda ArchitectureBatch + Stream Layer 를 병렬로 운용하는 구조. 정확성 중심
Kappa Architecture단일 스트림 파이프라인 기반의 구조. 단순성과 유지보수 용이성 중심
구성 요소Batch Layer(Lambda) 정기적 일괄 처리 수행 계층
Speed Layer(Lambda) 최신 데이터를 빠르게 처리하는 계층
Serving Layer사용자 쿼리에 응답 가능한 상태를 저장하는 계층 (공통)
상태 관리 및 보장상태 저장 방식Checkpointing장애 복구를 위해 상태를 주기적으로 저장하는 기법
State BackendFlink 등에서 사용되는 상태 저장소 (e.g., RocksDB)
메시지 처리 보장Exactly Once각 이벤트가 정확히 한 번만 처리되도록 보장
At Least Once이벤트가 최소 한 번 이상 처리되는 보장 방식
플랫폼/도구스트리밍 플랫폼Apache Kafka고신뢰 분산 메시징 시스템. 스트림 처리 및 재처리에 핵심 플랫폼
Apache Flink상태 기반의 실시간 스트림 처리 프레임워크. 정확한 이벤트 처리 보장
Apache Spark대규모 배치 및 마이크로배치 기반의 스트림 처리 가능
운영 및 성능운영 전략Checkpoint처리 중간 상태 저장을 통해 장애 복구 가능
Backpressure처리 속도보다 빠른 유입 시 흐름 제어. 시스템 안정성을 위한 필수 메커니즘
Latency데이터 처리 완료까지 걸리는 시간 (지연 시간)
Throughput단위 시간당 처리 가능한 데이터 양
분산 처리 전략스케일 전략Partitioning데이터를 샤드별로 분산 처리하여 병렬성과 확장성을 확보
Sharding데이터베이스를 수평으로 나눠 저장 및 처리하는 전략
Rebalancing작업 부하를 클러스터 노드 간에 재분배하는 과정

참고 및 출처