Brain303. 스트림 처리 DB
핵심 인사이트 (3줄 요약)
- 본질: 스트림 처리 DB(Stream Processing Database)는 데이터 스트림(事件 流)을 실시간으로 처리·분석하는 데이터베이스로, Kafka, Flink, Kafka Streams, KSQLDB 등이 있다.
- 가치: 수 밀리초~수 초의 극低 지연으로 실시간 분석, 연속 Queries, 실시간 대시보드, 이상 탐지,事件驱动 애플리케이션 지원이 가능하다.
- 융합: Kafka, Apache Flink, 스트림 처리, Complex Event Processing, 실시간 분석, Lambda/Kappa 아키텍처와 밀접하게 연관된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
스트림 처리 DB(Stream Processing Database)는 데이터의_continuous stream_(연속적인事件 流)을 실시간으로 처리·분석하는数据库이다. 전통적인 배치 처리(Batch Processing)가 저장된 데이터를 일괄적으로処理するのに対し、ストリーム処理는 데이터가 도착하는 시점에 바로 처리한다. 스트림 처리 시스템은"time in motion"으로 데이터를捕らえ、데이터の arriving speedに跟上する。Kafka, Apache Flink, Kafka Streams, KSQLDB, Apache Storm, Amazon Kinesis Data Analytics 등이 대표적인 스트림 처리 기술이다.
필요성
현대 비즈니스는より素早い 의사결정을 위해 수 밀리초~수 초 단위의リアルタイム 데이터 분석을 필요로 한다. 금융 사기 탐지, 네트워크 침입 감지, 실시간 추천, IoT 센서 모니터링, 광고 클릭률 최적화 등의用例では、배치处理의 수시간延迟は致命的な問題となる。 스트림 처리 DB는 이러한 실시간 처리 니즈를 충족하며, 데이터가 스트림으로流入하는 동안 지속적으로 결과를 산출한다.
배경
스트림 처리 개념은 1970년대 데이터 흐름 언어(Dataflow Programming)에서 비롯되었다. 이후电信 및 금융 분야でのリアルタイム処理 필요性に 따라CEP (Complex Event Processing) 기술이 발전했다. 2010년대에는 LinkedIn에서 개발된 Apache Kafka(2011年)가 분산 메시지 큐의 사실상 표준이 되었고, Kafka Streams, Apache Flink, Apache Storm 등의 스트림 처리 엔진이 등장했다. 최근에는 스트림 처리와 데이터베이스를 통합한 Stream Processing Database(如 Kafka Streams, KSQLDB, Materialize)も注目を集めている.
비유
스트림 처리는大型항공사 관제塔와 같다. 비행기가離陸하면 실시간으로 위치, 속도, 고도 등의 데이터가 흘러들어오고(데이터 스트림), 관제사는 이를 실시간으로 모니터링하여 충돌 위험이 있으면即時 경고を発한다(실시간 분석). 전통적인 배치处理는 비행기가 다落地한 후 정보를まとめて確認するが、스트림 처리는 비행 중常に監視する。 실시간성이 필요한 시스템에서 배치处理는使用불가능하다.
📢 섹션 요약: 스트림 처리 DB는 데이터 스트림을 실시간으로 처리·분석하는 DB로, 수 밀리초~수 초의 극低 지연으로 실시간 분석, 연속 Queries,事件驱动 애플리케이션을 지원한다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
배치 처리 vs 스트림 처리
┌─────────────────────────────────────────────────────────────────────────────┐
│ 배치 처리 vs 스트림 처리 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [배치 처리 (Batch Processing)] │
│ ───────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Data │──▶│ Storage │──▶│ Batch │──▶│ Results │ │ │
│ │ │ Source │ │ (File, │ │ Process │ │ │ │ │
│ │ │ │ │ DB) │ │ │ │ │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │
│ │ 시간: ────────────────────────────────────────────────────▶ │ │
│ │ │←────────── Batch Interval (수시간~수일) ──────────→│ │
│ │ │ │
│ │ 예: 야간 DW 배치 (매일 자정 실행) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ [스트림 처리 (Stream Processing)] │
│ ───────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Data │──────▶│ Stream │──────▶│ Results │ │ │
│ │ │ Stream │ │ Process │ │ │ │ │
│ │ │ │ │ (Kafka, │ │ │ │ │
│ │ │ Events │ │ Flink) │ │ │ │ │
│ │ │ flowing │ │ │ │ │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │
│ │ 시간: ────────────────────────────────────────────────────▶ │ │
│ │ │←── Event-by-event processing (수ms~수s) ──────────→│ │
│ │ │ │
│ │ 예: Kafka Topic → Flink Streaming → 실시간 대시보드 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ [핵심 차이] │
│ ─────────── │
│ ┌──────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 특성 │ 배치 처리 │ 스트림 처리 │ │
│ ├──────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 데이터 범위 │ 저장된 데이터 (at rest) │ 유입되는 데이터 (in motion)│ │
│ │ 처리 지연 │ 높음 (수시간~수일) │ 극低 (수ms~수s) │ │
│ │ 처리 단위 │ 배치 (수천~수백만 행) │ 이벤트 (1개~배치) │ │
│ │ 결과 종류 │ 최종 결과 │ 증분 결과 (계속 갱신) │ │
│ │ 용도 │ 재무 보고, 일/주간 분석 │ 실시간 모니터링, 탐지 │ │
│ └──────────────────┴────────────────────────┴────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
스트림 처리 아키텍처
┌─────────────────────────────────────────────────────────────────────────────┐
│ 스트림 처리 아키텍처 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [Kafka 기반 스트림 처리 파이프라인] │
│ ───────────────────────────────── │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Source │ │ Source │ │ Source │ │
│ │ (OLTP DB)│ │ (IoT │ │ (Web │ │
│ │ CDC) │ │ Sensors) │ │ Logs) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ │ ┌──────────┼──────────┐ │ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Apache Kafka │ │
│ │ ───────────────────────────────────────── │ │
│ │ │ │
│ │ Topic: orders [P0][P1][P2]... │ │
│ │ Topic: clicks [P0][P1][P2]... │ │
│ │ Topic: sensors [P0][P1][P2]... │ │
│ │ │ │
│ │ ※ Kafka는 분산 로그로, 스트림의 Source 역할 │ │
│ └────────────────────┬────────────────────────┘ │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Kafka │ │ Apache │ │ Kafka │ │
│ │ Streams │ │ Flink │ │ KSQLDB │ │
│ │ (경량 SDK) │ │ (범용엔진)│ │ (SQL 확위)│ │
│ └──────┬────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └────────────────┼──────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Stream Processing Operations │ │
│ │ ──────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ • Filter: 특정 조건 만족 Events만 통과 │ │
│ │ • Map: 각 Event에서 특정 필드 추출/변환 │ │
│ │ • Aggregate: 창(Window) 기반 집계 (COUNT, SUM, AVG) │ │
│ │ • Join: 스트림 간 조인 (예: 주문+결제 스트림 조인) │ │
│ │ • Tumbling Window: 고정 크기 겹치지 않는 창 │ │
│ │ • Sliding Window: 고정 크기 겹치는 창 │ │
│ │ │ │
│ └────────────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Sink: │ │ Sink: │ │ Sink: │ │
│ │DW/DataLake│ │ Analytics│ │ Alerting │ │
│ │ (S3, │ │ (BI, │ │ (Fraud │ │
│ │ Redshift)│ │Dashboard)│ │ Detection)│ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Kafka Streams vs Flink 비교
┌─────────────────────────────────────────────────────────────────────────────┐
│ Kafka Streams vs Apache Flink 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 특성 │ Kafka Streams │ Apache Flink │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 개발 언어 │ Java, Scala │ Java, Scala, Python, │ │
│ │ │ │ SQL │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │Deployment │ 라이브러리 (애플리케이션 │ 독립형 클러스터 │ │
│ │ │ 내장) │ (YARN, K8s, Standalone)│ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 실행 모델 │ Kafka에만 의존 │ 완전한 스트림 처리 │ │
│ │ │ (Kafka broker 필요) │ (독립 실행 가능) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 상태 관리 │ Local State Store │ Managed State (RocksDB │ │
│ │ │ │ 내장) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ Event-time │ ✓ (Kafka 기반) │ ✓ │ │
│ │ 처리 │ │ │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ Windowing │ 기본 (Flink 대비 제한) │ 풍부 (Tumbling, │ │
│ │ │ │ Sliding, Session 등) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 복잡한Event │ 제한적 │ ✓ (CEP 라이브러리) │ │
│ │ 처리 (CEP) │ │ │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ SQL 지원 │ KSQLDB 별도 설치 │ Flink SQL 내장 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 사용 난이도 │ 낮음 (단순한 경우) │ 높음 (복잡한 경우) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 적합场景 │ Kafka 기반 단순 스트림 │ 복잡한 대용량 스트림 │ │
│ │ │ 변환/앱 │ 처리, ML 파이프라인 │ │
│ └────────────────┴────────────────────────┴────────────────────────┘ │
│ │
│ [KSQLDB: Kafka-native SQL] │
│ ──────────────────────────── │
│ • Kafka topic의 데이터를 SQL로 查询/변형하는 스트림 처리 엔진 │
│ • CREATE STREAM, CREATE TABLE, SELECT 등의 SQL 문법 지원 │
│ • 예: │
│ CREATE STREAM suspicious_orders AS │
│ SELECT order_id, customer_id, amount │
│ FROM orders │
│ WHERE amount > 1000000 AND amount > AVG(amount) OVER LAST 1 HOUR; │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
스트림 처리 핵심 개념
┌─────────────────────────────────────────────────────────────────────────────┐
│ 스트림 처리 핵심 개념 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [Event Time vs Processing Time] │
│ ────────────────────────────── │
│ │
│ Event Time: Event가 실제로 발생한 시간 (로그에 기록된 타임스탬프) │
│ Processing Time: Event가 시스템에서 처리된 시간 │
│ │
│ ※ Network 지연,Consumer 처리遅延 등으로 인해 둘 사이에 차이가 발생할 수 있음 │
│ ※ Event Time 기반 처리 위해서는 Watermark机制가 필요 │
│ │
│ [Watermark] │
│ ───────── │
│ • "이 시간 이전의 Event은 모두 도착했다"는 가정 │
│ • Late event handling을 위해 사용 │
│ • 예: Watermark이 T이면, Event Time < T인 모든 Event은 이미 도착한 것으로 간주│
│ │
│ [Window] │
│ ────── │
│ • 무한 스트림을 유한 크기로 分別하기 위한概念 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Tumbling Window (고정, 겹치지 않음) │ │
│ │ ───────────────────────────────── │ │
│ │ │ 0-5min │ 5-10min │ 10-15min │ 15-20min │ │ │
│ │ └─────────┴──────────┴──────────┴──────────┘ │ │
│ │ │ │
│ │ Sliding Window (고정, 겹침) │ │
│ │ ───────────────────────────── │ │
│ │ │◀── 5min ──▶│◀── 5min ──▶│◀── 5min ──▶│ │ │
│ │ └───────────┴───────────┴───────────┘ │ │
│ │ │ │
│ │ Session Window (동적, 사용자 세션 기반) │ │
│ │ ───────────────────────────────── │ │
│ │ │ Session A (1min) │ Session B (30s) │ Session A (2min) │ │ │
│ │ └─────────────────┴─────────────────┴──────────────────┘ │ │
│ │ ※ 일정 시간 이상gap이 있으면 새로운 Session으로 인식 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 스트림 처리는 배치 처리와根本적으로 다른 패러다임으로, 데이터를 저장하지 않고event-by-event로 실시간 처리한다. Kafka Streams는 Kafka 생태계 내에서軽량하게 스트림 처리를 하는 데 적합하고, Apache Flink는より 복잡한 대용량 스트림 처리와 ML 파이프라인에 적합하다. Event Time 처리를 위해서는 Watermark와 Window 개념이 필수적이며, 이를 통해 무한 스트림을 유한 단위로分析할 수 있다.
📢 섹션 요약: 스트림 처리 DB는event-by-event 실시간 처리로 극低 지연을 제공하고, Kafka Streams와 Flink 등이 대표적이며, Event Time 처리를 위해 Watermark와 Window 개념이 활용된다.
Ⅲ. 결론
스트림 처리 DB는 데이터 스트림을 실시간으로 처리·분석하는 핵심 기술로, Kafka, Flink, Kafka Streams, KSQLDB 등이 있다. 배치 처리와 달리 데이터를 저장하지 않고event-by-event로 처리하여 수 밀리초~수 초의 극低 지연을 제공한다. Event Time 기반 처리, Watermark, Window 등의 개념을 통해 무한 스트림을 유한 단위로 분석할 수 있다. 금융 사기 탐지, IoT 모니터링, 실시간 추천, 네트워크 침입 감지 등 실시간성이 필수적인 다양한領域에서 활용된다.
📢 섹션 요약: 스트림 처리 DB는event-by-event 실시간 처리를 통해 극低 지연을 제공하며, Kafka Streams, Flink 등이 대표적이고, Event Time, Watermark, Window 등의 개념으로 무한 스트림을 분석한다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ Stream Processing DB Concept Map │
│ │
│ ┌─────────────────────────────────┐ │
│ Stream Processing DB │ │
│ (스트림 처리 DB) │ │
└───────────────┬─────────────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Apache │ │ Kafka │ │ KSQLDB / │ │
│ │ Flink │ │ Streams │ │ Materialize │ │
│ │ (범용 엔진) │ │ (경량 SDK) │ │ (SQL 기반) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ └────────────────────┼────────────────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Event Time + │ │
│ │ Watermark + │ │
│ │ Windowing │ │
│ └─────────────────────┘ │
│ │
│ 용도: 실시간 분석 | 사기 탐지 | IoT 모니터링 | 이상 감지 | 추천 시스템 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- 스트림 처리 DB는 데이터 스트림을event-by-event로 실시간 처리한다.
- Apache Kafka, Flink, Kafka Streams, KSQLDB 등이 대표적이다.
- 배치 처리와 달리 데이터가 유입되는 시점에 바로 처리한다.
- Event Time, Watermark, Window 등의 개념을 활용한다.
- 수 밀리초~수 초의 극低 지연으로 실시간 분석을 지원한다.
- 금융 사기 탐지, IoT 모니터링, 실시간 추천 등에 활용된다.