Real Time Dashboard, iş zekası dünyasında yıllardan beri konuşulan ancak çok az kurumun hayata geçirebildiği konulardan bir tanesidir. Veri ambarının Real Time olarak güncellenebilmesinde üst düzey yöneticilerin tüm kurum performansını anlık olarak izleyebilmesi için gerekli teknolojik altyapı gözönüne alındığında birden fazla teknolojik bileşen ve implementasyon yaklaşımının devreye girdiğini görüyoruz. Bu noktada karşımıza farklı terimler çıkıyor ancak çoğu kez müşterilerimizle konuştuğumuzda bu terimlerin yanlış ya da eksik kullanıldığını görüyoruz. “Ürününüz değişen kayıtların sisteme alınarak raporlanmasını ya da dashboard ortamlarında kullanılmasını destekliyor mu?”. Bu soru özellikle iş zekası ürünleriyle ilgili satış aktivitelerinde en sık sorulan sorulardan bir tanesi olarak karşımıza çıkıyor. Ya da “Geliştirdiğimiz dashboard uygulamalarında veriye anlık olarak ulaşarak dashboard’ların ekranda otomatik olarak güncellenmesi mümkün mü?”.
Böyle bir soru, çok özetlenmiş ve veri hacmi çok yüksek olmayan, veri entegrasyonu ihtiyacı duyulmayan veri kaynakları için Dashboard’ların direk olarak operasyonel sisteme karşı oluşturulması senaryosunda kolay bir şekilde çözüm bulabilir. Ancak tipik bir dashboard uygulamasında verilerin işlenmesi ve bir çok kaynak kullanılarak entegre edilmesi senaryosu çok sık karşılaştığımız bir durum Böyle bir senaryoda verilerin staging area olarak nitelendirilebilecek bir alana alınması ve/veya sadece dashboard’lara özel bir datamart yapısının kurulması kaçınılmaz olmaktadır. Bu nedenle bu tür sorulara doğru yanıtları verebilmek için kavramların üzerinden geçmekte fayda var.
Real Time Dashboard Uygulamaları
Real-Time Dashboard uygulamaları geliştirebilmek için karşımıza çıkacak ilk konu, operasyonel sistemdeki değişikliklerin yakalanabilmesi ki bu konu Changed Data Capture(CDC) olarak adlandırılmakta. CDC verilerinin yakalanabilmesi çoğu kez ön yüzde kullanılan iş zekası yazılım araçlarının işi değildir aslında. CDC verilerinin yakalanabilmesi için dünya üzerinde bu konuya odaklanmış ve bu konuda uzmanlaşmış firmalar ve çözümler bulunmaktadır.
Attunity firmasının çözümlerinde olduğu gibi bu ürünler veri kaynaklarının bulunduğu donanım üzerine kurularak veritabanlarında yapılan ekleme, silme, değiştirme gibi işlemlerin tümünü performanslı bir biçimde alternatif yöntemlerle (örneğin veritabanı log’ları) okuyarak bunu iş zekası yazılım araçlarına ya da veri entegrasyonu sağlayan ETL araçlarına sunabilmektedir. Bununla birlikte Attunity gibi bir ürün kullanılmasa bile operasyonel sistemdeki değişiklikerin yakalanabilmesi için veri hacimlerine bağlı olarak değişik yaklaşımlar uygulanabilir. Örneğin operasyonel sistemlerdeki tablolarda kayıtların üzerinde bir TimeStamp varsa o takdirde belli bir tarihten sonra değiştirilmiş, eklenmiş ya da silinmiş tüm kayıtları bulmak mümkün olabilir. Bu tür kayıtlara veritabanı üzerinde yazılacak bir takım trigger’larla ulaşarak CDC verilerini ayrı bir tablo içinde biriktirmek de mümkün. Hatta, eğer operasyonel sistemdeki tüm programlar kontrol edilebilecek düzeydeyse, bu operasyonel programlar güncellenerek, veritabanı üzerinde ekleme, silme, değiştirme gibi işlemler yapılırken aynı zamanda ayrı bir tabloya yapılan işlemler kaydedilebilir.
Bununla birlikte her yaklaşımın avantajları olduğu gibi bir takım dezavantajları söz konusu. Örneğin veri hacmi ve işlem sayısı çok fazlaysa o zaman veritabanı üzerine yazılacak trigger’ların sisteme getireceği yük çok fazla olacaktır. Benzer şekilde büyük kurumlarda çok fazla program olduğu için programların güncellenerek verilerin başka bir tabloya yazılmasının maliyeti yüksek olacaktır. Yine büyük kurumlarda yıllardır çalışan bir takım uygulamalar bulunmakta olup zamanında öngörülemediği için bu tablolarda bir TimeStamp bulunmamakta. Attunity gibi bir ürünün kullanılması durumunda ise ekstra lisans maliyetleri gündeme gelmektedir.
Avantaj ve dezavantajlar ne olursa olsun, yukarıda belirttiğim gibi Real-Time Dashboard için gerekli konulardan ilki değişen kayıtların yakalanabilmesi için gerekli politikanın netleşmesi ve buna paralel bir implementasyonun gerçekleşmesi.
CDC Süreci
İkinci aşamada ise bu CDC verilerinin ne yapılacağıdır. Değişen kayıtlar elde edildikten sonra iş zekası araçlarına anında bu verilerin aktarılabilmesi gerekmektedir. İş zekası aracında (ya da bir ETL engine’inde) bir prosesin yeni bir CDC veri kümesinin olup olmadığını dinlemesi gerekmektedir. Bir listener olarak nitelendirilebilecek bu proses, yeni oluşan CDC veri kümesini aldıktan hemen sonra bunu işleme sokabilecektir.
Ancak az önce söylediğim gibi dashboard uygulamalarında çoğu kez verilerin işlenmesi ve transformasyonu gerekmektedir. Bu nedenle CDC kayıtlarının direk ön yüz uygulamaları içine alınması çoğu kez bir anlam ifade etmeyecektir. Onun yerine bu kayıtların sadece dashboard için oluşturulmuş datamart tarzında bir yapıya eklenmesi gerekmektedir Başka bir söylemle, varolan datamart yapısı üzerinde Incremental Load sürecine dahil edilmesi gerekecektir. Bu durumda da seçilen teknolojilerin alternatif yöntemlerle elde edilmiş bu CDC veri kümesini, hedef veri kaynağı üzerinde Incremental Load işlemelidir. Bu yaklaşım sonucunda en güncel veriler Dashboard Datamart üzerinde biriktirilmiş olacaktır.
Son aşamada ise son kullanıcı arayüzündeki dashboard uygulamalarının bu değişikliklerden haberdar olması için trigger benzeri bir mekanizmaya ihtiyaç bulunmaktadır. Bu da sağlanırsa son kullanıcılar ekranda herhangi bir tuşa dokunmasa bile dashboardlarının ekran üzerinde kendiliğinden güncellenmesini sağlayabilir.
Tüm bunlara rağmen özellikle yüksek sayıda işlemin gerçekleştiği kurumlarda bu işlemleri push tekniğiyle gerçekleştirmektense Near-Real-Time olarak yapılmalıdır. Dashboard’ların belli aralıklarla güncellenmesini sağlayan bir altyapının kurulması çoğu senaryoda daha verimli olacaktır. Aksi takdirde tüm bu süreçler özellikle network altyapıları gözönüne alındığında operasyonel sistemlerin performansını olumsuz derecede etkileyecek sonuçlara neden olabilir.