Genişleyebilir Hesaplama Ortamları ve Apache Spark

Merhabalar 🙂

Bitirme tezimdeki “Genişleyebilir Hesaplama Ortamları ve Apache Spark” isimli bölümü paylaşıyorum.

Özel olmayan standart bilgisayar donanımlarında ilk dağıtık hesaplamayı Google başlatmamış olsa da, endüstri seviyesinde bu akımı başlatan şirket Google oldu. Google dağıtık bilgisayarlar üzerinde genişleyebilir bir mimaride ucuz bilgisayarları kullanarak endüstriye bir öneri sunmuş oldu. Yayınladıkları Google Dosya Sistemi (The Google File System) makalesi [16] ve önerdikleri haritala-indirge (map-reduce) algoritması [17] bilişim sektörü için oyun değiştiriciydi. Çünkü bu iki tekniği kullanarak büyük olan veriyi organize halde yönetebildiler ve hesaplamayı genişleyebilen bir mimaride bilgisayar kümeleri üzerinde gerçekleyebildiler. Bu iki teknik ile Google bütün interneti indeksledi. Bu iki teknik Google’ı dünyanın en iyi arama motoru yapan faktörlerden ikisiydi. Burada önemli olan Google’ın teknolojiye bakış açısıydı. Google başından beri dağıtık bir dosya sistemi üzerinde tasarlandı. Aslında kullandıkları algoritma, arama motoru başarısı açısından o dönemki en yakın rakibi Altavista’nın önüne geçmesine sağlamış olsa da, bunu dağıtık ve genişleyebilir bir dosya sistemi ve dağıtık ve genişleyebilir hesaplama alt yapısı olmadan yapamazlardı. Altavista’nın yazılım altyapısına dair bir bilgi bulunmasa da, kullanılan donanım özellikleri Altavista’nın yazılım alt yapısına dair genişleyebilir bir mimari olmadığının ipuçlarını vermekte. 1998 yılında Altavista’nın alt yapısında 20 tane çok çekirdekli, 130 GB belleği bulunan ve 500 GB sabit diski bulunan bilgisayarlardan oluşmakta [18]. Altavista’nın yaratıcıları donanım üreticisi (DEC) olduğu için makinelerin donanımsal özelliklerini bu kadar yüksek tutabilmişlerdi. Google ise 1999 yılında Exodus veri merkezinden kiralanmış 30 adet Pentium 2 işlemcisi olan standart sunucu bilgisayarlar üzerinde çalışmaktaydı [19]. Altavista’nın sunucularındaki donanım özelliklerinin yanına yaklaşamazlardı. Kişisel tahminim, Altavista’nın burada farkedemediği şey sonsuza kadar genişleyen bir mimariye uygun vizyonlarının ve büyük ihtimalle de yazılımlarının olmamasıdır. Sebebi ise, yapılarını daha çok dikeyde genişleyen bir mimari üzerine kurmuş olmalarıdır. Google’ın kurucularının farkında olduğu şeyin farkında olsalardı, dönemin şartlarında 130GB belleği bulunan bir sunucu kullanma zahmetine girmezlerdi. Google ise en başından beri –ellerindeki yazılım bunu yapamasa bile- “yatayda sonsuza kadar genişleyen bir yazılım tasarımı” vizyonuyla hareket etmiş, şirket olarak teknolojik kararlarını bu vizyon üzere almıştır. Google’ın kurucuları farkında olarak veya farkında olmadan bize “büyük veri” kavramının kapılarını açmışlardır. Altavista’nın Google’a kaybetmesinin görünürdeki sebebi algoritmasının Google’dan daha başarısız olmasıdır, fakat görünmeyen, altta yatan bir başka sebep ise Google’ın büyük veri kavramı Altavista’dan daha doğru tanımlaması ve şirket olarak hamlelerini buna göre yapmasıdır. (Ek not: Büyük veri kavramını tanımlamaktan kasıt uygulamalı olarak bunu eyleme koymalarıdır. Yoksa bunu ilk sözcük olarak tanımlayan olduklarını iddaa etmek oldukça saçmadır. Dönemin teknoloji ruhu zaten bunu doğru bir şekilde eyleme dökmeye uğraşmaktadır. Görüldüğü üzere o dönem Altavista firması da aynı şekilde uygulamalı bir şekilde gerçeklemeye uğraşmıştır. Fakat tasarımları görüldüğü üzere Google’dan daha başarısızdır. Aynı dönemde Yahoo firmasında da büyük veriyi yönetmek üzerine çalışmalar yapılmıştır.)

Google’ın endüstride açtığı bu yeni kapı, açık kaynak kodlu Hadoop projesini doğurmuştur. Google’ın yayınladığı Google dosya sistemi ve haritala-indirge algoritması sonucunda yazılan Hadoop, yazılım olarak 4 ana parçadan oluşsa da, ekosisteminde birçok yazılım mevcuttur [20].

Hadoop’un parçaları şunlardır:
Hadoop-common: Hadoop modülleri tarafından ihtiyaç duyulan kütüphaneleri ve araçları içerir.

