流媒体和流媒体分析

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以及可观察性，隐私性和控制成本。按照所描述的做法，该平台获得了可靠的风险检测器，操作面板以及具有可预测潜伏性和成本的个性化。