یکپارچگی داده ها

1) یکپارچگی داده ها چیست

یکپارچگی داده ها مجموعه ای از خواص و کنترل ها است تا اطمینان حاصل شود که داده ها در طول چرخه زندگی خود، از منابع و تبدیل به فروشگاه ها، API ها و صادرات، صحیح، سازگار و سازگار هستند. هدف این است که همان عبارت در صورت تکرار همان پاسخ را بدهد و هرگونه تغییر قابل ردیابی و قابل اثبات باشد.

2) انواع یکپارچگی و جایی که آنها زندگی می کنند

Entity-Unique کلیدهای اصلی، بدون تکراری.
ارجاع معتبر FK لینک عدم وجود «حلق آویز» لینک.
محدوده ها و فرمت های معتبر دامنه (نوع، طول، دایرکتوری ها).
قوانین کسب و کار: موضوع ثابت (تعادل ≥ 0، مقدار معامله = 0، و غیره).
موقت: یکنواختی و هماهنگی زمان بندی، مناطق زمانی صحیح.
سیاست های دسترسی: RLS/CLS سازگاری منطقی داده های قابل مشاهده را نقض نمی کند.

3) قراردادها و طرح های داده (منبع حقیقت)

ما قراردادهای رسمی برای مجموعه ها و رویدادها تنظیم می کنیم ؛ ما آنها را در ورودی و بعد از هر تحول اعمال می کنیم.

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id schema:
- {name: txn_id, type: string, unique: true}
- {name: user_id, type: string, not_null: true}
- {name: amount, type: decimal(18,2), min: 0}
- {name: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4) تضمین های معاملاتی و انزوا

اسید برای OLTP: اتمی، سازگاری، انزوا، دوام.
سطوح جداسازی: خواندن متعهد/تکرار خواندن/سریال سازی - در معرض خطر خواندن «کثیف «/منحصر به فرد/فانتوم را انتخاب کنید.
OLAP و دریاچه: تعهدات اتمی جداول (ورود به سیستم معامله)، سینک idemotent و طرح تکامل با کنترل سازگاری.
سازگاری فرمول های KPI: لایه معنایی → یک حقیقت برای گزارش ها و API ها.

5) سیستم های توزیع شده: نظم، تکرار، idempointency

سفارش رویداد: استفاده از 'event _ time' + 'inted _ at'، علامت های سفید و تحمل تاخیر ؛ جمع آوری بر اساس زمان رویداد.
تحویل مجدد (حداقل یک بار): جهانی 'event _ id'، جداول کلید های idempotency، upsert/ادغام با کلید پایدار.
خارج از ترتیب: محاسبه مجدد پنجره ها، استراتژی تاخیر، جبران خسارت.
دقیقا یک بار در معنی: حمل و نقل می تواند حداقل یک بار، گیرنده - idemotent.

6) اعتبار سنجی یکپارچگی (DQ) در هر لایه

• تازگی/کامل بودن/منحصر به فرد بودن/ارزش های معتبر/یکپارچگی ارجاعی.
• ناهنجاری ها: انفجار تکراری، شکاف زمانی، تغییرات شدید در توزیع.
• کنترل فرمول های KPI: نسخه بندی محاسبات و آزمون ها برای تطبیق نتایج (مجموعه های طلایی).
• کنترل صادرات - ممنوعیت صدور مجموعه با نقض (قرنطینه).

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7) یکپارچگی مالی و عملیاتی

دو ورودی: بدهی/اعتبار در تعادل ؛ خلاصه ای از آشتی در قطع.
Total invariants: مبلغ پرداخت = مبلغ نوشتن + هزینه + تنظیمات.
متغیرهای عملیاتی: معیارهای SLA/guardrail قوانین تجاری را نقض نمی کنند (به عنوان مثال، تعمیر خودکار تکراری ایجاد نمی کند).

8) اصل و نسب، حسابرسی و تکرارپذیری

Linage: منبع به نمایش گذاشتن/ویژگی ؛ قابلیت مشاهده تحولات و صاحبان.
مسیرهای حسابرسی: چه کسی، چه زمانی و چرا تغییر کرد نسخه های طرح/فرمول/شغل.
Snapshots/checkpoint: توانایی محاسبه مجدد و تایید گزارش های گذشته.
Repro: همان پرس و جو در همان برش → همان نتیجه (نسخه ها و لایه ها).

9) امنیت و حریم خصوصی بدون از دست دادن یکپارچگی

RLS/CLS: فیلترهای ردیف/ستون نباید ناورداها را نقض کنند (به عنوان مثال، مجموع نمونه قابل مشاهده باید با نمونه اعلام شده مطابقت داشته باشد).
Masking/tokenization: استراتژی های قطعی برای اطمینان از حفظ یکپارچگی و ارجاع.

رمزگذاری: در کانال و «بر روی دیسک» پس از فشرده سازی ؛ مدیریت کلیدی و حسابرسی دسترسی

DSAR/Retention: حذف/ناشناس اتصال را قطع نمی کند (سیاست آبشار).

10) خود سرویس و تعمیر خودکار

