Data Lake (Veri Gölü)

Bir data lake (veri gölü), verinin önceden tanımlanmış bir şemaya göre yapılandırılması gerekmeden — yapılandırılmış (veritabanı export'ları), yarı yapılandırılmış (JSON, CSV logları) ve yapılandırılmamış (görseller, PDF'ler, ses, ham metin) verileri kendi doğal formatında — devasa ölçekte ve düşük maliyetle tutan merkezi bir depolama havuzudur. Bu, bir data warehouse'dan (veri ambarı) temel farkıdır: bir warehouse "schema-on-write" (yazarken şema) yaklaşımını dayatır — veri içeri girmeden önce temizlenip yapılandırılmalıdır — data lake ise "schema-on-read" (okurken şema) uygular: veri olduğu gibi içeri girer, yapı ve anlam daha sonra, sorgu veya işleme zamanında, onu okuyan araç tarafından uygulanır. AI/SaaS geliştiricileri için neden önemli: data lake'ler AI çağında özellikle önem kazandı, çünkü AI özellikleri için ham malzemenin büyük kısmı — belgeler, sohbet transkriptleri, yüklenen dosyalar, model çıktıları, değerlendirme (eval) logları — ilişkisel tablolara düzgün oturmuyor ve depolamadan önce buna sıkı bir şema dayatmak, verinin ilk geldiği anda genellikle bilinmeyen "tam olarak nasıl kullanılacağı" sorusuna baştan karar vermek anlamına gelir. Veriyi önce ham haliyle bir data lake'te (genellikle tanımlı bir klasör/partition kuralına sahip S3 gibi basit bir object storage) saklamak, opsiyonel kalma imkânı korur: altı ay sonra ortaya çıkan yeni bir AI özelliği, veri ilk toplandığında kimsenin öngöremediği bir şekilde aynı ham geçmiş veriyi yeniden işleyebilir. Nasıl çalışır: data lake'ler genellikle doğrudan object storage üzerine (S3, Google Cloud Storage, Azure Blob Storage) açık dosya formatları (Parquet, Avro, JSON) kullanılarak ve sorgu motorlarının tüm veri kümesini değil yalnızca ilgili partition'ları taramasını sağlayan bir partition şeması (ör. `s3://lake/events/year=2026/month=07/day=02/`) altında organize edilerek inşa edilir. Apache Spark, Presto/Trino veya AWS Athena gibi sorgu motorları, ayrı bir yükleme (load) adımı olmadan doğrudan gölde duran dosyalara karşı SQL çalıştırabilir; bu da "data lake" ile "data warehouse" arasındaki çizgiyi bulanıklaştırır — genellikle "lakehouse" (Databricks tarafından yaygınlaştırılmış) olarak adlandırılan hibrit bir model, göl tarzı ucuz ve esnek ham depolamanın üzerine warehouse benzeri transactional garantiler ve şema zorlaması ekler. Somut örnek: bir AI SaaS ürünü, her ham LLM istek/yanıt çiftini (prompt, model, token sayısı, gecikme, çıktı) tarihe göre partition'lanmış, S3 tabanlı bir data lake'e JSON dosyaları olarak kaydeder; bunu, üzerinde tam olarak hangi analizleri çalıştıracağına karar vermeden çok önce yapar. Aylar sonra ekip, model davranışını versiyonlar arasında karşılaştıran bir prompt-regresyon değerlendirme sistemi kurmak istediğinde, göldeki geçmiş ham JSON verisine karşı doğrudan Athena sorguları çalıştırır — veri toplama anında kimsenin tanımlamadığı bir kullanım senaryosu için önceden bir ETL pipeline'ı kurmaya gerek kalmamıştır.