カジノ向けData LakeとDWH:回路図、SLAダウンロード
完全な記事
1)データレイクカジノとDWHの理由
報告とコンプライアンス:規制アップロード(GGR/NGR、 KYC/AML、 RG)、マネー監査。
製品/マーケティング:LTV/保持、セグメンテーション、A/B、推奨事項。
操作:プロバイダ、PSP、 SLAライブゲームおよびキャッシュレジスタの監視。
データソリューション:安価な長期ストレージ(レイク)の上に高速ストアフロント(DWH)。
ボトムライン:レイクは生のレイヤーとクリーニングされたレイヤーを格納し、DWHはクイッククエリと管理モデルを提供します。
2)リファレンスアーキテクチャ(レイクハウス)
ソース(OLTP、 Kafka、 Webhooks、 CDC)
│
├─Bronze (raw、 append-only;寄木細工/デルタ/氷山)
ingestion_time、 source_metadata、スキーマの変更はありません
├─Silver(洗浄、適合;dedup、 PIIマスキング、SCD2)
ビジネスキー、制約、品質チェック
└─Gold (marts;星/雪片;キューブテーブル、集計)
└─DWH/Queryエンジン(Snowflake/BigQuery/Trino/Spark SQL)Форматы: Delta Lake/Apache Iceberg/Hudi (ACID湖、タイムトラベル、MERGE)。
ファイル:Parquet+ZSTD/Snappy、ターゲット~ 128-512 MB;「small file」コンパクション。
カタログ:ハイブ/ユニティ/氷山カタログ;地域/テナントごとのバケツの「青銅/銀/金」地帯。
3)ドメインスキーム(概念的に)
3.1ウォレット/会計
3.2ベット/決済(RGS/ライブ)
'bet': 'bet_id'、 'round_id'、 'player_id'、 'game_id'、 'stake_minor'、 'currency'、 'played_at'、 'brand/region'、 'provider_id'、 'in_bonus'。
'settlement': 'settlement_id'、 'bet_id'、 'round_id'、 'win_minor'、 'settlement_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'、 reason codesを参照する別々のテーブル。
'txid'、 'network'、 'confirmations'、' finalized_at'。
3.4ボーナス/ベイガー/ジャックポット
'bonus_grant'、 'bonus_progress (wager)'、 'jackpot_contribution'、 'jackpot_payout'。
3.5参照および測定
'dim_player' (pseudo-ID、 geo、 channel、 RG statuses-分析にPIIなし)、'dim_game'、 'dim_provider'、 'dim_psp'、 'dim_brand'、 'dim_region'、カレンダー寸法。
キーと互換性:Silver/Goldモデル-安定したビジネスキー('bet_id'、 'round_id'、 'payout_id'、 'intent_id')と「idempotent」イベントの意味。
4)ダウンロードストリーム: ストリーミング+マイクロバッチ
ストリーミング(Kafka/Pulsar→Bronze): OLTPとWebhookイベント、outbox/CDC、少なくとも一度はシルバーで重複除外を保証します。
CDC (Debezium/レプリケーションログ): OLTPテーブル(ウォレット/決済)の変更→ブロンズ。
マイクロバッチ:PSP/bank/custom reports (SFTP/API)→Bronze Raw Files→normalization。
MERGE in Silver: 'idempotency_key/event_id'によるdedup、 latecomers('透かし')の排除、測定にSCD2。
5) SLAダウンロードとレイトウィンドウ(透かし)
5.1典型的なSLA(ランドマーク)
財布/台帳イベント: ブロンズ≤ 1-2分、シルバー≤ 5-10分、ゴールドマート≤ 15分
ベット/和解: ブロンズ≤ 1-2分、シルバー≤ 10分、ゴールド≤ 30分
支払い(PSP webhooks):ブロンズ≤ 5分、シルバー≤ 15分、ゴールド≤ 30-60分。
Crypto finality:ネットワーク依存;lag Nの確認が付いている場合を表示して下さい。
毎日のPSP/銀行レポート:T+1まで09:00地域の現地時間。
5.2遅いウィンドウ
イベントタイムによる透かし('occured_at')+公差:- ウォレット/ベット:24-48時間、支払い/PSP: 72時間(レトロなwebhookがあります)、暗号:まれな再編のための24時間まで。
- 再処理の後のイベント:ゴールドウィンドウの増分計算(MERGE)、修正ログ。
5.3 SLAコミュニケーション
データカタログには、'freshness_target'、 'freshness_status'、 'expected_lag_p95'、 'watermark'というSLA属性が含まれています。
アラート違反の「新鮮さ」のダッシュボード。
6)データ品質(DQ)と契約
各トピックのデータ契約:Avro/JSONスキーム、semver、必須フィールド、ビジネスインバリアント(例:'win_minor ≥ 0'、 'currency ∈ ISO-4217')。
Silver DQチェック:重要な一意性、参照整合性、バランスチェック(ウォレットの調整)、PSPコード/理由の有効性、日付範囲。
重要度:'ERROR'(ブロック)、'WARN'(マーキング)、'INFO'。
監視:%違反、トップの理由、自動チケット。
サンプリング&リプレイ:リサイクルのための未加工ブロンズを保存します。
7) PII、居住および安全
PIIショーケースは分析から分離されています:シルバー/ゴールド-仮名、マスキング/ハッシュ、トークン化。
データ居住地:EU/UK/BRなど-物理的に独立したバケット/カタログ。同意とプロキシなしでクロスリージョナルリーディングはありません。
RBAC/ABAC (Lake/DWH)、行レベルのセキュリティテナント/ブランド/リージョン。
暗号化:at-rest (KMS)およびin-transit(地域/ブランドキーごと)、アクセスとポリシー変更のWORM監査。
忘れられる権利:財務記録を削除することなくゲームデータをローカライズするためのメカニズム(識別解除)。
8)ゴールドウィンドウモデリング(スター)
8.1実際のテーブル
'fact_betts'、 'fact_wallet_entries'、 'fact_payments'、 'fact_bonus_wager'、 'fact_jackpot'。
8.2の測定
'dim_date/time'、 'dim_player'(仮名)、'dim_game'、 'dim_provider'、 'dim_psp'、 'dim_brand'、 'dim_region'、 'dim_currency'。
8.3メトリクスと計算
GGR/NGR、 hold/frequency、 RTP(ゲーム/プロバイダー/地域別)、入金変換、決済遅延、成功率PSP、成功あたりのコスト、FX-PnL、ジャックポットの貢献/支払い。
9)性能および費用
パーティショニング:'occased_date'+'region/tenant'により、Goldの集計のために'game_id'が発生することがあります。
クラスタリング/Z-Order: 'player_id'、 'game_id'、 'psp'、 'currency'。
圧縮と真空:計画された「OPTIMIZE/COMPACT」、 「hanging」バージョンの削除(法的保持を考慮して)。
キャッシュ:結果キャッシュ/倉庫キャッシュ、ホットパネルの実体化ビュー。
DWHのインデックス:クラスタ/セグメント(Snowflakeクラスタキー、BigQueryパーティション+クラスタ)。
コスト:オブジェクトストレージのコールドブロンズ、DWHのホットゴールド/マーチユニット。自動駐車場/自動スケール。
10)系統、カタログおよび文書
データカタログ(OpenMetadata/Amundsen/Collibra):テーブルの説明、所有者、SLA、 PIIフィールド、アクセスポリシー。
血統:ソースから(イベント/CDC)ショーケースとレポート;安全な変更のための制約の可視性。
Changelogスキーム:semverと非推奨のジャーナル;CIパイプラインでの互換性テスト。
11)和解
毎日:- 'wallet_entry' ↔合計残高(蓄積≡スナップショット)、支払い:PSP/銀行レポート↔ 'fact_payments'、 crypto: 'txid/network' ↔ 'fact_payments'。
- 検索結果:'match'、 'timing'、 'missing_source'、 'missing_platform'、' amount_mismatch'。
- アラート:'mismatch'>しきい値の割合;老化の顕著な>N日。
12)インスタンスSLAテーブル(例)
13)パイプライン: 私たちが収集するもの
Ingestion: Kafka Connect/Debezium、クラウドingestion services、 SFTP pullers。
ETL/ELT:オーケストレーションのためのSpark/DBT/Trino/Beam/Flink(ストリーミングシルバー)、Airflow/Argo。
質:大きい期待/Dequ/dbtテスト。
モニタリング:OpenTelemetry+Lake/DWH指標(鮮度遅延、ジョブ待ち、コスト)。
事故と繰り返し:ブロンズからの再処理、キー付きのdedup、バージョン管理されたパイプライン。
14)チェックリスト
アーキテクチャとセキュリティ
- Lakehouseフォーマット(デルタ/アイスバーグ/フーディ)ACIDとタイムトラベル。
- 主要な源として'青銅/銀/金'、outbox/CDCを割って下さい。
- 「テナント/ブランド/リージョン」によるPII分離、トークン化、RLS。
- Bucket/directory-level residency、 key/secrets per region。
- スキーマ/ポリシー/アクセスルールの変更のWORM監査。
品質とSLA
- データ契約とsemverスキーム;互換性テスト。
- 透かしと再処理、増分MERGEショーケース。
- フレッシュネスダッシュボードとSLAアラート;各テーブルの所有者。
- ウォレット/決済/暗号による和解。
パフォーマンスとコスト
- パーティショニングとクラスタリング;「small file」コンパクション。
- 重要なレポートのための実体化されたショーケース。
- オートスケール/自動駐車、保持ポリシーおよびアーカイブ。
15)赤旗(アンチパターン)
BIと規制レポートはOLTPを直接ヒットさせました。
ブロンズは「書き換え」し、生のデータを失います。
透かしはなく、遅いイベントは「切り捨て」されます。
'idempotency_key'/'event_id'→Goldの重複除外はありません。
RLSとレジデンスなしで、異なる地域からのPIIとお金が一緒に保管されています。
スキームは(semver/contractsなしで)「静かに」変え、店の窓を壊します。
何百万もの小さな非圧縮Parquetファイル→高価な要求。
SLA/フレッシュネスダッシュボードはありません。四半期ごとの報告における「驚き」。
16)結論
iGamingのData Lake+DWHは、単なるストレージではなく、標準化されたスキームと契約、ACID-lakehouse、明確なSLAの鮮度と遅いウィンドウ、品質と直線性、PIIのセキュリティとレジデンスという制御されたエコシステムです。調整とパーティショニング/コンパクト化の節約を追加し、毎晩の移行や手動Excelなしでレポート、製品ソリューション、ビジネススケーリングの基盤を提供します。
