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.

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.

“Veri Ambarı ve BIG Data elele verirse?!?”

Herkesin dilinde, her etkinlikte BIG Data var. Bu sunuların ilk beş-on dakikası, 3V’yi anlatmakla, dünyadaki verinin saatte kaç kilometre hızla büyüdüğü, yere göğe sığmadığı ve sığmayacağını aktarmakla başlıyor. Bir kavramı anlamak ve anlatmak çok önemli. Kavram anlaşıldığında ve gerçekleştirildiğinde, o kavramın üstünden üretilen teknolojiler, ürünler ve hizmetler doğru şekilde değerlendirilebiliyor.

Bence, BIG Data kavramını ve algısını bir çok üretici farklı açıdan anlatsa da, bu kavram üzerinde bir asgari müşterek oluştu artık. BIG Data’dan “verim” sağlayacak “tüketici”, yani bu ürün ve hizmetleri alacak müşteriler, kurum içinde uygulama yapacakları bir alan arıyorlar. Kurumlar dönüp kendi veri işleme envanterlerine baktıklarında, geçtiğimiz yıllar boyunca Operasyonel/Transactional Sistemlerini kurduklarını, bunun üstüne de Veri Ambarları inşa ettiklerini görüyorlar. OLTP’den, Veri Ambarı’nı besleyerek raporlar çekiyorlar, karar süreçlerini daha doğru verilerle besleyip, daha hızlı karar karar almaya çalışıyorlar. Bu yapılanların üzerine acaba BIG data bana daha fazla ne katabilir diye herkes arayış içinde!

Büyük Veri teknolojisinin kullanılabileceği alanlara bakıldığında beş temel “Use-Case” görüyoruz.

Büyük Veri Arama: Karar verme sürecini daha etkin kılmak için tüm büyük veri kaynaklarını aramak, taramak, görselleştirmek. Buradaki en önemli girdi Sosyal Medya.

360^o Müşteri Görüntüsü: İç ve Dış bütün veri kaynaklarıyla müşteri analizi. Sosyal Medya, OLTP ve Veri Ambarını tekmişcesine inceleyebilme beceris.

Güvenlik ve Istihbarat Yetkinlikleri: Düşük risk, gerçek zamanlı dolandırıcılık, izleme ve siber güvenlik algısı. Güvenlikle ilgisi olan herkesin en ilgili olduğu alan.

Operasyon Analizi: Sensor ve Log Analizi yaparak sonuç geliştirme. Özellikle makine, sensor vb. elektronik herşeyin ürettiği sinyalleri anlık işleme ve karar destek süreçlerini besleyebilme yetkinliği.

Veri Ambarı Eklentisi: Operasyonel Verimliliği arttırmak için Büyük Veri ve Veri Ambarı özelliklerini entegre etmek.

Günümüzde, Veri Ambarı olmayan bir kurum artık kalmadığına göre beşinci seçenek, bence bir kurumun BIG Data çözümleriyle tanışıp, uygulaması için en hızlı seçenek olabilir.

Big Data ve Veri Ambarı Eklentisi

Mevcut veri ambarlarımız çoğunlukla, çok büyük miktarlarda yapısal verilerin, yüksek maaliyetli donanımlar üzerinde biriktirildiği ve sürekli gittikçe büyüdüğü, karmaşık sorguların çalıştığı yapıdadır. Kullanıcı sayıları ve kullanıcı taleplerindeki çeşitlilik ve sayının artış eğilimi, ambara giren verilerin de sayısısının artması ile veri ambarlarının motorları klasik veri tabanlarından, appliance dediğimiz çözümlere doğru evrilmekte. Bu evrilme sırasında BIG Data bize başka olanaklar sunuyor.

- Yapısal olan ve olmayan verilerle, akan verilerin büyük resmin içinde olup hep birlikte değerlendirilebilmesi, analitik sürece dahil edilebilmesi.

- Daha sorgulanabilir, göreceli olarak daha düşük maaliyetli bir ortam sağlanması.

- Soğuk Verilerin taşınabileceği, veri saklama, lisans ve bakım maaliyetlerinin aşağı çekilebileceği

