Müəssisələr niyə lakehouse arxitekturasına keçir?

Müəssisələr lakehouse arxitekturasına eyni vaxtda gələn beş səbəbə görə keçir: eyni datanı iki dəfə saxlamağa görə ödəniş, açıq table format-ların istehsalata yararlı hala gəlməsi, AI yüklərinin həm xam, həm kurasiya olunmuş qata ehtiyacı, mülkiyyət formatlı warehouse-lardan çıxış xərci və hər şeyi xarici buludda mərkəzləşdirməyə imkan verməyən rezidentlik qaydaları.

Bunların heç biri təkbaşına işləyən platformanı yenidən qurmağı əsaslandırmazdı. Birlikdə isə əksər arxitektura baxışlarında sualın «keçəkmi»dən «nə vaxt»a niyə sürüşdüyünü izah edir.

İkiqatlı arxitektura əslində hansı problemi doğururdu?

Müəssisələrin çoxunun hələ də işlətdiyi arxitekturada xam və yarımstrukturlu data üçün data lake, kurasiya olunmuş analitika üçün data warehouse var, aralarında isə datanı birincidən ikinciyə daşıyan pipeline-lar dayanır.

O, işləyirdi və mühit böyüdükcə qatlanan üç struktur xərci var.

Eyni data iki dəfə saxlanılır — bir dəfə lake-də, bir dəfə warehouse-da, fərqli formatlarda, fərqli giriş nəzarətləri və fərqli saxlama davranışı ilə. Anbar ucuzdur; iki nüsxə anbar üstəgəl onları birləşdirən pipeline-lar isə yox.

Pipeline qatı darboğaza çevrilir. Warehouse-da hələ olmayan dataya ehtiyacı olan hər yeni analitik sual data mühəndisliyi komandasına sorğuya çevrilir, o komandanın növbəsi isə həftələrlə ölçülür. Yeni sualın cavabının qiyməti zamanla artır — bu isə yanlış istiqamətdir.

Governance parçalanır. Warehouse-da həssas kimi təsniflənmiş sütun lake-də tez-tez təsnifsiz qalır, çünki ikisini fərqli alətlərlə fərqli komandalar idarə edir. Nəticədə mühitdə bir yaxşı idarə olunan nüsxə və bir də heç kimin dəqiq əmin olmadığı nüsxə qalır — ən çox rast gəlinən data governance çətinlikləri məqaləsindəki uğursuzluq forması məhz budur.

Lakehouse təklifi budur: obyekt anbarında açıq formatlarda bir nüsxə saxlamaq və warehouse səviyyəli SQL-i, BI-ı və maşın öyrənməsini birbaşa onun üzərində işlətmək. Bu iddianın arxasındakı arxitektura detalı data lakehouse arxitekturası: warehouse, lake və lakehouse məqaləsindədir.

Amil 1 — ikinci nüsxənin iqtisadiyyatı

Maliyyə arqumenti adətən anbara qənaət kimi təqdim olunur, bu isə onu az göstərir.

Anbar ən kiçik komponentdir. Real xərclər ikinci nüsxəni aktual saxlamaq üçün pipeline mühəndisliyi, həmin pipeline-ları işlədən hesablama, onlar sınanda yaranan insident yükü və gözləmə çox uzun olduğu üçün heç vaxt verilməyən sualların alternativ dəyəridir.

Bir neçə yüz pipeline-ı olan müəssisə adətən data mühəndisliyi tutumunun böyük hissəsini yeni imkan yox, baxım işinə sərf edir. İkinci nüsxəni aradan qaldırmaq onu qidalandıran pipeline-ları aradan qaldırır və gəlir də həmin mühəndislik tutumudur — anbar sətri yox.

Dürüst əks çəki: lakehouse çevrilməni aradan qaldırmır. Kurasiya olunmuş, modelləşdirilmiş cədvəllər yenə qurulmalıdır. Dəyişən budur ki, çevrilmə altında ayrıca mülkiyyət anbar qatı olmadan, yerində və açıq formatlarda baş verir.

Amil 2 — açıq table format-lar istehsalata yararlı oldu

Lakehouse anlayışı onun həyata keçirilə bilməsindən köhnədir. Onu praktiki edən açıq table format-ların — Apache Iceberg, Delta Lake və Hudi — yetkinləşməsi oldu: bunlar obyekt anbarına əvvəllər yalnız warehouse-un verdiyi xüsusiyyətləri əlavə etdi — ACID tranzaksiyalar, sxem təkamülü, zamanda geri baxış və səmərəli partition idarəsi.

