16 Ekim 2014 Perşembe

Hadoop Konfigürasyon Ayarları

Hadoop da konfigürasyonlar Configuration sınıfı üzerinden yönetilir. Konfigürasyonlar sisteme xml dosyaları şeklinde import edilebilir. Bunun için farklı yöntemler mevcut.

  • Bu dosyaları kendimiz ayrıştırabileceğimiz gibi GenericOptionsParse sınıfı ile de ayrıştırma işlemi yapılabilir.
  • xml dosyalarının ayrıştırılması ve job ların başlatılması gibi işlemleri soyutlamak için Tool ve ToolRunner sınıfları bulunmakta. Bu sınıfları kullanarak kodlama yapıldığında konfigürasyon dosyalarıdaki parametreler otomatik olarak yüklenmekte ve job'lar çalıştırılmaktadır.
  • Birden çok xml dosyası konfigürasyon ayarları için kodsal olarak eklenebilmektedir: 

    • Configuration.addDefaultResource("hdfs-default.xml");
    • Configuration.addDefaultResource("hdfs-site.xml");
    • Configuration.addDefaultResource("mapred-default.xml");
    • Configuration.addDefaultResource("mapred-site.xml");

  • Konfigürasyon dosyaları job çalıştırılırken komut satırından da eklenebilmektedir:
    • -conf filename
  • Konfigürasyon dosyalarında aynı parametreler var ise en son yüklenen dosyadaki parametre diğerlerini ezmektedir.


  • Bir paremetrenin hiç bir zaman başka değerler ile eilmemesini istiyor isek bu parametrede <final>true</final> özelliği eklenmelidir.
  • Konfigürasyon parametreleri jon çalıştırılırken komut satırından da verilebilmektedir. Bu şekilde ayarlanan parametrelerin önceden aynı isimde tanımlanmış olan değerlere göre önceliği vardır:
    • HADOOP_OPTS="-Dmapred.reduce.tasks=10"

13 Ekim 2014 Pazartesi

Hadoop - Yedek Verilerini (Replica) Neye Göre Konumlandırılıyor?

Hadoop dosya sistemlerinden HDFS de bir veri oluşturulduğunda, bu verinin istenilen adette yedeği altyapı tarafından oluşturulmakta. Yedek sayısı varsayılan olarak 3 adet. Bu değiştirilebilen bir değer.
Peki HDFS üzerindeki verileri yedeklenirken, hangi verinin hangi sunucularda yedekleneceği neye göre belirleniyor.

Burada bir kaç faktör var. Bunlardan en önemlisi bant genişliği. Bant genişliği göz önünde bulundurulduğunda verinin tüm yedeklerini aynı düğümde tutmak yada aynı rack üzerinde tutmak bandwith bakımından kazanç sağlayacaktır. Ancak burada oluşacak bir arıza veri kaybına neden olacaktır. Bu nedenle bu yöntem tercih edilmemekte.

Hadoop verilerin yedeklerini dağıtırken: ilk yedeği istemcinin çalıştığı düğüm üzerinde tutumakta. Eğer istemci hadoop kümesi dışında çalışıyor ise, ilk düğümü çok dolu yada çok meşgul olamayan düğümler arasından rastgele seçmekte. İkinci yedek ise, birinci yedeğin bulunduğu rack haricinden  rack'ler içinden rastgele seçilerek yerleştirilir. Üçüncü yedek ise ikinci ile aynı rack üzerinde, ikinci yedeğin bulunduğu düğümden farklı rastgele bir düğüme yerleştirilir. Hadoop sisteminin ağ topolojisini nasıl öğrendiği  Hadoop - Ağ Topolojisi Tanımlama yazısında detaylandırılmıştır.

Hadoop 1.x den itibaren bu strateji kullanıcı tarafından değiştirilebilir şekildedir.

10 Ekim 2014 Cuma

