داده های خود شفا

1) تعریف و اهداف

داده های خود ترمیم روشی برای مهندسی داده است که در آن نقص ها به طور خودکار شناسایی می شوند و اقدامات اصلاحی (تعمیر، تحویل مجدد، برگشت، تثبیت مجدد، نمایه سازی مجدد) بدون مداخله انسانی یا با حداقل مداخله (انسان در حلقه برای موارد حساس) انجام می شود.
اهداف: MTTR داده پایین، افزایش اعتماد، انعطاف پذیری در برابر رانش و شکست، هزینه قابل پیش بینی مالکیت.

2) مشکلات معمولی برای درمان

طرح ها و قراردادها: تغییرات ناسازگار، ستون های گم شده، درگیری های نوع.
کیفیت/یکپارچگی: تکراری، حذفیات، منحصر به فرد/ارجاع نقض یکپارچگی.
زمان و طراوت: تاخیر تزریق، «سوراخ» در پنجره ها، desynchronization TZ/locales.
شناسه ها و کلیدها: تغییر ژنراتور شناسه، برخورد، کلیدهای طبیعی شناور.
ترتیب رویدادها: رویدادهای دیرهنگام، تنظیم مجدد، تحویل مجدد (حداقل یک بار).
ذخیره سازی: تخریب دسته ها، فایل ها/بلوک های شکسته، تحریف شاردینگ.
حقوق/امنیت: ماسک نادرست/رمزگذاری, نشت PII در آپلود.

3) ستون های خود شفا

1. قراردادهای داده (schemas + rules) با تست های خودکار.
2. خطوط لوله Idempotent (راه اندازی مجدد بدون اثرات دوگانه).
3. روزنامه نگاری و تکرارپذیری (خام/برنز غیر قابل تغییر، اصل و نسب).
4. مکانیسم های تعمیر (پخش، پر کردن، تراکم، ادغام-تعمیر، بازسازی).
5. قابلیت مشاهده و SLO (طراوت، کامل بودن، منحصر به فرد بودن، تأخیر).
6. سیاست های تصمیم گیری (زمانی که ما خودکار را ثابت می کنیم، زمانی که ما افزایش می یابد).

4) قراردادها و تست های کیفیت

قرارداد توصیف: طرح، محدوده قابل قبول، منحصر به فرد، RLS/ماسک، طراوت SLA.

yaml dataset: payments 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: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

تستها در هر مرحله اجرا میشوند: injection → staging → showcase. نقض قوانین فعال تعمیر خودکار (پایین را ببینید) و/یا قرنطینه.

5) Idempotence و جبرگرایی

Upsert/ادغام با کلید های پایدار (SCD2 برای تاریخ، SCD1 برای برش).
تبدیلات قطعی: یک ورودی → یک خروجی با همان پارامترها.
نسخه بندی - نسخه کد/طرح/لایه و برچسب داده (علامت) را اصلاح کنید.
سینک Idempotent: ضبط از طریق مرحله بندی + تعویض اتمی/تغییر نام.
دقیقا یک بار در معنی: قابل قبول «حداقل یک بار» حمل و نقل + گیرنده idempointent.

6) ابزار تعمیر

Replay/Backfill: تحویل مجدد برای پنجره نمی ∈ [T0، T1] 'از ورود به سیستم غیر قابل تغییر (خام).
آشتی: مقایسه aggregates/کلید بین لایه ها (خام ↔ سرپرستی ↔ marts) و بین سیستم ها (منبع ↔ DWH).
Deduplication: پنجره dedup توسط کلید (txn_id، event_id) + اکتشافی فاصله (فازی برای کلید های کثیف).
تراکم: انتقال فایل های کوچک به احزاب بزرگ (Parquet/ORC)، دوباره نمایه سازی.
Merge-repair: هنگامی که پرونده ها درگیر می شوند، پیش بینی های اولویت (توسط منبع/زمان/نسخه).
بازسازی شاخص ها/مواد: محاسبه مجدد aggregates/cube/roll-up.
قرنطینه/سایه: احزاب مشکوک خود را جدا می کنند ؛ مصرف کنندگان یک موضوع «تمیز» را می خوانند.
میانجیگری طرح: انتخابگر طرح ریزی خودکار (پر کردن پیش فرض ها، ستون های قابل محاسبه) برای تغییرات جزئی.

