Makale Özeti

OLAP kavramı merkezli Business Intelligence (Kurumsal iş zekası) evreninde dolaşarak farklı açılardan bakmaya çalışıyoruz. Bu makalede basit bir özet tablodan yola çıkıp veri ambarına; ordan da analiz servis kübü üzerinden alınan raporlara uzanan yolda yaşananlara şöyle bir göz atıyoruz.

Makale

Hangi raporlama aracı olursa olsun (gerek kendi yazdığımız, gerek Microsoft ya da başka bir şirketin ki) veritabanı biraz büyüdükçe işler karışmaya başlar.Bir uygulama için veritabanı tasarlanırken iki ana amaç vardır ve veritabanı motorunun en önemli görevleri de bunlardır :

  • insert, update, delete işlemleri hızlı çalışsın. Tablolar arasında ilişkiler olsun.
  • Veriler tutarlılığını korusun. Veri tekrarı olmasın.

Neden Analiz Servis?
Analiz servis gibi bir yapıya ihtiyaç duyulmasının sebebi raporlamanın canlı ve büyük veritabanı sistemleri üzerinden doğrudan alınmak istenmemesinden kaynaklanır aslında.Çünkü canlı sistemlerde (-OLTP- yani şirket bünyesinde bir ya da daha fazla uygulamanın doğrudan beslediği/beslendiği veritabanı sistemleri) kendimizi tekrar etmemek ve veri bütünlüğünü sağlamak için normalizasyon yapılır. Böyle bir veritabanında rapor almak istediğimiz vakit örneğin 10 tabe tabloya gitmek gerekebilir; ki bunların çoğu da hatırı sayılır boyutlarda kayıt ve kolon kombinasyonuna sahip olabilir. Kullanılan ram'in maksimum 8 - 16 gb. olduğunu düşünürsek (Tabi bunun tamamını rapor sistemleri için ayıramadığımızı gözden kaçırmayalım) bu boyutta verinin belleğe çıkması sorun olacaktır.(Arttırılabilse de 32 bit makinelerde sql server'ın adresleyebileceği bellek alanı varsayılan olarak bu değerlere çıkamaz zaten) Bu sorunlar, rapor alanların raporlarını yavaş alması, sistemin çalıştığı uygulamalardan birinin yavaşlaması ya da kilitlemesi şeklinde baş gösterebilir. Sonrasında senaryo genelde şu şekilde cereyan eder : Programı kullanan son kullanıcı şirketteki yazılım departmanını, raporu alan son kullanıcı ise şirketin veritabanı yöneticisini arar ve derdini anlatır. Problem karşısında alınabilecek tek aksiyon çoğu zaman uygulamanın ve/veya rapor sürecinin durdurulması ve sırayla!!! tekrar başlatılması olur. Hatta veritabanı yöneticisi, -gerçek problemin farkında ya da değil- raporun sorgusunu inceler ve "dur ben şu kolona bir index atayım da rapor hızlansın" şeklinde geçici çözümler üreterek günü kurtarmaya çalışabilir. Canlı sistemdeki ham verinin, aynı zamanda raporlama ve analiz için kullanılması sağlıklı değil, tamam; peki neler yapılabilir?

Özet Tablolar
Canlı sistemin DML (Data Manipulation Language -veri üzerinde güncelleme yapan komutlar kümesi-) sorgularının dışında kalması gereken farklı bir tablo yapısı için akla gelebilecek olan çözümlerden birisi, aynı veritabanı yapısı içerisinde özet tablolar ile çalışmak olabilir. Ham veri içeren tablolardan trigger'lar ile beslenen ya da bir uygulama ile belli aralıklarla hesaplatılan özet tablolar örneğin yıllara, şehirlere ve mağazalara göre toplam satış rakamlarını hazır bir şekilde saklayabilir. Almak istenilen her rapor için bu konseptte özet tablolar hazırlanıp ve bu tablolardan hızlı bir şekilde raporlama yapılabilir. Ancak özet tabloların güncellenmesi trigger'lar yerine bir uygulama aracılığıyla yapılırsa kaçak olması ihtimali vardır; yani yanlış özet bilgilerin hesaplanması mümkündür. Tabi ki tutarsız veri istemeyiz. Bu tarz kaçakları önlemek için trigger'lardan faydalnılsa dahi yönetim zorluğundan kurtulmak için başka çözümler aranabilir.

Indexed View
Rapor alınmak istenen özet tablo bir view olarak saklanabilir. Üzerine clustered index atılmış bir view, verisini sıralı tutmak isteyeceğinden kendi üzerinden saklar ve veri dosyasında bağımsız bir bellek alanı kullanmaya başlar. Gerçek verilerin orjinal tablolardan hesaplanarak view'e aktarılması, sql server database engine'i tarafından sağlanacağından veri tutarsızlığı problemi aşılmış olur ve yine raporlar hızlıca alınabilir.. Bu aşamada dikkat edilmesi gerekn bir detay ise OLTP sistemdeki transaction'ların yazılmasının yavaşlayacaktır. Çünkü yapılan her işlem, aynı zamandan bir view üzerinde aggregate function'larla (sum, avg, count vb.) hesaplanan işlemleri yanında getirdiği için 2 adım ileri gitmeye çalışırken 1 adım geri gitmeye sebep olabilir. Tabi bu senaryo, verinin boyutunun anlamlı büyüklüklere ulaştığı zaman geçerli olacaktır.