HDFS: Hadoop ortamındaki dağıtık dosya sistemi. Normal bir dosya sistemi bir dosyayı, dosya üst bilgisi (metadata), ve dosya verisi olarak tutar. Dosya verisi bloklara ayrılır. HDFS ise dosya üst bilgisini isim servisinde (namenode) tutar, dosya verisi bloklarını ise Hadoop kümesindeki makinelere algoritmik olarak dağıtır.

YARN: Hadoop ortamındaki kaynak yönetim modülüdür. Hadoop ortamında çalıştırılacak işler YARN’a gönderilir. Kendisine gelen işler için kaynak planlaması ve iş sıralama yapar.

MapReduce: Hadoop ortamındaki dağıtık ve genişeyebilen hesaplama altyapısıdır. Tek bir bilgisayar üzerinde hesaplaması uzun sürecek işleri birden fazla bilgisayar üzerinde parçalayarak daha hızlı sonuca varmak için kullanılabilir. Herhangi bir programlama dili kullanılarak geliştirilebilir. Hadoop’un kullandığı MapReduce alt yapısı her parça işlem (map veya reduce herhangi biri olabilir) sonunda veriyi sabit diske yazar.

Apache Spark yazılımı da MapReduce gibi dağıtık ve genişleyebilen hesaplama altyapısıdır. Yapılan parça hesaplama operasyonları bellek üzerinde tutulur. Aksi belirtilmediği sürece diske yazılmazlar. Böylece Hadoop ortamındaki MapReduce hesaplama altyapısından ~100 kat daha hızlı işlem yapabilir [13]. Bu hızlanma her zaman 100 kata kadar çıkmamakla beraber (bazen 30 kat, bazen 2-3 kat), ana fikri itibariyle MapReduce’tan daha hızlı işlem yapacağı barizdir.

Apache Spark ortamında Scala, Java, Python ve R programlama dilleri kullanılarak geliştirme yapılabilir. Hangi programlama diliyle geliştirilmiş olsun, Spark Java sanal makinesi üzerinde çalışır.

Apache Spark, Hadoop MapReduce gibi dağıtık bir hesaplama ortamı olduğu gibi YARN gibi kaynak yönetim ve iş sıralama modülüne ihtiyacı vardır. Apache Spark, Hadoop projesinin bir parçası olmasa da, YARN kaynak yönetimi modülünü kullanabilir. YARN modülünü kullanmak istemeyen, Spark’ı bağımsız olarak çalıştırmak isteyen kullanıcılar için, Spark’ın kendi iç mekanizmasında bir kaynak yönetimi ve iş sıralama modülü mevcuttur. Dileyen kullanıcılar bunu kullanabilir. Apache Spark’ın kaynak yönetimi ve iş sıralama için kullanabileceği üçüncü bir ortam ise Mesos ortamıdır.

Mesos veri merkezleri için işletim sistemi olduğunu iddaa eden bir kaynak yönetimi ve iş sıralama yazılımıdır. Bunu yaparak veri merkezi kaynaklarını daha efektif kullanmayı hedeflemektedir. YARN sadece kendi ortamına entegre yazılımları çalıştırabilirken taşıyıcı (container) desteğiyle docker ve AppC taşıyıcılarını çalıştırabilir. Böylece YARN’a kıyasla daha genelleştirilmiş bir çözüm sunar. Mesos pratik açıdan çok farklı işletim sistemlerinde, çok farklı yazılımların koştuğu ortamlar için uygun değildir. Örneğin, Microsoft Windows 2012 R2 işletim sistemi üzerinde çalışan Active Directory yazılımı ve Solaris üzerinde çalışan Oracle Veritabanı 12c gibi yazılımları ve onların üzerinde koştuğu makineleri kendi kaynak yönetimi ve iş sıralama sürecine dahil edemez. Henüz yazılımsal olarak böyle bir yeteneği mevcut değildir. Fakat Linux işletim sistemi üzerinde çalışabilecek, çekirdek ve çekirdek modülleriyle özel olarak ilişkisi bulunmayan her türlü uygulama Mesos üzerinde taşıyıcılar (containers) aracılığıyla çalıştırılabilir. Mesos pratik açıdan daha çok Google, Facebook, Twitter gibi genişleyebilen uygulamaları çalıştırmak için uygun bir yazılımdır. Hali hazırda Twitter, Airbnb, Apple gibi büyük şirketler kullanmaktadır [21] . Mesos aslında bu bölümde Google için bahsedilen “yatayda sonsuza kadar genişleyen bir yazılım tasarımı” vizyonunun bir ürünüdür. Google kendi sunucu sistemleri için kaynak yönetimi ve iş sıralaması yapan Borg adından bir yazılım geliştirmiştir [22]. Mesos bu yazılımdan esinle geliştirilen açık kaynak kodlu bir projedir. Doğru tanımlamak adına, Mesos veri merkezi kaynaklarını daha efektif kullanabilen bir uygulama değildir. Mesos büyük veri için yazılmış uygulamaları, veri merkezlerinde daha efektif çalıştırmak için yazılmış bir uygulamadır. Mesos’tan sonra Google’ın kendi içerisinde Omega isimli başka bir kaynak yönetimi ve iş sıralayıcı yazılım geliştirilmiştir. Bu yazılımın algoritmasının geliştirilmesinde Mesos tasarımcılarından Andy Konwinski de yer almıştır [23] [24]. Bundan sonra Google, taşıyıcılar (containers) için Kubernetes adında kaynak yönetimi ve iş sıralama yazılımı geliştirmiş ve bunu açık kaynak olarak topluluğa sunmuştur [22].

