მონაცემთა კონვეიერის ტესტირება

1) რატომ უნდა შეამოწმოთ კონვეიერები

• სანდოობა (კორექტირება) და სტაბილურობა (სტაბილურობა).
• ცვლილებების პროგნოზირება (schema/logic evolution).
• SLO შესაბამისობა სიახლის, სისრულის, ლატენტობის მიხედვით.
• სწრაფი გამოშვება (გამოშვების სიჩქარე) ავტომატიზირებული შემოწმების გამო.

2) მონაცემთა ტესტირების პირამიდა

ქვემოდან ზემოთ: ბევრი სწრაფი ადგილობრივი ტესტი ნაკლებია ინტეგრაციის დროს.

1. ტრანსფორმაციების განყოფილება (ფუნქციები, UDF, SQL მოდელები, dbt მოდელები).
2. მონაცემთა ხარისხის ტესტები (სუფთა/სისრულის/უნიკალურობის/დიაპაზონის წესები).
3. კონტრაქტები და სქემები (schema/contract tests, ევოლუცია).
4. Paypline ინტეგრაციის ტესტები (DAG: ingest - storage - ტრანსფორმაცია/მარტები).
5. E2E ტესტები (წყაროდან ფანჯარაში/API), მათ შორის უფლებები (RLS/CLS) და ექსპორტი.
6. დატვირთვა/შესრულება (მოცულობა, სიჩქარე, cost-to-serve).
7. მონაცემთა ქაოსის ტესტები (შეფერხებები, დუბლიკატები, out-of-order, მიუწვდომლობა).

3) ტესტების ტიპები: რა ვამოწმებთ

3. 1 საუნივერსიტეტო ლოგიკური ტესტები

ტრანსფორმაციების სუფთა ფუნქციები; property-based (ინვარიანტები: იდემპოტენტურობა, ერთფეროვნება).
SQL/DBT: შედეგის შედარება სტანდარტთან (golden set), აკრძალვა 'SELECT', დროულად შეამოწმეთ ფილტრი.

3. 2 მონაცემთა ხარისხის ტესტები (DQ)

სიახლე: ფანჯრების შეფერხება სამიზნე ბარიერში.
სისრულე: მოსალოდნელი რაოდენობა/შევსების წილი.
უნიკალურობა: გასაღებები დუბლიკატების გარეშე.
დომენის წესები: დიაპაზონი, რეფერენდუმის მთლიანობა, ბიზნეს ინვარიანტები.
ანომალიები: outliers, დუბლიკატების აურზაური, დროის უფსკრული.

3. 3 კონტრაქტები და სქემები

ცვლილებების თავსებადობა (SemVer: MAJOR/MINOR/PATCH).
სავალდებულო სვეტების, ტიპების, შეზღუდვების არსებობა.
ჩაწერილი KPI სემანტიკა: დანაყოფის ფორმულები და ფანჯრები.

3. 4 ინტეგრაცია და E2E

DAG- ის მთლიანობა: ტრიგერები, დამოკიდებულებები, იდემპოტენტური გამეორება.
სრული გზა: წყარო - raw - curated - marts - BI/API; RLS/CLS.

3. 5 პროდუქტიულობა და ხარჯები

p95/p99 ჯობსის ლატენტობა, throughput (rows/s), მოცულობა/ღირებულება.
შესრულების რეგრესიების ტესტები და სკანირების შეზღუდვები.

3. 6 უსაფრთხოება და კონფიდენციალურობა

შენიღბვა PII/PCI (დეტერმინისტული ტოქსიკაცია).
შემოწმება RLS/CLS: მომხმარებლები მხოლოდ საკუთარ თავს ხედავენ.
ექსპორტი/ფიფქები: „ნედლეული“ პერსონალური ველების არარსებობა.

4) ნაკადის სპეციფიკა (Kafka/Flink/Spark Structured Streaming)

Watermarks და lateness: ფანჯრების ტესტები დაგვიანებული მოვლენებით (T + C), სწორი გადაანგარიშებები.
Exactly-once მნიშვნელობით: 'ღონისძიების _ id' ბაბუა, იდემპოტენტური ჩანაწერი (upsert/merge).
Out-of-order: 'event _ time' დანაყოფების ინვარიანტები; ჩაწერეთ 'ingested _ at'.
ზარალი/გამეორება: ჩვენ სიმულაციას ვაძლევთ პარტიების ნაკადს/რეიგს, ვამოწმებთ ფანჯრების სისწორეს.

5) Idempotence და determinism (რა და როგორ უნდა ტესტირება)

ნაბიჯის ხელახალი გაშვება იგივე შედეგს იძლევა (იგივე ფანჯრის პარამეტრებით).
ჩაწერა - staging და atomic swap.
Merge ლოგიკა SCD1/SCD2- ით დაფარულია კონფლიქტური ტესტებით (ბოლო write wins, წყარო).
UDF/აგრეგატების დეტერმინაცია: იგივე შესასვლელი - იგივე გასასვლელი.

6) ტესტის მონაცემების მენეჯმენტი

Golden მონაცემთა ბაზები: მცირე სტანდარტები სახელმძღვანელო რეგულირებით.
სინთეზური + მონაცემთა ქარხანა: დომენის კიდეების დაფარვა (nulls, ექსტრემალური ვალები, Unicode, TZ).
დე იდენტიფიცირებული პროდუქტები: კონფიდენციალურობის შესაბამისობა.
ფენიანი ფიქსაცია: ნედლეული მოვლენები, შუალედური ფენები, საბოლოო ფანჯრები.

