Veri Gölü ile Veri Lakehouse Arasındaki Fark

Ortak zemin: ucuz nesne depolamada açık formatlı veri

Veri gölü (data lake), her türden veriyi (yapılandırılmış tablolar, günlük dosyaları, JSON olayları, görüntü ve metin) ham hâliyle, düşük maliyetli ve ölçeklenebilir bir depolamada tutan mimaridir. Bugün veri gölleri çoğunlukla Amazon S3, Azure Data Lake Storage ya da Google Cloud Storage gibi bulut nesne depolama servisleri üzerinde, Parquet gibi açık dosya formatlarıyla kurulur. Şema okuma anında uygulanır (schema-on-read).

Veri lakehouse ise Databricks'in tanımıyla veri göllerinin esnekliğini, maliyet verimliliğini ve ölçeğini veri ambarlarının veri yönetimi ve işlem (transaction) desteğiyle birleştiren açık bir veri yönetimi mimarisidir. Lakehouse, aynı nesne depolamanın üzerine bir metadata ve tablo katmanı ekler: Delta Lake, Apache Iceberg ya da Apache Hudi gibi açık tablo formatları bu katmanı sağlar.

Yani lakehouse, veri gölünü ortadan kaldırmaz; onun üzerine kurulur. Depolama aynı kalır, değişen şey verinin tablo olarak nasıl yönetildiği, nasıl güncellendiği ve kimlerin hangi amaçla doğrudan kullanabildiğidir.

Ölçüt ölçüt karşılaştırma

• İşlem güvenliği: Veri gölü / Databricks'e göre veri gölleri işlemleri (transaction) desteklemez; aynı anda yazma ve okuma, yarım kalan işler tutarsız veri bırakabilir. Veri lakehouse / Delta Lake gibi katmanlar ACID uyumlu işlemler sunar; yazma ya tamamen başarılı olur ya da hiç görünmez.
• Şema: Veri gölü / şema okuma anında yorumlanır; yanlış tipte ya da eksik sütunla gelen dosya sessizce göle düşer. Veri lakehouse / yazma anında şema zorlaması ve kontrollü şema evrimi; beklenmeyen veri tabloya girmeden yakalanır.
• Güncelleme ve silme: Veri gölü / dosya tabanlı olduğu için tek bir kaydı güncellemek ya da silmek zordur; genellikle bölümler yeniden yazılır. Veri lakehouse / MERGE, UPDATE ve DELETE işlemleri tablo düzeyinde yapılır; kişisel veri silme talepleri gibi uyum gereksinimleri karşılanabilir.
• Sürümleme: Veri gölü / dosyaların geçmiş hâllerini izlemek ayrıca kurgulanmalıdır. Veri lakehouse / tablo sürümleri ve işlem günlüğü sayesinde önceki bir sürüme sorgu atmak (time travel) ve değişikliği geri almak mümkündür.
• İş yükleri: Veri gölü / veri bilimi ve makine öğrenmesi için uygun; doğrulanmamış yapısı nedeniyle BI raporlamada sınırlı kullanılır. Veri lakehouse / aynı veri üzerinde BI raporlama, SQL analitiği, akış işleme ve makine öğrenmesi birlikte çalışır.
• Yönetişim: Veri gölü / erişim çoğunlukla klasör ve dosya izinleriyle yönetilir; veri soy ağacı (lineage) ve katalog ayrı araç ister. Veri lakehouse / Unity Catalog gibi birleşik kataloglarla tablo, sütun düzeyinde yetki, soy ağacı ve denetim tek yerden yönetilir.
• Performans: Veri gölü / küçük dosya sorunu ve bölümleme hataları sorguları yavaşlatabilir. Veri lakehouse / dosya sıkıştırma, istatistikler ve veri yerleşimi optimizasyonlarıyla analitik sorgular hızlandırılır.

Veri gölü ne zaman yeterlidir?

Her veri gölünün lakehouse'a dönüşmesi gerekmez. Aşağıdaki durumlarda sade bir veri gölü işini görür:

• Ham verinin uzun süre ucuza arşivlenmesi asıl amaçsa (günlük dosyaları, sensör ham verisi, yedek kopyalar).
• Veri ağırlıklı olarak yapılandırılmamışsa (görüntü, ses, belge) ve tablo olarak sorgulanmayacaksa.
• Kullanıcılar yalnız veri mühendisleri ve veri bilimcilerse, veriyi kendi not defterlerinde işleyip sonuç üretiyorlarsa.
• Veri yalnız eklenerek büyüyor, güncelleme ve silme ihtiyacı yoksa.

Bu senaryolarda bile göl, iyi bir klasör ve adlandırma standardı, katman ayrımı (ham, işlenmiş, sunulan), yaşam döngüsü kuralları ve erişim politikalarıyla düzenli tutulmalıdır. Aksi hâlde, kimsenin neyin nerede olduğunu bilmediği bir "veri bataklığına" dönüşür.

