Processing Types#
데이터 처리 방식은 시스템의 요구 사항에 따라 배치 (Batch), 스트림 (Stream), 하이브리드 (Hybrid) 로 구분된다. Batch Processing 은 데이터의 대량 집계와 정확성에 적합하고, Stream Processing 은 실시간 응답성과 낮은 지연 시간에 유리하다. Hybrid Processing 은 Lambda Architecture 처럼 두 방식을 조합해 실시간성과 정확성을 모두 확보하려는 전략이다. 각각은 처리량, 지연 시간, 아키텍처 복잡도 등에서 상호 보완적이며, 시스템 목적에 따라 선택 또는 병행된다.
핵심 개념#
- Batch는 대용량 데이터를 정확하게 처리하고, 일정 간격으로 분석과 보고서를 생성하는 데 적합하다.
- Stream은 지연 없이 이벤트를 실시간 처리하고, 즉시 반응해야 하는 시스템에 사용된다.
- Hybrid는 두 방식의 강점을 조합하여, 실시간성과 정합성이 모두 중요한 복잡한 비즈니스 도메인에서 사용된다.
예: 이상 탐지, 실시간 사용자 분석, 추천 시스템 등.
구분 | Batch Processing | Stream Processing | Hybrid Processing |
---|
정의 | 일정량의 데이터를 모아서 일괄 처리 | 데이터가 생성되는 즉시 실시간으로 처리 | 배치와 스트림 방식을 병행하여 처리 |
지향점 | 정확성, 정합성 중심 | 실시간성, 즉시 반응 중심 | 정확성과 실시간성의 균형 |
처리 방식 | 고정 주기 실행 (예: 하루 1 회) | 이벤트 기반으로 연속 처리 | 배치 레이어 + 스피드 레이어 (Lambda) / 통합 레이어 (Kappa) |
주요 특징 | 지연 허용, 대용량 처리, 분석 최적화 | 낮은 지연, 빠른 대응, 상태 기반 처리 가능 | 복합적 요구 대응, 운영 복잡도 증가 |
활용 분야 | 리포트 생성, ETL, 통계 분석 | 실시간 알림, 이상 탐지, 모니터링 | 금융 거래 분석, 사용자 행동 예측, 마케팅 실시간 반응 시스템 등 |
실무 기술 스택 매핑#
구성 요소 | Batch | Stream | Hybrid (Lambda/Kappa) |
---|
엔진 | Apache Spark, Hadoop MapReduce, Hive | Apache Flink, Kafka Streams, Spark Streaming | Lambda: Spark + Storm / Kappa: Flink 단독 사용 |
메시징 시스템 | Kafka, Amazon Kinesis | Kafka, Pulsar, RabbitMQ | Kafka (공통 메시지 버퍼링), Kinesis |
저장소 | HDFS, Amazon S3, RDBMS | NoSQL, Elasticsearch, Redis | 데이터 레이크 + 실시간 인덱싱 레이어 |
스케줄링 | Airflow, Oozie | Kafka Consumer, Flink Job | 조합: Airflow + Flink / Kappa 구조에서는 Flink 단독 사용 |
서빙 레이어 | Presto, Druid, BI 도구 | Redis, Elasticsearch | Redis + Druid/ES 통합 서빙 |
실무 적용 사례 및 고려 사항#
구분 | 적용 사례 | 처리 우선순위 | 적합성 설명 |
---|
Batch | 월간 리포트 생성, 로그 정제 및 보관 | 정합성 우선 | 대량 데이터 처리에 적합하며, 처리 지연 허용 가능 |
Stream | 실시간 트래픽 분석, 센서 데이터 모니터링 | 반응 속도 우선 | 지연이 적고 상태 기반 처리가 필요한 실시간 이벤트 처리에 적합 |
Hybrid | 광고 클릭 분석, 이상 금융 거래 탐지 | 정합성 + 실시간성 | 정확성과 즉시 반응이 동시에 필요한 복합적 시스템에 최적화 |
하위 처리 기준 비교#
기준 | Batch | Stream | Hybrid |
---|
지연 허용 여부 | 있음 (분 ~ 시 단위) | 없음 (ms ~ s 단위) | 부분 허용 |
정확성 | ✅ | ❌ | ✅ |
실시간성 | ❌ | ✅ | ✅ |
구현 복잡도 | 낮음 | 보통 | 높음 |
운영 복잡도 | 단순 | 보통 | 복잡 |
아키텍처 연계 요약#
처리 방식 | 연계 아키텍처 | 설명 |
---|
Batch | ETL Pipeline, Data Warehouse | 데이터 수집 → 변환 → 적재 → 분석 (정기적 리포트 등) |
Stream | Event-Driven, Reactive | 실시간 이벤트 수신 및 처리, CEP 등 이벤트 흐름 중심 구조 |
Hybrid | Lambda, Kappa Architecture | Lambda: 배치 + 스피드 레이어 / Kappa: 단일 스트림 기반 배치 + 실시간 통합 구조 |
Batch Processing vs. Stream Processing vs. Hybrid Processing 비교#
각 처리 방식은 데이터의 시간적 특성과 비즈니스 요구사항에 따라 선택된다. 배치 처리는 정확성과 효율성을, 스트림 처리는 실시간성과 반응성을, 하이브리드 처리는 두 방식의 균형을 추구한다.
구분 | Batch Processing | Stream Processing | Hybrid 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, Airflow | Apache Flink, Kafka Streams, NiFi | Lambda/Kappa Architecture, Spark+Flink, Flink Reprocessing |
코스트 효율성 | 저비용 (스팟 인스턴스, 야간 처리 등 활용 가능) | 고비용 (상시 실행, 메모리/CPU 소비 큼) | 구조 설계에 따라 비용 급증 또는 절감 가능 |
성능 최적화 포인트 | 병렬 처리, 파티셔닝, 스케줄링 최적화 | 윈도우 크기 조정, 워터마크 튜닝, 백프레셔 제어 | 흐름 제어, 경로 분기, Serving Layer 최적화 |
패턴/아키텍처 | Batch Sequential, Pipe-and-Filter | Stream Dataflow, Stateful Pipeline | Lambda, 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 Processing | Stream Processing | Hybrid Processing (Lambda 등) |
---|
데이터 소스 | DB, 로그, 파일 | 이벤트 스트림 (Kafka, MQTT 등) | 이벤트 + 배치 대상 |
처리 엔진 | Spark, Hadoop | Flink, Kafka Streams | Spark + Flink / Storm |
저장소 | DWH, RDBMS, S3 | Redis, Elastic, Cassandra | HBase, Druid, 통합 DB |
스케줄러 | Airflow, Cron | 지속 실행 or Trigger 기반 | Batch: 주기 실행 / Stream: 지속 실행 |
사용자 응답계층 | BI 도구, Data Studio | 실시간 대시보드, Alert | 응답 인터페이스에서 통합된 결과 제공 |
작동 원리 및 데이터 흐름#
- Batch: 느리지만 강력한 집계/분석용 처리 방식, 대규모 로그 분석이나 ETL 에 적합
- Stream: 실시간 반응이 필요한 모니터링, 알림 시스템 등에 필수적이며, 상태 기반 처리가 핵심
- Hybrid: 실시간성과 정확성을 동시에 만족하고자 할 때, 아키텍처 복잡도가 높은 대신 유연한 처리 가능
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: 쿼리
배치 처리 작동 원리:
- 데이터 축적: 일정 기간 동안 데이터 수집 및 저장
- 배치 생성: 처리 단위로 데이터 그룹화
- 병렬 처리: 다수 노드에서 동시 처리
- 결과 통합: 개별 결과를 최종 결과로 병합
- 결과 저장: 처리된 데이터를 목적지에 저장
Stream Processing#
sequenceDiagram
participant EventSource
participant StreamProcessor
participant Storage
participant Dashboard
EventSource->>StreamProcessor: 실시간 이벤트 전송
StreamProcessor->>Storage: 처리 결과 저장
Dashboard->>Storage: 실시간 데이터 조회
스트림 처리 작동 원리:
- 연속 수집: 실시간으로 데이터 스트림 수신
- 윈도우 처리: 시간 또는 크기 기반 윈도우 적용
- 상태 관리: 과거 이벤트 정보 유지 및 활용
- 즉시 처리: 수신과 동시에 처리 로직 적용
- 실시간 출력: 처리 결과 즉시 전달
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: 응답
구현 기법 비교#
처리 방식 | 구현 기법 | 핵심 구성 요소 | 주요 목적 | 대표 예시 |
---|
Batch | MapReduce | Mapper, Reducer, Shuffling | 대규모 데이터 집계 및 분산 처리 | Hadoop, Hive 로그 분석 |
| Batch Window | 시간/이벤트 기준 배치 윈도우 | 정해진 주기 데이터 처리 | Spark Batch Job, Flume Sink |
| Micro-Batch | 짧은 간격의 배치 윈도우 + 배치 엔진 | 배치와 실시간의 절충 | Spark Streaming (DStream), Azure Stream Analytics |
Stream | Event Time Processing | Timestamp, 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 Handling | Buffer, Flow Control, Async I/O | 처리 속도 초과 제어 및 안정성 확보 | Flink, Akka Streams |
Hybrid | Lambda Architecture | Batch Layer + Speed Layer + Serving Layer | 정확성 (배치) + 최신성 (실시간) 병행 | Spark + Storm / Spark Streaming + Kafka |
| Kappa Architecture | 단일 스트림 레이어 + Event Replay 기반 처리 | 단순화된 구조에서 재처리까지 일관성 처리 | Kafka + Flink 기반 전체 파이프라인 |
| Replay-Based Processing | Kafka Offset Reset, Stateless Processor | 비즈니스 로직 변경 시 재처리 지원 | 모델 교체 후 전체 예측 재계산 |
| Unified Stream-Batch Engine | Streaming-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 Processing | Batch 와 Stream 을 통합하여 정확성과 지연 시간의 균형을 추구 |
| 세부 처리 기술 | Micro-Batch | 소규모 배치를 사용해 준실시간 처리를 수행하는 방식. Spark Streaming 등에서 사용 |
| 시간 단위 처리 | Tumbling Window | 고정 시간 간격으로 데이터를 집계하는 윈도우 방식 |
| | Sliding Window | 중첩된 시간 구간으로 연속적인 집계를 수행하는 방식 |
| 시간 기준 | Event Time | 데이터가 실제 발생한 시간 기준으로 처리 |
| | Processing Time | 시스템이 데이터를 수신 및 처리한 시간 기준 |
| | Watermark | 늦게 도착한 이벤트 처리를 위해 정의하는 시간 기준점 |
아키텍처 | 패턴 및 구조 | Lambda Architecture | Batch + Stream Layer 를 병렬로 운용하는 구조. 정확성 중심 |
| | Kappa Architecture | 단일 스트림 파이프라인 기반의 구조. 단순성과 유지보수 용이성 중심 |
| 구성 요소 | Batch Layer | (Lambda) 정기적 일괄 처리 수행 계층 |
| | Speed Layer | (Lambda) 최신 데이터를 빠르게 처리하는 계층 |
| | Serving Layer | 사용자 쿼리에 응답 가능한 상태를 저장하는 계층 (공통) |
상태 관리 및 보장 | 상태 저장 방식 | Checkpointing | 장애 복구를 위해 상태를 주기적으로 저장하는 기법 |
| | State Backend | Flink 등에서 사용되는 상태 저장소 (e.g., RocksDB) |
| 메시지 처리 보장 | Exactly Once | 각 이벤트가 정확히 한 번만 처리되도록 보장 |
| | At Least Once | 이벤트가 최소 한 번 이상 처리되는 보장 방식 |
플랫폼/도구 | 스트리밍 플랫폼 | Apache Kafka | 고신뢰 분산 메시징 시스템. 스트림 처리 및 재처리에 핵심 플랫폼 |
| | Apache Flink | 상태 기반의 실시간 스트림 처리 프레임워크. 정확한 이벤트 처리 보장 |
| | Apache Spark | 대규모 배치 및 마이크로배치 기반의 스트림 처리 가능 |
운영 및 성능 | 운영 전략 | Checkpoint | 처리 중간 상태 저장을 통해 장애 복구 가능 |
| | Backpressure | 처리 속도보다 빠른 유입 시 흐름 제어. 시스템 안정성을 위한 필수 메커니즘 |
| | Latency | 데이터 처리 완료까지 걸리는 시간 (지연 시간) |
| | Throughput | 단위 시간당 처리 가능한 데이터 양 |
분산 처리 전략 | 스케일 전략 | Partitioning | 데이터를 샤드별로 분산 처리하여 병렬성과 확장성을 확보 |
| | Sharding | 데이터베이스를 수평으로 나눠 저장 및 처리하는 전략 |
| | Rebalancing | 작업 부하를 클러스터 노드 간에 재분배하는 과정 |
참고 및 출처#
Batch Processing 배치 처리 (Batch Processing) 는 여러 데이터 작업을 묶어 한 번에 처리하는 데이터 처리 방식이다. 이는 주로 대용량 데이터 집계, 변환, 백업, 보고서 생성 등 반복적이고 대규모 작업에 적용된다. 배치 처리는 데이터 흐름 아키텍처의 한 형태로, 자동화, 확장성, 일관성, 오류 복구 등에서 강점을 가지며, 실시간 처리와는 다른 효율성과 안정성을 제공한다. 현대 IT 시스템에서는 분산 처리, 스케줄링, 장애 복구 등과 결합되어 다양한 산업에서 핵심 역할을 수행한다.
배경 대규모 데이터가 실시간으로 처리될 필요가 없을 때, 리소스 효율성과 자동화, 신뢰성을 위해 배치 처리 방식이 도입됨. 초기 메인프레임 환경에서부터 현대의 분산 시스템, 클라우드 환경까지 널리 사용됨. 목적 및 필요성 주요 목적
...