OvalEdge artıq işlətdiyiniz sistemlərə qoşulan, onların metadata-sını crawl edən, sorğu tarixçəsindən və koddan sütun səviyyəli lineage quran və nəticəni business glossary, təsnifat və giriş iş axınları ilə birlikdə axtarıla bilən catalog kimi təqdim edən data catalog və governance platformasıdır. O, verilənlər bazası deyil və datanızı saxlamır.

Sonuncu cümlə qiymətləndirmə görüşlərində ən çox yanlış başa düşülən məqamdır, ona görə başqa hər şeydən əvvəl onu açmağa dəyər.

OvalEdge verilənlər bazasıdırmı?

Xeyr. OvalEdge metadata saxlayır — datanızın təsvirini, datanın özünü yox.

Konkret olaraq: cədvəl və sütun adları, tiplər, sətir sayları, profiling statistikası, sorğu şablonları, sahiblik, biznes tərifləri, təsnifatlar və lineage əlaqələri. Müştəri qeydlərinizi saxlamır. İstifadəçi «kredit qalığı» axtarıb sütunu tapanda OvalEdge ona bu sütunun hansı sistemdə yaşadığını, nə demək olduğunu, sahibinin kim olduğunu və girişi necə istəyəcəyini deyir. Real dəyərləri götürmək yenə mənbə sistemində, həmin sistemin giriş nəzarəti altında baş verir.

Bir şüurlu istisna var. Profiling — null nisbətlərinin, fərqli dəyər saylarının və paylanmaların hesablanması — datanı oxumağı tələb edir, önizləmə üçün nümunə götürmək isə kiçik nümunənin saxlanmasını. Hər ikisi konfiqurasiya olunur və data ilə davranış tələbləri sərt olan qurumlarda hər ikisi adətən həssas aktivlər üçün məhdudlaşdırılır və ya söndürülür. Bu konfiqurasiya qərarını audit zamanı kəşf etmək əvəzinə dizayn mərhələsində açıq şəkildə vermək lazımdır.

Praktiki nəticə: OvalEdge warehouse-unuzu, lake-inizi və ya əməliyyat sistemlərinizi əvəz etmir. Onları təsvir edir. Təşkilata ümumiyyətlə niyə belə bir təsvir qatının lazım olduğu data catalog nədir məqaləsindədir.

Arxitektura necə görünür?

Dörd komponent, və bu bölgünü başa düşmək deployment söhbətini xeyli qısaldır.

Metadata repozitoriyası. Catalog-un özünü saxlayan relyasion baza — aktivlər, əlaqələr, glossary terminləri, təsnifatlar, lineage kənarları, audit qeydləri. Bu, hər hansı digəri kimi işlətdiyiniz və ehtiyatını çıxardığınız adi bazadır. On-premise deployment-də sizin infrastrukturunuzda dayanır.

Crawler və konnektor qatı. Mənbə sistemlərinə müraciət edən, onların sistem kataloqlarını oxuyan və tapdığını repozitoriyaya yazan komponent. Crawler-lər qrafiklə işləyir və hər konnektor öz mənbəsinin metadata modelini bilir — Oracle-da sxemləri sadalamaq üsulu Hadoop klasterindən və ya S3-uyğun obyekt anbarından fərqlidir.

Tətbiq və axtarış qatı. İstifadəçilərin işlədiyi veb tətbiqi və tapılabilənliyi sürətli edən axtarış indeksi. Adoption-u məhz axtarışın keyfiyyəti müəyyən edir, çünki axtarıla bilməyən catalog açılmayan catalog-dur.

Lineage mühərriki. SQL-i, ETL təriflərini və sorğu jurnallarını parse edərək datanın aktivlər arasında necə hərəkət etdiyini çıxaran komponent. Arxasında ən çox mühəndislik dayanan və praktikada catalog-ları ən çox fərqləndirən hissə budur.

Deployment topologiyası bu bölgüdən çıxır: repozitoriya və tətbiq sizin işlətdiyinizdir; crawler-lərə hər mənbəyə şəbəkə yolu lazımdır; runtime-da heç nəyə çıxış internet marşrutu lazım deyil.

