Maʼlumotlar kelib chiqishi

Ma’lumotlarning kelib chiqishi (Lineage)

1) Lineage nima va nima uchun kerak

Data Lineage - bu «ma’lumotlar qayerdan kelgan, ular qanday o’zgargan, qaerda va kim tomonidan ishlatilgan» degan rasmiy yozuv. Natija - ma’lumotlar tizimini tushunarli va auditlanuvchan qiladigan atributlar (vaqt, versiyalar, egalari, transformatsiyalar, kirish siyosati, sifat) bilan bog’liqlikning yo’naltirilgan grafasi.

• Metriklarning shaffofligi (moliya, mahsulot, xavf): "Nima uchun X = 1 234 raqami? ».
• O’zgarishlarni tezkor impakt-tahlil qilish (sxema/job): «agar nima buzilsa»....
• Muvofiqlik va audit (GDPR/ISO/SOC): dalaning isbotlanadigan yoʻli.
• Onbordingni tezlashtirish va toil (o’z-o’ziga xizmat ko’rsatish) ni kamaytirish.
• Sifatni yaxshilash: xavf yuqori bo’lgan joylarda maqsadli tekshiruvlar.

2) Qamrov sohalari va tafsilotlar darajasi

Oqim darajasi (pipeline/job): qanday joblar/orkestratorlar datasetlarni yaratdilar.
Dataset darajasi (table/view/topic/file): kirish → chiqish, versiya/snapshotlar.
Ustunli daraja (column/feature-level): har bir maydon qanday hisoblanganligi, qaysi manbalardan olinganligi.
Iste’mol qatlami: BI, API hisobotlari, ML modellari, dashbordlar va ogohlantirishlar.

Tanqidiy mavjudotlar (pul, tartibga soluvchi) uchun - column-level tafsilotlari majburiy hisoblanadi.

