Bu yazımda veri madenciliği modelleme sürecindeki basamaklardan bahsedeceğim. Veri madenciliği modelleme sürecinde bulunmamış okuyucular için bir veri madenciliği projesindeki basamakları anlamak adına faydalı olacağını düşünüyorum. Daha önceden modelleme tecrübesi olanlar için de kullanılan süreçle yazımda geçen süreci kıyaslamak açısından faydalı olabilir.

Veri madenciliğini anlatmaya birkaç veri madenciliği tanımını inceleyerek başlayalım:

Principles of Data Mining by Hand, David:
‘Data mining is the analysis of (often large) observational datasets to find unsuspected relationships and to summarize the data in novel ways that are both understandable and useful to the data owner.’ 

Applied Data Mining by Paolo Giudici:
Data mining is the process of selection, exploration, and modeling of large quantities of data to discover regularities or relations that are at first unknown with the aim of obtaining clear and useful results for the owner of the database 

Vikipedi:
Büyük veri yığınları içerisinden gelecekle ilgili tahminde bulunabilmemizi sağlayabilecek bağıntıların bilgisayar programı kullanarak aranmasıdır.

Yukarıdaki 3 tanımda bazı kelimeleri bold yaptım. Bu kelimeleri gruplayarak incelersek veri madenciliğinin anahtar kelimelerini yakalamış oluruz.

Veri Boyutu:
(often large) observational data sets
Large quantities of data
Büyük veri yığınları

Çıktı:
Understandable, useful and unsuspected relationships
Unknown, useful results
Gelecekle ilgili tahmin

Yöntem:
Novel ways
Process of selection, exploration, and modeling
Bilgisayar programı kullanarak

Her üç tanımda da belirttiğimiz gibi üç farklı alana vurgu vardır. Her şeyden önce veri madenciliği yüksek hacimde veriye ihtiyaç duyar. Kurumsal veri ambarları bu ihtiyaca cevap verirler. İkinci olarak, veri madenciliği kompleks bir takım algoritmalarla yapılır. SAS, SPSS gibi yazılımlar da algoritma ihtiyacına cevap verir. Tanımlardaki bir diğer vurgu da amaç ve çıktı ile alakalı. Veri madenciliğinin amacı, öncesinde bilinmeyen ama bir iş değeri olan bir takım bilgileri ortaya çıkarmaktır. Söz gelimi, bir GSM Operatörü için müşterilerinin %90’ının siyah gözlü olması bilgisi bir veri madenciliği projesinin çıktısı olmamalı.

Veri Madenciliği Proje Süreci
Her kurumun, kişinin benimsediği kendine has süreçleri muhakkak vardır ama temelde veri madenciliği proje sürecini aşağıdaki basamaklarda tanımlayabiliriz.

1. Problem tanımının yapılması

1. Veri kümelerinin oluşturulması

1. Modellerin geliştirilmesi

1. Modellerin değerlendirilmesi

1. Modelin deploy edilmesi

1. Model geçerliliğinin kontrolü

Problem tanımının yapılması:
Bu basamak aslında çok basit bir basamak olarak görülüyor olabilir ancak tüm projeye yöne verecek basamak olması açısından çok önemlidir ve dikkatle yapılmalıdır.

Problem zaten bellidir, tanımını yapmak gerekmez çünkü ortadadır her şey zaten diye düşünenler olabilir. Evet, problem veya bulunmak istenen şey aslında nettir ama bu işi veri madenciliği projesi seviyesinde düşünmek önemlidir. Problemi ve muhtemel sonucunu düşünürken bulunacak sonucun gerçekten problemin çözümü olup olamayacağı iyi analiz edilmelidir.

