Bacarıqlı mühəndisləri olan hər təşkilat öz kataloqunu qurmağı düşünür və mülahizə irəli sürüldüyü anda əsaslıdır. Kataloq baza sxemlərini oxuyur və onları axtarıla bilən bir yerdə saxlayır. Yaxşı mühəndis iki həftəyə işlək versiya çıxarır. Kommersiya məhsulları isə bahadır və istəmədiyiniz funksiyalarla doludur.

Mülahizə tələb "cədvəl adlarına baxmaq üçün bir yer" olduğu müddətdə keçərlidir. Metadata anbarını idarəetmə platformasına çevirən dörd imkanda keçərli olmaqdan çıxır və onların hər biri təkbaşına çoxrüblük mühəndislik layihəsidir.

Bu yazı dürüst qərar vermək haqqındadır — qurmağın düzgün cavab olduğu hallar daxil olmaqla.

Birinci versiya nəyə başa gəlir və bu rəqəm niyə yanıldır

Bir mühəndisin iki həftəsi real bir şey istehsal edir: əsas bazanıza konnektor, toplanmış cədvəl və sütun metadata-sı, axtarış interfeysi, təsvir yazmaq üçün yer. O, işləyir, insanlar razı qalır və həqiqətən faydalıdır.

Rəqəm ona görə yanıldır ki, birinci versiya problemin ən ucuz 10%-idir. Qalan 90% eyni işin davamı deyil — dörd fərqli problemdir və heç biri ilk iki həftəyə oxşamır.

Qərarı həll edən dörd imkan

Sütun səviyyəli lineage. Cədvəl səviyyəli yox — sütun səviyyəli, SQL-dən, stored procedure-lardan və ETL təriflərindən parse edilmiş. Bu, sizin faktiki dialektlərinizi idarə edən, view-ları həll edən, müvəqqəti cədvəlləri stored procedure-lar boyu izləyən və dinamik SQL ilə bacaran SQL parser yazmaq və ya inteqrasiya etmək deməkdir. Bu, funksiya deyil; ixtisaslaşmış məhsul kateqoriyasıdır və hər qurma layihəsinin dəfələrlə az qiymətləndirdiyi yerdir. Tələbiniz yalnız cədvəl səviyyəli lineage-dirsə, qurmaq xeyli mümkündür — və bunun auditorunuzu qane edib-etmədiyi barədə dürüst olun. Adətən qane etmir; bax data lineage nədir.

Konnektor genişliyi və saxlanması. İlk üç konnektorunuz sadədir. İyirmincisi sabit enli düzülüşü olan və ümumiyyətlə metadata-sı olmayan mainframe ixracıdır. Sonra hər mənbə sistem öz cədvəli ilə yenilənir və hər yeniləmə artıq sizə aid olan baxım hadisəsidir. Kommersiya məhsulları bu xərci bütün müştəri bazası üzrə daşıyır; siz onu tək daşıyırsınız.

Giriş nəzarəti və iş axını. Metadata üzərində dəqiq icazələr, giriş sorğusu iş axını, təsdiq marşrutlaması və kimin nəyi gördüyünün auditi. Bu, adi müəssisə proqram təminatı işidir və həcmi ciddidir — nəzarət altındakı institutda isə atlanıla bilməz, çünki metadata anbarı özü həssasdır.

Mənimsəmə funksiyaları. Həqiqətən tapan axtarış, istifadə siqnalları, sorğu redaktorunda inline təriflər, aşağı axın sahiblərinə dəyişiklik bildirişləri. İnsanların müraciət etdiyi kataloqla insanların qarşılaşdığı kataloq arasındakı fərq budur və bütün proqramın qazancının əslində gəldiyi yer də budur. Eyni zamanda qurma layihəsində heç vaxt prioritetləşdirilməyən hissədir, çünki həmişə növbəti konnektordan az təcili görünür.

Dördü də lazımdırsa, qurmaq daxili alət deyil, məhsul inkişafı proqramıdır. Bunu on səkkiz ay sonra deyil, qərar verilən anda açıq deyin.

Dürüst üçillik müqayisə

Almaq lisenziya plus tətbiq plus platforma istismarı üçün mühəndisin bir hissəsinə başa gəlir. Əhatəsi müəyyən edilmiş sahə üçün tətbiq value platforma ilə həftələrlə, müəssisə paketi ilə rüblərlə ölçülür.

Qurmaq fasiləsiz iki-dörd mühəndisə başa gəlir — layihə üçün yox, daimi, çünki kataloq mənbələr yeniləndikcə sınan konnektorları olan canlı sistemdir. Üstünə həmin mühəndislərin əks halda çatdıracaqlarının alternativ xərcini və əsas adam riskini əlavə edin: kataloq onu yazan adamın mülkiyyətinə çevrilir, onun getməsi isə aktivi öhdəliyə çevirir.

Müqayisə adətən almağın xeyrinədir və fərq başlanğıcda göründüyündən genişdir, çünki qurma varyantı demək olar həmişə qeyri-müəyyən baxım öhdəliyi olan məhsul kimi deyil, layihə kimi qiymətləndirilir.

Adını çəkməyə dəyən üçüncü yol da var: açıq mənbəli bünövrələr. DataHub, OpenMetadata və Amundsen kimi layihələr storage, model və interfeys qatlarında ciddi başlanğıc verir. Bu, sıfırdan qurmaqdan həqiqətən ucuzdur. Pulsuz deyil — tətbiq, yeniləmələr, konnektor boşluqları, təhlükəsizlik inteqrasiyası və mənimsəmə funksiyaları sizin üzərinizdədir — və ən düzgün anlayış budur: birinci 40%-i alırsınız, qalanını qurursunuz.

