Data Lake (Veri Gölü)

#VeriDepolama #BigData #DataLake #SchemaOnRead #Lakehouse #MLOps

Data Lake, her türdeki ham veriyi doğal formatında depolayan merkezi ve ölçeklenebilir büyük veri deposudur.

Data Lake (Türkçe: Veri Gölü), yapılandırılmış, yarı yapılandırılmamış ve yapılandırılmamış verilerin orijinal ham formatlarında depolandığı merkezi, ölçeklenebilir bir büyük veri deposudur. Geleneksel veri ambarlarının aksine, Data Lake veriye önceden bir şema uygulamaz; veriler ham hâlde saklanır ve sorgu anında şema belirlenir (schema-on-read yaklaşımı). Bu esneklik aracılığıyla log dosyaları, görüntüler, videolar, sensör verileri ve JSON/CSV gibi farklı formatlardaki veriler aynı depoda bir arada tutulabilir. "Data Lake" kavramı ilk olarak 2010 yılında Pentaho'nun CTO'su James Dixon tarafından kavramsallaştırılmıştır. Dixon, veri ambarlarını sunum için hazır su şişeleriyle kıyaslarken Data Lake'i kendi doğal ve safiyetini koruyan bir göle benzetti: tüm su kaynakları (veriler) doğal hâlde bu göle akar ve kullanıcılar ihtiyaçlarına göre bu gölden istedikleri miktarda ve formatta su alır. Bir Data Lake mimarisi genellikle birkaç katmandan oluşur. Ham veri bölgesi (Raw/Landing Zone), kaynak sistemlerden gelen verilerin sıfır değişiklikle aktarıldığı giriş noktasıdır. Rafine veri bölgesi (Curated Zone), temizleme, dönüştürme ve kalite kontrolünden geçirilmiş verileri barındırır. Tüketim bölgesi (Consumption Zone) ise iş analistleri, veri bilimciler ve makine öğrenmesi uygulamaları tarafından kullanıma hazır hâle getirilmiş verileri içerir. Data Lake'in başlıca avantajları arasında yüksek ölçeklenebilirlik, düşük birim depolama maliyeti ve veri formatı esnekliği sayılabilir. Ancak yeterli yönetim ve kataloglama araçları olmadığında "Data Swamp" (Veri Bataklığı) hâline gelebilir: verinin nereden geldiği, ne anlama geldiği ve nasıl kullanılacağı belirsizleşir. Bu sorunu çözmek için veri kataloğu (data catalog), veri soyu takibi (data lineage) ve meta veri yönetimi araçları kullanılır. Günümüzde AWS S3 + Glue, Azure Data Lake Storage Gen2, Google Cloud Storage ve Apache Hadoop HDFS popüler Data Lake altyapılarıdır. Modern Delta Lake, Apache Iceberg ve Apache Hudi açık tablo formatları ise ACID işlem desteği ve şema evrimi ekleyerek Data Lake ile Data Warehouse özelliklerini "Lakehouse" mimarisinde birleştirir. Yapay zeka ve büyük dil modeli (LLM) alanında ise Data Lake, model öncesi (pre-training) ham veri havuzu ve fine-tuning veri kümesi deposu olarak kritik bir rol üstlenmektedir. 2025-2026 döneminde Apache Iceberg, AWS Athena, Google BigQuery ve Snowflake'in yerel destek eklemesiyle kurumsal standart tablo formatına dönüşmüştür. DuckDB ise geliştirici bilgisayarında Parquet/Iceberg dosyalarını saniyeler içinde sorgulamayı mümkün kılarak veri gölü erişimini demokratikleştirmiştir. LLM'lerin büyümesiyle birlikte veri gölleri, pre-training corpus yönetiminin birincil katmanı hâline gelmiştir; 2026'da kurulan pek çok AI şirketi veri katmanı olarak doğrudan Lakehouse mimarisini tercih etmektedir.

Veri Gölü Nedir?

