流媒體和流媒體分析

1）目的和價值

• Antifrod/AML：識別存款結構，velocity攻擊，提供商異常。
• 響應性遊戲（RG）：超過限制，風險模式，自我體驗。
• 操作/SRE：SLA退化，錯誤爆發，早期事件信號。
• 產品/營銷：個性化事件,任務/任務,實時分割。
• 近實時報告：GGR/NGR店面，操作面板。

目標特性：p95端對端0。5-5秒，完整≥ 99。5%,管理成本。

2）參考體系結構

1.Ingest/Edge

`/events/batch` (HTTP/2/3), gRPC, OTel Collector.

模式驗證，反重復，地理路由。

2.事件總線

Kafka/Redpanda（通過「user_id/tenant/market」分組）。
Retention 3-7天,壓縮,DLQ/「隔離」 for 「bit」消息。

3.流式處理

Flink / Spark Structured Streaming / Beam.

Stateful運算符，CEP，watermark，allowed lateness，重復數據消除。
富集（Redis/Scylla/ClickHouse-Lookup），異步I/O和計時器。

4.Cerving/運營店面

ClickHouse/Pinot/Druid用於分鐘/秒匯總和行車記錄。
功能商店（在線）用於模型評分。
Alert topics → SOAR/ticketing/webhooks。

5.長期存儲（Lakehouse）

Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.

後退/後援，時間旅行。

6.可觀察性

Piplines度量，Tracing（OTel），Logi，lineage。

3）計劃和合同

計劃第一：JSON/Avro/Protobuf+Registry，每個事件中的「schema_version」。
演變：可匹配-新的不可分割字段；breaking-'/v2'+雙重出版物。

必填字段： 「event_time」 （UTC）、「event_id」、「trace_id」和「user」。pseudo_id`, `market`, `source`.

4）窗口,水上市場和遲到的數據

• Tumbling（固定），Hopping（重疊），Session（非活動性）。
• Watermark：事件時間的「知識」閾值；例如，2-5分鐘。
• 後期數據：大量積壓時,DLQ的調整前發出「late=true」。

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream.payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

5）Stateful聚合和CEP

關鍵字： 'user_id'，'device_id'，'payment。account_id`.

狀態：滑動金額/計數器、會話、用於重復數據消除的bloom過濾器。
CEP模式：結構（<閾值,每窗口T ≥N次）,設備開關,RG-fatigue。

python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())

6）Exactly-Once，順序和冪等

總線：at-least-once+分期密鑰提供本地順序。
相似性：'event_id'+dedup state（TTL 24-72小時）。
Sink：事務性命題（2階段）或upsert/merge-idementity。
Outbox/Inbox：保證從OLTP發布域事件。

7）實時豐富

Lookup：Redis/Scylla（RG限制，KYC狀態，BIN→MCC，IP→Geo/ASN）。
異步調用：具有定時和後退（「未知」）的制裁/RER API。
FX/時間段：金額正常化和本地市場時間（「fx_source」，「tz」）。

8）Serving和實時店面

ClickHouse/Pinot/Druid： 按分鐘/秒匯總,materialized views.

黃金流：操作表GGR/RG/AML，SLA延遲≤ 1-5分鐘。
API/GraphQL：低潛伏度用於行車記錄儀和外部集成。

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream.game_events
GROUP BY ts_min, market, provider_id;

9）可觀察性和SLO

• p95 ingest→alert ≤ 2 c（關鍵），≤ 5 c（其余）。
• T ≥ 99窗口的完整性。5%.
• 模式錯誤≤ 0。1%;「trace_id」的事件比例≥ 98％。
• 流服務的可用性≥ 99。9%.

• 按批次/拓撲，操作員忙碌的時間，狀態大小。
• 漏鬥「sobytiye→pravilo→keys」，熱鍵地圖，後期評分。
• 費用：費用/GB，費用/查詢，支票/反射費用。

10）隱私和合規性

