Data lineage hər data parçasının haradan gəldiyinin və yolda onunla nə baş verdiyinin qeydidir. Ən faydalı halında sütun səviyyəsində işləyir: bu hesabatdakı bu rəqəm həmin mənbə sistemlərindəki həmin konkret sütunlardan, bu transformasiyalardan keçərək, bu ardıcıllıqla yaranıb.

Əhəmiyyəti dar və praktikidir. Gec-tez səlahiyyəti olan kimsə — auditor, nəzarətçi, baş risk zabiti — bir rəqəmi göstərib onun necə hesablandığını soruşur. Əksər təşkilatda dürüst cavab dörd sistemdən, iki əl ilə uzlaşdırma addımından və konkret bir analitikin apardığı cədvəldən ibarət zəncirdir. Onu yenidən qurmaq günlər aparır və nəticə sübut yox, nağıldır.

Lineage həmin nağılı sistemlərin özündən yaradılmış izlənmiş yola çevirir. Nəzarət altındakı institutda bu çevrilmə idarəetmə proqramının ən müdafiə oluna bilən qazancıdır və biznes əsaslandırmasını qurarkən ondan başlamağa dəyər.

Üç səviyyə və niyə yalnız biri mübahisəni bitirir

Lineage üç dənəlikdə satılır və vendorlar demo-nun hansını göstərdiyi barədə həmişə dəqiq olmur.

Sistem səviyyəli lineage deyir ki, data core banking sistemindən anbara, oradan hesabat qatına axır. Onu hazırlamaq asandır, çəkmək asandır və demək olar heç nəyə cavab vermir. Bunu onsuz da hamı bilirdi.

Cədvəl səviyyəli lineage deyir ki, bu hesabat cədvəli həmin beş mənbə cədvəlindən qurulub. Kobud təsir qiymətləndirməsi üçün faydalıdır, audit sualı üçün yetərsizdir — çünki iki yüz sütunlu cədvəl mübahisəli rəqəmi hansının qidalandırdığını demir.

Sütun səviyyəli lineage deyir ki, bu hesabatdakı provision_amount sahəsi loan.principal_outstanding və risk_grade.pd_value sütunlarından konkret join və konkret case ifadəsi vasitəsilə alınıb. Auditorun həqiqətən verdiyi suala cavab verən yeganə səviyyə budur və pul ödəməyə dəyən yeganə səviyyə də budur.

Fərq vendor qiymətləndirməsində kəskin şəkildə üzə çıxır. Gözəl sistem səviyyəli diaqramlar və zəif sütun səviyyəli əhatə istehsal edən məhsul demo-da əks profilli məhsuldan yaxşı görünəcək və faktiki olaraq xeyli az dəyər daşıyacaq.

Lineage nəyə işlədilir

Xərci nə qədər tez-tez əsaslandırdığına görə azalan sıra ilə dörd istifadə ssenarisi.

Tənzimləyici sübut. Təqdim edilmiş rəqəmin necə alındığını tələb olunan anda, bir həftəlik hazırlıq olmadan göstərmək. Mərkəzi Bankın nəzarətindəki bankda əsas hərəkətverici budur və proqramı maliyyələşdirilə bilən edən ssenari də budur.

Dəyişiklikdən əvvəl impact analysis. Mühəndis sütunun tipini dəyişməyə və ya sahəni silməyə hazırlaşır. Lineage ona hansı on iki aşağı axın hesabatının sınacağını deyir. Onsuz cavabı on ikinci hesabatı istifadə edən adam istehsalatda kəşf edir.

Sınıqdan sonra root cause analysis. Rəqəm səhvdir. Lineage axtarışı bütün estate-dən onu yaradan konkret zəncirə qədər daraldır — iki günlük araşdırma iki saatlıq işə çevrilir.

Etibar. Rəqəmin haradan gəldiyini görə bilən analitik ondan istifadə edəcək. Görə bilməyən isə onu özü yenidən quracaq — təşkilatların eyni metrikin dörd versiyası ilə qalmasının səbəbi budur.

Lineage necə toplanır və hansı güzəştlərlə

Üç mexanizm, və real tətbiqlərin çoxu kombinasiya işlədir.

Kod parse etmə SQL-i, stored procedure-ları, ETL job təriflərini və view məntiqini oxuyur və sütun uyğunluqlarını statik şəkildə çıxarır. İşlədiyi yerdə ən tam metoddur, çünki nadir hallarda icra olunan yolları da daxil olmaqla nəzərdə tutulan məntiqi tutur. Eyni zamanda dinamik SQL-də, sətir birləşdirməklə qurulan sorğularda və mülkiyyət transformasiya dillərində sınan metod da budur.

