Veri gölü (data lake), sensör akışları, log dosyaları, görüntüler, PDF'ler ve sistem dökümleri gibi her türden veriyi önceden bir şemaya sokmadan, ham hâliyle ve düşük maliyetli depolamada saklayan merkezi veri alanıdır. Veri ambarından farkı, yapının veri okunurken kurulmasıdır. Rapor için ambar, keşif ve yapay zeka için göl uygundur; olgunlaşmış veri altyapılarında ikisi genellikle birlikte çalışır.
Veri gölü nedir ve bu soru nereden çıkar?
Bir üretim işletmesi makinelerine sensör taktırır; titreşim, sıcaklık ve akım verisi saniyede birkaç kez akmaya başlar. Kalite ekibi hatalı ürün fotoğraflarını saklamak ister, bakım ekibi PLC alarm loglarını, satış ekibi de müşteri e-postalarından çıkarılan talepleri. Bu verilerin hiçbiri ERP'nin tablolarına ya da mevcut veri ambarının satır-sütun yapısına rahatça sığmaz.
İlk refleks genellikle bir dosya sunucusunda "ham veri" klasörü açmaktır. Birkaç ay sonra klasörde kimin ne attığı, hangi dosyanın güncel olduğu ve içinde kişisel veri bulunup bulunmadığı bilinmez hâle gelir. Veri gölü sorusu tam bu noktada sorulur: Bu veriyi nerede, hangi düzende ve hangi kurallarla saklamalıyız ki sonradan işe yarasın?
Veri gölü bu soruya "her şeyi tek yerde, ucuz depolamada, kaynağındaki biçimiyle tut; ihtiyaç doğduğunda işle" diye yanıt verir. Yanıtın gücü esneklikte, riski de düzensizlikte yatar.
Veriyi saklayıp kullanamamanın maliyeti
Veri toplamak artık zor değil; zor olan, toplanan veriye güvenmek ve onu karar sürecine sokmak. Türkiye'de bu açık büyük: TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2025 sonuçlarına göre 10 ve daha fazla çalışanı olan girişimlerin yalnızca %6,5'i iş zekası (BI) yazılımı kullanıyor. Yani üretilen verinin büyük kısmı rapora bile dönüşmüyor.
Toplanan veri düzensiz saklandığında sorun güvene dönüşür:
Drexel Üniversitesi LeBow İşletme Fakültesi ile Precisely'nin 565 veri ve analitik uzmanıyla yaptığı araştırmaya göre yapay zeka girişimlerini engelleyen en büyük veri sorunu %62 ile veri yönetişimi eksikliği; verisini yapay zekaya hazır gören kurumların oranı yalnızca %12. (Drexel LeBow & Precisely, 2025 Outlook: Data Integrity Trends and Insights)
Aynı araştırmada katılımcıların %67'si kurumunun kullandığı veriye tam güvenmediğini söylüyor. Veri kalitesi uzmanı Thomas C. Redman ise MIT Sloan Management Review'daki makalesinde kötü verinin çoğu şirkete maliyetini gelirin %15–25'i olarak tahmin ediyor (2017). Bulutta kurulan göllerde bir kalem daha var: Flexera 2026 State of the Cloud Report verisine göre boşa giden bulut harcaması oranı beş yıl sonra ilk kez artarak %29'a çıktı. Yaşam döngüsü kuralı olmadan biriken ve kimsenin sorgulamadığı terabaytlar da bu tür israfı büyütür.
Veri gölü ile veri ambarı arasındaki fark
İki yapı birbirinin rakibi değil; farklı soruları yanıtlar. Veri ambarı "geçen çeyrek bölge bazında kâr marjı neydi?" sorusuna hızlı ve tutarlı yanıt verir. Veri gölü ise "makine arızasından önceki 72 saatte sensör verisinde bir örüntü var mı?" gibi henüz sorusu tam kurulmamış keşiflere alan açar.
| Ölçüt | Veri gölü | Veri ambarı |
|---|---|---|
| Veri türü | Yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış (JSON, log, görüntü, ses, PDF) | Yapılandırılmış, temizlenmiş tablolar |
| Şema | Okurken kurulur (schema-on-read) | Yazarken kurulur (schema-on-write) |
| Birincil kullanıcı | Veri mühendisi, veri bilimci, yapay zeka modelleri | Yönetici, analist, BI araçları |
| Tipik iş | Keşif, model eğitimi, ham arşiv, yeniden işleme | Standart raporlar, KPI, dönem karşılaştırması |
| Depolama | Nesne depolama ya da dağıtık dosya sistemi, açık dosya biçimleri | İlişkisel veya sütun tabanlı veritabanı |
| En büyük risk | Düzensizlik ve "veri bataklığı" | Katılık; yeni veri türü eklemek yavaş |
Lakehouse ise iki yapıyı birbirine yaklaştıran bir mimaridir. Veri, gölün ucuz depolamasında açık tablo biçimleriyle tutulur; üzerine işlem (transaction) desteği, şema kontrolü ve sürümleme eklenir. Böylece aynı veri hem keşif hem raporlama için kullanılabilir. Veriyi göle önce ham yükleyip dönüşümü sonra yapmak ise ELT yaklaşımının göl tarafındaki karşılığıdır; iki yaklaşımın ayrımını ETL mi ELT mi yazımızda ele aldık.
Veri gölü bataklığa nasıl dönüşür?
"Veri bataklığı" (data swamp), içinde veri olduğu bilinen ama kimsenin bulamadığı, güvenmediği ya da kullanmaya cesaret edemediği göle verilen addır. Genellikle üç nedenden doğar. Birincisi, yüklenen dosyaların kaynağı, sahibi ve anlamı kaydedilmez. İkincisi, ham veri ile işlenmiş veri aynı klasörlerde karışır.
Üçüncüsü erişim kuralıdır. Kişisel veri içeren kamera kayıtları ya da müşteri yazışmaları herkesin okuyabildiği alana düşer. Türkiye'de 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), verinin amaçla sınırlı işlenmesini ve gereğinden uzun saklanmamasını ister; "belki bir gün lazım olur" diye biriktirilen kişisel veri, gölde hukuki riske dönüşür. Bulut bölgesi yurt dışındaysa yurt dışına veri aktarımı kuralları da devreye girer.
Bataklığı önlemenin yolu teknoloji seçmekten önce kural koymaktır; bu, veri yönetişimi çerçevesinin göle uygulanmış hâlidir.
Veri gölü kurmanın 7 adımı
- Kullanım senaryosuyla başlayın. "Her şeyi toplayalım" yerine iki üç somut soru yazın: arıza öncesi sensör örüntüsü, hatalı ürün görüntüleriyle model eğitimi, beş yıllık ham sipariş geçmişinin yeniden işlenmesi gibi.
- Kaynakları ve hacmi envanterleyin. Hangi sistem hangi biçimde, ne sıklıkla, ne kadar veri üretiyor; hangisinde kişisel veri var? Bu envanter depolama ve bütçe kararının girdisidir.
- Katmanları ayırın. Ham (bronze), temizlenmiş (silver) ve kullanıma hazır (gold) alanlar ayrı tutulur; bu düzene medallion mimarisi de denir. Ham katmana yazılan dosya değiştirilmez; hata olursa yeniden işlenir.
- Açık dosya ve tablo biçimleri seçin. Parquet gibi sütun tabanlı biçimler ve Delta Lake, Apache Iceberg gibi açık tablo biçimleri, veriyi tek bir araca kilitlemeden sorgulanabilir kılar.
- Kataloğu ilk günden kurun. Her veri setinin sahibi, kaynağı, güncelleme sıklığı, alan açıklamaları ve kişisel veri etiketi kayıt altına alınır. Katalogsuz göl, birkaç ay içinde bataklığa döner; veri kataloğu ve veri sözlüğü yazımız nereden başlanacağını anlatır.
- Erişim ve saklama kurallarını yazın. Rol bazlı yetki, maskeleme, silme ve imha süreleri tanımlanır; kişisel veri içeren alanlar ayrı tutulur.
- Maliyeti ve kaliteyi izleyin. Depolama sınıfları (sık ve seyrek erişilen), yaşam döngüsü kuralları ve yükleme anında kalite kontrolleri kurulur. Mükerrer ve hatalı kayıtların temizliği gold katmana çıkmadan yapılır. Göl üzerine kurulacak raporlama katmanının bütçe kalemleri için veri ambarı maliyet kalemleri yazısına bakabilirsiniz.
Hangisi size uygun? Hızlı kontrol
- Verinizin büyük kısmı ERP, CRM ve muhasebe tablolarıysa ve ihtiyaç raporsa: önce veri ambarı.
- Sensör, log, görüntü ya da belge verisi hızla büyüyorsa ve yapay zeka projesi planlanıyorsa: veri gölü, üzerine raporlama için ambar ya da data mart.
- Hem keşif hem raporlama aynı veri üzerinde isteniyor ve ekipte veri mühendisliği yetkinliği varsa: lakehouse.
- Tek kaynak, az veri ve basit raporlar varsa: hiçbiri; Excel'den BI'a geçiş yeterli olabilir.
Veri gölünün işe yaradığı üç senaryo
Kestirimci bakım. Sensör verisi saniyelik aralıklarla gelir ve aylar boyu birikmesi gerekir; model ancak geçmiş arızalarla birlikte eğitilebilir. Ham veri gölde tutulur, kestirimci bakım modelleri oradan beslenir, özet göstergeler ise yönetici paneline çıkar.
Kurumsal belge ve yapay zeka. Sözleşmeler, teknik şartnameler ve prosedürler gölde metin ve meta veriyle saklandığında, RAG tabanlı kurumsal LLM asistanları için güvenilir bir kaynak oluşur. Erişim yetkisi belge düzeyinde korunmazsa asistan, kullanıcının görmemesi gereken belgeyi özetleyebilir.
Uzaktan izleme ve saha verisi. Dağıtık tesislerden gelen ölçümler önce göle, ardından gerçek zamanlı raporlama katmanına akar. Ham kayıt saklandığı için bir hesaplama hatası sonradan fark edildiğinde geçmiş yeniden işlenebilir.
Digital Bridge'de bu işi nasıl yapıyoruz?
Veri gölü projesine depolama satın alarak değil, soru yazarak başlıyoruz. Süreç dört aşamadan oluşur:
- Keşif ve ihtiyaç analizi. Kaynak sistemleri, veri hacmini, kişisel veri içeren alanları ve yanıtlanmak istenen soruları birlikte çıkarıyoruz. Sonuçta göl mü, ambar mı, ikisi birden mi gerektiğini gerekçesiyle yazıyoruz; gerekmiyorsa bunu da söylüyoruz.
- Mimari ve altyapı kararı. Bulut geçiş ve altyapı danışmanlığı kapsamında yerinde, bulutta ya da hibrit kurulumu; depolama sınıflarını ve veri çıkış maliyetini birlikte değerlendiriyoruz. Bütçe tarafının ayrıntıları için buluta geçiş maliyet kalemleri yazımıza bakabilirsiniz.
- Pilot. Tek bir kullanım senaryosuyla, örneğin bir üretim hattının sensör verisiyle, ham–temiz–hazır katmanları ve kataloğu kuruyoruz. Pilot çıktısı bir rapor ya da model olarak kullanıcının önüne çıkmadan ikinci kaynağa geçmiyoruz.
- Entegrasyon ve yönetişim. Raporlama gereken kısmı veri ambarı ve ETL katmanına, oradan BI dashboard ekranlarına taşıyoruz. Sahiplik, kalite kuralları ve katalog düzeni veri yönetişimi ve kalite çalışmasıyla, kişisel veri alanlarının saklama ve imha kuralları da KVKK uyum danışmanlığı ile netleşir.
Veriyi rapora dönüştürme yolculuğunun geri kalanı için yönetici paneli ve KPI rehberimizi ve Veri ve Analitik rehberleri sayfasını inceleyebilirsiniz.
Sonraki adım
Veri gölü, doğru soruyla kurulduğunda yapay zeka ve ileri analitiğin yakıtıdır; sorusuz kurulduğunda pahalı bir arşivdir. Elinizdeki veri kaynaklarını ve yanıtlamak istediğiniz iki üç soruyu bize anlatın; göl, ambar ya da ikisinin birleşiminden hangisinin gerektiğini birlikte netleştirelim. İletişim sayfamızdan bize ulaşabilirsiniz.