Veri ambarı projelerinde karşımıza çıkan sorunlar

Merhaba ,

Bilginin güç getirdiğini keşfettiğimizde medeniyetimizi kurmaktaki ilk adımı atmış olduk. Bu durum hiç değişmedi hatta artarak günümüze geldi.

Bugünün koşulları hala çağlar öncesi kadar vahşi. En doğru bilgiye en hızlı ulaşanın hayatta kalacağı bir endüstri savaşı var. Kurumların veriden bilgi edinmesi ömürlerini sürdürebilmeleri için elzem bir halde. Kobilerden en dev kurumlara kadar uyulması gereken bir kural.

Kurumsal yapıların onlarca sistemin oluşturduğu veriyi işlemesi bu veriden anlam çıkarması ,geçmişi görüp geleceğe ışık tutmasını sağlayan yapıların başında veri ambarı geliyor. Doğru bir veri ambarı yapısı ile geçmiş analiz edilip , veri analitiği projeleri ile karlılık maksimize edilirken , maliyetler de minimize ediliyor.

Veri ambarı 1980 lerden beri oluşturulmuş bir konsept olmasına rağmen günümüzde hala bir çok veri ambarı projesi başarısızlıkla sonuçlanıyor. Başarısızlığın başlıca sebeplerini aşağıdaki gibi derleyebiliriz.

İHTİYAÇ ANALİZİ : İş birimlerinin ihtiyaçlarını kendi taraflarında netleştirmemiş olması
Teknik ekiplere iletilen ihtiyaç analizi ya da teknik analiz dokümanları yeterince emek verilmeden oluşturulduğu zaman v2 ,v5 ,v11 diye uzayıp giden bir doküman bataklığına dönüşüyor.Artan versiyon sayısı hem veri modelinin hem de ETL lerin revize edilmesini ya da sıfırdan yapılmasına sebep oluyor. Günün sonunda elde ihtiyacı yarım yamalak karşılayan bir rapor , harcanmış olan onlarca saatlik efora değmiyor.

KAYNAK ANALİZİ : Kaynak analizi yapılmamış olması ya da yetersiz yapılması
– Tabloların ilişkilerinin – ki bu ilişki PK-FK ilişkisi de olabilir mantıksal ilişki de olabilir- yeterince tespit edilmemiş olması.
– Tablolardaki veri üreme sıklıklarının , analiz edilmemiş olması.
– Farklı kaynaklardaki aynı ürün , müşteri , adres , tedarikçi vb entity’lerin tekilleştirme senaryolarının analiz eksikliği
– Kaynak sistemlere ait dokümantasyon eksikliği
– Farklı sistemlerdeki iş süreçlerinin analizlerindeki eksiklikler
– Veri kalitesinin yetersizliği

EKİP & TECRÜBE : Tecrübeli kaynakların yetersizliği.
-Yetkin veri ambarı mimarı bulunmaması
– Yetkin ETL developer bulunmaması
– Yetkin BI developer bulunmaması
– Yetkin BI analist bulunmaması


BEST PRACTICE : Kullanılan veri tabanı ya da veri tabanları , ETL ürünü vb platformların yetkinliklerinin , “best practice” lerinin bilinmemesi
Hiç bir platform tam anlamıyla diğerinden üstün değil. Eğer öyle olsaydı boşu boşuna haftalarca POC süreçleri için vakit harcamak yerine bütçemize göre en kalitelisini alır kullanırdık. Gerek veri tabanı yönetim sistemlerinin gerek ETL ürünlerinin gerekse de iş zekası uygulamalarının birbirlerine göre üstünlükleri ve birbirlerinden geri kaldıkları noktalar bulunuyor. Kullanılan her ürünün üstün özelliklerinin tek bir kişi tarafından bilinmesi mümkün bir senaryo değil , zira tek bir üründe bile hemen hemen her yıl minör ya da majör versiyon güncellemeleri oluyor.
Kullanılan platformların üstün noktalarını bilmek hem geliştirme maliyetini , hem de geliştirme tamamlandıktan sonra operasyon maliyetini düşürüyor. Günün sonunda bu iki parametre de bütçede bir yer kapladığından kullanılan platformlarda yetkin kişilerin ekipte olması orta ve uzun vadede karlı bir yatırıma dönüşüyor.

ENVANTER : Belirli bir rapor envanterinin bulunmaması
Migration projelerinde ya da sıfırdan veri ambarı projelerinde en çok sıkıntı çekilen nokta rapor envanteri bulunmaması. Raporlama alt yapısının günden güne geliştiği ortamlarda raporlama için doküman ve envanter oluşturulması rapor kirliliği oluşmaması adına da oldukça önem teşkil ediyor.
Sigorta ya da bankacılık gibi orta büyüklükteki veri ambarılarında bile yüzlerce ana rapor bulunuyor. Big data platformlarının sistemlere entegre olması ile bu sayılar üssel olarak artış gösteriyor. Hızla büyüyen bu artış belli bir zaman sonra kontrolden çıkıyor. Belirli bir rapor envanteri ve dokümantasyonun olması geliştirmelere ek bir adım ve vakit kaybı gibi görünse de kısa vadede bile oldukça önemli bir değer.

