Müasir data platforması səkkiz qatdır: ingestion, açıq table format ilə storage, çevrilmə, sorğu və xidmət, semantik qat, catalog və governance, orchestration və observability, həmçinin AI və retrieval qatı. Arxitekturanın özü onları hansı ardıcıllıqla qurduğunuzdan və hansı qərarların sonradan geri qaytarıla biləcəyindən az əhəmiyyət daşıyır.
Bu məqalə Yukon Labs-ın korporativ layihələrdə istinad etdiyi arxitekturadır — bu bazarda tətbiq olunan on-premise məhdudiyyətləri sonradan əlavə edilmiş yox, içinə qurulmuş şəkildə.
Data platforması əslində nə etməlidir?
Qatlardan əvvəl dörd iş. Bunları edən platforma adekvatdır; onları zərif, amma yarımçıq edən platforma isə yox.
Datanı tapıla bilən etmək. İstifadəçi həmkarından soruşmadan dataset-in mövcud olduğunu kəşf edə, mənasını anlaya və sahibinin kim olduğunu öyrənə bilməlidir.
Layihəsiz sorğulana bilən etmək. Yeni suallar pipeline tələb etməməlidir. Tələb edəndə maraqlanmağın qiyməti zamanla artır və analitiklər soruşmağı dayandırır.
İdarə olunan etmək. Təsnifat, giriş nəzarəti və lineage bərabər tətbiq olunmalıdır ki, həssas sütun göründüyü hər qatda həssas qalsın.
Təkrarlana bilən etmək. Eyni sorğu sabah da eyni cavabı qaytarmalı və istənilən rəqəmin necə alındığını izah etmək mümkün olmalıdır.
Aşağıdakı hər qat bunlardan birinə və ya bir neçəsinə xidmət üçün var. Qat bunlardan heç birinə bağlana bilmirsə, adətən orada olmasının səbəbi vendorun onu satmasıdır.
Qat 1 — Ingestion
Üç ingestion rejimi var və müəssisələrin çoxuna hər üçü lazımdır. Səhv birində standartlaşmaqdır.
Batch çıxarış — başqa heç nəyi dəstəkləməyən sistemlər üçün: köhnə sistemlərdən gecə çıxarışları, fayl ötürmələri, üçüncü tərəf axınları. Dəbdə deyil və qurumların çoxunda həcmin böyük hissəsi hələ də budur.
Change data capture — analitik qatın mənbəni yoxlamadan cari vəziyyətə yaxın qalmalı olduğu əməliyyat bazaları üçün. CDC bazanın tranzaksiya jurnalını oxuyur və sətir səviyyəli dəyişiklikləri ötürür; bu, təkrarlanan sorğulardan mənbə sisteminə qat-qat yüngül düşür. Analitik yükə dözməyən core banking sisteminə qarşı real vaxta yaxın analitikanı mümkün edən mexanizm budur, detalı isə real vaxt analitikası: streaming, CDC və lakehouse məqaləsindədir.
Streaming — həqiqətən hadisə yönümlü mənbələr üçün: tranzaksiya hadisələri, telemetriya, tətbiq jurnalları.
Və çox vaxt hər üçündən yaxşı olan dördüncü variant: ümumiyyətlə ingestion etməmək. Mənbə sistemi federasiya mühərriki ilə yerində sorğulana bilirsə, onu ingestion etmək heç bir faydası olmadan idarə edilməli, qorunmalı və aktual saxlanmalı bir nüsxə yaradır. Defolt federasiya olmalı, ingestion isə konkret ehtiyacla — sorğu performansı, mənbənin saxladığından uzun tarixçə, ya da kövrək sistemin yükünün azaldılması — əsaslandırılmalıdır.
Bu tərsinə çevirmə — defolt federasiya, istisna olaraq ingestion — bu istinad arxitekturası ilə müəssisələrin çoxunun işlətdiyi pipeline mərkəzli dizaynlar arasındakı ən böyük fərqdir.
Qat 2 — Storage və table format
Üzərində açıq table format olan obyekt anbarı. İki qərar, fərqli çəkilərlə.
Obyekt anbarı. S3-uyğun və buradakı qurumlar üçün on-premise — adi seçimlər MinIO və Ceph-dir. Əhəmiyyət daşıyan xüsusiyyətlər üfüqi miqyaslanma, ucuz tutum və hər mühərrikin onsuz da danışdığı API-dir.
Table format. Apache Iceberg, Delta Lake və ya Hudi. Format əks halda sadəcə vedrədəki fayllar olacaq şeyə ACID tranzaksiyalar, sxem təkamülü, zamanda geri baxış və partition idarəsi əlavə edir.
Table format qərarına diqqət lazımdır, çünki bu, platformadakı nəzəri olaraq geri qaytarıla bilən ən nəticəli qərardır: böyük mühiti formatlar arasında çevirmək mümkündür və xoşagəlməzdir. Yeni korporativ quruluşların çoxunda Iceberg mühərrikdən asılı olmayan uyğunluğa görə defolt seçimə çevrilib; spesifikasiya üzrə davam edən iş formatı genişləndirir. Delta mühit Spark mərkəzli olanda güclüdür. Hudi tez-tez upsert olanda güclüdür.
Seçimdən asılı olmayaraq qüvvədə qalan iki qayda:
Datanın necə gəldiyinə görə yox, necə sorğulandığına görə partition edin. Yeni lakehouse-da ən çox rast gəlinən performans problemi müştəri üzrə sorğulanan, tarix üzrə partition edilmiş datadır.
Compaction-ı əvvəldən planlaşdırın. Streaming və CDC ingestion çoxlu kiçik fayl doğurur, kiçik fayllar isə kimsə fərqinə varana qədər sorğu performansını sabit şəkildə pisləşdirir. Compaction könüllü optimallaşdırma yox, qrafikli baxım işidir.
Qat 3 — Çevrilmə və modelləşdirmə
Xam data təhlilə hazır deyil. Nəsə onu təmizləməli, uyğunlaşdırmalı və modelləşdirməlidir; arxitektura seçimi isə bunun harada işləməsidir.
İşin çoxu üçün yerində, SQL-də, table format üzərində çevirin. Sorğulara xidmət edən mühərrik çevrilmələri də icra edə bilər, bu isə bütöv bir infrastruktur qatını aradan qaldırır.
Ağır batch işi üçün ayrıca emal mühərriki işlədin. Spark iri miqyaslı çevrilmə, maşın öyrənməsi üçün feature hazırlanması və SQL olmayan məntiq tələb edən hər şey üçün doğru alət olaraq qalır. O, sorğu mühərriki ilə rəqabət aparmır, yanaşı yaşayır — eyni cədvəlləri oxuyurlar.
Çevrilmə məntiqini tətbiq kodu kimi versiyalayın. Çevrilmələr repozitoriyada, kod baxışından keçmiş, pipeline ilə yayılan. Planlaşdırıcının interfeysində yaşayan çevrilmə məntiqi təkrarlana bilməyən rəqəmlərin ən çox rast gəlinən mənbəyidir.
Qəbul etməyə dəyən qatlama konvensiyası üç pillədir: gəldiyi kimi xam, uyğunlaşdırılmış və təmizlənmiş, biznesə baxan kurasiya olunmuş modellər. Adlar qaydadan az əhəmiyyət daşıyır: hər pillə yuxarıdakından versiyalanmış kodla alınır, heç vaxt yerində redaktə olunmur.
Qat 4 — Sorğu və xidmət
Suallara cavab verən mühərrik — və bu arxitekturada o, eyni anda iki iş görür: lakehouse cədvəllərini sorğulayır və yerində qalan sistemlərə federasiya edir.
Arxitekturanı miqrasiyasız mümkün edən məhz ikinci işdir. Core banking sistemi, departament bazaları, sahibləri köçməyə razı olmayan sistemlər — mühərrik onları yerində sorğulayır və nəticələrini bir ifadədə lakehouse cədvəlləri ilə birləşdirir.
Yukon Labs bunun üçün Trino-nun korporativ distribusiyası olan Starburst-u quraşdırır — əsasən ona görə ki, federativ sətir və sütun səviyyəli giriş nəzarəti hər qoşulmuş mənbədə, hətta öz təhlükəsizlik modeli bunu ifadə edə bilməyənlərdə də ardıcıl tətbiq olunur. Regional arqument Starburst və Trino Azərbaycanda, mühərrik müqayisəsi Starburst, Dremio və Databricks SQL, performans mexanikası — pushdown, caching, paralel oxuma — isə Starburst analitikanı necə sürətləndirir məqaləsindədir.
Xidmət dizayn mərhələsində ayrılmağa dəyən üç şablona bölünür: interaktiv BI sorğuları, qrafikli hesabatlıq və tətbiqə baxan API-lər. Komandalar üçüncüdə həddən artıq mühəndislik edir — data platforması saniyədən az gecikmə tələbi olan müştəri tətbiqi üçün nadir hallarda doğru backend-dir.
Qat 5 — Semantik qat
Müəssisələrin çoxunun atladığı və üçüncü ziddiyyətli paneldən sonra yenidən qurduğu qat.
Semantik qat metrikləri bir dəfə müəyyən edir — «aktiv müştəri» nəyi sayır, gəlir necə tanınır, hansı istisnalar var — və hər istehlakçı metriki BI alətində yenidən qurmaq əvəzinə onun üzərindən həll edir.
Onsuz eyni metrik bir hesabat üçün warehouse-da, digəri üçün BI alətində, idarə heyəti paketi üçün isə cədvəl faylında müəyyən olunur. Üçü də əsaslandırıla bilir, bir-birinə uyğun gəlmir, uzlaşdırılması isə rüblük mərasimə çevrilir.
Ödədiyi tələb təkrarlana bilənlikdir və bu, həm də platformanın governance ilə birbaşa görüşdüyü yerdir: semantik qatdakı metrik tərifi business glossary-də təsdiqlənmiş tərifin eyni olmalıdır, paralel variant yox. Bu ikisi uzaqlaşanda təşkilatda yenidən iki cavab yaranır — glossary-nin həll etməli olduğu problem də elə budur.
Qat 6 — Catalog, governance və giriş
Üstdəki qat deyil. Bütün digər qatları kəsən qatdır.
Catalog nəyin mövcud olduğunu, nə demək olduğunu, sahibinin kim olduğunu, necə təsnifləndiyini və necə axdığını saxlayır. Mənbə sistemlərini, lakehouse cədvəllərini və BI qatını crawl edir və mühitin tam mənzərəsinə malik yeganə komponentdir. Yukon Labs burada OvalEdge tətbiq edir; arxitekturası və konnektor modeli OvalEdge necə işləyir məqaləsində təsvir olunub.
Giriş nəzarəti bir-birinə zidd olmamalı iki nöqtədə tətbiq olunur: mühərrik sorğu vaxtı sətir və sütun səviyyəli siyasəti tətbiq edir, mənbə sistemləri isə özününkünü. Əhəmiyyət daşıyan siyasət bir dəfə ifadə olunub ardıcıl tətbiq olunandır — federativ giriş nəzarətinin funksiya yox, mühərriki müəyyən edən imkan olmasının səbəbi də budur.
Təsnifat qalan hər şeyi idarə edən atributdur — maskalama, saxlama, rezidentlik və AI sisteminin nə çəkə biləcəyi. O, siyasət sənədində yazılmış yox, aktivin üzərində maşın oxuya bilən olmalıdır.
Lineage dəyişikliyi təhlükəsiz, auditi isə mümkün edir. Sütun səviyyəli, əl ilə bəyan yox, SQL-dən və sorğu jurnallarından avtomatik alınmış.
Platformanın idarə oluna bilən olub-olmamasını müəyyən edən ardıcıllıq məqamı budur: bu qat erkən, yüklər gəlməzdən əvvəl qoyulur. Dolmuş platformaya governance-ı sonradan geydirmək bu arxitekturada mövcud olan ən bahalı səhvdir və ən çox rast gəlinən data governance çətinlikləri məqaləsindəki səbəblərə görə ən tez-tez edilən səhv də elə odur.
Qat 7 — Orchestration və observability
Orchestration işi planlaşdırır və sıralayır: ingestion işləri, çevrilmələr, compaction, keyfiyyət yoxlamaları, catalog crawl-ları. Tələb asılılıqları nəzərə alan icra, təkrar cəhd, bildiriş və baxıla bilən icra tarixçəsidir — cron cədvəli yox.
Observability komandaların qarışdırmağa meylli olduğu üç ayrı şeyi əhatə edir:
Pipeline sağlamlığı — iş işə düşdümü, uğurlu oldumu, nə qədər çəkdi, yavaşlama meyli varmı.
Data quality — nəticələr öz qaydalarını ödəyirmi. Kritik elementlərdə tamlıq və etibarlılıq, ciddiliyə görə pozuntunun mənasını qərara ala bilən adama yönləndirilmiş. Arxasındakı operating model data quality governance proqramında harada dayanır məqaləsindədir.
Sorğu və xərc davranışı — klasteri hansı sorğular tutur, hansılar lazım olandan qat-qat çox skan edir, nəsə pisləşəndə kim təsirlənir. On-premise-də bu, hesab yox, tutum planlaşdırmasıdır, amma təhlil eynidir.
Qat 8 — AI və retrieval
Ən yeni qat və altındakı qatların tələblərini ən çox dəyişən qat.
Korporativ AI sisteminə platformadan dörd şey lazımdır:
İdarə olunan retrieval əhatəsi. Sistemin istifadəçi üzrə hansı sənəd və cədvəllərə çata biləcəyi. Bu, 6-cı qatdakı təsnifat atributuna gəlib çıxır — idarə olunmayan mühitlərdə AI tətbiqlərinin dayanmasının səbəbi də budur: «o nə görə bilər» sualının cavabı hələ mövcud deyil.
Yalnız kurasiya olunmuş yox, xam qat da. Retrieval sənədlər, transkriptlər, jurnallar və tam dənəvərlikdə tarixçə üzərində işləyir; ikiqatlı arxitekturada isə bunlar ən az idarə olunan yerdə yaşayır. Bir idarə olunan nüsxəyə yığılmaq lakehouse ilə korporativ AI-ın eyni yol xəritəsində görünməsinin böyük hissəsini izah edir; bu, korporativ AI və RAG üçün lakehouse arxitekturası məqaləsindədir.
Rezidentliyə hörmət edən inferens. Buradakı nəzarət altındakı qurumlar üçün inferens perimetrin içində işləyir. Onun arxitekturası, ölçülməsi və xərci LLM-lərin on-premise tətbiqi, altındakı məhdudiyyət isə data rezidentliyi və şəxsi məlumat qanunu məqaləsindədir.
Audit izi. Nə çəkildi, nə yaradıldı, kim onun əsasında hərəkət etdi. Bu, tətbiq funksiyası yox, platforma imkanıdır və ISO/IEC 42001 auditinin görmək istədiyi də budur.
On-premise-də bu necə görünür?
İstinad arxitekturası on-premise üçün dəyişmir; komponent seçimləri dəyişir.
Obyekt anbarı hiperskalyar xidməti yox, MinIO və ya Ceph olur. Mühərrik sizin data mərkəzinizdə Kubernetes üzərində işləyir. Catalog və onun repozitoriyası sizin infrastrukturunuzda qalır. İnferens sizin GPU-larınızda işləyir. Arxitekturada heç nə runtime-da internet bağlantısı tələb etmir — tələb olunan yerdə air-gapped iş rejimini mümkün edən də budur.
Həqiqətən dəyişən əməliyyat yüküdür. İdarə olunan bulud platforması klaster əməliyyatlarını, yeniləmələri və tutum idarəsini udur; on-premise-də bunların sahibi kimsə olmalıdır. Bu, arxitektura təsdiqlənəndən sonra yox, əvvəl cavablandırılmalı kadr sualıdır — və başqa cür sağlam dizaynın gözlənilən nəticəni verməməsinin ən çox rast gəlinən səbəbi də budur. Buradakı qurumların bu yükü niyə qəbul etdiyinə dair geniş arqument suveren AI məqaləsindədir.
Hansı ardıcıllıqla qurulmalıdır?
Təkrarlanan layihələrdən çıxan, boşa gedən işi minimuma endirən ardıcıllıq:
Mərhələ 1 — mövcud olanın üzərində sorğu və federasiya. Mühərriki qurun, mövcud mənbələri qoşun, analitiklərə federativ giriş verin. Bu, heç bir datanı tərpətmədən həftələr içində dəyər verir və imkanın özündən qiymətli bir şey də istehsal edir: insanların əslində nə soruşduğunu göstərən real sorğu şablonları.
Mərhələ 2 — catalog və governance. 1-ci mərhələdə qoşulmuş mənbələr üzrə təsnifat, sahiblik və lineage. Yeni anbar qatı yaranmazdan əvvəl — beləliklə governance sonradan geydirilən yox, ilkin şərt olur.
Mərhələ 3 — storage və table format. Obyekt anbarını və table format-ı qaldırın. Ölçüləbilən fayda görən yükləri köçürün — ağrılı pipeline-ı olanları və mənbənin saxlaya bilmədiyi tarixçəni.
Mərhələ 4 — çevrilmə və semantika. Çevrilmə məntiqini versiya nəzarətinə köçürün, üç pilləli modeli qurun, metrikləri semantik qatda bir dəfə müəyyən edin.
Mərhələ 5 — orchestration və observability. Bu vaxta artıq düzgün orchestration-a dəyəcək qədər iş işləyir.
Mərhələ 6 — AI və retrieval. İdarə olunan, konsolidasiya edilmiş mühitdə, təsnifat artıq retrieval əhatəsini idarə edən halda.
Ardıcıllıq şüurludur: hər mərhələ növbətini ucuzlaşdırır, 1-ci və 2-ci mərhələlər isə heç bir miqrasiya riski götürülmədən dəyər verir. 3-cü mərhələdən başlayan proqramlar hələ heç kimin sorğulamadığı anbarı qurmağa bir il sərf edir.
Hansı qərarları geri qaytarmaq çətindir?
Dördü. Qalan hər şey komponent dəyişməsidir.
Table format. Çevrilə bilər, amma böyük mühitdə real qiymətə.
Ən böyük cədvəllərinizdə partition strategiyası. İllərlə tarixçəsi olan cədvəli yenidən partition etmək layihədir.
Təsnifat modeli. Aktivlər işarələnəndən və siyasətlər işarələrə istinad edəndən sonra sxemi dəyişmək yenidən işarələmə və siyasətin yenidən yazılması deməkdir.
Governance-ın əvvəl gəlib-gəlmədiyi. Texniki qərar deyil və dördün ən az geri qaytarılanıdır. İdarə olunmadan böyümüş mühiti sonradan kataloqlaşdırmaq olar, amma onda sahiblik, təriflər və təsnifat heç kimin sənədləşdirmədiyi mühitdən bərpa edilməlidir — data governance yetkinlik modelinin «üstündə müasir platforma olan 1-ci səviyyə» kimi təsvir etdiyi vəziyyət budur.
Mühərrik seçimi, orchestrator, BI aləti və inferens dəsti — hamısı əvəzlənə biləndir. Elə dizayn edin ki, belə də qalsın.
Bunun üçün necə komanda lazımdır?
Vendorların dediyindən kiçik, bir platforma mühəndisindən böyük.
Orta ölçülü qurum üçün işlək minimum: anbar, mühərrik və orchestration-un sahibi iki platforma mühəndisi; ingestion və çevrilmənin sahibi iki-üç data mühəndisi; catalog və governance əməliyyatlarının sahibi bir nəfər; və biznes domenlərinə yerləşdirilmiş, hər biri həftədə iki-dörd saat ayıran steward-lar — data stewardship rolları və işlək RACI məqaləsində təsvir olunduğu kimi.
Ən çox əskik olan rol altıncıdır — catalog və governance əməliyyatları. Onsuz platforma işləyir, mühit isə səssizcə yenidən sənədsiz qalır.
Əsas məqamlar
- Səkkiz qat: ingestion, storage və table format, çevrilmə, sorğu və xidmət, semantik qat, catalog və governance, orchestration və observability, AI və retrieval.
- Defolt federasiya, istisna olaraq ingestion. Hər ingestion edilmiş nüsxə idarə olunmalı, qorunmalı və aktual saxlanmalı bir nüsxədir.
- Table format-ı şüurlu seçin; yalnız nəzəri olaraq geri qaytarıla bilən ən nəticəli qərar budur.
- Sorğu şablonlarına görə partition edin və compaction-ı ilk gündən qrafikə salın.
- Semantik qat eyni metrikin üç dəfə müəyyən olunmasının qarşısını alır. Onun təriflərini business glossary ilə eyni saxlayın.
- Governance bütün qatları kəsir və yüklər gəlməzdən əvvəl qoyulmalıdır.
- Ardıcıllıqla qurun: federasiya, governance, sonra storage, çevrilmə, orchestration və yalnız bundan sonra AI.
- Ən çox əskik olan rol catalog və governance əməliyyatlarıdır; onsuz mühit yenidən sənədsiz qalır.
Yukon Labs bu arxitekturanı Azərbaycanda on-premise dizayn və tətbiq edir — sorğu qatında Starburst, governance qatında OvalEdge. Hazırlıq qiymətləndirməsi mühitinizin faktiki olaraq hansı mərhələdə olduğunu müəyyən edir. Arxitektura fonu üçün data lakehouse arxitekturası, praktiki maneələr üçün isə lakehouse tətbiqinin çətinlikləri məqaləsinə baxın.