Crawler-lər əslində necə işləyir?

Crawler mənbəyə xidmət hesabı ilə qoşulur, onun metadata-sını sadalayır və nəticələri repozitoriyaya yazır. Praktikada vacib olan həmin xidmət hesabının nə edə bilməli olduğudur.

Əksər relyasion mənbələr üçün struktur metadata — sxemlər, cədvəllər, sütunlar, tiplər, məhdudiyyətlər — üçün sistem kataloquna oxu girişi kifayətdir. Profiling datanın özünə oxu girişi tələb edir. Sorğu jurnalına əsaslanan lineage isə mənbənin icra olunmuş ifadələri qeyd etdiyi yerə giriş tələb edir.

Hər təhlükəsizlik baxışında qalxan üç praktiki məqam:

İcazələr yalnız oxumaqdır. Crawler mənbə sistemlərinə yazmır. DBA-nın adətən verdiyi ilk sual budur və layihəni açan cavab da elə budur.

İstehsalat sistemlərində crawl qrafiki əhəmiyyətlidir. Böyük mühitin tam crawl-ı pulsuz deyil, profiling isə datanı oxuyur. Crawl-ları iş saatlarından kənara salmaq və profiling-i seçilmiş aktivlərlə məhdudlaşdırmaq optimallaşdırma yox, standart praktikadır.

Catalog-u aktual saxlayan artımlı (incremental) crawl-dır. Rübdə bir dəfə yenilənən catalog artıq dəyişmiş mühiti təsvir edir. Gündəlik artımlı crawl və həftəlik tam crawl geniş yayılmış şablondur, təzəlik sualını isə yayılmadan sonra yox, pilot mərhələsində həll etmək lazımdır — köhnəlmiş catalog catalog-ların ölməsinin ən çox rast gəlinən yoludur.

Konnektor inventarı adi korporativ mənbələri əhatə edir — relyasion bazalar, warehouse-lar, Hadoop və obyekt anbarı, BI alətləri, ETL platformaları və fayl sistemləri — dəqiq siyahı isə hər relizlə dəyişir.

[[TK: burada rəqəm dərc etməzdən əvvəl OvalEdge-in cari konnektor sayını və Yukon Labs layihələrində doğrulanmış konkret konnektorları — core banking sistemləri, 1C, SAP və yerli platformalar — təsdiqləyin.]]

Siyahı OvalEdge məhsul saytında saxlanılır, konnektorların sizin real mənbə versiyalarınıza qarşı doğrulanması isə istənilən tətbiqin birinci mərhələsidir, çünki versiya uyğunsuzluğu ən çox rast gəlinən erkən sürprizdir.

Lineage necə qurulur?

Üç mexanizm birlikdə işləyir və bu fərq istənilən catalog-u qiymətləndirəndə əhəmiyyət daşıyır.

SQL və ETL təriflərindən parse edilərək. View-lar, saxlanılan prosedurlar, ETL iş tərifləri və çevrilmə skriptləri datanın necə hərəkət etdiyini bəyan edir. Onları parse etmək kodun dediyinə uyğun lineage verir.

Sorğu tarixçəsindən çıxarılaraq. Mənbə sistemi icra olunmuş ifadələri jurnala yazırsa, həmin jurnallar real data hərəkətini üzə çıxarır — o cümlədən heç bir ETL tərifinin təsvir etmədiyi hərəkəti, məsələn daimi asılılığa çevrilmiş ad-hoc CREATE TABLE AS SELECT.

Əl ilə bəyan edilərək. Catalog-un müşahidə edə bilmədiyi sistemlərarası hərəkətlər üçün — ixrac olunub yenidən idxal edilən fayl, mühitdən kənarda işləyən proses — kənarı insan qeyd edir.

Bu qarışığın niyə əhəmiyyət daşıdığı budur: əsasən əl bəyanına söykənən catalog-lar birinci gün tam, altıncı ay səhv olan lineage verir. Lineage-i sənəd yox, canlı artefakt edən avtomatik çıxarışdır — məhz buna görə qiymətləndirmə zamanı ən sərt yoxlanmalı imkan budur və OvalEdge, Collibra və Alation müqayisəsi də vaxtının çoxunu burada keçirir.

