Data warehouse ilə data lake arasındakı sərhəd 2026 etibarilə tamamilə silindi. Bunun texniki səbəbi tək texnologiya deyil, üç açıq cədvəl formatının yarışıdır: Apache Iceberg, Delta Lake və Apache Hudi. Onlardan Iceberg son 18 ayda Snowflake, AWS, Google Cloud və Microsoft Fabric-in birbaşa rəsmi dəstək elanlarıyla de-fakto standart oldu. Niyə Iceberg bu qədər önəmlidir və korporativ arxitektura üçün nə anlama gəlir?
Problem: Vendor Lock-in və Verinin Kopyalanması
Ənənəvi data warehouse-lar (Snowflake, BigQuery, Redshift) qapalı cədvəl formatı istifadə edir. Bu, performans baxımından əladır, lakin iki böyük xərcə səbəb olur: eyni veri fərqli platformalarda istifadə oluna bilmək üçün surətlənməlidir və hər hansı platformadan çıxış çətinləşir. Apache Iceberg bu problemi Parquet faylların üzərinə açıq metadata qatı qoyaraq həll edir — veri tək bir surət olaraq object storage-də (S3, ADLS, GCS) yaşayır, bir neçə motor (Spark, Trino, Snowflake, Databricks) eyni cədvəli oxuya bilir.
Iceberg-in Texniki Vədləri
Onun sürətli yayılmasına səbəb olan dörd xüsusiyyət:
- Snapshot izolyasiyası: ACID əməliyyat təminatı, schema evolution və time travel — tam olaraq data warehouse kimi.
- Gizli partition: sorğu yazarkən partition sütununu bilmək məcburi deyil; Iceberg arxa planda idarə edir.
- Schema evolution: sütun əlavə etmək, silmək, yenidən adlandırmaq tarixi cədvəlləri sındırmadan icra olunur.
- Manifest əsaslı metadata: trilyon sətirlik cədvəllərdə belə metadata sorğuları saniyələr ərzində tamamlanır.
Açıq Cədvəl Formatları Arasındakı Fərq
- Iceberg: Apache Foundation, Netflix mənşəli, bütün böyük bulud platformlarında dəstəklənir. Vendor-neytral namizəd.
- Delta Lake: Databricks mənşəli, Linux Foundation altındadır, lakin Databricks ekosistemində daha güclüdür. Yüksək performans ssenarilərində yaxşıdır.
- Hudi: Uber mənşəli, real-time upsert yüklərində güclüdür, lakin korporativ qəbulu daha məhduddur.
2026-da yeni greenfield layihələrdə Iceberg Snowflake və Databricks-in ortaq dəstəyi səbəbindən təhlükəsiz seçim oldu.
Lakehouse Arxitekturasında Praktik Təsir
Tipik bir bankçılıq DWH-ı (50–100 TB miqyasında) Iceberg + Trino + Snowflake hibridinə miqrasiya edildikdə müşahidə olunan nümunələr:
- Snowflake compute xərci 38% azaldı (ad-hoc analitika Trino-ya keçirildi).
- Eyni cədvəl Spark-da feature store kimi yenidən istifadə olundu, kopyalama lazım gəlmədi.
- Schema dəyişiklikləri istehsalı dayandırmadan həyata keçirildi.
- Tənzimləyici audit gəzişləri time travel sayəsində bir gündən iki saata düşdü.
Miqrasiya Strategiyası: Big-Bang Yox, Mərhələli
Mövcud Snowflake/BigQuery-dən Iceberg-ə keçidində tövsiyə etdiyimiz mərhələli yanaşma:
- Faza 1: Yeni veri mənbələrini Iceberg-ə yazmağa başlayın, mövcud warehouse cədvəllərinə toxunmayın.
- Faza 2: Xarici sistemlər tərəfindən çox oxunan (export-heavy) cədvəlləri Iceberg-ə köçürün.
- Faza 3: Analitik qatda açıq sorğu motoru (Trino və ya Athena) tətbiq edin.
- Faza 4: Metrik və xərc təsdiqləndikdən sonra qalan miqrasiyanı tamamlayın.