Query log analizi həqiqətən nəyin işlədiyinə baxır. Kod parse etmənin buraxdığını tutur — ad hoc transformasiyalar, sənədləşdirilməmiş job-lar, analitikin çərşənbə axşamı skripti — və niyyəti yox, reallığı əks etdirir. Zəifliyi odur ki, yalnız müşahidə pəncərəsində icra olunmuş yolları tanıyır, yəni rüblük job üç ay boyunca görünmür.

Əl ilə elan — kiminsə interfeysdə əlaqəni özünün çəkməsi. İlk iki metodun çata bilmədiyi boşluqlar üçün lazımdır: departamentlər arasında e-poçtla göndərilən fayl, heç kimin parse edə bilmədiyi mainframe ixracı. Eyni zamanda köhnələn hissə də budur: əl ilə çəkilmiş lineage çəkildiyi həftə dəqiqdir və hər həftə bir az daha az dəqiq olur.

İşləyən proqram ilk ikini avtomatlaşdırır, əl ilə elanı yalnız əsl boşluqlar üçün saxlayır və əl ilə çəkilmiş kənarları interfeysdə görünən şəkildə işarələyir ki, heç kim iddianı sübutla qarışdırmasın.

Avtomatik lineage harada sınır

Bu barədə konkret olmaq vacibdir, çünki vendor demo-ları bunu heç vaxt göstərmir və hər real tətbiq bununla qarşılaşır.

Dinamik SQL. İcra zamanı sətirlərdən yığılan sorğu statik parse edilə bilməz. Query log analizi icraları tutur, onları birləşdirən məntiq isə qaranlıq qalır.

Nəzarət axını olan stored procedure-lar. Şaxələnmə, dövrələr və müvəqqəti cədvəllər sadə parser-ləri məğlub edir. Yaxşı məhsullar yayğın nümunələri idarə edir; heç biri hamısını yox.

Cədvəllər (Excel). Rəqəm sistemdən çıxır, Excel-də emal olunur və yükləmə kimi geri qayıdır. Bu, hər təşkilatda hər lineage zəncirini qırır və yeganə dürüst yanaşma boşluğu üstündən kənar çəkmək əvəzinə onu açıq işarələməkdir.

Ortaq metadata olmadan sistemlərarası ötürmə. Adlandırma konvensiyası paylaşmayan iki sistem arasında gecə fayl ötürməsi. Həmin sərhəddən keçən lineage yaxşı halda təxmindir.

Legacy və mainframe. COBOL copybook-ları, sabit enli ixraclar və job control language əksər müasir kataloqun əhatəsindən kənardadır. Azərbaycan banklarında və dövlət qurumlarında tənzimlənən datanı çox vaxt məhz bu sistemlər saxlayır — yəni lineage sualı ən çox əhəmiyyət daşıdığı yerdə ən çətindir.

Beşinin də düzgün cavabı eynidir: boşluğu ört-basdır etmək əvəzinə lineage qrafında təsvir edin. Cədvəl yerində dürüst qırığı olan zəncir auditor üçün səssizcə təxmin edən fasiləsiz zəncirdən daha faydalıdır.

Qiymətləndirmə zamanı lineage-i necə yoxlamalı

Demo-ların ən az məlumat verdiyi və məhsullar arasındakı fərqin ən böyük olduğu imkan budur, ona görə sistemli yanaşmağa dəyər.

Ən mürəkkəb üç real transformasiyanızı götürün — iç-içə view-ları, dinamik SQL-i və 2015-ci ildə kiminsə yazdığı stored procedure-u olanları. Hər vendordan proof of concept zamanı onlar üçün sütun səviyyəli lineage istehsal etməyi tələb edin — öz kodunuz üzərində, öz mühitinizdə. Nümunə data üzərində lineage qəbul etməyin; nümunə datanı vendor məhz parse olunduğu üçün seçib.

Sonra nəticə haqqında üç sual verin. Sona qədər sütun səviyyəlidirmi, yoxsa yarı yolda cədvəl səviyyəsinə enir? Toplanıb, yoxsa çəkilib? Və qrafik üzrə avtomatik yenidən yaradıla bilirmi ki, növbəti rübün sxem dəyişikliyindən sonra da doğru qalsın?