PII最小化：ID別名，字段掩蔽，PAN/IBAN令牌化。
數據駐留性：區域輸送機（EEA/UK/BR），單獨的加密密鑰。
法律業務：DSAR/RTBF在下遊店面，法律持有案件/報告。
審核：訪問日誌,不變的解決方案歸檔。

11）經濟和生產力

Keys and Sharding：避免熱鍵（salting/composite key）。
狀態：合理的TTL，snapshots，RocksDB調音/狀態後端。
預聚：對於嘈雜的線程,上前端重置。
采樣：允許使用非關鍵度量（不適用於事務/合規）。
Chargeback：主題/喬巴預算、配額和團隊變異。

12）流DQ（質量）

Ingest驗證（計劃，enums，size），dedup「（event_id，source）」。
在線程上：completeness/dup-rate/late-ratio,窗口控制（無重復計數）。
反應策略：critical → DLQ+alert；major/minor →標記和隨後的清除。

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

13）訪問安全和發布控制

RBAC/ABAC：每個線程讀取、規則/模型更改的不同角色。
雙重控制：通過「2個密鑰」釋放規則和模型。
金絲雀/A/B：深色規則和模型啟動，精密/回收控制。
秘密：KMS/CMK，定期輪換，禁止登錄中的秘密。

14）流程和RACI

R（響應）：流平臺（infra/版本），域分析（規則/fici），MLOps（得分）。
A（Accountable）：按域分列的數據頭/風險/合規性。
C（咨詢）：DPO/法律（PII/Retention），SRE（SLO/事件），體系結構。

I （Informed）： 產品,支持,市場營銷,財務.

15）實施路線圖

1.Kafka/Redpanda+兩個關鍵的拓撲（「payments」，「auth」）。

2.帶有水廠、重復數據消除和單個CEP規則（AML或RG）的flink-joba。

3.ClickHouse/Pinot店面1-5分鐘，lag/completeness dashbords。

4.事件頻道（webhooks/Jira），基本的SLO和Alerta。

• 在線豐富（Redis/Scylla），功能商店，異步外觀。
• 作為代碼管理規則，金絲雀版本，A/B。
• 流式DQ，流水線區域化，DSAR/RTBF程序。

• 多區域主動活動，「what-if」反射模擬器，自動校準閾值。
• 全金流店面（GGR/RG/AML），近實時報告。
• Dashbords，chargeback，DR演習。

16）示例（片段）

Flink CEP — device switch:

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT() AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

17）售前支票清單

• 註冊表中的方案和合同，背對背測試是綠色的。
• 包括watermark/allowed lateness、dedup和DLQ。
• 配置了SLO和Alerta （lag/late/dup/state size）。
• 通過緩存和時間表豐富,fallback「未知」。
• RBAC/dual-control到規則/模型,所有更改均被計算。
• 規則文檔，陳列櫃和跑步簿以及反射/回滾。

18）頻繁的錯誤以及如何避免錯誤

忽略事件時間：沒有水上標記「漂浮」。
沒有重復數據消除：錯誤的Alerta和雙重計數。
熱鍵：傾斜批次→ salting/resharding。
同步外部API熱路：只有async+緩存。
非管理成本：預聚、TTL狀態、配額、成本差額板。
缺失模擬器：不帶有「重播」的輸出會導致回歸。

19）詞匯表（簡短）

CEP-復雜事件處理（事件模式）。
Watermark是事件時間窗口就緒的邊界。
Allowed Lateness-允許遲到的事件。
Stateful Operator-保存狀態的運算符。
Feature Store-一致的特征伺服器（在線/離線）。

20）結果

流媒體和流媒體分析是一個托管系統：合同，窗口和水上市場，靜態邏輯和CEP，豐富和實時店面，SLO以及可觀察性，隱私性和控制成本。按照所描述的做法，該平臺獲得了可靠的風險檢測器，操作面板以及具有可預測潛伏性和成本的個性化。