2 Feb 2014

Real Time Scoring – Gerçek Zamanlı Skorlama Teknolojileri.





Veri üretiminin ve kullanılamadan tüketilen verinin hiç bu kadar büyük hacimlerde olduğu bir dönemden geçmemiştik. Kurumlar satış rakamlarını yukarı çekmek, müşteri memnuniyetlerinde zirve yapmak için tek bir müşteri şikayetini dahi kaçırmamak adına yeni teknolojiler arıyorlar, teknoloji üretenler de, bu ihtiyaçları karşılamak için, AR&GE’lerden gelen bilimsel çalışmaları, ürün haline getirmek için uğraşıyorlar.

Öyle bir noktadayız ki, eskiden doğru bilgiyi bulamamak bir problemdi, şimdi bilgiye ulaşmak için veri okyanusunda boğulmamak daha büyük yetenek gerektiriyor.

Bu bağlamda, OLTP sistemlerimizde oluşturduğumuz verileri anlamlı hale getirmek için  Veri Ambarları oluşturduk, bu ambarları, ETL süreçleri ile doldurduk. Başlarda bu doldurma süreleri makul sürelerdeydi. İş birimleri de bizi o kadar sıkıştırmıyorlardı. Raporların ertesi günü alınması sorun olmuyordu. Zamanla bu ambarlardan anlık, analitik sorgu yapmak ve bu sorgularla karar süreçlerimizi beslemek için “Canlı” Karar Destek Sistemleri kurduk. İş birimleri bu sistemlerden hazır raporları değil, istedikleri dinamik raporları çeker hale geldiler ve öyle de bağımlı hale geldiler ki, kimse artık istediği rapor için saatler geçmesine veya ertesi sabahı beklemeye dayanamıyor.

İş birimlerinin aradığı her cevabın arkasında veri var ve doğru veriyi toplayan, hızlı raporlayan ve analiz edebilenin (bu üçünü aynı anda yapabilenin) avantaj sağladığı günlerdeyiz. Öyle ki, yukarıda ki analiz sistemleri mevcut veri üzerinden özet ve rafine bilgi üreterek karar vericileri desteklerken, bu olgunun bir adım ötesi olan “Predictive” yani ileriyi gören analiz sistemlerinin de (Predictive Analytics - PA) konuşulduğunu ve uygulandığıni görüyoruz. PA, karar destek süreçlerine, verinin istatistiksel olarak analiz edilmesi ve bilginin tahminde bulunularak dahil edilmesi olarak da adlandırlılabilir. PA, İş analizi süreçlerine tarihi verinin incelenerek bir tahmin çıkarılması üzerinden dahil olmak olarak da görülebilir. Bu tahminler, bir model kullanılarak, geçmiş verilerden üretilen skor ile servis edilir.

Skorlama katmanı; verinin içindeki bu gizli değeri süzerek, belirlenen kategoriler ile müşteriyi, hizmeti, servisi belli bir segmente yerleştirmek olarak da düşünülüyor. Müşteri özelinden bakarsak, o müşterinin sadakati, ürün çeşitliliği, geçmiş hareketleri, portföy, vb.  çeşitleyebileceğimiz bir çok değer bir araya gelerek bu skor oluşuyor. Online veya Offline olarak üretilebilen bu skor genellikle müşterinin anlık hareketine göre üretilmiyor. Skorlama sürecinde, periyodik olarak, OLTP’den ve ambardan alınan veriler işlenip skor oluşuyor; kurum buradan bu bilgiyi sorgulayarak tüketiyor, kullanıyor ve işini görüyor.

Bu süreçteki sorun şu;

Eğer skor bilgisini üretecek veriyi sağlayan sistem, skoru üreten sistem ve skoru kullanacak sistemler birbirinden ayrık ve dağıtık olarak çalışıyorsa, işletimden, karar sürecine kadar olan süreçlerde ki cevap süreleri, SLA’lerin üzerine çıkabiliyor, veriye ulaşımda gecikmeler olabiliyor. Daha da kötüsü, doğru zamanda doğru kararı vermeye yardımcı olacak skor bilgisinin zamanında alınamamasına neden oluyor.

Model Skorlamanın üretimi ve bu skorun OLTP sistem içinden erişimi için çok temel iki  yaklaşım var:

