實時分析

1）目的和業務價值

• AML/Antifrod：存款結構，velocity攻擊，風險交易。
• Responsible Gaming （RG）：超越限制、風險模式、自我體驗。
• SRE/操作：及早檢測SLA降解、錯誤爆發、群集過熱。
• 產品和營銷：個性化觸發器,任務/任務,實時分割.
• 運營報告：近實時GGR/NGR，大廳/提供商的行車記錄板。

目標基準： p95端對端0。5–5 с, completeness ≥ 99.5％，可用性≥ 99。9%.

2）參考體系結構

1.Ingest/Edge — `/events/batch` (HTTP/2/3), gRPC, OTel Collector;電路驗證，反配對，地理路由。
2.事件總線-Kafka/Redpanda（通過「user_id/tenant/market」，DLQ，3-7天的續集）。
3.流處理-Flink/Spark Structured Streaming/Beam：靜態操作員,CEP, watermarks, allowed lateness, dedup。
4.在線豐富-Redis/Scylla/ClickHouse lookups（RG限制，KYC，BIN→MCC，IP→Geo/ASN），帶有計時器的異步調用和後退。
5.Serving-ClickHouse/Pinot/Druid（1-5分鐘的操作展示），Feature Store（在線標誌），webhooks/ticketing/SOAR。
6.Lakehouse-青銅/Silver/黃金，用於長期固定，回放和焊接。
7.可觀察性-piplines，tracing（OTel），logi，lineage和cost-dashbords的度量。

3）信號和分類法

付款： '付款。deposit/withdraw/chargeback`.

遊戲："遊戲。bet/payout"，會議。

身份驗證和行為： 'auth。login/failure`, device-switch, velocity.

操作：latency, error-rate,重新啟動pods, aturation。
合規性：制裁篩查，RG標誌，DSAR事件。

每種類型都有所有者（域所有者），電路，SLO新鮮度和長期數據策略。

4）窗口、水廠和長期數據

窗口：tumbling （fix.），hopping（重疊），session（非活動性）。
Watermark：「時間知識」邊界（通常為2-5分鐘）。
遲到的事件：調整發布前，「late=true」標誌，嚴重延遲時的DLQ。

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） CEP和stateful聚合

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

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

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

6）Exactly-Once，順序和冪等

TTL 24-72小時內通過處理上的「event_id」在總線+後端進行一次交付。
順序：按鍵分組（保證本地順序）。
Sink：事務性命題（2階段）或idempotent upsert/merge。
Outbox/Inbox：從OLTP對域事件進行事務性發布。

7）在線豐富和功能商店

Lookup：事件發生時的RG限制，KYC狀態，BIN→MCC，IP→Geo/ASN，市場/稅收，FX。
異步調用：具有計時器的制裁/RER API；錯誤時為「unknown」+retray/緩存。
功能商店：在線/離線約定；一個轉換代碼庫。

8）實時店面和伺服器

ClickHouse/Pinot/Druid：秒/分鐘單元，材料化視圖，SLA延遲1-5分鐘。
API/GraphQL：dashbords/widgets的低潛伏期。
Alerts：具有豐富上下文的webhooks/Jira/SOAR（trace_id，最後的事件）。

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）度量標準，SLI/SLO和dashbords

• p95 ingest→alert ≤ 2 c（關鍵規則），≤ 5 c（其他）。
• T ≥ 99窗口的完整性。5%;Schema validity ≥ 99.9%;Trace coverage ≥ 98%.
• 流服務的可用性≥ 99。9%;late-ratio ≤ 1%.

• 按政黨/斧頭劃分；運營商忙碌的時間；狀態大小。
• 漏鬥「sobytiye→pravilo→keys」，通過域進行精制/回收。
• 晚期/完整熱卡；熱線鑰匙卡。

10）流DQ（質量）

Ingest驗證：schema/enums/size-limits，anti-Dubly。
在線程上：completeness/dup-rate/late-ratio,窗口正確性（不重復考慮）。
反應策略：critical → DLQ+pager；專業/小調→標記+報告。

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

11）隱私、安全和居留權

PII最小化：ID別名，敏感字段掩蓋，PAN/IBAN令牌化。
數據駐留：區域輸送機（EEA/UK/BR），單獨的KMS密鑰。
DSAR/RTBF：在下遊櫥窗上進行選擇性編輯；用於案例/報告的法律保留。
審計：不可更改的訪問權限/規則更改，發布日誌。

12）經濟和生產力

Sharding/Keys：避免熱鍵（salting/Composite）,聚會平衡。
狀態：TTL，緊湊型快照，RocksDB調音/狀態後端。

預聚： reduce在早期階段為嘈雜的主題.

采樣：僅適用於非關鍵指標（非事務/合規性）。
Chargeback：主題/喬巴預算、繼電器配額和繁重查詢。

13）流程和RACI

R：流媒體平臺（infra/發行版），域分析（規則/fici），MLOps（計分/功能商店）。
答：按域分列的數據頭/風險/合規性。
C：DPO/法律（PII/Retention），SRE（SLO/事件），體系結構。

I： 產品,支持,營銷,財務.

14）實施路線圖

1.Kafka/Redpanda+2關鍵拓撲（例如「payments」，「auth」）。

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

3.ClickHouse/Pinot（1-5分鐘）的操作展示，lag/completeness行車記錄儀。

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

• 在線豐富（Redis/Scylla），功能商店，異步外觀。
• 將規則作為代碼，canary/A-B，流DQ進行管理。
• 流水線區域化，DSAR/RTBF程序，法律案件保留。

• 多區域活動，「replay&what-if」模擬器，自動閾值校準。
• 金流店面（GGR/RG/AML），近實時報告。
• Cost-dashbords，chargeback，DR教學。

15）示例（片段）

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);
}

16）售前支票清單

• Registry中的計劃/合同，背對背測試是綠色的。
• 包括watermark/allowed lateness、dedup和DLQ。
• 配置了SLO和Alerta （lag/late/dup/state size）。
• 通過緩存和時間表豐富；fallback «unknown».
• RBAC/雙控制規則/模型；已啟用更改日誌。
• 規則文件/店面；runbook'和反射/回滾。

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

忽略事件時間：沒有水上標記「漂浮」。
沒有重復數據消除：錯誤的alerta,雙重計數。
熱鍵：傾斜批次→ salting/resharding。
同步外部API熱路：只有async+緩存。
非管理成本：預聚、TTL狀態、配額、成本監控。
缺少模擬器：在沒有「重播」→回歸的情況下退出。

18）結果

實時分析不是「快速BI」，而是具有合同，狀態邏輯，CEP，水上市場，在線豐富和嚴格SLO的托管輪廓。遵循這些做法，該平臺在秒內獲得準確的信號和解決方案，以可控的成本支持合規性，產品場景和運營可持續性。