7) მონაცემთა კონტრაქტები: მაგალითი და წესები

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 დაკვირვება და ტესტები

მეტრიკის ექსპორტი: Freshness, Completeness, Uniqueness, Latency Grafana/Prometheus.
SLO ალერტები, როგორც „წითელი“ ერთეულის ტესტები გაყიდვაში (სინთეტიკა).
რეგრესიის მოხსენებები: „X p95 გამოშვების შემდეგ 40% -ით“.

9) CI/CD და გარემო

CI: ერთეული + DQ + კონტრაქტები PR- სთვის; schema-diff; SQL (ლინტერი) სტატიკური ანალიზი.
Staging/staging: ინტეგრაციის და e2e პროგნოზი, უსაფრთხო მონაცემების ქაოსის ტესტები.
Feature-flags: კანარის ჯობი/მოდელები/ფორმულები.
კატალოგიზაცია: სქემების ვერსია, KPI ფორმულები, ხაზები; დოკუმენტაციის ავტომატური განახლება.

10) მონაცემთა ქაოსის ტესტირება (Chaos-Data)

დუბლიკატების/პასების, შეფერხებების, რიგის ინექცია.
ბროკერის/წვეულებების დაცემა, „გატეხილი“ ფაილები, schema drift.
Validirum: რემონტი (replay/backfill), quarantine და alertes, MTTR მონაცემები.

11) დატვირთვა და ღირებულება

ტრაფიკის გენერატორები p95/მწვერვალის პროფილით.
სკანირების/ნაბიჯის ლიმიტები (bytes scanned, time caps).
A/B ღირებულების პროფილი: „ძველი“ vs „ახალი“ მოდელი/მოთხოვნა.

12) ხელსაწყოები (სამაგალითო კლასები)

DQ/კონტრაქტები: dbt tests, Great Expectations, Dee, Soda, Custom linters.
ორკესტრი: Airflow/Dagster/Argo/Prefect (ტესტის ოპერატორები თითოეულ ეტაპზე).
პლატფორმები: BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi.
ნაკადი: კაფკა, ფლინკი, Spark Streaming; TestContainers ადგილობრივი მედიისთვის.
Observability: Prometheus/Grafana/Otel; DataHub/Amundsen/Collibra კატალოგები.

13) ანტიპატერები

„ტესტირება არაფერია მხოლოდ SQL“: არ არსებობს დანაყოფები და DQ - მეტრიკა იშლება.
მხოლოდ E2E: ნელა, არასტაბილურად, ავარიის მიზეზები უცნობია.
SELECT: იშლება MINOR ევოლუციის დროს.
OLTP ცოცხალი კითხვა ტესტებში: არასტაბილურობა და ფლეიკები.
ოქროს ნაკრების არარსებობა: შედეგების შედარება არაფერი აქვს.
არ არსებობს იდემპოტენტურობის ტესტები: ხელახალი გაშვება აფუჭებს მონაცემებს.
დავიწყებული ნაკადი: lateness/out-of-order/ხელახალი მიწოდება არ არის ტესტირებული.

14) გზის განხორციელების რუკა

1. საფუძველი: ტრანსფორმაციების ერთეული, ოქროს ნაკრები, SQL ლინტერი, ტოპ-10 ფანჯრის DQ წესები.
2. კონტრაქტები: schema-diff CI, SemVer, ავტომატური თავსებადობის შემოწმება.
3. ინტეგრაცია: DAG ტესტები, idempotence, e2e კრიტიკული ნაკადებისთვის.
4. ნაკადი: ტესტები watermarks/lateness, dedup/idempotent sinks.
5. SLO და ქაოსი: გაყიდვების მეტრიკა, ალერტები, ქაოსის სცენარები, MTTR მიზნები.
6. ოპტიმიზაცია: perf რეგრესია, ბიუჯეტის მცველები, კანარის გამოშვებები.

15) ჩეკის სია გამოქვეყნებამდე

• ერთეულის ტესტები მოიცავს საკვანძო ტრანსფორმაციებს და UDF.
• DQ წესები ახალი/სისრულე/უნიკალურობა/დიაპაზონი გადის.
• კონტრაქტები და schema-diff მწვანე; Approve- ს გარეშე არ არის გატეხილი ცვლილებები.

შემოწმებულია Idempotenty; atomic sink/merge მუშაობს.

• Striming: watermarks/late data/out-of-order დაფარულია; ადგილზე dedup.
• SLO მეტრიკა გამოფენილია; კონფიგურაციის ალერტები; runbooks არის.
• ტესტის მონაცემები უსაფრთხოა; PII შენიღბულია; შემოწმებულია RLS/CLS.
• არ არსებობს perf რეგრესიები; დაცულია სკანირების ლიმიტები/დრო.
• ძირითადი სცენარების ქაოსის ტესტები გაიარა; MTTR მიზნობრივი მიღწევა.

16) მინი შაბლონების მაგალითები

16. 1 Unit ტესტი SQL (ფსევდო-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 Contract-test (schema-diff CI):

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

17) შედეგი

მონაცემთა კონვეიერის ტესტირება არის სისტემური დისციპლინა და არა განსხვავებული შემოწმებების ერთობლიობა. დააკავშირეთ ტესტების პირამიდა, კონტრაქტები და დაკვირვება იდემპოტენტურობის პრაქტიკასთან, სქემების ევოლუციასა და სტრიმინგის ინვარიანტებთან. შემდეგ გამოშვებები სწრაფი გახდება, ინციდენტები იშვიათი და მოკლე გახდება, ხოლო მონაცემებისადმი ნდობა სტაბილური გახდება.