ادغام داده ها از منابع مختلف

ادغام داده ها از منابع مختلف

ادغام داده ها فرایند ترکیب جریان های ناهمگن (پایگاه داده های محصول، CRM، ارائه دهندگان پرداخت، گزارش های رویداد، ثبت های شخص ثالث) به نهادهای جامع و فروشگاه های سازگار است. هدف این است که یک رکورد طلایی و کاهش مداوم برای تجزیه و تحلیل، ML و موارد عملیاتی دریافت کنید.

1) سناریوها و اهداف معمول

360 درجه در اصل: مشتری/بازیکن، دستگاه، ابزار پرداخت، بازرگان.
تثبیت معامله: چندین PSPs/ثبت نقدی → یک ورود به سیستم تنها با idempotency اجباری.
عادی سازی رویداد: سیاهههای مربوط به وب/موبایل/backend → یک فرهنگ لغت رویداد واحد.
غنی سازی: دایرکتوری های خارجی (جغرافیایی، FX، AML/تحریم ها، منابع بازاریابی).
معیارهای یکپارچه: هماهنگی ارزها/زمان بندی ها، طرح ها و رمزگذاری ها.

2) قراردادها و طرح های منبع

• Schema: fields, types, nullability, key (s), value domains.
• Semantics: معنی هر فیلد (فرهنگ لغت).
• SLA: طراوت/فرکانس، حداکثر تأخیر و عدم سفارش.
• تکامل: سیاست تغییر طرح (عقب/جلو)، افسردگی.
• کیفیت: منحصر به فرد بودن کلید، محدوده قابل قبول، یکپارچگی ارجاعی.

3) شناسایی: کلید و نقشه برداری (ارتباط رکورد)

3. 1. شناسه های سخت

کلیدهای طبیعی: 'user _ id', 'transaction _ id', 'device _ id', 'iban'.
کلید های پروکسی: ایمیل/تلفن (عادی: مورد، فضاهای، کدهای کشور).
جایگزین: 'surrogate _ id' در جداول توپی در غیاب کلید جهانی.

3. 2. قوانین تطبیق نرم

قطعی: مطابقت دقیق ایمیل نرمال + DR ؛ «خانه «/» تلفن همراه «→ E.164.
احتمالاتی (فازی): Jaro-Winkler/Levenshtein برای نام/آدرس، TF-IDF/embedding برای رشته ها، «مسدود کردن» (مسدود کردن) توسط hashes/prefixes درشت برای شتاب.
رویکردهای گراف: موجودیت ها به عنوان گره ها، همزمانی ها به عنوان لبه ها ؛ اجزای اتصال خوشه بندی.
استراتژی گام به گام: از قوانین سخت و نرم با بررسی دستی «در مرز».

3. 3. قوانین تحکیم (بقا)

اولویت منبع «KYC registry> CRM> logs» است، زمانی که تضاد مقادیر وجود دارد.
تازگی: برچسب زمانی جدیدتر برنده (تنظیم شده برای اعتبار).
کامل: ترجیح می دهند غیر NULL ؛ ادغام آدرس ها/برچسب ها با ترکیب مجموعه ها.
حسابرسی: نگه داشتن «دنباله راه حل» - چه رونویسی شد و چرا.

4) تقسیم و MDM

لایه MDM (Master Data Management): جداول موجودیت اصلی + istochnik → روابط استاد.
رکورد طلایی: رکورد جمع شده با زمینه اعتماد به نفس/منبع حقیقت.
تاریخچه: SCD نوع 2 برای ویژگیهای وابسته به زمان (آدرس، وضعیت KYC).
هویت: ادغام جداول نقشه با «ادغام «/» نشت «تاریخ.

5) جریان تغییر: CDC، latecomers و تکراری

CDC (Change Data Capture): события 'insert/update/delete' + 'source _ lsn '/offset.
رویدادهای اواخر: علامت های سفید و دوره فضل، ذخیره به روز رسانی های دیر برای تنظیمات.
خارج از ترتیب: مرتب سازی بر اساس کلید و زمان، جبران به روز رسانی.
تکراری: کلید idempotent ('event _ id'، 'idempotency _ key')، dedup در پنجره.
دقیقا یک بار: تک معاملات/فروشگاه، 'MERGE' با منطق قطعی.

6) زمان بندی، ارزها و تقویم

زمان: فروشگاه در UTC + برش های محلی ؛ به صراحت فروشگاه 'مصرف در' و 'event _ time'.
ارزها: «ارز خام» را ذخیره کنید و «base _ ccy» را با نرخ در تاریخ معامله نرمال کنید.
تقویم ها: جداول تعطیلات/روز کاری بر اساس منطقه برای مقایسه عادلانه.