Mesela herhangi bir sektörde yapılabilecek bir müşteri tutma projesi ele alalım. Bu projeyi gerektirecek problem bellidir. Bir şirketin müşterileri o şirketten ayrılıyordur ve müşteriyi tutmak için bir proje geliştirmek isteniyordur. Problem net gibi görünüyor ama bu problemi veri madenciliği projesi seviyesine çekebilmek lazım. Gidecek müşteriyi tahmin edebilsek gitmesini engelleyecek aksiyonlarda bulunabiliriz değil mi? O halde problemi müşterinin gitme ihtimalini tahmin etmeye dönüştürmüş olduk. Bunu da netleştirmek lazım çünkü müşterinin gitme olasılığı havada bir kavramdır. Problemin, müşterinin yarın gitme ihtimalini hesaplamak olması işi biraz daha netleştirir ama yarın gidecek müşteriyi bilmek bize birşey kazandırmaz çünkü aksiyon alabilmek için daha fazla zamana ihtiyaç var o halde bir müşterinin önümüzdeki bir ay içinde gitme ihtimalini hesaplamak olarak problemimizi finalize edebiliriz.

Sonuç olarak, bu basamakta görünen problemi veri madenciliği seviyesine çekiyoruz ve üretilecek muhtemel sonucun aksiyon almaya açık olduğunu da garantiliyoruz.

Veri kümelerinin oluşturulması:
Problemi netleştirdikten sonra probleme özel veri hazırlanması gerekiyor. Veri hazırlama kısmı bir veri madenciliği projesinin en fazla zaman alan kısmıdır. Veri ambarında mevcut birtakım verilerin yanısıra birçok başka sistemden veri alma ihtiyacı doğacaktır. Verinin kalitesini sağlama, entegrasyonu, temizliği gibi işlemler yapılmalıdır ki bütün bunlar vakit alıcı işlerdir. Bu basamağın sonucunda genelde müşteri bazlı olarak birçok indikatör kolon ve bir tane de hedef kolondan oluşan bir tablo ortaya çıkar. İndikatör kolondan kastım müşteriyle ilgili ve problem için belirleyici olacağı düşünülen kolonlar. Hedef kolon da tahmin etmeye çalıştığımız sonucun geçmişte gerçekleşen örneklerinden oluşan kolondur. Mesela müşterinin ne kadar zaman daha müşterimiz olarak kalacağını tahmin etmeye çalıştığımızı varsayalım bu durumda indikatör kolonlar müşteriyle ilgili demografik ve davranışsal tüm bilgiler hedef kolon da mevcut müşterilerin ilk müşteri olmasından bu yana geçen zamandan oluşabilir.

Bunlarında yanında bu basamakta yapılması gereken ve sonuca da direk etkili olacak bir işlem de yeni değişkenler, indikatörler yaratılmasıdır. Mesela elimizde müşterinin toplam işlem sayısını gösteren bir indikatör kolon olduğunu varsayalım. Belki de bu kolonu toplam işlem sayısı 10’dan küçükse 0 büyükse 1 olacak şekilde transform etsek sonuç çok daha iyi çıkabilir. Bu tarz indikatörler üretmek için beyin fırtınası seansları yapmak faydalı olacaktır.

Modellerin geliştirilmesi:
Verimizi de hazırladıktan sonra artık veri madenciliği modelimizi geliştirebiliriz. Modeli geliştirme işi genelde bir yazılım kullanılarak yapılır ki en çok kullanılan yazılım da SAS Enterprise Miner’dır.

Bu yazılım metod olarak bir çok seçenek sunar: Regression, Decision Tree, Neural Network, Support Vector Machine, vb.

Farklı yöntemler kullanarak veya bir yöntemi farklı parametrelerle kullanarak değişik modeller geliştirebiliriz.

Modellerin değerlendirilmesi:
Geliştirdiğimiz birçok modelden en iyiyi seçme işleminin yapıldığı basamaktır. Veri Madenciliği yazılımları model değerlendirme için de bir takım metotlar sunarlar. Bu metotların sonucunu hem sayısal hem de görsel olarak tüm modeller için inceleyip ona göre en iyi modeli belirlemek gerekir.Bu değerlendirmeyi yapabilmek için aşağıdaki yöntemleri bilmek gerekir.

Değerlendirme Yöntemleri: Lift Chart, Concentration Chart, Receiver Operation (ROC) Curve ,Score Distribution

