流式處理

流處理是什麼

流處理是對無限事件序列（事務日誌、點擊、支付、遙測）的連續響應，最小延遲並保證狀態正確性。與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）。客戶展示應該能夠更新。

底線

流處理不僅是低延遲，而且是時間，狀態和合同的紀律。正確選擇活動時間、窗口和水印,再加上等效效果、可觀察性和測試,使傳送帶可靠、可復制且經濟高效,並為企業提供「在這裏和現在」而不是「過夜」的解決方案。