Table format Parquet fayllarından ibarət qovluğu baza cədvəli kimi davranan bir şeyə çevirən qatdır: atomar commit-lər, sxem təkamülü, time travel və yazıcılar işləyərkən oxuyucular üçün ardıcıl mənzərə. Apache Iceberg, Delta Lake və Apache Hudi bunu edən üç açıq formatdır və aralarında seçim geri qaytarılması həqiqətən çətin olan az sayda lakehouse qərarından biridir.

Geri qaytarılması ona görə çətindir ki, format datanızı hansı engine-lərin səmərəli oxuya biləcəyini, hansı kataloqu işlətdiyinizi və vendor dəyişəndə platformanızın nə qədərinin daşına biləcəyini müəyyən edir. Lakehouse-dakı qalan hər şey — engine, orkestrator, BI aləti — bir rüb ərzində dəyişdirilə bilər. Table format isə çoxillik öhdəlikdir.

İndi qurmağa başlayan əksər təşkilat üçün qısa cavab: konkret səbəbiniz yoxdursa, Iceberg. Yazının qalanı həmin səbəblərin nə olduğu və fərqlərin hələ də nə qədər əhəmiyyət daşıdığı haqqındadır.

Hər üçünün verdiyi

Ortaq zəmini müəyyən etməyə dəyər, çünki vendor materialı paylaşılan imkanları fərqləndirici kimi təqdim etməyə meyllidir.

Hər üçü obyekt storage üzərində ACID tranzaksiyalar verir — commit ya tam yerə düşür, ya heç düşmür və oxuyucular yarımçıq yazılmış vəziyyəti heç vaxt görmür. Hər üçü sxem təkamülünü dəstəkləyir, yəni sütun əlavə etmək, adını dəyişmək və ya silmək dataseti yenidən yazmağı tələb etmir. Hər üçü time travel dəstəkləyir — cədvəli müəyyən andakı halında sorğulamağa imkan verir, ki bu, formatı auditor qarşısında ən çox əsaslandıran imkandır. Və hər üçü sətir səviyyəli update və delete əməliyyatlarını idarə edir — obyekt storage-dakı sadə Parquet bunu etmir, silinmə tələbləri kimi tənzimləyici öhdəlikləri ümumiyyətlə həll edilə bilən edən də elə budur.

Tələbiniz yuxarıdakılardan hər hansı biridirsə, hər üçü ona cavab verir. Fərqlər yazma nümunələrində, kataloq arxitekturasında və ekosistemdədir.

Əslində nə ilə fərqlənirlər

Apache Iceberg engine neytrallığı ətrafında layihələndirilib. Metadata-sı hər engine-in ortaq runtime olmadan oxuya biləcəyi manifest fayllarından ibarət ağacdır — Trino, Spark, Flink, Snowflake, Databricks və əksər bulud anbarının onu nativ dəstəkləməsinin səbəbi budur. Çox böyük cədvəlləri yaxşı idarə edir, gizli partisiyalaşdırması bütöv bir istifadəçi səhvi sinfini aradan qaldırır və spesifikasiyası tək dominant vendor tərəfindən deyil, bir neçə ciddi töhfəçi ilə açıq şəkildə inkişaf etdirilir.

Delta Lake Databricks-də yaranıb və ən dərin inteqrasiyası hələ də oradadır. Tranzaksiya log dizaynı sadə və effektivdir, Databricks runtime-ı daxilində performansı əladır, həmin runtime-dan kənar ekosistemi isə xeyli yaxşılaşsa da, hələ Iceberg-dən geridədir. Platformanız Databricks-dirsə, Delta ən az müqavimətli yoldur və ona qarşı arqumentlər əsasən nəzəridir.

Apache Hudi konkret problem üçün qurulub: yüksək tezlikli upsert-lər və mərhələli emal, xüsusən əməliyyat bazalarından change data capture. Copy-on-write və merge-on-read cədvəl tipləri yazma xərci ilə oxuma xərci arasındakı güzəşt üzərində real nəzarət verir və streaming ingestion iş yükləri üçün həqiqətən güclü qalır. Ekosistemi üçü arasında ən dardır, əməliyyat mürəkkəbliyi isə ən yüksək.

2026-da nə dəyişdi

İndi bu qərarı verən hər kəs üçün iki hadisə əhəmiyyət daşıyır və hər ikisi fərqi daraldır.

Formatlar texniki olaraq yaxınlaşdı. Iceberg Summit 2026 tədbirində v4 spesifikasiyası ilə yanaşı Delta 5.0-ın Iceberg v4 ilə eyni adaptiv metadata ağac strukturunu mənimsədiyi qeyd olundu. İki format müstəqil şəkildə eyni metadata dizaynına gəlirsə, birini digərindən performans əsasında seçmək üçün texniki arqument ciddi şəkildə zəifləyir.

Kataloq qatı açıldı. Apache Polaris 2026-cı ilin fevralında Apache-nin yuxarı səviyyəli layihəsinə çevrildi və Iceberg-ə açıq, vendor-neytral kataloq implementasiyası qazandırdı. Bu, göründüyündən vacibdir, çünki lock-in əslində formatda deyil, kataloqda yaşayır. Table format fayl düzülüşüdür; kataloq isə engine-lərə hansı faylların cari cədvəli təşkil etdiyini deyən xidmətdir və mülkiyyət kataloq açıq formatı faktiki olaraq əsir edə bilər.

