Neyleyim görselleştiremediğim veriyi

Business Analytics projelerinin çoğu iç müşteriye göre en cezbedici ve aslında ürünün etin kemiğe büründüğü kısım veri görselleştirme bölümü. Acı gerçekleri konuşacak olursak çoğu insan için arka tarafta cebelleştiğiniz sorunlar veya kullandığınız ürünlerin bir önemi olmaksızın çalışmalarınızın göründüğü, anlama kavuştuğu son nokta.

Buradaki esas sıkıntı veri görselleştirme konusunda seçilecek ürün. Özellikle Big Data teknolojilerinin hayatımıza çok daha fazla girmesiyle birlikte öneminin tekrar ortaya çıktığını düşündüğüm veri görselleştirme ile ilgili son dönemde ciddi sayıda ürün hayatımıza girdi.

Bazı ürünlere baktığımız zaman inanılmaz güzel, geliştiricilerin içini kımıl kımıl yapan veya başta yönetim seviyesi olmak üzere tüm kullanıcıların işte hayalimdeki ürün bu! diyebileceği arayüzler sunuyorlar. Fakat burada dikkat edilmesi gereken bir iki husus var ki aslında yazımızın ana konusunu bu oluşturuyor.

İhtiyaçları Karşılama Durumu

Gözlemlerime dayanarak söyleyebileceğim şey:

Ürünü seçip sonra problemi çözmesi için uğraşıyoruz. Halbuki problemi net teşhis edip ona göre ürün seçmemiz gerekiyor.

Şirketlerle bu konuları konuşmaya başladığım zaman ilk sorduğum soru Neden? Neden X ürününü seçtin. Buna maalesef derinlemesine ve gerçekçi cevap veren yer sayısı çok az. Genelde böyle bir proje başlatıyoruz ve alternatif ürünlere bakalım denilip bir üründe karar kılınıyor. Sonrasında ise problemimize net olarak odaklanıp çözümleri seçtiğimiz ürüne yönelik taklalar atarak çözmeye çalışıyoruz.

Peki problemlerimiz neler? En basitinden kullanıcı kitlemizin davranışı ve ihtiyaçları gerçekten çok önemli bir konu. Yıllardır konuşulan ama gerçek hayata dönmesi bir o kadar zor olan Self Service BI konusu. Siz istediğiniz ürünü kullanın istediğiniz kadar ürünleri kusursuz hale getirin önemli olan onu tüketecek kullanacak son kullanıcının davranışlarıdır. Belki hakikaten self service bir çözüme ihtiyaç duymayan bir yapıda çalışıyorsunuz. Belki taleplerinizin %80 ve fazlasını otomatik çalışacak sistemlerle karşılayabiliyorsunuz. O zaman gerek var mı hakikaten self service yöntemlerini kullanmaya. Aklıma ilk gelen Qlikview ve Tableau ürünlerine baktığımız zaman gerçekten çok güçlü ve probleme yönelik net, hızlı aksiyon almanızı sağlayan yapılar. Lakin verinin bilgiye dönüşümü ve görselleştirilmesi konusunda nice şirketlerde heba oldular ve sadece tablo gösterimi için kullanılan yapılara döndüler kim bilir. Tableau ve Qlikview ürününü seçiyorsak onun hakkını verebilecek problemler ve tüketicilere ihtiyacımız var demektir.

Peki bu ürünler kusursuz mu? Elbette hayır. Özellikle Hürriyet her beş dakikada ~450 MB veri üreten bir yapıda ve bu veriler için hali hazırda çözümleri direk kullanabilmeniz çok mümkün değil. Hele ki verileri memory üzerinde saklarım böylelikle çok daha hızlı sana sonuç dönebilirim tarzında çalışan ürünlerde.

Hürriyet’te kullanıcıların tüketimlerine göre üç farklı raporlama alt yapısı sunmaya başladık. Bunlardan ilki real-time analytics. Hakikaten real time :) Amazon Web Services üzerinde geliştirilen projede Elastic BeanStalk ile başlayan clickstream verilerinin alınması sırasıyla Kinesis, Lambda (aaaa serverless!) üzerinde işlenip Redis’e aktarıldıktan sonra geliştirilen bir extension yardımıyla başka bir arayüz olmadan direk site üzerinden anlık olarak analiz edilebiliyor. Bu sayede hangi haber ne kadar okunuyor, düşüş var mı, ana sayfamı yeteri kadar verimli kullanıyor muyum sorularına anlık cevap verilebiliyor. Üzgünüm ama acı gerçekleri söylemek zorundayım. Yaaa bu haber ne böyle kim okuyor çok saçma! şeklinde yorum yaptığınız haberler okunuyor ki orada duruyor. Çünkü bu haberler eş zamanlı olarak takip ediliyor. Üzgünüm ama çoğumuz Demet Akalın kiminle laf dalaşına girmiş, Arda Turan nereye gidecek, Asena bugün yine ne yapmış haberlerini bayıla bayıla okuyoruz.

