Pochodzenie danych

Rodowód

1) Czym jest rodowód i dlaczego jest potrzebny

Data Lineage jest formalnym zapisem "skąd pochodzą dane, jak zostały one przekształcone, gdzie i przez kogo zostały wykorzystane. "Rezultatem jest kierowany wykres zależności z atrybutami (czas, wersje, właściciele, transformacje, zasady dostępu, jakość), co sprawia, że system danych jest zrozumiały i audytowy.

• Przejrzystość mierników (finanse, produkt, ryzyko): "Dlaczego liczba X = 1234? ».
• Szybka analiza wpływu zmian (schemat/praca): „co złamie się, jeśli”....
• Zgodność i audyt (RODO/ISO/SOC): sprawdzalna ścieżka pola.
• Przyspieszenie wsiadania na pokład i zmniejszenie siły (wiedza samoobsługowa).
• Poprawa jakości: ukierunkowane kontrole, w których ryzyko jest wyższe.

2) Obszary zasięgu i poziomy szczegółowości

Poziom strumienia (rurociąg/praca): Które zadania/orkiestra tarła zbiory danych.
Poziom zbioru danych (tabela/widok/temat/plik): wejścia → wyjścia, wersje/migawki.
Column/feature-level - jak oblicza się każde pole, z którego źródła.
Warstwa zużycia: raporty BI, interfejsy API, modele ML, deski rozdzielcze i wpisy.

W przypadku podmiotów krytycznych (pieniądze, regulacje) wymagana jest szczegółowość na poziomie kolumn.

3) Model danych Lineage - kluczowe podmioty

Zestaw danych: '{urn, type, schemat, właściciele, pii_class, retencja, tagi}'

Zadanie: '{urn, code_ref, wersja, czas trwania, harmonogram, właściciele}'

Run/Execution: '{run _ id, job_urn, start/end, status, inputs [], outputs [], code_sha, infra}'

Pole: '{dataset _ urn, name, type, derivation}' (pochodna - expression/AST/operator).

Polityka: '{dataset _ urn/field, access_rules, masking, consent_scope}'

Kontrola jakości: '{check _ id, scope, rule, severity, result}'

4) Źródła rodowodowe: aktywny zespół pasywny vs

Aktywne (na bazie zdarzeń): orkiestratory/silniki instrumentalne (silniki Spark/DBT/SQL/Kafka) do wydawania wydarzeń „job started/finished, inputs/outputs, column-mapping”.

Plusy: dokładność, znaczenie, minimalizacja postparsing.
Pasywne (wnioskowanie): DAG parsim, żądania SQL/DDL/log, katalog/dzienniki pamięci masowej; budować zależności z mocą wsteczną.

Plusy: szybkie objęcie dziedzictwem; minus: niższa dokładność na poziomie kolumny.

Zazwyczaj stosuje się hybrydę: aktywne zdarzenia tam, gdzie to możliwe, oraz bierną analizę jako „siatkę ubezpieczeniową”.

5) Architektura rozwiązań (odniesienie)

Producenci (orkiestry/silniki) → Autobus Lineage event → Normalizator → Przechowywanie wykresu → Indeks/wyszukiwanie → UI/API/alerty → Eksport/katalog.

Zdarzenia: ujednolicone (job/run/dataset/column-lineage), z URN i wersjami semantycznymi.
Przechowywanie wykresu: wykres na poziomie kolumny (na przykład na podstawie bazy danych wykresu lub indeksu relacyjnego + odwróconego).
Interfejs użytkownika: interaktywna wizualizacja najkrótszych ścieżek, uderzenie/przyczyna, „sygnały jakości” na krawędziach i węzłach.
Integracje: katalog danych, system jakości (DQ), kontrola dostępu (ABAC), audyt (dzienniki tylko do dodatku).

6) Identyfikatory i wersioning

URN/Global ID dla każdego zbioru danych/zadań/pól: stabilny, czytelny dla ludzi, w tym dla platformy/przestrzeni nazw/nazwy/wersji.
SchemaVersion i wersja kodowa (kod SHA, trawienie obrazu).
Rodowód w czasie podróży: powtarzalność dochodzeń.

7) Rodowód na poziomie kolumn: jak uzyskać niezawodność

SQL parsing z budową AspAT i normalizacją pseudonimów/CTE/blizzard.
Adnotacje w kodzie transformacji (testy DBT, komentarze prymitywne, metadane UDF).