A-    Offline - Batch Skorlama: klasik ve en yaygın yaklaşım bu. ETL süreçi ile taşınan veri üzerinden, yine Batch işlemle geçilerek türetilen skor, tüketime hazır hale geliyor ama güncelliği ancak bir sonraki üretim döngüsünden sonra olabiliyor. OLTP Transaction içinden erişimi yok.
B-    Online – OLTP ve dış skorlama fonksiyonu: Bu metod birincisine göre daha modern. Webservis ile transaction içinden çağrılan skorlama modeli, işini görüp geri geliyor. Yalnız bu metodun işletimi sırasında, OLTP ile senkron çalışması gereken Webservisi, OLTP’nin SLA’ler içinde tamamlanmasını engellediği gibi, güvenlik, ağ gecikmesi gibi sorunlar da barındırıyor.

Yukarıdaki durumların bütün bileşkesi ve acil iş ihtiyaçlarının dayatmaları, B metodunun da “gerçek zamanlı ve In-DB olarak” yapılması ihtiyacını doğurdu. Böyle bir teknoloji bizlere, skorlama ihtiyacını, OLTP ortamında çalışan transaction henüz sonlanmadan ve dış skorlama katmanına gitmeden, veritabanının içinde çalışan skorlama metodu ile sağlayacak, veri güvenliği ve ağ gecikmelerinden soyutlayacaktır. Bu teknoloji ancak ve ancak kullanılan programlama dilinin ve SQL’ün olanakları ile çağrılabilen ve Veri Tabanının içinde çalışabilen imkanlar serisi ile sağlanacaktır.

Bu çok detay gibi gözüken ama büyük finans kurumlarının dört gözle beklediği bir olanak olarak gözüküyor. Özellikle rekabetin zirve yaptığı bu dönemde yazılım üreticilere çok iş düşüyor.

26 Nov 2013

Nedir bu NoSQL?



Günümüzde yazılımla uğraşıp, SQL (Structured Query Language) bilmeyen ve duymayan kalmamıştır herhalde. Nasıl yabancı dil eğitimi İlkokullara kadar indiyse, SQL’in temellerinin de İlköğretim Eğitim Programı içine alıp, gençleri erken yaşta veritabanı ve onun küresel dili olan SQL ile tanıştırmanın zamanı geldi de geçiyor. Buradan Milli Eğitim Bakanlığı’na bir mesaj vermiş de olayım.
Ama bu yazının temel konusu SQL değil, NoSQL!

SQL kullanan veritabanlarının geleneksel nimetlerini anlatmayacağım. 1970’lerde IBM için çalışan iki bilim insanı, Donald D. Chamberlin ve Raymond F. Boyce tarafından tasarlanan bu veri işleme dili, bütün ilişkisel veri tabanları için neredeyse standart hale geldi ve günümüze kadar ulaştı.
Öncelikle şu fark ile başlayalım.

SQL; ilişkisel veri tabanlarında, saklanan verileri yönetmek için kullandığımız, veritbanı bağımsız bir dil.
NoSQL ise yeni bir veritabanı sistemi veya modeli olarak adlandırılabilir.
Geleneksel veri tabanı üreticileri (IBM, Oracle, Microsoft vb.) geliştirdikleri veritabanlarıyla (DB2, Oracle, SQLServer) geleneksel veri tiplerini saklamak, yönetmek üzerine tasarlanmış, verinin doğruluğunu, herzaman tutarlı ve kararlı olarak saklanabilmesini, ulaşılabilir olmasını temel kriterleri olarak önceliklendirmişler ve bunlara göre çok sağlam motorlar geliştirmişlerdir. Bu veritabanları yıllar boyunca öncelikle “mission-critical” veri saklanmasını gerektiren bütün alanlarda görevlerini yapmaya devam etmektedirler.
NoSQL olarak adlandırılan model, yukarıdaki geleneksel modelin dışında, veri saklama, veriye ulaşma ve tutarlılığının ikinci planda kaldığı ihtiyaçların daha öne çıkması ile gözüktü. Bıg Data ihtiyaçları, Web ve Mobile uygulamaların ciddi derecede artması NoSQL olgusunu çok geliştirdi. Bu modelde saklanan veriler “yapısal olmayan” verilerden oluşuyor ve “mission-critical” ihtiyaçlar genel olarak yok. Böyle beklentilerin olmadığı NoSQL veritabanları bu anlamda yatay ölçeklemeye daha yatkın olarak düşünülebilir. Daha çok iş yükünü çalıştırmak için daha güçlü sunucular kullanarak dikey büyüme yöntemi yerine, daha ucuz sunucular ile yatay büyümenin tercih edildiği, “High Availability” çözümlerinin veritabanı olanaklarından çok, yazılım geliştirme teknolojileri ile sağlandığı yeni bir dünya burası. Bu dünyada merkezi veritabanından çok, dağıtık veritabanı özendirilir. Geleneksel veritabanlarının olmazsa olmazı ACID (Atomicy, Consistency, Isolation, Durability) kuralları NoSQL dünyasında sağlanmayabilir.
NoSQL veritabanlarında, SQL dili kullanılmıyor anlamı çıkmasın. Bazı yazarlar bunu “Not Only SQL” olarak da tanımlıyorlar yani bir nevi SQL’de kullanabildiğiniz ilişkisel model olmayan veritabanı gibi.