- Şimdiye kadar “akan veri analizi”nin mevcut veri ambarlarında hiç yapılmamış olmasından dolayı, bu tip veri kaynaklarının “işlenerek” veri ambarına yazılamasıyla, saklama maaliyetlerinden tasarruf edilmesi.

Bunlar bir çırpıda, göze çarpan hızlı kazançlar.

BIG data teknolojileri ve Veri Ambarlarını eklemlemenin yukarıdaki kazanım ve ihtiyaçlar göz önüne alındığında üç yaklaşımla yapıldığını görüyoruz.

- Ön İşleme

Kurum mimarisinde, BIG Data veri kaynaklarının ön tarafına eklenecek, “staging” görevini üstlenen bir Kurumsal Hadoop Sunucusu, Veri Ambarına hangi verilerin girip girmeyeceğini ve filtrelemesini yapabilir. Bu yaklaşımla, BIG Data kaynaklarındaki veriler, temizlenerek, filtrelenerek ve anlamlı hale gelerek, Veri ambarına yerleştirilir. Bu şekilde hem yeni veri kaynaklarından mevcut ambara, daha önce veri ambarında hiç olmamış verilerin akışı sağlanmış olur, hem de bu ön filtreleme ve analiz ile veri ambarının daha değerli olan saklama ve hesaplama maaliyeti, gereksiz veriler yüklenmediği için, korunmuş olur.

- Sorgulanabilir Arşiv

Bu yaklaşımda, mevcut veri ambarında daha az erişilen soğuk veriler, daha ucuz maaliyetli olan bir Kurumsal Hadoop Sunucusu’na veri aktarım araçları ile taşınabilir. Federation teknolojilerinin yardımı ile son kullanıcılar her iki kaynaktan, tek kaynakmışcasına sorgulama yapmaya devam edebilirler.

- Keşifsel Analiz

Bu yaklaşımda ise, BIG Data kaynakları, akan veri analizi tekniği ile (Stream Computing) incelenip, analiz edilirken, yapılan bu analizlerin sonuçları hem anlık olarak değerlendirilebilir hem de mevcut veri ambarına beslenerek oradaki yapısal sorgulama ortamının bu keşifsel analiz sounçlarından faydalanması sağlanabilir. BU yaklaşımın bir diğer avantajı, BIG Data’yı tekil (unique) yapan teknolojilerin başında gelen “Stream Computing”in mevcut veri ambarı bileşeninin çalışmasını ve çıktılarını etkilemeden, mevcut yapıya en az müdehale ile entegre edilmesini sağlamasıdır.

Bu üç seçenekten birisi ile kurumdaki veri ambarının yanına bir BIG Data çözümü eklemleyerek, bu teknolojiyle tanışıp, kullanmaya başlamak artık an meselesi.

Nedir bu Hadoop ?

Herkesin dilinde bir “Hadoop” var ama nedir bu Hadoop ?

Apache-Hadoop güvenilir, ölçeklenebilir bir dağıtık hesaplama (distributed computing) ortamı yaratabilmek amacıyla ortaya çıkmış, açık kaynak kodlu bir yazılım geliştirme projesinden başka bir şey değil.

Bu projeye katkı verenler arasında Yahoo, Microsoft, Cloudera, facebook, linkedin, twitter, IBM gibi büyük yazılım şirketleri de bulunuyor.

Hadoop, basit programlama modeli kullanarak, kümelenmiş (cluster) bilgisayarlar arasında, büyük hacimli verilerin dağıtık olarak işlenmesini sağlayan bir yazılım kütüphanesi olarak ortaya çıktı. Tasarımı gereği, tekil bir sunucuda da, her birinin kendi CPU ve hafıza birimi bulunan binlerce sunucuyu barındıran bir küme (cluster) üzerinde de çalışabilir, büyüyebilir. Hadoop’un tasarımındaki önemli bir fark, bu yazılım geliştirme teknolojisinin, “High-Availability (HA)” ihtiyaçları için arka planda kullanılabilecek pahalı donanım çözümlerine ihtiyaç duyması yerine, kesintiyi uygulama seviyesinde farkedip, çözümleme üstüne tasarlanmasıdır. Hadoop, arka plandaki kümelenmiş bilgisayarların üstüne kurguladığı uygulama seviyesindeki HA çözümüyle farklı, ucuz bir alternatif olmayı hedefliyor.

