Data Mesh：聯合數據模型
（部分： 技術和基礎設施）
簡短摘要
Data Mesh是一個組織和技術模型，其中數據被視為域命令的產品，平臺的核心作用是提供自我服務，標準和合規性。對於iGaming來說，這意味著：Payments團隊擁有「Deposit Events」和「Net Deposits Mart」，Risk團隊擁有「Fraud Signals」，Games擁有「Bet Events」和「Leaderboards」，中央平臺提供目錄，電路合同，可訪問性，質量監控，苯丙胺和流媒體/ELT工具。
1） Data Mesh原則
1.域責任：每個域（Payments、Risk、Games、KYC/Compliance、CRM、Affiliate）都擁有其數據集及其生命周期。
2.數據作為產品：每個集合都有所有者、說明、SLO、SLA訪問、文檔、版本、反饋和路線圖。
3.自助服務平臺：標準的pipline ingest/transform/serve,模板,默認安全性,目錄和可觀察性。
4.聯邦治理：計劃通用標準，度量，PII/本地化和質量-中心；實現和演化-在領域。
2）操作模式和角色
Domain Data Product Owner （DPO）：優先級、SLO、數據產品改進支持。
Domain Data Engineer/Analytics Engineer：圖形、pipline、DQ測試、驗證。
域管道：字段語義，與度量詞典和PII分類匹配。
平臺團隊：目錄，IAM/RBAC，Policy-as-Code，表格格式（Delta/Iceberg/Hudi），編排，可觀察性，泡沫。
聯邦政府委員會：批準標準（方案，度量，安全性），解決跨域爭議。
3）「數據產品」-護照和文物
數據產品的最小組成：- 合同（方案，類型，演變，兼容性）。
- 存取API （SQL/表格, topic/stream,文件/共享）。
- SLA/SLO（新鮮，可用性，質量）。
- DQ測試（唯一性，範圍，引用完整性）。
- 文檔（字段說明、查詢示例、所有者、聯系人）。
- 轉化（方案的語義版本，刪除策略）。
- 政策（PII，本地化，retention/TTL，權利）。
護照模板（YAML,示例）
yaml name: bets. events. v1 domain: games owner: games-data@company interface:
sql: lakehouse. silver. bets_events stream: kafka://bets. events. v1 share: read-only (EU only)
schema_version: 1. 3. 0 slo:
freshness: "<= 5 min (p95)"
availability: ">= 99. 9%"
dq:
- unique: bet_id
- valid_values: currency in [EUR, USD, TRY, BRL]
- non_negative: [stake, payout]
security:
pii: false region: EU retention: 365d lineage:
sources: [game_engine. outbox, payments. psp. webhooks]
consumers: [crm. triggers, risk. realtime, dwh. fact_bets]
versioning:
compat: backward deprecation_policy: "60 days"4）互操作性和標準
計劃/合同：Avro/Protobuf/JSON-Schema+Schema Registry；背對背政策，禁止在沒有新主要版本的情況下中斷更改。
語義層：GGR，NGR，Net Deposits，LTV的統一定義，隊列-作為代碼（dbt metrics/semantic layer）。
標識符：全球「player_id」、「tenant_id」、「bet_id」、統一的國家/貨幣/提供商目錄。
元數據：必修欄「ingest_ts」，「schema_version」，「trace_id」，「source」，「region」。
訪問：SQL（lakehouse/OLAP），流（Kafka/Pulsar），Sharing 表/snapshots；交換格式為Parquet/Delta/Iceberg。
5）技術基準（對供應商不可知）
Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold;增量「MERGE」，SCD，材料店面。
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
目錄/線性：單一目錄、自動文檔、依存關系圖。
可觀察性：新鮮度度量/SLO，DQ-assert，流瀉藥，成本。
策略：IAM/RBAC/ABAC,加密,本地化（數據區域路由）。
6）數據產品的SLO/SLA
目標SLO的示例：- Freshness: Bets Events (p95) ≤ 5 мин;Fraud Signals ≤ 30秒；Net Deposits Mart ≤ 15分鐘。
- Availability: ≥ 99.9%用於讀取接口。
- 質量：復制品≤ 0。01%，空白必填字段比例≤ 0。1％，貨幣一致性100％。
- Cost SLO：店面掃描費用≤ N美元/天，小文件評分<10%。
7）安全、PII和本地化
分類：PII/敏感基金/手術。
技術措施：加密at-rest/in-transit；PII令牌化；掩蓋專欄；通過「tenant_id」行級過濾器。
本地化：域名產品在授權區域發布（EU/TR/LATAM）；跨境球只是沒有PII的單位。
審計：誰出版/閱讀；電路版本；要求升級權利-通過協商。
8）FinOps和價值管理
域預算：計算限制，超支差異。
存儲：存儲類+TTL（青銅短，銀平均，金長/集合）。
查詢優化：批次/群集，實例化視圖，BI結果緩存。
Small files： compaction/OPTIMIZE策略；目標文件大小128-1024 MB。
9）生命周期和進化
轉化："域。product.v{major}`;次要字段是背對背。
Deprekate：消費者通知，「雙軌」時期，舊版本的自動變量。
模式更改：向合同存儲庫索取；CI兼容性測試；自動發布到目錄中。
反饋：產品渠道（issue tracker），消費者NPS，事件響應時間。
10）iGaming的具體化-域名和產品地圖
Payments
`payments.psp.webhooks.v1` (stream)
`mart_net_deposits_daily.v1 '（SQL）-SLO新鮮度≤ 15分鐘；PII-free
Games
`bets.events.v1' （stream/SQL）-p95 ≤ 5分鐘
`mart_ggr_daily.v1' （SQL/MV）-按國家/遊戲分組
Risk/Anti-fraud
`risk.signals.v1'（stream）-p95 ≤ 30秒
`risk.case_mgmt.v1' （SQL）-調查歷史SCD2
CRM/Personalization
`crm.triggers.v1' （stream）-分段觸發器
`profile.features.online.v1 '（KV/SQL）-在線字幕（TTL）
KYC/Compliance
`kyc.status.v1' （SQL）-PII受保護,row-level policies
`responsible_gaming.events.v1' （stream）-限制/信號
11）平臺流程和工件
目錄：按域/字段/PII標記搜索，模式預覽和示例。
模板生成器：cookiecutter為新產品（護照,CI, DQ測試,dashboard SLO）。
政策即代碼：區域之間的出口規則，PII，沙林。
可觀察性：現成的行列板：Freshness，DQ錯誤，成本，線性，Stream lag。
Runbooks：新鮮/DQ/電路事件，緊急刪除，版本回滾。
12）遷移到Data Mesh（路線圖）
1.當前數據集的清單→按域分組。
2.2-3域飛行員（Payments, Games, Risk）-作為帶有護照的產品簽發。
3.目錄和標準：方案，度量，PII/本地化，DQ。
4.自我服務：piplines模式，CI/CD，SLO監視。
5.將整體店面切成域；對舊接口的「雙軌」支持。
6.聯邦委員會-定期開會，審查變更合同。
7.擴展到CRM/附屬機構/市場營銷,然後擴展到合作夥伴共享。
13）實施支票
域定義；指定了所有者和通信渠道。
目錄正在運行；每種產品的護照都已公布。
模式-在合同存儲庫中；CI 測試兼容性/DQ。
SLO/SLA已申報；Freshness/DQ/Cost dashbords可用。
PII/本地化策略-代碼；已啟用審計。
FinOps：預算，Alerta，「按領域成本」報告。
轉化/丟棄過程-記錄並自動化。
Runbooks事件-可用和退試（遊戲日）。
14）反模式
「重命名為Data Mesh,但一切都通過中央數據命令」-狹窄的喉嚨不會消除。
沒有單一的度量詞典→ GGR/NGR在域之間有所不同。
沒有合同和兼容性測試的方案→「打破」版本。
沒有Self-serve →每個表都是手動創建的，高時間到數據。
忽略跨區域Sharing中的PII/本地化。
沒有所有者/SLO的微產品是「廢棄」數據。
15） KPI成功Data Mesh
時間到數據：從想法到可用數據產品（↓中位數）。
重復使用：每個產品的消費域數。
質量：成功的DQ檢查的比例，數百萬個事件的缺陷。
可靠性：符合SLO的新鮮度/可用性。
費用：$/查詢/用戶，小文件份額，計算處置。
更改速度：每周發布電路/店面。
結果
Data Mesh不僅是技術，而且是管理域聯盟，其中數據是與所有者，SLO，合同和質量指標的產品。在iGaming中，這種方法可以消除狹窄的喉嚨，加快整合（反氟化物，支付，CRM），提高度量的透明度（GGR/NGR/LTV）並控制成本。構建強大的自我服務平臺，輸入聯邦標準和「數據即產品」文化，您的分析生態系統與業務一起擴展-不會失去質量，速度和合規性。