Деректердің шығу тегі

Деректердің шығу тегі (Lineage)

1) lineage дегеніміз не және ол не үшін қажет

Data Lineage - бұл «деректер қайдан келді, олар қалай өзгерді, қайда және кім пайдаланды» деген ресми жазба. Нәтижесі - деректер жүйесін түсіндірілетін және аудиттелетін атрибуттары (уақыты, нұсқасы, иелері, трансформациясы, қол жеткізу саясаты, сапасы) бар тәуелділіктің бағдарланған бағаны.

• Метриканың ашықтығы (қаржы, өнім, тәуекел): "неге X = 1 234 саны? ».
• Өзгерістердің жылдам импакт-талдауы (схема/джоб): «егер»...
• Сәйкестік және аудит (GDPR/ISO/SOC): өрістің дәлелденетін жолы.
• Онбордингті жеделдету және toil төмендету (білімге өздігінен қызмет көрсету).
• Сапаны жақсарту: тәуекел жоғары жерде мақсатты тексерулер.

2) Жабу салалары және нақтылау деңгейлері

Ағын деңгейі (pipeline/job): қандай джобтар/оркестраторлар датасеттерді туғызды.
Датасет деңгейі (table/view/topic/file): кірістер → шығулар, нұсқалар/снапшоттар.
Баған деңгейі (column/feature-level): әрбір өріс қалай есептелген, қандай бастапқы көздерден.
Тұтыну қабаты: BI, API есептері, ML модельдері, дашбордтар және құлақтандыру.

Сыни мәндер үшін (ақша, реттеуіш) - міндетті түрде column-level нақтылау.

3) 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): «job started/finished, inputs/outputs, column-mapping» оқиғаларын шығару үшін оркестраторларды/қозғалтқыштарды (Spark/DBT/SQL engines/Kafka) аспаптандырамыз.

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

Артықшылықтары: мұраны жылдам қамту; кемшіліктері: төмен дәлдік column-level.

Әдетте гибридті қолданады: мүмкіндігінше белсенді оқиғалар және «сақтандыру торы» ретінде пассивті талдау.

5) Шешім архитектурасы (эталон)

Producers (оркестраторлар/қозғалтқыштар) → Шина оқиғалар lineage → Нормализатор → Қойма бағаны → Индекс/іздеу → UI/API/алерта → Экспорт/каталог.

Оқиғалар: URN идентификаторлары және семантикалық нұсқалары бар біріздендірілген (job/run/dataset/column-lineage).
Баған қоймасы: column-level бағандары (мысалы, бағандық ДБ немесе реляциялық + inverted index негізінде).
UI: қысқа жолдарды интерактивті бейнелеу, импакт/тамыр-себеп, қабырғалар мен түйіндердегі «сапа сигналдары».
Интеграциялар: деректер каталогы, сапа жүйесі (DQ), кіруді басқару (ABAC), аудит (append-only журналдары).

6) Сәйкестендіргіштер және нұсқалау

Әрбір датасет/джобтар/өрістер үшін URN/Global ID: тұрақты, адам оқитын, платформаны/неймспейсті/атауды/нұсқаны қамтиды.
Схемалар нұсқасы (SchemaVersion) және код нұсқасы (code SHA, image digest).
Уақыт бойынша графаның түсірілімі (time-travel lineage): тергеудің қайталануы.

7) Column-level lineage: қалай дұрыс алуға болады

AST құру және алиастарды/СТЕ/вьюх қалыпқа келтіру арқылы SQL-парсинг.
Трансформация кодындағы аннотациялар (DBT tests, комменттер-примитивтер, 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), бірегейлігі/кілттері, бөлу дрейфі.
SLO/SLI: «Қаржылық есептің метрикасын қоректендіретін джобтың 95% -ы 06:00 UTC ≤ аяқталды».
Root-cause: баған + орындау уақыты «бірінші сынған тораптың» тез анықтамасын береді.

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: fiches/datacets lineage, модель нұсқалары, жаттығу артефактілері, белгілер көздері.

12) Таңбаларды насихаттау ережелерін модельдеу (data contracts)

Деректер жиынтығының келісімшарты: схема + өрістер семантикасы (кілттер, PII, агрегаттылық, лицензиялар/құқықтық негіздер, retention).

• 'SELECT a, b FROM T' → 'a, b' белгілерін жылжыту.
• 'hash (email)' → детокенизациялауға тыйым салынған 'PII-derived (pseudonymized)' белгісі.
• 'SUM (amount)' → жеке тұлғаны жоғалту; нәтиже өрісінде join 'дерге тыйым салынған.
• Келісімшарттар CI-де (сәйкессіздік кезінде blocker) валидацияланады, ал бұзушылықтар - аудитке оқиғалар.