Tənzimlənən qurumda tələb olunmalı standart cədvəl səviyyəli yox, sütun səviyyəli lineage-dir, çünki müfəttişin sualı cədvəl haqqında yox, konkret hesabat göstəricisi haqqındadır.

Hansı deployment modelləri var?

Üç model var və seçim adətən texniki yox, data rezidentliyi əsasında edilir.

On-premise. Repozitoriya, tətbiq və crawler-lər tamamilə sizin infrastrukturunuzda işləyir. Azərbaycanda banklar və dövlət qurumları üçün normal model budur; səbəbləri data rezidentliyi və şəxsi məlumat qanunu məqaləsindədir: şəxsi məlumat haqqında metadata özü də həssasdır və təkcə sütun adları qurumun nə saxladığı barədə çox şey deyə bilər.

Cloud. Vendor tərəfindən hostlanır; mühit onsuz da public cloud-dadırsa və rezidentlik icazə verirsə uyğundur.

Air-gapped. On-premise-in heç bir çıxış bağlantısı olmayan variantı. Bu işləyir, çünki runtime arxitekturasında heç nə internet girişi tələb etmir — crawler-lər daxili mənbələrlə danışır, tətbiq daxili istifadəçilərə xidmət edir. Air-gap-ın dəyişdiyi şey yenilənmə yoludur: relizlər və konnektor yenilikləri qurumun proqram təminatı üçün onsuz da işlətdiyi nəzarətli prosesdən artefakt kimi keçir və bu proses ilk yeniləmədə yox, başlanğıcda razılaşdırılmalıdır.

Buradakı nəzarət altındakı qurumlarda şablon belədir: on-premise, təsniflənmiş aktivlərdə məhdudlaşdırılmış profiling ilə — və buna ilk seminardan dizayn etməyə dəyər.

Giriş nəzarəti necə işləyir?

İki fərqli qat var və onları qarışdırmaq real problem doğurur.

Catalog-a giriş kimin metadata görəcəyini müəyyən edir: axtarışda hansı aktivlərin görünəcəyini, kimin glossary terminlərinin görünəcəyini, lineage-i kimin görə biləcəyini. Metadata avtomatik olaraq açıq deyil — bankda müəyyən cədvəllərin mövcudluğu və sütun quruluşu özü də məhdudlaşdırılmış məlumatdır.

Dataya giriş mənbə sisteminin qərarı olaraq qalır. OvalEdge sorğu iş axınını daşıya bilər — istifadəçi aktivi tapır, giriş istəyir, sorğu sahibə yönlənir, qərar qeyd olunur — amma verilmə mənbə sistemində icra olunur. Catalog audit artefaktını istehsal edir; ikinci avtorizasiya orqanına çevrilmir.

Müfəttişin istədiyi sübutu catalog məhz bu «istə və qeyd et» iş axınında istehsal edir və bu, nəzarət altında dayanıqlı olan yeddi təcrübədən biridir.

Tətbiq nə tələb edir?

İlk tətbiq adətən səkkiz-on iki həftə çəkir və forması sabitdir.

1–2-ci həftələr — kəşfiyyat və konnektor doğrulaması. Hansı sistemlər əhatədədir, hansı versiyalarda işləyir, hansı şəbəkə yolları var, təhlükəsizlik baxışı nə tələb edir. Sürprizlər bu mərhələdə üzə çıxır: dəstəklənməyən baza versiyası, sahibinin əhatədə olduğunu bilmədiyi sistem, marşrutu olmayan şəbəkə seqmenti.

3–4-cü həftələr — quraşdırma və ilk crawl. Repozitoriya və tətbiq qaldırılır, xidmət hesabları verilir, seçilmiş alt dəst üzrə ilk crawl-lar icra olunur. Bu mərhələnin nəticəsi doldurulmuş texniki catalog-dur — çox vaxt mühitin bir yerdə sadalandığını ilk dəfə burada görürlər.

