バッチ処理

1）目的と価値

• 規制および財務報告（GGR/NGR、税金、RG/AMLレジストリ）。
• BIおよび製品分析（コホート、LTV、コンバージョンファネル）。
• 精度検証（OLTP↔DWH、 プロバイダ/PSP）、履歴化（SCD）。
• MLのための機能とトレーニングセットの準備。

主な特性：予測可能性、完全性、再現性、データ単位あたりの低コスト。

2）アーキテクチャ（参考）

1.Ingest （raw capture）： HTTP/gRPC、 OLTPからのCDC、プロバイダのアップロード→ブロンズ。
2.レイクハウス：ブロンズ（生、追加のみ）→シルバー（クリーン/コンフォーム）→ゴールド（サーブ）。
3.オーケストレーション：Airflow/Dagster/Prefect （DAG 'and、 dependencies、 retrays、 SLA）。
4.処理：火花/Trino/DBT/SQLエンジン；パーティショニングとACIDフォーマット（デルタ/アイスバーグ/フーディ）。
5.DQと契約：スキーマレジストリ、DQルール （YAML/SQL）、コンシューマテスト。
6.サービング：BI/セマンティック層、レポート可能なエクスポート（CSV/PDF/JSON+ハッシュ）、API/GraphQL。
7.観測可能性：パイプライン指標、系統、ログ、コスト（コスト/GB、コスト/クエリ）。

3）周波数とSLA

毎日（D+1〜06：00ロック）：GGRレポート、規制アップロード、和解。
時間/準時間：Ops/Financeの運用パネル。
毎週/毎月：finconsolidation、モデルおよびretroprocesses。

• ゴールドデイリーショーケースは現地時間06：00まで準備ができています。
• 鮮度シルバーp95 ≤マイクロバット用15分/昼間≤ 2時間。
• 完全性≥ 99。5％、有効性（スキーム）≥ 99。9%.

4）インクリメンタルダウンロードとCDC

• CDC （Change Data Capture）： Debezium/log replication→Bronze→increments in Silver。
• 時間による透かし：'updated_at> max_loaded_ts'。
• ハッシュ比較：変更検出のための'md5 （row）'。
• Upsert/Merge： Idempotent Silver/Goldアップデート。

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

5） SCD（測定履歴）

SCD I：上書き（スペル、軽微な修正）。
SCD II：完全履歴（'valid_from/valid_to/is_current'）。
SCD III：簡単な比較のための「before/after」。

sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. country <> u. country OR t. rg_status <> u. rg_status)
THEN UPDATE SET t. is_current = FALSE, t. valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED
THEN INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

6） Backfill○Reprocessing

Backfill： Initial Fill/Historical Backfill。
再処理：ロジック/データを編集/修正した後、ショップウィンドウを再計算します。

• Idempotency （MERGE/upsert）、ブロンズ不変性、ロジックバージョニング。
• 繰り返し実行されるメタデータスナップショットのタイムトラベル。
• ガードレール：範囲、クォータ、競争力のある仕事を制限します。
• ドキュメント：ステップと完了基準を含むrunbook。

7）レイヤーモデリング

• 追加のみ、'event_date'、'管轄'、'テナント'パーティション。
• 元のペイロード（フォレンジック用）を保存し、ingested_atを修正します。

• 正規化と標準化：FK/ディレクトリ、 dedup、 FX/タイムゾーン。
• ファクト/寸法表（3NF/BCNF）、キー寸法のSCD。

• BI/規制/金融、 SLA対応の非正規化ストアフロント。
• 集計の具体化；不変エクスポートアーティファクト（hash+WORM）。

8）データ品質（DQ-as-code）

yaml table: silver. payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: unique_tx type: unique columns: [transaction_id]
severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

反応ポリシー：critical→fail job+DLQ；major/minor→tag+レポート。

9）セマンティックレイヤーとレポート

semantic-layer/metrics-storeのメトリック（GGR/NGR、 ARPPU、 Retention）の統一された定義。

バージョン管理メトリクス；BI/エクスポートパッケージとの統合

レポート：CSV/JSON/PDF+sha256、必要に応じてログと法的保持をダウンロードします。

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