7) حفاظت از ذخیره سازی و یکپارچگی

بررسی مقدار و اعتبار بلوک (CRC، برابری).
ذخیره سازی Quorum (سیستم های سازگار با RAFT/Paxos، quorum خواندن/نوشتن).
پاک کردن برنامه نویسی برای افزونگی مقرون به صرفه.
نسخهبندی ذخیرۀ شیء) لغو (.
Atomic commit в Lakehouse (ثبت تراکنش، ACID - таблицы: Delta/Iceberg/Hudi).

8) ترتیب وقایع و «واقعیت کثیف»

رویدادهای اواخر: نگه داشتن پنجره تاخیر، استفاده از علامت "و ؛ پنجره ها را دوباره محاسبه کنید.
Redelivery: dedup توسط global 'event _ id'، جداول کلید idempotency.
زمان آفست: نرمال کردن TZ، ذخیرۀ «مصرف شده _ at» و «event _ time».
خارج از ترتیب: event_time-based مصالح با تنظیم علامت.

9) منطق تصمیم گیری (موتور سیاست)

قانون: «چه ناهنجاری → چه عمل → چه آستانه → که مالک است».

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) قابلیت مشاهده و SLO برای داده ها

• تازه بودن موارد نمایش ≤ 15 دقیقه.
• کامل بودن> 99 5٪ در زمینه های کلیدی.
• منحصر به فرد: تکراری <0. 01%.
• تاخیر محاسبه: p95 <5 دقیقه.
• پایداری تعمیر: MTTR-data <30 دقیقه.

معیارها و هشدارها: نمایشگاه در Prometheus/Grafana ؛ یک نوار اولویت از حوادث داده ایجاد کنید.

11) آشتی (شیوه ها)

بررسی aggregates: 'تعداد/مجموع/دقیقه/حداکثر' بین لایه/سیستم در پنجره کشویی.
آشتی کلید: تفاوت متقارن از مجموعه 'Δ = (A\B) ∪ (B\A)'.
«کار حسابرسی» دوره ای: مقایسه با منبع، بررسی انتخابی در منبع.
پرداخت/امور مالی: دو ورود، آشتی قطع روزانه، ورود به سیستم تنظیم.

12) مدیریت مدار و تکامل

SemVer برای طرح: MAJOR (می شکند )/MINOR (اضافه می کند )/PATCH (رفع).
قراردادها در CI/CD: schema-diff، سازگاری، تولید خودکار مهاجرت.
قلاب Backfill: با MINOR اضافه کردن پیش فرض/محاسبه زمینه، محاسبه مجدد ویترین.

پیش بینی های انعطاف پذیر: خوانندگان زیر مجموعه ستون ها را می خوانند ؛ ممنوع کردن «انتخاب»

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

RLS/CLS: فیلترهای ردیف/ستون، به ویژه در شاخه های تعمیر و صادرات.
نشانه گذاری مبتنی بر PII برای deduplication پایدار.
ممیزی دسترسی/صادرات: چه کسی دید که چه چیزی صادر شده است، جایی که آنها آن را فرستاده اند.
DSAR/Retention: حذف خودکار/ناشناس در فرایندهای تعمیر ؛ bickbackها الزامات قانونی را در نظر میگیرند.

14) هزینه و عملکرد

