Data lakehouse datanı ucuz obyekt anbarında açıq formatlı fayllar kimi saxlayan, eyni zamanda əvvəllər yalnız data warehouse-da mümkün olan tranzaksiya zəmanətlərini, sxem idarəetməsini və sorğu performansını verən data platformasıdır. Onu mümkün edən açıq cədvəl formatlarıdır — Apache Iceberg, Delta Lake, Apache Hudi — bunlar həmin faylların üzərinə metadata qatı əlavə edir və mühərriklərə cədvəlin ardıcıl, versiyalanmış görünüşünü verir.

Niyə mövcud olduğunun qısa cavabı: warehouse-lar etibarlılıq verirdi, amma datanızı yüksək qiymətə xüsusi mühərrikin içinə kilidləyirdi. Lake-lər ucuz açıq anbar verirdi, amma zəmanət vermirdi və çoxu istifadəsiz qaldı. Lakehouse birinci xüsusiyyəti saxlayıb ikincisinin pulunu ödəməmək cəhdidir, indi işləməsinin səbəbi isə cədvəl formatlarının yetkinləşməsidir.

Bu yetkinlik artıq mübahisə mövzusu deyil. Iceberg Summit 2026 tədbirində — 600-dən çox iştirakçı, 70-dən çox sessiya — bir dənə də olsun çıxış onu mənimsəməyin lehinə arqument gətirmirdi; hər sessiya auditoriyanın onu onsuz da işlətdiyini nəzərdə tuturdu. Maraqlı sual hansı format olmaqdan çıxıb üstündə nə qurmalıya keçdi.

Bura necə gəldik

Başa düşməyə dəyər, çünki hər nəslin güzəştləri lakehouse-un əslində nəyi optimallaşdırdığını izah edir.

Data warehouse

Strukturlaşdırılmış, schema-on-write, SQL analitikası üçün güclü optimallaşdırılmış. Data yerə düşməzdən əvvəl onu təmizləyən və uyğunlaşdıran ETL boru xətləri ilə yüklənir.

Yaxşı etdiyi: ACID tranzaksiyaları, sabit performans, yetkin idarəetmə və giriş nəzarəti, hər analitikin onsuz da bildiyi sorğu interfeysi.

Harada sındı: anbar və hesablama bir-birinə bağlı idi və hər ikisi baha idi, ona görə xərc həcmlə elə artırdı ki, təşkilatlar sonradan lazım ola biləcək datanı atmağa məcbur olurdu. Schema-on-write o demək idi ki, hər yeni sual boru xəttində dəyişiklik, hər dəyişiklik isə mühəndislik növbəsi tələb edirdi. Data xüsusi formatda saxlanılırdı, ona görə onu warehouse-dan başqa bir şeylə işlətmək köçürmək demək idi. Və yalnız strukturlaşdırılmış datanı emal edirdi.

Müəyyənedici simptom: aylarla ölçülən analitika növbəsi, harada ki hər yeni sual ayrıca layihədir.

Data lake

Buna reaksiya. Hər şeyi açıq formatlarda, ucuz obyekt anbarında saxla, schema-on-read. Nə demək olduğuna sonra qərar ver.

Yaxşı etdiyi: istənilən miqyasda ucuz, istənilən data növü, açıq formatlar, hesablamadan ayrılmış anbar.

Harada sındı: demək olar ki, qalan hər yerdə. Tranzaksiyalar yox idi, ona görə paralel yazmalar datanı korlayırdı. Sxem məcburiyyəti yox idi, ona görə fayllar bir-birindən uzaqlaşırdı. Qeydi yeniləmək və ya silmək üçün etibarlı yol yox idi — bu da qanunla tələb olunan silmə sorğularını həqiqətən çətinləşdirirdi. Ciddi mühəndislik olmadan sorğu performansı zəif idi. Və kataloq yox idi, ona görə heç kim heç nə tapa bilmirdi.

Nəticə data bataqlığı oldu: heç kimin etibar etmədiyi petabaytlarla fayl, yalnız üç nəfərin başa düşdüyü işlərlə sorğulanan.

Lakehouse

Sintez. Lake-in anbar iqtisadiyyatını və açıqlığını saxla. Metadata qatı əlavə edərək warehouse-un zəmanətlərini geri qaytar.