Veri gölü (data lake), hem yapılandırılmış hem yapılandırılmamış hem de yarı yapılandırılmamış verilerin ham biçimlerinde — JSON, CSV, Parquet, video, ses, log dosyaları — herhangi bir dönüşüm ya da şema tanımı zorunluluğu olmaksızın merkezi bir havuzda saklandığı depolama mimarisidir. 2010 yılında Pentaho'nun kurucu teknik yöneticisi James Dixon tarafından kavramsallaştırılan data lake yaklaşımı, veriye erişim anında şema uygulanması (schema-on-read) ilkesiyle çalışır; bu da veri bilimcilerin ve analistlerin ham kaynağa dokunmadan farklı sorgu desenlerini denemesine imkân tanır. AWS S3, Azure Data Lake Storage Gen2 ve Google Cloud Storage bu mimarinin en yaygın altyapı platformlarıdır.

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

  • check_circle Veri Formatı: Veri ambarı yalnızca yapılandırılmış (tablolar) veri kabul eder; veri gölü video, metin, log, sensör ve her formattaki veriyi ham biçimde saklar.
  • check_circle Şema Yaklaşımı: Ambar schema-on-write çalışır — veri yazılmadan önce şema tanımlanmalı. Göl schema-on-read kullanır — şema sorgu anında belirlenir.
  • check_circle Kullanıcı Profili: Ambar BI analistleri ve raporlama ekiplerini hedefler; göl veri mühendisleri, veri bilimciler ve ML ekiplerini karşılar.
  • check_circle Maliyet: Object storage (S3, ADLS) üzerindeki veri gölü ambardan belirgin ölçüde ucuz; ancak sorgu performansı için ek optimize katmanı (Iceberg, Delta) gerekebilir.

Temel Bileşenler ve Teknolojiler

  • check_circle Ham Depolama Katmanı: AWS S3, Azure ADLS Gen2, Google GCS veya on-prem Hadoop HDFS; petabayt ölçeğinde nesne/dosya depolama.
  • check_circle Veri Kataloğu: AWS Glue Data Catalog, Apache Atlas, Databricks Unity Catalog; verinin nerede, ne olduğunu ve kim eriştiğini izler.
  • check_circle Tablo Formatları: Apache Parquet ve ORC kolonar formatlar analitik sorgu hızını artırır; Delta Lake, Iceberg ve Hudi ACID işlem desteği ekler.
  • check_circle Sorgu Motorları: Presto/Trino, Spark SQL, AWS Athena, BigQuery Omni; veri gölünü SQL ile sorgulamayı mümkün kılar.

Yapay Zeka ve Makine Öğrenimi ile İlişkisi

Veri gölü, modern makine öğrenimi boru hatlarının birincil hammadde deposudur. LLM ön eğitimi için gerekli web taraması (Common Crawl, C4) milyonlarca ham dosyayı doğrudan veri gölünde barındırır; eğitim sürecinde bu dosyalar tokenizasyon ve filtreleme aşamalarından geçirilir. Görüntü, ses ve video tabanlı çok modlu modellerin eğitim kümeleri de ham biçimde göle yüklenerek veri artırma (data augmentation) ve etiketleme pipeline'larıyla işlenir. MLflow ve Weights & Biases gibi deney izleme araçları, model checkpointlerini ve artifact'larını doğrudan veri gölüne yazar; feature store'lar (Feast, Tecton) ise göldeki ham veriyi çevrimiçi özellik sunumuna hazırlayan bir katman oluşturur.

Veri Bataklığı Riski ve Yönetişim

Yönetilmediğinde veri gölü, nereden geldiği ve ne anlama geldiği bilinmeyen dosyaların karmaşık yığınına — veri bataklığına (data swamp) — dönüşür. Bu riski bertaraf etmek için veri kataloğu (kimin, hangi veriyi, ne amaçla eklediğinin kayıt altına alınması), veri lineage (verinin kaynaktan tüketime kadar iz bırakması) ve erişim kontrol politikaları zorunlu yönetişim katmanlarını oluşturur. Apache Atlas, AWS Lake Formation ve Databricks Unity Catalog bu ihtiyaçlara yönelik araçlardır. GDPR ve KVKK uyumluluğu için kişisel verinin maskelenmesi ve silinme hakkı (right to erasure) göl mimarisine baştan entegre edilmelidir; aksi hâlde denetim riskiyle karşılaşılır.