13) Өнімділік және масштаб

Lineage оқиғаларының инкременталды инжестиясы; '(run_id, job_urn)' бойынша дедупликация.
Бағанды сақтау: ыстық индексті (соңғы 30-90 күн) және мұрағатты бөлу; снапшоттар.
Жиі сұраулар үшін жолдарды кэштеу («алтын» метрикаларға қысқа жолдар).
Неймспейстер/жалға алушылар бойынша шардинг; «монстр-тораптарынан» қорғану (фан-аутты шектеу).

14) Визуализация және UX

• Path to metric: «метрика неден жиналған».
• Impact from source: «өзгерту кімге әсер етеді».
• Field lineage: «өріс қалай есептелді».
• Оверлейлер: джоб мәртебесі, сапасы, PII-белгілері, ретенциясы, иелері.
• Іс-әрекеттер: келісімшарт ашу, көші-қонға арналған сертификат жасау, өзгерістер алаңына жазылу.

15) Бағанға қол жеткізу қауіпсіздігі

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

16) Пайдалану: SLO, мониторинг, алерта

SLO бағаны: оқиғаның пайда болуының кідіруі <5 мин; жабындының толықтығы> 98% сындарлы пайплайндар; 100% «алтын метриктерде» column-level lineage бар.
Алерттар: тізбектің үзілуі, аяқталу оқиғаларынсыз run, схемалардың келісілмеуі, «жетім» датасеттер, фан-аута/циклдердің өсуі.
Есептер: апталық «state of lineage coverage», топ-10 тәуекел торабы.

17) Жекелік және комплаенс (байламдар)

GDPR/PbD: өңдеу негіздерін және ретенцияны тегтер ретінде сақтау; lineage жолдарды жылдам DSAR іздеуді және тиісті сегменттерді каскадты крипто-жою арқылы «алып тастау құқығын» қамтамасыз етеді.
Құпия менеджменті: шикізатқа қол жеткізу көздері lineage-ге ешқашан ашық кред ретінде кірмейді; рөлге/саясатқа сілтеме ғана сақталады.
Аудит/өзгермейтін журналдар: lineage барлық оқиғаларына қол қойылады және append-only қоймасында бекітіледі (тиісті мақаланы қараңыз).

18) Чек парақтары

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

• Критикалық домендер бойынша lineage жабу ≥ 98%, «ақша» бойынша column-level = 100%.
• «Жетім» датасеттер, схемалардың дрейфі қосылған үзілістерге арналған алерттар.
• PII белгілерінің және келісімшарттардың тоқсан сайынғы аудиті.
• Өзгерістердің құжат айналымы (breaking) және тұтынушыларға тарату.

19) Шағын рецептер

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-level жоқ. Баған деңгейінсіз есептеулерді түсіндіруге болмайды.
Толық емес оқиғалар (code_sha/версии схемаларсыз). Ойнату мүмкін емес.
Құпиялылық белгісі. PII таңбалары өрістермен бірге тұруы және тасымалдануы тиіс.
Бір үлкен графалық ДБ шардингсіз. Неймспейстер бойынша бөліңіз, снапшоттарды сақтаңыз.
Парсердерге соқыр сенім. Даулы жағдайларда - қозғалтқыштардың белсенді оқиғалары.

21) Runbook’и

Оқиға: метрика «секірді».

1. «Path to metric» ашыңыз → жолдағы соңғы 'Run' түйіндерін тексеріңіз.
2. Код/схема нұсқаларын, қабырғалардағы DQ чектерінің күйін салыстыру.
3. Егер сынған сілтеме табылса - иесіне тикет жасау, уақытша «hold» метрика жарияланымын қосу.
4. Фикстен кейін - RCA-ны белгілеу және бағанды түйіндермен байланыстыру.

Көз схемасын өзгерту.

1. downstream импактісін сұрату.
2. Иелеріне хабарландыруларды жіберу, көші-қон PR 'терін құру.
3. Параллельді 'v _ next' көтеру, екі нұсқасын да sunset-күнге дейін ұстау.
4. 'v _ prev' дегенді жабу, келісімшарттар мен lineage-бағандарды жаңарту.

• «Privacy by Design (GDPR)»
• «PII-деректерді токендеу»
• «Құпия менеджменті»
• «Аудит және өзгермейтін журналдар»
• «At Rest/In Transit шифрлау»
• «Кілттерді басқару және ротация»