Data Lake

Film adını andıran Data Lake, veri ile uğraşanların duymaya başladıkları bir kavram. Türkçe karşılığını bilmediğimden dolayı kavrama yazı bozunca Data Lake demeye devam edeceğim ve diğer kavramların Türkçe karşılıkları olsa bile aynı patern'de olması için orjinal isimlerini kullanacağım.

Kimilerine göre Data Warehouse'ın güncel adı, kimilerine göre yeni versiyonu. Oysaki bunların farklı olduğunu görüyoruz. Ayrıldıkları noktalar kullanım yer ve amaçlarındaki farklılıklardan oluşmaktadır. Her ne kadar bu ifadeden Data Lake, Data Warehouse'ın yerini almayacak gibi görünse de kanaatime göre disruption(bozulma anlamında olsa da öldürücü demek daha doğru gibi) bir unsurdur.

Pentaho kurucusu James Dixon'ına göre eğer data mart'ları hijyenik hale getirilip paketlenerek kullanıma hazır hale getirilmiş su şişeleri olarak düşünürsek, Data Lake geniş hacimli doğal su gölleridir. Değişik su kaynaklarından beslenir ve isteyen istediği miktarda alıp kullanır.

Data Warehouse ve Data Mart'lar structured veya tabular tipindeki verilerden oluşurlar. Schema-On-Write olarak tasarlanmışlardır. Verileri önce işlenir sonra yüklenir. Data Lake'ler ise structured olsun olmasın her türlü veriyi tutabilir, yüklenmeden önce verinin işlenmesine, dönüştürülmesine gerek yoktur. Schema-On-Read olarak tasarlanırlar.

Verilerin işlenip kalıplara sokulmasından dolayı Data Warehouse sistemleri büyük veri depolama alanlarına ihtiyaç duyarken, aynı zamanda bu depolama alanları çok pahalı sistemlerdir. Data Lake sistemler ise çok daha ucuz ve verinin gerçek boyutu kadar depolama alanları ile yetinirler.

Çeviklik olarak Türkçe'ye tercüme ettiğimiz Agility, Data Lake sistemlerde hayli yüksekken, Data Warehouse sistemlerin tasarımlarının sabit olmasından dolayı çok düşüktür. Yeniden tasarlanıp konfigürasyonun yapılması gerekir. Oysaki Data Lake sistemler esnektir, istenildiği gibi yeniden konfigürasyonu yapılabilir.

Diğer taraftan Data Lake sistemlerin dezavantajlarını ele alacak olursak, henüz yeni sistemlerdir. Olgunlaşmamış olmasından dolayı pazardaki sektörler tarafından yeterince güvenilir bulunmaması yaygınlaşmasının önündeki en büyük engellerden biri olarak durmaktadır.

Tüm bunların yanında Data Warehouse sistemlerin hedef kitlesi iş birimleri iken Data Lake sistemler, veri birimciler için kullanışlıdır.

 

Schema-On-Write Schema-On-Read Kıyaslaması

İki yeni terim ile karşılaştım, yeni karşılaşmış olman bunların yeni türetildiği anlamına gelmiyor, ne zaman türetildiklerini bilmiyorum fakat bundan sonra daha çok karşılaşacağımızdan eminim. Bu nedenle  terimleri açıklamak ve kıyaslamak istedim, başucu kaynağı olarak dursun.

Schema-On-Write

SQL developer ve adminlerin veri tabanı ya da tablo dendiğinde zihinlerinde ilk canlandırdıkları olgudur. Biraz daha açarsak, önce bir çerçeve tanımlayıp şemanızı belirliyorsunuz, ardından verilerinizi yazıyor ve okuyorsunuz. E bunda ne var, bunu zaten biliyorduk. Aynen öyle. Peki schema-on-read ne?

Schema-On-Read

Bunda ise schema-on-write'da olandan farklı bir süreç işletiyorsunuz. Şemanızı tanımlamak yerine verilerinizi olduğu gibi yüklüyorsunuz. Sıra okumaya geldiğinde ise elinize merceğinizi alıyor ve ya gözlüğünüzü takıyorsunuz. Gözlük veya mercek diyorum çünkü veriyi olduğu gibi yüklediğinizden dolayı detaylara inebilmek için merceğe, uzaktan, yakından ya da  farklı açılardan farklı boyutlardan bakabilmek için gözlüğe ihtiyacınız oluyor. 3D gözlükleri düşünün.

Örnek ile somutlaştırmaya çalışalım. Elinizde bir anket formu var ve bunu veri tabına kaydetmek istiyorsunuz. Schema-on-write, tablo veya tablolar tasarlayıp verileri bunların içini yazarsanız, diğerinde ise formu olduğu gibi sisteme yüklersiniz. Örneğin JSON veya XML.  Peki niye buna ihtiyaç duyalım ki?