قرنطینه: جداسازی احزاب/دسته های مشکوک ؛ مصرف کنندگان - یک شاخه «تمیز».
Replay/Backfill: یک پنجره را از یک ورودی خام غیر قابل تغییر باز می کند.

آشتی دادن: آشتی دادن لایه و سیستم (raw↔curated↔marts ؛ istochnik↔DWH)

Dedup/Compaction/Rebuild: روش های سیستم برای تعمیر شاخص ها/مصالح.
سیاست به عنوان کد: «چه ناهنجاری → چه اقدامی → آستانه → تشدید».

11) شیوه های مدل سازی و ذخیره سازی

کلیدهای پایدار: PK جانشین (UUID/ULID)، کلیدهای طبیعی بدون تغییر در کتابهای مرجع.
Normalizatsiya↔denormalizatsiya: اتصالات FK در منابع، ویترین denormalized با کنترل نسخه منطقی.
SCD1/SCD2: تاریخ هدایت شده برای ابعاد.
مرتب سازی/خوشه بندی: RLE/zone-maps را بهبود می بخشد و آشتی ها را ساده می کند.
هش ها و چک سام ها: بررسی یکپارچگی فایل ها/دسته ها.

12) صداقت در طول زمان و در گزارش

نسخه های فرمول: گزارش ژانویه 2025 باید با فرمول نسخه X قابل تکرار باشد.
قطع و «بسته شدن دوره»: انجماد پنجره فروشگاه و آرشیو برش.
حقایق دیر رسیدن: مکانیک دوباره پر کردن و شمارش با علامت نسخه گزارش.
مستندات لغو: تنظیمات دستی - فقط حسابرسی.

13) ادغام و API ها

قرارداد API: طرح ها، انواع، زمینه های مورد نیاز، کدهای خطا ؛ نسخه بندی (v1/v2).
اعتبار در ورودی: بارهای بد را رد کنید، «سکوت» را تعمیر نکنید.
POST Idempotent: کلید idempotence، دوباره سعی کنید امن است.
صادرات به فایل ها: سازگاری دسته ای، هش، امضا.

14) ضد گلوله

SELECT در نمایش داده شد فروش و کولاک - تجزیه با تکامل جزئی.
FK «در کلمات»: بدون بررسی مرجع واقعی.
اصلاح اطلاعات خاموش بدون حسابرسی و گزارش.
TZ و فرمت های زمان را در یک مجموعه مخلوط کنید.
«گرفتن» KPI لغو بدون نسخه و سیاهههای مربوط.
کلید تقسیم تنها بدون استراتژی های بازپرداخت.
حذف DSAR بدون چک کردن لینک آبشاری.

15) نقشه راه پیاده سازی

1. موجودی و بحرانی: نقشه مجموعه/رویداد، صاحبان، خطرات، ناوردا.
2. قراردادها و طرح ها: انواع/محدودیت ها/FK، چک های سازگاری CI را رسمی کنید.
3. DQ در خط لوله: طراوت/کامل بودن/منحصر به فرد بودن/RI، قرنطینه، هشدارها.
4. مبنای معاملات: سینک اتمی، upsert/ادغام، تاریخ SCD، نسخه فرمول.
5. خط و ممیزی: دایرکتوری، ردیابی، تغییر سیاهههای مربوط، دسترسی به سیاهههای مربوط.

6. سیاست های تعمیر: پخش/backfill/dedup/آشتی به عنوان کد ؛ runbook'и и داده های MTTR SLO

7. امنیت/priv: RLS/CLS، پوشش، رمزگذاری، فرآیندهای DSAR.
8. گزارش: برش، برش یخ، نسخه KPI.

16) چک لیست قبل از انتشار/مورد نمایش

• PK/FK و محدودیت های دامنه تنظیم و تصویب آزمون.
• نسخهبندی طرحواره/فرمول فعال است ؛ سبز طرحواره دیف.
• قوانین DQ (طراوت/کامل بودن/منحصر به فرد بودن/محدوده/RI) سبز هستند.
• ورودی های Idempotent: upsert/merge، کلید idempotence (برای رویدادها).
• زمان: 'event _ time' و 'intested _ at'، TZ = UTC ؛ سیاست داده های دیر
• خط و حسابرسی قابل مشاهده است ؛ شامل قرنطینه و هشدار.
• RLS/CLS/ماسک کردن ناورداها و RI را نقض نمی کند.
• DSAR/نگهداری تست شده ؛ cut-off/archive آماده است.

17) قالب های کوچک

SQL: بررسی یکپارچگی ارجاعی

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

سیاست قرنطینه/تعمیر (pseudo-YAML)

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

نمودار SCD2 اندازه گیری

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) خط پایین

یکپارچگی داده ها یک چک واحد نیست، بلکه یک سیستم تضمین پایان به پایان است: قراردادهای رسمی و محدودیت ها، معاملات و توزیع های توزیع شده، اعتبار سنجی و اتوماسیون تعمیرات، خط و حسابرسی، حریم خصوصی و حقوق. هنگامی که این عناصر با هم کار می کنند، داده ها پایه قابل اعتماد برای راه حل ها می شوند و حوادث نادر، کوتاه و قابل پیش بینی هستند.