3. BÜYÜK VERİ
Toplanan ve saklanan verinin boyutu artmaktadır.
Bilgisayar ve internet altyapısındaki gelişmeler
Online hizmetler/ürünler
Mobil uygulamalar
Sosyal medya
…
Facebook, 2012 yılında 100 PB veriyi saklamaktaydı.
Yine aynı yıl her gün 0.5 PB veri eklendiğini açıkladılar.
4. BÜYÜK VERİ
Son 10 yılda, bu büyüklükte veriyi işlemeye ve analiz etmeye yarayan
açık kaynak kodlu araçlar ortaya çıktı
Google, Facebook, Linkedin vs. bu araçları kullanıyor ve geliştiriyor.
Türkiye’de kullanımı kısıtlıdır, ama büyük bir potansiyel
bulunmaktadır.
Düşük maliyetlerle sağlanan analizler, şirketlerin kullanmak isteyeceği
bilgiler sunmaktadır.
5. BÜYÜK VERİ
Genel bir senaryo üzerinden büyük veri teknolojilerini belirli bir
tasarım dahilinde nasıl kullanılabileceğini göstermek yararlı olacaktır.
Bu senaryo başka durumlara uyarlanıp kullanılabilir.
Önce kullanılacak teknolojilerinden bahsedelim…
6. BÜYÜK VERİ TEKNOLOJİLERİ
Büyük veri ekosistemi birçok araçtan oluşmaktadır.
Araçlar/Teknolojiler:
Apache Hadoop, büyük verinin birden fazla düşük maliyetli
bilgisayarda paralel olarak analiz edilmesini sağlayan bir araçtır.
2013 yılında, 1.42 terabayt boyutundaki veri ortalama 60 saniyede sıralanmıştır.
Hadoop tarafından analiz edilecek veri HDFS(Hadoop File System)
üzerinde tutulmaktadır.
7. BÜYÜK VERİ TEKNOLOJİLERİ
Apache Pig ve Apache Hive, SQL benzeri betikler yazılmasını ve bunun
Hadoop işlerine çevrilmesini sağlayan araçlardır.
Apache Oozie, tanımlanan Hadoop işlerinin (örneğin Pig/Hive
betikleri) bir akış içerisinde belirlenen bir sırada ve belirlenen
aralıklarda çalıştırılmasını sağlayan bir araçtır.
MongoDB büyük verilerin sorgulanabilir bir tarzda saklandığı nosql
veritabanıdır.
8. BÜYÜK VERİ SENARYOSU
Bahsedilen teknolojiler, belirli bir tasarım dahilinde beraber
kullanıldığında
bir veri akış modeli oluşturulabilir
bu akış belirlenen aralıklarla çalıştırılabilir
ortaya çıkan bilgi anlamlı bir şekilde arayüz birimlerinde gösterilebilir.
Birçok senaryo, buna benzer bir altyapıya ihtiyaç duymaktadır.
Örnek senaryomuzu detaylandıralım…
9. BÜYÜK VERİ SENARYOSU
Şirket A, son kullanıcılara hitap eden bir e-ticaret sitesi işletmektedir.
Kullanıcılar site dahilinde eşsiz olarak tanımlanabilmekte ve takip
edilmektedir.
Her sayfa ziyareti ve her ürün satışı, web sunucularında olay kaydı
olarak loglanmaktadır
Log dosyalarında her olayın/satırın belirli bir formatı vardır. Ziyaret
logları ve satış logları aynı formata sahiptir:
Kullanıcı Ülke Zaman Sayfa Ürün Marka Kategori Olay Tipi
10. BÜYÜK VERİ SENARYOSU
Bu loglar, belirli aralıklarla web sunucularından transfer edilip HDFS
üzerinde depolanmaktadır.
Bir günün bütün ziyaret logları, o günün ismini taşıyan klasöre
gitmektedir:
/views/2014_10_01
Bir günün bütün satış logları, o günün ismini taşıyan klasöre
gitmektedir:
/sales/2014_10_01
11. BÜYÜK VERİ SENARYOSU
Şirket A, sitesinde bulunan ürünlerin
günlük olarak hangi ülkelerde kaç defa ziyaret edildiğini,
kaç tekil kullanıcı tarafından görüntülendiğini,
kaç defa satış yapıldığını raporlamak istemektedir.
Ürün Ülke Gösterim Tekil
Kullanıcı
Satış
ürün1 Türkiye 25000 5000 100
12. SİSTEM TASARIMI
Pig/Hive betikleri yardımıyla veri dönüşümü ve işlemler
tanımlanacaktır.
Yazılan betikler Hadoop üzerinde çalıştırılacaktır.
Ortaya çıkan analiz sonucu MongoDB’ye aktarılmak üzere bir yedek
dosyasına yazılacaktır.
Bu yedek dosyası MongoDB veritabanına yüklenecektir.
Oozie yardımıyla bu veri akışı tanımlanacak ve Pig/Hive betikleri bu
akışta bir adıma karşılık gelecektir.
Bu süreç her gün tekrarlanacak ve var olan veriler yenileri tarafından
değiştirilecektir.
13.
14. APACHE HADOOP
Kullanım Amacı
Hadoop, analiz için gereken veri işleme görevlerini yerine getirecektir
Kullanımı
Hadoop birden fazla bilgisayar üzerinde küme(cluster) yapısında
çalışmalıdır.
Bu senaryo için düzgün çalışan ve yeterli disk alanına sahip bir küme
gerekli ve yeterlidir.
15. APACHE HADOOP
HDFS Kullanımı
Web uygulamasından gelen loglar, tarihi belirten klasörler altında
tutulmaktadır
Herhangi bir veri kaybını önlemek için birden fazla bilgisayar üzerinde
replike edilmektedir/çoklanmaktadır.
HDFS replikasyon sistemi veri kaybına karşı önlem alır.
16. APACHE PIG/HIVE
Kullanım Amacı
Apache Pig ve Hive Map-Reduce işlerinin daha üst seviyede
yazılmasına olanak sağlar.
Pig’in betik dili olan Pig Latin kendine has yazım kurallarına sahiptir.
Hive betik dili olan HiveQL ile yazılan sorgular, SQL yazım kurallarını
belli dereceye kadar takip eder.
Pig ve Hive, yazılan bu betikleri belirli optimizasyon adımlarından
geçirdikten sonra map-reduce işlerine çevirir.
17. APACHE PIG/HIVE
Kullanımı
Bir ürünün görüntülenme ve satış bilgilerini çıkaran Pig betiğinin bir kısmı aşağıda verilmiştir.
AllViews = LOAD ‘/views/2014_10_01’ USING PigStorage() AS
{
user: chararray, country: chararray, date: datetime, page: chararray, product: chararray, brand:
chararray, category:chararray, event_type:chararray
}
ProductViewsPerCountry = GROUP AllViews BY (product, country);
ProductViewsAggregations = FOREACH ProductViewsPerCountry {
unique_users = AllViews.user;
GENERATE group.$0 as product, group.$1 as country, COUNT(AllViews) as view_count:long, COUNT(unique_users) as unique_user_count:long;
}
…
STORE DailyResult INTO ‘/result/daily/’ USING PigStorage();
18. APACHE PIG/HIVE
Yukarıdaki betikte HDFS üzerindeki bir dizin girdi olarak LOAD
fonksiyonuna verilmektedir.
Bu dizin altındaki bütün dosyalar okunarak, her satır belirli bir
ayraca(varsayılan olarak tab karakteri) göre parçalara ayrılır ve bu
parçalar verilen değişken-tip ikilileriyle sırayla eşlenir.
Daha sonra SQL benzeri bir gruplama işlemi gerçekleşir.
Tüm işlemlerden sonra, değerler hesaplanıp STORE fonksiyonuyla
HDFS üzerindeki bir dizine sonuçlar yazılır.
Bu Pig betiğinin tam hali, logları okuduktan sonra istenilen formatta
bilgiyi üretecektir:
19. APACHE PIG/HIVE
Neden Pig Tercih Edildi?
Pig dili karmaşık akışlarda geliştiriciye daha fazla esneklik sağlar ve
gerekli yerlerde müdahale imkânı verir.
Hive betik dili olan HiveQL de benzer yeteneklere sahip olmakla
birlikte SQL tarzı cümleler akışı net bir şekilde göstermez ve belirli
işlem aşamalarında müdahale imkânı sağlamaz.
Fakat Pig Latin ve HiveQL dillerinin ikisi de geliştiriciye temelde
benzer yetenekler sunar ve yapılmak istenen bir analiz iki dilden
herhangi biri seçilerek yapılabilir.
20. MONGODB
Kullanım Amacı
Hadoop tarafından üretilen sonuçların boyutu, istenen detay
seviyesine göre farklılıklar gösterebilir.
Ayrıca elde edilen analizlerin toplanma ve biriktirilme yöntemleri de
veri boyutunu şekillendirir.
Verinin boyutu büyümeye meyilliyse, veriyi nosql veritabanlarında
tutmak daha mantıklı olur.
MongoDB doküman bazlı bir veritabanıdır. Büyük miktardaki veriye
hızlı bir şekilde erişmeye olanak sağlar.
21. MONGODB
Kullanımı
Hadoop ile işlenen veriyi MongoDB veritabanına aktarmak için çeşitli
yöntemler mevcuttur.
Veriler direk olarak Pig betiği içerisinden MongoDB veritabanına
eklenebilir/güncellenebilir
Veya MongoDB yedek dosyası(bson dosyası) oluşturulabilir.
Bu senaryo dâhilinde yedek dosya oluşturma yöntemi seçilmiştir
Bu dosya daha sonra ayrı bir shell betiği aracılığıyla MongoDB
veritabanına yüklenecektir.
22. APACHE OOZIE İLE AKIŞ YÖNETİMİ
Kullanım Amacı
Analiz adımlarını sırasıyla çalıştırmak için, Apache Oozie
kullanılacaktır.
İş akışları oluşturulmasını sağlar.
Bu akışta her adım Pig/Hive/Map-Reduce/Shell gibi aksiyonları
içerebilir.
Bir diğer önemli özellik, tanımlanan bu akışların belirli aralıklarla
çalıştırılmasıdır.
23. APACHE OOZIE İLE AKIŞ YÖNETİMİ
Kullanımı
Oozie akışları XML
dokümanları şeklinde
hazırlanır.
Günlük analiz için 3 adımdan
oluşan akış dokümanı yandaki
gibidir:
Bu Oozie terminolojisinde
workflow application olarak
geçer.
Oozie üzerinde çalıştırıldığında
sadece bir kere çalışır.
<workflow-app xmlns="uri:oozie:workflow:0.2" name="analysis workflow">
<start to="dailyAnalysis"/>
<action name="dailyAnalysis">
<pig>...</pig>
<ok to="createMongoDBBackup"/>
<error to="fail"/>
</action>
<action name="createMongoDBBackup">
<pig>...</pig>
<ok to="restoreMongoDB"/>
<error to="fail"/>
</action>
<action name='restoreMongoDB'>
<shell xmlns="uri:oozie:shell-action:0.1">...</shell>
<ok to="end" />
<error to="fail" />
</action>
<kill name="fail">
<message>Daily analysis failed!</message>
</kill>
<end name="end"/>
</workflow>
24. APACHE OOZIE İLE AKIŞ YÖNETİMİ
Her gün çalışması için koordinatör
uygulaması(coordinator application)
tanımlanması gerekir.
Koordinatör uygulaması bir akış
uygulaması(workflow application)
içerir ve onu her gün belirtilen saatte
çalıştırır.
<coordinator-app name="daily analysis coordinator"
frequency="${coord:days(1)}"
start="${jobStart}" end="${jobEnd}"
timezone="UTC"
xmlns="uri:oozie:coordinator:0.4">
<action>
<workflow>
<app-path>${workflowRoot}/workflow.xml</app-path>
...
</workflow>
</action>
</coordinator-app>
25. SONUÇ
Öncelikle elimizdeki veriyi ve üzerinde gerçekleştirilmek istenen
analizi belirledik.
Verinin büyüklüğü dolayısıyla büyük veri teknolojilerini kullanmaya
karar verdik.
Yukarıda sıraladığımız teknolojileri kullanarak bir akış içerisinde
analiz adımlarımızı oluşturduk.
Ve çıkan sonucu MongoDB veritabanında depoladık.
26. GELİŞTİRME OLANAKLARI
Bu akış, ek özelliklerle daha yararlı hale getirilebilir.
Günlük olarak yapılan analizler, eski günlerle birleştirilip başlangıçtan
şimdiye kadar bir ürünün performansı ortaya konabilir.
Haftalık veya aylık olarak çalışan Oozie akışları tanımlanarak çeşitli
zaman pencerelerinde bir ürünün performansı izlenebilir