- tweet
-
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.
Cüneyt Göksu
yılları arasında Kurumsal Müşterilerde Teknik Uzman ve Yönetici olarak görev yapan Cüneyt, 2000'den 2013'e kadar
Vizyon Bilgi Teknolojileri bünyesinde Bilgi Sistemleri Danışmanı, Veri Mimarı, Eğitmen ve Profesyonel Hizmetler
Direktörü olarak kurumsal projelerde görev aldı. 2013 Ekim'den beri IBM'de Bilgi Sistemleri konusunda, Teknik Satış
Uzmanı olarak görev yapıyor.
1996'den beri IDUG'da (International DB2 User Group) çeşitli sorumluluklar üstlenen Cüneyt, 2011'den beri IDUG
Yönetim Kurulu'nda görevli ve bir çok yurtiçi, yurtdışı konferanslarda sunumlar yapmaktadır. 2003'de kurulan, IDUG'un
Türkiye'deki bağlantısı TDUG'un (Türkiye DB2 Kullanıcı Grubu) lideridir. IBM'in Information on Demand (IOD) Avrupa
konferanslarının organizasyon komitelerinde çalışan Cüneyt'e, 2008 yılında, "IBM Information Champion" ünvanı
verildi. 2009'da IBM'in "Gold Consultant" takımına seçilen Cüneyt, Bilgi Sistemlerindeki gelişmelerin günlük hayatta
müşterilerde uygulanabilmesi ve değere dönüşmesi konusunda faaliyetlerde bulunuyor. [email protected] adresinden Cüneyt’e ulaşabilirsiniz.
Latest posts by Cüneyt Göksu (see all)
- “Big Data” nedir? Geleneksel “Veri Yönetimi”ne etkisi ne olur? - Oca 27, 2014
- Veri Ambarı ve BIG Data elele verirse - Oca 5, 2014
- Nedir bu NoSQL? - Ara 23, 2013
