データウェアハウス

1） iGamingにおけるDWHの目的と役割

• 一般的なメートル定義（GGR/NGR、 ARPPU、 Retention、 Churn）。
• 規制当局や社内ステークホルダーのための再現可能なレポート。
• BI/操作パネルとモデルのソースのための高速ストアフロント。
• プラットフォームレベルの品質管理、血統、安全性。

2）建築の選択

2.1クラシックDWH

ETL→DWH→BI。
長所：管理可能なモデル、強力な一貫性。
短所：高価なダウンロード、複雑なバックフィル、限られた柔軟性。

2.2レイクハウスDWH

ACIDテーブル上のブロンズ/シルバー/ゴールド（デルタ/アイスバーグ/フーディ）+SQL/MPPエンジン。
長所：統一されたストレージ、タイムトラベル、簡単な再処理。
短所：レイヤーとDQ、成熟したオーケストレーションの規律が必要です。

2.3ハイブリッド

レイクハウスは「真実の源」（ブロンズ/シルバー）として、高速読み取りのためのMPP （ClickHouse/Pinot/Druid/Cloud DWH）でDWH-March。
長所：コストとパフォーマンスのバランス、柔軟なストアフロント。
短所：回路とスケートのデュアルサポート、同期が必要です。

推薦：iGaming-Lakehouse+DWH-March（ハイブリッド）。ブロンズ/シルバー-標準化、ゴールド/リアルタイムマート-読み取り負荷を提供します。

3）データモデリング

3.1星と雪片

ファクトテーブル：narrow、 event-driven： 'fact_bets'、' fact_payouts'、 'fact_payouts'。
寸法：'dim_users' （SCD）、 'dim_games'、 'dim_providers'、 'dim_markets'。
スノーフレークはシルバー（正規化）、スター-ゴールド（読書）で適切です。

3.2 Data Vault 2。0（統合コア）

ハブ（ビジネスキー）、リンク（関係）、衛星（コンテキスト/履歴）。
シルバーで長寿命のプロバイダ/PSP統合に適用します。

3.3 SCD I/II/III

RG/KYC/チャンネルおよびゲーム属性（RTP/ボラティリティ）用のSCD II。
厳密な間隔'valid_from/valid_to'、正しい結合時間。

4）負荷： ETL/ELT、 CDCおよび増分

ELTアプローチ：loading in Silver→transformation in DWH。
CDC： OLTPからのDebezium/logのレプリケーション；メルジは馬鹿だ。
増分：time water （'updated_at> max_loaded_ts'）および/またはhash deltaによって。
バックフィル/再処理：タイムトラベル、範囲、クォータ、ドライラン比較。

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5）セマンティックレイヤーとメトリック

Metrics Store/Semantic Layer： uniform formumulas GGR/NGR/Conversion/LTV。
再現性のためのメトリクスと「as-of」計算のバージョニング。
規約は、メトリック名、単位、通貨（基本EUR）、および'fx_source'です。

6）店頭およびサービング

ゴールドショーケース： 非正規化、SLA対応（例えば、06：00ロックまで）.

Operational Marts： ClickHouse/Pinot/Druidを1〜5分間使用します。
エクスポート：CSV/JSON/PDF+ハッシュ；レギュレータのための不変パケット（WORM）。

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

7）データ品質（DQ）と契約

スキーマファースト：JSON/Avroレジストリ+互換性テスト（消費者主導）。
DQ-MM：完全性/妥当性/一意性/FK/範囲/時間。
反応ポリシー：critical→fail+DLQ；major/minor→タグとレポート。
DQの観測可能性：鮮度/完全性/有効性ダッシュボード、失われたレコード漏斗。

8）セキュリティ、プライバシー、居住

PII最小化：疑似IDを介したユーザー；別にマッピングします。
RLS/CLS：役割と管轄によるライン・バイ・ライン/ポスト・テーブル・アクセス。
暗号化：TLS in-transit；at-rest-回転付きKMS/CMK。
データ常駐：EEA/UK/BRのための別のディレクトリそしてキー；理由なくクロスリージョナルジョインを禁止します。
DSAR/RTBF：計算可能な投影と選択的編集；アーティファクトの報告に関する法的保持。

9）パフォーマンスとコスト（コストエンジニアリング）

仕切り：日付/市場/テナントによって；'market'、 'provider_id'、 'game_id'、 'user_pseudo_id'によるクラスタリング/Z注文。
フォーマット：寄木細工+統計と圧縮；予定どおりに最適化/真空。
具体化：安定した集計とサマリテーブル；「脂肪」が飛び交うのを避けます。
クォータ/チャージバック：重いリクエスト/リプレイの予算；コスト/クエリ、コスト/GBをレポートします。
階層型ストレージ：ホット/ウォーム/コールド；明確な回復SLA。

