GH GambleHub

تست خطوط لوله داده

1) چرا آزمایش خطوط لوله داده

خطوط لوله داده (مصرف → تبدیل → خدمت) - یک زیرساخت حیاتی برای گزارش، ML و راه حل های عملیاتی. خطاها به معیارهای نادرست، سیگنال های تقلب و زیان های پولی تبدیل می شوند. تست فراهم می کند:
  • صحت و مقاومت.
  • تغییرات قابل پیش بینی (تکامل طرح/منطق).
  • انطباق با SLO از لحاظ تازگی، کامل بودن، تاخیر.
  • انتشار سریع (سرعت انتشار) به دلیل تأیید خودکار.

2) هرم تست داده

پایین به بالا: بسیاری از تست های محلی سریع → ادغام کمتر → کمی پایان به پایان.

1. تست واحد از تحولات (توابع، UDF، SQL-نمایش، DBT-مدل).
2. تست های کیفیت داده (طراوت/کامل بودن/منحصر به فرد بودن/قوانین محدوده).
3. قراردادها و طرحها (آزمونهای طرح/قرارداد، تکامل).
4. تست یکپارچه سازی خط لوله (DAG: مصرف ذخیره سازی ↔ ↔ تبدیل ↔ marts).
5. تست های E2E (منبع به فروشگاه/API) از جمله حقوق (RLS/CLS) و صادرات.
6. بار/ظرفیت (حجم، سرعت، هزینه برای خدمت).
7. تست هرج و مرج داده ها (تاخیر، تکراری، خارج از دستور، در دسترس نبودن).

3) انواع تست ها: دقیقا چه چیزی را بررسی می کنیم

3. 1 تست منطق واحد

توابع تبدیل خالص ؛ مبتنی بر ویژگی (ثابت: idemotency، یکنواختی).
SQL/DBT: مقایسه نتیجه با استاندارد (مجموعه طلایی)، ممنوعیت «انتخاب»، بررسی فیلتر توسط زمان.

3. 2 تست کیفیت داده (DQ)

تازگی: تاخیر پنجره ≤ آستانه هدف.
کامل بودن: مقدار مورد انتظار/درصد اشغال.
منحصر به فرد: کلید بدون تکراری.
قوانین دامنه: محدوده ها، یکپارچگی ارجاعی، ناورداهای تجاری.
ناهنجاریها: خروجیها، انفجار تکراری، شکافهای زمانی.

3. ۳ قراردادها و طرحها

سازگاری را تغییر دهید (SemVer: MAJOR/MINOR/PATCH).
در دسترس بودن ستون های اجباری، انواع، محدودیت ها.
معانی KPI ثابت: فرمول ها و پنجره های جمع آوری.

3. ۴ ادغام و E2E

یکپارچگی DAG: محرک ها، وابستگی ها، تکرار بی نظیر.

مسیر کامل → منبع → خام → سرپرستی → marts → BI/API ؛ RLS/CLS

3. 5 عملکرد و هزینه ها

p95/p99 تاخیر کار، توان (ردیف/ثانیه)، حجم/مقدار.
تست های رگرسیون عملکرد و محدودیت های اسکن.

3. 6 امنیت و حریم خصوصی

PII/PCI پوشش (نشانه گذاری قطعی).
بررسی RLS/CLS - کاربران فقط خودشان را می بینند.
صادرات/عکس های فوری: هیچ زمینه شخصی «خام» وجود ندارد.

4) ویژگی های جریان (Kafka/Flink/Spark Structured Streaming)

علامت های سفید و تاخیر: تست پنجره ها با وقایع دیر (T + Δ)، محاسبه صحیح.
دقیقا یک بار در معنی: dedup توسط 'event _ id'، ورودی idempotent (upsert/merge).
خارج از ترتیب: ثابت برای aggregates توسط «event _ time»; درست کردن خوردن در.
از دست دادن/تکرار: شبیه سازی قطره/بازی احزاب، بررسی صحت ویترین.

5) idempotence و جبرگرایی (چه و چگونه به آزمون)

راه اندازی مجدد یک مرحله همان نتیجه را می دهد (با همان پارامترهای پنجره).
ضبط - از طریق مرحله بندی و مبادله اتمی.
ادغام منطق با SCD1/SCD2 تحت پوشش last-write-wins، اولویت منبع است.

تعیین UDF/aggregate: ورودی های مشابه → خروجی های مشابه

6) تست مدیریت داده ها

مجموعه داده های طلایی: استانداردهای کوچک با اعتبار دستی.
Synthetics + کارخانه های داده: پوشش لبه های دامنه (null، مقادیر شدید، یونیکد، TZ).
De-identified prod samples: مسابقه حریم خصوصی.
داستان های لایه ای: رویدادهای خام، لایه های میانی، ویترین های نهایی.

7) قراردادهای داده - مثال و قوانین

قرارداد YAML (ساده شده):
yaml dataset: orders schema:
- name: order_id; type: string; unique: true
- name: user_id; type: string; not_null: true
- name: amount; type: decimal(18,2); min: 0
- name: event_time; type: timestamp; tz: UTC freshness_sla: 10m dq_rules:
- "pct_null(user_id) < 0. 1%"
- "duplicates(order_id) = 0"
- "sum(amount) >= 0"
evolution:
allowed_minor_additions: true breaking_changes_require: approval: 'data-governance'
actions_on_violation:
- quarantine_partition
- replay_last_60m

8) تست های قابل مشاهده و SLO