Modelin deploy edilmesi:
Modellerin değerlendirilmesi basamağından sonra artık elimizde bir tane final model var. Artık bu modelimizi birinci basamaktaki problemimize uygulayabiliriz. Bu defa modeli oluşturduğumuz veri dışındaki bir veri kümesine(başka zaman aralığındaki) modeli uygularız.Ayrıca eğer modelin belli periyotlarla yeniden çalışması isteniyorsa yapılması gereken otomasyon işleri de bu basamakta yapılır.Bu basamakta çıkan model sonucuna göre bir takım aksiyonlar alınabilir.Mesela eğer bir sms kampanyası yapılacaksa bu model sonucunda en büyük skoru alan müşteriler seçilerek onlara sms atıılır.

Model geçerliliğinin kontrolü:
Deploy ettiğimiz model her geçen gün güncelliğini kaybeder çünkü zamanla bir takım şartlar değişir ve modeli geliştirdiğimizde sonucu etkileyen değişkenler artık etkisiz kalır veya yeni bir takım parametreler daha etkili olmaya başlayabilir. Bu durumda üretilen skorlar başarısız olacaktır. Bunu engellemek için her model kullanıldığında performansını ölçmek gerekir. Bu kontrolü model değerlendirmesinde bahsettiğimiz yöntemlerle yapabiliriz ve eğer model performansı düşük çıkarsa yeniden ikinci basamağa dönüp güncel verilerle gerekli veri kümelerini oluşturup model geliştirme süreci tekrarlarız.

Özetlemek gerekirse, bir veri madenciliği projesinde ilk basamak olarak problemin net bir şekilde tanımlanması gerekir ardından bu probleme uygun veri kümeleri ve bu veri kümeleri kullanılarak indikatör değişkenler ve hedef kolon(lar)’dan oluşan bir final tablo oluşturulur. Bu tablo üzerinde çalışılarak değişik modeller geliştirilir. Sonrasında bu modellerden en iyisi seçilerek deploy edilir ve sonuca uygun aksiyonlar alınır.Model geçerliliğini kaybettiğinde de tekrar yeni veri kümeleriyle yeni model geliştirilip deploy edilir ve bu bir döngü halinde devam eder.

Güven Gül

Veriambarı bir organizasyonun elektronik olarak saklanan datasının deposudur.Veri

ambarları raporlama ve analizi kolaylaştırmak için dizayn edilmişlerdir. Veriambarları analiz ve ilişkili verilerin sorgulanabildiği sistemlerdir.Birden fazla kaynak sistemin işleme tabi tutulmasıyla oluşmuştur.Ayrıca bu şekilde anlık işlemlerin gerçekleştiği veritabanlarındaki tutarsızlıkların ve kirli verilerin filtrelenerek analiz ve raporların etkilenmemesi sağlanmıştır.

 

Veri ambarının yapısı genel itibariyle şu aşamalardan oluşur;

 

1.Kaynak sistem:Günlük işlemlerden gelen kayıtların(transactionların)kaydedildiği

veritabanlarıdır.Bu veritabanları genelde tek bir işlev için normalize edildikleri için bunların hem raporlamada hem de işlemler için kullanılmaları verimi düşürür.

 

2.ETL(Extract-Transform-Load):ETL sürecinin ilk parçası olan extract aşamasında veri kaynak sistemlerden

 

ortaya çıkmaktadır.Bu şekilde farklı kaynaklardan gelen datalar üzerinde daha etkin ve kolay şekilde sorgulama yapılabilmektedir.

 

 

Veriambarları iş    zekası çözümlerinde de kullanılmaktadır.İş zekası daha iyi iş kararları verebilmek amacıyla kullanılmaktadır[2].Veriambarları günümüzde birçok sektörde kullanılmakla birlikte özellikle rekabetin yoğun olduğu telekomünikasyon sektöründe kullanılmaktadır.Burada abonelere sunulan kampanyaların sonuçları,verilen bonusların kullanılma durumu gibi çeşitli işlevlerin yanında özellikle numara taşıma sonrası abonenin gidebileceğini tahmin eden algoritmalar da kullanılmaktadır.

 

 

