9148c358d0
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
6.7 KiB
6.7 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | verification_status | tags | raw_sources | last_reinforced | github_commit | tech_stack | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| wiki-2026-0508-event-stream-processing | Event Stream Processing | 10_Wiki/Topics | verified | self |
|
none | A | 0.93 | applied |
|
2026-05-10 | pending |
|
Event Stream Processing
매 한 줄
"매 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.
매 핵심
매 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.
매 핵심 개념
- 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.
매 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.
매 응용
- Real-time fraud detection.
- IoT telemetry aggregation.
- Live dashboards (clickstream).
- CDC → search index sync.
- AI feature stores (real-time).
💻 패턴
Pattern 1: Kafka producer (TS)
import { Kafka } from "kafkajs";
const kafka = new Kafka({ brokers: ["broker:9092"] });
const producer = kafka.producer({ idempotent: true, maxInFlightRequests: 5 });
await producer.connect();
await producer.send({
topic: "orders",
messages: [{
key: order.id,
value: JSON.stringify(order),
headers: { "event-time": Date.now().toString() },
}],
});
Pattern 2: Flink DataStream (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");
orders
.keyBy(o -> o.userId)
.window(TumblingEventTimeWindows.of(Time.minutes(1)))
.aggregate(new OrderCountAgg())
.sinkTo(new MetricsSink());
Pattern 3: Kafka Streams aggregation
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");
Pattern 4: Streaming SQL (Flink SQL / RisingWave)
-- 매 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;
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;
Pattern 5: Bytewax (Python streaming)
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)
# 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)
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
- 응용: Feature Store
- Adjacent: 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 |