Маалыматтардын келип чыгышы

Маалыматтардын келип чыгышы (Lineage)

1) Сызык деген эмне жана эмне үчүн керек

Data Lineage - бул формалдуу жазуу "маалыматтар кайдан келген, алар кантип трансформацияланган, кайда жана ким тарабынан колдонулган". Натыйжасы - берилиштер системасын түшүнүктүү жана аудитордук кылган атрибуттары (убакыт, версиялар, ээлери, трансформациялар, жеткиликтүүлүк саясаты, сапат) менен багытталган көз карандылык графикасы.

• Метриктердин ачыктыгы (каржы, продукт, тобокелдик): "эмне үчүн саны X = 1 234? ».
• Тез импакт-талдоо өзгөрүүлөр (схема/JOB): "Эгер эмне бузулат"....
• шайкештик жана аудит (GDPR/ISO/SOC): далилденген талаа жолу.
• Онбординг тездетүү жана toil азайтуу (өзүн-өзү тейлөө билим).
• Сапатты жакшыртуу: тобокелдик жогору болгон жерде максаттуу текшерүү.

2) камтуу жана деталдаштыруу деңгээл

Агымы деңгээл (pipeline/job): кандай Jobs/Оркестр Datasets төрөлгөн.
dataset деңгээл (table/view/topic/file): кириштер → чыгуулар, версиялар/snapshots.
Мамычалык деңгээл (column/feature-level): кандай ар бир талаа эсептелген, кайсы булак.
Керектөө катмары: BI отчеттор, API, ML моделдер, dashboard жана эскертүү.

Критикалык нерселер үчүн (акча, жөнгө салуучу) - милдеттүү түрдө column-level деталдаштыруу.

3) Data lineage модели: негизги жактары

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/оператор).

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

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

4) lineage булактары: активдүү VS пассивдүү чогултуу

Активдүү (event-based): иш-чараларды чыгаруу үчүн аспаптык оркестраторлор/кыймылдаткычтар (Spark/DBT/SQL engines/Kafka) "job started/finished, inputs/outputs, column-mapping".

Артыкчылыктары: тактык, актуалдуулук, пост-парсинг минималдаштыруу.
Пассивдүү (inference): DAG 'i парсим, SQL/DDL/лог-суроолор, каталогдордун/сактагычтардын логдору; биз көз карандылыкты ретроактивдүү куруп жатабыз.

Артыкчылыктары: мурасты тез камтуу; кемчиликтери: төмөнкү тактык боюнча column-деңгээл.

Адатта, гибрид колдонулат: мүмкүн болгон жерде активдүү окуялар, жана пассивдүү талдоо катары "камсыздандыруу тор".

5) Архитектуралык чечим (эталон)

Producers (Оркестр/кыймылдаткычтар) → Shine окуялар lineage → Нормалдаштыргыч → Count сактоо → Индекс/издөө → UI/API/alerty → Экспорт/каталог.

Окуялар: бирдиктүү (job/run/dataset/column-lineage), URN идентификаторлору жана семантикалык версиялары менен.
Graph сактоо: column-level graph (мисалы, graph DD же реляциялык + inverted index негизинде).
UI: кыска жолдорду интерактивдүү визуалдаштыруу, импакт/тамыр-себеп, кабырга жана түйүндөрдө "сапат сигналдары".
Интеграциялар: маалымат каталогу, сапат системасы (DQ), жеткиликтүүлүктү башкаруу (ABAC), аудит (append-only журналдар).

6) Идентификаторлор жана версиялоо

URN/Global ID ар бир dataset/jobs/талаалар үчүн: туруктуу, адам окуй турган, анын ичинде платформа/Name/Name/Version.
Схемалардын версиялары (SchemaVersion) жана коддун версиялары (code SHA, image digest).
Убакыт боюнча сүрөттөр (time-travel lineage): тергөөнүн кайталанышы.

7) Column-level lineage: кантип ишенимдүү алуу керек

AST куруу менен SQL-парсинг жана нормалдаштыруу Alias/STE/жип.
Трансформация кодундагы аннотациялар (DBT tests, comments-primitives, UDF-metadata).
Кыймылдаткычтардагы окуялар: "target. col = f(src. a, src. b)».
Семантикалык эрежелер: UDF/агрегаттоо опстары "lossy" (гранулярдуулугун жоготуу менен) же "sensitive-preserving" (PII белгилерин которуу) деп белгиленет.