Açar fikir budur: cədvəlin xüsusi anbar strukturu olması vacib deyil. O, fayllar toplusu plus hansı faylların verilmiş anda cədvəli təşkil etdiyini təsvir edən manifest ola bilər. Bu manifest olandan sonra atomar commit-lər, sxem təkamülü, zamanda səyahət və partisiya idarəetməsi əlavə etmək olar — alt qatdakı data isə istənilən mühərrikin oxuya biləcəyi adi Parquet faylları olaraq qalır.

Həmin manifest qatı açıq cədvəl formatıdır və lakehouse-un bütün texniki təməli də elə odur.

Cədvəl formatı əslində nə verir

Fayl qovluğunu cədvələ çevirən dörd imkan.

Atomar commit-lər. Yazma ya tam görünür olur, ya da heç olmur. Oxuyanlar heç vaxt yarımçıq vəziyyət görmür. Paralel girişi təhlükəsiz edən budur, onun yoxluğu isə data lake-ləri etibarsız edən şey idi.

Sxem təkamülü. Datanı yenidən yazmadan sütun əlavə etmək, silmək, adını dəyişmək və ya sırasını dəyişmək. Format sütunun kimliyini mövqedən asılı olmadan izləyir, ona görə ad dəyişikliyi sonrakı bütün sorğuları səssizcə sındırmır.

Zamanda səyahət və snapshot-lar. Hər commit snapshot yaradır. Cədvəli verilmiş vaxtdakı halı ilə sorğulaya, pis yazmanı geri qaytara və hesabatı keçən rübdə işlədiyi kimi eynilə təkrar istehsal edə bilərsiniz. Tənzimlənən institutda bu, rahatlıq funksiyası deyil — tarixi rəqəmlərlə bağlı suallara belə cavab verirsiniz.

Sətir səviyyəsində yeniləmə və silmə. Change data capture üçün, düzəlişlər üçün və data müdafiəsi qanunu üzrə silmə öhdəlikləri üçün vacibdir. Sadə fayl əsaslı lake-lər bunu bütöv partisiyaları yenidən yazmadan edə bilmirdi.

2026-cı ildə formatlar harada dayanır

Iceberg neytrallıq mübahisəsini udub. O, dizaynına görə mühərrikdən asılı deyil; Snowflake, AWS, Google və geniş açıq mənbə ekosistemi onun üzərində ümumi standart kimi birləşib, Delta Lake-i yaradan Databricks isə Unity Catalog vasitəsilə ciddi Iceberg uyğunluğu əlavə edib.

Arxitekturaya öhdəlik götürməzdən əvvəl 2026-cı ilin iki hadisəsini bilməyə dəyər:

Praktiki məsləhət dəyişməyib və indi daha yaxşı əsaslanıb: mühərrik müstəqilliyi vacibdirsə Iceberg seçin, və hansı kataloqa öhdəlik götürdüyünüzə diqqət yetirin.

Lakehouse müqayisədə

Hər ölçünü üçü üzrə oxuyaq — əvvəlcə warehouse, sonra lake, sonra lakehouse:

  • Anbar xərci — yüksək, aşağı, aşağı.
  • Format — xüsusi, açıq, açıq.
  • Tranzaksiyalar — var, yox, var.
  • Sxem — yazılanda, oxunanda, hər ikisi və məcburi.
  • Yeniləmə və silmə — var, praktiki deyil, var.
  • Strukturlaşdırılmamış data — yox, var, var.
  • Mühərrik seçimi — vendora kilidli, istənilən mühərrik, istənilən mühərrik.
  • Zamanda səyahət — məhdud, yoxdur, tam snapshot-lar.
  • Performans — əla, zəif, yaxşıdan əlaya.
  • Əməliyyat mürəkkəbliyi — aşağı, yüksək, orta.

Kommersiya baxımından ən vacib sətir mühərrik seçimidir. Warehouse-da datanız vendorun sistemi içindədir və onu çıxarmaq miqrasiyadır. Lakehouse-da isə data sizin obyekt anbarınızdakı Parquet fayllarıdır, sorğu mühərriki isə əvəz edə biləcəyiniz komponentdir. Bu, davamlı struktur üstünlüyüdür və bir bahalı warehouse miqrasiyasından keçmiş təşkilatların bunda israr etməsinin səbəbi də budur.

