BIAnalytics yükleniyor

BIAnalytics

Veri mimarisi rehberi

Data Lakehouse Nedir? Veri Mimarisi ve Yönetişim Rehberi

Kısa cevap

Data Lakehouse, data lake'in esnekliği ile veri ambarının yönetilen analitik kullanımını yönetişim kurallarıyla birlikte ele alan bir veri mimarisi yaklaşımıdır. Doğru yaklaşım; verinin türü, kullanıcıların soruları, erişim kuralları ve bakım sorumlulukları üzerinden belirlenir.

Son güncelleme: 14 Ekim 2026. Bu rehber, kurumsal veri yönetimi ve raporlama çalışmalarında sık karşılaşılan kavramları sadeleştirmek amacıyla hazırlanmıştır.

Data Lakehouse nedir?

Data Lakehouse, veri gölü yaklaşımının esnekliğini analitik kullanım ve yönetişim ihtiyaçlarıyla birlikte ele alan mimari bir çerçevedir. Tek başına bir ürün adı ya da tüm veri problemlerine aynı yanıt veren bir kalıp değildir.

Mimarinin amacı; farklı veri kaynaklarının hangi amaçla kullanılacağını, hangi katmanda anlam kazanacağını ve kim tarafından yönetileceğini görünür hale getirmektir.

Kimler için uygundur?

Farklı veri türleriyle çalışan, analitik kullanımını genişletmek isteyen veya veri gölü ile raporlama katmanları arasındaki sorumlulukları netleştirme ihtiyacı duyan kurumlar değerlendirme yapabilir.

Veri mühendisliği, analiz, veri yönetişimi ve iş birimleri aynı tasarımda farklı sorumluluklar üstlenebilir. Bu nedenle karar yalnızca altyapı seçimi olarak değil, veri sahipliği ve kullanım modeliyle birlikte ele alınmalıdır.

Hangi probleme yardımcı olur?

Kurumlarda veri farklı kaynaklarda, farklı ayrıntı seviyelerinde ve farklı kalite koşullarında bulunabilir. Analitik kullanıma açılacak verinin anlamı, erişimi ve sorumluluğu net değilse raporlama ve karar destek çalışmaları zorlaşabilir.

Lakehouse yaklaşımı; bu soruları veri gölü, analitik katman ve yönetişim ilişkisi içinde değerlendirmeye yardımcı olur. Veri kalitesi, kataloglama ve erişim ilkeleri bu değerlendirmeden ayrı tutulmamalıdır.

Data Lakehouse nasıl çalışır?

Bu yaklaşımda veri, kullanıma doğru aşama aşama olgunlaşır. Katman, burada yalnızca teknik bir altyapıyı değil, mantıksal bir rolü anlatır: ham veri kaynaktan geldiği haliyle tutulur, işlenmiş veri temizlenip düzenlenir, analitik kullanıma hazır veri ise iş sorularına göre şekillendirilir. Her rolün sorumlusu ayrıca belirlenir.

Bir katmandan diğerine geçerken veri kalitesinin kontrol edilmesi, verinin tanımının katalogda güncel tutulması ve erişim kurallarının gözden geçirilmesi gerekir. Bu adımlar izlenebilirliği destekler: verinin nereden geldiği ve hangi haliyle kimin kullanabileceği görülebilir.

Teknik olarak lakehouse üç parçadan oluşur. Depolama: veri, bulut nesne depolamasında (S3, ADLS, GCS gibi) Parquet gibi açık bir dosya biçiminde durur; açık biçim, dosyanın tek bir ürüne bağlı kalmadan okunabilmesi demektir.

İşlem günlüğü ve metadata katmanı: tablonun hangi dosyalardan oluştuğunu ve her değişikliği kaydeder; Delta Lake, Apache Iceberg ve Apache Hudi bu rolü görür.

