Data Lakeと集中型ストレージ

（セクション： 技術とインフラ）

概要

Data Lakeは、原材料と統合データセットの一元化されたストレージの基本層です。iGamingでは、賭け/支払い/ゲームログイベント、アフィリエイトアップロード、OLTPからのCDCを受け入れ、分析、不正防止、CRM、 BIに提供します。現代の実践-Lakehouse：開いた列のフォーマット+ACIDテーブル層+単一のディレクトリ+トランザクション/データバージョン。成功の鍵は、スキームと分割、コスト管理、PIIセキュリティ、および厳格な運用文化（DQ、 lineage、 DR）の規律です。

iGamingプラットフォームにおけるデータレイクの役割

分析のための1つの真実のポイント：ソースとフォーマットに関係なく、生のデータと精製されたデータを保存します。
柔軟性：バッチとストリーミング（CDC/コネクタ、イベントストリーム）のサポート。
進化：生のブロンズからコンフォーマルシルバーとゴールドのビジネスケースまで。
責任分担：生産サービスはタイヤ/ステージングに書き込み、分析/MLはレイク層から消費します。

建築モデル： レイクvsレイクハウス

Data Lake （S3/ADLS/GCS+Parquet/ORC）：スキーマオン読み取り、安価なストレージ、柔軟なフォーマット。
Lakehouse （Delta/Iceberg/Hudi over Parquet）： ACIDトランザクション、アップサート/マージ、タイムトラベル、コンパクトファイル、真空、インデックス作成/クラスタリング。
練習：LakehouseはメインレイヤーとしてiGamingにとって有益であり、ショーケースや特別なエンジンとして外部OLAP （ClickHouse/BigQuery/Snowflake/Pinot）があります。

メダリオン層モデル

ブロンズ（Raw/ステージング）：ソースからの生ファイル（CDC、ログダンプ、アフィリエイトCSV、 webhooks）。最小限の検証、「そのまま」。
シルバー（適合）：クリーニング/デッドアップ、通貨/タイムゾーンの正規化、タイピング、SCD測定、一貫したキー。
Gold （Marts/サービング）： GGR/NGR/LTV/Retentionの集計、BI/CRM/不正防止のための実体化されたストアフロント。
TTL：ブロンズに積極的、シルバーに中程度、ゴールドユニットに長期的。

フォーマットとテーブルレイヤー

コラム：寄木細工（デファクトスタンダード）、ORC。

オープンテーブルフォーマット（ACID）：

デルタレイク-トランザクション、'MERGE'、タイムトラベル、最適化/真空、Z注文。
Apache Iceberg-マニフェスト/スナップショット、隠しパーティショニング、'MERGE/DELETE/UPDATE'、タイムトラベルを持つテーブル。
Apache Hudi-copy-on-write/merge-on-read、 upsert-optimization、 incremental extractions。
スキームの進化のアップサート/ストリーミング/柔軟性のためのエコシステムと要件に基づいて選択してください。

カタログ・メタスター

単一のディレクトリ（Hive Metastore/Unity/Glue/platformディレクトリ）には、スキーマ、パーティー、バージョン、権利が格納されます。
要件：テーブル層とのトランザクション整合性、複数のエンジン（Spark、 Trino/Presto、 Flink、 dbt）のサポート、監査/系統。

スキームと進化

スキーマ契約： 必須フィールド、タイプ、セマンティクスを修正します。バージョン管理ソース（'schema_version'）

進化：オプションのフィールドを追加し、移行なしで変更を破ることを禁止します。パイプラインの自動チェックスキーム。
PIIセグメンテーション：機密フィールド-暗号化と個別の権利を持つ個別の列/テーブルに。

データの分割とレイアウト

日付/時間-イベントの基本キー。オプションのフィールド：'country'、 'product'、' tenant_id'。

ハイブスタイルのпуть： 's3 ：//lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001。「寄木細工」

クラスタリング/ソート：Z順序/頻繁にフィルタリングされたフィールド（player_id、国）でキーを並べ替えます。
ファイルサイズ：128-1024 MBを目指します。「小さなファイル」は避けてください（下記参照）。
隠しパーティショニングのための仮想カラム（氷山/デルタ）。

小さなファイルと圧縮の問題

ソースは、小さなチャンク→スキャンとメタデータの劣化をストリーミングします。
ソリューション：定期的な最適化/圧縮（合体）、圧縮タスクスケジューラ、摂取時のバッチマイクロバンドル、'AutoOptimize'（利用可能な場合）。
merge-on-readとcopy-on-writeポリシーは、書き込みレイテンシと読み取り速度のバランスです。

Injest： バッチ、ストリーム、CDC

OLTP（デベジウム/コネクター）からのCDC→青銅（分の新鮮さ）。

ストリーム（Kafka/Flink/Spark Structured Streaming）→シルバー/ゴールド（upsert/merge）

バッチ（パートナーレポート/CSV/JSON）-マニフェスト付きの「受信機」を通じて、チェックサムによる重複の制御。
Idempotency：キー（idempotency_key)、 dedup by （key、 ts）、後でレコードに到着するための「透かし」。

データ品質（DQ）と系統

DQチェック：完全性、キーの一意性、範囲、参照整合性（国/通貨リスト）、ビジネスルール（GGR ≥ 0）。
Liniage：レポートからソースへの依存関係のグラフ、モデルコードのバージョン、およびテーブルのスナップショット。
スキーマコントロール：「破断」の変更をブロックする自動バックコンパットテスト。
監査ダウンロード：who/when/how many、 rejected batches、 retrays。

