实时分析

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的托管轮廓。遵循这些做法，该平台在秒内获得准确的信号和解决方案，以可控的成本支持合规性，产品场景和运营可持续性。