معیارهای صادرات: طراوت، کامل بودن، منحصر به فرد بودن، تأخیر در Grafana/Prometheus.
هشدار SLO به عنوان تست واحد «قرمز» در prod (Synthetics).
گزارش های رگرسیون: «پس از انتشار ↑ X p95 توسط 40٪».

9) CI/CD و رسانه ها

CI: واحد + DQ + قراردادهای PR ؛ طرحواره دیف ؛ تجزیه و تحلیل استاتیک SQL (linter).
Sandbox/staging: اجرای یکپارچه سازی و e2e، تست هرج و مرج با داده های امن.
پرچم ویژگی: canary jabs/models/formulas.
فهرست بندی: نسخه طرح ها، فرمول های KPI، اصل و نسب ؛ به روز رسانی خودکار اسناد.

10) تست داده های هرج و مرج (Chaos-Data)

تزریق تکراری/حذفیات، تاخیر، خارج از دستور.
قطره کارگزار/حزب، فایل های «شکسته»، رانش طرح.
ما اعتبار: تعمیر خودکار (پخش/backfill), قرنطینه و هشدار, MTTR-داده.

11) بار و هزینه

ژنراتور ترافیک با مشخصات p95/قله.
محدودیت در اسکن/مرحله (بایت اسکن، کلاه زمان).
پروفایل ارزش A/B: «قدیمی» در مقابل «جدید» مدل/پرس و جو.

12) ابزار (کلاس های نمونه)

DQ/قرارداد: تست های DBT، انتظارات بزرگ، Dequ، سودا، خطوط سفارشی.
ارکستراسیون: جریان هوا/Dagster/Argo/Prefect (اپراتورها برای آزمایش در هر مرحله).
بستر های نرم افزاری: BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi.

جریان: کافکا، فلینک، جرقه جریان ؛ TestContainers برای محیط های محلی

قابلیت مشاهده: Prometheus/Grafana/Otel ؛ دایرکتوری های DataHub/Amundsen/Collibra.

13) ضد گلوله

«هیچ چیز برای تست وجود ندارد - فقط SQL است»: هیچ واحدی وجود ندارد و معیارهای DQ → شکستن.
فقط E2E: آهسته، ناپایدار، علل خرابی مشخص نیست.
انتخاب: شکاف تحت تکامل جزئی.
خواندن زنده از OLTP در آزمون: بی ثباتی و پوسته.
عدم وجود مجموعه طلایی: چیزی برای مقایسه نتایج با.
بدون آزمون idempotency: دوباره داده ها را خراب می کند.
جریان فراموش شده: تاخیر تست نشده/خارج از ترتیب/تحویل مجدد.

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

1. اساس: تست واحد تحولات، مجموعه های طلایی، خطوط SQL، قوانین DQ را به نمایش می گذارد.
2. قراردادها: schema-diff در CI، SemVer، چک سازگاری خودکار.
3. یکپارچه سازی: تست DAG، idempotency، e2e برای جریان های بحرانی.
4. جریان: علامت های سفید/تاخیر، تست غرق dedup/idempotent.
5. SLO و هرج و مرج: معیارهای کیفیت در فروش، هشدارها، سناریوهای هرج و مرج، اهداف MTTR.
6. بهینه سازی: رگرسیون perf، نگهبانان بودجه، انتشار قناری.

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

  • تست های واحد شامل تحولات کلیدی و UDF است.
  • قوانین DQ برای طراوت/کامل بودن/منحصر به فرد بودن/محدوده عبور.
  • قراردادها و طرحوارهها سبز هستند ؛ هیچ تغییر ناگهانی بدون appruv وجود ندارد.
  • Idempotency تست شده ؛ سینک اتمی/ادغام کار می کند.
  • جریان: علامت های سفید/داده های دیرهنگام/خارج از سفارش تحت پوشش ؛ dedup در محل.
  • معیارهای SLO در معرض هستند ؛ هشدارها تنظیم می شوند ؛ کتاب های اجرا هستند.
  • داده های تست امن است ؛ PII ماسک زده ؛ RLS/CLS بررسی شده است.
  • بدون رگرسیون ؛ اسکن/محدودیت زمانی ملاقات کرد.
  • آزمون هرج و مرج از سناریوهای اساسی گذشت; MTTR-هدف قابل دستیابی است.

16) نمونه قالب کوتاه

16. 1 تست واحد SQL (pseudo-dbt):

sql
-- tests/assert_positive_amount. sql select count() as c from {{ ref('fct_payments') }}
where amount < 0 having c = 0

16. 2 انتظارات بزرگ سبک:

yaml expect_table_row_count_to_be_between:
min_value: 1000 mostly: 0. 99 expect_column_values_to_not_be_null:
column: user_id expect_column_values_to_be_unique:
column: txn_id

16. 3 بررسی تاخیر در جریان (شبه کد):

python emit(events_out_of_window <= threshold)
emit(reprocessed_events == late_events_detected)

16. 4 تست قرارداد (CI طرح):

bash schema-diff --current models/orders. yml --target prod_schema. yml --semver

17) خط پایین

تست خطوط لوله داده یک نظم سیستم است، نه مجموعه ای از چک های جزئی. ترکیب یک هرم از آزمون, قرارداد, و مشاهده با شیوه های idempointency, تکامل مدار, و جریان ثابت. سپس انتشار سریع خواهد شد، حوادث نادر و کوتاه خواهد شد و اعتماد به داده ها پایدار خواهد بود.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.