Database, Data Warehouse, Data Lake... Bir de Başımıza Lake House mu Çıktı?

Bir veri mühendisi, veri bilimci veya veri analisti için bir veri akışı (data pipeline) oluşturmanın nihai amacı, işlenen/taşınan veriyi sorgulamak ve ondan içgörüler elde etmektir. Her akarsu nasıl bir göl veya denizde son buluyorsa, her veri akış hattı da mutlaka kalıcı bir depolama sisteminin kollarında huzura kavuşur. İşte bu yazımızda veri akış hattının huzur bulduğu bu yerde hangi teknolojiler kullanıldı/kullanılıyor, adları neler, niçin bu kadar çok isim değiştirdiler ve lake house bunun neresinde gibi sorulara cevap bulmaya çalışacağız.

Büyükşehirler göç alıp nüfus artınca şehrin ne kadar geliştiğine (değiştiğine desek daha iyi, değişen bir şey olduğu kesin) şahit olan büyükler: "Biz İstanbul’a ilk geldiğimizde buralar hep tarlaydı, şimdi bak her yer ev oldu. Zamanında kapatacaktık şuradan 3-5 metrekare yer…" derler hep. Analitik amaçla kullanılan veri tabanlarında da durum buna benziyor. Çünkü bilgi sistemlerinin gelişmediği veya yeni yeni geliştiği yıllarda defter ve kalemden kurtulup veri tabanına geçmek ve işlemleri daha hızlı ve zahmetsiz halletmek büyük bir şeydi. Ben hatırlıyorum da hastanelerde her gittiğimiz poliklinikte bir tıbbi sekreter önce bizi deftere kaydeder sonra içeri alırdı. İlişkisel veri tabanları bu dönemde çok harika şeylerdi. Ta ki veri bollaşana ve analitik ihtiyaçlar artana kadar... Bu noktada ilişkisel veri tabanından türeyen data warehouse (veri ambarı) doğdu.

Şimdi gelelim konumuza. Aslında başlıktaki dört kavramı kabaca iki gruba ayırabiliriz:

• İlişkisel veri tabanı kullananlar (Database, Data Warehouse)
• İlişkisel veri tabanı kullanmayanlar (Data Lake, Lake House)
   

1. Database (İlişkisel veri tabanı veya Relational Database Management System (RDBMS))

Hayatımıza ilk girdiğinden midir nedir veri tabanı deyince aklımıza hep ilişkisel veritabanı gelir. Artık kavram Selpak mendil veya Şaşal su gibi olmuş. Yani veri tabanının bir türü, kavramla özdeşleşmiş. Bu yaygınlıktan olsa gerek ondan sonra gelen her teknoloji kendisini ifade ederken “İlişkisel veritabanları böyle ben şöyleyim” gibi kıyaslarla kendini ifade etmek durumunda kalmış.

İlişkisel veri tabanlarının iki farklı kullanım usulü var. İlki analitik olmayan uygulamalara veri tabanlığı yapmak. Buna Online Transaction Processing (OLTP) diyoruz. İkincisi ise Online Analytical Processing (OLAP). OLAP tahmin edebileceğiniz gibi analitik amaçlı bir kullanım. OLTP iş yükleri genellikle banka hesap işlemleri gibi, yüksek eş zamanlılık, düşük gecikme süresi ve bir seferde birkaç kaydı okuyan veya güncelleyen basit sorgulardır. OLAP iş yükleri ise periyodik raporlama gibi, genellikle birçok kayıt üzerinde yüksek verimli taramalar gerektiren aggregation ve join içeren karmaşık analitik sorgulardır.

İlişkisel veri tabanları neden analitik için kullanılıyor? Aslında zamanında başka bir seçenek yoktu da o yüzden. “Elimizde bir veri tabanı var, bunu analitik ihtiyaçlar için de kullanalım” dediler. Ancak büyük veri, bu kolaycılığı tuzla buz etti. Çünkü doğası gereği ilişkisel veri tabanlarının bazı kısıtları var:

