異なるソースからのデータのマージ

異なるソースからのデータのマージ

データの統合は、異機種混在フロー（製品データベース、CRM、決済プロバイダ、イベントログ、サードパーティのレジストリ）を全体的なエンティティと一貫したストアフロントに組み合わせるプロセスです。目標は、Golden Recordを取得し、分析、ML、運用事例の一貫したカットを得ることです。

1）典型的なシナリオと目的

本質の360°：顧客/プレーヤー、装置、支払の器械、商人。
トランザクションの統合：複数のPSP/キャッシュレジスタ→必須のIDを持つ単一のログ。
イベント正規化：web/モバイル/バックエンドログ→単一のイベント辞書。
エンリッチメント：外部ディレクトリ（geo、 FX、 AML/制裁、マーケティングソース）。
統一された指標：通貨/タイムゾーン、スキーム、エンコーディングの調整。

2）ソースコントラクトとスキーム

• スキーマ：フィールド、タイプ、nullability、キー（複数可）、値ドメイン。
• セマンティクス：各フィールド（辞書）の意味。
• SLA：新鮮さ/頻度、最大レイテンシおよびオーダー外。
• 進化：スキーム変更ポリシー（後方/前方）、うつ病。
• 質：キーの独自性、受諾可能な範囲、参照完全性。

3）識別： キーおよびマッピング（記録連動）

3.1.ハードID

自然キー：'user_id'、 'transaction_id'、 'device_id'、 'iban'。
プロキシキー：電子メール/電話（正規化：ケース、スペース、国コード）。
サロゲート：普遍的なキーがない場合、ハブテーブルの'surrogate_id'。

3.2.ソフトマッチングルール

確定論：正規化された電子メール+DRの正確な一致；「home「/」mobile 「phone→E.164。
確率的（ファジー）：名前/アドレスのJaro-Winkler/Levenshtein、文字列のTF-IDF/埋め込み、加速のための粗いハッシュ/接頭辞による「ブロック」（ブロック）。
グラフのアプローチ：ノードとしてのエンティティ、エッジとしての偶然；クラスタリング接続コンポーネント。
ステップアップ戦略：マニュアル「国境で」レビューで厳格からソフトルールまで。

3.3.統合ルール（存続）

値の競合がある場合のソースの優先順位は「KYCレジストリ>CRM>ログ」です。
新鮮さ：新しいタイムスタンプが勝つ（有効性に合わせて調整）。
フルネス：NULL以外を好む；セットを組み合わせてアドレス/タグをマージします。
監査：「ソリューショントレイル」を維持します-上書きされたものとその理由。

4）重複排除およびMDM

MDMレイヤ（マスターデータ管理）：マスタエンティティテーブル+istochnik→マスタリレーション。
ゴールデンレコード：「信頼」フィールド/真実のソースを持つ集計レコード。
履歴：時間依存属性（アドレス、KYCステータス）のSCDタイプ2。
アイデンティティ：マップテーブルを「merge「/」spill「日付でマージします。

5）変更の流れ： CDC、 latecomersおよび重複

CDC （Change Data Capture）： 'insert/update/delete'+'source_lsn '/offset。
遅いイベント：透かしと猶予期間、調整のための遅い更新を保存します。
Out-of-order：キーと時間によるソート、更新の補償。
重複：idempotentキー（'event_id'、 'idempotency_key'）、ウィンドウのデッドアップ。
正確に一度：トランザクションシングル/ストア、決定論理を持つ'MERGE'。

6）タイムゾーン、通貨、カレンダー

時間：UTC+ローカライズされたスライスに保存します。明示的に'ingested_at'と'event_time'を格納します。
通貨：「未加工通貨」と正規化された「base_ccy」を取引日のレートで保存します。
カレンダー：公正な比較のための地域別の休日/仕事日テーブル。

7）マージ用の疑似SQL （upsert/merge）

7.1.トランザクション（idempotent journal）

sql
MERGE INTO fact_transactions t
USING staging_transactions s
ON t. txn_id = s. txn_id
WHEN MATCHED AND s. updated_at > t. updated_at THEN
UPDATE SET amount = s. amount,
currency = s. currency,
status = s. status,
updated_at = s. updated_at
WHEN NOT MATCHED THEN
INSERT (txn_id, user_ext_id, amount, currency, status, event_time, updated_at)
VALUES (s. txn_id, s. user_ext_id, s. amount, s. currency, s. status, s. event_time, s. updated_at);

7.2.ユーザー「ゴールデンレコード」（ソース優先度+鮮度）

