მონაცემთა წარმოშობა

მონაცემთა წარმოშობა (Lineage)

1) რა არის ხაზი და რატომ არის ეს საჭირო

Data Lineage არის ოფიციალური ჩანაწერი „საიდან მოვიდა მონაცემები, თუ როგორ გარდაიქმნენ ისინი, სად და ვის იყენებდნენ“. შედეგი არის დამოკიდებულების ორიენტირებული გრაფიკი ატრიბუტებით (დრო, ვერსიები, მფლობელები, ტრანსფორმაციები, დაშვების პოლიტიკა, ხარისხი), რაც მონაცემთა სისტემას გასაგებად და აუდიტს ხდის.

• მეტრიკის გამჭვირვალობა (ფინანსები, პროდუქტი, რისკი): "რატომ არის ნომერი X = 1 234? ».
• ცვლილებების სწრაფი გავლენის ანალიზი (სქემა/ჯობი): „რა იშლება, თუ“....
• შესაბამისობა და აუდიტი (GDPR/ISO/SOC): ველის დადასტურებული გზა.
• Onboarding- ის დაჩქარება და toil- ის დაქვეითება (ცოდნის თვითდახმარება).
• ხარისხის გაუმჯობესება: მიზნობრივი შემოწმება, სადაც რისკი უფრო მაღალია.

2) დაფარვის სფეროები და დეტალების დონე

ნაკადის დონე (pipeline/job): რა ჯობებმა/ორკესტრებმა შექმნეს datasets.
Dataset- ის დონე (table/view/topic/file): შესასვლელი, გასასვლელი, ვერსიები/snaphots.
სვეტის დონე (column/feature-level): როგორ გამოითვლება თითოეული ველი, რომელი წყაროებიდან.
მოხმარების ფენა: მოხსენებები BI, API, ML მოდელები, დაშბორდები და სიგნალები.

კრიტიკული ერთეულებისთვის (ფული, მარეგულირებელი) - დეტალიზაცია სავალდებულოა.

3) ხაზის მონაცემთა მოდელი: ძირითადი ობიექტები

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

ველი: '{dataset _ urn, name, ტიპი, დერივაცია' (დერივაცია - გამოხატვა/AST/ოპერატორი).

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

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

4) ხაზის წყაროები: აქტიური პასიური ასამბლეა

აქტიური (ღონისძიება): ჩვენ ვაგზავნით ორკესტრებს/ძრავებს (Spark/DBT/SQL engines/Kafka) მოვლენების გამოსაცემად „job started/finished, inputs/outputs, column-mapping“.

დადებითი: სიზუსტე, აქტუალობა, პოსტ-პარსინგის მინიმიზაცია.
პასიური (inference): parsim DAG 'და, SQL/DDL/ლოგიკური მოთხოვნები, კატალოგების/საცავის ლოგოები; ჩვენ რეტროაქტიულად ვქმნით დამოკიდებულებებს.

დადებითი: სწრაფი მემკვიდრეობის გაშუქება; უარყოფითი: უფრო დაბალი სიზუსტე column-level.

ჩვეულებრივ გამოიყენება ჰიბრიდი: აქტიური მოვლენები, სადაც შესაძლებელია, და პასიური ანალიზი, როგორც „დაზღვევის ქსელი“.

5) გადაწყვეტილების არქიტექტურა (სტანდარტი)

Producters (ორკესტრები/ძრავები) - Lineage Shina - ნორმალიზატორი გრაფიკის საცავი ინდექსი/ძებნა UI/API/Alerta- ს ექსპორტი/კატალოგი.

მოვლენები: გაერთიანებული (job/run/dataset/column-lineage), URN იდენტიფიკატორებით და სემანტიკური ვერსიებით.
გრაფიკის საცავი: column-level გრაფიკი (მაგალითად, გრაფიკული მონაცემთა ბაზის საფუძველზე ან რელატიური + ინვერსიული ინდექსი).
UI: უმოკლეს ტრასების ინტერაქტიული ვიზუალიზაცია, გავლენის/ფესვის მიზეზი, „ხარისხის სიგნალები“ ნეკნებსა და კვანძებზე.
ინტეგრაცია: მონაცემთა კატალოგი, ხარისხის სისტემა (DQ), წვდომის მენეჯმენტი (ABAC), აუდიტი (append-only ჟურნალები).