Backfill هزینه آگاه: محدود کردن عرض پنجره (به عنوان مثال، کشویی 3-7 روز).
Materialization and caches: محاسبه مجدد فقط دسته های تغییر یافته (افزایشی).
اولویت بندی: اولین ویترین بحرانی (مالی، خطرات)، سپس تحلیلی.
تعمیرات خارج از اوج: پنجره های شب/اولویت کم در زمانبندی.

15) شبیه سازی تست و حادثه

Chaos-data-testing: عمدا پارتیشن ها/مدارها را بر روی صحنه می شکند.
تاخیر جعلی: دسته های جعلی، خارج از ترتیب، تکراری.
مجموعه داده های طلایی: معیارهای آشتی پس از تعمیر.
GameDays: آموزش تیم به طور منظم در runbooks.

16) ضد گلوله

اصلاحات «نامرئی»: ویرایش خاموش بدون حسابرسی یا گزارش.
backfills تست نشده: هیچ منبع حقیقت/نسخه فرمول.
درخواست زنده سنگین به OLTP در طول تعمیرات: شما prod را به پایان برسانید.
انتخاب در مصرف کنندگان: با هر تغییر جزئی شکسته می شود.
تنها کلید برای deduplication عدم وجود کلیدهای fallback/امضاهای هش است.

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

1. کشف: مجموعه های بحرانی/معیارها، خطرات، صاحبان ؛ وابستگی نقشه.
2. قراردادها و تست ها: رسمی کردن طرح ها/قوانین در CI ؛ واژه نامه را منتشر کنید.
3. Idempotency: بازنویسی خطوط لوله کلیدی در upsert/ادغام، سینک اتمی.
4. ورود به سیستم خام و اصل و نسب: لایه تغییر ناپذیر، ابرداده کامل، علامت "و.

5. مکانیک تعمیر: backfill/replay، dedup، تراکم، قرنطینه ؛ موتور سیاست

6. قابلیت مشاهده و SLO: داشبورد کیفیت، هشدارها، نوار اولویت.
7. هرج و مرج داده ها و آموزش: تمرینات منظم + runbook 'و.
8. بهینه سازی هزینه: محاسبات افزایشی، اولویت بندی پنجره.

18) چک لیست قبل از انتشار

• قراردادهای داده و تست های کیفیت مجموعه های بحرانی را پوشش می دهند.
• خطوط لوله idemotent هستند ؛ تعهد اتمی و عقب نشینی وجود دارد.
• Backfill/replay و قرنطینه پیکربندی شده اند، سیاست های تشدید بیان شده است.
• تازگی/کامل بودن/منحصر به فرد بودن/معیارهای تاخیر و هشدار در تولید.
• شامل ممیزی ویرایش/تعمیرات ؛ نسخه های فرمول ها و فروشگاه ها را ذخیره می کند.
• DSAR/Retention برای تعمیرات و بازپرداخت دنبال می شود.
• یک کتاب اجرا وجود دارد و، تمرینات انجام شده، MTTR-هدف ثابت شده است.
• هزینه backfills توسط نگهبانان بودجه محدود است.

19) نمونه هایی از خودکار اقدامات (قالب)

«Window freshness failure X» → backfill (last_2h) → if not ok in 30 minutes → quarantine + on-call page.
«Duplicate txn_id spike» → شامل dedup سخت + آشتی منبع → گزارش علت.
«تغییر طرح MINOR» → تولید یک فیلد پیش فرض محاسبه → بازسازی aggregates.
«از دست دادن دسته» → بازگرداندن → تأیید مقدار چک از شی versioned.

خط پایین: داده های خود شفا یک «اسکریپت تعمیر» نیست، بلکه یک معماری سیستم است: قراردادهای رسمی، خطوط لوله idempotent، ورود به سیستم قابل اعتماد، مکانیک تعمیر خودکار و قابلیت مشاهده شفاف با SLO دقیق. چنین سیستمی نه تنها خود را تعمیر می کند، بلکه حوادث را به رویدادهای قابل کنترل با هزینه قابل درک و زمان بازیابی تبدیل می کند.