10）観察と管理

パイプラインメトリクス：持続時間、ボリューム、リトレイ、ラグ、フォールトトレランス。
DWHメトリクス：応答時間/競争力/キャッシュのヒット数/値。
血統：ソースからレポートへのグラフ；変化に対する影響分析。

SLO： Freshness Silver p95 ≤ 15；毎日ゴールド-06：00まで準備ができています。有効期限≥ 99です。9%;完全性≥ 99。5%;99 ≥可用性。9%.

11）複数のテナントおよび範囲の分離

スキーマ/データベース/カタログによるテナント/マーケットへの分割。
クォータとリソースグループ；「騒々しい隣人」を制限します。
テナント間の輸出入ポリシー、標準契約。

12）データレジスタとドキュメント

データカタログ：所有者、SLA、スキーマ、例、DQルール、系統。
メトリック/ダッシュボード：数式と責任を持つカード。
変更ログ：ロジック、マイグレーション、インパクトのバージョン。

13）プロセスとRACI

R（責任ある）：データエンジニアリング（モデルSilver/Gold、 DAG 'i）、データプラットフォーム（infra、レジストリ、DQ）。
A（説明責任）：データ/CDOの責任者。
C（コンサルティング）：コンプライアンス/リーガル/DPO、ファイナンス（FX/GGR）、リスク（RG/AML）、 SRE （SLO/стоимость）。
I（インフォームド）：BI、製品、マーケティング、オペレーション。

14）実装ロードマップ

1.レイクハウスブロンズ/シルバー（ACIDテーブル）、CDC/支払い/ゲームプレイの増分。

2.最初のゴールドショーケース（GGRデイリー、コンバージョン）、SLA 06：00まで。

3.DQ-like-code （10-15ルール）+Freshness/Completenessダッシュボード。

4.データカタログと基準メトリクスの基本セマンティック層。

• SCD IIは、ユーザー/ゲーム/プロバイダ；ドメイン拡張。
• オンライン行進（ClickHouse/Pinot）リアルタイム/ニアリアルタイムパネル用。
• 系統/影響分析、DSAR/RTBF手順、地域化（EEA/UK）。

• 変更の自動シミュレーション（ドライラン）、リプレイ、メトリックの比較。
• チャージバック/クォータ、コストダッシュボード;DR演習とタイムトラベルの回復。
• ショーケースのドキュメントとメトリックカードの自動生成。

15） SQLテンプレートの例

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16）売り上げ前のチェックリスト

• レジストリ内のスキームと契約、互換性テストは緑色です。
• CDC/incrementsおよびMERGEプロシージャはidempotentです。
• ゴールドショーケースにはSLAがあり、メトリック式は固定されています。
• DQルールはアクティブ（critical→fail+DLQ）、 Freshness/Completenessダッシュボードです。
• RBAC/ABAC、暗号化、地域別レジデンシー、アクセスログ。
• 血統/影響が有効になっています。タイムトラベル/バックアップ/DRチェック。
• 管理下のコスト：当事者、クラスタリング、具体化、クォータ。

17）アンチパターンとリスク

「レイヤーのない1つの脂肪DWH」：生と報告されたデータの混合→カオスと高価な修正。
不必要に毎日フル再ロード：増分/CDCを使用します。
所有者と数式のない金：真実の単一のバージョンの欠如→紛争と回帰。
分析レイヤーのPII：マッピングを分離したまま、CLS/RLS。
DQ/lineageなし：規制当局/監査の証拠はありません。
管理不能なコスト：バッチ/最適化/クォータなし。

18）用語集（短い）

DWHは統合と分析のためのデータウェアハウスです。
Lakehouse-データレイク+ACIDテーブルとSQLエンジン。
CDC-OLTPから変更をキャプチャします。
SCD-ゆっくりと変化する測定（I/II/III）。
ゴールドショーケース-すぐに使用できるレポートシート/プレゼンテーション。
セマンティックレイヤー-メトリックと属性の統一的な定義。

19）ボトムライン

iGamingの現代のDWHは「大きなテーブル」ではなく、管理可能なプラットフォームです。ブロンズ/シルバー/ゴールド層、厳格な契約とDQ、均一な指標と血統、プライバシーと居住性、パフォーマンスと効率。Lakehouse+DWH-Marchハイブリッドを構築することで、監査、規模、新しい市場に向けた迅速かつ検証可能な意思決定が可能になります。