6) იდენტიფიკატორები და ვერსიები

URN/Global ID თითოეული Dataset/Jobe/ველისთვის: სტაბილური, ადამიანური, მათ შორის პლატფორმა/ნეიმსპეისი/სახელი/ვერსია.
სქემების (SchemaVersion) და კოდის ვერსიები (code SHA, გამოსახულების ციფრი).
დროის გრაფიკის სურათები: გამოძიების რეპროდუქცია.

7) Column-level ხაზები: როგორ მიიღოთ საიმედოდ

SQL პარსინგი AST- ის მშენებლობით და ალიასის/STE/Book- ის ნორმალიზაციით.
ტრანსფორმაციის კოდში განთავსებული სურათები (DBT tests, პრიმიტიული კომენტარები, UDF-metadata).
მოვლენები ძრავებიდან: გამონათქვამების მითითება "target. col = f(src. a, src. b)».
სემანტიკური წესები: UDF/აგრეგაციის ოპერაციები აღინიშნება როგორც „lossy“ (მარცვლეულის დაკარგვით) ან „sensitive-preserving“ (მოითმენს PII ეტიკეტებს).

8) ხაზის კავშირი კონფიდენციალურობასთან და უსაფრთხოებასთან

Privacy by Design: ველების ეტიკეტები 'pii _ class', 'consent _ scope', 'retention'. სვეტების პროპაგანდისას, ეტიკეტები გადადის წესების შესაბამისად (მაგალითად, 'email' hash _ email 'რჩება PII-derived).
Tockenization PII: lineage ინახავს ტოკენიზაციის/დეტოკენიზაციის ფაქტს და ტოკენის სერვისის კვანძებს; ნებისმიერი დეტოქსიკაცია არის აუდიტის მოვლენა.
დაშიფვრა: AEAD/FPE ველებისთვის, ხაზს უსვამს „კრიპტო-მდგომარეობას“ და საკვანძო რეგიონს (tenant/scope) - გასაღებების გამჟღავნების გარეშე.
აუდიტი და WORM: ხაზის მოვლენები და პოლიტიკოსის ცვლილებები ინახება უცვლელი ჟურნალში (append-only მძიმე ჯაჭვებით).

9) მონაცემთა ხარისხი და SLO, რომელიც დაფუძნებულია ხაზზე

ჩეკები ნეკნებზე: სიახლე, სისრულე, უნიკალურობა/გასაღებები, განაწილების დრიფტი.
SLO/SLI: „ჯობების 95%, რომლებიც იკვებებიან finochet- ის მეტრიკებით, დასრულებულია 06:00 UTC“.
Root-cause: გრაფიკი + შესრულების დრო სწრაფად განსაზღვრავს „პირველი გატეხილი კვანძი“.

10) გავლენის ანალიზი და ცვლილების მენეჯმენტი

სქემის/ლოგიკის დაგეგმილი შეცვლისას: გრაფიკის მიხედვით, ნაკადი (downstream) არის API მომხმარებლების დაკავშირებული ანგარიშების/მოდელების/მოდელების/მომხმარებლების სია.
პოლიტიკა „breaking changes“: სავალდებულო შეტყობინება downstream არტეფაქტების მფლობელებისთვის, გრეის პერიოდი, პარალელური ვერსიები ('v1 '/' v2') და დროშა „sunset-date“.
ავტომატური PR/თიკეტები მომხმარებელთა სიით და მიგრაციის შემოწმების ფურცლით.

11) ინტეგრაცია ორკესტრებთან და ძრავებთან

