加密賭場

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」。