サービングとアクセス

SQLエンジン：アドホックと変換のためのSpark/Trino/Presto；ELTモデルのdbt。
リアルタイム/ニアリアルタイム：店舗としてのピノ/Druid/ClickHouse；レイクハウスはインクリメンタルシンクを介してソースです。
データ共有：コピーなしで外部コマンドにテーブル/スナップショットを共有します（フォーマットでサポートされている場合）。

セキュリティ、PII、マルチテナンシー

暗号化：at-rest （KMS）およびin-transit （TLS）。
IAM/RBAC/ABAC：ディレクトリ/テーブル/列/行レベルの役割（マスキング、動的ポリシー）。
地域別のセグメンテーション（EU/トルコ/LatAmローカリゼーション）：バケットと計算プールの分離。
マルチテナンシー：名前空間/ディレクトリとパス接頭辞、'tenant_id'によるフィルタ、オプション-行レベルポリシー。
アクセス監査：メタデータの読み取り/変更ログ、保持ログ、変更不可ログ。

コスト管理

ストレージクラス：標準クラスでホット（しばしば読み取り可能）、アーカイブ-コールド/グレイシャークラスでTTLポリシー。
パーティショニング/クラスタは、スキャンを削減します→$$未満。
高価なレポートのための実用化されたストアフロント；BI結果キャッシュ。
圧縮と「正しいファイルサイズ」-メタデータとI/Oが少なくなります。
クォータと予算：計算クラスタ/ジョブの制限、データセット/チームのコストレポート。
ごみの除去：テーブルフォーマットの「真空/書き換え」、TTLブロンズ。

DRと再現性

タイムトラベルテーブルバージョニングとカタログスナップショット。
Bucketとメタデータの領域横断レプリケーション。
PITR：テーブルのトランザクションログ（Delta/Iceberg/Hudi）とパイプラインログの保存。
ゲーム日：定期的な回復演習と地域の切り替え。

観測可能性とSLO

SLO鮮度：ブロンズ≤ 5分、シルバー≤ 15-30分、ゴールド≤ 60分（例）。
メトリクス：ファイルのボリューム/数、パーケットファイルの平均サイズ、スキャン時間、欠落バッチの共有、圧縮頻度、コスト/日付、DQエラー、遅延データ。
アラート：小さなファイルのサージ、コスト増加、p95/p99の劣化、DQ/スキーム違反、ストリームブルーラグ。

命名規則とパスウェイ（テンプレート）


s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/      # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/

データセット名：'bets_raw'、 'payments_cdc'、 'players_silver'、 'mart_ggr_daily'。
メタデータ列：'ingest_ts'、 'source'、 'schema_version'、 'trace_id'、 'tenant_id'。

例（一般化）

1）氷山： 日付によって隠された党が付いている銀製のテーブル

sql
CREATE TABLE silver. bets (
bet_id    BIGINT,
player_id   BIGINT,
country    STRING,
stake     DECIMAL(18,2),
win      DECIMAL(18,2),
event_ts   TIMESTAMP,
ingest_ts   TIMESTAMP,
schema_version INT
)
PARTITIONED BY (days(event_ts))
TBLPROPERTIES ('format-version'='2');

2）デルタ： CDCからの増分アップサート

sql
MERGE INTO silver. players t
USING bronze. players_cdc s
ON t. player_id = s. player_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

3）青銅のためのTTLの方針（考え）


bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)

実装チェックリスト

1.テーブル形式（Delta/Iceberg/Hudi）とディレクトリを選択します。エンジン（Spark/Trino/Flink/dbt）と整列します。
2.メダリオンレイヤー、TTLルール、チームの責任を定義します。
3.スキーマコントラクト、進化制御、PIIセグメンテーション、暗号化をキャプチャします。
4.設計レイアウト：部品、ソートキー、ターゲットファイルサイズ；コンパクト化を有効にします。
5.ingest （CDC/stream/batch）をidempotencyとdeduplicationで構成します。
6.DQ/lineage、メタデータカタログ、監査を有効にします。
7.新鮮さ/コストのSLO、メトリクスとアラートのダッシュボードを定義します。
8.DRの整理：スナップショット/レプリケーション/リカバリ+通常のエクササイズ。
9.名前とパス、メタ列（'ingest_ts'、 'source'、 'schema_version'）を標準化します。
10.適切なOLAP/RTエンジンにゴールドのショーケースとリアルタイムのサービスを提供します。

アンチパターン

レイヤーとTTL→カオスとコストの爆発のない1つの一般的な「バッグ」。
国または製品を除く時間のみのパーティショニング→重いスキャン。
圧縮せずに数千の小さなファイル/時間を作成するスレッド。
スキームとDQの制御の欠如→「破る」変更とレポートの不信。
PIIとゴールドのショーケースをマスキング/権利分離なしで混合します。
ディレクトリおよび表形式ポリシーの代わりに、Bucketレベルのアクセス権のハードコード。

概要

Modern Data Lake for iGamingは、オープンテーブルフォーマット、単一のカタログ、メダリオンモデルを備えたLakehouseです。スキーム/パーティーの規律、小さなファイルに対する圧縮、DQ/lineage、 PIIセキュリティとコスト衛生は、湖の層を持続可能な基盤に変えます。