Hadoop Projesi 4 modülden oluşuyor.

• Hadoop Common: Bütün Hadoop modüllerini destekleyen ortak modüller.

• Hadoop Hadoop Distributed File System (HDFS™): Büyük miktardaki veriye yüksek iş/zaman oranı (throughput) ile erişim sağlayan Dağıtık Dosya Yönetim Sistemidir. Birçok makinedeki dosya sistemlerini birbiriyle bağlayarak tek bir dosya sistemi gibi gözükmesini sağlar. HDFS, düğüm noktalarının (node’ların) her zaman %100 çalışamayacağını, kesintiler olabileceğini baştan kabul eder. Bu yüzden veri güvenliğini, verinin birden fazla düğüm noktasına kopyalayarak sağlar.

• Hadoop YARN: İş zamanlayıcı (job scheduler) ve kaynak yönetimini yapan bir dizi kütüphane.

• Hadoop MapReduce: YARN temelli, büyük miktarda veriyi parallel olarak işlemeye yarayan bir sistem. Gelen iş yükünü tanıyarak, arka plandaki bilgisayar düğüm noktalarına bu iş yükünü tahsis eden imkanlar sunar.

Hadoop kullanmaya başladığınızda, kesinlikle karşılaşacağınız Hadoop temelli bazı projeler de var. Bunlardan en popüler olan bazıları şöyle:

• Cassandra: Ölçeklenebilir, çok-nodlu, kümelenmiş veritabanı.

• Chukwa: Dağıtık ve Büyük Sistemleri yönetmek için veri toplama sistemi.

• Hive: Veri Özetleme ve “ad hoc” sorgu yazma ortamı sağlayan bir veri ambarı mimarisi.

• Pig: Parallel İşlem Tasarımı yapmak için hazırlanmış, veri akışlarını ve çalıştırma planlaması yapılabilecek bir dil.

Hadoop projesi ne getiriyor?

Hadoop, özellikle büyük hacimli verinin işlenmesinde, ekonomik değerleri ve dinamikleri kökten değiştirebilir. Çeşitli ihtiyaçlar için sistem mimarisi tasarlarken, ölçeklenebilirlik, süreklilik, hatadan kurtarma, paralel işlem yetenekleri, fiyat/performans, esnek tasarım gibi parametreler kullanıyoruz. Hadoop aşağıdaki 4 temel özelliği ile bu parametrelerin hepsinin aynı anda gerçekleşmesini sağlayabilir.

• Ölçeklenebilir: İhtiyaç duyulduğunda, verinin kendisini,  formatını, yerini değiştirmeden, çalışan işlerin ve uygulamaların nasıl yazıldığını dikkate almadan yeni düğüm noktası eklenebilir.

• Hesaplı Çözüm: Yüksek hacimli verinin, fazla CPU gücü ile işlenmesini gerektiren parallel çözüm ihtiyaçlarını, daha ucuz veya hesaplı bilgisayar altyapısı ile gerçekleşitirlmesini sağlar. Sonuç olarak her TB Saklama alanı için maaliyetler düştüğünden, kurumun bütün verisini fiyat endişesini daha ikinci plana iterek modellemesini sağlar.

• Esneklik: Hadoop’un şemasız, yapısal olan veya olmayan bütün veri tiplerini, her kaynaktan işleyebilen bir mimarisi var. Farklı kaynaklardan gelen, farklı veri tipleri birbirleriyle birleştirilip, özetlenebilir ve işlenebilir.

• Hatadan Kurtarma: Düğüm noktalarından biri ulaşılamaz olduğunda, sistem, gelen yükü diğer düğüm noktalarına paylaştırarak kesintisiz hizmete devam eder.

Hadoop size uygun mu?