NoSQL veritabanları veriyi saklama metodlarından dolayı “çok büyük” veriyi, ilişkisel olarak saklama ihtiyacının olmadığı, bu veriyi daha hızlı getirmek ön koşulu  üzerine tasarlanmışlardır. Yani geleneksel veritabanlarındaki gibi birbiri ile ilişkili tablolar arasındaki verileri bulup, filtreleyip, işleyip getirmek gibi ihtiyaçlara burada cevap bulmak zordur. İlişkisel Model, veriyi alır birbiri ile ilişkili tablolarda kolon/satır şeklinde saklar. Örneğin “Document Store” modelini kullanan bir NoSQL veritabanı, JSON formatında gelen verilerin her bir kümesini ayrı bir veritabanı nesnesi gibi saklar.

Istatistik Hesaplar, Gerçek-Zamanlı Analizler, sürekli, hızlı ve kontrolsüz büyüyen verilerin saklanması (Twitter) gibi alanlar en yoğun kullanım şekilleridir. Özellikle Twitter gibi uygulamalar, “extreme scale” diyebileceğimiz şekilde büyük ve ucuz ölçekleme ihtiyacı göstermektedir. NoSQL bu alanı adreslemektedir.

Günümüz uygulama geliştirme süreçleri çok hızlı beklentiler içinde olduğundan (rapid application development) ve DBA gereksinimini en aza indirmek içinde NoSQL veritabanları ilgi görmektedir.

Klasik veritabanı API’lerinin veri erişimindeki göreceli olarak “overhead”leri daha fazla olduğundan ve NoSQL API’leri bu anlamda uygulama geliştiriciler tarafından daha revaçta olmaktadır.
Şu günlerde 122’den fazla kendini NoSQL sınıfına koyan veritabanı bulunmaktadır. Daha derin teknik detayları bir başka yazı konusuna bırakarak, kendini NoSQL veritabanı olarak tarifleyenlerin 4 ana grubundan bahsedeyim. 122 ününün yaklaşık %65’i bu 4 modelden birini benimsiyor.
Key Value Stores: Key değerleri, hash olarak tutuluyor. Key kısmındaki veri kısmı ise binary olarak saklanıyor. MemcacheD, REDIS, WebSphere eXtreme Scale bu modele uyan örnekler.
Document Stores: Saklanan veriler/dökümanlar tagged elementler gibi tutuluyor. MongoDB, couchDB bu modeli kullanan NoSQL veritabanları
Column Family: Her Storage bloğunda sadece bir kolon veya kolon kümesine ait veriler saklanıyor. Hbase, Cassandra güzel iki örnek
Graph Store: Key değerleri “graph yapısı” denen bir modelleme ile ilişkilendirilip saklanıyor. Jena, Sesame iki örnek. 

Öyleki, en yukarıda örneklerini verdiğim klasik veritabanları da, mevcut motorlarına yukarıdaki dört modelden birisini seçerek, ek “NoSQL” özellikleri ekliyor.

Örneğin Oracle, Key Value Stores, kullanarak, NoSQL desteği verirken, IBM - DB2 ise  Graph Store modelini kullanarak yollarına devam edeceklerini açıkladılar. Bunun anlamı, JSON dökümanlarına, SQL ile erişilebilecek olması çok yakında. Bu olanak geldiğinde yılların SQL bilgisine sahiplik yok olup gitmeyecek ve aynı becerileri kullanarak NoSQL veritabanlarını kullanabileceğiz.

Şimdilik görünen bunlar ama bu alanda o kadar hızlı gelişmeler oluyor ki siz bu satırları okurken bile bazı şeyler değişmiş olacak.