Federasiya: onu praktiki edən hissə

İstənilən lakehouse planının dürüst problemi budur ki, sizdə onsuz da iyirmi sistem var, hamısını lakehouse-a köçürmək isə prioritetlərin dəyişməsindən sağ çıxmayacaq çoxillik proqramdır.

Sorğu federasiyası bunu həll edir. Federativ mühərrik — Trino və onun kommersiya distribusiyası Starburst dominant seçimdir — datanı olduğu yerdə sorğulayır: lakehouse, mövcud warehouse, əməliyyat bazaları və obyekt anbarı üzrə bir SQL ifadəsində, heç nəyi köçürmədən birləşdirir. Trino 30-dan çox istehsal səviyyəli konnektorla gəlir, Starburst isə bunu 50 və daha çoxa genişləndirir.

Bu, miqrasiya hekayəsini tamamilə dəyişir. Böyük partlayış köçürməsi əvəzinə federativ mühərriki estate-in üzərinə olduğu kimi qoyursunuz, dəyəri dərhal verirsiniz, və ayrı-ayrı datasetləri lakehouse-a plan belə dediyi üçün deyil, konkret səbəb — performans, xərc və ya idarəetmə — olduqda köçürürsünüz.

Sorğu federasiyasının mexanikası Azərbaycanda Starburst və Trino yazısında verilib.

İstinad arxitekturası

İşləyən lakehouse beş qatdan ibarətdir.

Anbar. Obyekt anbarı — S3-uyğun, o cümlədən ictimai buluddan istifadə edə bilməyən təşkilatlar üçün MinIO və ya Ceph kimi on-premise reallaşdırmalar. Data Parquet kimi.

Cədvəl formatı. Ən çox Iceberg — həmin fayllar üzərində tranzaksiya qatını verir.

Kataloq. Bu sözü iki fərqli şey bölüşür və bu, davamlı çaşqınlıq yaradır:

  • Mühərriklərin cədvəl metadata-sını həll etmək üçün işlətdiyi texniki kataloq — Hive Metastore, və ya Apache Polaris, Nessie kimi REST kataloq.
  • İdarəetmə üçün biznes kataloqu — data nə deməkdir, sahibi kimdir, haradan gəlib. Bu, OvalEdge-dir və tamam ayrı məsələdir.

Hər ikisi lazımdır. Onları qarışdırmaq çaşdırıcı arxitektura diaqramlarının daimi mənbəyidir.

Sorğu mühərriki. Federativ və interaktiv SQL üçün Trino və ya Starburst; ağır batch transformasiyası üçün Spark. Bunlar eyni cədvəllər üzərində yan-yana işləyir — açıq formatın mənası da elə budur.

İstehlak. BI alətləri, notebook-lar, tətbiqlər və AI retrieval — hamısı eyni idarə olunan cədvəllərlə SQL dilində danışır.

Nəyə başa gəlir — və sizə nəyə başa gəlir

Harada qənaət edir. Anbar warehouse anbarının kiçik bir hissəsinə başa gəlir. Hesablama ayrılıb və real sorğu yükü ilə miqyaslanır. Xüsusi format kilidlənməsi yoxdur, ona görə gələcək mühərrik dəyişikliyi miqrasiya deyil, konfiqurasiyadır. Federasiya isə yalnız datanı sistemlər arasında daşımaq üçün mövcud olan bütöv boru xətti kateqoriyalarını aradan qaldırır.

Harada baha başa gəlir. Əməliyyat mürəkkəbliyi idarə olunan warehouse-dan həqiqətən yüksəkdir — siz bir məhsul almırsınız, komponentləri yığırsınız. Kiçik faylların idarəsi, sıxlaşdırma və partisiya baxımı real, davamlı işlərdir və iş yükləri Iceberg-in ilkin nəzərdə tutulduğu sahədən uzaqlaşdıqca çətinləşir: hər bir neçə saniyədə commit edən streaming boru xətləri və minlərlə sütunu olan feature cədvəlləri artıq adi haldır və metadata qatına təzyiq göstərir. Ən çətin iş yüklərində sorğu performansı hələ də yaxşı tənzimlənmiş xüsusi warehouse-dan geri qalır. Və bu bazarda müvafiq bacarıqlar warehouse bacarıqlarından az yayılıb.

