數據模式及其演變
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：模型操作。
底線
方案的演變是一個過程而不是一次性遷移：註冊表，版本和兼容性；雙奔跑和藍綠色代替「午夜切換」；相容性測試和業務不變性而不是運氣。因此，數據保持穩定，模型是可預測的，報告是正確的，監管者是平靜的。