8) lineage купуялык жана коопсуздук менен байланыш

Privacy by Design: 'pii _ class', 'consent _ scope', 'retention' талааларынын белгилери. Тилкелерди пропагандалоодо белгилер эрежелер боюнча берилет (мисалы, 'email → hash_email' PII-derived бойдон калат).
PII токенизациясы: lineage токенизациялоо/детокенизациялоо фактысын жана токен кызматынын түйүндөрүн сактайт; ар кандай детокенизация - аудит менен окуя.
Шифрлөө: AEAD/FPE lineage талаалары үчүн "крипто абалын" жана негизги аймакты (tenant/scope) - ачкычтарды ачпастан бекитет.
Аудит жана WORM: lineage окуялары жана саясаттагы өзгөрүүлөр өзгөрүлбөс журналда (хэш-чынжырлар менен append-only) сакталат.

9) Маалымат сапаты жана SLO lineage негизинде

Кабыргалар боюнча чектер: сергектик (freshness), толуктугу (completeness), уникалдуулук/ачкычтар, бөлүштүрүү drift.
SLO/SLI: "95% JOB азыктандыруучу эсептөө метрика, 06:00 UTC ≤ аяктады".
Root-cause: Count + аткаруу убактысы тез аныктама берет "биринчи сынган түйүн".

10) Импакт-талдоо жана өзгөрүүлөрдү башкаруу

Схеманы/логиканы пландуу өзгөртүүдө: төмөнкү агым боюнча графа (downstream) - таасир этүүчү отчеттордун/моделдердин/API кардарларынын тизмеси.
"breaking changes" саясаты: downstream-артефакттар, grace-мезгили, параллелдүү версиялар ('v1 '/' v2') жана "sunset-date" желеги ээлерине милдеттүү билдирүү.
Керектөөчүлөрдүн тизмеси жана миграциялык чек баракчасы менен автоматтык PR/билеттер.

11) Оркестр жана кыймылдаткычтар менен бириктирүү

Orchestrators: job алдында/кийин окуялар чыгарылат 'RunStarted/RunCompleted' менен inputs/outputs.
SQL/ELT: иш жүзүндөгү аткаруу планын алуу үчүн кыймылдаткычтарга (warehouse, lakehouse) туташтыргычтар жана мамычалар.
Stream-processing: lineage билдирүүлөр (topic → topic, key/headers), Euro/Protobuf схемалар, registry аркылуу схемалардын эволюциясы.
ML: сызыктар/datacets, моделдин нускалары, машыгуу артефакттары, белгилердин булактары.

12) этикеткаларды пропагандалоо эрежелерин моделдөө (data contracts)

Маалыматтар топтомунун келишими: схема + талаалардын семантикасы (ачкычтар, PII, агрегаттуулук, лицензиялар/укуктук негиздер, retention).

• 'SELECT a, b FROM T' → 'a, b' белгилерин жылдыруу.
• 'hash (email)' → теги 'PII-derived (pseudonymized)' детокенизациялоого тыюу салуу менен.
• 'SUM (amount)' → инсандыгын жоготуу; натыйжа талаасында join's тыюу салынган.
• Контракттар CI менен тастыкталат (дал келбеген учурда blocker), ал эми мыйзам бузуулар - аудит окуялар.

13) аткаруу жана масштабы

Инкременталдык инжестия окуялар lineage; '(run_id, job_urn)' боюнча дедупликация.
Сактоо Graph: ысык индекси (акыркы 30-90 күн) жана архив бөлүштүрүү; снапшоттор.
Көп суроо үчүн жолдорду кэш ("алтын" метрикага кыска жолдор).
Неймспейс/ижарачылар боюнча шардинг; "желмогуз түйүндөрүнөн" коргоо (фан-аута чектөө).

14) Көрүү жана UX

• Path to metric: "Метрика чогултулган".
• Impact from source: "өзгөртүү таасир этет".
• Field lineage: "талаа кантип эсептелет".
• Overlay: JOB статусу, сапаты, PII-белгилер, retents, ээлери.
• Иш-аракеттер: келишим ачуу, миграциялык билет түзүү, өзгөрүүлөрдүн алерттерине жазылуу.

15) Графага кирүү коопсуздугу

