流式处理

流处理是什么

流处理是对无限事件序列（事务日志、点击、支付、遥测）的连续响应，最小延迟并保证状态正确性。与batch不同，在batch中，"获取所有累积的周期"，线程在到达时处理数据，保持状态并考虑事件的时间。

关键概念

事件（event）是具有"event_time"和唯一的"event_id"的不可变事实。
事件时间（event time）与处理时间（processing time）-第一个来自源,第二个来自操作员实际看到事件时。

窗口（windows）-按时间分组事件：

Tumbling（不重叠），Hopping/Sliding（重叠），Session（非活动断裂）。
水印（watermarks）-估计"T点之前的事件已经到来"，允许关闭窗口并限制对迟到数据的等待。
滞后数据（lateness）-"event_time"小于当前水上的事件；通常适用加工规则。
状态（state）-用于聚合、加入、重复数据消除的本地表/语句存储（keyed state）。
Backpressure-超过下游吞吐量的压力；由协议和缓冲区管理。

建筑基础

1.资料来源：事件经纪人（Kafka/NATS/Pulsar），CDC来自DB，队列，文件/日志收集器。
2.流引擎：计算窗口,聚合,joins,模式（CEP）,控制状态和checkpoint 'ami。
3.接收器（sink）：OLTP/OLAP DB，搜索引擎，缓存，拓扑，店面/报告存储。
4.方案注册表：控制付费的演变和兼容性。
5.可观察性：度量标准，tracing，logi，laga和水印的dashborda。

时间语义和顺序

总是喜欢事件时间：这是延迟和中断的唯一不变量。
事件可能不合时宜；该命令仅在党键内得到保证。

Watermarks允许：

关闭窗口并发布结果；
限制"等待多少"滞后事件（"allowed_lateness"）。
对于迟到的事件,请使用retractions/upserts：重新计算聚合和纠正事件。

状态和可靠性

Keyed state：数据集合（总和、计数器、用于重复数据消除的结构）通过分流分布在密钥上。
Checkpoint/Savepoint：恢复的周期性状态快照；savepoint-用于迁移代码版本的受控快照。

仅通过效果来实现：

事务性"阅读处理记录"（commit sink+阅读位置）；
等容器（upsert/merge）+重复数据消除表；
通过聚集体转化（optimistic concurrency）。

窗口、聚合、join 's

窗口是：

Tumbling：简单的定期报告（分钟、小时）。
Hopping/Sliding："滑动"度量（5分钟1分钟）。
会话：对于自定义会话和防冻自然。
Aggregations: sum/count/avg/approx-distinct (HyperLogLog), percentiles (TDigest/CKMS).
Stream-Stream join：需要通过键和时间缓冲双方,尊重"allowed_skew"。
Stream-Table join （KTable）：附加目录或当前状态（例如,"活动用户限制"）。

处理滞后和重复数据

重复数据消除：通过"event_id"或"（producer_id，序列）"；从TTL ≥重播窗口存储"可见"密钥。
后期活动：在关闭后允许窗口在"X"期间进行重新装修（重新装修/升级）。
虚假重复：一步一步调整集合,并在日志中捕获"ALREADY_APPLIED"。

扩展和性能

按键：提供并发；留意热键。
Backpressure：限制并行性,发布时使用蹦床和压缩。
水印：不要过于激进--硬水厂减少了等待，但增加了后期更新的比例。
状态：选择格式（RocksDB/state store/内存），并考虑访问的大小和模式；清洁TTL。
自动缩放：通过滞后，CPU，状态大小，GC时间。

可靠性和重新启动

具有正交固定的Idempotent sink或事务性商品是正确性的基础。
重新启动后允许重新处理；效果必须保持"正好一次"。
DLQ/parking lot：将问题记录发送到具有原因的独立线程；确保重新整理。

可观察性（测量的内容）

按来源排列（按时间和消息排列）。
Watermark/当前事件的时间和较晚事件的份额。
Throughput/latency运算符，p95/p99端到端。
State size/rocksdb I/O，checkpoint频率/持续时间。
DLQ率,重复数据消除/重复数据删除百分比。
CPU/GC/heap，停顿时间。

安全性和合规性

数据分类：PII/PCI在电路中标记，存储最小值，加密状态和快照。
访问控制：在拓扑/状态表和sinks上单独的ACL。
转介：符合法律要求（GDPR/遗忘权）。
审核：编写"event_id"、"trace_id",结果："APPLIED/ALREADY_APPLIED/RETRIED"。

实施模式

1.CDC →域事件→正常化：不要广播原始的DB更改，请了解可以理解的业务事实。
2.生产者的Outbox：交易事实+事件-单个DB交易。
3.Core vs Enriched：关键流中的最小负载,异步丰富。
4.Replay友好：投影/店面必须从日志中重新包装。
5.Idempotency by design： operation/event key, upsert schema,聚合版本。

测试

单位/基于属性的：聚合和变换不变量。
流测试：带有顺序和重复的固定事件流→检查窗口和重复数据消除。
Golden windows：参考窗口/聚合和允许的后期调整。
断层喷射："记录效果"和"commited offset"之间的下降。
Replay tests：从日志开始重新组合店面=当前状态。

成本和优化

窗口和水厂会影响延迟/资源：窗口越长,"allowed_lateness"越大,状态越大。
编解码器和压缩：平衡CPU/网络。
在输出中击球：减少网络呼叫和事务。
提早过滤（"pushdown"）：尽可能靠近源丢弃多余的过滤器。

反模式

在需要活动时间的地方进行处理时间→不正确的分析。
Sink中缺乏幂等性→重启时的双重影响。
全球"巨键"：一个热分区打破并发。
原始CDC作为公共事件：DB方案泄漏，进化脆弱。
没有DLQ："有毒"消息会阻止整个传送带。
固定的硬延迟而不是水上市场：要么是永恒的等待，要么是数据丢失。

域示例

付款/财务

"Payment."流，用于防冻的窗口（session+CEP），"operation_id"的滞后。
分解为会计ledger（upsert+版本）时的异常效果。

营销/广告

Sliding CTR/转换窗口，Join点击和放映，并带有"± Δ t"接收，bidding aggregation。

iGaming/在线服务

实时平衡/限制，任务/静音（会话窗口），反亲缘模式和警报。

迷你模板（伪代码）

带有水印和后期更新的窗口

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

带有ofset提交的事务性sink

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

生产清单

确定活动时间和水上市场战略；选择了窗口和"allowed_lateness"。
带有正交的偶数小吃或事务性商品。
包含电路注册表和兼容性模式；加性演化。
度量标准：lag, watermark, p95/p99, DLQ, state size, checkpoint持续时间。
测试：out-of-order,副本,重新启动,replay。
国家和狙击手的PII/复仇政策。
缩放计划和逆冲策略。
窗口合同和调整文档（最新更新）。

FAQ

活动时间是强制性的吗？
如果指标的正确性和一致性很重要，-是的。处理时间适用于技术计算/监视，但会扭曲分析。

是否需要exactly-once？
点：对于关键效果。更常见的是足够的at-least-once+等效的sink。

如何选择窗口?

推回商业SLA："在过去5分钟内"→希望，"用户会话"→会议，"分钟报告"→ tumbling。

如何处理后期数据?

允许有限的"allowed_lateness"并进行调整（upsert/retract）。客户展示应该能够更新。

底线

流处理不仅是低延迟，而且是时间，状态和合同的纪律。正确选择活动时间、窗口和水印,再加上等效效果、可观察性和测试,使传送带可靠、可复制且经济高效,并为企业提供"在这里和现在"而不是"过夜"的解决方桉。