データスキーマとその進化

1）これがiGamingプラットフォームである理由

信頼性-データの変更により、レポート、API、モデルが破損することはありません。
機能速度：ストリームを停止することなく安全にフィールド（KYC/RG/PSP）を追加します。
規制：トレーサビリティと再現性（監査/系統、DSAR、リーガルホールド）。
コスト：「オーバーフロー」とバックフィルのダウンタイムを最小限に抑えます。

2）スキームの種類と彼らが住んでいる場所

イベント（ストリーム）：'支払い。deposit_accepted'、ゲーム。 。 。
OLTP/DDL：正規化テーブル（KYC、アカウント、制限）。
DWH/storefronts （Gold）： BI/MLの下で非正規化された集計。
特徴の店：一貫性の保証のオンライン/オフラインの特徴セット。
外部パートナー契約：PSP、ゲームプロバイダー、マーケティングソース。

表記：Avro/Protobuf（ストリーム）、JSONスキーマ（インテグレーション）、SQL DDL （DWH）、 Parquetスキーマ（レイク）。

3）互換性（進化の中核）

後方互換性：新しい生産者→古い消費者（field c default/nullableを追加）。
前方互換性：古い生産者→新しい消費者（新しい読者は不要な無視します）。
完全互換性：両方（イベントのための望ましいターゲット）。
Breaking-changes：フィールドの名前変更/削除、type/semanticsの変更、/partitioningキーの変更。

ルール1：イベントは変化によってではなく、追加によって進化します。
ルール2：削除-廃止期間後のスキームのMAJORバージョンでのみ。

4）セマンティックバージョンとポリシー

'MAJOR。マイナー。各スキーム/ショーケース/フィーチャーセットのPATCH'。

MAJOR-互換性がありません（新しいトピック/テーブル/フィーチャーセット、デュアルラン）。
MINOR-互換性があります（新しいnullable/defaultフィールド、新しい列挙値）。
PATCH-説明/制限/コメントを編集します。

フィールドライフサイクル：'experimental→active→deprecated→removed'（日付と所有者）。

5）スキーム登録とデータ契約

スキーマレジストリ：バージョン、互換性、進化、所有者を格納します。
データ契約：スキーム+SLO品質+プライバシーを修正します（「データ検証」セクションを参照してください）。

例（Avro、支払い。deposit_accepted v1です。7.0):

json
{
"type":"record","name":"deposit_accepted","namespace":"payments",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"user_id","type":"string"},
{"name":"brand","type":"string"},
{"name":"country","type":"string"},
{"name":"psp","type":"string"},
{"name":"method","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":{"type":"enum","name":"Currency","symbols":["EUR","USD","TRY","BRL"]}},
{"name":"risk_score","type":["null","int"],"default":null},       // MINOR+
{"name":"kyc_level","type":["null",{"type":"enum","name":"Kyc","symbols":["L0","L1","L2","L3"]}],"default":null}
],
"compatibility":"FULL","owner":"team-payments"
}

6）移行パターン

6.1イベント（ストリーム）

Additive-only： デフォルト/nullableのフィールドを追加します。古い消費者は壊れない。
Enum拡張機能：新しい文字はMINORと見なされ、消費者は'else/unknown'ブランチを持つ必要があります。
MAJOR移行：新しいトピックの支払い。 。 。v2'、デュアル書き込み、シャドウ読み取り、消費者の切り替え。

6.2 DWH/ストアフロント

青緑のテーブル：'ゴールド。'v1'の隣にあるrevenue_v2'；実体化、検証、BIの切り替え。
Backfill：スナップショットによる再生+idempotentマージ（キー/バージョン別）。
SCD：属性をゆっくり変更するタイプ2（制限、KYC、 VIPステータス）。

6.3 Featureストア

デュアルサーブ：古いフィーチャーセットは新しいフィーチャーセットと平行に提供されます。モデルはルータを介してサービスされます。
ポイント・イン・タイムの一貫性：進化はPITAの喜びを壊すべきではありません（タイムスタンプ/粒度はMINORで変更されません）。