Sorgu motoru: tablo üzerinde SQL çalıştıran bileşendir (Iceberg dokümanı Spark, Trino ve Flink'i örnek verir).

Günlük sayesinde okuyucu her zaman tek ve tutarlı bir sürüm görür; bu, tabloya ACID işlemi (örneğin bir yazma işleminin ya tamamen görünmesi ya hiç görünmemesi) ve eski sürümü sorgulama imkânı kazandırır. Üç biçimin sözdizimi karşılaştırması ve resmî dokümandan SQL örnekleri sayfanın en altındaki 'Delta Lake, Iceberg ve Hudi: sözdizimi karşılaştırması' bölümündedir.

Nasıl planlanır?

İlk adım, hangi iş sorularının yanıtlanacağı ve hangi veri kaynaklarının bu sorular için gerekli olduğunun belirlenmesidir. Veri tanımları, güncellik ihtiyacı, erişim kuralları ve yaşam döngüsü bundan sonra tasarlanabilir.

Mimari plan; ham verinin, işlenmiş verinin ve analitik kullanıma hazır katmanların hangi sorumlulukla ele alınacağını açıklar. Modelleme, kalite kontrolü ve veri sahipliği; teknik akış kadar önemli tasarım başlıklarıdır.

Data lake, veri ambarı ve Lakehouse farkı

Veri ambarı, modellenmiş tablolarda tutulan veridir; sütunlar ve türler (şema) veri yazılırken tanımlanır, şemaya uymayan kayıt yazılamaz. Data lake ise ham dosyaları (CSV, JSON, Parquet) olduğu gibi saklar; şema çoğunlukla dosya okunurken uygulanır.

Lakehouse, aynı göl dosyalarının üstüne işlem destekli bir tablo katmanı koyar: veri dosyada kalır, ama tabloya ACID yazma ve geçmiş sürüm sorgusu gelir. Raporlama yalnız modellenmiş tablolara dayanıyorsa ambar yeterlidir; ham dosyaları saklamak, onlara güvenli yazmak ve eski hallerini sorgulamak gerekiyorsa lakehouse devreye girer.

Ne zaman lakehouse gerekmez?

Şu dört durumda ayrı bir lakehouse katmanı çoğu zaman gerekmez.

Tek kaynak, küçük veri: Veri tek bir veritabanından geliyorsa ve o veritabanı sorguları taşıyorsa, üstüne dosya ve tablo biçimi katmanı eklemek çoğu zaman karşılığını vermez.

Yalnız SQL raporlama: İhtiyaç modellenmiş tablolar üzerinde SQL raporu almaksa veri ambarı ya da ilişkisel veritabanı bunu karşılar; ham dosya saklamaya gerek kalmaz.

Geçmiş sorgusu ve işlem ihtiyacı yok: Lakehouse'un tabloya kattığı ACID yazma ve eski sürümü sorgulama özellikleri kullanılmayacaksa bu katmanın asıl kazancı devreye girmez.

Dosya ve tablo katmanını yönetecek ekip yok: Tablo biçimleri depolama, işlem günlüğü ve sorgu motoru yapılandırması ister (örneğin Iceberg'de katalog ayarı); bunu işletecek kişi yoksa katmanı sürdürmek zorlaşır.

Kaynak sayısının artması tek başına gerekçe değildir. Ham dosya saklama, işlem desteği ya da geçmiş sorgusu ihtiyacı gerçekten doğduğunda lakehouse değerlendirmeye alınır.

İlgili danışmanlık ve rehberler

Kurulum ya da mimari değerlendirmesi arıyorsanız Data Lakehouse danışmanlığı sayfası bu hizmet niyetine ayrılmıştır.

Üç yaklaşımın kavram düzeyinde karşılaştırması için Data Warehouse, Data Lake ve Lakehouse farkı yazısına bakın.

Data Lakehouse değerlendirme özeti

Data Lakehouse, data lake esnekliği ile analitik ve yönetişim ihtiyaçlarını birlikte değerlendiren bir mimari yaklaşımı ifade eder. Karar; raporlama, veri türleri, metrik kalitesi, erişim, maliyet ve işletim sorumluluğu gerçek kullanım senaryosu üzerinden ele alınmalıdır.

Lakehouse bir teknoloji etiketi değildir; data warehouse ve data lake ihtiyacının hangi katmanlarda kesiştiği açıklığa kavuşturulmalıdır.

Bu ek bölüm, ilgili sorgu niyetini görünür hale getirmek ve kullanıcıyı doğru rehber, çözüm veya ürün bilgisine yönlendirmek için eklenmiştir.

Sık sorulan sorular

Data Lakehouse nedir?

Data Lakehouse, veri gölündeki dosyaların üstüne ACID işlem ve sürüm geçmişi getiren bir tablo katmanı kullanan veri mimarisidir. Bu katmanı Delta Lake, Apache Iceberg ve Apache Hudi gibi açık tablo biçimleri sağlar; veri ise Parquet gibi açık dosya biçimlerinde bulut depolamada kalır.

Data Lakehouse ile veri ambarı arasındaki fark nedir?

Veri ambarı veriyi modellenmiş tablolarda tutar ve şemayı veri yazılırken uygular. Lakehouse veriyi göldeki açık dosyalarda tutar ve bu dosyaların üstüne işlem destekli tablo koyar; böylece ambar tarzı SQL sorgusu ile ham dosya depolama aynı yerde buluşur.

Data Lakehouse kimler için uygundur?

Ham dosyaları bulut depolamada tutan ve aynı veriye hem SQL raporlama hem güvenli güncelleme ya da eski sürümü sorgulama isteyen ekipler için uygundur. Veri tek kaynaktan geliyor ve yalnız SQL raporlama yapılıyorsa lakehouse gerekçesi zayıftır.

Data Lakehouse hangi problemlerde kullanılır?

Üç soruna yanıt verir: göldeki dosyalara eşzamanlı yazarken okuyucunun yarım ya da tutarsız veri görmesi (ACID işlem), yanlış yazılan veriyi geri almak ve eski haliyle sorgulamak (sürüm geçmişi) ve aynı tabloya birden fazla sorgu motorunun erişmesi (Iceberg dokümanı Spark, Trino ve Flink'i örnek verir).

Data Lakehouse ne zaman değerlendirilmelidir?

Gölde tutulan veriye ACID yazma, geçmiş sürüm sorgusu ya da birden çok motordan güvenli erişim gerektiğinde. Tek kaynak, küçük veri ve yalnız SQL raporlama varsa gerekmez; ayrıntısı Ne zaman lakehouse gerekmez? bölümünde.

Veri mimarisi ihtiyacınızı paylaşın

Delta Lake, Iceberg ve Hudi: sözdizimi karşılaştırması

Üç açık tablo biçiminin Spark SQL'deki oluşturma ve geçmişe dönük sorgu sözdizimi, resmî dokümanlardaki örneklere göre:

KonuDelta LakeApache IcebergApache HudiKaynak
Tablo oluşturmaUSING DELTAUSING icebergUSING HUDI TBLPROPERTIES (primaryKey = 'uuid')Delta dokümanı, Iceberg dokümanı, Hudi dokümanı
Geçmişe dönük sorguVERSION AS OF ve TIMESTAMP AS OFTIMESTAMP AS OF ve VERSION AS OF (snapshot kimliği)TIMESTAMP AS OFDelta dokümanı, Iceberg dokümanı, Hudi dokümanı
Değişiklikleri kaydeden yapıİşlem günlüğü (transaction log)Metadata dosyaları, snapshot'lar ve manifest'lerTimeline (tablodaki tüm işlemlerin günlüğü)Delta protokolü, Iceberg spesifikasyonu, Hudi timeline

Yalnız tek biçimin dokümanında geçen ayrıntılar

Delta Lake, geçmiş saklama süresi: VACUUM çalıştırılmadıkça varsayılan olarak 30 güne kadar eski sürüme gidilebilir. Geçmiş bir sürüm için hem günlük hem veri dosyaları saklanmalıdır; günlük süresi delta.logRetentionDuration (varsayılan interval 30 days), VACUUM'un silme eşiği delta.deletedFileRetentionDuration (varsayılan interval 7 days) ile ayarlanır. Delta dokümanı

Iceberg, gizli bölümleme: tablo, sütun değerlerinden bölüm değerlerini kendisi üretir ve sorguda gereksiz bölümleri kendisi atlar. Bölümleme dönüşümleri PARTITIONED BY (bucket(16, id), days(ts), category) biçiminde tanımlanır. Iceberg dokümanı

Hudi, tablo türü: tablo türü TBLPROPERTIES içinde seçilir: type = 'cow' (Copy-on-Write) ya da type = 'mor' (Merge-on-Read). Hudi dokümanı

SQL örnekleri

Iceberg: bölümlü tablo oluşturma

CREATE TABLE prod.db.sample (
    id bigint,
    data string,
    category string)
USING iceberg
PARTITIONED BY (category);

Iceberg: tablonun geçmiş halini sorgulama

-- 26 Ekim 1986 01:21:00 anındaki hali
SELECT * FROM prod.db.table TIMESTAMP AS OF '1986-10-26 01:21:00';

-- 10963874102873 kimlikli snapshot
SELECT * FROM prod.db.table VERSION AS OF 10963874102873;

Delta Lake: sürüm numarasına ve zamana göre okuma (dokümandaki sözdizimi)

SELECT * FROM table_name VERSION AS OF version
SELECT * FROM table_name TIMESTAMP AS OF timestamp_expression

Örnekler resmî dokümanlardan alınmıştır ve Spark SQL sözdizimidir; sürüm ve katalog şartları için ilgili sayfaya bakın: Iceberg sorgu sayfası, Iceberg DDL sayfası, Delta sayfası. Iceberg dokümanına göre Spark'ta Iceberg kullanmak için önce Spark katalogları yapılandırılır.

Lakehouse seçimi için sonraki adım

Lakehouse değerlendirmesinde veri gölü esnekliği, tanımlı analitik kullanım, erişim ve yönetişim soruları birlikte yanıtlanmalıdır. Data Warehouse, Data Lake ve Lakehouse farkları rehberi bu kararı ayırmaya yardımcı olur; hizmet değerlendirmesi için Data Lakehouse danışmanlığı sayfası ayrı bir başlangıç noktasıdır.

Demo Talebi

Çözümlerimizi yakından tanımak için formu doldurun.

person
mail
phone
notes