• Ölçeklenemiyorlar.
• Katı bir şema dayatıyorlar.
• Yapısal olmayan ve yarı yapısal verilere kapıları kapalı.
• Destekledikleri dosya formatları sınırlı.
   

2. Data warehouse

Data warehouse da aslında bir ilişkisel veri tabanıdır. Sadece veri modellemesi ve kullanım amacı farklıdır. OLTP veri tabanının aksine burada artık odak birkaç satırla uğraşmak değil yüzlerce/binlerce satırı özetlemektir. Ayrıca veriyi tekrarlı tutuyorum kaygısı yoktur. Çünkü burada asıl kaygı sorgu performansıdır. Veriyi tekrarlanmayacak şekilde tutmak OLTP açısından birçok fayda sağlasa da basit bir iş ihtiyacı onlarca bölük pörçük tabloda bulunan bilgilerin derlenmesini gerektirir. Veri ambarı bile kullanmayıp OLTP’yi analitik ihtiyaçlar için kullanıp “Hocam aslında bize big data lazım” diyenleri çok duydum. Ama ihtiyaçları olan şey aslında düzgün modellenmiş bir veri ambarıydı.

Bir bilgi ihtiyacının birden fazla tabloda olması demek join demek, join demek ise sorgu performansının ölmesi demek. Dolayısıyla veri ambarındaki veri tekrarı hoş görülmelidir. Kaldı ki artık burada ETL süreçlerinden geçmiş temiz veri var ve bu veri genellikle güncelleme istemiyor çünkü tarihsel, yani olmuşla ölmüşü tutuyor. Olmuşla ölmüş geriye dönük güncellenemeyeceğine göre geriye sadece sınırlı bir güncelleme ihtiyacı kalıyor, bu da OLTP’ye göre oldukça sınırlı.

Veri ambarında veri modeliyle oynayarak bir takım analitik kazanımlar elde edilse de veri belli bir büyüklüğe ulaştıktan sonra veri ambarının da ilişkisel veritabanlarından kalıttığı kötü genler yüzünden yine ihtiyaç tam karşılanmıyordu. Arkadaşın dediği gibi çözüm big datadaydı aslında. Büyük şirket ve kurumların cayır cayır büyük veri platformu edinmelerinin en temel sebebi budur.

 

3. Big data ve data lake

Verinin çoğalması ve ilişkisel veri tabanlarının yetersizlikleri insanları alternatif bir çözüm aramaya itti. 2000’lerin başlarında Sanjay Ghemawat, Howard Gobioff ve Shun-Tak Leung, The Google File System makalesiyle bombayı patlattı. Google’ın kendi indeksleme ihtiyacından doğan bu sistemden esinlenen Apache Hadoop ortaya çıktı. Hadoop zamanla yaygınlaşarak büyük verinin merkezinde yer almaya başladı. Bugün halen HDFS en yaygın dağıtık dosya sistemlerinden birisidir.

Peki data lake nedir? Data lake kabaca büyük veri imkanları ile data warehouse ihtiyaçlarının karşılanmasıdır. Aynı zamanda ilişkisel veri tabanlarına ait kısıtlardan kurtuluştur. Katı dayatmaları yoktur. Hele hele şema dayatması hiç yoktur. Ancak bunun da mahsurları var. Onca veri hengamesinde nerede ne veri var, bunların şeması ne bilmek zorlaşacağından dolaylı olarak veri yönetişim zaafiyeti doğurur. Veri gölünün sunduğu üç ana kolaylık var:

Depolama sistemi

Bu HDFS olabileceği gibi diğer ölçeklenebilir dağıtık dosya sistemleri/object store (AWS S3, Azure Data Lake, Google Cloud Storage) da olabilir.

Dosya formatı

Aşağı yönlü veri akış iş yüklerine bağlı olarak veriler, yapılandırılmış (Parquet, ORC…), yarı yapılandırılmış (JSON…) veya hatta bazen yapılandırılmamış biçimlerde (Metin, resimler, ses, video…) dosyalar olarak saklanabilir.

