Database, Datawarehouse, Datalake derken bir de Lakehouse mu çıktı başımıza?

Erkan ŞİRİN 28 Ağustos 2020 Büyük Veri, Distributed Systems 0 2162 1842 kelime - 12 dakika49

---

Bu yazıya puan ver

(3 votes, average: 4,67 out of 5)

Loading...

---

Geçenlerde lakehouse kavramını duyunca Hoppalaaa!!! diyesim geldi. Neredeyse her güne yeni bir kavramla uyandığımız bir devirde yaşıyoruz. Daha datawarehouse ne anlayamadan başımıza datalake çıkardılar, şimdi ise lakehouse. Merak ettim, lakehouse da acaba aynı şeylerin süslenmiş başka isimlerle sunulması mı diye? Değilmiş.

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 (data pipeline) huzur bulduğu bu yerde hangi teknolojiler kullanıldı-yor, adları neler, niçin bu kadar çok isim değiştirdiler ve konumuz olan lakehouse bunun neresinde gibi sorulara cevap bulmaya çalışacağız.

Buralar eskiden hep tarlaydı…

Büyükşehirler göç alıp nüfus artınca şehrin ne kadar geliştiğine (değiştiğini 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ı. Şimdi öyle mi? Neyse. İlişkisel veri tabanları bu dönemde çok harika şeylerdi (şimdi de işine göre hala harika) ta ki veri bollaşana ve analitik ihtiyaçlar (bu kadar veri var, yazık, boşa gitmesin bişeyler yapak) artana kadar. Bu noktada ilişkisel veri tabanından türeyen datawarehouse (veri ambarı) doğdu.

İlişkisel veritabanı ve diğerleri

Şimdi gelelim başlığımıza. Aslında başlıktaki dört kavramı kabaca 2 gruba ayırabiliriz:

1. İlişkisel veri tabanı kullananlar (database, datawarehouse)
2. İlişkisel veri tabanı kullanmayanlar (datalake, lakehouse)

hadi önce kullananlardan başlayalım.

1. Database – AKA İlişkisel veri tabanı -AKA Relational Database Management System – AKA RDBMS

Hayatımıza ilk girdiğinden midir nedir veritabanı deyince aklımıza hep ilişkisel veritabanı gelir. Artık kavram selpak mendil veya şaşal su gibi olmuş. Yani veritabanı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” gibisinden onunla kıyaslayarak kendini ifade etmek durumunda kalmış.

İlişkisel veri tabanlarının iki farklı kullanım usulü var: İlki analitik olmayan uygulamalara veritabanlığı 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.

Aslında ilişkisel veri tabanıyla biz analitik ihtiyaçları çözüyoruz işi tıraş. Bu hayvanın asıl var oluş amacı OLTP. Niye analitik için kullanılıyor peki? Başka bir seçenek yoktu zamanında da o yüzden. “Elimizde hazır koç gibi veritabanı var, bunu analitik ihtiyaçlar için de kullanak” 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ı, ki bir çoğu analitik hesaplamalarda acayip fark yaratıyor.

2. Datawarehouse

Datawarehouse da aslında bir ilişkisel veri tabanıdır. Sadece veri modellemesi ve kullanım amacı farklıdır. OLTP veritabanı 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 (aslında kullanamayıp, çünkü sorgular ya dönmüyor patlıyor ya da onlarca saatte dönüyor ve bu arada operasyonun anası ağlıyor) “Hocam aslında bize big data lazım yav” diyenleri çok duydum. Ama aslında ihtiyacı düzgün modellenmiş bir veri ambarıydı.

Bir bilgi ihtiyacının birden fazla tabloda olması demek join demek, join demek sorgu performansının ölmesi demek. Atasözünü unutmayın: “Join, sorgu performanssızlığının anasıdır”. 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 (fact tabloları için), 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 (genelde boyut tablolarında), 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, datawarehouse hikayeydi. 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 Datalake

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’un “The Google File System” araştırma 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 Datalake nedir? Datalake kabaca büyük veri imkanları ile datawarehouse ihtiyaçlarının karşılanmasıdır. Aynı zamanda ilişkisel veri tabanlarına ait kısıtlardan kurtuluştur. “Kim olursan ve ne olursan gel” anlayışı hakimdir. Katı dayatmaları yoktur. Hele hele şema dayatması hiç yoktur. Ancak bunun da (şema yoksulluğu) 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) olabilir.
• Dosya formatı: Aşağı yönlü veri akış iş yüklerine bağlı olarak veriler, yapılandırılmış (ör., Parquet, ORC), yarı yapılandırılmış (ör. JSON) veya hatta bazen yapılandırılmamış biçimlerde (ör. 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 (ör. Spark, Presto, Apache Hive), bir akış işleme (streaming) motoru (ör. Spark, Apache Flink) veya bir makine öğrenimmesi kütüphanesi (ör. Spark MLlib, scikit-learn, R) olabilir.

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

Peki veri gölü güzel anladık da bunun hiç mi eksi yönleri yok. Var elbette. İ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ı. Bunu aşmanın yolları deneniyor ancak ilişkisel dünyadaki gibi değil. Örneğin bir kayıt güncellemek için bir partition komple yeniden yazılıyor gibi. İşte bu gibi eksiler lakehouse kavramını doğurmuştur.

4. Lakehouse

Lakehouse aslında datawarehouse ve datalake’in ü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: Lakehouse, 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. (Bu arada upsert, kayıt yoksa ekle varsa güncelle demek).
• 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 Deltalake ile uyumluluk gösterir çünkü Spark’ı geliştirenler onu da geliştiriyor, her nekadar projenin hostu Linux Foundation olsa da. Apache Hudi’yi Uber icat etmiş, Hadoop Update Delete Incremental baş harflerinden oluşuyor. Iceberg’i ise Netflix icad 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 lakehouse 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.”

En kötü yaşam alanınız kapaktaki göl ve ev olsun 🙂

Kaynaklar:

1. Learning Spark, Second Edition, O’reilly, 2020.