GH GambleHub

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).
Əməliyyat:
  • 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.

Əlaqəli materiallar:
  • «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»
Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

Telegram
@Gamble_GC
İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.