Hadoop Altyapısının Desteklediği Dosya Sistemleri

  • Local 
  • HDFS
    • Hadoop Distributed Filesystem
  • HFTP
    • HDFS 'e Http üzerinden sadece okuma amaçlı erişim sağlayan dosya sistemi
  • HSFTP
    • HDFS 'e Https üzerinden sadece okuma amaçlı erişim sağlayan dosya sistemi
  • WebHDFS
    • HDFS 'e Http üzerinden okuma ve yazma amaçlı güvenli erişim sağlayan dosya sistemi
  • HAR
  • KFS (Cloud-Store)
    • C++ ile yazılmış HDFS yada GFS benzeri dağıtık dosya sistemi
  • FTP
  • S3 (native)
    • Amazon S3 üzerinde bir dosya sistemi
  • S3(block based)
    • Amazon s3 üzerinde, dosyaları bloklarda saklayan dosya sistemi
  • Distributed RAID
    • HDFS'in RAID versiyonu
  • View
    • İstemci tarafında oluşturulan bir mount tablosudur

    Hadoop Namespace Image, Edit Log, Secondary Namenode

    Hadoop dosyalarını HDFS de saklamakta. HDFS de hangi dosyanın nerde tutulduğunu , replikalarının nerde olduğunu ise kalıcı olarak yerel diskde saklamakta. Bu bilgileri "namespace image" ve "edit log" dosyalarında tutmakta.

    Namenode gittiğinde hdfs'in metadası niteliğindeki bu bilgilerde kaybolacağından hdfs'i ayağa kaldırmak mümkün değildir. Bunu engellemek için hadoop üzerinde belirli ayarlamalar yapılarak bu bilgilerin yedeklenmesi amacıyla kalıcı başka bir diske de senkron olarak yazılması sağlanabilmektedir.

    Secondary namenode ise bir namenode değildir. Namenode da tutulan "namespace image" ve "edit log" dosyalarının belirli periyodlar ile merge edilmesini sağlamaktadır. Böylelikle "edit log" dosyalarının şişmesi engellenmiş olur.

    Secondary namenode farklı bir fiziksel makinada çalıştırılmalıdır. Ve en az namenode kadar belleğe sahip ve CPU gücü yüksek bir makina olmalıdır. Kendi içinde merge işleminden sonra "namespace image" in kopyasını tutmaktadır. Namenode çökerse bu yedekden de dönülebilir ancak veri kaybı yaşanması olasıdır.

    Namenode da bulunan verilerin bir NFS e senkron olarak kopyalanmasını sağlayarak, namenode çöktüğünde bu veriler secondary namenode 'a kopyalanıp burada sistemin ayağa kaldırılması veri kaybı yaşanmadan sistemin tekrar çalışmasını sağlayacaktır.

    Hadoop - Jop Map Sayısı

    Hadoop üzerinde bir job başlatıldığında kaç adet map task oluşturulacağı o job da kullanılacak data nın büyüklüğü ile orantılıdır. Hadoop veriyi HDFS'e atarken splitler şeklinde parçalayarak atmaktadır. Bir job başlatıldığında kullanacağı veri kaç splitten oluşuyor ise o kadar map taski oluşturulmakta. Bu işlem Hadoop altyapısının yönetiminde gerçekleşiyor. Programsal olarak map sayısınına müdahale edilememekte.

    Hadoop veriyi split olarak parçalarken 64 MB lık bölümler oluşturmakta. Ancak veri küçük dosyalardan oluşuyor ise 64 MB dan küçük splitler oluşacaktır. Bu durumda bir job çalıştırıldığında daha fazla map task açılmış olacaktır. Bu işlem de zamandan kayıba neden olacaktır.

    Bunu bir örnek ile açıklayacak olur isek:

    1. Durum

    2 adet 128 MB dosyamız olsun , bu dosyaları HDFS e attığımızda 4 adet split oluşacaktır.
    Tüm veriyi kullanan bir job çalıştırdığımızda 4 adet map task oluşacaktır.

    2. Durum

    16 adet 16 MB dosyamız olsun, bu dosyaları HDFS e attığımızda her bir dosya 64 MB dan küçük olduğundan hepsi için bir split yapılarak  16 adet split oluşacaktır.
    Tüm veriyi kullanan bir job çalıştırdığımızda 16 adet map task oluşacaktır.

    NOT: Bir job da çalışacak reduce sayısı değiştirilebilmektedir.

    23 Ağustos 2014 Cumartesi

    RFC (Request For Comment)

    İnternette kullanılan protokoller ile ilgili standartları tanımlayan dokümanlar dizisidir. Bütün internet standartları RFC dökümanları olarak tanımlıdır. Her döküman bir RFC numarasına sahiptir.

    21 Ağustos 2014 Perşembe

    Blade Sunucular ve Avantajları

    Blade Şasiler ve Blade Sunucular (Blade Enclosures & Blade Servers) kısaca anlatmak gerekir ise, üreticilerin çeşitli isimlerle adlandırdığı (Blade System c-Class, BladeCenter E, H gibi), sunucuların toplam ve ilk sahip olma maliyetini düşürmek üzere tasarlanmış, mevcut veya yeni temin edilecek blade sunucu donanımları üzerine kurulan ve buna ek olarak yazılım, hizmet, ağ ve sanallaştırma araçlarına sahip entegre ortamlardır.

    En yüksek verim ve blade miamrinin gerçek avantajları sanallaştırma altyapısına sahip kurum ve kuruluşlarda gözlenmektedir.

    Blade Sistemler, erişebildikleri yüksek donanım yoğunluğu, az yer kaplamaları, anında fonksiyon değiştirme, tüm bir şasinin kapatılmasına gerek kalmadan donanıma müdahale edebilme, tam yedekli güç kaynakları, fanlar, ağ arabirimleri ve veriyolları gibi avantajlar sunmakla birlikte sanallaştırma altyapısıyla bütünleşik esnek işlemgücü ve bellek havuzu gibi avantajlara sahiptir.

    Blade Sistemlerin kısaca avantajları;

    Hızlı ve kolay kurulum
    İlk sahip olma maliyetinin aynı işlemci ve belleğe sahip rack tipi sunuculara göre düşük olması.
    Operasyonel maliyetlerin rack tipi sunuculara nazaran daha düşük olması,
    Rack/Tower form faktör sunuculara oranla daha az yer kaplaması,
    Sanallaştırma ve konsolidasyon seçenekleri için tercih edilen platform olması ve entegrasyon kolaylığı,
    Sağladığı yoğun sunucu alanı ve düzenlenmiş blade şasi sayesinde esneklik sağlanması ve kablo karmaşasının önlemesi
    İş sürekliliği konusunda tam yedekli bileşenler ve esnek yapı sayesinde rakipsiz olması
    Güç tüketimi ve soğutma maliyetinin rack/tower form faktör sunuculara göre daha düşük olması

    Blade Sistemlerin kısaca dezavantajları;

    Kısıtlı disk alanı
    Rack tipi sunuculara ait kartların kullanılamaması, kısıtlı pci kart desteği

    Kaynak:

    http://www.4s.com.tr/tr/blog/Lists/Postalar/Post.aspx?ID=20