Günümüzün bilgi çağı olmasından dolayı sürekli artan veri miktarının saklanması için veritabanları sürekli artmıştır.Ancak bu veritabanlarında bulunan veriler raporlama ve analiz için kullanılmaya uygun değildir.Bu verileri raporlama ve analizde kullanabilmek için buradaki ham bilginin kulanılır şekile dönüştürülmesi gerekmektedir.

 

 

Genel itibariyle veri tabanları hızlı ve etkin veri girişi,çıkışı ve güncellemesi için tasarlanmışlardır.Ancak bu yapılarda analiz ve raporlama için gereken algoritmaları çalıştırarak analiz ve raporlamaları gerçekleştirmek çok zordur.Bu nedenle yeni bir veritabanı oluşturularak bu yeni veritabanına sadece analiz ve raporlamada kullanılacak verilerin taşınması gerekliliği çekilir.Genellikle veriambarları birden fazla farklı kaynak sistemi kullanmaktadır.

 

 

Bu kısımın esasında çekilen verinin beklenen yapıya uygun olup olmadığının kontrol edilmesidir.Eğer değilse veri veriambarına alınmaz.

 

 

ETL sürecinin ikinci ayağı olan transform(dönüştürme)aşamasında ise birçok kural ve fonksiyonun extract edilen veriye uygulanmasıdır.Bu sayede iş ve teknik taleplei karşılayan hedeflenen veri kaynaktan türetilmiş olmaktadır.

 

 

ETL sürecinin son ayağı olan load(yükleme) aşamasında ise veri veriambarına yüklenir.Ancak bu işlem iş isteklerine göre değişebilmektedir.Mesele kimi işletmelerde mevcut veriye eklenerek giderken,bir kısmında haftalık olarak yenilenmekte ya da tarihsel olarak yeni data eklenmektedir.

 

 

1.Metadata: Veri hakkındaki bilgilere metadata denilmektedir.Veriambarında bulunan herbir veri elemanının anlamını,hangi elemanın hangi elemanlarla ilişkisi olduğunu,bu ilişkinin hangi şekilde gerçekleştiğini ve kaynakta bulunan veri ile hedefteki veri gibi bilgileri kendine tutmaktadır.

 

2.Front-end:Kullanıcı tarafında raporlama ve analizde kullanılmak üzere çeşitli araçlar kullanılarak veriambarına erişmesidir.

 

2.YAZILIM TEST

 

 

Bir program veya sistemin özelliğinin veya yeteneğinin değerlendirilmesi ve beklenen

sonuçlarım gözlemlenebilmesi için yapılan aktivitelere yazılım testi denilmektedir [3].

 

Yazılım testi genel itibariyle müşteri talepleri doğrultusunda geliştirilen bir yazılımın, kalite düzeyi müşteri tarafından belirlenen maliyet analizi göz önüne alınarak,müşterinin beklediği kalitede olup olmadığının belirlenmesi sürecidir.Yazılımlardaki hatalar geliştirici,analist gibi insan kaynaklı olmakla birlikte donanımsal kaynaklı da olabilmektedir.Bütün yazılım hatalarıkodlama hatası olmayabilir.Pahalı hataları meydana getiren ortak kaynak ihtiyaç analizleridir.Beklenilmeyen ihtiyaçlar yazılım dizaynırı tarafından ele alınmaz[4].

 

 

Yazılım geliştirme süreçlerine testin eklenmesinin nedeni yazılım geliştirme süreci sonucunda ortaya çıkan hataların müşteriye geri dönülmesi zor durumlara bırakmamasını sağlamaktır.Çünkü yazılımlarda bulunan bir hata canlıya alındığında yazılımın yaptığı işe göre bir şirkete itibar,para ve müşteri kaybına neden olabilmektedir.Tüm bunların önüne geçebilmek için test süreçlerini yazılım sürecinin içerisine yerleştirmek gerekiyor.

 

 