7) شبه SQL برای ادغام (upsert/ادغام)

7. 1. معاملات (مجله idemotent)

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 دقیقه/ساعت ؛ نظارت تاخیر و backogging.
هشدارها: افزایش تکراری، افزایش درگیری ها، کاهش کلید های پوشش.
سیاهههای مربوط به خط: از کدام منبع زمینه گرفته شد، چه زمانی و توسط چه کسی رونویسی شد.
Runybooks: سناریوهای حادثه (دسته های دیر، طوفان CDC، FX نادرست).

10) امنیت، حریم خصوصی، انطباق

PII: نام مستعار، هش کردن شناسه، پنهان کردن در BI.
RLS/CLS: دسترسی به نقش ها و ردیف ها ؛ صادرات - با نشانه ها و تاریخ انقضا.
طول عمر داده: برنامه های ذخیره سازی ؛ حق حذف (DSAR) و «نگهداری قانونی».
Re-identification: قوانینی برای به حداقل رساندن اتصالات جداول حساس.

11) مدل و سازمان داده

Layers: 'raw' (as is) → 'staging' (cleaning/normalization) → 'core' (master entities, fact/measurements) → 'marts' (ویترین برای تجزیه و تحلیل/ML).
SCD: نوع 2 برای ویژگی ها، نوع 1 برای اصلاح خطا ؛ صریح 'valid _ from/valid _ to'.
فروشگاه ویژگی: توابع تبدیل آنلاین/آفلاین یکسان هستند ؛ صحت در زمان.

12) الگوهای پیاده سازی

ELT با لایه معنایی: منطق ادغام به صورت اعلانی (قوانین، اولویتها، کلیدها) توصیف میشود.
جریان + microbatch: برای نمایش در زمان واقعی - microbatches 1-15 دقیقه با علامت های سفید.
Graph-linkage: یک هاب گراف جداگانه برای شناسایی پیچیده (دستگاه ها، نقشه ها، آدرس ها).
اعتبار سنجی مرحله ای: شامل قوانین پیوند جدید در حالت سایه، جمع آوری معیارهای دقت.

13) قبل از ادغام حلقه انتشار چک لیست

• قراردادهای امضا شده ؛ طرح ها و لغت نامه های زمینه سازگار هستند
• کلید های اتصال/قوانین تعریف شده ؛ دارای استراتژی تقسیم است
• قوانین بقا و اولویت های منبع تعیین می شوند ؛ گزارش حسابرسی فعال شد
• CDC/idempotency/پردازش داده ها در اواخر اجرا
• ارز/منطقه زمانی/تقویم نرمال
• تست های کیفیت و آشتی ها تنظیم می شوند ؛ داشبورد قابلیت مشاهده در دسترس هستند
• طراوت و در دسترس بودن SLO ثابت است ؛ هشدارها و runibooks آماده هستند
• PII/دسترسی/ذخیره سازی سازگار است
• مستندات: نهاد گذرنامه، طرح نسب، درخواست نمونه

14) گذرنامه «رکورد طلایی» (قالب)

نهاد: «کاربر _ طلایی»

کلید: 'user _ master _ id' (جانشین), mappings 'source _ user _ id []'

• 'email': عادی سازی + اولویت 'KYC> CRM> LOGS'
• «تلفن»: عادی سازی E.164، تقسیم تأیید
• «نام»: جارو-وینکلر ≥ 0. 92، سقوط - منبع KYC
• 'آدرس': شیء ترکیبی ؛ اتحادیه + اولویت تازگی
• تاریخچه: SCD2 ('valid _ from/valid _ to')
• خط: لیست مرجع زمینه اهدا کننده
• کیفیت: coverage≥98٪، dublikaty≤0. 3%
• SLO: طراوت ≤ 1 ساعت، در دسترس بودن ≥ 99. 9%
• صاحبان: پلت فرم داده، KYC/AML
• خطرات: برخورد نام، تلفن های «خانوادگی»، دستگاه های مشترک

15) خلاصه و توصیه ها

ادغام نه تنها یک «JOIN by key» است، بلکه یک طرح کلی است: قراردادهای منبع → شناسایی و تقسیم کردن → اولویت ها و «رکورد طلایی» CDC → و اواخر → کیفیت و مشاهده پذیری → ایمنی و تغییر تاریخ.
ساخت قوانین شفاف، نگه داشتن ممیزی از هر راه حل، پشتیبانی SCD و دقیقا یک بار. اینگونه است که داده ها از ده ها منبع به فروشگاه های قابل اعتماد و معیارهای پایدار برای محصول، تجزیه و تحلیل و ML تبدیل می شوند.