ACELE ETMEK : Hızlı çıktı alınması adına rapor bazlı yapılan geliştirmeler
Üst yönetime ya da müşteriye yaranma , daha ilk haftadan ilerleyiş gösterme derdinde olan ekip yöneticileri genellikle bu hatanın bedelini birkaç ay içerisinde ödemeye başlıyorlar. Bu bedel çoğu zaman DB kirliği , benzer rapor için çok benzer akışların mükerrer olarak oluşturulması , raporlardaki yeni ihtiyaçların modelsel olarak giderilememesi gibi problemler oluyor. Bunun yanında ETL süreçlerinin her rapor tablosu için tekrar tekrar oluşturulup çalıştırılması kısa sürede CPU, Storage , RAM vb fiziksel yatırımların arttırılmasına sebep oluyor. Bu arada Jobların monitoring maliyetinin , hatalardaki çözüm sürelerinin , db deki yoğunluğun yönetilmesi de cabası.

ETL MİMARİSİ : ETL mimarisinin planlanmamış olması
– Birbirinden beslenen tabloların yüklenme zamanlarının çakışması , hangi job’ın hangi job a bağımlılığının olduğunun analizinin yapılmaması
– Benzer ya da aynı hesaplamaların farklı ETL süreçlerinde defalarca yapılması.
– Veri üreme sıklığının kontrolü yapılmadan farklı tabloların join’lenerek incremental job yapılmaya çalışılması.
– ETL geliştirmeye yeterince süre ayrılmaması
– ETL job’larının test ortamında değil production ortamda geliştirilmesi.
– Performans testleri yapılmadan devreye alınması

VERİ MİMARİSİ : Veri ambarı mimarisinin planlanmamış olması
– Veri ambarı katmanlarının oluşturulmaması. Örneğin , ODS , STG , DWH , DM gibi katmanların birbiri ardına çalışıp düzenli bir ilerleyişe sahip olması yerine, rastgele geçici tablolardan oluşturulmuş sözde datamart’lar ile raporlamanın yapılması.
– Farklı katmanlardaki tabloların -örneğin ODS ya da STG- doğrudan raporlarda kullanılıp DM katmanındaki tablolar ile bağlandığı modeller oluşturulması.
– Kaynaklardaki veri standardize edilmeden, veri kalitesi arttırılmadan olduğu gibi süreçlerde kullanılması.
– Kaynak tablonun başına ya da sonuna DWH eki getirilerek adına DWH tablosu denmesi.
– SCD yapılarının gerekli biçimde kullanılmaması
– Farklı zaman pencereleri için yapılan hesaplara dair time dimension yapısı yerine her aralık için ayrı ayrı rapor oluşturulması.
– Fact ve Dim yapılarının bilinmemesi her rakama fact , her sözel veriye dim gözüyle bakılması.
– Nasıl olsa ilerde lazım olur diyerek gereksiz kolonların tablo üzerinde bulundurulması.
– Kaynaktan silinen verinin inicial aktarım ile DWH ortamından da silinmesi.
– KVKK/GDPR gibi yasal düzenlemeler göz önüne alınmadan kişisel veya kritik bilgilerin rastgele tablolarda bulundurulması
– TCKN , VKN gibi alanların key olarak kullanılması
– Veri ambarının hesaplama merkezi gibi düşünülüp diğer sistemler üzerinde yapılması gereken işlemlerin DWH da yapılıp sonra tekrar ilgili sisteme aktarımlarının yapılması.

YÖNETİM : Veri yönetimi konseptlerine hakim olmayan yöneticilerin tüm bu süreci küçümsemesi, basit bir işmiş gibi düşünmesi.
Veri ambarı , iş zekası , veri analitiği , büyük veri , veri yönetişimi vb bir çok ekip büyük kurumların karar destek mekanizmalarının temelini oluşturuyor. Bu kadar büyük bir orkestrayı yönetmek gerçekten zor. Fakat veri ile alakalı işlere “Ne var canım , selekt yıldız fırom” gözü ile bakılması ,işlere gereken planlama , kaynak ve platform yatırılmarının bir araya getirilmemesi ile kurumlar gözleri bağlı kalabiliyor. Her “gitar çalan”ın orkestra ya giremeyeceği gibi her “sorgu yazmayı bilen” de bu devasa orkestra olmamalı. Personel maliyetinden kısmak isteyen kurumlar günün sonunda raporlama ve analitik projelerde para yakmaktan öteye gidemeyebiliyor.

Dilbert by Scott Adams | Data science, Data, Data quality