Veri işleme motoru

Gerçekleştirilecek analitik iş yüklerinin türlerine bağlı olarak bir işleme motoru seçilebilir. Bu, bir toplu işlem (batch) motoru (Spark, Presto, Apache Hive…), bir akış işleme (streaming) motoru (Spark, Apache Flink…) veya bir makine öğrenmesi kütüphanesi (Spark MLlib, scikit-learn, R…) olabilir.

Veri gölünün, eldeki iş yüküne en uygun depolama sistemini, açık veri biçimini ve işleme motorunu seçme imkanlarını sağlaması veri tabanları üzerindeki en büyük avantajdır. Genel olarak, aynı performans özellikleri için, veri gölleri veri tabanlarından çok daha ucuz bir çözüm sunar. Bu iki önemli avantaj, büyük veri ekosisteminin parlamasına yol açmıştır.

Peki veri gölünün hiç mi eksi yönleri yok? Elbette var. İlişkisel veri tabanının sağladığı konfor yok bir kere. Yani ACID yok. Dolayısıyla veri güncelleme sıkıntı, tutarlılık sıkıntı… Bunları aşmanın yolları deneniyor ancak ilişkisel dünyadaki gibi değil. Örneğin bir kaydıgüncellemek için bir partition komple yeniden yazılıyor gibi. İşte bu gibi eksiler lake house kavramını doğurmuştur.

4. Lake House

Lake house aslında data warehouse ve data lakein üstün yönlerini bir araya getirmeye çalışır. Göze çarpan özellikleri:

• Transaction desteği: Eşzamanlı sorgularda RDBMS gibi ACID garantisi sağlar.
• Şema dayatımı ve yönetimi: Lake house, bir tabloya yanlış bir şema eklenmesini önler ve gerektiğinde tablo şeması sürekli değişen verileri barındıracak şekilde açıkça geliştirilebilir.
• Birçok farklı veri formatını desteklemesi
• Birçok farklı iş yükünü (workload) desteklemesi
• Upsert ve delete desteği: Klasik veri ambarındaki Slowly Changing Dimensions mümkündür.
• Data governance: Veri bütünlüğü ve yönetimini destekleyen araçlar sunar.

Apache Hudi, Apache Iceberg ve Delta Lake gibi yukarıdaki özelliklere sahip açık kaynak projeler mevcuttur. Büyük veri dünyasının analitik motoru Apache Spark en çok Delta Lake ile uyumluluk gösterir. Çünkü Spark’ı geliştirenler onu da geliştiriyor, her ne kadar projenin hostu Linux Foundation olsa da... Apache Hudi’yi Uber icat etmiş, Hadoop Update Delete Incremental baş harflerinden oluşuyor. Iceberg’i ise Netflix icat etmiş, tek tabloda çok büyük (petabayt) veriyi tutabilir.

Sonuç

Gün geçmiyor ki hayatımıza yeni bir kavram ve yeni bir teknoloji girmesin. Bu yazımda lake house kavramını ilişkisi olan diğer kavramlarla beraber açıklamaya çalıştım. Yeni gelişmeleri takip etmek zahmetli olsa da bunu yapmalıyız. Aksi halde bir şeyin daha iyisi ve yenisi varken eskisiyle uğraşıp emek, zaman ve para kaybedebiliriz. Son bir söz: “Her çivi aynı çekiç ile çakılmaz. İşine uygun çivi, ona da uygun çekiç kullanmak gerekir.”

Büyük Veri hakkında daha geniş ve kapsamlı bilgiye erişmek, kariyerinizde fark yaratacak adımlar atmak isterseniz Miuul'un sunduğu Apache Spark ile Büyük Veri İşleme eğitimine göz atabilirsiniz.

Kaynaklar

• Learning Spark, Second Edition, O'reilly, 2020.