Zdarzenia z silników: określenie "cel. col = f (src. a, src. b) "

Zasady semantyczne: UDF/agregacje są oznaczone jako „lossy” (z utratą ziarnistości) lub „sensitive-preserving” (transfery znaczników PII).

8) Powiązanie lineage z prywatnością i bezpieczeństwem

Prywatność według projektu: etykiety polowe „pii _ class”, „consent _ scope”, „retention”. Podczas promowania kolumn etykiety są przesyłane zgodnie z zasadami (na przykład, 'email → hash_email' PII-derived remains).
tokenizacja PII: sklepy lineage tokenizacja/detokenizacja faktu i węzły usługi token; każda detokenizacja jest wydarzeniem audytu.
Szyfrowanie: dla pól AEAD/FPE, rodowód przechwytuje „stan krypto” i obszar kluczowy (najemca/zakres) - bez ujawniania kluczowych informacji.
Audyt i WORM - zdarzenia lineage i zmiany zasad są przechowywane w niezmodyfikowalnym dzienniku (tylko dodatek z łańcuchami hash).

9) Jakość danych i oparte na lineage SLO

Kontrole krawędzi: świeżość, kompletność, wyjątkowość/klucze, dryf rozkładu.
SLO/SLI: „95% miejsc pracy karmiących mierniki raportu finalnego ukończone ≤ 06:00 UTC”.
Przyczyna: wykres + czasy wykonania dają szybką definicję „pierwszego złamanego węzła”.

10) Analiza skutków i zarządzanie zmianami

W przypadku planowanej zmiany schematu/logiki: przez kolumnę poniżej (poniżej) - listę dotkniętych raportów/modeli/klientów API.
Polityka dotycząca przełamywania zmian: obowiązkowe powiadamianie właścicieli artefaktów znajdujących się poniżej, okres karencji, wersje równoległe („v1 ”/„ v2”) oraz flaga daty zachodu słońca.
Automatyczne PR/bilety z listą konsumentów i listą kontrolną migracji.

11) Integracja z orkiestratorami i silnikami

Orkiestratorzy: imprezy „RunStarted/Run Completed” z wejściami/wyjściami są emitowane przed/po wykonaniu zadania.
SQL/ELT: złącza do silników (magazyn, lakehouse) w celu uzyskania rzeczywistego planu wykonania i mapowania kolumn.
Przetwarzanie strumieniowe: rodowód wiadomości (temat → temat, klucz/nagłówek), Avro/Protobuf schematy, ewolucja systemów poprzez rejestr.
ML: funkcje lineage/zbiory danych, wersje modelowe, artefakty treningowe, źródła funkcji.

12) Modelowanie zasad rozpowszechniania etykiet (umowy o dane)

Umowa zbioru danych: schemat + semantyka terenowa (klucze, PII, agregacja, licencje/podstawy prawne, zatrzymanie).

• 'WYBIERZ a, b z T' → przesuń etykiety'a, b '.
• „hash (e-mail)” → etykieta „PII-derived (pseudonimized)” z zakazem detokenizacji.
• „suma (kwota)” → utrata indywidualności; join's nie są dozwolone w polu wyników.
• Umowy są zatwierdzane w CI (bloker w przypadku niezgodności), a naruszenia są zdarzeniami w audycie.

13) Wydajność i skala

Stopniowe wtryskiwanie zdarzeń rodowodowych; deduplikowanie przez '(run_id, job_urn)'.
Przechowywanie kolumn: oddzielenie gorącego indeksu (ostatnie 30-90 dni) i archiwum; migawki.
Buforowanie ścieżek dla częstych zapytań (krótkie ścieżki do „złotych” metryk).
Shading przez neimspaces/najemców; ochrona przed „węzłami potwornymi” (ograniczenie wentylacji).

14) Wizualizacja i UX

• Ścieżka do metryki: „z której zmontowana jest metryka”.
• Wpływ ze źródła: „kto będzie dotknięty zmianą”.
• Linia pola: „jak oblicza się pole”.
• Nakładki: statusy pracy, jakość, znaczniki PII, retencje, właściciele.
• Akcje: otwórz umowę, utwórz bilet na migrację, zapisz się do zmiany wpisów.

15) Bezpieczeństwo dostępu do wykresu

