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）并控制成本。构建强大的自我服务平台，输入联邦标准和"数据即产品"文化，您的分析生态系统与业务一起扩展-不会失去质量，速度和合规性。