|
İş Zekası projelerinin %60-%80 eforu verinin kaynak sistemlerden çıkarılması, gerekli çevrimlerin yapılması ve hedef sistemlere yüklenmesi (ETL) aşamalarında harcanmaktadır. Bu amaç için çok çeşitli ürünler aynı yöntemlerle veri çevrimlerini yapmakta ve veri akışını oluşturmakta. İşte bu ESKİ ihtiyaca YENİ bir yaklaşım getirmektedir Oracle Data Integrator (ODI) . Önceleri sadece veri ambarlarının oluşturulması için kullanılmakta olan bu tür ürünler artık bir kurumdaki tüm veri entegrasyon amaçları için de kullanılıyor ve veri entegrasyonu konusunda uzmanlaşmış olan veri ambarı uzmanları ise artık kurumların veri entegrasyon ortamlarının da oluşmasında önemli roller oynamakta. Oracle Data Integrator heterojen ortamların batch, real time, event oriented, message oriented, service oriented veri entegrasyonu için tekleştirilmiş bir arayüz ile yeni bir yaklaşım getirmekte ve entegrasyon süreçlerinin geliştirilmesi için gereken eforu projenin %60-%80 lerinden %30-%40 larına düşürebilmektedir. ODI’ın öne çıkan özelliklerini aşağıdaki başlıklarda inceleyelim: - ETL değil ELT - Knowledge moduller (şablonları) - Her aşamada veri çevrimi (kaynak, hedef ve veri işleme alanlarında) - Changed Data Capture (Değişen verinin bulunması) - Master Data Management - Servis Odaklı Mimari (SOA ) - Java mimarisi – Tüm platformlar için tek uygulama - Erişebilirlik - Öğrenme hızı ETL Değil ELT Bu tür ürünlerin tarihçesine baktığımızda 3 ana aşamayı görüyoruz. 1- Veri taşınması ve çevrimi için kod üreten ürünler. Bunlar platformalara göre Cobol, C kodları üreten uygulamalardı. 2- Kendi server’ında veri işlemeyi yapan ürünler. 3- Veri tabanlarını kullanıp veri işleyen ürünler. ODI üçüncü nesil bir ürün, veri işleme işini bu konuda zaten büyük yatırımlar yapan veri tablarına bırakmakta ve kendisi veri tabanlarının en güçlü yanlarını kullanarak verinin çevrimini sağlamakta. Diğer birçok ürün piyasaya çıktığında veri tabanlarının SQL lerinde CASE komutu yoktu, böyle düşününce veriyi işleyecek ayrı bir server fikri anlamlıydı. Oysa günümüzde veri tabanlarına baktığımızda (ör: Oracle 10g, Teradata, DB2, SQL Server 2005, Sybase IQ ) veri işleme anlamında çok güçlüler. Kurumlar veri tabanlarına ciddi bir yatırımı halihazırda yapmış bulunuyorlar. Bu gücü iş zekası ortamlarının oluşturulması için gereken veri işleme aşamasında neden kullanmasınlar? ODI kaynak sistemlerden veriyi toparlayıp tasarıma göre staging veya hedef veri kaynağında birleştirip konsolide ediyor ve gereken çevrimi veri tabanı içerisinde yapıp hedefe yüklüyor. Kaynak ve hedef veri kaynaklarının en güçlü yanlarını kullanarak çevrimi yapabiliyor. Yapılan çevrimlerin %90 ı SQL’ler ile yapılabiliyor. ELT kelimesinden de anlaşılacağı üzere önce veri kaynaktan çıkarılıyor (Extract) sonra hedef veya staginge yükleniyor (Load) ve çevrim yapılıyor (Transform). ELT yaklaşımında kaynak ile hedef arasında herhangi bir server olmadığından verinin network üzerinden yolculuğu da kısalmış oluyor. ETL ürünlerindeki gibi ayrı bir server’ın bakımı ve kurulumu gibi yüklerde ortadan kalkmış oluyor. Veri tabanları üzerinde çevrim yapmaktan bahsediyorsak bunun SQL’ler ile yapıldığını tahmin etmişsinizdir. Yeni bir scripting öğrenmenize gerek kalmadan tüm veri çevrim işini SQL in gücünü kullanarak yapabiliyorsunuz. ELT yaklaşımında veri genel olarak bulk olarak işleniyor. Veri tabanlarının bu konuda yapmış oldukları performans yatırımlarını düşündüğünüzde performans arttırma konusunda da elimizdeki veri tabanımızın bize sunduğu fırsatları kullanıyor oluyoruz. Kısaca ODI ile veri tabanları üzerinde, ayrı bir scripting öğrenmeden, yüksek performans ile ve geliştirme süresini ciddi miktarda azaltarak veri entegrasyonu yapılabiliyor. Knowledge Modul’ler (Şablonlar) Lego parçacıkları gibi birçok veri işleme modülünüzün olduğunu düşünün, onlarca modül (sort, transform, join vs.) ve karşımızda bir veri entegrasyonu problemi var. Bu modulleri kullanarak bir süreç tasarlayacaksınız. Tasarladınız, ileriki aşamalarda optimizasyonunu yapacaksınız. Optimizasyonu yaptıktan sonra benzer durumdaki belkide yüzlerce akış için aynı işi tekrarlayacaksınız. ODI ın devrimsel farkı bu noktada ortaya çıkmakta, knowledge modul adı verdiğimiz şablonlarınız var ve yukarıda bahsedilen zorluklarla uğraşmanıza gerek kalmıyor. Verinin bir ortamdan başka bir ortama taşınması, değişik ortamlardaki verinin entegre edilmesi, değişen veri ile hedef sistemlerin beslenmesi vs. gibi aşamaların her birisi için çeşitli şablonlar bulunmakta. Knowledge Modul (KM) ler binlerce kişi tarafından test edilmiş, optimum çözümleri size sunmuş oluyor. İş zekası projelerinde veri entegrasyonu için harcanan zamanın çoğu ETL için harcanıyor demiştik. ETL süreci içerisinde de en fazla efor ise karşımıza çıkan problemler için geliştirmek zorunda olduğumuz veri akışlarının tasarımı. ODI birçok değişik durum için bu tür problemlerin çözümünü de beraberinde sunmasıyla hayatımızı kolaylaştırmaktadır. Her Aşamada Veri Çevrimi Verinin çevrimi çoğunlukla SQL’ler ile yapılıyor demiştik; kaynak, hedef ve staging veri kaynaklarımızın olduğunu düşünürsek çevrimin nerede yapılacağı ihtiyacımıza ve zorunluluklarımıza göre ODI içerisinde tasarlanabiliyor. Basit bir örnekle verecek olursak: kaynak sistemde text bir bilgi var ve uzunluğu 100 karakter, hedef ise 80 karakter, uzunluğu 100 den 80’e indirirken SUBSTR komutunu 2 nokta çalıştırabiliriz. - Kaynaktan veriyi çekerken - Kaynak sistemdiki bilgiyi staging’e aynı uzunlukla taşıyıp konsolide ederken - Hedef veri kaynağına yüklerken çalıştırabiliriz Bu esnekliğin bize kazandırdıklarını da şöyle özetleyebiliriz: - Veri işleme yükünün veri tabanları arasında istenen şekilde dağıtılması - Network trafiğinin azaltılması - Her veri tabanının güçlü yanını kullanabilme Changed Data Capture (Değişen Verinin İşlenmesi) Günlük olarak yükleme yapılan bir veri ambarı düşündüğümüzde kaynak sistemlerden değişen verinin alınması zorunluluğu ortaya çıkmktadır. ODI içerisinde değişen verinin veri tabanı loglarından okunarak veya triggerlar ile bulunabilmesi için çeşitli knowledge moduller de bulunmaktadır. Örneğin kaynak sistemi Oracle olan bir kurumda operasyonel sistem tablolarından değişen verinin sisteme en az yük getirecek şekilde bulunabilmesi basit bir şekilde mümkün olmaktadır. Değişen verinin veya tüm verinin işlenmesi için iki farklı akışın oluşturulması da gerekmemektedir, sadece bir check box ın işaretlenmesi ile akışın değişen veriyle çalışmasının sağlanması mümkün olmaktadır. Master Data Management Bugüne kadar kurumda bulunan hiçbir operasyonel sistemin sorumluluğu müşteri, ürün vs. verisinin tekliğini, doğruluğunu ve bütünlüğünü gözetmek değildi. Master Data’yı ise bu sorumluluğu alan sistem olarak düşünebiliriz. ODI değişik ortamlarda bulunan master verinin Master Data üzerinde konsolide edilmesi ve diğer tüm sistemlerle paylaşılması konusunda organizasyonlara yardımcı olabilmektedir. Veri seviyesinde yapılan bu entegrasyon aynı zamanda Servis Odaklı Mimari geçişlerinde de servislerin tanımlama zorluklarını da basitleştirmiş olmaktadır. Servis Odaklı Mimari ODI ile oluşturulan veri çevrimin ve verinin kendisi web service’ler ile dış kullanımlara açılabilmektedir. Veri çevrimi için dış ortamlarda bulunan web service leri de ODI içerisinden kullanılabilmektedir. Bu olanaklar ile verinin ve veri çevrim süreçlerinin kurumların SOA altyapıları ile entegrasyonu mümkün olabilmektedir. Java Mimarisi ODI tamamı ile java ile geliştirilmiş ve dolayısıyla ortam bağımlılığı yoktur. Aynı kodun windows, linux ve unix ortamlarında çalışabiliyor olması uygulamanın geliştirme maliyetinide düşürdüğünden kurumlara maliyet olarak avantaj sağlayacağı da düşünülebilir. Erişebilirlik ODI tüm JDBC,ODBC desteği olan populer veri tabanlarını ayrı bir connectore ihtiyaç duymadan kaynak veya hedef olarak kullanabilmektedir. İlişkisel veri tabanları yanında çok boyutlu veri tabanları (Essbase), text dosyalar, xml, JMS tabanlı veri kaynaklarını da kullanabilmektedir. Öğrenme Hızı Son olarak ODI ı öğrenmek için harcayacağımız efordan bahsedelim; SQL bilgisi olan bir uygulamacı 2 günlük bir eğitim sonunda ELT işleri tasarlayabiliyor duruma gelebiliyor. Bazı durumlarda uygulamacıların uzun zamanlarını alan hata mesajlarının anlaşılması da önemli bir konu. Veri ile uğraşan her uygulamacının SQL bildiği varsayılabilir ve ODI ın hata mesajları SQL hataları şeklinde kullanıcılara sunuluyor. Bu fark Hataların anlaşılması aşamasında ciddi bir kolaylık sağlayabiliyor. Knowledge Moduller sayesinde değişik uygulamacıların geliştirdikleri uygulamaların standartlaştırması kaygısı ortadan kaybolmaktadır. Her kullanıcının geliştirmesi gereken onlarca adım zaten ODI tarafından KM ile hazır sunulmaktadır. Uygulamacılar verinin akışı ile ilgili herhangi bir tasarım yapmamakta sadece veri eşleştirilmesi (mapping) yapmaktadırlar. Sonuç Yukarıda öne çıkan özellikleri anlatılan ODI ürünü içerisinde aynı zamanda metadata yönetimi, scheduling, process flow tasarımı, data quality firewall gibi birçok özellikleri de mevcuttur. Özet olarak söyleyecek olursak; veri tabanlarını en iyi şekilde kullanıp, basit ve yüksek performansta veri entegrasyonu yapabileceğimiz bir ürün ODI. Veri ambarı ve veri entegrasyonu projelerinde yeni bir yaklaşımla benzer geleneksel ürünlerin bir adım önüne çıkmaktadır. |
Kaynak