Qurmaq nə vaxt düzgündür

İki hal, və onlar realdır.

Tələbləriniz həqiqətən dar və sabitdir. Altı sistem üçün axtarıla bilən texniki metadata lazımdır, cədvəl səviyyəli lineage kifayətdir, tənzimləyici lineage öhdəliyiniz yoxdur və boş tutumu olan mühəndisləriniz var. Qurun. Bu tələb üçün kommersiya kataloqu artıq xərcdir, baxım yükü isə əhatə kiçik olduğu üçün kiçikdir.

Heç bir məhsulun ödəmədiyi tələbiniz var. Heç kimin dəstəkləmədiyi mülkiyyət sistem, qeyri-adi təhlükəsizlik modeli, təşkilatınızın işləmə tərzində mərkəzi olan daxili platformaya inteqrasiya. Onda qurun — amma yalnız həqiqətən ödənilməmiş hissəni qurun və ətrafındakı hər şeyi yenidən yazmaq əvəzinə inteqrasiya edin.

Yaxşı səbəb olmayan şey: "biz bunu daha ucuz edə bilərik." Bu, birinci versiya üçün doğru, üçüncü il üçün yalandır və qərar əslində həmin fərqdə yaşayır.

Tənzimlənən Azərbaycan institutunda qurma qərarı

Üç yerli amil tarazlığı dəyişir — ikisi almağın, biri qurmağın xeyrinə.

Almağın xeyrinə: lineage öhdəliyi. Təqdim edilmiş rəqəmin necə hesablandığını soruşan nəzarətçiyə çəkilmiş yox, toplanmış sütun səviyyəli lineage lazımdır. Sizin Oracle dialektinizi, stored procedure-larınızı və legacy ETL-inizi idarə edən SQL parser qurmaq bütün bu qərarda ən böyük mühəndislik öhdəliyidir və yarı yolda tərk edilməsi ən çətin olanıdır.

Almağın xeyrinə: kadr bazarı. Azərbaycanda metadata infrastrukturu qurmuş mühəndislər çox deyil və iki müstəsna adamın qurduğu sistem onlar gedəndə dağılır. Yerli tətbiq imkanı olan kommersiya məhsulu buna qarşı real qorunmadır.

Qurmağın xeyrinə: tətbiq məhdudiyyəti. On-premise tətbiq edə bildiyiniz məhsullar ehtiyaclarınızı ödəmirsə, qurmaq eliminasiya yolu ilə cazibədar olur. Bu nəticəyə gəlməzdən əvvəl yoxlamağa dəyər — bir neçə kataloq on-premise-i birinci dərəcəli məhsul kimi tətbiq edir və sahə bulud bazarından dardır, amma boş deyil. Müqayisələr OvalEdge, Collibra və Alation və OvalEdge və Atlan yazılarındadır.

İki həftəyə necə qərar vermək

Müdafiə oluna bilən cavab istehsal edən qısa və ucuz proses.

Dörd imkanı yazın və həqiqətən hansına ehtiyacınız olduğunu işarələyin. Sütun səviyyəli lineage və giriş iş axını hər ikisi tələb olunursa, cavab demək olar mütləq "almaq"dır və dayana bilərsiniz.

Qurmağı layihə kimi deyil, məhsul kimi qiymətləndirin. Üç il, fasiləsiz kadr, konnektor baxımı və mənimsəmə funksiyaları. Onu lisenziya plus tətbiq plus mühəndisin bir hissəsi ilə müqayisə edin.

Ən çətin hissə üzərində iki həftəlik spike keçirin. Açıq mənbəli kataloqu ən pis legacy mənbəyinizə yönəldin və ondan sütun səviyyəli lineage çıxarmağa çalışın. Həmin iki həftədə öyrəndiyiniz hər şey istənilən həcmdə qiymətləndirmədən dəyərlidir və adətən bir istiqamətdə həlledici olur.

Sonra qərar verin və səbəbini yazın. On səkkiz aydan sonra kimsə soruşacaq və əsaslandırma nəticədən faydalıdır.

Əsas məqamlar

  • Kataloqun birinci versiyası ucuzdur və problemin təxminən 10%-ini təmsil edir. Qalan 90% dörd fərqli problemdir.
  • Sizin real SQL-inizdən parse edilmiş sütun səviyyəli lineage qurma layihələrini sındıran imkandır. Cədvəl səviyyəli lineage xeyli mümkündür və adətən auditoru qane etmir.
  • Qurmaq bir dəfə yox, daimi olaraq iki-dörd mühəndisə başa gəlir. Onu qeyri-müəyyən baxım öhdəliyi olan məhsul kimi qiymətləndirin.
  • Açıq mənbəli bünövrələr qanuni üçüncü yoldur — təxminən birinci 40%-i almaq və qalanını qurmaq.
  • Tələblər dar və sabit olanda, yaxud əsl tələb tətbiq edilə bilən heç bir məhsul tərəfindən ödənilməyəndə qurun.
  • Qərarı təxminlər cədvəli ilə deyil, ən pis legacy mənbəyinizə qarşı iki həftəlik spike ilə verin.

OvalEdge-i on-premise tətbiq edirik, idarəetmə qiymətləndirməmiz isə əvvəlcə estate-i xəritələyir — bu da adətən qərarı sadələşdirir. Əlaqəli oxu: data kataloqu nədir və metadata idarəetməsi.