PII最小化：ユーザーの仮名化；マッピング-別の保護ループで。
データ常駐：EEA/UK/BRのための別のディレクトリ/キー；法的根拠のない地域横断参加の禁止。
暗号化：TLS in-transit；KMS/CMK at-rest；エクスポートコントロール。
DSAR/RTBF：計算可能な投影、選択的編集；アクセスの監査。
法的保留：規制アーティファクトのためのWORMアーカイブ。

11）性能および費用

日付/市場/テナントによる分割；頻繁な述語によるZ順序/クラスタ。
フォーマット：寄木細工+ACIDテーブル；圧縮/統計、最適化/真空。
具現化：金の安定した集計；「モノリシック」ジョブを避けます。
クォータ/予算：チームによるチャージバック；backfillの限界/重い要求。
スケジュール：低負荷のウィンドウ（夜/週末）、キューの優先順位。

12）観測・管理

パイプラインメトリクス：期間、成功率、再試行、処理された行、コスト/クエリ。
DQメトリクス：完全性、妥当性、一意性、FKエラー、ドリフト。
新鮮さのヒートマップ：範囲および市場によって；SLAダッシュボード。
血統：レポートへの青銅の起源；変更の前の影響の分析。
アラート：SLO予算、DQの劣化、遅延、コスト増加。

13） SQL/モデルの例

sql
CREATE OR REPLACE TABLE silver. payments AS
SELECT p. transaction_id,
p. user_pseudo_id,
p. currency,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
p. market,
CAST(p. event_time AS TIMESTAMP) AS event_time
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time)
AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';

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;

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

14）プロセスとRACI

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

15）実装ロードマップ

1.レイクハウスブロンズ/シルバー（ACID形式）、CDC/2-3ドメインの増分。

2.DQ-like-code：支払い/ゲームプレイ+CI検証の10-15ルール。

3.最初のゴールドショーケース（GGRデイリー）SLA 06：00まで；レポートされたexport+hash。

4.鮮度/完全性/コストのダッシュボード、基本的なアラート。

• SCD IIは、ユーザー/ゲーム/プロバイダ；ドメイン拡張。
• メトリクスのセマンティック層；OLTP/プロバイダ（精度）でチェックします。
• バックフィル/再処理手順、系統および影響分析、地域化（EEA/UK）。

• 変更の自動シミュレーション（ドライラン）、予算/クォータ、チャージバック。
• 自動ドキュメント（データ製品ページ）、DR演習、タイムトラベルリカバリ。
• コスト最適化（クラスタリング、具現化、TTL、真空）。

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

• レジストリの契約とスキーマ、互換性テストは緑色です。
• Incremental downloads/CDC works、 MERGE idempotent。
• DQルールはアクティブです。critical→fail+DLQ；違反について報告してください。
• SLA/freshness/fullnessダッシュボード；アラートが設定されています。
• Legal/DPOによって確認されたPII/DSAR/RTBF/Legal Holdポリシー。
• Runbookとbackfill/reprocessing/DRテスト。
• 管理下のコスト（コスト/クエリ、コスト/GB、クォータ）。

17）反パターンおよび避ける方法

モノリシックなナイトジャブ：パーティーで並行して独立したステップに分割されます。
不必要にフルリロード：増分/CDC/マージを使用します。
analyticsでのPIIブレンド：マッピングを分離し、CLS/RLSを適用します。
No DQ/lineage： DQ-as-codeとtrace originを入力します。
「手動」バックフィル：自動化とドキュメント化、制限範囲。
管理不能なコスト：クラスタリング、マテリアライゼーション、保持ポリシー。

18）用語集（短い）

CDC-OLTPから変更をキャプチャします。
SCD-ゆっくりと変化する測定（I/II/III）。
Lakehouse-データレイク+ACIDテーブル。
MERGE/Upsert-idempotent更新操作。
タイムトラベル-テーブルの歴史的なバージョンを読む。
WORM-アーティファクトの不変の保存。

19）ボトムライン

バッチ処理は、予測可能、再現可能、および無料のパイプラインの規律です。スキーマファースト、増分/CDC、 SCD履歴、DQ-as-code、 observability、 conscious economicsの原則に従うことで、安定したGoldショーケースとレポートを受け取ることができます。