加密赌场

Torrent Gear

数据湖和DWH赌场：计划,SLA下载

文章全文

💡 18+.用于平台/运营商，工作室和分析团队的技术材料。不打电话。该平台理解PAM/钱包/现金/奖金/RG，提供商理解RGS/live/头奖/付款集成。

1）为什么赌场数据湖和DWH

报告和合规性：监管卸载（GGR/NGR，KYC/AML，RG），货币审计。

产品/营销：LTV/Retention,细分,A/B,推荐。

操作：监视提供商，PSP，SLA直播游戏和收银机。

数据解决方桉：在廉价的长期存储（Lake）之上快速展示（DWH）。

底线：湖泊存储原始和纯化的层，DWH提供快速查询和可管理的模型。

2）参考建筑（lakehouse）


Sources (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (raw, append-only;Parquet/Delta/Iceberg)
│   ingestion_time, source_metadata, no schema changes in place
├─Silver (cleaned, conformed;dedup, PII masking, SCD2)
│   business keys, constraints, quality checks
└─Gold (marts;star/snowflake;cube tables, aggregates)
└─DWH/Query Engines (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Lake / Apache Iceberg / Hudi (ACID в lake, time travel, MERGE).

文件：Parquet+ZSTD/Snappy，目标~ 128-512 MB；编译"小文件"。

目录：Hive/Unity/Iceberg目录；"bronze/silver/gold"区域位于per region/tenant罐上。

3）域图（概念上）

3.1钱包/会计

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
不变性：总和=平衡（通过snapshot+change log）。

3.2投注/投注（RGS/live）

`bet`: `bet_id`, `round_id`, `player_id`, `game_id`, `stake_minor`, `currency`, `placed_at`, `brand/region`, `provider_id`, `in_bonus`.

`settlement`: `settlement_id`, `bet_id`, `round_id`, `win_minor`, `settled_at`, `jackpot_hit`, `bonus_state`.

3.3付款（现金/PSP/加密）

`payment_intent`: `intent_id`, `player_id`, `method`, `status`, `amount`, `currency`, `psp`, `created_at`.

"capture/refund/chargeback"：带有"intent_id"，"psp_ref"和原因代码链接的单独表。

Крипто: `txid`, `network`, `confirmations`, `finalized_at`.

3.4 奖金/vager/头奖

`bonus_grant`, `bonus_progress (wager)`, `jackpot_contribution`, `jackpot_payout`.

3.5参考书和衡量

"dim_player"（伪ID，geo，通道，RG状态-分析中没有PII），"dim_game"，"dim_provider"，"dim_psp"，"dim_brand"，"dim_region"，日历维度。

密钥和兼容性：在Silver/Gold模型中-稳定的业务密钥（"bet_id"，"round_id"，"payout_id"，"intent_id"）和"等效"事件的语义。

4）下载流： 流媒体+微库

流媒体（Kafka/Pulsar → Bronze）：OLTP和webhook事件，outbox/CDC，"至少一次"保修以及Silver中的重复数据消除。

CDC （Debezium/复制日志）：更改OLTP表（wallet/payments） → Bronze。

微库：PSP/银行/castodi报告（SFTP/API）→青铜原始文件→规范化。

Silver的MERGE："idempotency_key/event_id"的去除，消除在测量上SCD2的迟到（"watermark"）。

5） SLA下载和延迟窗口（watermarks）

5.1类型SLA（地标）

Wallet/ledger事件：青铜≤ 1-2分钟，Silver ≤ 5-10分钟，金牌≤ 15分钟。

Bets/settlements：青铜≤ 1-2分钟，Silver ≤ 10分钟，黄金≤ 30分钟。

Payments （PSP webhooks）： Bronze ≤ 5分钟,Silver ≤ 15分钟,Gold ≤ 30-60分钟。

加密的最终性：取决于网络；带有lag N确认的店面。

每日PSP/银行报告：T+1至当地时间09：00。

5.2个延迟窗口

根据事件时间（"occurred_at"）+公差：

钱包/投注：24-48小时，付款/PSP：72小时（有复古的网络杂志），加密：每罕见的reorgas最多24小时。
后期事件：重新计算黄金店面增量（MERGE）,校正日志。

5.3 SLA通讯

数据目录包含SLA属性："freshness_target"，"freshness_status"，"expected_lag_p95"，"watermark"。

违规时，带有Alert的Dashbords"新鲜"。

6）数据质量（DQ）和合同

每个主题的数据合同包括：Avro/JSON电路，semver，必填字段，业务不变性（例如"win_minor ≥ 0"，"currency" ∈ ISO-4217"）。

DQ验证银：密钥的唯一性、参考完整性、平衡验证（钱包对账）、PSP代码的有效性/原因、日期范围。

Severity："ERROR"（阻塞），"WARN"（标记），"INFO"。

监视：违规百分比、最高原因、自动滴答作响。

Sampling&replay：储存原始青铜进行重新加工。

7） PII、居住和安全性

PII陈列柜与分析师分开：Silver/Gold是化名，蒙面/哈希，令牌化。

数据驻留：EU/UK/BR等-物理上分开的垃圾箱/目录；没有跨区域的阅读未经同意和通过。

Доступ: RBAC/ABAC (Lake/DWH), row-level security по `tenant/brand/region`.

加密：at rest （KMS）和in-transit,按区域/品牌键,WORM访问和策略更改审核。

遗忘权：游戏数据本地化而不删除财务记录的机制（de标识）。

8）金色店面模拟（明星）

8.1事实表

'fact_bets'（每行/或两张表的赌注和设置），'fact_wallet_entries'，'fact_payments'（存款/现金/退款），'fact_bonus_wager'，'fact_jackpot'。

8.2个测量

`dim_date/time`, `dim_player` (pseudonymous), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, `dim_currency`.

8.3指标和计算

GGR/NGR，保留/频率，RTP（按游戏/提供商/地区），存款转换，定格记录，success-rate PSP，按成功计算，FX-PnL，jackpot contributions/payouts。

9）生产力和成本

分期付款：通过"occurred_date"+"region/tenant"，有时用于Gold聚合的"game_id"。

聚类/Z-Order：通过"player_id"，"game_id"，"psp"，"currency"。

堆积和真空：计划中的"OPTIMIZE/COMPACT"，删除"悬挂"版本（考虑法律重组）。

缓存：结果缓存/仓库缓存，热面板的材料化视图。

DWH中的索引：聚类/分段（Snowflake群集键，BigQuery分区+群集）。

成本：对象存储中的冷黄铜，DWH中的热金/三月单元；自动停车场/自动滑道。

10）线条、目录和文档

数据目录（OpenMetadata/Amundsen/Collibra）：表格的描述，所有者，SLA，PII字段，访问策略。

线性：从源（事件/CDC）到店面和报告；可见依赖关系以进行安全更改。

Changelog方案：semver和deprecate日志；piplines CI兼容性测试。

11） Reconciliation（数据对账）

每天：

"wallet_entry" ↔总资产负债表（积聚≡ snapshot），付款：PSP/银行报告 ↔ "fact_payments"，加密："txid/network" ↔ "fact_payments"。
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
Alerts： "mismatch">阈值的份额；aging不忠实者>N日。

12）实例SLA表（示例）

域是	青铜（ingest）	Silver（清理）	黄金（3月）	后期活动（watermark）
Wallet	≤2枚地雷	≤10枚地雷	≤15枚地雷	48小时
Bets/Settlements	≤2枚地雷	≤10枚地雷	≤30枚地雷	48小时
Payments (PSP)	≤5枚地雷	≤15枚地雷	≤60枚地雷	72小时
Crypto	realtime→finalnost	≤15枚地雷	≤60枚地雷	24小时
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 d

13）Piplines： 我们从哪里收集

Ingestion： Kafka Connect/Debezium,云注入服务,SFTP pullers。

ETL/ELT：Spark/DBT/Trino/Beam/Flink（流媒体Silver），用于编排的Airflow/Argo。

质量：Great Expectations/Deeug/dbt测试。

监视：OpenTelemetry+湖泊/DWH度量（freshness delay，job latency，cost）。

事故和重播：来自Bronze的reprocess，dedup keys，转化的piplines。

14）支票单

体系结构与安全

Lakehouse格式（Delta/Iceberg/Hudi）带有ACID和时间旅行。
将"bronze/silver/gold"分开，outbox/CDC作为主要来源。
PII隔离，令牌化，RLS通过"tenant/brand/region"。
在垃圾箱/目录级别居住,按区域键或秘密。
WORM审核方案/策略/访问规则更改。

质量和SLA

数据合同和semver电路；兼容性测试。
Watermarks and reprocess,店面增量MERGE。
Dashbords的新鲜度和SLA-Alerta；每个表中的所有者。
重新分配钱包/付款/加密。

性能和成本

参与和集群；编译"小文件"。
关键报告下的实例化店面。
自动标记/自动标记，重建和档案政策。

15）红旗（反模式）

BI和监管报告直接打击OLTP。

青铜"重写"并丢失原始数据。

没有水上市场，后期事件正在"修剪"。

缺少"idempotency_key"/"event_id"的重复数据消除→ Gold中的重复数据消除。

PII和不同地区的资金一起保存，没有RLS和居住权。

电路会"悄悄"更改（没有semver/合同），打破店面。

数以百万计的小型Parquet文件没有压缩→昂贵的查询。

没有SLA/dashbords的新鲜度；季度报告中的"惊喜"。

16）结论

iGaming中的Data Lake+DWH不仅是一个存储库，而且是一个受控的生态系统：标准化计划和合同，ACID-lakehouse，清晰的SLA新鲜度和后期窗口，质量和线性，PII安全性和居住性。添加回收和聚合/聚合节省-并且您将拥有报告、产品解决方桉和业务扩展的基础，而无需夜间迁移和"手动Excel"。