Linux işletim sisteminde taşıyıcılar (containers) temel manada Linux çekirdeğindeki özelliklerden isim alanları (namespaces), kontrol gruplarını (cgroups) kullanarak ayrı bir isim uzayında prosesler çalıştırmaya ve bunları kontrol grupları aracılığıyla bellek, çekirdek sayısı, ağ kartı gibi kaynakları sınırlama ve kontrol etme mantığına dayanan izole edilmiş ortamlardır. Linux taşıyıcılar daha öncesinde barındırma hizmeti sağlayıcılar tarafından OpenVZ adı altında olarak sanallaştırma olarak satılmış olsa da, teknik açıdan sanallaştırma olarak değerlendirilmemektedir. Sanallaştırma, mevcut işletim sisteminin üzerinde başka bir sanal makine ve o makinenin üzerinde başka bir işletim sistemi ve haliyle o işletim sisteminin çekirdeği şeklinde çalışan uygulamalardır. Linux taşıyıcılar, ana makine ile aynı Linux çekirdeğini ve aynı Linux çekirdek modüllerini kullanmaktadır. Linux taşıyıcılar, Linux işletim sistemi üzerinde ana makineden ayrı isimlerle etiketlenmiş normal proseslerdir. Linux taşıyıcılar sanallaştırma tekniğinden daha hızlı olmakla beraber, teknik açıdan sanallaştırmadan daha güvensizdir. Güvenilmeyen uygulamalar taşıyıcı makineler üzerinde çalıştırılmamalıdır.

Bu bölümde kavramsal olarak büyük veri kavramı, yatayda genişleme ve dikeyde genişleme, dağıtık ve genişleyebilen dosya sistemleri, dağıtık ve genişleyebilen hesaplama ortamları, büyük veride kaynak yönetimi ve iş sıralama, büyük verinin işlenme sürecinin yönetilmesi, sanallaştırma, taşıyıcılar ve bunların yatayda genişleyebilen yazılımlara sağladığı esneklik anlatılmıştır. Ayrıca hikâye ve tarihçe olarak Altavista ve Google’ın büyük veri kavramını nasıl ele aldığı, Hadoop yazılımı ve Hadoop’un ortaya çıkışı, Mesos yazılımı ve Google ile ilişkisi anlatılmıştır. Bunların anlatılma sebebi Spark yazılımının teknik olarak nerede durduğunu belirlemek ve hangi aşamalardan geçerek bu noktaya geldiğini göstermektir.

Spark yazılımı büyük veriyi işlemek adına yazılmış dağıtık ve genişleyebilen hesaplama ortamıdır.

Referanslar:
[13] Apache Spark, “Apache Spark”, 2016
http://spark.apache.org
[14] Apache Spark, “Spark Streaming – Spark 2.0.2 Documentation”, 2016 http://spark.apache.org/docs/latest/streaming-programming-guide.html#mllib-operations
[16] S. Ghemawat, H. Gobioff, S.-T. Leung, “The Google File System”, 2003 https://static.googleusercontent.com/media/research.google.com/tr//archive/gfs-sosp2003.pdf
[17] J. Dean, S. Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters”, 2004 https://static.googleusercontent.com/media/research.google.com/tr//archive/mapreduce-osdi04.pdf
[18] Wikipedia, “Altavista”, 2016
https://en.wikipedia.org/wiki/AltaVista
[19] U. Hölzle, “15 years ago (on Feb 1st, 1999) I first set foot in a Google datacenter.”, 2014
https://plus.google.com/+UrsH%C3%B6lzle/posts/UseinB6wvmh
[20] Wikipedia, “Apache Hadoop”, 2016
https://en.wikipedia.org/wiki/Apache_Hadoop
[21] Wikipedia, “Apache Mesos”, 2016
https://en.wikipedia.org/wiki/Apache_Mesos.
[22] B. Burns, B. Grant, D. Oppenheimer, E. Brewer, J. Wilkes, “Borg, Omega, and Kubernetes”, 2016 https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44843.pdf
[23] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. D. Joseph, R. Katz, S. Shenker, I. Stoica, “Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center”, 2011 http://people.csail.mit.edu/matei/papers/2011/nsdi_mesos.pdf
[24] M. Schwarzkopf, A. Konwinski, M. Abd-El-Malek, J. Wilkes, “Omega: flexible, scalable schedulers for large compute clusters”, 2013 https://static.googleusercontent.com/media/research.google.com/tr//pubs/archive/41684.pdf

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.