Lakehouse: Güncel Yönelim

Delta Lake (Databricks), Apache Iceberg ve Apache Hudi gibi açık tablo formatları veri gölüne ACID işlem desteği, zaman yolculuğu (time travel) ve şema evrimi kazandırarak 'lakehouse' mimarisini ortaya çıkardı. Lakehouse, veri gölünün düşük maliyetli ve esnek depolamasını veri ambarının güvenilir sorgu performansı ve tutarlılığıyla bir araya getirir. 2024 itibarıyla Amazon S3 Tables (Iceberg uyumlu) ve Databricks Catalog'un yaygınlaşması, lakehouse'un artık nişten ana akıma geçtiğine işaret ediyor. Bütün büyük bulut sağlayıcıları lakehouse desteği sunmakta; saf veri gölü kurulumları yerini giderek yönetilen lakehouse platformlarına bırakmaktadır. Microsoft Fabric ve Snowflake de benzer birleşik veri platformu vizyonunu benimsemiş durumda.

Sık Sorulan Sorular

  • check_circle Veri gölü ile veri ambarını birlikte kullanabilir miyim? Evet. Çoğu kurumsal mimari her ikisini birlikte kullanır: ham ve yarı işlenmiş veriler gölde tutulur, iş analitiği için hazırlanmış veri küpleri ise ambara taşınır. Bu iki katmanlı yaklaşım ELT boru hattıyla gerçekleştirilir.
  • check_circle Veri gölü kurulum maliyeti nasıl hesaplanır? Object storage maliyeti (GB başına ~$0.02/ay AWS S3 standart), veri transfer ücretleri, sorgu motoru hesaplama maliyeti (Athena: tarama başına $5/TB) ve katalog/yönetişim aracı lisansları toplam maliyeti belirler. On-prem Hadoop'a kıyasla bulut seçeneği genellikle daha düşük başlangıç maliyeti sunar.
  • check_circle Schema-on-read ne demek ve ne zaman avantajlı? Verinin şeması yazma sırasında değil, sorgu çalıştırılırken uygulanır. Bu, formatı henüz bilinmeyen ya da farklı ekiplerin farklı şema yorumlarıyla çalışacağı durumlarda esneklik kazandırır; ancak veri kalitesi yönetimi daha dikkatli yapılmalıdır.
  • check_circle Delta Lake ile Apache Iceberg arasında ne tercih etmeli? Databricks ekosistemi ağırlıklıysa Delta Lake entegrasyonu daha kolay. Çoklu motor ortamlarında (Spark + Trino + Flink) Iceberg motor-agnostik desteğiyle öne çıkıyor. İkisi de ACID işlem, time travel ve şema evrimi sunuyor; seçim ekosistem bağımlılığına göre yapılır.
  • check_circle Veri gölü KVKK uyumluluğu için nasıl yapılandırılır? Kişisel veri sütunları maskelenmeli ya da tokenize edilmeli; silme hakkı taleplerine karşılık 'tombstone' kayıt mekanizması veya Delta Lake delete ile fiziksel silme uygulanmalı. Veri lineage araçları ile hangi pipeline'ların kişisel veri işlediği iz bırakılmalı.
  • check_circle Küçük ekipler için veri gölü mantıklı mı? Veri hacmi TB seviyesinin altındaysa ve sorgu ihtiyacı basitse managed veri ambarı (BigQuery, Redshift) daha az yönetim yükü getirir. Veri gölü çok modlu ham veri, ML pipeline ve esneklik gerektiren durumlarda değer kazanır; küçük ekipler için Databricks Community Edition iyi bir başlangıç noktasıdır.