OLAP Cube
Bu yüzden cube denen ve verinin OLTP'dekinden farklı yapıda saklandığı sistemler vardır. Küpler ile veri yapısnın, istenen raporların alınması için önceden hazırlanması amaçlanır. Farklı boyutlarda (ürün, zaman, müşteri, mekan vb) farklı ölçülebilir büyüklüklerin (satış, karlılık vb.) bütün kesişimlerindeki verilerin raporlanmak için hazır bekleyeceği bir altyapı sunan OLAP küpleri sayesinde sağlıklı bir veri yapısı ve hızlı bir raporlama altyapısına sahip olunabilir.Bu arada küp teriminin kullanılmasından dolayı, hesaplanmış bir şekilde bekleyen verilerin bulunduğu yüzlerin sayısının matematikteki küp'ün yüz sayısı (6) ile aynı olmak zorunda olduğu akla gelmesin. Sadece çok boyutlu bir yapıyı temsil ettiğini göstermek için bu terim kullanılmaktadır. Bir analiz servisi kübü üzerinden çeşitli araçlar ile analizler yapılabilir ve raporlar tasarlanabilir. Bunlara örnek olarak aşağıdakiler gösterilebilir:

  • Sql Server Reporting Service,
  • Performance Point Server 2007,
  • MS Office Excel ya da analiz servisin kendisi ile veri madenciliği (data mining), 
  • Analiz servisin kendi sağladığı arayüzde pivot table mantığında analizler gerçekleştirilebilir.

Data Warehouse
Bir OLAP kübünün verisini nereden aldığı incelenecek olursa process denen bir süreç sonunda verinin bir veritabanı sisteminden çok boyutlu yapılara alındığı söylenebilir.Bir kübün process edilmesi ile kaynak verileri alarak yüzeylerindeki hesaplamaları güncellemesi sağlanır. Tahmin edersiniz ki raporlanacak verinin, taze veri olma ihtiyacına bağlı olarak bu işlem belirli aralıklarla tekrarlanmalıdır (job'lar yardımıyla) Burada kübe kaynak veriyi sağlayan veritabanı ortamı, canlı bir uygulama grubunun beslediği bir OLTP veritabanı sistemi olabileceği gibi OLTP ve OLAP kübünün arasında yerini alacak başka bir veritabanı ortamı da olabilir. Bu ara veritabanı ortamının veri yapısı, canlı sistemin isteklerinin aksine raporlama sisteminin isteklerini gözetecek şekilde dizayn edilir. Veri ambarı (data warehouse) diyeceğimiz bu sistemde, OLTP veritabanlarının aksine veri tekrarı yapmaktan korkmayız, daha genel bir ifadeyle normalizasyonu sıfıra yakın kullanırız; böylece mağazalarımızın adreslerini tutmak için 5-6 ayrı tablo yerine tek tablo kullanabiliriz, hesaplanan kolonları veri dosyasına yazılı bir şekilde tutarız, anahtarlar ve kısıtlamalardan olabildiğince kaçarız vb. Bütün bunların amacı, veriyi canlı veritabanı sisteminden veri ambarına daha hızlı bir şekilde pompalamak ve raporlamaya uygun bir şekilde hızlı select atılabilmesini sağlamaktır. Veriyi canlı sistemden veri ambarına pompalamak için bir ETL (Extract - Transform - Load) aracının kullanılması gerekir. Microsoft Sql Server 2005 içerisinde bu iş için kullanılan araç SSIS'dir (Sql Server Integration Service). Veri transferi için hazırlanan SSIS paketleri belirli aralıklarla çalıştırılarak rapor verisinin veri ambarına aktarılmasında başrol oynar. Veri ambarı içerisinde tartışılması gereken fact tablolar, dimension tabloları vb. kavramları sonraki makalere bırakalım. Akla gelebilecek bir soruyu cevaplandırarak makaleyi sonlandıralım: Madem veri ambarının veri yapısı OLTP'ye nazaran raporlamaya daha uygun yapıdadır ve canlı sistemin güncellemelerinden uzakta ayrı bir veritabanı yapısı olarak tasarlanmakta ve beslenmektedir; neden raporları buradan almıyoruz da gidip bir de analiz servis ile küp tasarlıyoruz ve raporları oradan alıyoruz? Aslında bu sorunun cevabı yukarıda bulunmaktadır. En başta veri ambarı, her ne kadar veriyi OLTP bir veritabanına göre raporlamaya daha uygun tutsa da bir OLAP kübünün yaptığı gibi farklı boyutlardaki ve ölçülebilir büyüklükteki veriyi küpte tasarlanan çok boyutlu veri yapısındaki her kesişim noktası için hesaplayarak (process işlemi sonrası) rapor alınmaya hazır bir şekilde bekletmez. Rapor anında birçok hesaplamanın yapılması gerekir ki bu da bizi birincil amacımız olan daha performanslı raporlar almaktan uzaklaştırır.Ayrıca eklenebilecek ikinci bir sebep, küp üzerinden kolayca gözlem ve analiz yapılmasını sağlayan pivot mantığının sadece veri ambarı ile bu kolay yapılamayacak olmasıdır.

Bir sonraki makalede görüşmek dileğiyle...