Dünyadaki verilerin %80’i yapısal değil. Öyle ki, birçok kurum bu veriyi kendi avantajına dönüştürecek şekilde kullanma becerisi ve yatırım esnekliğinden de uzak. Bir an için hayal edin: Kurumun ürettiği veya kendisine dışardan gelen, istisnasız olarak her verinin gerektiğinde saklanabildiği, işlenebildiği, kurumun var olan diğer karar destek sistemleri ile entegre olabilen, ölçeklenebilir, hesaplı, esnek bir mimari kurguluyorsanız, Hadoop temelli çözümleri düşünmenin zamanı gelmiş demektir.

Hadoop’un çalışması “Yığın İşlem – Batch Processing” üzerine kurulu. Veri Ambarları ile bir Hadoop sistemi arasındaki en temel farklardan biri performans olacaktır. Dikkat edilirse, yukarıdaki değerlendirme parametreleri içinde perfromans bulunmuyor. Çünkü, Veri Ambarı sistemlerini karakterize eden erişim ve cevap süresi paternlerine baktığımızda, Hadoop temelli sistemlerde aynı beklenti içinde olmamız şimdilik doğru olmaz. Hadoop “Batch Processing” yapan bir çerçeve mimari sağlamaktadır ve cevap süresi olarak şimdilik veri ambarları ile aynı beklentide olmamak daha doğru olacaktır.

Örneğin; Bir Hadoop Sistemi, mevcut Veri Ambarı sisteminin arşivleme altyapısı için kullanılabilir. Müşteri Profillerini saklayan ve değerlendiren, iyi cevap süresi vermek üzere kurgulanmış ve yatırımı yapılmış bir veri ambarı sistemi, son iki yıllık bilgiyi saklarken, daha eski veriler bir Hadoop sistemine aktarılarak 20 yıllık bilgiler de burada saklanabilir ve gerektiğinde erişilebilir. Burada dikkat edilmesi gerekenlerden birisi de, SQL tabanlı olan Veri Ambarı sistemine erişen uygulamaların, aynı arayüzlerle Hadoop sistemine erişebilmeleridir; SQL ve NoSQL dünyasının bir arada çalışabilme gerekliliği vardır. Her iki mimari farklı hizmetler ve beklentiler için tasarlanmıştır, birbirinin yerini almak için değil, birbirini tamamlamak için kullanılmalıdır.

Hadoop’u kendiniz indirip kurup, kullanmaya başlayacağınız gibi, Hadoop Projesini destekleyen Microsoft, IBM gibi büyük oyuncuların kurumsal çözümleri ile de kullanmaya başlayabilirsiniz.

Hadoop, mevcut sistemlerinizin bir alternatifi değildir. Geleneksel veritabanı motorları ve yeni veri işleme motorları (Hadoop vb.) bir kurumun sol ve sağ kolları gibidir. Kuruma uyarlanacak BIG Data çözümünün, mevcut sistemle entegre olması, ayrık şekilde çalışmıyor olması en önemli önşartlardan birisi olmalıdır.

Yakında her eve bir “fil” girecek diyor Hadoop’u geliştirenler.

Hep beraber göreceğiz ve gerçek olup olmadığı da çok uzakta bir tarih değil!...

BT Haber

Big Data’nın getirdikleri

“Petrolün ham hali, işlenmiş halinden daha az değerlidir ve bir defa işlendimi en önemli enerji kaynağına dönüşür” Bu nitelemeye koşut olarak “Data is the new Oil” deniyor!

Bu benzeştirmede ki dip anlam şöyle: Dünyamızda petrole sahip olmanın sağladığı ayrıcalık neyse, veri işleme yeteneklerine sahip kurumların ve ülkelerin kazanacakları ayrıcalık da o olacak. Burada en önemli vurgu, “veri işleme yeteneği”. Yani illa ki sahip olduğunuz, size özel ve sizin ürettiğiniz verileri işlemeniz ve değer yaratmanız gerekmiyor. Kurumun sahip olmadığı ama eklemlendiği diğer kurum dışı kaynaklardan beslenerek üretebildiği değer ölçüsünde, rekabette ve değer yaratmada bir adım önde olabileceği anlatılıyor. İşte tam bu noktada BIG Data kavramının için dolduran elementler, kurumun sahip olması gereken yetenekler de karşılığını bulmaya başlıyor.