İkinci konu özet raporlar. Özet raporlar ile ilgili genellikle “raporlama uzmanı” unvanıyla Excel konusunda Phd yapmış arkadaşlar şirketlerde bulunur. Biz istiyoruz ki bu tarz statik raporları çalışanlar yapmasın, onlar vakitlerini daha verimli geçirsinler. Bu sebeple tüketicilerin ihtiyaçları olan tüm statik veya az parametreli raporları SQL Server Reporting Services üzerinden subscription ile otomatik olarak gönderiyoruz. Çok kısa bir süre içerisinde 100'den fazla rapor yayına aldık ve daha yolun çeyreğine bile gelmedik diyebilirim. Ama ihtiyaç olan rapor zaten hep aynı formatta ise niye bir grup çalışan bu raporlar için mesai zamanını harcasın? Bırakalım onu SSRS yapsın ve biz daha verimli olabileceğimiz konulara odaklanalım. Peki Volume problemini nasıl çözüyorsunuz derseniz aslında orada tüm ham verimiz üzerinden çalışmıyoruz. Yani yığın verimiz yine Spark, Hive veya custom yazılmış ETL paketleri üzerinde duruyor ve sadece raporlama yapacağımız özet verilerimizi SSRS üzerinden yayınlıyoruz.

Real Time Analytics ve automated reports tüm ihtiyacımızı karşılıyor mu? Hiç mi ad-hoc talep gelmiyor veya hiç kimse drag&drop çalışmıyor, What if analizleri yapmıyor diye soruyor olabilirsiniz. Aslında o tarafta da yine özet verilerden beslenen küçük data martlardan faydalandığımız yapımız mevcut. Özellikle yönetim seviyesinde daha genele bakılacak veya az değişiklikle hızlı sonuç görülebilmesi için PowerBI kullanmaya gayret gösteriyoruz. Dediğim gibi burada önemli olan kullanıcı davranışı ve ihtiyacın net olarak belirlenmiş olması. Tableau görsellik açısından çok kullanışlı, çok rahat öğrenilebilen bir ürün. Fakat sürekli benzer formatlarla çalışıyorsak ve ürünün gücünün hakkını vermiyorsak aslında yaptığımız şey bir Ferrari alıp hız limiti 50 olan yolda sürmek ve etrafa bakın benim Ferrarim var demek.

Implementasyon Süreci

Raporlama ürünlerine baktığınızda evet çok fazla veri kaynağına erişimleri var artık ve bunları çok rahat kullanabiliriz! ürünleri 5 dakika inceliyorsanız evet kesinlikle haklısınız. Ama detaya girdikçe küçücük konuları çözümlemek vaktinizin çok büyük bir kısmını alabiliyor. ODBC → OleDB veya tam tersi her boğuştuğum zaman afakanların bastığı bir durum en basitinden. Veya yakın zamana gelecek olursak Apache Kafka için hazırlanacak Dashboard mantığı. Eğer probleminiz hakikaten buysa (akan veri üzerinden dashboard gösterimi) belki de Kafka diye diretmek yerine Azure EventHub, Stream Analytics, Power BI veya Amazon Kinesis, Kinesis Analytics, QuickSight üçlemelerini denemek daha hızlı çözüm üretmenizi sağlayabilir. Burada teknik altyapınızın seçilecek ürün ile uyumluluğu ve probleminizin doğru teşhisi çok çok önemli.

Kullanım Kolaylığı

Burada aslında iç içe iki konu var. Birincisi teknik işlerden sorumlu kişilerin öğrenim ve kullanım kolaylığı, ikincisi ürünü tüketecek müşterinizin kullanım kolaylığı. Maalesef insanoğlu olarak yeni şeyler öğrenmeye, onları anlamaya çalışmaya çok meyilli insanlar değiliz. Bknz: Abi ben C# yazarım, python falan bilmem öğrenemem şimdiciler. Hal böyle olunca raporlama altyapısı çok kolay geliştirilebilir olsun ki hızlıca ürün çıkartabilelim. Kısa sürede ~100 rapor geliştirebilmemizin başlıca sebeplerinden birisi veri görselleştirmede kullandığımız ürünler için SQL dışında bir dil öğrenmemize çok gerek olmayışı diyebilirim. Son kullanıcı için ise SSRS üzerinde zaten tek bir buton var. View Report. Yani çalıştırması çok zor değil :) Ama yok ben bunu dahi yaptırmayalım kısmı bizim için oldukça önemli. Bunun sebepleri farklı bir yazı konusu ama olabildiğince raporlarımızı otomatik göndermeye özen gösteriyoruz.

Konuyu özetlemek gerekirse Tableau, Qlikview, PowerBI, Tibco, Domo, Birst, MicroStrategy her biri ayrı ayrı çok iyi güzel ürünler. Önemli olan doğru hastaya doğru ilacı verebilmek.