3) Lineage ma’lumotlar modeli: asosiy mohiyatlar

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}’(derivatsiya/AST/operator).

Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`

Quality Check: `{check_id, scope, rule, severity, result}`

4) Lineage manbalari: aktiv vs passiv yig’ish

Aktiv (event-based): «job started/finished, inputs/outputs, column-mapping» voqealarini chiqarish uchun orkestrator/dvigatellarni (Spark/DBT/SQL engines/Kafka) instrumentlaymiz.

Afzalliklari: aniqlik, dolzarblik, post-parsingni minimallashtirish.
Passiv (inference): DAG’i parsimlari, SQL/DDL/log-so’rovlar, kataloglar/omborlar loglari; retroaktiv bog’liqlik tuzamiz.

Afzalliklari: merosni tez qamrab olish; kamchiliklar: quyida aniqlik column-level.

Odatda gibrid qo’llaniladi: mumkin bo’lgan faol voqealar va passiv tahlil «sug’urta to’ri» sifatida.

5) Yechim arxitekturasi (etalon)

Producers (orkestratorlar/dvigatellar) → Shina hodisalar lineage → Normalizator → Ombor grafa → Indeks/qidiruv → UI/API/alertlar → Eksport/katalog.

Hodisalar: unifikatsiyalangan (job/run/dataset/column-lineage), URN identifikatorlari va semantik versiyalari bilan.
Grafa saqlovchisi: column-level grafa (masalan, grafik DB yoki relyasion + inverted index asosida).
UI: qisqa yo’llarni interfaol tasvirlash, impakt/ildiz-sabab, qovurg’a va tugunlardagi «sifat signallari».
Integratsiyalar: maʼlumotlar katalogi, sifat tizimi (DQ), kirishni boshqarish (ABAC), audit (append-only jurnallar).

6) Identifikatorlar va versiyalash

Har bir dataset/job/maydon uchun URN/Global ID: platforma/nomspeys/nom/versiyani o’z ichiga olgan barqaror, o’qish mumkin.
Sxemalar versiyasi (SchemaVersion) va kod versiyasi (code SHA, image digest).
Vaqt bo’yicha grafik rasmlari (time-travel lineage): tekshiruvlarning takrorlanuvchanligi.

7) Column-level lineage: ishonchli qanday olish mumkin

SQL-parsing AST qurish va aliaslarni/STE/vyuxni normallashtirish.
Transformatsiya kodidagi izohlar (DBT tests, primitiv kommentlar, UDF-metadata).
Harakatlantiruvchi hodisalar: "target. col = f(src. a, src. b)».
Semantik qoidalar: UDF/agregatsiyalash opslari «lossy» (granulyarligi yo’qolgan holda) yoki «sensitive-preserving» (PII-belgilarni ko’chiradi) deb belgilanadi.

8) Lineage bilan maxfiylik va xavfsizlik aloqasi

Privacy by Design:’pii _ class’,’consent _ scope’,’retention’. Ustunlarni targ’ib qilishda belgilar qoidalarga muvofiq uzatiladi (masalan,’email → hash_email' PII-derived bo’lib qoladi).
PII: lineage tokenizatsiya/detokenizatsiya faktini va token-servis uzellarini saqlaydi; har qanday detokenizatsiya - audit bilan bog’liq voqea.
Shifrlash: AEAD/FPE lineage maydonlari uchun kalitlarni ochmasdan «kripto-holat» va asosiy sohani (tenant/scope) belgilaydi.
Audit va WORM: lineage voqealari va siyosatdagi o’zgarishlar o’zgarmas jurnalda (xesh-zanjirli append-only) saqlanadi.

9) Lineage bazasidagi ma’lumotlar va SLO sifati

Qovurg’alardagi cheklar: yangilik (freshness), to’liqlik (completeness), noyoblik/kalitlar, taqsimot dreyfi.
SLO/SLI: «Moliyaviy hisob metrikasini oziqlantiruvchi joblarning 95 foizi 06:00 UTC ≤ yakunlandi».
Root-cause: grafa + bajarish vaqtlari «birinchi singan tugun» ni tezda aniqlaydi.

10) Impakt-tahlil va o’zgarishlarni boshqarish

Sxema/mantiq rejali o’zgarganda: oqim bo’yicha pastga (downstream) - ta’sir ko’rsatuvchi hisobotlar/modellar/API mijozlari ro’yxati.
«breaking changes» siyosati: downstream-artefaktlar egalarini majburiy ravishda xabardor qilish, grace-davr, parallel versiyalar (’v1 ’/’ v2’) va «sunset-date» bayrog’i.
Iste’molchilar ro’yxati va migratsiya chek-varaqasi bo’lgan avtomatik PR/chiptalar.

11) Orkestratorlar va dvigatellar bilan integratsiya qilish

Orchestrators: job oldidan/keyin’RunStarted/RunCompleted’s inputs/outputs voqealari chiqariladi.
SQL/ELT: amalda bajarish rejasi va ustunlar mappingini olish uchun dvigatellarga (warehouse, lakehouse) ulanadigan konnektorlar.
Stream-processing: lineage xabarlar (topic → topic, key/headers), Euro/Protobuf sxemalari, registry orqali sxemalarning evolyutsiyasi.
ML: fich/datasetlar lineage, model versiyalari, mashq artefaktlari, belgilar manbalari.

12) Belgilarni targ’ib qilish qoidalarini modellashtirish (data contracts)

Ma’lumotlar to’plami kontrakti: sxema + maydonlar semantikasi (kalitlar, PII, agregatsiyalanganlik, litsenziyalar/huquqiy asoslar, retention).

• ’SELECT a, b FROM T’ →’a, b’belgilarini koʻchirish.
• ’hash (email)’ →’PII-derived (pseudonymized)’belgisi detokenizatsiyani taqiqlaydi.
• «SUM (amount)» → individuallikni yo’qotish; natija maydonida join’lar taqiqlangan.
• Kontraktlar CI (mos kelmaganda blocker) da, qoidabuzarliklar esa auditga kiritiladi.

13) Unumdorlik va masshtab

Lineage voqealarining inkremental injestiyasi; ’(run_id, job_urn)’ bo’yicha deduplikatsiya.
Grafani saqlash: issiq indeks (oxirgi 30-90 kun) va arxivni bo’lish; snapshotlar.
Tez-tez soʻrovlar uchun yoʻllarni keshlash («oltin» metriklarga qisqa yoʻllar).
Neyspeyslar/ijarachilar bo’yicha sharding; «yirtqich uzellardan» himoya qilish (fan-autni cheklash).

14) Vizualizatsiya va UX

• Path to metric: «nimadan olingan metrika».
• Impact from source: «Oʻzgarish kimga taʼsir qiladi».
• Field lineage: «maydon qanday hisoblangan».
• Overleylar: job maqomi, sifati, PII-belgilari, retensiyalari, egalari.
• Harakatlar: kontrakt ochish, migratsiya uchun chipta yaratish, o’zgartirish alertlariga obuna bo’lish.

15) Grafadan foydalanish xavfsizligi

ABAC: uzellar/qovurg’alar ko’rinishi ijarachilar/rollar bilan cheklangan.
Redaction: tayyorlanmagan rollar uchun sezgir maydonlarning nomlarini (yoki ularning taxallusini) UIda yashirish.
mTLS/OIDC uchun API; lineage voqealari servis identifikatsiyalari bilan imzolanadi.
WORM va o’qish nazorati: tanqidiy segmentlarni o’qish ham jurnalga solinadi.

16) Ekspluatatsiya: SLO, monitoring, alertlar

SLO grafa: hodisaning kechikishi <5 min; kritik payplaynlarni qoplashning to’liqligi> 98%; 100% «oltin metriklar» column-level lineage ga ega.
Alertlar: zanjirning uzilishi, tugash hodisalarisiz run, sxemalarning nomuvofiqligi, «yetim qolgan» datasetlar, fan-autning o’sishi/tsikllar.
Hisobotlar: haftalik «state of lineage coverage», top-10 ta xavfli uzel.

17) Maxfiylik va komplayens (bog’lamalar)

GDPR/PbD: ishlov berish va retensiya asoslarini teglar sifatida saqlash; lineage yo’llarni tez DSAR-qidirishni va tegishli segmentlarni kaskadli kripto-olib tashlash orqali «olib tashlash huquqini» ta’minlaydi.
Maxfiy menejment: xomashyodan foydalanish manbalari lineagga hech qachon ochiq kredd sifatida kirmaydi; faqat rol/siyosatga havola saqlanadi.
Audit/oʻzgarmas jurnallar: lineage barcha hodisalari append-only saqlash joyiga imzolangan va oʻrnatilgan (tegishli maqolaga qarang).

18) Chek varaqlari

• datasets/jobs/fields uchun URN kelishuvlari aniqlandi.
• Orkestratorlar va dvigatellardan lineage hodisalari chiqarildi.
• SQL/DDL parseri va sxemalar normalizatori ishlaydi.
• Data-contracts va PII/retentsiyalarni targ’ib qilish qoidalari tasdiqlandi.
• WORM hodisa jurnali va grafikning zaxira nusxalari sozlandi.
• BI/ML lineage (hisobotlar, modellar, chichlar) isteʼmolchilari sifatida ulangan.

• Kritik domenlar bo’yicha lineage ≥ 98%, column-level = 100%.
• «Yetim qolgan» datasetlar, dreyf sxemalari uchun alertlar kiritilgan.
• PII belgilari va kontraktlarning har choraklik auditi.
• O’zgarishlarning hujjat aylanishi (breaking) va iste’molchilarga yuborish.

19) Mini-retseptlar

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
}
]
}

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

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 xatolar va ulardan qanday qochish mumkin

Lineage «rasm bo’yicha» rasmiy modelsiz. Hodisa/sxema/URN kerak, aks holda grafik kattalashtirilmaydi.
«Pul» boʻlgan joyda column-level yoʻq. Ustunsiz hisob-kitoblarni tushuntirib boʻlmaydi.
To’liq bo’lmagan hodisalar (code_sha/versii sxemalarsiz). Takrorlash mumkin emas.
Maxfiylik ignori. PII belgilari dalalar bilan birga yashashi va ko’chirilishi kerak.
Bitta katta grafik shardingsiz DB. Nimspeyslarni bo’ling, snapshotlarni saqlang.
Parserlarga ko’r imon. Bahsli holatlarda - harakatlantiruvchi vositalarning faol voqealari.

21) Runbook’и

Hodisa: metrika «sakrab tushdi».

1. «Path to metric» ni ochish → Oxirgi’Run’tugunlarini yoʻlda tekshirish.
2. Kod/sxemalar versiyasini, qovurgʻalardagi cheklarning DQ holatini solishtirish.
3. Agar buzilgan boʻgʻin topilsa, egasiga «hold» vaqtinchalik metrik maʼlumotni kiriting.
4. Fixdan keyin - RCAni belgilash va grafik tugunlari bilan bog’lash.

Manba sxemasini oʻzgartirish.

1. Downstream impaktini soʻrash.
2. Egalariga xabarnoma yuborish, migratsiya PRlarini yaratish.
3. Parallel’v _ next’ni koʻtarish, ikkala versiyani ham sunset sanasigacha ushlab turish.
4. ’v _ prev’ ni yopish, shartnomalar va lineage-grafalarni yangilash.

• «Privacy by Design (GDPR)»
• «PII-ma’lumotlarni tokenlashtirish»
• «Sirlar menejmenti»
• «Audit va o’zgarmas jurnallar»
• «At Rest/In Transit shifrlash»
• «Kalitlarni boshqarish va rotatsiya»