[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -1,133 +1,196 @@
|
||||
---
|
||||
id: wiki-2026-0508-event-stream-processing
|
||||
title: Event stream processing
|
||||
title: Event Stream Processing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-777ED71E]
|
||||
aliases: [Stream Processing, ESP, Streaming Analytics]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [event-stream-processing, event-driven-architecture, complex-event-processing, event-sourcing, apache-kafka, architecture-principles]
|
||||
confidence_score: 0.93
|
||||
verification_status: applied
|
||||
tags: [streaming, kafka, flink, real-time, data-engineering]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-02
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: polyglot
|
||||
framework: kafka-flink
|
||||
---
|
||||
|
||||
# [[Event stream processing]]
|
||||
# Event Stream Processing
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
이벤트 스트림 처리(Event stream processing)는 일반적인 이벤트와 주요 이벤트를 식별하고, 이를 실시간으로 수집하여 스트림 프로세서에 연속적으로 공급하는 이벤트 기반 아키텍처의 핵심 데이터 처리 방식이다 [1, 2]. 데이터 스트리밍 플랫폼을 파이프라인으로 활용하여 시스템 내외부의 실시간 정보 흐름을 주도하며, 기업의 즉각적인 의사 결정을 가능하게 한다 [1, 2]. 대규모 데이터와 높은 처리량이 요구되는 IoT 워크로드 및 실시간 분석 시스템에 매우 적합한 접근법이다 [1].
|
||||
## 매 한 줄
|
||||
> **"매 unbounded data 의 매 record-by-record 의 transform"**. 매 batch 의 ETL 의 opposite — 매 event 의 arrive 시점 에 immediately compute. 매 2026 의 매 dominant stack 의 Kafka + Flink (or Kafka Streams), 매 emerging 의 RisingWave / Materialize (streaming SQL DB), 매 cloud-native 의 Confluent Cloud / AWS Kinesis / GCP Dataflow.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **내구성을 갖춘 연속적 이벤트 로그**: 이벤트 스트리밍 환경에서 이벤트는 파티션 내에 엄격하게 정렬되며 내구성이 있는 로그(durable log) 형태로 기록된다 [3]. 큐(Queue)를 기반으로 한 방식에서는 이벤트가 소비된 후 삭제되는 경우가 많지만, 스트림에서는 이벤트가 영구적으로 저장되어 전체 이력이 유지된다 [4-6].
|
||||
- **클라이언트 주도적 소비 및 재실행(Replay) 능력**: 클라이언트는 시스템이 제공하는 스트림을 단순히 구독(Subscribe)만 하는 것이 아니라, 스트림의 어느 위치에서든 데이터를 읽을 수 있으며 스스로 읽기 위치(offset)를 진행시킨다 [3]. 이 메커니즘을 통해 클라이언트는 언제든지 스트림에 합류할 수 있고, 과거의 이벤트를 재실행(Replay)할 수 있다 [3].
|
||||
- **독립적이고 유연한 비동기 다중 처리**: 스트리밍 플랫폼(예: Azure IoT Hub, Event Hubs, Apache Kafka 등)은 파이프라인 역할을 하여 다수의 하위 스트림 프로세서로 이벤트를 분배한다 [1]. 이벤트가 스트림에 보존되기 때문에, 각 이벤트 핸들러(소비자)는 다른 핸들러에 구애받지 않고 즉시 처리하거나 주기적으로 처리하는 등 각자의 속도와 목적에 맞춰 이벤트를 비동기적으로 처리할 수 있다 [5, 6].
|
||||
- **대규모 실시간 데이터 워크로드 대응**: 주문 결제, RFID 전송, 센서 데이터 등 방대하게 발생하는 일상적 이벤트들을 실시간으로 필터링 및 변환하여 의미 있는 정보로 만들어낸다 [1, 2]. 특히 상태 변화가 잦은 IoT 환경이나 막대한 이벤트 핸들러가 연결되는 복잡한 네트워크에서 효율적인 데이터 처리를 지원한다 [6].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **시스템 복원성 및 감사 용이성(장점)**: 이벤트를 재실행(Replay)할 수 있는 특성 덕분에 시스템 장애 후의 복구, 늦게 참여한 소비자의 데이터 동기화, 버그 수정 후의 과거 데이터 재처리가 매우 용이하다 [3]. 또한 과거의 이벤트를 분석하여 사용자 행동 패턴을 파악하거나, 이벤트 소싱(Event Sourcing)을 통해 과거의 시스템 상태를 완벽히 재구성할 수 있다 [6].
|
||||
- **최종 일관성(Eventual Consistency) 감수**: 이벤트 생산자와 소비자가 비동기 채널을 통해 완전히 분리되어 작동하기 때문에, 이벤트가 게시된 직후 모든 서비스의 데이터가 즉시 일치하지 않는 데이터 지연(Time lag)이 발생한다 [7]. 시스템의 특정 부분들이 현재 상태에 대해 일시적으로 동의하지 않는 창(window)을 견딜 수 있어야 한다 [7].
|
||||
- **오류 처리 및 순서 보장의 복잡성**: 복수의 소비자 인스턴스가 동시에 실행될 때, 이벤트 처리 순서를 보장하거나 정확히 한 번(exactly-once) 처리되도록 만드는 것은 매우 까다로우며 멱등성(Idempotent)을 고려한 설계가 필수적이다 [7]. 또한 비동기 통신 중 오류가 발생하여 이벤트를 재전송(Resubmit)할 경우 이벤트가 순서를 벗어나 처리될 위험이 있다 [7].
|
||||
- **스토리지 및 디버깅 오버헤드**: 모든 이벤트를 지속적으로 저장하는 설계는 시스템 모니터링에는 유리하지만, 시간이 지남에 따라 데이터 스토리지 요구량과 비용이 기하급수적으로 증가할 수 있다 [6]. 또한 여러 비동기 구성 요소에 걸쳐 흐르는 단일 비즈니스 트랜잭션을 디버깅하고 추적하려면 Correlation ID와 같은 정교한 관측성(Observability) 도구가 도입되어야 한다 [8].
|
||||
### 매 batch vs streaming
|
||||
- **Batch**: 매 hourly/daily, 매 high latency, 매 reprocess easy.
|
||||
- **Streaming**: 매 sub-second, 매 always-on, 매 stateful.
|
||||
- **Lambda architecture**: batch + streaming hybrid (매 deprecated 2026).
|
||||
- **Kappa architecture**: streaming-only, 매 replay 의 reprocess.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
### 매 핵심 개념
|
||||
- **Event time vs processing time** — 매 event 의 produce 시점 vs broker 의 receive.
|
||||
- **Watermark** — 매 "event time T 까지의 모든 event 의 도착 의 expect" 의 signal.
|
||||
- **Window** — tumbling / sliding / session.
|
||||
- **Exactly-once semantics** — Kafka transactions + Flink checkpoints.
|
||||
- **Stateful operator** — 매 RocksDB / state backend.
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- `[[Event-Driven Architecture]]`
|
||||
- 연결 이유: 이벤트 스트림 처리는 컴포넌트 간 비동기적으로 이벤트를 생산하고 소비하는 이벤트 기반 아키텍처의 핵심 실행 모델 중 하나이다 [2, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이벤트 브로커와 메디에이터 토폴로지의 차이, 생성자와 소비자의 느슨한 결합 원리 [9].
|
||||
- `[[Complex event processing]]`
|
||||
- 연결 이유: 이벤트 스트림 처리를 통해 유입되는 단순 이벤트나 일상적 이벤트들을 시간적, 인과적 패턴으로 평가하여 복합적인 비즈니스 의미나 이상 징후를 도출할 때 사용된다 [10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순한 스트림을 넘어, 다수의 이벤트를 상관 분석(Correlation)하고 패턴을 매칭하는 정교한 데이터 해석 기법 [10].
|
||||
- `[[Event Sourcing]]`
|
||||
- 연결 이유: 스트림에 이벤트를 영구 저장하는 특성은, 애플리케이션의 상태 변경을 일련의 이벤트로만 기록하여 영속성을 확보하는 이벤트 소싱 패턴 구현의 기반이 된다 [6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 감사 추적(Audit trails) 시스템 및 데이터의 과거 상태 재구성 원리 [6, 11].
|
||||
### 매 frameworks (2026)
|
||||
- **Apache Flink 1.20** — 매 most powerful, 매 unified batch+streaming, 매 exactly-once.
|
||||
- **Kafka Streams 3.7** — 매 JVM 만, 매 library (no cluster).
|
||||
- **Apache Beam** — 매 portable runner (Flink/Dataflow/Spark).
|
||||
- **RisingWave / Materialize** — 매 streaming SQL DB, 매 incremental view maintenance.
|
||||
- **Bytewax** — 매 Python-native, 매 Rust core.
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- `[[Apache Kafka]]`
|
||||
- 연결 이유: 이벤트 스트림 처리 환경에서 높은 처리량의 데이터 수집 파이프라인 역할을 수행하며 다수의 스트림 프로세서에 이벤트를 전달하는 대표적인 플랫폼이다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 파티션, 로그 보존, 그리고 클라이언트가 오프셋을 직접 관리하는 스트림 처리의 실제 물리적 구현 구조 [1, 3].
|
||||
- `[[Azure IoT Hub]]`
|
||||
- 연결 이유: 센서 등 하드웨어 기기(IoT)에서 발생하는 대규모 스트림을 수집하고 이벤트를 전달하는 파이프라인으로 사용되는 클라우드 인프라이다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 데이터와 속도를 요구하는 IoT 워크로드에서의 이벤트 처리 방법 [1, 12].
|
||||
### 매 응용
|
||||
1. Real-time fraud detection.
|
||||
2. IoT telemetry aggregation.
|
||||
3. Live dashboards (clickstream).
|
||||
4. CDC → search index sync.
|
||||
5. AI feature stores (real-time).
|
||||
|
||||
### Deeper Research Questions
|
||||
## 💻 패턴
|
||||
|
||||
- 복수의 스트림 프로세서가 개별적인 속도로 이벤트를 읽어갈 때, 데이터 로그의 크기와 스토리지 비용을 효율적으로 제어하기 위한 보존(Retention) 정책은 어떻게 설계해야 하는가?
|
||||
- 비동기 스트림 처리 환경에서 트랜잭션 도중 오류가 발생했을 때, 데이터 일관성을 회복하기 위한 보상 트랜잭션(Compensating Transaction)은 어떻게 구현되는가?
|
||||
- 큐(Queue) 기반의 처리(정확히 한 번 처리)와 스트림(Stream) 기반의 처리(다수 소비자의 다중 페이스 처리)를 단일 시스템 내에서 결합할 때의 설계 기준은 무엇인가?
|
||||
- 고도로 분산된 스트림 환경에서 스키마 버전이 변경되었을 때, 기존 이벤트를 처리하는 레거시 소비자와 신규 소비자가 충돌 없이 동작하기 위한 이벤트 진화(Event Evolution) 전략은 무엇인가?
|
||||
- 복합 이벤트 처리(CEP)와 이벤트 스트림 처리(ESP)를 결합하여 실시간 금융 사기 탐지와 같은 예측 시스템을 구축할 때의 지연 시간(Latency) 최소화 기법은 무엇인가?
|
||||
### Pattern 1: Kafka producer (TS)
|
||||
```typescript
|
||||
import { Kafka } from "kafkajs";
|
||||
const kafka = new Kafka({ brokers: ["broker:9092"] });
|
||||
const producer = kafka.producer({ idempotent: true, maxInFlightRequests: 5 });
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** Apache Kafka, Azure Event Hubs와 같은 데이터 스트리밍 플랫폼을 사용하여 수백만 개의 IoT 센서 데이터를 수집하는 파이프라인을 구축하고, 다양한 스트림 프로세서로 전달한다 [1].
|
||||
- **System Design:** 소비자가 이벤트를 수신하더라도 큐에서 삭제하지 않는 '내구성 있는 로그(durable log)' 시스템을 설계하여, 특정 컴포넌트 장애 시 로그를 다시 읽어 시스템 상태를 안전하게 복구할 수 있도록 구성한다 [3].
|
||||
- **Operation / Maintenance:** 버그가 배포된 후 발견되었을 때, 수정된 코드를 배포한 다음 스트림의 읽기 포인터를 과거로 되돌려(Replay) 영향을 받은 이벤트들을 재처리하는 방식으로 운영 사고에 대처한다 [3].
|
||||
- **Learning Path:** 분산 시스템의 기본 개념 이해 -> 비동기 메시징 및 Event-Driven Architecture 통신 패턴 학습 -> Queue 모델과 Stream 모델 비교 -> Event Sourcing 및 스트림 분석(CEP) 심화 적용 [2, 6, 10, 13].
|
||||
- **My Project Relevance:** 고용량의 실시간 클릭스트림 데이터를 수집해야 하는 e-커머스 플랫폼, 또는 지속적으로 위치 및 상태 정보를 쏟아내는 운송 시스템(예: 차량 호출 앱)의 백엔드 실시간 분석 파이프라인 구축에 적용 가능하다 [1].
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- `[[Microservices Architecture]]`
|
||||
- 확장 방향: 마이크로서비스 간 느슨한 결합을 구현하고 데이터 일관성을 맞추기 위해 이벤트 스트리밍 및 비동기 메시지 패싱(Async Message Passing)을 사용하는 전략으로의 확장 [7, 14].
|
||||
- `[[CQRS (Command Query Responsibility Segregation)]]`
|
||||
- 확장 방향: 이벤트 스트림(이벤트 소싱)을 커맨드 모델로 저장한 뒤, 여러 개의 뷰(Read Model)로 투영하기 위해 상태를 동기화하는 구조적 패턴 연구 [15, 16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
await producer.connect();
|
||||
await producer.send({
|
||||
topic: "orders",
|
||||
messages: [{
|
||||
key: order.id,
|
||||
value: JSON.stringify(order),
|
||||
headers: { "event-time": Date.now().toString() },
|
||||
}],
|
||||
});
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: Flink DataStream (Java)
|
||||
```java
|
||||
DataStream<Order> orders = env.fromSource(
|
||||
KafkaSource.<Order>builder()
|
||||
.setBootstrapServers("broker:9092")
|
||||
.setTopics("orders")
|
||||
.setDeserializer(new OrderDeserializer())
|
||||
.build(),
|
||||
WatermarkStrategy
|
||||
.<Order>forBoundedOutOfOrderness(Duration.ofSeconds(5))
|
||||
.withTimestampAssigner((o, ts) -> o.eventTime),
|
||||
"kafka-source");
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
orders
|
||||
.keyBy(o -> o.userId)
|
||||
.window(TumblingEventTimeWindows.of(Time.minutes(1)))
|
||||
.aggregate(new OrderCountAgg())
|
||||
.sinkTo(new MetricsSink());
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Kafka Streams aggregation
|
||||
```java
|
||||
StreamsBuilder builder = new StreamsBuilder();
|
||||
KStream<String, Order> orders = builder.stream("orders");
|
||||
orders
|
||||
.groupBy((k, v) -> v.userId)
|
||||
.windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(5)))
|
||||
.count(Materialized.as("user-order-count"))
|
||||
.toStream()
|
||||
.to("user-order-counts");
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 4: Streaming SQL (Flink SQL / RisingWave)
|
||||
```sql
|
||||
-- 매 RisingWave / Flink SQL 동일
|
||||
CREATE SOURCE orders (
|
||||
order_id VARCHAR, user_id VARCHAR, amount DOUBLE,
|
||||
event_time TIMESTAMP, WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND
|
||||
) WITH (connector='kafka', topic='orders', properties.bootstrap.servers='broker:9092') FORMAT JSON;
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
CREATE MATERIALIZED VIEW user_revenue_5m AS
|
||||
SELECT user_id,
|
||||
window_start, window_end,
|
||||
SUM(amount) AS revenue
|
||||
FROM TUMBLE(orders, event_time, INTERVAL '5' MINUTES)
|
||||
GROUP BY user_id, window_start, window_end;
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 5: Bytewax (Python streaming)
|
||||
```python
|
||||
from bytewax.dataflow import Dataflow
|
||||
from bytewax.connectors.kafka import KafkaSource, KafkaSink
|
||||
from bytewax import operators as op
|
||||
|
||||
flow = Dataflow("fraud-detect")
|
||||
src = op.input("kafka-in", flow, KafkaSource(brokers=["broker:9092"], topics=["tx"]))
|
||||
parsed = op.map("parse", src, lambda kv: json.loads(kv.value))
|
||||
flagged = op.filter("suspicious", parsed, lambda tx: tx["amount"] > 10_000)
|
||||
op.output("kafka-out", flagged, KafkaSink(brokers=["broker:9092"], topic="alerts"))
|
||||
```
|
||||
|
||||
### Pattern 6: CDC stream (Debezium → Kafka → Flink)
|
||||
```yaml
|
||||
# Debezium connector config
|
||||
connector.class: io.debezium.connector.postgresql.PostgresConnector
|
||||
database.hostname: pg
|
||||
database.dbname: app
|
||||
plugin.name: pgoutput
|
||||
table.include.list: public.orders
|
||||
topic.prefix: cdc
|
||||
```
|
||||
|
||||
### Pattern 7: Exactly-once sink (Flink)
|
||||
```java
|
||||
KafkaSink<Order> sink = KafkaSink.<Order>builder()
|
||||
.setBootstrapServers("broker:9092")
|
||||
.setRecordSerializer(KafkaRecordSerializationSchema.builder()
|
||||
.setTopic("processed-orders")
|
||||
.setValueSerializationSchema(new OrderSerializer())
|
||||
.build())
|
||||
.setDeliveryGuarantee(DeliveryGuarantee.EXACTLY_ONCE)
|
||||
.setTransactionalIdPrefix("orders-")
|
||||
.build();
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Sub-second latency, JVM team | Flink |
|
||||
| Lightweight, library-only | Kafka Streams |
|
||||
| Python team, simple jobs | Bytewax |
|
||||
| SQL-only, fast iteration | RisingWave / Materialize |
|
||||
| Multi-runtime portability | Apache Beam |
|
||||
| Cloud-managed | Confluent / Dataflow / Kinesis |
|
||||
|
||||
**기본값**: 매 Kafka + Flink (전통 stack), 매 SQL-only 시 RisingWave.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Data Engineering]] · [[Distributed Systems]]
|
||||
- 변형: [[Batch Processing]] · [[Lambda Architecture]] · [[Kappa Architecture]]
|
||||
- 응용: [[Real-time Analytics]] · [[Change Data Capture (CDC)]] · [[Feature Store]]
|
||||
- Adjacent: [[Apache Kafka]] · [[Apache Flink]] · [[Event Sourcing]] · [[CQRS]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 real-time pipeline 설계, 매 streaming SQL 의 generate.
|
||||
**언제 X**: 매 daily batch 의 충분, 매 small data 의 cron job.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **No watermark**: 매 late event 의 silently drop or wrong window.
|
||||
- **At-least-once + idempotent missing**: 매 duplicate 의 downstream impact.
|
||||
- **Unbounded state**: 매 keyed state 의 TTL 의 missing — 매 OOM.
|
||||
- **Reorder reliance**: 매 partition 별 only 의 ordering — 매 cross-partition 의 X.
|
||||
- **Synchronous external call inside operator**: 매 backpressure / slow.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Flink docs, Kafka docs, "Streaming Systems" Akidau et al., RisingWave docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Flink/Kafka Streams/RisingWave + windowing |
|
||||
|
||||
Reference in New Issue
Block a user