Orchestrators: RunStarted/RunCompleted's inputs/outputs- ის მოვლენები გამოიცემა ადრე/შემდეგ.
SQL/ELT: ძრავების ოფისები (warehouse, lakehouse) სვეტების განხორციელებისა და გაშვების ფაქტობრივი გეგმის მისაღებად.
Stream-processing: lineage შეტყობინებები (topic-topic, key/headers), Avro/Protobuf სქემები, სქემების ევოლუცია რეგისტრის საშუალებით.
ML: ხაზის იხვები/თარიღები, მოდელის ვერსიები, ტრენინგის არტეფაქტები, ნიშნების წყაროები.

12) ეტიკეტების პროპაგანდის წესების მოდელირება

მონაცემთა ნაკრების ხელშეკრულება: სქემა + ველების სემანტიკა (გასაღებები, PII, აგრეგაცია, ლიცენზია/იურიდიული საფუძვლები, რეტენტიფიკაცია).

• 'SELECT a, b FROM T' - ს გადატანა ეტიკეტები 'a, b'.
• 'hash (email)' 'ეტიკეტი' PII-derived (pseudonymized) "დეტოქსიკაციის აკრძალვით.
• 'SUM (amount)' - პიროვნების დაკარგვა; შედეგის მოედანზე join's აკრძალულია.
• კონტრაქტები ძალაშია CI- ში (ბლოკერი შეუსაბამობის შემთხვევაში), ხოლო დარღვევები - მოვლენები აუდიტში.

13) პროდუქტიულობა და მასშტაბები

lineage მოვლენების სავარაუდო ინჟესტია; დედუპლიკაცია '(run _ id, job _ urn)'.
გრაფიკის შენახვა: ცხელი ინდექსის გამიჯვნა (ბოლო 30-90 დღე) და არქივი; Snaphots.
ხშირი მოთხოვნების ბილიკების დაგება (მოკლე გზები „ოქროს“ მეტრიკებისკენ).
Sharding neimespaces/მოიჯარეებისთვის; „მონსტრების კვანძებისგან“ დაცვა (გულშემატკივართა შეზღუდვა).

14) ვიზუალიზაცია და UX

• Path to metric: „საიდანაც შეგროვდა მეტრიკა“.
• Impact წყაროდან: „ვინ იმოქმედებს ცვლილებაზე“.
• ველი ხაზი: „როგორ გამოითვალა ველი“.
• ოვერლეი: ჯობ სტატუსები, ხარისხი, PII ეტიკეტები, რეტენსიები, მფლობელები.
• მოქმედებები: ხელშეკრულების გახსნა, მიგრაციის თიკეტის შექმნა, ცვლილებების ალერტებზე ხელმოწერა.

15) გრაფიკზე წვდომის უსაფრთხოება

ABAC: კვანძების/ნეკნების ხილვადობა შემოიფარგლება მხოლოდ მოიჯარეებით/როლებით.
Redaction: მგრძნობიარე ველების სახელების დამალვა UI- ში მოუმზადებელი როლებისთვის.
mTLS/OIDC API- სთვის; ხაზის მოვლენებს ხელს აწერენ მომსახურების იდენტურობა.
WORM და კითხვის კონტროლი: ასევე ხდება ჟურნალის კრიტიკული სეგმენტების წაკითხვა.

16) ოპერაცია: SLO, მონიტორინგი, ალერტები

SLO გრაფიკი: მოვლენის შეფერხება <5 წთ; დაფარვის სისრულე> კრიტიკული შეღავათების 98%; ოქროს მეტრიკის 100% -ს აქვს column-level ხაზები.
ალერტები: ჯაჭვის რღვევა, რუნი დასრულების გარეშე მოვლენების გარეშე, სქემების შეუსაბამობა, „ობოლი“ datasets, გულშემატკივართა დონის/ციკლის ზრდა.
მოხსენებები: ყოველკვირეული „ხაზის შეგროვების სახელმწიფო“, სარისკო კვანძების ტოპ 10.

17) კონფიდენციალურობა და შესაბამისობა (ლიგატები)