7）変更の分類（チェックリスト）

• 'nullable/default'フィールドの追加；
• enum extension（消費者で'unknown'ブランチを持つ）；
• 非キーインデックス/コメント/説明を追加します。

• スケール/単位の変更（例：セントの金額→基本通貨）-MAJORのみ
• reference/reference transfer-プレゼンテーションレイヤーを介して。

• フィールドの名前変更/削除
• タイプ/フォーマット/キー/パーティションを変更する
• セマンティクスの変更（例：「accrued」→「writing off」からの'bonus_amount'）。

8）回路リンターと互換性テスト

Schema-lint： name style （'snake_case'）、 required labels （'owner'、 'doc'、' pii'）、date/currency format。
Compat-tests：新しいバージョンをレジストリ（後方/前方/完全）に対してチェックします。
消費者契約テスト：各サービスは「サンプルペイロード」と期待を提供します。スキームを変更するときにCIで実行します。
Golden-datasets：実例と「悪」の集合（新しい列挙、空/後期フィールド、和の境界値）。

9）ディレクトリ、列挙、ローカライズ

参考データ（国/通貨/PSP/プロバイダ）：個々のバージョンとSLAの更新；イベントコードを縫わないでください。
ロケール/タイムゾーン：プレゼンテーションのイベント+明示的ロケールにUTCを保存します。
管轄のルール：年齢のフラグ、プロモーションの制限-アクションの日付を持つディレクトリの形で。

10）複数のブランド/複数の管轄およびPII

テナント分離：'ブランド'、'国'、'ライセンス'-必須フィールドとenum；それらをルーティングします。
スキーマレベルのPIIポリシー：フィールド'pii=true'をマークし、マスク/トークン化を適用します。イベントではトークンのみ。
DSAR： 'source_id/trace_id'の存在/削除/検索；MAJOR移行の法的保持。

11） DDLおよび湖のバージョン管理

DDLマイグレーション：宣言的マイグレーション（Liquibase/Flyway/dbt）、 VCSでのストレージ、ドメイン所有者によるレビュー。
湖のフォーマット：Avro/Parquet-フィールドの進化を記録します。MAJOR-新しいテーブル/パス'……/v2/'。
パーティショニング：部品の変更（例：'date'→'date、 brand'）-MAJORとダブルエントリのみ。

12） iGamingの例

12.1 PSP拡張メソッド

enumに'method=「MEFETE」を追加しました。
'deposit_accepted v1のMINORリリース。8.0`;MEFETEを知らない消費者は"unknown_method'にブランチを送ります。

12.2ゲームプロバイダーがピッチを追加

V 'game。round_finished' 'jackpot_id' （nullable）を追加しました。
ショーケースのゴールド。game_rounds_v3'はマイナーを受け取ります。古いレポートの仕事、新しいものは大当たりを数えます。

12.3つのRG属性

Boolean 'self_excluded'からstatus 'rg_state ∈ {none、 limit、 cooldown、 self_excluded}'-MAJOR、新しいトピック+ショーケースとモデルの二重書き込み+移行。

13）進化プロセス（アイデアからスイッチまで）

1.提案（ADR）：変更の理由、互換性の種類、リスクアセスメントおよび影響を受ける消費者。
2.設計と契約：登録、semver、互換性ポリシーのスキーム。
3.テスト：linters、 compat、消費者契約、ゴールデンセットでのリプレイ。
4.展開：デュアルライト/ブルーグリーン/シャドウ読み取り；警告します。
5.調整：ビジネスバランス/不変量（データ検証を参照）。
6.スイッチ：消費者/BI/機能を切り替えます。
7.廃止：古いスキーマ、猶予期間、削除、アーカイブをフリーズします。

14）進化の指標とSLO