Yazılım doğrulama(verification) ve onaylama(validation)’nın birleşiminden oluşur.

Doğrulama:Yazılımı doğru yaptık mı?

Onaylama:Doğru yazılımı yaptık mı? 

 

 

Yazılım test süreçlerini aşağıdaki şekilde sınıflandırabiliriz;

Sistem bilgisine göre;

 

1.Black box test;

 

2.White box test;

 

3.Gray box test:

 

Yazılım yaşam döngüsünde çalıştırılma zamanına göre;

 

1.Unit test

 

2.Entegrasyon testi

 

3.Sistem testi

 

4.Kullanıcı onay testi

 

Testleri amaçlarına göre de sınıflandırabiliriz;

 

1.İşlevsel test:Yazılımın işlevsel yönünün irdelendiği testlerdir.Burada verilen bir girdinin

analize göre beklenilen çıktının verilip verilmediği test edilir.İşlevsel test yazılım yaşam

döngüsünün tüm anlarında yapılan testlerde kullanılabilir.

 

1.1.Yükleme testi(Installation test) : Kullanıcının ilk etkileşimi yazılımı yükleme sırasında oluşmaktadır.Farklı platformlarda yazılımın sorunsuz şekilde yüklenebildiği kontrol edilmelidir.Kullanıcı kurulumda sorun istemediği için çok önemli bir testtir.

 

1.2.Regresyon testi(Regression Test) : Regresyon testlerinin amacı yapılan bir hata düzeltmesinin veya bir değişikliğin halihazırda sorunsuz çalışan kısımları etkilemediğinin görülmesidir.

 

1.3.Yükseltme ve uyumluluk  testi(Upgrade and backward compatibility testing) : Her yazılımın sürekliliğini sağlamak için yükseltme sürümleri yapılır.Ancak bu sürümlerin önceki

sürümlerlerle uyumlu olması gerekmektedir.Bu nedenle bunun testinin yapılması gerekir.Bu teste uyumluluk testi adı verilir.

 

Yükseltme testinde ise kullanıcının efor sarfetmeden ve sistemini bozmadan bir yazılım yükseltmesi yapması beklenir.Bunun kontrolü için de yükseltme testi yapılır.

 

1.4.Erişilebilirlik testi: Kullanıcıların görsel,işitsel veya bedensel engelleri olabilir.Yazılımın bu kullanıcılar için çeşitli kolaylık sağlaması gerekmektedir.Bu nedenlede bu özelliklerin fonksiyonel testler sırasında kontrol edilmesi gerekmektedir.

 

1.5.Uluslararasılalıştırma ve yerelleştirme testi : Yapılan yazılımların diğer ülkelerde satışa sunulacak ise yazılımın bu ülkeler için uyumlu olması gerekmektedir.Bunun için yazılımın GUI’si,mesajlar,uyarı ekranları vb. Kısımlarının yerel dille yazılmış olmalıdır.Ayrıca bu değişiklikler yazılımın düzgün çalışmasını engellememelidir.

 

 

2.İşlevsel olmayan test: Test aktivitelerine odaklanılan,yazılımın işlevsel olamayan yönünü

irdeler,

 

2.1.Performans,yükleme ve stres testleri :  İşlevsel testlerden sonra yapılan bir testtir.Genel itibariyle bir kodlamanın hataları düzeltilmesinden sonra yapılır.Genel olarak web uygulamalarında kullanılır.Burada belli bir yük altında iken   sistemin cevap zamanı ve kullanımı testleri yapılır.

2.2.Kullanılabilirlik testleri :  Bir sistemin ne kadar kolay kullanılabilir ve öğrenilebilir olduğuyla ilgili testlerdir.Bu testler sayesinde müşteri memnuniyetiyle satışlar artar,destek için ayrılan kaynak azalır.