Neden Schema-On-Read

Yukarıdaki örneğimizi düşünelim; ankete yeni bir soru eklendi veya çıkartıldı, cevap seçenekleri değişti. Gidip şemanızı değiştirmek ve yeni yapıya uyarlamak zorunda kalırsınız. Oysaki ikinci seçenekte buna ihtiyaç olmaz. Fakat asıl sebep bu değil, gerçek fayda okuma yaparken ortaya çıkıyor. Terimin isminde "Read" geçiyor olmasının nedeni de bu olsa gerek.

Verilerimiz varlıklarımızdır ve varlıkları kullanan kişiler, kişilerin rolleri birbirlerinden çok farklıdır. Varlıklardan değer üretebilmek için kendi çerçevelerinden bakmaya ihtiyaç duyuyorlar. Biz bir şemaya oturttuğumuz zaman, kullanıcılar çerçeveleri ile uyuşmayabilir. Bazılarının çerçeveleri 10x15, bazılarının 15x20 bazılarının ki ise 20x30 boyutlarındadır.  Biz 15x20 seçtiğimizde diğerlerininkine uymayacaktır.

Uydurmak için tekrar tasarım , geliştirme ve devreye alma durumunda kalınır ki, bu da ekstra maliyet ve zaman demektir. Hepsine uyabilmesi için en büyük çerçeveyi seçtiğimizde ise fazladan yer tutmanın maliyeti gelir. Hepsi için ayrı ayrı çerçeveler oluştursanız, maliyetleri ve geliştirme sürelerini katlamış olursunuz.

Sadece bir örnek üzerinden konuştuk, farklı bir anket formu olduğunu düşünün. İkinci bir şema oluşturmak ve verileri yazacak benzer bir sistem geliştirmek zorunda kalırsınız.

Yukarıda verilen örnekleri düşündüğümüz de nasıl bir yük ile karşı karşıya olduğumuz gün yüzüne çıkmaktadır. Schema-On-Read'in asıl faydası burada ortaya çıkar. Veriyi olduğu gibi yüklediğinizden dolayı (yazmak değil, yüklemek tabirini özelikle kullanıyorum) proje sürelerinin kısalmasını, maliyetlerin azalmasını dolayısıyla projenin başarılı olarak kapatılması olasılığını yükseltmiş olursunuz.

Okuma Yapılması Engellenmiş Tablodan SP ile Okuma Yapılabilir mi?

Select yapabilmesi DENY ile engellenmiş kullanıcı SP kullanarak tablodan okuma yapabilir mi?
Bu sorunun cevabı evet ya da hayır şeklinde yanıtlayacağımız kadar basit değil. Okuma yapıp yapamayacağınızı belirleyen başka faktörler de var. Bu nedenle soruyu açıklayacak yazı yazma gereksinimi doğdu.
MS SQL serverda GRANT komutu içi kullanıcılara (Login veya User) yetki tanımlarken, tersine DENY ile yetkiler engellenir.
SALES isimli kullanıcıya  tablo üzerinde Select yetkisi tanımladıktan sonra ilgili kullanıcı tablodan okuma yapabilir.

DENY tanımlandığında ise daha önce SELECT yetkisi verilmiş olsa bile okuma yapamayacaktır.

Şimdi benzer işlemi yapacak stored procedure create edelim ve onunla okuma yapmaya çalışalım. Ne dersiniz okuma yapabilecek miyiz?

Create ettiğimiz SP'ye EXECUTE yetkisi tanımladıktan sonra, kullanıcının tablodan SELECT yapması engellenmiş olmasına rağmen SP'i çağrılıp istenilen kayıt okunabildi. MS SQL server SP'ler çağrıldığında, kullanıcının Execute yetkisi olup olmadığına bakıp eğer yetkisi var ise çalıştırmasını sağlıyor. SP içindeki nesneler üzerindeki yetki kontolünü ise aşamalı olarak yapıyor. Eğer içeride kullanılan nesneler ile SP'nin owner'ı aynı ise herhangi bir yetki kontolü yapmadan çalıştırıyor. Yukarıdaki örneğimiz bu şekilde gerçekleşti. Eğer owner'lar farklı ise alt nesneler için de yetki kontrolü yapıyor.
Create ettiğimiz SP'nin owner'ı değiştirip aynı işlemi tekrarlayalım.

Görüldüğü gibi select yetkisi DENY ile alındığından dolayı okuma yapılamadı ve Sp hata döndürdü.