Məhsulları tez ayıran əlavə bir test: development mühitində sütunu dəyişin, yenidən toplayın və lineage-in insan müdaxiləsi olmadan yenilənib-yenilənmədiyinə baxın. Saxlanması üçün insan tələb edən lineage sənədləşdirmədir, sənədləşdirmə isə sürüşür.

Lineage və AI sistemləri

Daha yeni tələb, və təşkilatları hazırlıqsız yaxalayan tələb.

Dil modeli daxili datadan istifadə edərək suala cavab verəndə eyni audit sualı başqa formada gəlir: bu cavabı hansı sənədlər və hansı qeydlər yaradıb. Bu, retrieval pipeline-a tətbiq olunmuş lineage-dir və eyni münasibət tələb edir — sorğu anında tutulmuş, saxlanmış və aylar sonra bərpa oluna bilən.

Əks istiqamətdə də işləyir. Aİ AI Act üzrə yüksək riskli AI sistemləri təlim datasının keyfiyyəti, mənşəyi və sənədləşdirilməsi üzrə elə öhdəliklər daşıyır ki, təlim datasının haradan gəldiyini bilmədən onlara əməl etmək mümkün deyil. Hesabat rəqəmlərini izləyə bilməyən təşkilat təlim dəstlərini də izləyə bilməyəcək, çünki söhbət eyni çatışmayan imkandan gedir.

Bunun orkestrasiya tərəfi üçün AI orkestrasiyası nədir yazısına baxın.

Praktiki ardıcıllıq

Bütün estate üzrə lineage — yol boyu heç nə nümayiş etdirməyən çoxillik layihədir. Dəyəri erkən verən ardıcıllıq daha dardır.

Bir tənzimləyici hesabatdan başlayın. Onu qidalandıran hər aktiv üçün lineage-i uçdan-uca toplayın, boşluqlar daxil olmaqla. Əksər təşkilatda bu, proqram yox, dörd-altı həftəlik işdir və ondan sonrakı hər şeyi maliyyələşdirən artefaktı istehsal edir.

Onu həmin rəqəmə görə cavab verməli olan adamların gözü qarşısında nümayiş etdirin — CFO, risk rəhbəri, təqdimatı imzalayan kim varsa. Nəticə qraf deyil, nümayişin özüdür.

Sonra sistemləri əlifba sırası ilə əhatə etməklə deyil, hesabatların ardınca gedərək genişləndirin. Nəzarət təqdimatlarında və rəhbərlik qərarlarında görünən aktivlər səhv olmağın nəticə doğurduğu yerdir; qalan otuz min cədvəl gözləyə bilər.

Bütün bu müddət ərzində mənzərəni əl ilə tamamlamaq istəyinə müqavimət göstərin. 70%-i toplanmış və qalanı barədə dürüst olan lineage qrafı 100% tam və 30%-i iddia edilmiş qrafdan dəyərlidir, çünki ikincisi ciddi sual qarşısında dayana bilmir.

Əsas məqamlar

  • Auditorun verdiyi suala yalnız sütun səviyyəli lineage cavab verir. Sistem və cədvəl səviyyəsi demo-da yaxşı görünür, heç nəyi həll etmir.
  • Kod parse etmə plus query log analizi ilə toplayın; əl ilə elanı yalnız əsl boşluqlar üçün saxlayın və onu iddia kimi görünən şəkildə işarələyin.
  • Avtomatik lineage müntəzəm olaraq dinamik SQL-də, Excel-də, sistemlərarası fayl ötürmələrində və mainframe ixraclarında sınır. Üstündən təxmin etmək əvəzinə qırığı təsvir edin.
  • Öz ən pis transformasiya kodunuz üzərində, öz mühitinizdə yoxlayın — heç vaxt vendorun nümunə datası üzərində yox. Sonra qrafik üzrə insan müdaxiləsi olmadan yenidən yarandığını təsdiqləyin.
  • Eyni imkan artıq AI sistemləri üçün də tələb olunur — bu cavabı hansı qeydlər yaradıb və təlim datası haradan gəlib.
  • Bir tənzimləyici hesabatdan başlayın, uçdan-uca sübut edin və sxemin yox, hesabatların ardınca gedərək genişləndirin.

Avtomatik sütun səviyyəli lineage-i qiymətə görə ən güclü imkanı olan OvalEdge tətbiq edirik; alternativlərlə müqayisə OvalEdge, Collibra və Alation müqayisəsi yazısındadır. Daha geniş proqram üçün data governance nədir yazısına baxın.