2.3.Güvenlik testleri : Güvenlik testindeki birincil amaç güvenlik açıklarını tespit etmek ve bunları tamir etmektir.Güvenlik testi genellikle kodlama  ve yükleme yapılıp operasyonel hale geldikten sonra yapılır. Bu test diğerlerinin aksine periyodik olarak ağ güvenliği için sistemin tüm güvenlik açıklarını tespit etmek için kullanılır.

 

 

 

3.VERİAMBARI PROJESİNDE TEST PROSEDÜRLERİ

 

 

Şirketimizin yapmış olduğu veriambarı projesinde kullanılan veri miktarı çok fazla olduğu için veriambarlarında kullanılan PL/SQL kodlarıyla verinin işlenmesi yetersiz kalmaktaydı.Bu nedenle ABINITIO adında ETL  (Extract,Transform,load) aracı kullanıldı.Bu aracın özelliği parametrik şekilde ayarlanarak paralel işlem yapabilmesidir.Bu nedenle çok büyük verileri kolaylıkla kısa zamanda işleyebilmektedir.

 

 

Bu araç tablo bazlı işlem yapmamaktadır.Yani bir veri işlenmeden önce tablodan dosyaya inilmeli sonrasında raporlamada kullanılmak üzere işlem sonrasında tekrar veriler dosyadan tablolara çıkılmaktadır.

 

Bu aracın bir diğer özelliği yarı görsel olmasıdır.Geliştirme hem görsel komponentler kullanılarak hem de kodlama yapılarak halledilmekteydi.

               

 

Bu projede yapılan geliştirmelerin testleri yukarıda bahsedilen testlerin  tamamı yapılamamıştır.Nedeni de sürenin kısıtlı olması ve bu nedenle bazı sorunlar geliştirme canlıya alındıktan sonra çıkmakta ve canlıda düzeltilmekteydi.

Yapılan testleri anlatacak olursam;

 

 

1.Yapılan geliştirme test grubuna ulaştığında öncelikle run olup olamadığı testi yapılmaktaydı.Yani giriş dosyaları veildiğinde dml hataları varmıydı,geliştirmenin çıkışında data oluşup oluşmadığıyla ilgili genel yapıyla alakalı testler yapılmaktaydı.Bu kısımda işlevsel testimizi halletmiş oluyorduk.

 

 

2.Canlıdan alınan güncel verilerle geliştirme run edilmekteydi.Bu şekilde oluşan çıkış verileri   ‘Veri Kalitesi’(Data Quality) testlerinde kullanılmak üzere tablolara yüklenmektaydi.Daha sonrasında bizler giriş veri tablolarını verilen analize göre SQL kodlamasıyla çıkış veri tablosunu oluşturmaktaydık.Son aşamada ABINITIO geliştirmesinin çıkış verisiyle,bizim yaptığımız SQL kodunun çıkış verisi  SQL’in ‘MINUS’ özelliği kullanılarak çıkış verisinin doğruluğu test edilmekteydi.

 

3.Incremental run   yapılarak geliştirmenin bir sonraki gün gelecek yeni insertleri,updateleri ve delete datalarını işleyip işleyemediğinin testini yapıyorduk.

 

 

4.Extraction ve load shell script kodlarının doğru şekilde tablolardan verileri çekip,tablolara düzgün şekilde yüklemesinin  testini yapıyorduk.

 

 

5.Canlıda olan bir geliştirmede hata bulunduysa düzeltmesi yapıldıktan sonra tüm geliştirme tekrardan bütünlüğünün bozulup bozulmadığıyla ilgili teste tabii tutulmaktaydı.

 

 

6.Performans testlerinde yapılan geliştirmelerde işlem tekrarlarının azaltılması yönünde yapılan geliştirmeler gözden geçirilmekte ve geliştiriciye bununla ilgili geri dönüş yapılmaktaydı.

Yukarıda bahsettiğim gibi yapılan testler daha fazla çeşitlendirilebilirdi.Ancak bir proje dahilinde kısıtlı zaman içerisinde yapıldığından dolayı test çeşidi olarak bu kadar yapılmıştır.

 

Okan Beşli

İ.Hakkı ÇAVDAR