移行の成功率、デュアルランタイム、新しいフォーマットイベントの共有、バックフィルボリューム、遅延/鮮度。
互換性インシデント（P1/P2）、切り替え後のウィンドウ品質。
コスト：$/TBオーバーフロー、$/時間デュアルライト、クラスタ負荷。
コンプライアンス：0 PIIリーク、SLA DSAR/Legal Hold meet。

15）ツールとアーティファクト

15.1互換性ポリシー（レジストリ）

yaml schema: payments. deposit_accepted compatibility: FULL default_nulls: true enums:
currency: {allow_new_symbols: true, require_consumer_unknown_branch: true}
pii: false owners: ["team-payments"]
reviewers: ["data-governance","security-dpo"]

15.2移行パスポート（テンプレート）

yaml change_id: MIG-2025-041 scope: game. round_finished -> v3 type: MAJOR plan:
dual_write: true shadow_reads: consumers: ["gold-rounds","rg-models"]
backfill: {from: "2025-01-01", mode: "idempotent-merge"}
validation:
invariants: ["sum_bets = sum_wins + margin + bonuses"]
freshness_delta_p95_max: "PT5M"
switch_criteria:
error_rate_max: 0. 1%
kpi_diff_pp_max: 0. 5 deprecate_after: "2025-12-31"

15.3名前と種類のリンク（ルール）

'sake_case'、 UTCタイムスタンプ、DECIMAL （18。2）和のために、alpha-2 ISO-3166-1のための'国'、ISO-4217のための'通貨'。
列挙フィールドの'free_text'はありません。参考図書-外部。

16）実装ロードマップ

0-30日（MVP）

1.主要イベント（支払い、game_rounds、ユーザー）のスキーマレジストリ+互換性ポリシーを有効にします。
2.CIのLinters/compatテスト；オーナーディレクトリとSLAレビュー。
3.ADRテンプレートと移行パスポート；MAJORチェックリスト。

30-90日

1.金の店頭のための青緑；重要なトピックのためのデュアルライト。
2.基本的なサービスのための消費者契約テスト；golden-datasets。
3.切り替え時の自動差分調整とアラート;コストレポート。

3〜6ヶ月

1.猶予期間のある単一の非推奨/削除プロセス。アーカイブとリーガルホールド。
2.地理/テナント固有の暗号化スキームとキー;敏感な市場のためのDPの変形。
3.データ辞書とライブ血統グラフ。

17） RACI

データガバナンス（A/R）：標準、レジストリ、移行レビュー、非公開。
ドメインオーナー（R）：フィールド、参考書、ビジネス不変量の意味。
データプラットフォーム（R）：レジストリツール、コンパットテスト、デュアルラン/バックフィル。
セキュリティ/DPO （A/R）： PIIポリシー、地理/テナント、DSAR/リーガルホールド。
SRE/Observability （C）：アラート、進化SLO、容量。
製品/金融（C）： KPIの検証、ウィンドウの切り替え。

18）アンチパターン

「現場でフィールドを編集」バージョンとデュアルランなし。
新しいフィールド→大規模な故障を追加する代わりに名前を変更します。
'unknown'ブランチのないハード列挙→新しい値でドロップ。
すべての管轄区域のシングルディレクトリ「in code」。
idempotent-mergeおよびcheck balancesのないBackfill。
検索/DSARのためのPIIとtrace_idなしでログを記録します。

19）関連セクション

データ検証、データ起源とパス、DataOpsプラクティス、分析とメトリクスAPI、監査とバージョン管理、データセキュリティと暗号化、アクセス制御、MLOps：モデル活用。

合計

スキームの進化はプロセスであり、1回限りの移行ではありません。レジストリ、バージョン、相互運用性；「真夜中のスイッチ」の代わりにデュアルランとブルーグリーン。運の代りに両立性テストおよびビジネス不変量。したがって、データは安定したままで、モデルは予測可能であり、レポートは正しく、レギュレータは穏やかです。