Xüsusən Iceberg arxitekturanın söykəndiyi qarşılıqlı uyğunluq nöqtəsinə çevrilib; v3 spesifikasiyası üzrə iş formata yeni əlavələr gətirir və ekosistem boyu geniş mühərrik dəstəyi var. Praktiki nəticə budur: eyni cədvəli bir neçə mühərrik oxuya bilər — biri interaktiv SQL üçün, digəri batch çevrilmə üçün, üçüncüsü maşın öyrənməsi üçün — hər mühərrikin öz nativ formatına kopyalamadan.

Lakehouse-u üzərinə sorğu mühərriki bərkidilmiş lake-dən ayıran xüsusiyyət məhz budur. Format seçimi kifayət qədər nəticəlidir ki, mühərrik seçimindən ayrıca təhlil olunsun.

Amil 3 — AI yüklərinə hər iki qat lazımdır

İkiqatlı arxitektura dizayn olunanda bu amil yox idi; indi isə büdcələri tərpədən amil odur.

Analitik yüklər kurasiya olunmuş, modelləşdirilmiş, idarə olunan cədvəl istəyir. AI yükləri başqa şey istəyir: xam sənədlər, yarımstrukturlu jurnallar, tam dənəvərlikdə tarixi qeydlər və embedding modeli dəyişəndə hər şeyi yenidən emal etmək imkanı.

İkiqatlı arxitekturada bunlar fərqli yerlərdə, fərqli governance altında yaşayır və AI layihəsi sonda lake-ə əl atır — yəni təsnifatı və giriş nəzarəti ən zəif olan qata. Retrieval sisteminin heç kimin təsnifləmədiyi dataya nəzarətsiz giriş yoluna çevrilməsi belə baş verir.

Lakehouse hər iki yükü bir idarə olunan nüsxənin üzərinə qoyur. Kurasiya olunmuş cədvəllər və xam qat eyni giriş nəzarəti və eyni catalog altındadır, bu isə AI sisteminin retrieval əhatəsi barədə düşünməyi mümkün edir. Bunun yalnız uyğunluq üçün yox, cavab keyfiyyəti üçün də niyə vacib olduğu korporativ AI və RAG üçün lakehouse arxitekturası məqaləsində açılıb.

Amil 4 — çıxış xərci və vendor konsentrasiyası

Mülkiyyət formatlı warehouse-lar əhəmiyyət kəsb edənə qədər görünməyən çıxış problemi yaradır. Vendorun daxili formatında saxlanan datanı yalnız həmin vendorun mühərriki oxuya bilir; getmək hər şeyi ixrac etmək deməkdir, bu isə elə bahadır ki, təşkilatların çoxu bunu etmir.

Açıq formatlar danışıq mövqeyini dəyişir. Obyekt anbarında Iceberg formatındakı datanı Trino, Spark və bir sıra digər mühərriklər oxuya bilir, bu isə mühərriki daimi öhdəlik yox, əvəzlənə bilən komponent edir. Həmin qatda mövcud mühərriklərin müqayisəsi Starburst, Dremio və Databricks SQL məqaləsindədir.

Nəzarət altındakı qurumlar üçün bu, yalnız kommersiya məsələsi deyil. Çıxış planlaşdırması və konsentrasiya riski standart nəzarət narahatlıqlarıdır; datanın sizin idarə etdiyiniz infrastrukturda açıq formatda olduğu arxitekturanı çıxarışın vendor əməkdaşlığını tələb etdiyi arxitekturadan xeyli asan əsaslandırmaq olur — bu, Mərkəzi Bankın İT və data tələblərindəki autsorsinq gözləntiləri ilə birbaşa yanaşı dayanır.

Amil 5 — rezidentlik mərkəzləşdirməni əlçatmaz edir

Azərbaycandakı banklar və dövlət qurumları üçün standart müasir arxitektura — hər şeyi bulud warehouse-una yığmaq — tez-tez ümumiyyətlə variant deyil, çünki şəxsi məlumatı sadəcə köçürmək olmur. Ötürmə qaydaları və onların mühəndislik nəticələri Azərbaycanda data rezidentliyi və şəxsi məlumat qanunu məqaləsindədir.

Bu məhdudiyyət buradakı cavabı formalaşdırır. Sizin idarə etdiyiniz obyekt anbarında — hiperskalyarın xidməti yox, MinIO və ya Ceph — qurulmuş lakehouse, üstəgəl onu sorğulaya bilən və yerini dəyişə bilməyən sistemlərə federasiya edən mühərrik müasir analitikadan imtina etmədən rezidentliyi ödəyən arxitekturadır. Onun federasiya yarısı Starburst və Trino Azərbaycanda məqaləsindədir.

Lakehouse üçün beynəlxalq arqument səmərəlilikdir. Burada isə çox vaxt sadəcə mümkünlükdür.

Miqrasiya əslində necə gedir?

