数据模式及其演变
1）为什么是iGaming平台
可靠性：数据更改不会破坏报告、API和模型。
速率：我们安全地添加字段（KYC/RG/PSP）而不停止流。
监管：可追溯性和可重复性（审计/在线、DSAR、法律保留）。
成本：尽量减少"溢出"和后场。
2）方案的类型和居住地
事件（流）： 'payments。deposit_accepted`, `game.round_finished`.
OLTP/DDL：归一化表（KYC，帐户，限制）。
DWH/店面（黄金）：BI/ML下的未标准化单元。
Feature Store：具有一致性保证的在线/离线照片集。
外部合作伙伴合同：PSP，游戏提供商，营销来源。
符号：Avro/Protobuf（流），JSON Schema（集成），SQL DDL（DWH），Parquet schema（湖）。
3）兼容性（进化核心）
Backward-compatible：新的生产商→旧用户（添加了c default/nullable字段）。
前瞻性：旧的制作人→新的消费者（新读者忽略了额外的）。
完全兼容：两者（事件的理想目标）。
Breaking-changes：重命名/删除字段、更改类型/语义、更改密钥/分区。
规则1：事件通过添加而演化，而不是通过更改。
规则2：删除-仅在MAJOR版本的方案中删除。
4）语义版本和策略
`MAJOR.MINOR.PATCH'用于每个电路/店面/相框。
MAJOR-不兼容（新的topic/表/fich-set，双跑）。
MINOR-兼容（新的nullable/default字段，新的enum值）。
PATCH-描述/限制/注释编辑。
字段生命周期："experimental → active → deprecated → removed"（具有日期和所有者）。
5）图形注册和数据合同
Schema Registry：存储版本，兼容性，演变和所有者。
数据合同：捕获方桉+SLO质量+隐私（参见数据验证）。
示例（Avro，payments。deposit_accepted v1.7.0):
json
{
"type":"record","name":"deposit_accepted","namespace":"payments",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"user_id","type":"string"},
{"name":"brand","type":"string"},
{"name":"country","type":"string"},
{"name":"psp","type":"string"},
{"name":"method","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":{"type":"enum","name":"Currency","symbols":["EUR","USD","TRY","BRL"]}},
{"name":"risk_score","type":["null","int"],"default":null}, // MINOR+
{"name":"kyc_level","type":["null",{"type":"enum","name":"Kyc","symbols":["L0","L1","L2","L3"]}],"default":null}
],
"compatibility":"FULL","owner":"team-payments"
}6）迁移模式
6.1个事件（流）
仅添加：添加带有default/nullable的字段；老消费者不会崩溃。
Enum扩展：新字符被认为是MINOR，要求用户具有"else/unknown"分支。
MAJOR迁移：新的topic'payments。deposit_accepted.v2', dual-write, shadow-reads,然后切换用户。
6.2 DWH/店面
蓝绿色表：'黄金。revenue_v2'靠近"v1"；通过实现，钻探，切换BI。
Backfill： snapshots+idempotent merge（按键/版本）的倒带。
SCD：用于缓慢变化的属性（限制，KYC，VIP状态）的类型2。
6.3 Feature Store
Dual-serve：旧的fich-set与新的fich-set平行；该模型通过路由器进行维护。
点对点一致性：演化不应打破PITA操纵杆（时间戳/粒度在MINOR下不变）。
7）更改分类法（支票清单）
安全（MINOR）：- 添加"nullable/default"字段；
- enum扩展（消费者具有"未知"分支）；
- 添加非关键索引/评论/说明。
- 规模/单位变动（例如，以美分计→以主要货币计算的比例变动），仅限于MAJOR；
- 通过视图层传输参考书/参考书。
- 重命名/删除字段；
- 更改类型/格式/键/分区；
- 语义更改（例如，从"累积"到"注销"的"bonus_amount"）。
8）线程和兼容性测试
Schema-lint：名称样式（"snake_case"），强制性标签（"owner"，"doc"，"pii"），日期/货币格式。
Compat-tests：针对注册表验证新版本（backward/forward/full）。
消费者合同测试：每项服务都提供"有效载荷示例"和期望；在电路变更时,赶到CI。
Golden-datasets：一组真实和"邪恶"的例子（新的enum，空白/后期字段，和的边界值）。
9）参考书，enum和本地化
参考数据（国家/货币/PSP/提供商）：更新的单独版本和SLA；不包含在事件代码中。
地方/时区：将UTC存储在事件中+用于演示的显式位置。
司法管辖区规则：年龄标志，促销限制-以带有动作日期的手册的形式。
10）多品牌/多功能和PII
Tenant隔离："brand"，"country"，"license"是带有enum的必填字段；穿过它们。
方案级别的PII策略：标记"pii=true"字段，应用掩码/令牌化；在事件中，只有令牌。
DSAR：具有"source_id/trace_id"进行删除/搜索；MAJOR迁移上的法律保留。
11） DDL和Lake Version
DDL迁移：声明性迁移（Liquibase/Flyway/dbt），存储在VCS中，由域所有者咆哮。
湖中的格式：Avro/Parquet-记录字段的演变；MAJOR是新的表格/路径"……/v2/"。
Partitioning：更改部分（例如"date'→'date,brand"）-仅通过MAJOR和双重记录。
12） iGaming示例
12.1 PSP扩展了方法
在enum中添加'method='MEFETE'。
"deposit_accepted v1"模式的MINOR版本。8.0`;不知道MEFETE的用户将发送到"unknown_method"分支。
12.2游戏提供商增加了领域
在'游戏中。round_finished'添加了"jackpot_id"（不可用）。
金色展示柜。game_rounds_v3'获得MINOR；旧报告有效，新报告认为头奖。
12.3个RG属性
从布尔的"self_excluded"到雕像的"rg_state ∈ {none, limit, cooldown, self_excluded}'-MAJOR,新的topic+dual-write+迁移店面和模型。
13）进化过程（从思想到切换）
1.Proposal （ADR）：为什么我们要改变,兼容性类型,风险评估和受影响的消费者。
2.设计与合同： 图表到注册表,semver,兼容性政策.
3.测试：linters, compat, consumer contracts, golden set reples。
4.部署：双write/blue-green/shadow-reads；Alertes。
5.对账：业务平衡/不变量（请参阅"数据验证"）。
6.Switch： 切换消费者/BI/fici。
7.Deprecate：旧方案的冻结，宽限期，删除和存档。
14）进化度量和SLO
迁移的成功率，双运行时间，新格式的事件比例，后退量，lag/freshness。
兼容性事件（P1/P2）,转换后店面质量。
Cost： $/TB溢出,$/h dual-write,群集下载。
Compliance： 0 PII泄漏,SLA DSAR/Legal Hold符合要求。
15）工具和文物
15.1兼容性政策（注册表）
yaml schema: payments. deposit_accepted compatibility: FULL default_nulls: true enums:
currency: {allow_new_symbols: true, require_consumer_unknown_branch: true}
pii: false owners: ["team-payments"]
reviewers: ["data-governance","security-dpo"]15.2迁移护照（模板）
yaml change_id: MIG-2025-041 scope: game. round_finished -> v3 type: MAJOR plan:
dual_write: true shadow_reads: consumers: ["gold-rounds","rg-models"]
backfill: {from: "2025-01-01", mode: "idempotent-merge"}
validation:
invariants: ["sum_bets = sum_wins + margin + bonuses"]
freshness_delta_p95_max: "PT5M"
switch_criteria:
error_rate_max: 0. 1%
kpi_diff_pp_max: 0. 5 deprecate_after: "2025-12-31"15.3 Linter名称和类型（规则）
总和的"snake_case"，UTC时间表，DECIMAL（18.2），ISO-3166-1 alpha-2的"country"，ISO-4217的"currency"。
enum字段没有"free_text"；参考书是外部的。
16）实施路线图
0-30天（MVP）
1.启用关键事件（payments、game_rounds、user）的Schema Registry+policy兼容性。
2.CI 中的Linters/compat测试；所有者目录和SLA评论。
3.ADR模板和迁移护照；MAJOR支票单。
30-90天
1.Blue-Green for Gold店面；关于关键话题的双重写作。
2.主要服务的消费者合同测试；golden-datasets.
3.切换时自动对接和差分；价值报告。
3-6个月
1.单个deprecate/remove过程与grace-period；存档和合法保留。
2.地理/特异性电路和加密密钥；敏感市场的DP变体。
3.字段语义目录（数据词典）和实时线图。
17) RACI
数据管理（A/R）：标准，注册表，移民评论，出版。
域所有者（R）：字段的含义，参考书，业务不变式。
数据平台（R）：注册表工具、计算测试、双运行/后门。
安全/DPO（A/R）：PII政策，geo/tenant，DSAR/法律保留。
SRE/Observability（C）：Alertes，SLO进化，能力。
产品/财务（C）： KPI验证,开关窗口。
18）反模式
没有版本和双奔跑的"我们即时统治领域"。
重命名而不是添加新字段→大规模故障。
僵硬的enum没有分支"未知"→以新的值下降。
所有司法管辖区的"代码"统一目录。
Backfill没有idempotent-merge和支票余额。
带有PII且无trace_id 搜索/DSAR的日志。
19）相关部分
数据验证、数据来源和路径、DataOps实践、API分析和指标、审计和验证、数据安全和加密、访问控制、MLOps：模型操作。
底线
方案的演变是一个过程而不是一次性迁移：注册表，版本和兼容性；双奔跑和蓝绿色代替"午夜切换"；相容性测试和业务不变性而不是运气。因此，数据保持稳定，模型是可预测的，报告是正确的，监管者是平静的。