Praktiki nəticə: kataloqu formatla eyni ciddiliklə qiymətləndirin. Qapalı kataloqun arxasındakı açıq format marketinqin nəzərdə tutduğundan az daşınabilirlik verir.

Qərar, dürüst şəkildə

Iceberg seçin — mövcud öhdəliyiniz olmadan indi qurursunuzsa, birdən çox sorğu engine-i işlədəcəyinizi gözləyirsinizsə, yaxud engine neytrallığının strateji dəyəri varsa. Bu, əksər təşkilatı əhatə edir, bu bazarda isə demək olar hamısını — çünki qarışıq estate üzrə federated giriş adətən tələbin özüdür.

Delta Lake seçin — platformanız Databricks-dirsə və Databricks olaraq qalacaqsa. İnteqrasiya üstünlüyü realdır və heç vaxt istifadə etməyəcəyiniz opsionallığı qorumaq üçün Iceberg seçmək faydasız xərcdir.

Hudi seçin — dominant iş yükünüz yüksək tezlikli upsert ingestion-dursa (əməliyyat sistemlərindən miqyaslı CDC) və onu istismar etməyə sərmayə qoyacaq mühəndisləriniz varsa. Bu profildən kənarda daha az fayda üçün daha çətin idarə olunan platformadır.

Benchmark-lara əsasən seçməyin. Dərc olunmuş müqayisələr demək olar həmişə maraqlı tərəf tərəfindən, ona uyğun seçilmiş iş yükləri üzərində hazırlanır və real miqyasda fərqlər eyni formatın iki konfiqurasiyası arasındakı fərqdən kiçikdir.

Bunun Azərbaycan tətbiqi üçün mənası

Üç yerli amil çəkiləri dəyişir.

On-premise obyekt storage. Bu formatlar adətən S3-ə qarşı təsvir olunur, nəzarət altındakı bank isə MinIO, Ceph və ya on-premise NAS işlədir. Hər üç format işləyir, amma S3-dən fərqli storage qarşısında yetkinlikləri fərqlidir və düzgün test vendorun bulud benchmark-ı yox, sizin öz storage qatınızdır. Öhdəlik götürməzdən əvvəl faktiki obyekt storage-ınızda atomar rename və ya conditional-put semantikasını yoxlayın; on-premise tətbiqlərin əslində sındığı yer buradır.

Federation format performansından vacibdir. Praktiki arxitektura həm lakehouse-u, həm core banking sistemini bir ifadədə oxuyan sorğu engine-idirsə — adətən elədir — engine neytrallığı istənilən formatın pik ötürücülüyündən dəyərlidir. Bu, Iceberg-ə işarə edir və Trino-nun ən geniş mənbə sistem çeşidini idarə edən engine olması ilə uzlaşır.

Time travel uyğunluq funksiyasıdır. Nəzarətçiyə cədvəlin hesabat tarixindəki dəqiq vəziyyətini snapshot nüsxələri saxlamadan göstərə bilmək real suala real cavabdır. Saxlama müddətini şüurlu təyin edin: çox qısa olsa imkanı itirirsiniz, çox uzun olsa storage limitsiz böyüyür və şəxsi məlumatı qanuni müddətdən artıq saxlayırsınız.

Formatlar arası miqrasiya

Mümkündür və pulsuz deyil — qərarın vaxt istəməsinin səbəbi də budur.

Dataseti formatlar arasında çevirmək mexaniki olaraq sadədir — metadata-nı, bəzən faylları yenidən yazırsınız. Çevrilməyən şey ətrafdakı estate-dir: formata xas yazma məntiqi olan pipeline-lar, engine konfiqurasiyaları, kataloq inteqrasiyaları və komandadakı əməliyyat biliyi. Büdcəni dataya yox, estate-ə ayırın.

Praktiki azaldıcı tədbir formata xas məntiqi nazik saxlamaqdır. Ağlabatan yerdə abstraksiya vasitəsilə yazın, özünü ödəmədikcə hər hansı formatın eksklüziv funksiyalarından asılı olmayın və kataloq seçimini açıq saxlayın.

Əsas məqamlar

  • Table format həqiqətən yapışqan az sayda lakehouse qərarından biridir — engine uyğunluğunu və lock-in-in harada oturduğunu müəyyən edir.
  • Hər üçü ACID, sxem təkamülü, time travel və sətir səviyyəli update verir. Vendor materialı bu ortaq zəmini fərqləndirici kimi təqdim edir.
  • Engine neytrallığı üçün defolt Iceberg-dir; Databricks-ə bağlısınızsa Delta; konkret olaraq yüksək tezlikli upsert ingestion üçün Hudi.
  • Formatlar 2026-da yaxınlaşdı — Delta 5.0 Iceberg v4 ilə eyni adaptiv metadata ağacını mənimsəyir — bu isə performans arqumentlərini zəiflədir.
  • Lock-in formatda yox, kataloqda yaşayır. Apache Polaris-in 2026-cı ilin fevralında yuxarı səviyyəyə keçməsi istənilən format funksiyası qədər vacibdir.
  • On-premise: formatı bulud benchmark-ında yox, faktiki obyekt storage-ınızda yoxlayın. Bu tətbiqlərin sındığı yer oradır.

Lakehouse-ları açıq formatlar üzərində, sorğu qatı olaraq Starburst ilə və on-premise qururuq. Əlaqəli oxu: data lakehouse arxitekturası və Starburst, Dremio və Databricks müqayisəsi.