Lakehouse'a ne zaman geçilmeli?

Lakehouse'a geçişi tetikleyen işaretler genellikle somut sorunlar olarak görünür:

• İş birimleri gölden doğrudan rapor almak istiyor, ancak veri tutarsız olduğu için ayrı bir veri ambarına kopyalanıyor ve ayrı sistemlerin maliyeti ve senkron sorunu doğuyor.
• Gece çalışan bir yükleme işi yarıda kaldığında raporlar eksik veriyle üretiliyor.
• KVKK gibi düzenlemeler nedeniyle belirli kişilerin verisini silmek gerekiyor, ancak hangi dosyalarda olduğu bilinmiyor.
• Akış verisi (anlık olaylar) ile toplu veri aynı tablolarda birleştirilmek isteniyor.
• Makine öğrenmesi modelleri ile raporlar farklı kopyalardan beslendiği için sonuçlar birbirini tutmuyor.

Örneğin bir perakende şirketinin veri gölünde kasa işlemleri, e-ticaret olayları ve stok hareketleri ayrı klasörlerde birikiyor olsun. Finans raporları için bu veri her gece ayrı bir ambara aktarılıyor, iade işlemleri ise geç geldiği için düzeltmeler elle yapılıyor. Lakehouse mimarisinde aynı veri Delta tablolarına dönüştürülür, iadeler MERGE ile işlenir, finans ekibi SQL ile, veri bilimi ekibi ise aynı tablolardan talep tahmini modelleriyle çalışır.

Geçiş nasıl planlanır: medallion yaklaşımı

Lakehouse'a geçiş genellikle büyük bir taşıma yerine katmanlı ve aşamalı bir dönüşüm olarak yapılır. Microsoft'un Azure Databricks belgelerinde de yer alan medallion mimarisi bu dönüşüm için yaygın bir tasarım desenidir: veri, katmanlardan geçtikçe kademeli olarak iyileştirilir ve zenginleştirilir.

• Bronze katman: kaynaklardan gelen ham veri, değiştirilmeden ama tablo formatında saklanır; kaynak izlenebilirliği korunur.
• Silver katman: veri temizlenir, tipleri düzeltilir, tekilleştirilir ve kaynaklar arası birleştirilir; şema kuralları burada uygulanır.
• Gold katman: iş birimlerinin raporlama ve analiz ihtiyacına göre özetlenmiş, iş diliyle adlandırılmış tablolar oluşturulur.

Pratik adımlar şöyle sıralanabilir: en çok kullanılan ve en çok sorun çıkaran veri kümesini seçmek, açık tablo formatını belirlemek, kataloğu ve erişim modelini kurmak, ilk akışı bronze katmandan gold katmana kadar uçtan uca çalıştırmak ve ardından diğer veri kümelerini aynı desene taşımak.

Sık yapılan hatalar

• Lakehouse'u bir ürün sanmak: lakehouse bir mimari desendir; bir platform satın almak, şema, katman ve yönetişim kararlarını vermeden sorunları çözmez.
• Tablo formatını seçmeden işe başlamak: Delta Lake, Iceberg ya da Hudi arasında seçim; kullanılan sorgu motorları, bulut ve araç ekosistemine göre baştan yapılmalıdır.
• Küçük dosya sorununu ihmal etmek: sık ve küçük yazmalar sorgu performansını düşürür; düzenli sıkıştırma ve bakım işleri planlanmalıdır.
• Gold katmanını atlamak: iş kullanıcılarına silver katmanı doğrudan açmak, karmaşık birleştirmelerin her raporda farklı yapılmasına yol açar.
• Yönetişimi sona bırakmak: katalog, sahiplik ve erişim kuralları ilk tablo oluşturulurken tanımlanmazsa lakehouse da kısa sürede bataklığa döner.

Mindset programlarında veri gölü ve lakehouse

Veri Lakehouse Mimarisi eğitimi; veri mimarisinin evrimi ve lakehouse kavramı, Delta Lake ile güvenilir veri katmanı, Apache Iceberg ile açık tablo formatı, medallion mimarisi (bronze, silver, gold), akış verisi ve lakehouse entegrasyonu, sorgu motoru ve performans optimizasyonu ile veri yönetişimi ve güvenliği modüllerinden oluşur.

Veri gölü temelinden başlamak isteyenler için Yapay Zeka ve Veri Gölü Mimarisi eğitimi veri gölü mimarisi temelleri, açık tablo formatları (Delta Lake, Iceberg, Hudi), sorgulama motorları, kataloglama ve maliyet yönetimini; Delta Lake ile Güvenilir Veri Gölü eğitimi ise işlem günlüğü, MERGE işlemleri, zaman yolculuğu ve akış ile toplu işlemenin birleşimini uygulamalı olarak ele alır.