ABAC: Widoczność węzła/krawędzi jest ograniczona do lokatorów/ról.
Redakcja: ukrywanie wrażliwych nazw pól (lub ich aliasowanie) w interfejsie użytkownika w odniesieniu do niewyszkolonych ról.
mTLS/OIDC dla zdarzeń lineage API są podpisywane z identycznymi usługami.
WORM i kontrola odczytu: czytanie krytycznych segmentów wykresu jest również rejestrowane.

16) Działanie: SLO, monitoring, alerty

Wykres SLO: opóźnienie zdarzenia <5 min; kompletność pokrycia> 98% rurociągów krytycznych; 100% „złotych metryk” ma linię na poziomie kolumn.
Wpisy: break chain, run without completion events, niespójne schematy, osierocone zbiory danych, fan out growth/cycles.
Raporty: tygodniowy „stan pokrycia linii”, top 10 węzłów ryzyka.

17) Prywatność i zgodność (pakiety)

RODO/PbD: podstawy przetwarzania i retencji magazynu jako znaczniki; lineage zapewnia szybkie DSAR pathfinding i „prawo do usunięcia” poprzez kaskadowe usunięcie krypto odpowiednich segmentów.
Tajne zarządzanie: źródła dostępu do surowców nigdy nie wpadają w rodowód jako otwarte kredyty; przechowuje się tylko odniesienie do roli/polityki.
Audyt/niezmodyfikowane dzienniki - wszystkie zdarzenia związane z lineage są podpisywane i przypinane do repozytorium tylko w dodatku (patrz odpowiedni artykuł).

18) Listy kontrolne

• Umowy URN zdefiniowane dla zbiorów danych/miejsc pracy/pól.
• Umożliwiona emisja imprez lineage z orkiestry i silników.
• Parser SQL/DDL i normalizator schematu.
• Zatwierdza się przepisy dotyczące kontraktów na dane i PII/propagacji retencji.
• Skonfigurowany dziennik zdarzeń WORM i kopie zapasowe wykresu.
• BI/ML są połączone jako konsumenci linii (raporty, modele, funkcje).

• Pokrycie linii dla domen krytycznych ≥ 98%, poziom kolumny dla „pieniędzy” = 100%.
• Włączone są wpisy dotyczące przerw, osieroconych zbiorów danych, dryfów obwodów.
• Kwartalne audyty znaczników i umów PII.
• Przepływ dokumentów zmian (łamanie) i dystrybucja do konsumentów.

19) Mini przepisy kulinarne

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) Częste błędy i jak ich uniknąć

Rodowód „na zdjęciu” bez formalnego modelu. Potrzebne są zdarzenia/schematy/URN, w przeciwnym razie wykres nie jest skalowany.
Nie ma poziomu kolumn, gdzie jest "pieniądze. "Obliczeń nie można wyjaśnić bez poziomu kolumny.
Niekompletne zdarzenia (bez schematów code_sha/versii). Odtwarzalność nie jest możliwa.
Ignoruj prywatność. Tagi PII muszą żyć i być przenoszone z polami.
Jedna duża baza wykresów bez strzyżenia. Podziel według przestrzeni nazw, przechowywać migawki.
Ślepa wiara w parserów. W kontrowersyjnych przypadkach - aktywne zdarzenia z silników.

21) Runbook 'а

Incydent: Metryczny „skoczył”.

1. Otwórz „Ścieżka do metryki” → sprawdź ostatnie węzły 'Run' na ścieżce.
2. Sprawdź wersje kodu/schematu, sprawdź stan DQ na krawędziach.
3. Jeśli złamany link zostanie znaleziony, utwórz bilet dla właściciela, włącz tymczasowe „trzymaj” publikacji metrycznej.
4. Po ustaleniu - zaznaczyć RCA i skojarzyć z węzłami wykresu.

Modyfikacja schematu źródłowego.

1. Poproś o następne uderzenie.
2. Wyślij powiadomienia do właścicieli, utwórz migrację PRS.
3. Podnieś równoległe 'v _ next', zachowaj obie wersje do zachodu.
4. Zamknij 'v _ em', zaktualizuj kontrakty i wykres linii.

• „Prywatność według projektu (RODO)”
• „Tokenizacja danych PII”
• „Tajne zarządzanie”
• „Audyt i niezmienne kłody”
• „W odpoczynku/w tranzycie szyfrowanie”
• „Kluczowe zarządzanie i rotacja”