ETL/ELTプロセス

1）目的とコンテキスト

ETL/ELTパイプラインは、報告用データ（GGR/NGR、レギュレータ）、分析/ML、および運用パネルの予測可能な読み込み、変換、公開を提供します。

ETL： DWH/Lakehouseにロードする前に変換します（現代のスタックではあまり頻繁にありません）。
ELT：最初にLakehouse（ブロンズ/シルバー）にロードし、SQL/エンジンを変換します（推奨）。

2）リファレンスアーキテクチャ

1.Ingest/Edge： HTTP/gRPC/Batch、 OLTPからのCDC、プロバイダのアップロードS3/FTP。
2.ブロンズ（生、追加のみ）：不変ペイロード、日付/市場/テナントによるパーティー。
3.シルバー（クリーン/コンフォーム）：正規化、dedup、ディレクトリ、SCD、 FX/タイムゾーン。
4.ゴールド（サーブ）：BI/レギュレータ/モデルの非正規化ストアフロント。
5.オーケストレーション：Airflow/Dagster/Prefect （DAG 'i、 SLA、 Retrai、 Shifts）。
6.DQ/Contracts： Schema Registry+DQ-DQ-DQ-DR-DR、消費者主導のテスト。
7.観測可能性：パイプラインのメトリック、リネージ、ログ、コストダッシュボード。

3） ETLとELTの選択

［基準］	ETL	ELT（推奨）
配分の柔軟性	低	高い（タイムトラベル、再処理）
コスト（Cost）	成長するとより高価になります	スケーリング時に最適
品質管理	on ingest	シルバー/ゴールド+DQ-as-code
歴史性/法医学	限定された	full（ブロンズアペンドのみ）

練習：iGamingで-ELT+CDC：すばやくロードし、次に標準化してカウントします。

4）増分およびCDC

デルタのアプローチ：

CDC （Debezium/log replication）： OLTPの変更→ブロンズ→シルバーのMERGE。
時間による透かし：'updated_at> max_loaded_ts'。
Hash diff： 'md5 （row）'変更検出の比較。
Upsert/MERGE：ダウンロードのidempotency。

MERGE（デルタ/アイスバーグ）の例：

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）契約とスキーム

スキーマファースト： レジストリ内のJSON/Avro/Protobuf；イベント/ファイルの'schema_version'

進化：バックコンパチブル（nullable追加）；breaking-'/v2'+ダブルエントリ。
必須フィールドは'event_time （UTC）'、 'event_id'、 'trace_id'、 'user_pseudo_id'、 'market'です。

6） DQとしてコード（最低セット）

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

7）オーケストレーション： DAG 'and、依存関係、SLA

DAGデザイン：ソースから店舗まで。タスク間の明示的な依存関係。
Retraiとidempotence：バックオフ、「クリーン」リプレイ、チェックポイント。
キャッチアップ：見逃した期間のきちんとしたキャッチ。
SLA：ゴールドなど。毎日06：00現地時間の前に準備ができています。違反の警告。
変数化：varsによる市場/テナント/日付；単一のジョブテンプレート。

8） Idempotenceおよび丁度一度

In ingest： duplicates are possible→dedup by '（event_id、 source）'。
処理中：upsert/merge；「純粋な」変換関数。
In sink：トランザクションコミットまたはidempotent書き込み；「ダブルカウント」の制御。
Outbox/Inbox： OLTPからのドメインイベントのトランザクション発行。

9）再処理のバックフィル

バックフィル：プライマリフィル/履歴範囲。
再処理-ロジックの変更/修正時の再計算。
ガードレール：範囲制限、クォータ、時間ウィンドウ、メートル法の比較によるドライラン。
マーク：'logic_version'、 'reprocessed_at'、 'recalc_reason'。

10）シルバー/ゴールドモデリング

シルバー（3NF/BCNF）：ファクト'facts_bets/payouts'、ディメンション'dim_users/games/providers/markets （SCD II）'、通貨標準化/タイムゾーン。
ゴールド：BI/レギュレータ/モデルの非正規化ストアフロント。immutableエクスポートパッケージ（WORM）+署名。

ゴールド例： GGRデイリー

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;