sql
WITH ranked AS (
SELECT s. ext_user_id,
s. norm_email,
s. phone_e164,
s. addr_struct,
s. source,
s. updated_at,
ROW_NUMBER() OVER (
PARTITION BY s. ext_user_id
ORDER BY
CASE s. source
WHEN 'KYC' THEN 1 WHEN 'CRM' THEN 2 ELSE 3 END,
s. updated_at DESC
) AS rn
FROM staging_users s
)
MERGE INTO dim_user_golden g
USING ranked r
ON g. ext_user_id = r. ext_user_id
WHEN MATCHED AND r. rn = 1 THEN
UPDATE SET email = COALESCE(r. norm_email, g. email),
phone = COALESCE(r. phone_e164, g. phone),
address = COALESCE(r. addr_struct, g. address),
source_of_truth = r. source,
updated_at = r. updated_at
WHEN NOT MATCHED AND r. rn = 1 THEN
INSERT (ext_user_id, email, phone, address, source_of_truth, updated_at)
VALUES (r. ext_user_id, r. norm_email, r. phone_e164, r. addr_struct, r. source, r. updated_at);

8）質およびテスト

テストスキーマ：必須フィールド、タイプ、ドメイン。
ロジックテスト：キーの一意性、重複の不在、「バック・イン・タイム」。
和解：ソースと最終ショーケースによる金額；相違→チケット。
プロファイリング：ディストリビューション、分数NULL、「ロングテール」。
メトリクスのマージ：精度/リコールマッピング、信頼できる≥しきい値を持つレコードの％。

9）観察可能性およびSLO

SLOの新鮮さ：窓の遅れ≤ N分/時間；遅延監視とバックログ。
アラート：重複の増加、競合の急増、カバレッジキーの低下。
血統ログ：フィールドがどのソースから、いつ、誰によって上書きされたか。
Runybooks：インシデントシナリオ（後期バッチ、CDC嵐、誤ったFX）。

10）セキュリティ、プライバシー、コンプライアンス

PII：エイリアシング、IDハッシュ、BIでのマスキング。
RLS/CLS：役割と行によるアクセス；export-トークンと有効期限。
データ寿命：ストレージのスケジュール；削除する権利（DSAR）と「法的保持」。
再識別：機密テーブルの結合を最小化するための規則。

11）モデルおよびデータ組織

レイヤー：'raw'→'staging' （cleaning/normalization）→'core' （master entities、 fact/measurements）→'marts' （showcases for analytics/ML）。

SCD： 属性のタイプ2、エラー訂正のタイプ1；明示的な'valid_from/valid_to'

Feature Store：変換関数はオンライン/オフラインで同一です。ポイント・イン・タイムの正しさ。

12）実装パターン

ELT with semantic layer：マージロジックは宣言的に記述されます（ルール、優先順位、キー）。
ストリーム+マイクロバッチ：ほぼリアルタイムディスプレイ用-透かし付きマイクロバッチ1-15分。
グラフリンケージ：複雑な識別のための別のグラフハブ（デバイス、マップ、アドレス）。
ステップアップ検証：シャドウモードに新しいリンケージルールを追加し、精度メトリックを収集します。

13）プリマージループリリースチェックリスト

• 署名されたソースコントラクト；スキーマとフィールド辞書は一貫しています
• 定義されたリンケージキー/ルール；重複排除戦略を持っています
• サバイバルルールとソースの優先順位が設定されています。監査ログが有効になっています
• CDC/idempotency/lateデータ処理を実装
• 通貨/タイムゾーン/カレンダー正規化
• 質のテストおよび和解はセットアップされます；可視性のダッシュボードが利用可能
• SLOの鮮度と可用性は固定されています。アラートおよびrunibooksは準備ができています
• PII/アクセス/ストレージ準拠
• ドキュメント：Entity Passport、 lineageスキーマ、サンプルリクエスト

14）「ゴールデンレコード」のパスポート（テンプレート）

エンティティ： 'USER_GOLDEN'

キー： 'user_master_id'（サロゲート）、マッピング'source_user_id［］'

• 'email'：正規化+優先度'KYC> CRM> LOGS'
• 'phone'： E.164正規化、検証分割
• 'name'： Jaro-Winkler ≥ 0。92、フォールバック-KYCソース
• 'address'：複合オブジェクト；ユニオン+鮮度優先
• 履歴：SCD2 （'valid_from/valid_to'）
• 血統：ドナー・フィールド参照リスト
• 質：適用範囲≥ 98％、 dublikaty ≤ 0。3%
• SLO：鮮度≤ 1時間、可用性≥ 99。9%
• 所有者：データプラットフォーム、KYC/AML
• リスク：名前の衝突、「家族」の電話、共有デバイス

15）概要と推奨事項

合併は「キーごとのJOIN」だけでなく、ソースコントラクト→識別とデッドアップ→優先順位、CDC→および後期→品質と観測性→安全性と変更履歴の「ゴールデンレコード」です。
ルールを透過的に構築し、各ソリューションの監査を維持し、SCDと正確に一度をサポートします。これは、数十のソースからのデータが信頼性の高いストアフロントと製品、分析、およびMLの持続可能な指標に変わる方法です。