5–6-cı həftələr — glossary və sahiblik. Biznes qatı: kritik data elementləri müəyyən olunur, terminlər təsdiqlənir, aktivlərə owner və steward təyin edilir. Layihə məhz bu mərhələdə uğur qazanır və ya uduzur, bu isə konfiqurasiya deyil, təşkilati işdir.

7–8-ci həftələr — təsnifat və lineage doğrulaması. Təsnifatlar tətbiq olunur, lineage məlum axınlara qarşı yoxlanılır — hesablanma yolu artıq bilinən bir hesabat seçin və qrafikin uyğun gəldiyini təsdiqləyin.

9–10-cu həftələr — iş axınları və adoption. Giriş sorğusu axınları, stewardship növbələri, axtarışın tənzimlənməsi və ilk analitik qrupunun gündəlik istifadəyə keçməsi.

11–12-ci həftələr — təhvil və ölçmə. İş ritmi qurulur, əhatə metriklərinin bazası götürülür.

Qorunmalı uğursuzluq forması budur: texniki mərhələlər əlçatan olduğu üçün bütün on iki həftəni onlara sərf etmək və sahibliyi sona saxlamaq. Sahibi olmayan texniki cəhətdən mükəmməl catalog data governance yetkinlik modelinin terminləri ilə 2-ci səviyyə artefaktıdır.

Sorğu mühərrikləri və AI ilə yanaşı harada dayanır?

Başa düşülməyə dəyən iki qonşuluq var.

Federativ sorğu mühərriki ilə. Catalog təsvir edir və idarə edir; Starburst kimi mühərrik isə datanı yerindən tərpətmədən mənbələr üzərində sorğu icra edir. Onlar eyni problemin fərqli yarılarını həll edir və yaxşı birləşir: catalog sütunun nə demək olduğunu və kimin görə biləcəyini deyir, mühərrik birləşməni icra edir. Heç biri digərini əvəz etmir.

Korporativ AI ilə. AI sistemi daxili datanı kontekst kimi çəkəndə catalog-un təsnifatı runtime girişinə çevrilir — assistentin nə göstərə biləcəyi altdakı aktivin necə təsnifləndiyindən və istifadəçinin kim olduğundan asılıdır. AI-ı kataloqlaşdırılmamış mühitdə işə salan təşkilatlar bunu gec kəşf edir; bu, Azərbaycanda korporativ AI məqaləsində təkrarlanan mövzudur.

Əsas məqamlar

  • OvalEdge datanı yox, metadata saxlayır. Profiling və nümunə götürmə konfiqurasiya olunan istisnalardır və hər ikisi həssas aktivlər üçün adətən məhdudlaşdırılır.
  • Dörd komponent: metadata repozitoriyası, crawler və konnektor qatı, tətbiq və axtarış, lineage mühərriki.
  • Crawler xidmət hesabları yalnız oxuyur; crawl-ları iş saatlarından kənara salın və profiling əhatəsini şüurlu seçin.
  • Lineage parse edilmiş SQL-dən, sorğu tarixçəsindən və əl bəyanından gəlir. Qiymətləndirmədə avtomatik payı ən sərt yoxlayın.
  • On-premise, cloud və air-gapped deployment-lər dəstəklənir; air-gap əsasən yenilənmə yolunu dəyişir və bu, əvvəlcədən razılaşdırılmalıdır.
  • Catalog girişi ilə data girişi ayrı qatlardır. Catalog sorğu axınını daşıyır və audit artefaktı istehsal edir; girişi yenə mənbə sistemi verir.
  • İlk tətbiq səkkiz-on iki həftə çəkir. Sahiblik işini texniki mərhələlərdən sonra yox, onlarla paralel aparın.

Yukon Labs OvalEdge-i Azərbaycanda on-premise, o cümlədən air-gapped mühitlərdə tətbiq edir. Adi başlanğıc nöqtəsi hazırlıq qiymətləndirməsidir, çünki qrafiki müəyyən edən konnektor doğrulaması və sahiblikdir. Regional çərçivə üçün Azərbaycanda data governance məqaləsinə baxın.