BIG Data’nın kurumlara ne sağlayacağının somut uygulamalarını çeşitli sektörlerde görüyoruz.

Güvenlik alanında, ses ve görüntü analizleri saatlerden dakikalara geriledi; Sağlık alanında hasta ve hastalık analizleri çok hızlandı; Finans analizlerinde PB’lık verilerin analizi saaterden dakikalara düştü; Telco’lar ağ üzerinden akan veri analizi (Stream Computing) yaparak donanım maaliyetlerini %90 oranında azaltıyorlar.

Öncelikle, kurulması hedeflenen BIG Data platformu, yeni bir veri ambarı olmamalı. BIG Data platformunu, veri ambarından ayıran en önemli özellik, işlenen verinin bir yerde yüklenmiş olmasının gerekmemesi, verinin kaynağında işlenerek kuruma ham haliyle değil, karar sürecini etkileyecek bilgiye dönüşmüş veya dönüşmeye hazır olarak ulaşması. Bir kurumun bu yeteneklere erişmesi için mevcut transaction işleme ve veri ambarı sistemlerinin yanına neler eklemlemesi gerekliyor veya bir başka deyişle BIG Data Platformu nelerden oluşmalı

1) 3V’yi yani Volume (Büyüklük), Velocity (Hız) ve Variety (Çeşitlilik), yönetebilmeli. Temel veri kaynaklarından bazıları, geleneksel transactional sistemler, makinelerin ürettiği duyarga verileri, sosyal medya verileri, yapısal olmayan bilgi içeren döküman yönetim sistemleri kaynakları ilk akla geleneler.

2) Hareket halindeki veriyi analiz edebilmeli (Stream Computing). Ürettiğimiz verinin %80’inin yapısal olmadığı düşünülürse bu veriyi kaynağında analiz edecek yetenekleri olmalı.

3) Hızlı uygulama geliştirme için araçları ve ön yüzleri bulunabilmeli. Hadoop ve Mapreduce temelli açık kaynak kodlu teknolojileri kesinlikle desteklemeli.

4) Kurumsal düzeyde güvenlik, yönetişim ve veri entegrasyon arayüzleri olmalı. Mevcut kurumsal veri kaynakları ile entegre çalışan, veri kalitesini iyileştirici, MDM (Master Data Management) çözümü ile entegre çalışabilmeli.

Geleneksel İş Analizi uygulamaları, önceden tasarlanmış sistemlerde, toplanmış ve yüklenmiş veriler üzerinden, iş analistlerinin belirlediği soruların cevaplarını arayan sistemlerdir. BIG Data Analiz ortamları ise veri kaynaklarının ve tiplerinin çeşitliliği, dağınıklığı ve büyüklüğü yüzünden bir platform olarak kullanıcının hizmetine ve yaratıcılığına sunulur.

Kurulacak BIG Data platformu işinize ne katabilir?

- Müşterileriniz hakkında herşeyi, Sosyal Medya hareketlerinden kanallarınız üzerinden sizinle kurduğu bütün etkileşime kadar, topyekün ve bireysel olarak bilmenizi sağlar. Ürün promosyonlarının yönetilmesi, karlılık analizi bunlardan bazıları.

- Operasyonel verilerle birlikte olmak şartıyla, süreçlerin optimize edilmesinde, karar verme sistemlerinin sıfır gecikmeyle gerçek zamanlı analiz yapabilmesini sağlar. Gerçek zamanlı satış raporlama ve analiz uygulamaları, bölgesel kampanya analizleri, doğal afetlerde etki ölçme uygulamaları sayılabilir.

- Veri kaynaklarınızı ve kuruma yapılan geri dönüşleri işleyip, “ışık hızında” yeni ürünler üretmenizi, proaktif kurumsal davranış geliştirebilmenizi sağlayacak imkanlar sunar. Sosyal Medya, Marka ve Piyasa etkileşim analizleri, RFID izleme uygulamaları ilk akla gelenlerden bazılarıdır.

- Kurumla ilgili bütün verileri, kurumda yüklenmemiş olsa bile, akan veri analizi teknikleri ile işleyerek, hile ve risk analiz modellerini çalıştırabilmeli. “Hile” algılama ve aksiyon alma, Cyber Güvenlik, Risk Yönetimi bunlardan bazıları.

