Məlumatların mənşəyi
Məlumatların mənşəyi (Lineage)
1) Lineage nədir və niyə lazımdır
Data Lineage «məlumatların haradan gəldiyi, necə çevrildiyi, harada və kimlər tərəfindən istifadə edildiyi» rəsmi qeydidir. Nəticə - məlumat sistemini başa düşülən və auditoriya edən atributlarla (vaxt, versiyalar, sahiblər, transformasiya, giriş siyasəti, keyfiyyət) yönümlü asılılıq qrafikidir.
Biznes dəyəri:- Metrik şəffaflıq (maliyyə, məhsul, risk): "Niyə sayı X = 1 234? ».
- Dəyişikliklərin sürətli impakt analizi (sxem/job): «Əgər nə qırılır»....
- Uyğunluq və audit (GDPR/ISO/SOC): sahənin sübut edilə bilən yolu.
- onbordinq sürətləndirilməsi və toil azalması (öz-özünə xidmət bilik).
- Keyfiyyətin yaxşılaşdırılması: risk daha yüksək olan yerlərdə hədəf yoxlamalar.
2) Əhatə dairələri və detal səviyyələri
Axın səviyyəsi (pipeline/job): hansı joblar/orkestratorlar datasetləri yaratdılar.
dataset səviyyəsi (table/view/topic/file): girişlər → çıxışlar, versiyalar/snapshotlar.
Sütun səviyyəsi (column/feature-level): Hər bir sahə necə hesablanır, hansı mənbələrdən.
İstehlak təbəqəsi: BI hesabatları, API, ML modelləri, daşbordlar və xəbərdarlıqlar.
Kritik varlıqlar üçün (pul, tənzimləyici) - column-level detalları tələb olunur.
3) Lineage data modeli: Əsas varlıqlar
Dataset: `{urn, type, schema, owners, pii_class, retention, tags}`
Job/Task: `{urn, code_ref, version, runtime, schedule, owners}`
Run/Execution: `{run_id, job_urn, start/end, status, inputs[], outputs[], code_sha, infra}`
Field: '{dataset _ urn, name, type, derivation}' (-/AST/operator ifadəsi).
Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`
Quality Check: `{check_id, scope, rule, severity, result}`
4) Lineage mənbələri: aktiv vs passiv montaj
Aktiv (event-based): «job started/finished, inputs/outputs, column-mapping» hadisələrinin emissiyası üçün orkestratorları/mühərrikləri (Spark/DBT/SQL engines/Kafka) alətləndiririk.
Üstünlüklər: dəqiqlik, aktuallıq, post-parsinqin minimuma endirilməsi.
Passiv (inference): DAG 'i parsimi, SQL/DDL/log-sorğular, kataloq/saxlama qeydləri; retroaktiv asılılıq qurmaq.
Üstünlüklər: irsin sürətli əhatə olunması; mənfi cəhətləri: column-level aşağı dəqiqlik.
Adətən hibrid tətbiq olunur: mümkün olan aktiv hadisələr və «sığorta şəbəkəsi» kimi passiv analiz.
5) Həll arxitekturası (etalon)
Producers (orkestrlər/mühərriklər) → lineage hadisələrinin şinası → Normallaşdırıcı → Qraf saxlama → İndeks/axtarış → UI/API/alertlər → İxrac/kataloq.
Hadisələr: URN identifikatorları və semantik versiyaları ilə vahid (job/run/dataset/column-lineage).
Qraf saxlama: column-level qraf (məsələn, qrafik DB əsasında və ya relyasiya + inverted index).
UI: qısa yolların interaktiv vizuallaşdırılması, impact/kök-səbəb, qabırğa və düyünlərdə «keyfiyyət siqnalları».
İnteqrasiyalar: məlumat kataloqu, keyfiyyət sistemi (DQ), giriş idarəetmə (ABAC), audit (append-only jurnalları).
6) Identifikatorlar və versiyalaşdırma
Hər bir dataset/job/sahə üçün URN/Global ID: sabit, insan oxunan, platforma/neyspace/ad/versiya daxil.
Sxem versiyaları (SchemaVersion) və kod versiyaları (code SHA, image digest).
Zaman qrafının şəkilləri (time-travel lineage): araşdırmaların təkrarlanabilirliyi.
7) Column-level lineage: etibarlı almaq üçün necə
SQL-parsinq AST qurulması və alias/STE/vyux normallaşdırılması ilə.
Transformasiya kodunda şərhlər (DBT testləri, primitiv şərhlər, UDF-metadata).
Mühərriklərdən hadisələr: "target. col = f(src. a, src. b)».
Semantik qaydalar: UDF/toplama opsları «lossy» (qranulyar itkisi ilə) və ya «sensitive-preserving» (PII etiketləri daşıyır) kimi qeyd olunur.
8) Məxfilik və təhlükəsizlik ilə lineage əlaqəsi
Privacy by Design: 'pii _ class', 'consent _ scope', 'retention'. Dinamikləri təbliğ edərkən etiketlər qaydalara uyğun ötürülür (məsələn, 'email → hash_email' PII-derived olaraq qalır).
PII tokenizasiyası: lineage tokenizasiya/detokenizasiya faktını və token xidmət qovşaqlarını saxlayır; hər hansı bir detokinasiya audit hadisəsidir.
Şifrələmə: AEAD/FPE lineage sahələri üçün «kriptovalyutası» və əsas sahəni (tenant/scope) açarları açmadan qeyd edir.
Audit və WORM: lineage hadisələri və siyasət dəyişiklikləri dəyişməz jurnalda saxlanılır (hash zəncirləri ilə append-only).
9) Lineage əsasında məlumat keyfiyyəti və SLO
Qabırğalarda çeklər: təzəlik (freshness), dolğunluq (completeness), unikallıq/açarlar, paylama sürüklənməsi.
SLO/SLI: «Maliyyə hesabının metriklərini qidalandıran cobların 95% -i 06:00 UTC ≤ başa çatıb».
Root-cause: qrafik + vaxt «ilk sınıq düyün» sürətli tərifi verir.
10) İmpakt təhlili və dəyişikliklərin idarə edilməsi
Sxemdə/məntiqdə planlaşdırılan dəyişiklik zamanı: aşağı axın sütununa görə (downstream) - toxunan hesabatların/modellərin/API müştərilərinin siyahısı.
«Breaking changes» siyasəti: downstream-artefakt sahiblərinə məcburi bildiriş, grace-period, paralel versiyalar ('v1 '/' v2') və «sunset-date» bayrağı.
İstehlakçıların siyahısı və miqrasiya çeki ilə avtomatik PR/biletlər.
11) Orkestrlər və mühərriklərlə inteqrasiya
Orchestrators: job-dən əvvəl/sonra 'RunStarted/RunCompleted' hadisələri inputs/outputs ilə yayımlanır.
SQL/ELT: faktiki icra planı və mapping sütunları almaq üçün mühərriklərə (warehouse, lakehouse) bağlayıcılar.
Stream-processing: lineage mesajları (topic → topic, key/headers), Euro/Protobuf sxemləri, registry vasitəsilə sxemlərin təkamülü.
ML: fich/dataset lineage, model versiyaları, təlim artefaktları, əlamətlərin mənbələri.
12) Etiketlərin təbliğat qaydalarının modelləşdirilməsi (data contracts)
Data dəsti müqaviləsi: sxem + sahə semantikası (açarlar, PII, aqreqativlik, lisenziyalar/hüquqi əsaslar, retention).
Təbliğat qaydaları:- 'SELECT a, b FROM T' → 'a, b' etiketlərini köçürün.
- 'hash (email)' → etiket 'PII-derived (pseudonymized)' detocenization qadağası ilə.
- 'SUM (amount)' → fərdiliyin itirilməsi; nəticə sahəsində join 's qadağan.
- Müqavilələr CI-də (uyğunsuzluqda blocker) təsdiqlənir və pozuntular auditdə hadisələrdir.
13) Performans və miqyas
Lineage hadisələrinin inkremental enjestiyası; '(run_id, job_urn)' deduplikasiyası.
Qraf saxlama: isti indeks (son 30-90 gün) və arxiv ayrılması; snapshot.
Tez-tez sorğular üçün yolların keşləşdirilməsi («qızıl» metriklərə qısa yollar).
Neyspeys/kirayəçilər üçün şərdinq; «canavar düyünlərindən» qorunma (fan-out limiti).
14) Vizuallaşdırma və UX
Rejimlər:- Path to metric: «metrika nədən ibarətdir».
- Impact from source: «dəyişiklik kimə təsir edəcək».
- Field lineage: «sahə necə hesablanır».
- Overlay: job statusu, keyfiyyət, PII etiketləri, retensiyalar, sahibləri.
- Tədbirlər: müqavilə açmaq, miqrasiya üçün bilet yaratmaq, dəyişiklik alertlərinə abunə olmaq.
15) Qrafa giriş təhlükəsizliyi
ABAC: düyünlərin/qabırğaların görünürlüyü kirayəçilər/rollarla məhdudlaşır.
Redaction: həssas sahələrin adlarını (və ya onların təxəllüslərini) hazırlıqsız rollar üçün UI-də gizlətmək.
API üçün mTLS/OIDC; lineage hadisələri xidmət şəxsiyyətləri ilə imzalanır.
WORM və oxu nəzarət: qraf kritik seqmentləri oxumaq da qeyd olunur.
16) Əməliyyat: SLO, monitorinq, alert
SLO Count: hadisə görünüşünün gecikməsi <5 dəq; tam örtük> 98% kritik payplayns; 100% «qızıl metrik» column-level lineage var.
Alertlər: zəncirin qırılması, tamamlanma hadisələri olmadan run, sxemlərin uyğunsuzluğu, «yetim» datasetlər, fan-out/dövrlərin böyüməsi.
Hesabatlar: həftəlik «state of lineage coverage», ən yaxşı 10 risk qovşağı.
17) Gizlilik və uyğunluq (bağlar)
GDPR/PbD: emal əsasları və retensiyaları etiketlər kimi saxlamaq; lineage uyğun seqmentlərin cascade kriptovalyutası aradan qaldırılması vasitəsilə sürətli DSAR yolları axtarış və «silmək hüququ» təmin edir.
Secrets Management: xammal giriş mənbələri lineage heç açıq kreditlər kimi daxil deyil; yalnız rol/siyasət istinad saxlanılır.
Audit/dəyişməz jurnallar: bütün lineage hadisələri imzalanmış və append-only saxlama (müvafiq məqaləyə baxın).
18) Çek vərəqləri
Başlamazdan əvvəl:- datasets/jobs/fields üçün müəyyən URN razılaşmaları.
- Orkestrlər və mühərriklərdən lineage hadisələrinin emissiyası daxil edilmişdir.
- SQL/DDL parser və sxemləri normallaşdırıcı işləyir.
- Təsdiq edilmiş data-contracts və PII/retens təbliğat qaydaları.
- WORM Hadisə Jurnalı və Qrafik Yedəkləri.
- BI/ML lineage istehlakçıları kimi qoşulur (hesabatlar, modellər, fiqurlar).
- Kritik domenlər üzrə lineage ≥ 98%, column-level = 100%.
- Boşluqlar, «yetim» datasetlər, sürüklənmə sxemləri daxildir.
- Rüblük PII və müqavilələrin auditi.
- Dəyişikliklərin sənəd dövriyyəsi (breaking) və istehlakçılara göndərilməsi.
19) Mini reseptlər
RunCompleted (psevdo-JSON) hadisəsi:json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}
PII təbliğat qaydası (ideya):
if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii
Impact-quaris «nə qırılacaq»:
affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}
20) Tez-tez səhvlər və onlardan necə qaçmaq olar
Lineage rəsmi model olmadan «şəkil». Hadisələr/sxemlər/URN lazımdır, əks halda qrafik miqyaslı deyil.
«Pul» harada column-level yoxdur. Sütun səviyyəsi olmadan hesablamalar izah edilə bilməz.
Natamam hadisələr (code_sha/versii sxemləri olmadan). Reproduktivlik mümkün deyil.
Gizlilik İqnor. PII işarələri sahələrlə birlikdə yaşamalı və köçürülməlidir.
Charding olmadan bir böyük qrafik DB. Nişanlara bölünün, snapshotları saxlayın.
Parserlərə kor iman. Mübahisəli hallarda - mühərriklərdən aktiv hadisələr.
21) Runbook’и
Hadisə: metrika «atladı».
1. Açın «Path to metric» → yolda son 'Run' düyünləri yoxlamaq.
2. Kod/sxemlərin versiyalarını, qabırğalarda DQ çeklərinin vəziyyətini müqayisə edin.
3. Əgər sınıq link tapılıbsa - sahibinə bilet yaratmaq, metrikanın müvəqqəti «hold» nəşrini daxil etmək.
4. Fiksdən sonra - RCA-nı qeyd edin və qrafın düyünləri ilə əlaqələndirin.
Mənbə sxeminin dəyişdirilməsi.
1. downstream impact tələb edin.
2. Sahiblərinə bildirişlər göndərin, miqrasiyanın PR-lərini yaradın.
3. paralel 'v _ next' qaldırın, sunset tarixinə qədər hər iki versiyası saxlamaq.
4. Bağla 'v _ prev', müqavilələri və lineage-qrafik yeniləyin.
- «Privacy by Design (GDPR)»
- «PII məlumatların tokenləşdirilməsi»
- «Sirlərin menecmenti»
- «Audit və dəyişməz jurnallar»
- «Şifrələmə At Rest/In Transit»
- «Açarların idarə edilməsi və rotasiya»