Ənənəvi mənada miqrasiya deyil və bu, ən faydalı praktiki məqamdır. Uğurlu keçidlər artımlı və əlavəedicidir.

Lakehouse qatını mövcud olanın yanında qaldırın. Obyekt anbarı, açıq table format, mühərrik. Hələ heç nə söndürülmür.

Real sahibi olan bir iş yükünü köçürün. Hazırda ağrılı pipeline tələb edən və yaxşılaşmanı görəcək adamı olan yük seçin. Onu yeni qatda təkrarlayın və rəqəmlər üst-üstə düşənə qədər ikisini paralel işlədin.

Köçməyəcək sistemləri köçürmək yox, federasiya edin. Core banking sistemi yerində qalır. Mühərrik onu yerində sorğulayır. Bu, miqrasiya riskinin ən böyük mənbəyini aradan qaldırır — köçürülməsi ən çətin olan sistemləri köçürmək tələb olunmur.

Pipeline-ları artıq lazımsız olduqca ləğv edin — bir-bir, ölçülən nəticə kimi azad olunan mühəndislik vaxtı ilə.

Governance-ı sona yox, əvvələ salın. Təsnifat və sahiblik lakehouse qatına yüklər ora düşməzdən əvvəl tətbiq olunmalıdır, sonra yox. Dolmuş lakehouse-a governance-ı sonradan geydirmək lake-ə geydirməklə eyni bahalı işdir və bu proqramlarda ən çox təəssüf doğuran qərar da elə budur.

Bütün mühitin bir dəfəyə köçürülməsi lakehouse proqramlarının uğursuz olduğu yerdir. Uğursuzluq formaları lakehouse tətbiqində heç kimin xəbərdarlıq etmədiyi çətinliklər məqaləsində toplanıb.

Lakehouse nə vaxt səhv cavabdır?

Dörd hal var və onları açıq yoxlamağa dəyəcək qədər çox rast gəlinir.

Tək mənbəli, yüksək paralellikli xidmət yükü. Saniyədən az cavab tələbi ilə bir bazanı sorğulayan min paralel istifadəçi düzgün indekslənmiş bazanın işidir.

Kiçik, sabit mühit. Bir əməliyyat sistemi və ehtiyaclarını ödəyən warehouse-u olan təşkilatda lakehouse-un həll etdiyi problem yoxdur. Arxitektura mürəkkəbliyini miqyas və rəngarənglikdə qazanır.

Platforma mühəndisliyi bacarığının olmaması. Lakehouse idarə olunan warehouse-dan çox komponentdir: anbar, table format, catalog, mühərrik, orchestration. Kimsə onların sahibi olmalıdır.

Əsl problem dataya etibar olanda. Lakehouse idarə olunmayan datanı daha sürətli əlçatan edir. Təriflər mübahisəlidirsə və lineage bilinmirsə, məhdudiyyət governance-dır və arxitektura dəyişikliyi onu yüngülləşdirməyəcək. Bu ardıcıllıq arqumenti data quality governance proqramında harada dayanır məqaləsindən keçir.

Əsas məqamlar

• Beş amil birləşdi: ikiqat anbar və pipeline xərci, istehsalata yararlı açıq table format-lar, xam və kurasiya olunmuş qatı birlikdə tələb edən AI yükləri, mülkiyyət formatlarından çıxış xərci və rezidentlik məhdudiyyətləri.
• İqtisadi gəlir anbara qənaət yox, azad olunan data mühəndisliyi tutumudur.
• Açıq table format-lar mühərriki əvəzlənə bilən komponentə çevirir; bu, həm danışıq mövqeyini, həm nəzarət üçün çıxış hekayəsini dəyişir.
• Büdcələri indi tərpədən amil AI-dır, çünki retrieval yükləri əks halda ikiqatlı mühitin ən az idarə olunan qatına əl atır.
• Artımlı köçün: qatı yanında qaldırın, sahibi olan bir yükü köçürün, köçməyəcəyi federasiya edin, lazımsızlaşan pipeline-ları ləğv edin.
• Governance-ı lakehouse qatına yüklər ora düşməzdən əvvəl tətbiq edin.
• Tək mənbəli yüksək paralellikli xidmət, kiçik sabit mühit, platforma bacarığı olmayan təşkilat və ya governance əvəzi kimi — səhv cavabdır.

Yukon Labs Starburst-u həm lakehouse, həm köhnə mənbələr üzərində sorğu qatı kimi on-premise tətbiq edir, eyni mühitə idarə olunan catalog lazım olanda isə OvalEdge qurur. Arxitektura fonu üçün data lakehouse arxitekturası məqaləsindən başlayın; mühitinizin harada dayandığını yoxlamaq üçün adi giriş nöqtəsi hazırlıq qiymətləndirməsidir.