11）プライバシーと居住

PII最小化：トークン化；分離ループ内の実際のIDのマッピング。
RLS/CLS：役割/管轄によるアクセスポリシー、マスキング。
居住：EEA/UK/BRのための別のディレクトリ/キー；理由なくクロスリージョナルジョインを禁止します。
DSAR/RTBF&Legal Hold：選択的編集、レポート用のWORMアーカイブ、エクスポート監査。

12）観察可能性およびSLO

SLI/SLOベンチマーク：

鮮度シルバーp95 ≤ 15分；金は毎日06：00ロックまで準備ができています。時間だよ。
完全性≥ 99。5％、有効性（スキーム）≥ 99。9%.
仕事の成功≥ 99。0％、 MTTRインシデント≤ 24-48時間。

ダッシュボード：フレッシュネスヒートマップ、DQロスファネル、コスト/クエリ&コスト/GB、リネージグラフ。

13）性能および費用

仕切り：日付/市場/テナント；フィルタによるクラスタリング/Z順序。
フォーマット：Parquet+ACID（デルタ/氷山/フーディ）、圧縮と統計。
圧縮：小さなファイル（OPTIMIZE/VACUUM）との戦い。
具現化：安定した集計；巨大なオンザフライの結合を避けます。
チャージバック：予算、リプレイクォータ/バックフィル；低い負荷窓のスケジューリング。

14）典型的なDAGタスクの例（Airflow擬似コード）

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15）プロセスとRACI

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

16）実装ロードマップ

MVP （3-5週）：

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

2.DQ-like-code （10-15ルール）と基本的なFreshness/Completenessダッシュボード。

3.最初のゴールドショーケース（GGR Daily）とSLA 「06：00まで」、WORMは署名と輸出します。

4.SLA/DQでのDAGとアラートオーケストレーション。

フェーズ2（5-10週間）：

ドメイン拡張、ユーザー/ゲーム/プロバイダのためのSCD II。
メトリクスのセマンティック層；血統/影響分析；backfill/reprocessingプロシージャ。
地域化（EEA/UK）、 RLS/CLS、コスト管理（クォータ/チャージバック）。

フェーズ3（10-16週間）：

リプレイシミュレータ（what-if）、ショーケース/メトリクスのドキュメントの自動生成。
コスト最適化（クラスタリング、実体化、TTL、圧縮）。
DR演習とタイムトラベルの回復。

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

レジストリ内の契約/スキーマ、互換性テスト緑。
CDC/incrementsとMERGEはidempotent；摂取するためにdedup。
DQルールがアクティブ（critical→fail+DLQ）、 SLAダッシュボードが設定されています。
ゴールドショーケースは文書化されており、セマンティックレイヤーのメトリック式。
RBAC/ABAC、暗号化、レジデンシー、DSAR/RTBF/Legal Hold検証済み。
スケジュールで圧縮/最適化/真空；backfill/replayの限界。
Runbookとインシデントと再処理、監査エクスポート（WORM+ハッシュ）。

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

フル・リロード「just in case」： CDC/incrementsを使用します。
未加工および報告されたデータの混合：青銅/銀/金を別に保って下さい。
DQと血統の欠如：証明性と再現性はありません。
分析レイヤーのPII：マッピングを分離し、CLS/RLSを適用します。
モノリシックな「夜」ジャブ：クラッシュ、バッチで平行。
コストを無視：小さなファイルを監視し、集計を実現し、クォータを導入します。

19）用語集（短い）

ETL/ELT-抽出/変換/ロード（ロード前/ロード後）。
CDC-変更をキャプチャします。
SCD-測定履歴（I/II/III）。
WORM-レポートパッケージの変更不可のストレージ。
タイムトラベル-テーブルの歴史的なバージョンを読む。

20）ボトムライン

現代のETL/ELTはスクリプトではなく、管理されたプラットフォームです：契約とDQ、 idempotent increments/CDC、 Bronze/Silver/Gold層の規律、観測性とSLO、プライバシーと経済。このガイドに従うことで、レポート、製品、モデルに驚くことなく一貫して電力を供給する再現性と監査可能なパイプラインが得られます。

ETL/ELTプロセス

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です