- “Acaba işime yararmı” diye saklanagelen ve çok nadiren erişilen, saklama maaliyetleri yüksek veri ambarlarını tutmak yerine, veriyi kaynağında işleyerek veri ambarı işletim maaliyetlerinin düşmesini sağlamalı. Ağ loglarının anlık analizi, Websitesi erişim, kullanım analizleri düşünülebilir.

BIG Data yeni bir platform ve veri işleme anlayışı getirmesinin yanında, BT ortamında yeni ve daha karmaşık beceri kümelerinin oluşmasını şart koşuyor. “Data Scientist- Veri Bilimci” bu anlamda yeni bir rol. Veri Bilimcisi, istatistik, bilgisayar bilimleri ve MBA’in birleşiminden oluşacak. Bu rolün en önemli çalışma prensibi “Gerçek Zamanlı” çözümler üretebilme yeteneklerinin olması. Bir örnekle açıklamaya çalışırsak; buzdolabınız bozulduğunda, gazeteyi açıp bir buzdolabı tamircisi ilanından bakarak ustayı çağırdığınızda çoktan geç kalmışsınız demektir. Ama bozulan buzdolabı ustayı arayıp yardım isteyebiliyor veya bir problem kaydını sizin adınıza satıcı firmaya açabiliyorsa, kullandığınız ürün gerçek zamanlı bir çözüm sağlar. “Veri Bilimcisi”,  kurumun veri kaynakları ve bunlar arasında ki etkileşimi bilerek, kurumun iş geliştirme stratejilerine uygun,  Big Data platformunun yeteneklerini de birleştirerek anlık analiz çözümleri üretebilen bir yeni rol olarak hayatımızda yerini almaya hazırlanıyor. Veri Bilimcisi, uçtan uca, kullanıcının ilk sorularıyla başlayan “merak” sürecinden, geliştirme ve dağıtıma kadar ki süreci yönetebilmelidir. İş ile ilgili soruları, kurumun veri kaynakları ile ilişkilendirecek kadar büyük fotoğrafı kavrayabilmelidir.

Gartner’a göre 2013’deki BT Harcamaları 3.7 Trilyon ABD Doları olacak ve 2015’e kadar Big Data ihtiyaçları için 4.4 milyon yeni iş imkanı doğacak.

Big Data kavramını özümseyerek, bu yolda insana, platforma ve teknolojiye yatırım yaparak, iş süreçlerini bu kavrama uyarlayan, “büyük düşünen” kurumlar, diğerlerinden bir adım önde olacak.

2012’de İş Zekâsı

2012 birçok şirket için “sinirli” bir yıl olacak!...

Ne mi demek istiyorum?

2011 küresel krizi birçok şirketi yaraladı ama yıkamadı. Bu tahribata rağmen büyük oyuncular 2011’i BT yatırımlarını yaparak tamamladılar, ama olası ekonomik belirsizlik beklentisi 2012 için de hâlâ çok yüksek; yani bu tür yatırım yapanlar, yatırımın karşılığını almak için daha agresif olacaklar. Yenisini yapmak yerine mevcut yatırımlardan alacakları verimi en fazlaya çekmek için daha çok uğraş verilecek. Bu açıdan bakınca, 2012’de, “iş zekâsı” uygulamalarının önemi eskisinden daha da fazla öne çıkacak.

“İş zekâsı” uygulamalarını kullanan kurumların CIO’ları ile yapılan görüşmelerde ortak kanı şöyle;

 ·        “İş zekâsı” yazılımları gittikçe daha karmaşık hale geliyor. Bu karmaşık yazılımların analiz sonucunu daha basit gösterip, sunacak yaklaşımlara ihtiyaç var. Analiz araçlarını üretenler bu ihtiyacın farkına son birkaç yılda vardılar; ve günümüzde artık, bu araçların ileri seviyede, gelişmiş grafik görsel ara yüzleri de var. Bu özellik “iş zekâsı” yazılımlarının olmazsa olmazları arasında.