ABAC: түйүндөрдүн/кабыргалардын көрүнүшү ижарачылар/ролдор менен чектелет.
Redaction: даярдалбаган ролдор үчүн UI сезгич талаалардын аттарын жашыруу (же алардын псевдонимдештирүү).
mTLS/OIDC үчүн API; lineage окуялары кызматтык иденттүүлүк менен кол коюлат.
WORM жана окуу контролдоо: критикалык сегменттерин окуу да жазылган.

16) Иштетүү: SLO, мониторинг, Алерт

SLO тилкеси: <5 мин окуя пайда кечигүү; камтуунун толуктугу> 98% критикалык пайплайндар; 100% "алтын метр" column-level сызык бар.
Алерталар: чынжырдын үзүлүшү, бүтүрүү окуялары жок чуркоо, схемалардын ыраатсыздыгы, "жетим" датасеттер, күйөрман-аута/циклдердин өсүшү.
Отчеттор: жума сайын "state of lineage coverage", жогорку 10 тобокелдик түйүндөрү.

17) Купуялык жана комплаенс

GDPR/PbD: иштетүү негиздери жана Retenia теги катары сактоо; lineage жолдорун тез DSAR-издөө жана тиешелүү сегменттердин каскаддык крипто-алып салуу аркылуу "алып салуу укугун" камсыз кылат.
Secrets Management: чийки заттарга жетүү булактары lineage эч качан ачык кред катары түшпөйт; ролуна/саясатына шилтеме гана сакталат.
Аудит/өзгөрүлбөс журналдар: lineage бардык окуялар кол коюлган жана append-only сактоо (тиешелүү макаланы карагыла).

18) Чек баракчалары

• datasets/jobs/fields үчүн URN келишимдери аныкталган.
• Оркестрден жана кыймылдаткычтардан lineage окуяларынын эмиссиясы киргизилген.
• SQL/DDL Parser жана схемалар нормалдаштыргыч иштейт.
• data-contracts жана PII/retents үгүт эрежелери бекитилген.
• WORM окуялардын журналы жана резервдик графалар.
• BI/ML lineage керектөөчүлөрү катары туташтырылган (отчеттор, моделдер, чүчүкулак).

• Критикалык домендер боюнча lineage жабуу ≥ 98%, column-level "акча" = 100%.
• үзүлүшү боюнча Alerts, "жетим" datasets, схемалар Drift кирет.
• PII белгилеринин жана контракттардын чейректик аудити.
• Өзгөрүүлөрдүн документ жүгүртүүсү (breaking) жана керектөөчүлөргө жөнөтүү.

19) Mini Recipes

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) Көп каталар жана аларды алдын алуу үчүн кантип

Lineage "сүрөт боюнча" расмий модели жок. Бизге окуялар/схемалар/URN керек, антпесе граф масштабдалбайт.
Жок column-деңгээл кайда "акча". Мамычасыз эсептөөлөрдү түшүндүрүүгө болбойт.
Толук эмес окуялар (code_sha/версии схемалары жок). Ойнотуу мүмкүн эмес.
Privacy Ignor. PII белгилери жашоого жана талаалар менен бирге өткөрүлүп берилиши керек.
Бир чоң графикалык DD шардингсиз. Неймспейстерге бөлүңүз, снапшотторду сактаңыз.
Парсерлерге сокур ишеним. Талаштуу учурларда - кыймылдаткычтардагы активдүү окуялар.

21) Runbook’и

Окуя: метрика "секирип".

1. Ачуу "Path to metric" → жолдо акыркы 'Run' түйүндөрүн текшерүү.
2. Коддун/схемалардын версияларын, кабыргадагы DQ чектеринин статусун салыштыруу.
3. Эгерде сынган звено табылса - ээсине билет түзүү, убактылуу "hold" метрика жарыялоону күйгүзүү.
4. Фикстен кийин - RCA белгилөө жана графанын түйүндөрү менен байланыштыруу.

Булак схемасын өзгөртүү.

1. downstream импакт сурап.
2. ээлерине билдирүүлөрдү жөнөтүү, PR's миграция түзүү.
3. параллель 'v _ next' көтөрүп, sunset-датага чейин эки нускасын сактап.
4. 'v _ prev' жабуу, келишимдер жана lineage-тилкесин жаңыртуу.

• «Privacy by Design (GDPR)»
• "PII-маалыматтарды токендештирүү"
• "Сыр менеджменти"
• "Аудит жана өзгөрүлбөгөн журналдар"
• "On Rest/In Transit шифрлөө"
• "Ачкычтарды башкаруу жана ротация"