Big Data

Big Data Big Data Konsepti ve Kullanılan Araçlar Ferhat SARIKAYA  İçindekiler Big Data Nedir? 2 Nereden Çıktı Bu Big Data? 2 Big Data’nın 4 V’si 4 Big Data Araçları 5 Hadoop 5 Peki, Hadoop Verileri Neden Dağıtık İşliyor? 5 Hadoop Verilerimizi Nasıl İşliyor? 6 Ambari 12 Flume 13 Kafka 14 Producer Mimarisi 15 Consumer Mimarisi 15 Topic Mimarisi 16 Broker Mimarisi 16 ZooKeeper 17 Hive 17 Pig 18 Pig Latin 18 Pig Engine 18 Tez 19 Spark 20 Oozie 21 Sqoop 22 HDFS Dosya Formatları 22 Sequence File 22 Avro 23 Parquet 23 ORC(Optimized Row Columnar) 23 RC File 24 Peki hangisini kullanmalıyım? 24  Big Data Nedir? Big Data deyince akıllara verilerin büyüklüğü geliyor. Doğrusu ben de ilk duyduğumda aklıma büyüyen veri boyutları ve buna karşı çaresiz kalmaya başlayan ilişkisel veritabanlarının durumu gelmişti ve buna bir çare olarak üretildiğini düşünmüştüm. Nispeten NoSQL Database kavramı bunun için oluşturulmuş olsa da aslında Big Data dediğimiz konseptin sadece bir parçasıdır, kendisi değil. Konu uzmanlarının hem fikir olduğu ve konsepte hakim olunca benim de katıldığım şey aslında konseptin adının yanlış koyulduğu. Çünkü mesele verilerin boyutları değil, çeşitliliğidir. Bu çeşitli verilerin ise önemli bir kısmı kayıt altında değildir. Elbette veri boyutları da büyük; ama Big Data konseptinin aslında hedeflediği şey size verilerinizden anlam çıkarmanızı sağlayabilecek bir alt yapı hazırlamaktır. Veriden anlam çıkarmak şüphesiz yine insanlara düşer yani Data Scientist dediğimiz Veri Bilimcilerine; ama yeterli teknolojik alt yapı yoksa şüphesiz veri bilimcinin de tahminlerini isabetli yapması mümkün olmaz. Big Data aslında nedir dediğimizde, cevap olarak kayıtlı ve kayıt altına alınmamış verilerin bir araya getirilerek anlamlı bir sonuç çıkmasını sağlayan eko sistemdir diyebiliriz. Kayıt altına alınmamış verilerimizden hemen her şeyi aklımıza getirebiliriz. Örneğin eğer bir saat satıcısı iseniz sadece sattığınız saatler, bunların veritabanınıza girişi yeterli değil, bunların sevki, tamire geldiklerinde kayıt altına alınması, gps entegrasyonu varsa bulunduğu konum bilgisinin sürekli kayıt altına alınması, belirli özellikleri varsa bunların hangi sıklıkla kullanıldığı, en çok işe yarayan uygulamaların tespiti, bunların yaygın kullanımı, eksiklerinin tespiti gibi birçok konuda size öngörü kazandıracak, iyileşme sağlayacak, müşteri davranışlarını görebileceğiniz bir yapı size rakiplerinize göre büyük üstünlükler sağlayacaktır. Bu örnekleri çoğaltabiliriz, zaten internet ortamını tararsanız böyle örnekler bulabilirsiniz. Google, Big Data konseptinin başlatıcısı oldu. Büyüyen veri boyutlarına çare bulmanın yanında makine öğrenmesi, diller arası tercüme gibi birçok alanda gösterdiği faaliyetler Big Data alt yapısını oluşturmasına neden oldu. Böylece önce Hadoop ve MapReduce’un gelişmesine, daha sonra da bu eko sisteme yeni ürünlerin katılmasına yol açtı. Şu anda olağanca hızıyla dünya Big Data konusunda çalışmalar yapmakta, biz ise her zamanki gibi epey geriden takip ediyoruz. Nereden Çıktı Bu Big Data? Başlangıç olarak klasik hikayeyi anlatmayacağım, zaten bunu okuyabileceğiniz çok fazla yer var. Ben temel mantığına girerek Big Data’ya giden yolu kısaca anlatıyor olacağım. Bilgisayar donanımlarının pahalı olduğu dönemlerde yazılım karmaşıklığı düşük düzeydeydi. Donanım maliyetleri düştükçe yazılım karmaşıklığı arttı. Çünkü işletmeler için ulaşılabilir duruma geldi ve hatta evimize kadar girdi. Böyle olunca hemen her akıllı işletme yapılan işlemleri otomatize edecek, daha da kolaylaştıracak olan yazılımların geliştirilmesine başladı. Süreç biraz sancıları getirse de zamanla yazılım mühendisliğinin de gelişmesini sağladı. Bu gelişim sürecinde elbette tüm verileri kayıt altına almak mümkün olmuyor aslında. Özellikle veritabanlarının hayatımıza girmesi sonucunda nispeten yapısal verileri saklamak mümkün oluyor; ama belli limitler dahilinde. Tabii bu verileri işleyecek, istediğiniz sonuçları döndürecek, analiz yapacak yeterli kaynağa sahip bilgisayarlara sahip olmanız gerekiyor ki bu da oldukça yüklü maliyetler demektir. Bu yüklü maliyetlere rağmen yine de belirli limitlerin üzerine çıkmanız mümkün değil. Java ile biraz haşır neşir olanlar dağıtık mimari hakkında bilgi sahibidir. Genelde analiz için yeterli kaynağa tek bir donanımla çözüm bulamıyorsanız java ile dağıtık mimaride çalışarak birden fazla bilgisayarı tek bir amaç için organize edebilme şansına ve yeteneğine sahip oluyordunuz. Dağıtık mimarinin öneminin eskiden yeterli derecede anlaşılmadığını düşünüyorum, en azından ülkemiz için bunun böyle olduğunu söyleyebiliriz. Ben özellikle yapay zeka üzerine çalışmalar tasarlarken dağıtık mimarinin olmazsa olmaz olacağını hesaplıyordum, aksi halde işlemciler gelişmiş olsa da gerçek bir insan gibi düşünebilen bir yazılım tasarlamak için bu karmaşıklığı kaldırbilecek tek bir bilgisayarın olmasının çok mümkün olmadığı, onlarca belki binlerce makinenin tek bir parça gibi çalışmasını sağlamak gerektiği üzerine duruyordum; ama doğrusu tek başına böyle bir işin altına girmek kolay değildi. Günlük hayatta çalışıp para kazanmak zorunda olduğumuz için de ben daha çok emekliliğe planlıyordum yapmak istediğim çalışmaları. Neyse ki Big Data konseptiyle birlikte buna gerek kalmadı. Bildiğiniz hikaye ile Google kendi altyapısındaki analiz, veri işleme, saklama vb. Birçok işlem için kendi sistemini geliştirdi ve hayatımıza Hadoopla birlikte yeni bir geliştirme, analiz ortamı kazandırmış oldu. Big Data konsepti dağıtık mimari üzerine konumlanan bir yapıdır. Özellikle ileride değineceğim gibi yapısal verileri değil, yapısal olmayan verileri de işlemenize ve o bilgilerden de faydalanmanıza olanak tanıyor. Google’ın başarı hikayeleri, teknolojiye verdiği yön sayesinde aslında yeni bir yaklaşım gelişti. Bu yaklaşım sayesinde şirketlerin tek kuruluş maksadı olan kâr marjını artırmak, her bir bireye uygun öneriler yapıp satışı gerçekleştirmek önemliydi. Eskiden televizyon reklamlarının faydasına inanılıyordu. Şüphesiz televizyonda gösterilen reklamlar satış marjlarına ciddi etkiler yaratacaktır. Marka bilinirliğini artırmak konusunda da faydaları vardır; ama bu günümüz için biraz daha farklı bir duruma geldi. Dijital çağ insanlara artık ulaşmanız gereken farklı kanallar sunmaya başladı, örneğin Facebook. Facebook gibi bir mecrada kişinin yaşından ilgi alanına kadar özelleştirilmiş reklam sunabilmenize imkan sağlıyor. Google keza yine aynı. Bir konuda arama yaptığınızda arama konunuzla alakalı reklamlar görebiliyorsunuz, daha da ötesine geçip dolaştığınız siteleri ve bu sitelerde yaptığınız alış veriş alışkanlıklarınızdan haberdar olarak size daha özelleşmiş ve nokta hedef reklamlar gösterebiliyor. Peki bu kadar çok veriyi nasıl işliyor? Nasıl anlık verileri aktarıp onlar sonucunda milyonlarca reklam arasından sizin için uygun reklamları gösterebiliyor? Veya arama kutusuna yazdığınız kelime veya kelime gruplarını yanlış yazdığınızı anlayarak size doğru kelimeyi öneriyor? İşte bu ve bunun gibi daha birçok şeyi yapmak için kullandığım konseptin adı Big Data’dır. Temelde çok yüksek özellikli sunucular kullanabilseniz bile bunun teknik olarak yapacağınız analize yetecek gücü olmayacaktır veya analiz yapabiliyor olsanız bile bunun kısa sürede olması mümkün olmayacaktır. Google’da bundan yola çıkarak donanım maliyetleri düşük onlarca bilgisayarı bir tek küme altında toplayıp verileri ayrıştırarak işlemeyi, analizleri gerçekleştirmeyi gerçekleştirdi. Böylece hem ucuz, hem daha büyük bir güce sahip dev bir veri işleme kompleksine sahip oldu. Onlar sayesinde de Hadoop ve dolayısıyla Big Data konseptine merhaba demiş olduk. Big Data’nın 4 V’si Big Data konseptinin 4 temel kavramı vardır. Bu kavramların içerdiği şekilde bir yapıya sahip veya potansiyeliniz varsa Big Data dünyasına dalmanız gerektiği anlamına geliyor. Aslında bu v’leri sayısı epey artırılıyor; ama aşağıda belirteceğim 4 tane yeterli diye düşünüyorum. Volume: Türkçesi hacim. Şirket olarak yaptığınız işlemleri boyutları büyüdükçe verilerinizin boyutları da büyür. İlişkisel veritabanlarında verilerini saklıyorsanız ve özel bir sürüm yaptırmayacaksanız 30 terebayt gibi bir veri saklamanız mümkündür. Standart şartlarda bu boyutun üzerine çıkmanız mümkün olmuyor. Tabii bu sadece yapısal (Structered) verilerinizin saklanma boyutu. Bunun yanında mailleriniz, form, fatura, irsaliye vb. yapısal olmayan (Unstructered) verileriniz de vardır. Bunlar da değerli bilgiler taşıdıkları için saklanabilmeleri lazım. Veri boyutları büyüdükçe bunları saklanması ve işlenmesi problemleri ile karşı karşıya gelirsiniz. Genelde 100 Terebayt ve üzeri verinin Big Data için uygun olduğu dile getirilse de ben buna katılmıyorum. Çünkü verinin boyutunun yanında önemsemeniz gereken şey verilerinizin işlenmesidir. İlişkisel veritabanları ile çeviremeyeceğiniz kadar bir veri ile boğuşuyorsanız bence yeterli düzeyde büyük hacimli veriniz var demektir ve Big Data’ya merhaba demelisiniz. Variety: Türkçesi çeşitliliktir. Veri çeşitliliğine atıf yapar. Az önceki örneklerimizde verdiğimiz gibi mail, form, fatura, irsaliye vb. Birçok yapısal olmayan veriye sahibiz ve aslında bunlar bizim için değerli bilgiler içeriyor. Bunları yapısal hale getiremediğimiz için analizlerimizde kullanamıyor ve önemli fırsatları görmemiz mümkün olmuyordu. Günümüz dünyasında bir şirketin global olma hedefi varsa kaçınılmaz olarak sosyal medya diye nitelendirilen sosyal network sitelerini takip etmesi, orada hakkında konuşulanları incelemesi, hatta ilerisine gidip rakiplerinin de insanların gözünde nasıl göründüğünü biliyor olması gerekir. Bu ortamlarda insanları yazıp paylaştıkları şeyler yapısal veriler değildir. Bunları almanız, işlemeniz ve anlamlı sonuç elde edebilmeniz için Big Data konseptine ihtiyacınız var. Çeşitliliğin ayrıca yeni bir algoritma kullanmaktan daha önemli olduğu üzerinde durulur. Yapılan araştırmalara göre yeni algoritmalar kullanmak isabetli tahminler yapmak için çok önemli artışlar sağlamıyor; fakat ne kadar çok farklı veriye sahipseniz bunların kullanılması sonucunda daha isabetli tahminler ve analizler yapılabildiği ortaya konmuştur. Velocity: Türkçesi hız. Günümüz karmaşık dünyasında hızla veriler artıyor. Sensörler çoğaldı örneğin, Araçlarımızı düşündüğümüzde artık yoldaki trafik işaretlerini, lastik basıncını, trafik durumu ve daha birçok şeyi sensörlerle takip eder hale geldik. Günümüz araçlarında en az 100 sensör bulunmaktadır. Saniyede binlerce sensör verisinin geldiğini düşündüğünüzde bunu anlık olarak işleyebilecek hızlı yapılara ihtiyacınız bulunuyor. Facebook’u düşünün, günde 30 milyardan fazla içerik paylaşımı yapılıyor. Bu da muazzam bir veri boyutu demektir ki Facebook oldukça hızlı hizmet verebilmekte. Bunun arkasında hiç şüphesiz Big Data konsepti, dağıtık mimari yaklaşımı bulunmaktadır. Aksi halde ilişkisel veritabanı kullanıyor olsaydı bu boyutta içerik paylaşımı yapılan bir sistemi ayakta tutması, milyarlık kullanıcı kitlesine cevap vermesi mümkün olamazdı. Veracity: Türkçesi gerçekliktir. Verileri analiz edip doğru sonuçlara ulaşabilmeniz için verilerin gerçekliği, tutarlılığı önemlidir. Bir analiz işlemi için en önemlisi bu olsa gerek. Müşterilerden aldığınız verilerin doğru olması, doğru bilgi almak, analiz başarınızı, tahminlerinizi lineer şekilde artıracaktır. Bu yüzden elde ettiğimiz verileri doğrulamamız ve uç değerleri temizlememiz gerekir. Bu da bir dizi işlem adımları gerektirir. İlerleyen yazılarımda bunlara değiniyor olacağım. Big Data Araçları Big Data konseptinde kullanılan araçlar oldukça çeşitlidir, hepsini anlatmak imkanı olmadığı için genel itibariyle sık kullanılanlardan bahsedeceğim. Şimdi genel itibari ile aşırı derine inmeden bunları tanıtacağım. Yalnız burada NoSQL dünyasına girmeyeceğim, çünkü onları ayrıca işlemiştik, yeniden aynı şeyleri yazmak anlamlı değil. O zaman haydi başlayalım. Hadoop Big Data dendiğinde akla ilk gelen şeydir Hadoop! Hatta Hadoop = Big Data şeklinde bir bakış açısı vardır. Bu algı esasında yanlıştır, çünkü NoSQL databaseler de bu konsette kullanacağımız araçlardır. Şimdilik bu bahsi uzatmadan asıl konumuz olan Hadoop’u anlatacağım. Hadoop, dağıtık veri işleyebilen, Java ile geliştirilmiş bir framework’tür. Hadoop’un arkasındaki mantığın Google’dan çıktığını daha önce dile getirmiştik. O yüzden temelde eş zamanlı olarak işlenebilen verilerle belirli bir hızın üzerinde işlem yapma gücü kazandırdığını söyleyebiliriz. Elbette Hadoop’u ilişkisel bir veritabanı ile her senaryo için kıyaslamak anlamsızdır, çünkü temelde yapılan işlemler, tutulan veri çeşiti, veriyi depolama ve işleme amaçları tamamen farklılaşabilir. Warehouse sisteminin bir alternatifi olarak tasarlanacak ise mantıklı olabilir; ama bir OLTP ortam kıyaslaması anlamsızdır, zira Matematik’ten de bildiğimiz üzere iki şey arasında bir hesaplama, kıyaslama yapacak isek bunların aynı türde, aynı özelliklerde olması gerekir. Peki, Hadoop Verileri Neden Dağıtık İşliyor? Bir veri işleme sürecinden bahsederken verilerin alınması, alındıktan sonra hesaplama işlemleri gerçekleştirilmesi ve sonra da yazılması sürecinden bahsediyoruz. Dağıtık verilerin işlenmesi ise bu süreci kısaltmak için geliştirilmiş bir yapıdır. Bu kısa tarif muhtemelen yetersiz kalacak, o halde gelin bu kavramların içini ilişkisel veritabanlarında işin nasıl yürüdüğünü anlatarak dolduralım ki aklınızda daha iyi yer etsin. Verilerin alınması aşamasında çeşitli süreçlerden bahsediyoruz aslında. Öncelikle bir web ortamından gelen bilgiler ilişkisel bir veritabanına gönderilirken, veritabanı yönetim sisteminde sizi dispatcher adı verilen bir process karşılar. Sizin için bir session atar ve session bilginiz ile sorgunuzu alarak sizi bir queue’ya sokar, sıranız geldiğinde database engine’e sorgunuzu gönderip, sonucunda bir result set dönmesini bekler ve dönen result set’i size vererek geri gönderir. Elbette bir sonuç dönmesini beklemiyor da olabilirsiniz; ama en azından bir insert, update veya delete yapsanız dahi size commit (işlem gerçekleştirildi) bilgisi dönecektir. Eğer veriler 3rd party bir uygulamadan geliyor ise (SQL Developer, Management Studio vb.) o zaman sizi bir listener karşılıyor (SQL Server dünyasındaki Alwayson listener’dan bahsetmiyorum!). Listener sizin ile database engine arasındaki iletişimi başlatıyor ve bağlanmanız onaylandıysa sizin için bir thread veya process (işletim sistemi ve database engine mimarisine göre bu değişiyor) açıyor ve doğrudan database engine ile konuşmaya başlıyorsunuz. Öncelikle bu tür işlemler için limitasyon var. Bir ilişkisel veritabanında maximum bağlanabilir kişi 65535 sayısını aşma ihtimali bulunmuyor. Tabii burada her bir session için tek bir thread veya process olması durumunda böyledir. Paralel olarak sorgularınızı gönderiyor veya işlenmesini istiyorsanız session / thread veya process olarak düşünmek gerekiyor. Yük dengelemesi için Oracle, MySQL veya PostgreSQL gibi bir veritabanı yönetim sistemi kullanıyorsanız aktif – aktif sistem ile birden fazla sunucu üzerinde konumlandırabiliyorsunuz. SQL Server kullanıyorsanız geçmiş olsun 😊 Çünkü aktif – pasif çalışan bir sistem olduğundan bu şekilde yük dengelemesi yapma olasılığınız yok. Bir Hadoop sisteme bağlanan kullanıcı sayısı için bir limitasyon söz konusu değildir. En azından şimdiye kadar böyle bir şikayet okumadım ve dokümanlarda kullanıcı sayı sınırlamasından bahsedilmiyor. Elbette bu sizin sistem kaynağınızla doğru orantılıdır. Bu da eş zamanlı bağlanabilirlik açısından lisanslı ücretli olan ilişkisel veritabanlarına göre daha avantajlı hale geliyor. Lisans ücretlerinin epey yüksek olduğunu düşündüğümüzde muhtemelen tüm big data alt yapısını lisans ücretine karşılık yapmak rahatlıkla mümkün olacaktır. Verilerin işlenmesi aşamasında ise ilişkisel veritabanları fiziksel olarak anında yazmıyor, ram üzerinde store edip, belirli aralıklarla checkpoint atarak verileri fiziksel diske yazıyor. Burada eğer hesaplama yapıyorsanız cpu, işlenen verilerin tutulması için yeterli düzeyde ram, fiziksel olarak yazma esnasında disk yazma hızlarının önemi vardır. Bu da demektir ki yüksek donanımlı sunucu ihtiyacı vardır. Bu tür sunucular için kapı 200.000 USD’den açılır ve milyon dolarlara doğru gider. Bir de storage sistemi almanız gerekecektir, ssd disklerle yazım hızlarını artırma ihtiyacı duyacaksınız çünkü verileri yazarken latency değerlerinin bir kaç mili saniyeyi geçmesini istemeyeceksiniz. Böyle bir sistemde milyon dolarlık seviyelere rahatlıkla çıkabilmektedir. Elbette yine ram ihtiyacınız da artacaktır. Tabii yedeklilik için de en az bir tane daha aynı özellikte sunucu almak zorundasınız. Bunun yanında disaster anında devamlılık için de bir tane daha almanız gerekecek. Yani ihtiyaç lineer artıyormuş gibi gözüksede n –> n3 olarak düşünmek gerekiyor. Bir hadoop istemi için yüksek kaynaklı sunucu ihtiyacı yoktur. Bir işlem çok ufak kaynaklı sunuculara yayıldığı için sunucu sayısı artışı ile hızı artırmak, verimi artırmak mümkündür ve maliyetleriniz çok daha düşük olacaktır. Google yüksek sayıda verisini, çok yüksek rakamlar ödediği ilişkisel veritabanlarında tutmaktansa ucua mal ettiği sunucularla, eş zamanlı olarak limitlere de pek takılmadan işleyebileceği bir sistem geliştirdi. Yaratıcı yıkım dedikeri bir süreç gelişti ve yeni ufuklar oluşmasına neden oldu. Artık her yerde bir Hadoop deneme fikri ciddi yer buldu. Rüzgar Hadoop’tan yana gözüküyor. Hadoop Verilerimizi Nasıl İşliyor? Hadoop hayatına başladığında map – reduce kütüphaneleri aracılığı ile işlem yapılıyor. MapReduce deyince Hadoop V1 akla geliyo ki o zaman job ve task trackerlara girmem lazım; ama oldukça eski ve geçersiz olduğu için gereksiz bir bilgiyle de zamanınızı almamak adına ben size Yarn’dan bahsedeceğim. Map ve Reduce, Hadoop üzerine veri işleme işlemlerini gerçekleştirirken Java üzerinde kullanadığımız Mapper ve Reducer sınıflarıdır. Hadoop V1’de bu işlemle özdeşleştiği için eski teknoloji gibi düşünülüyor; ama aslında durum biraz farklı. Eski versiyonda map ve reduce işlemlerini job tracker aracılığı ile task trackerlar yapıyorken Hadoop V2 ile Yarn ile işlemler gerçekleştiriliyor. Öncelikle Hadoop mimarisi ile başlayalım, sonra HDFS ve Yarn’ı anlattıktan sonra Map – Reduce modelinden de bahsederek Hadoop veri işleme sürecini bitirelim. Hadoop Mimarisi Bir Hadoop ortamı dediğimizde standalone (tek bir sunucu) olabileceği gibi onlarca ve belki de yüzlerce sunucudan oluşan bir clusterdan da bahsedebiliriz. Bu tamamen sizin tercihinize kalmış. Elbette standalone çalışmak pratikte sadece ortamı tanımayı hedefliyorsanız mantıklıdır; fakat bir geliştirme, test veya production ortam olarak kullanılacak ise cluster (küme) olarak kullanmak mantıklıdır. Bu sebeple tanımlayacağımız yapı bir cluster ortamı için geçerli olacaktır. Temel bir Hadoop cluster’ı yukarıdaki gibidir. Cluster’daki ana sunucu Name Node, verilerin saklandığı sunucular ise Data Node olarak adlandırılırlar. Name Node, meta data’yı tutar ve client üzerinden gelen istekleri karşılar. Hangi veri nerede saklanmıştır, sorgu için çalışması gereken node’lar hangileridir gibi işlemler Name Node üzerinden karar verilerek gerçekleştirilir. Yani Hadoop’un kalbidir. Name Node eğer hasar görürse, tüm cluster çöker, çünkü meta data elde kalmaz. Bu sebeple Name Node’un her zaman en az bir tane yedeği olması tavsiye edilir, tıpkı yukarıdaki topolojide gösterildiği gibi. Bir Hadoop Cluster’ında verilerin en az 3 replikaya yazılması tavsiye edilir. Cluster kurulumu yapaken bu sayıyı artırıp azaltabilirsiniz; ama 3 replika best practice’tir. Bunun sebebi comodity diye nitelendirdiğimiz aslında kişisel bilgisayarlarımıza yakın bir ortamda da işletilebilir bilgisayarlardan bahsettiğimiz için bunların atıza verme ihtimalleri sonrasında veri kaybı yaşanmaması açısından önerilir. Eğer veriyi tek replika üzerinde saklarsanız, sunucu gittiğinde verilerinize de elvada diyebilirsiniz. Google, ortalama sunucu problemlerinin % 3 olduğunu belirtmiştir. Yani her 100 sunucudan 3’üne yıl içerisinden veda ediliyor. Tabii Google’ın imkanları ve muhtemelen oldukça iyi sunucular ile store ettiğini düşünürsek normal bilgisayarlarla bu oranın artacağını rahatlıkla söyleyebiliriz. Data Node’lar ise verilerin üzerinde saklandığı ve bir hesaplama ve sonuç döndürme işlemlerinin üzerinde gerçekleştiği sunuculardır. Yedekli çalışırsanız hayati bir problem yaşamadan sorunsuz yolunuza devam edebilirsiniz, yani bir Name Node kadar kritik değildir. HDFS (Hadoop Distributed File System) Hadoop için geliştirilmiş dosya sistemidir. Bir dosya sistemi, verilerin nasıl saklanacağı ve nasıl okunacağı gibi işlemeri yönetir, yani oldukça hayatidir. Default olarak tek seferde 64 mb’lık veri işleyebilir yani blok size 64 mb’tır. Bu miktarı 128 veya 256 mb’a yükseltebilirsiniz. Bu ilişkisel veritabanlarında oldukça düşük miktardadır. Örneğin SQL Server 8 kb’lık data pagelerden oluşan 64 kb’lık bloklar halinde saklarlar. Oracle’da bu ayarlanabiliyor. 8, 16, 32 veya 64 kb’lık bloklar halinde saklayabilirsiniz ki OLTP sistemler için 8, Warehouse için ise 32 veya 64 tavsiye edilir. Anlayacağınız üzere diske veriyi yazma şeklinden kaynaklanan bir hız söz konudur Hadoop için. Tabii yine hatırlatmakta fayda var, Hadoop bir OLTP ortam için uygun değildir, Warehouse gibi bir kez yazıp çok fazla okumaya dayanan sistemler için kullanılabilir. Hadoop’a gönderilen veriler farklı sunucularda store edilebilir, bu hem yedeklilik açısından hem de hesaplama işlemini hızlı yapabilmek için böyledir. Yukarıda göreceğiniz gibi 3 replikalık bir yapıda 1, 2, 3, 4 ve 5 verilerimiz farklı 3 replikaya dağıtılmış durumdadır. Bunun kararını Name Node vermekte ve bilgileri kendisinde tutmaktadır. Yarn (Yet Anathor Resource Negotiator) Hadoop cluster’ında map – reduce işlemlerinin gerçekleştirilmesini sağlayan, kaynak yönetim aracıdır. Mimarisi aşağıdaki gibidir. Kısaca nasıl çalıştğını anlatmak gerekirse, bir işlem yapmak istediğimizde işlemimiz Name Node üzerinde çalışan Resource Manager’a iletilir ve kaynak tahsisi, hangi data nodeların işlem yapması gerektiği Resource Manager tarafından belirlenir ve yapılması gereken işlemler Node Manager’a iletilir. Node Manager, her bir data node üzerinde bulunan ve kaynak tahsisini düzenleyen uygulamadır. Üzerinde çalıştığı sunucunun ram, cpu ve disk alanı bilgilerini düzenli aralıklarla Resource Manager’a iletir. Resource Manager tarafından başlatılması istenen işlem olduğunda bunu Application Master’a iletir. Çalışan işlemlerin kontrolünü yapar, anormal bir durum olursa işlemi sonlandırır ve yeni container açılmasına izin vermeyerek durumu Resource Manager’a iletir. Application Master, sunucu üzerinde gerçekleştirilecek işlemler için bulundurulan kaynaktır. Kendisine iletilen bir işlem için yeter sayıda container oluşturur, hatta bunu başka Data Node’lar üzerinde de yapar. İşlem bitince sonucu Resource Manager’a iletir. Container ise yapılacak işlemlerle ilgili map veya reduce işlemlerini gerçekleştirildiği alandır.  Map – Reduce Modeli Hadoop üzerinde işlemler aslında bir Map ve Reduce işleminden ibaretttir. Başlangıçta yalnız Java ile yapılan süreç şu anda birçok dile ile gerçekleştirilebilir durumdadır. Bu sebeple bir programlama diline girmeden sadece Map ve Reduce işlemini kısaca anlatacağım. Map işlemi, girdinin kabul edilmesi ve işlenmesidir. Kendsine iletilen verileri key / value (anahtar / değer) çiftlerine çevirir ve reduce fonksiyonuna iletir. Reduce fonksiyonu ise Map işleminden çıkan key / value çiftlerini birleştirerek çıktı üretir.  Ambari Ambari, Hadoop cluster’ın yönetimi, monitör edilesi ve güvenliğinin sağlanması için geliştirilen bir araçtır. Ambari’nin bir web ortamı şekilnde erişilmektedir ve yönetim ekranı şöyle görünmektedir: Ambari topolojisi yukarıdaki gibidir. Her bir node üzerinde agent’ı bulunur ve gerekli veriler bu agent aracılığı ile Ambari Server’a iletilir. Ambari web uygulaması ise client side çalışır. Kullananıcı bilgisayarından javascript ile rest servisten bilgiler call metodu ile çekilerek yansıtılır. Doğal olarak async bir yapıda belirli aralılarla veriler çekilir. Default olarak rest api ile haberleşmede açılan session için bir sonlandırma zamanı yoktur. Böyle bir ihtiyaç durumunda Ambari üzerinde ayarlama yapılması gerekir. Flume Flume, streaming işlemleri için kullanılan araçlardan biridir. Stream işleminden kasıt akan yüksek miktarda verinin toplanması, hesaplanması, taşınması ve HDFS ortamına kayıt edilmesi için geliştirilmiş, dağıtık mimariye sahip bir araçtır. Sensör verileri, sosyal medya verileri, video gibi medya verileri, application loglar gibi verilerin işlenmesine olanak sağlar. Yukarıda tipik bir Flume akışı bulunmaktadır. İşlenecek veri kullanıcı üzerinde agent aracılığı ile alınır ve bir boru hattı gibi çerçeveleyerek Channel üzerinde karşılayan Agent’a veri iletlir ve Agent’ta veriyi yazması gereken Sink’e ileterek işlenmesini sağlar. Sonra Sink, işlemi gerçekleştirdiğine dair commit mesajını geri iletir.  Kafka Kafka, Linkedin tarafından geliştirilmiş bir programdır. Flume gibi Kafka’da dağıtık bir mesaj kuyruklama servisidir. Bu konuda en çok kullanılan open source system sanırım Kafka’dır. Kullanım amacı akan büyük boyutlu verileri düşük latency değerleri (10 milisaniyenin altında) ile işlenmesini sağlamaktır. Kafka bir cluster yapısında kurgulanabileceği gibi tek bir node olarakta kurgulanabilir elbette. Şimdi Kafka mimarisine bir bakalım. Producer: Kafka’ya mesajları yayınlayan api’lardır. Topic: Producer tarafından belirlenen formattaki mesajın tanımlanan kategorisidir. Kafka mesajları Topic üzerinde saklar. Consumer: Kafka ortamındaki topic’leri okuyup, istenilen ortama veriyi aktaran api’lardır. Broker: Cluster halindeki sunuculardır. Şimdi biraz daha derine inelim. Producer Mimarisi Producer’lar, Kafka üzerinde saklanacak verileri oluşturan api’lardır. Herhangi bir dil ile yazılabilirler. Python ile örnek olarak göstermek gerekirse: >>> from kafka import KafkaProducer >>> producer = KafkaProducer(bootstrap_servers='kafka1.hdp.local:6667') >>> for _ in range(100): ... producer.send('foobar', b'some_message_bytes') Yukarıdaki örneğe baktığımızda durum daha iyi anlaşılabilir. producer isimli nesne, görüleceği gibi Kafka için tanımlanmış producer sınıfından bir instance. Bağlanacağı Kafka cluster’ının adresi verilerek bağlantı sağlanıyor. producer nesnesinin send metodu ile görüleceği gibi ‘foobar’ ile Topik bilgisi verilmiş ve virgülden sonra da bu topic için saklanacak veriyi iletmektedir. Consumer Mimarisi >>> from kafka import KafkaConsumer >>> consumer = KafkaConsumer(bootstrap_servers='kafka1.hdp.local:6667') >>> consumer = KafkaConsumer('foobar') >>> for msg in consumer: ... print (msg) Consumer basit anlamda yukarıdaki python örneğinde görülebilir. Kafka clusterına bağlandıktan sonra ‘foobar’ isimli topic içerisinde saklanan bilgiler alınıyor ve bir döngü ile ekrana basılıyor. Tabii genelde bu böyle olmaz, normal şartlarda bunu elastic, mongo veya postgres gibi bir ortama yazılır. Topic Mimarisi Topic, producer aracılığıyla oluşturulan mesaj kategorileridir. Yazılan bir topic aynı anda birden fazla partition’a yazılmaktadır. Bu okuma işlemini kolaylaştırmak açısından büyük avantaj sağlamaktadır. Yazılan bir mesaj, her bir partition’a değiştirilemez bir offset değeri ile yazılırlar. İlk gelen mesaj 0 offset’îne sahip olarak oluşturulur ve sonra gelenler artar sayı şeklinde offset değerine ahip olarak oluşturulurlar. Tahmin edeceğiniz gibi bu sistem sürekli büyüyeceği için belirli bir süre sonunda silinmesi gerekir. Genelde bu bir haftadır. Bir hafta sonunda tüm veriler silinebilir, tabii bu ayarı siz istediğiniz şekilde, yapınıza göre değiştirebilirsiniz. Broker Mimarisi Yukarıda bir Kafka cluster’ı görülüyor. Yukarıdaki cluster’da 4 tane Kafka node’u bulunuyor ve bu her bir node broker olarak isimlendiriliyor. Bu yüksek erişilebilirlik (High Availibility) için böyledir. Herhangi bir node hata aldığında bu şekilde bir cluster’a sahip değilseniz verilerinizi kaybedeceksiniz demektir. Yukarıdaki yapıda 4 replica üzerinde toplam 3 node aynı veriyi taşımaktadır. Böylece herhangi biri veya ikisi çökse dahi verileriniz hala erişilebilir durumda olacaktır. Cluster içindeki bir replica lider (Leader) olur ve kendisine yazılan verileri diğer replicalara (Follower) veriyi dağıtır. Veri leader’e gelir ve o follwer’lara dağıtır. Dağıtım işleminde sıralama, yazma sırası gibi işlemler tamamen leader’ların sorumluluğundadır. Leader’da bir problem olduğu durumda bir follower ayağa kalkaak leader rolünü üstlenir ve kesintisiz hizmet verilmeye devam edilir. ZooKeeper Bir big data ortamı için olmazsa olmaz aracımızdır. Temelde yaptığı şey dağıtık bir sistemi konfigürasyon ve koordinasyon servisidir. ZooKeeper ile dağıtık bir sistemde ayarların tüm node’lar üzerine senkron edilmesi sağlamakla birlikte Hadoop sisteminde hangi node’un name node olduğu bilgisini de tutar. High Availibility için kaçınılmazdır. Herhangi bir dağıtık sistem kurduğunuzda Kafka Cluster, Hbase Cluster, Haddop Cluster vb. ZooKeeper ile ayağa kaldırır ve işletebilirsiniz, aksi halde işletilmesi mümkün değildir. Deyimi yerindeyse bu kadar hayvana bir bakıcı lazım diye oluşturulmuştur 😊 Ayrıca geliştiriciler için ZooKeeper dağıtık mimaride uygulama geliştirme imkânı ve kütüphaneleri de sağlamaktadır. Hive Hive, Facebook tarafından geliştirilmiş bir uygulama. Temelde Hadoop üzerinde verileri Map – Reduce ile işlediğimizi veya analiz ettiğimizi söylemiştik. Burada eskiden yalnız Java kullanılıyordu. Hive buna bir alternatif olarak geliştirilmiş ve SQL’e oldukça yakın bir dil olan HiveQL dili kullanılarak bu işlemlerin kolaylıkla gerçekleştirilmesini sağlayan bir araçtır. Hive topolojisi yukarıdaki gibidir. Hadoop cluster’ımızda bulunan veriler, bu verilerin saklandığı tablolar, tablodaki kolonların veri tipleri gibi bilgiler MetaStore üzerinde tutulmaktadır. Böylece clusterımız üzerindei veriler üzerinde Ad-hoc queryler yazabilir ve veri keşfi yaparak çeşitli analizler gerçekleştirebiliriz. Hive, sorgulama ve analiz işlemlerini ağır yaptığı için real time sorgulamalarda kullanılması tavsiye edilmez. Daha çok veri ambarı gibi, olap yapılar gibi analiz tabanlı işlemlerin yapıldığı bir yapıda kullanılması daha uygun olacaktır. Pig Hive gibi Pig’de Map – Reduce işlemlerini yapabilmek için geliştirilmiş platformdur. Apache tarafından geliştirilen uygulama bir dönem çok sıkı şekilde kullanılmaktaydı. Pig dediğimizde aslında iki şeyden bahsediyoruz, şimdi bunlardan bahsedelim. Pig Latin Pig Latin, yapılacak işlemler için yazılan script dilinden bahsediyoruz. Farklı formatta verileri alıp işleyebilir, üzerinde sıralama, gruplama, aggregation işlemleri yapabiliyorsunuz. Elbette bu durum bir performans problemi yaratmaya da aday, bu yüzden bir Pig Latin scripti iyi tasarlanmalı ve yazılmalıdır ve üzerinde çalıştığınız verileri iyi bilmeniz veya bilen biri ile çalışmanız önemlidir, aksi halde ilişkisel veritabanlarındaki benzer performans problemleri yaşayabilirsiniz. Pig Latin sayesinde, Java ile yüzlerce satırlık kod yazarak yapabileceğiniz işlemleri on – on beş satır kod ile yapabilmeniz mümkündür. Doğal olarak hem zamandan hem de efor açısından ideal bir dildir. Pig Engine Pig Latin ile yazılmış scriptlerin Map – Reduce kodlarına dönüştürüldüğü ortama Pig Engine denmektedir. Hadoop ortamında Java esas dil olduğu için bu şekilde bir yol izlenmiştir. Bir Pig Latin scripti işletildiğinde Pig Engine’de şu işlemler gerçekleştirilir: Parse: Pig Latin ile yazdığımız kodların yazım kuralları kontrol edilir. Eğer yazım ile ilgili bir sorun varsa exception fırlatılır ve işleme devam edilmez. Geliştiriciye hatanın kaynağı belirtilerek düzeltmesi beklenir. Compile: Bu aşamada Pig Latin scriptiniz Java tabanlı Map – Reduce kodlarına dönüştürülür. Programcılıkla uğraştıysanız bunu C, C++, Java gibi dillerin makine koduna dönüştürüldüğü durumun benzerini hayal edebilirsiniz, tek fark var, burada dönüştürüldüğü uygun ortam Hadoop olduğu için Java temelli bir koda dönüştürülür. Optimize: Yazdığınız Pig Latin scripti iyi tasarlanmış bir Map – Reduce kodu haline getirilmeye çalışılır; fakat sizin yazdığınız koda göre optimizasyon yapılacağı için, yazdığınız kodun kalitesi buradaki durumu etkiler. Zira Alan Gates’in dediği gibi: “Pig evcil bir hayvandır, ne söylerseniz onu yapar!”. Plan: Verilere erişme şeklinizin çıkartıldığı bölümdür. Hadoop ortamında name node üzerinde meta data’nın tutulduğundan bahsetmiştik hatırlıyorsanız. İhtiyacınız olan verilere erişmek istediğinizde bu verilerin nerede tutulduğu ve enuygun erişim metodunun ne olduğu belirlenir ve buna göre okuma veya yazma işlemleriniz programlanır. Tez Hive ve Pig ile boğuştuktan sonra performansı gözlerinizi yaşartacak ve ağzınızı açık bırakacak olan bir araçtır Tez. Hadoop V2 ile birlikte Yarn tarafından koordine edilen yüksek seviyeli data process işlemleri için kullanılan bir framework’tür. Cloudera dağıtımlarında bulunmuyor; ama Hortonworks dağıtımlarının olmazsa olmazı durumunda ve bence gerçekten de olması gereken bir framework. Tez birkaç anahtar noktada destek sağlar: Kullanıcı tarafından yapılmak istenen hesaplamaları bir DAG (Directed – Acyclic – Graph) olarak modelleme imkânı tanır. Klasik vertex ve edge yapısının daha iyi ayrıştırılmasıyla birlikte veri düzleminin daha fazla kontrol edilmesini ve özelleştirilmesini sağlar. DAG tanımını dinamik olarak geliştirmek için API'ler sunar. Bunu, online bilgilere dayanarak sofistike query optimizasyonu, data partition budama gibi karmaşık çalışma zamanlı sorgu optimizasyonlarını sağlar. Bazı özelliklerin ölçeklenebilir ve verilmli şekilde uygulanmasını sağlar. Örneğin YARN uyumlu güvenlik, data lolocality, hataya dayanıklılık, kaynakların yeniden kullanımı gibi. Pluggable API’ler aracılığıyla framework yazarları ve araştırmacıları için gerçek dünya deneyimini inovatif ve hızlı bir şekilde elde etme fırsatını sağlar. Tez'i “birleşme frameworkleri”nin birçok alternatifinden ayrı kılan şey şudur: Kanıtlanmış esneklik ve dinamik adaptasyon Operasyonel kaygılara odaklanma (production hazırlığı) Tez'i var olan birçok alana özgü engine’lere yerleştirmek. DAG’ı da kısaca tarif edecek olursam: Bir veri işleme iş akışının yapısını temsil eden Yönlendirilmiş Asiklik Graf. Veri edge yönünde akar. Vertex: İşlemenin mantıklı bir adımını temsil eder. Bir işlem adımı, filtrelemek veya verileri değiştirmek için uygulama tarafından sağlanan kodu uygulayarak verileri dönüştürür. Toparlayacak olursam, Tez Hive ve Pig gibi frameworklerin de ötesinde YARN ile tam uyumlu, Map – Reduce işlemlerini oldukça hızlı ve optimize yapabileceğimiz bir alt yapı sağlamaktadır. Özellikle büyük boyutlu veri kümesini yazdığımızı düşündüğümüzde Tez artık vazgeçilmez bir araç haline kolaylıkla gelebiliyor. Spark Tez gibi Map – Reduce işlemlerini optimize yapmak için kullanılan bir framework’tür. Hortonworks dünyasında Spark, Tez’in üzerinde koşmaktadır ve bu şekilde daha performans sağlandığı yönünden Yahoo’nun yaptığı çalışmalar sonucunda ortaya konan veriler vardır; ama daha önce de dediğim gibi Tez, Hortonworks dışında kullanımına pek rastlamadım. Spark ile veri ile ilgili Map – Reduce işlemlerini ram üzerinde gerçekleştiriyor; fakat bu hemen her şeyi ram üzerinde yapıyor anlamına gelmiyor. Bir şehir efsanesine dönüşen duruma bir açıklık getirmek gerekirse, eğer işleyeceğiniz veri, sunucunuz üzerindeki kullanılabilir durumda olan ram miktarını aşmıyorsa işlem ram üzerinde gerçekleştirilir; aksi halde disk üzerinde kullanılır. Map – Reduce’e göre kolay geliştirme yapılabilir bir ortam sağlamakla birlikte elbette disk kullansa da daha performanslıdır. Bunun nedeni de verileri işlemek için RDD (Resilent Distrubuted Dataset) kullanmasından kaynaklanır. RDD, özellikle tekrarlı verilerle ilgili işlemlerde önemli bir fark yaratmaktadır. Spark üzerinde R, Python, Java ve Scala dili ile geliştirme yapabildiğini gibi Ansi SQL’e yakın Spark SQL dili ile de geliştirme yapabiliyor. Scala aynı zamanda Spark’ın da geliştirildiği dil olduğu için Spark üzerinde herhangi bir işi yapmak ile ilgili örnek aradığınızda Scala dili olan örneklerin çokluğunu görüyor olacaksınız. Spark güzel kütüphanelere de sahiptir. Örneğin makine öğrenmesi için MLib kullanılmaktadır. Graphx, graph modeline dayanan hesaplamalar yapmak için kullanılan güzel kütüphanelerinden biridir. Yine Spark Streaming, gerçek zamanlı işlemlere yakın bir performans ile verileri işlemenizi sağlayan bir alt yapı da sunuyor. Batch işlemler için kullanmak pek avantaj sağlamıyor diyebilirim. Burada ihtiyaca göre başka bir aracı değerlendirmek daha uygun olacaktır. Gerçek zamanlı verileri işlemek için ise Spak daha efektif bir üründür. Oozie Oozie, yapılacak işlerin koordinasyonunu yapabilmek için geliştirilmiş bir uygulamadır. Web tabanlı olarak erişim sağlanır ve yapılması gereken işleri sırasıyla tanımlayarak komplex işlemleri planlayabilir ve çalışmasını sağlayabilirsiniz. Yukarıda görüldüğü gibi ardışık veya dağıtık çalışacak işler Oozie üzerinden planlanarak hayatınızı kolaylaştıracak işler yapabilirsiniz. Yapılacak işler karmaşıklaştıkça Oozie gibi bir aracı kullanmanın önemi daha da artar. Sqoop Sqoop, temelde ETL görevi yapar. Yani farklı servislerdeki verileri Hadoop ortamına yazdığı gibi, tersi de mümkündür, yani çift yönlü aktarım mümkündür. Oracle, SQL Server, Teradata, DB2 gibi popüler RDBMS’ler de dahil JDBC ile bağlanılabilecek tüm RDBMS’lerden veri alabilir veya yazabilir. Sqoop oldukça hayati uygulamalardan biri. Zira Hadoop’un temeli farklı veri kaynaklarından beslenmek olduğu için, ETL dediğimiz verileri alınması, döüştürülmesi ve hedefe yazılması işlemlerinin gerçekleştirilmesini sağlar. HDFS Dosya Formatları HDFS içerisinde alttaki dosya formatlarını kullanabiliriz. Şimdi bu dosya formatlarını genel hatları ile anlatalım. Sequence File Verileri ikili anahtar / değer çiftleri olarak saklar. SequenceFiles içinde saklanan kayıtlar için üç format vardır: Sıkıştırılmamış Çoğunlukla, sıkıştırılmamış SequenceFiles, girdi / çıktı (G / Ç) için daha az verimli olduklarından ve disk üzerinde sıkıştırılmış biçimde aynı verilerden daha fazla yer kapladığından, sıkıştırılmış alternatiflerine göre hiçbir avantaj sağlamaz. Tutanak sıkıştırılmış Bu format dosyaya eklenen her bir kayıt bazında sıkıştırma yapar. Blok sıkıştırılmış Bu format, her kayıt eklendiğinde sıkıştırma yapmaz, verilerin sıkıştırılacak blok boyutuna ulaşmasını bekler. Blok sıkıştırma, tutanak sıkıştırılmış SequenceFiles ile karşılaştırıldığında daha iyi sıkıştırma oranları sağlar ve genellikle SequenceFiles için tercih edilen sıkıştırma seçeneğidir. Ayrıca, burada bloklanacak referansın HDFS veya dosya sistemi bloğu ile ilgisi yoktur. Blok sıkıştırmasındaki bir blok, tek bir HDFS bloğunda birlikte sıkıştırılmış bir kayıt grubunu belirtir. Biçimden bağımsız olarak, her SequenceFile, kullanılan sıkıştırma kod çözücüsü, anahtar ve değer sınıfı adları, kullanıcı tanımlı meta veriler ve rastgele oluşturulmuş bir eşitleyici işaretleyici gibi, dosya hakkında temel meta veriler içeren ortak bir üstbilgi biçimi kullanır. Bu senkronizasyon işaretçisi, ayrıca dosyada rastgele noktaların aranmasına izin vermek için dosyanın gövdesine yazılır ve ayrılabilirliği kolaylaştırmanın anahtarıdır. Örneğin, blok sıkıştırması durumunda, bu senkronizasyon işaretleyici dosyadaki her bloktan önce yazılacaktır. SequenceFiles, Hadoop ekosisteminde iyi bir şekilde desteklenir, ancak ekosistem dışındaki destekleri sınırlıdır. Onlar da sadece Java'da desteklenir. SequenceFiles için yaygın bir kullanım durumu, daha küçük dosyalar için bir kapsayıcıdır. Hadoop'ta çok sayıda küçük dosyayı saklamak birkaç soruna neden olabilir. Biri, NameNode için aşırı bellek kullanımıdır, çünkü HDFS'de depolanan her dosya için meta veriler bellekte tutulur. Bir başka potansiyel sorun da bu dosyalardaki verileri işlemektir - birçok küçük dosya birçok işlem görevine yol açarak işlemlerde aşırı kaynak tüketimine neden olabilir. Hadoop büyük dosyalar için optimize edildiğinden, daha küçük dosyaları bir SequenceFile içine paketlemek, bu dosyaların depolanmasını ve işlenmesini çok daha verimli hale getirir. Avro Avro belki de dört formattan en basitidir, çünkü sütunsal değildir ve ilişkisel veritabanlarındaki gibi satır bazlı saklar. Avro'nun ana amacı, verileri sıkıştırmak ve şema esnekliğini kaybetmeden yapabilmektir. Örneğin, Hadoop'u belge deposu olarak kullanmak ve tüm verilerinizi JSON olarak sıkıştırmak için Avro dosyalarında tutmak isteyebilirsiniz, bunu Avro ile yapabilirsiniz. Çalışmak istediğiniz bazı karmaşık şemalara sahip olabilirsiniz ve tümü Avro ile de çalışabilir. Avro'nun esnekliği, istediğiniz sayıda şema çalışmanıza ve hala düzgün bir sıkıştırma elde etmenize olanak sağlar. Bir başka pozitif yanı ise Avro dosyaları dinamik olarak yazılmıştır. Bu, şema esnekliğine ve RPC desteğine izin verir. Bununla birlikte, Avro veri sıkıştırma için mükemmel bir formattır ve Spark'taki çoğu sıkıştırma tekniği için varsayılan olacaktır. Olumlu yanlarından sonra olumsuzluklarına bakacak olursak, Avro diğerlerden daha maliyetlidir. Örneğin, bir sütun bazlı formata kıyasla mümkün olan en iyi sıkıştırmayı elde edemezsiniz. Ayrıca, tüm veri formatları, sorgular için satır bazlı geçişe ihtiyaç duyacaktır. Şema esnekliği diskte daha fazla yer almaya değer olduğunda çok fazla bir sorun olmayabilir elbette. Parquet Parquet, Avro'dan farklı bir amaca sahiptir. Maksimum şema esnekliğine izin vermek yerine, sorgu hızlarını artırmak ve disk I/O'sunu azaltmak için kullanabileceğiniz şema türlerini optimize etmeye çalışır. Parquet, sütunlarda iç içe tiplere izin vererek geleneksel sütun bazlı tutmanın bazı zayıflıklarının üstesinden gelmeye çalışır. Böylece teknik olarak bir dizi olan bir sütuna ya da aslında birkaç sütun olan bir sütuna sahip olabilirsiniz. Spark Summit'te sadece bu konuyla ilgili harika bir konuşmalar oldu ve çalışmamda yararlı buldum. Parquet, çok sayıda düşük seviye optimizasyona ve belgelerde bulabileceğiniz diskte nasıl depolandığı ile ilgili bir dizi ayrıntıya sahiptir. Parquet belki de Spark ile ilgili birçok projede göreceğiniz en yaygın dosya formatıdır ve ben de kullanma eğilimindeyim. ORC(Optimized Row Columnar) ORC, Parquet'nin sütun biçimini paylaşır ancak bazı farklılıklar vardır. Başlıca farklılıklardan biri, kesinlikle yazılmış olması. ORC ayrıca iç içe veri türlerine izin veren listeler ve haritalar gibi karmaşık türleri de destekler. Sıkıştırma söz konusu olduğunda, ORC'nin verileri Parquet'den daha verimli bir şekilde sıkıştırdığı söylenir, ancak bu verilerinizin nasıl yapılandırıldığına bağlıdır. Parquet'de desteklenen özelliklerin yanı sıra, ORC ayrıca ACID işlem garantilerini de destekler. ACID'den yararlanabilecek uygulamaların sayısı düşünüldüğünde çok önemlidir. ACID işlemlerinin sadece veri biçiminde eklenmesi biraz karmaşık, ancak ilgileniyorsanız detayları araştırabilirsiniz. Presto veya Athena kullanıyorsanız, ORC tercih edilen formattır. Presto motorunda yapılan son değişikliklerle, ORC kullanımının birçok avantajı oluyor. Ek olarak, ORC stream verilerini işleyebilen birkaç sütun formatından biridir. ORC ayrıca client tarafında önbelleğe almayı da destekler ve bu da son derece değerli olabilir. Her türlü OLAP iş yükü için ORC'yi gerçekten bayıldım. RC File RCFile formatı özellikle MapReduce uygulamaları için performanslı işlem yapabilmeyi desteklemek için geliştirilmiştir, ancak pratikte yalnızca Hive depolama biçimi olarak kullanıldığı görülür. RCFile formatı hızlı veri yükleme, hızlı sorgu işleme ve yüksek verimli depolama alanı kullanımı sağlamak için geliştirilmiştir. RCFile formatı dosyaları satır bölmelerine böler, sonra her bölmede sütun odaklı depolama kullanır. Her ne kadar RCFile formatı, SequenceFiles ile karşılaştırıldığında sorgu ve sıkıştırma performansı açısından avantajlar sunsa da, sorgu süreleri ve sıkıştırma için en uygun performansı önleyen bazı eksikliklere de sahiptir. ORC ve Parquet gibi daha yeni sütun biçimleri bu eksikliklerin çoğunu giderir ve çoğu yeni uygulama için muhtemelen RCFile kullanımının yerini alacaktır. RCFile, Hive depolama alanında kullanılan oldukça yaygın bir formattır. Peki hangisini kullanmalıyım? Dağıtılmış hesaplama dünyasında, belirli bir platforma avantajlı testler tasarlamak çok kolaydır. Her birini sahip olduğunuz analitik iş yükü için denemenizi tavsiye ederim. Bunların her biriyle çalıştıktan sonra, bana yardımcı olacak bazı yöntemler buldum: Presto veya Athena kullanıyorsanız ORC, muhtemelen sizin için en iyi formattır.  Spark kullanıyorsanız Parquet veya Avro, en mantıklı olanıdır. Hive kullanıyorsanız veya kendi MapReduce işlerinizi yazıyorsanız, ORC muhtemelen sizin için en iyi seçenektir. JSON kullanıyorsanız, yalnızca gerçek seçeneğiniz Avro'dur veya JSON'unuzu biçimlendirecek bir pipe line oluşturmak istiyorsanız, diğer biçimlerden herhangi birini kullanabilirsiniz. Genel olarak, her format bir metin dosyasını veya bir csv'yi depolamak için bazı büyük optimizasyonlar sağlar, ancak doğru seçenek ne için kullanacağınıza bağlıdır. Ben tecrübe ettiğim kadarını sizlerle paylaştım.