·        Bir başka eğilim ise artık iş analizi araçlarının ofisten çıkıp, mobil uygulamalar şeklinde mobil cihazlar üzerinden kullanılabilir olması talepleri. Yıllardır satış yapanlar ve sahada çalışan teknisyenler mobil uygulamalara zaten hızla alıştı. Ancak iş zekâsı uygulamalarının kullanıcıları, özellikle de üst düzey karar vericiler, bu akımın dışındaydı. Mobil işletim sistemlerinin, platformlarının yaygınlaşması ve standartlaşmasıyla “mobil iş zekâsı” uygulamaları da konum bağımsız, her yerden ulaşılabilir bir endüstriyel standart olma yolunda ilerliyor. Yapılan bir ankete göre, kurumların mobil iş zekası uygulamalarına verdikleri önem 2010’da %10 iken, 2011’de %68’e fırladı. Gartner’a göre iş zekâsı işlevlerinin üçte biri mobil cihazlar ve uygulamalar üzerine kayacak. İş zekâsını en çok kullanan büyük oyuncuların %25’i, 2012’de, uygulamalarının %30’unu mobil ortama aktarmayı hedefliyor. eBay’ın PayPal üzerinden yapılan ödemelerinde, mobil cihaz’lar’ın kullanım oranı %500 arttı. IBM’e göre küresel online ticarette mobil cihazların kullanımı %6,6. Bu rakamlara bakınca iş analizinin mobile kayması kaçınılmaz.

·        “İş zekâsı” kullanmayan kurumlar rekabet etmekte çok zorlanıp, birkaç adım geriye düşecekler. Bu uygulamalar ürün geliştirme ve satış stratejilerinin belirlenmesinde, uygulanmasında ve ölçülmesinde önemli bir araç olacak. Özellikle 2012’nin belirsiz ekonomik koşullarında kaynakların etkin, yerinde, yeterli ve doğru kullanılması için iş zekâsı uygulamaları olmazsa olmaz.

·        “Büyük veri” gerçekliğinin getirdiği, yüksek hacimli, değişken içerikli verinin, “iş zekâsı” araçlarına doğru girdisini (hangi veri, ne miktarda, ne sıklıkta gibi...) sağlamak ve analiz etmek bir başka eğilim. Mükemmel analiz için mükemmel veri girişi gerekiyorsa, bu verinin temiz, ayıklanmış ve yapılandırılmış olması gerekiyor.

Eskiden beri var olagelen ama yenilenmiş paralel teknolojilerin bu büyüklükte veri ve analiz araçları ile çalışabilir olduğunun da gözden geçirilmesi gerekiyor. Bu anlamda “iş analizi” çözümlerinin paralel teknolojilerden faydalanmaksızın çözüm geliştirmesi beklenmiyor.

·        Agile, ya da Türkçesiyle ”kıvrak” uygulama geliştirme araçlarının daha da gelişmesi, yaygınlaşması, veri kalitesini iyileştirme yöntem ve araçlarının yayılması sayesinde “In Memory” veri analizi yenilikleri veri ambarı uygulamalarının krallığını ele geçirme yönünde ilerliyor. Mobil teknolojilerin, bu yeni uygulama geliştirme araçlarıyla birleşmesi, üstelik analizleri mobil olarak yapabilme veya sunabilme eğilimleri, kurumsal veri ambarlarını ikinci plana atabilir.

BT yöneticileri, daha karmaşık analiz ve zeka uygulamalarını daha da “gerçek zamanlı” görmek isteyeceklerdir. Veri ambarları bu analizlere girdi sağlayacak temizlenmiş, birleştirilmiş bilgiyle doldurulup donatılmazsa önemlerini yitirebilirler. Çünkü bu analizler mobil cihazlardan da talep edilmeye başlandıkça, “analiz hazır” bilginin veri ambarından beslenmesi şart. 2012’deki bu endişeli bekleyiş içinde, daha fazla BT yatırımı yapılacaksa, 2011’in yükselen eğilimi olan “İş Analizi”ne yatırımların yönlenmesi, büyük veri kümelerini (BIG DATA) analiz eden teknolojilere, özellikle de “In Memory Analiz”e yönlenmesi beklenebilir.