GDPR/PbD: შეინახეთ დამუშავების საფუძვლები და ჭდეები; lineage უზრუნველყოფს სწრაფი DSAR გზების ძიებას და შესაბამისი სეგმენტების კასკადის კრიპტო-მოცილების გზით „მოცილების უფლებას“.
საიდუმლოების მენეჯმენტი: ნედლეულის წვდომის წყაროები არასოდეს მოხვდებიან ხაზში, როგორც ღია კრედიტები; მხოლოდ როლის/პოლიტიკის ბმული ინახება.
აუდიტი/უცვლელი ჟურნალები: ყველა ხაზის მოვლენა გაფორმებულია და ფიქსირდება append-only საცავში (იხ. შესაბამისი სტატია).

18) ჩეკის ფურცლები

• განსაზღვრულია URN ხელშეკრულებები მონაცემთა/jobs/fields.
• ორკესტრებისა და ძრავების ხაზის მოვლენების ემისია.
• მუშაობს SQL/DDL პარსერი და სქემების ნორმალიზატორი.
• დამტკიცებულია მონაცემთა კონტრაქტები და PII/რეპრესიების პროპაგანდის წესები.
• შედგენილია WORM ღონისძიებების ჟურნალი და გრაფიკის სარეზერვო ასლები.
• BI/ML დაკავშირებულია, როგორც ხაზის მომხმარებლები (მოხსენებები, მოდელები, ფიჩები).

• ხაზის დაფარვა კრიტიკულ დომენებში 98%, კოლუმ-ლეველი „ფულით“ = 100%.
• ალერტები შესვენებებისთვის, „ობოლი“ Datasets, სქემების დრიფტი შედის.
• კვარტალური აუდიტი ეტიკეტებისა PII და კონტრაქტების შესახებ.
• ცვლილებების დოკუმენტების მენეჯმენტი და მომხმარებლებისთვის გაგზავნა.

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) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ხაზის „სურათზე“ ოფიციალური მოდელის გარეშე. ჩვენ გვჭირდება მოვლენები/სქემები/URN, წინააღმდეგ შემთხვევაში გრაფიკი არ არის მასშტაბური.
არ არსებობს column-level, სადაც არის „ფული“. სვეტის დონის გარეშე შეუძლებელია გამოთვლების ახსნა.
არასრული მოვლენები (სქემების code _ sha/ვერსიის გარეშე). რეპროდუქცია შეუძლებელია.
კონფიდენციალურობის უგულებელყოფა. ეტიკეტები PII უნდა ცხოვრობდეს და გადავიდეს მინდვრებთან ერთად.
ერთი დიდი გრაფიკული BD Sharding გარეშე. გააზიარეთ ნეიმსპასები, შეინახეთ sneaphots.
ბრმა რწმენა პარსერებისთვის. სადავო შემთხვევებში - აქტიური მოვლენები ძრავებიდან.

21) Runbook’и

ინციდენტი: მეტრიკა „გადახტა“.

1. გახსენით „Path to metric“ - ს, შეამოწმეთ ბოლო 'Run' კვანძები გზაზე.
2. კოდის/სქემების ვერსიების გადამოწმება, ზღვარზე DQ ჩეკების სტატუსი.
3. თუ ნაპოვნია გატეხილი ბმული, შექმენით თიკეტი მფლობელისთვის, ჩართეთ მეტრიკის დროებითი „hold“ პუბლიკაციები.
4. ფიქრის შემდეგ - აღინიშნოს RCA და დააკავშიროთ გრაფიკის კვანძებს.

წყაროს სქემის შეცვლა.

1. მოითხოვოს გავლენის downstream.
2. გაგზავნეთ შეტყობინებები მფლობელებს, შექმნათ PR მიგრაცია.
3. პარალელური „v _ next“ ამაღლება, ორივე ვერსიის შენახვა sunset თარიღამდე.
4. დახურეთ 'v _ prev', განაახლეთ კონტრაქტები და ხაზის გრაფიკი.

• «Privacy by Design (GDPR)»
• „PII მონაცემების ტოქსიკაცია“
• საიდუმლო მენეჯმენტი
• „აუდიტი და უცვლელი ჟურნალები“
• „დაშიფვრა At Rest/In Transit“
• „კლავიშების მართვა და როტაცია“