Nə vaxt qurmamalı

Bunu açıq yazmağa dəyər, çünki arxitektura dəbdədir, dəb isə zəif səbəbdir.

Datanız bir bazaya rahat sığırsa. Bir neçə terabaytdan az, bir komanda və proqnozlaşdırıla bilən sorğularla — yaxşı idarə olunan PostgreSQL və ya idarə olunan warehouse daha sadə, daha sürətli və daha ucuzdur. Burada lakehouse qurmaq bahalı teatrdır.

Data mühəndisliyi imkanınız yoxdursa. Lakehouse komponentlərdən yığılır. Sahibi olmadan qarşısını almaq üçün qurulduğu bataqlığa çevrilir.

İş yükünüz sırf əməliyyatdırsa. Lakehouse analitik infrastrukturdur. Yüksək paralellikli, aşağı gecikməli tranzaksiya xidməti başqa problemdir.

Əsl problem idarəetmədirsə. Çətinlik rəqəmlərə heç kimin inanmamasındadırsa, yeni anbar arxitekturası bunu düzəltməyəcək. Eyni çaşqınlığı daha ucuz anbarda təkrar istehsal edəcək. Əvvəlcə idarəetmə — baxın: Azərbaycanda data idarəetməsi.

Ağıllı miqrasiya yolu

Mövcud warehouse-u və boru xətti növbəsi olan təşkilat üçün:

  1. Əvvəlcə federasiya edin. Mövcud estate-in üzərinə sorğu mühərriki qoyun. Dərhal dəyər, miqrasiyasız — və bu, insanların əslində nəyi sorğuladığını sizə deyir.
  2. Yeni datanı lakehouse-a endirin. Yeni mənbələr obyekt anbarına Iceberg cədvəlləri kimi gedir. Miqrasiya tələb olunmur, lakehouse üzvi şəkildə böyüyür.
  3. Səbəbi olan datasetləri köçürün. Warehouse-dakı ən böyük və ən bahalı cədvəllər, və hazırda saxlamağa gücünüzün çatmadığı tarixçəyə ehtiyacı olan hər şey.
  4. Warehouse-u həqiqətən ən yaxşı bacardığı işə qədər kiçildin. O, yüksək paralellikli xidmət üçün doğru yer olaraq qala bilər. Əhatə azaldıqca xərc də azalır.
  5. Boyu idarə edin. Hər ikisi üzrə kataloq və lineage — başlanğıcdan, ki lakehouse sonradan düzəldilmiş yox, birinci gündən idarə olunan olsun.

Bu ardıcıllıq ilk rübdə dəyər verir və heç vaxt bir gecəlik keçid tələb etmir — çoxillik miqrasiya planlarını öldürən rəhbərlik dəyişiklikləri və büdcə dövrlərindən sağ çıxmasının səbəbi də elə budur.

Əsas məqamlar

  • Lakehouse obyekt anbarındakı açıq formatlı fayllar plus tranzaksiyaları, sxem təkamülünü və zamanda səyahəti geri qaytaran cədvəl formatıdır.
  • Format mübahisəsi praktikada həll olunub: Iceberg neytral standartdır, 2026 isə Delta ilə metadata yaxınlaşmasını və Polaris-in ən yüksək səviyyəli Apache kataloq layihəsinə çevrilməsini gətirdi.
  • Yalnız fayl formatına deyil, kataloqa baxın. Kilidlənmə yenidən orada üzə çıxır.
  • Mühərrik seçimi davamlı kommersiya üstünlüyüdür: datanız vendorun sistemi içində deyil.
  • Federasiya lakehouse-u çoxillik miqrasiya olmadan praktiki edən şeydir. Əvvəlcə federasiya, sonra seçmə miqrasiya.
  • Texniki kataloqu biznes kataloqundan ayırın. Onlar fərqli problemləri həll edən fərqli alətlərdir.
  • Datanız bir bazaya sığırsa, və ya əsl probleminiz idarəetmədirsə, lakehouse qurmayın.

Yukon Labs federativ lakehouse analitikası üçün Trino üzərində Starburst tətbiq edir — tələb olunduqda on-premise.