Apache Oozie’yi Oluşturan Unsurlar

Bu yazımda Apache Oozie’yi oluşturan temel kavramlar ve bunlar arasındaki ilişkiden bahsedeceğim. O’Reilly tarafından basılmış Apache Oozie kitabının bu bölümünü okuyorum. Onu okurken aldığım notları sizinle paylaşacağım. Kitap, Mohammed Kamrul Islam ve Aravind Srinivasan adlı Oozie projesinde de görev almış iki yazar tarafından kaleme alınmış.

Giriş

Yahoo’da Hadoop kullanılmaya başladıktan sonra Hadoop görevleri daha karmaşık ve çok kademeli hale gelmiş. Bu kadar birbirine bağımlı görevi yönetmek ve takip etmek için çözüm aramaya başlamışlar. Kimi script shell yazmış kimi de Hadoop’un JobControl sınıfını kullanmaya kalkmış. Bir takım da Ant’ı kullanmayı denemiş. Bu girişimlerin ortak sıkıntıları hata takibi zorluğu ve hatadan arındırma zorluğu.

Oozie Hadoop görevleri haricindeki görevleri de icra edebilir örneğin java sınıfı ve shell scripti.

Oozie Hadoop görevleri için bir orkestrasyon sistemidir. Oozi görevleri istendiğinde veya priyodik olarak çağrılır. İstendiğinde çağrılanlara iş akış görevi (workflow job) Periyodik olarak çağrılan görevlere ise koordinatör görevler (coordinator jobs) denir. Üçüncü bir görev tipi ise paket görevler (bundle jobs) denir. Paket görevler bazı koordinatör görevlerin bir araya toplanıp paket haline getirilmesiyle oluşur ve tek bir görev olarak icra edilir.

Hadoop 1.0’de jobtracker kavramı Hadoop 2.0’de değişti bu sebeple Oozie’de jobtracker kavramının karşılığında Hadoop 2.0 sistemlerinde resourcemanager olarak düşünmek gerekir.

Oozie sürüm yükseltmeleri geriye dönük uyumludur,. Sürüm yükseltmek basit ve kolaydır.

Yahoo Oozie’nin en büyük kullanıcısıdır. Yahoo’nun bir kaç Hadoop clusterında 40.000 civarında sunucu var. Oozie bu ortamın ana iş akış motoru (workflow engine). Oozie ayda 30 milyona yakın Hadoop görevi yaptırıyor. En büyük hadoop clusterında 60 paket ve 1600 koordinatör var bunlar günde 80.000 iş akışına denk geliyor. Bu görevlerin bir çoğu periyodik görevler.

Bu yazıda iş akışı (workflow), koordinatör ve paket görevler (bundle jobs) hakkında temel konsept ve bu kavramların birbiriyle ilişkileri üzerinde durulacaktır.

Oozie Uygulamaları (Oozie Applications)

Oozie uygulamalarını Unix’in çalıştırılabilir dosyalarına, görevlerini ise Unix’in processlerine benzetebiliriz. oozie’de bir uygulamanın geliştirilip çalıştırılmasına bir Oozie görevi (Oozie job) denir.

Oozie İş Akışları (Oozie Workflows)

Bir Oozie iş akışı çok kademeli bir Hadoop görevidir. İş akışı, eylem (action) ve kontrol düğümlerinin güdümlü döngüsüz diyagram (DAG – directed acyclic graph) içinde düzenlenmiş halidir. Düğümlerin sıralaması işlerin yapılış sıralamasını da belirler. Bir iş bitmeden diğeri başlamaz. Kontrol düğümleri ise aynen trafik polisi gibi iş akışını düzenler. Bazı kontrol düğümleri; başlama, bitiş, birleştir, çatallaştır (fork). İş akışları güdümlü döngüsüz diyagram olduğundan adı üstünde döngüleri desteklemez. Standart bir Oozie iş akış şeması aşağıdadır.

Oozie iş akışı için örnek bir kullanım senaryosu: Mobil kullanıcıların telefonlarındaki bir uygulamanın kullanımına dair iz kayıtları (log) bir sunucuya gönderiliyor. Bu bilgiler arasında, uygulama ile etkileşim kurulan tarih zaman, kullanıcı adı ve coğrafi koordinatlar bulunuyor. İz kayıtları sunucularda günlük olarak toplanıyor. Biz bir güne dair şu bilgileri bu izkayıtlarından edinmek istiyoruz:

  • ZIP kodu,
  • Kullanıcı başı etkileşim
  • ZIP kodu başına kullanıcı etkileşimi

İstediğimiz bilgiler doğrudan iz kayıtları arasında istediğimiz formatta bulunmadığı için bazı dönüşümler yapmak gerekiyor. Örneğin coğrafi koordinatı ZIP koduna dönüştürmek gibi. Bu dönüşüm to-ZIP MapReduce göreviyle yapılsın. Bu görevin girdileri; timeStamp, geoLocation ve userName Bu görevin çıktıları: ZIP, userName ve interactions olacaktır. Bu çıktıyı kullanarak iki ilave MapReduce görevi ile user-ZIPs ve user-interactions görevleri çalışacaktır. İz kayıtlarından ilgili bilgilerin toplanmasına dair örnek iş akış şeması aşağıdadır. İş akışının adı: daily-logs-workflow

Oozie Koordinatörler (Coordinators)

Bir Oozie koordinatörü başlama zamanı ve tekrarlanma sıklığı parametrelerine bağlı olarak iş akışını çizelgelendirir. Koordinatör başlangıç zamanından bitiş zamanına kadar belirlenen sıklıkta çalışmaya devam eder. Örneğin; her gün saat 14.00’dan 15.00’a kadar her beş dakikada bir çalış. Örnek bir koordinatör çalışma şeması aşağıdadır.

Koordinatör çalışmaya başlamadan önce gerekli girdi verinin hazır olup olmadığını kontrol eder. Hazır değilse bekler, veri hazır olunca gecikmeli olarak çalışır. Verinin hazır olmasını beklemek için bir süre sınırı tanınabilir. Eğer veri girişi yoksa koordinatör tamamen zamana bağlı olarak çalışır. Koordinatörün çalışma örneğine, iş akışındaki daily-logs-workflow isimli iz kayıtlarını toplayan istenen formata dönüştüren iş akış görevinin günlük olarak çizelgelendirilmesini verebiliriz.

Oozie Paketleri (Bundles)

Oozie paketi, bir küme koordinatörün bir görev haline getirilerek hep beraber başlatma, bitirme veya düzenlenebilmesine olanak sağlayan koordinatörler grubuna verilen adıdır. Bu paketteki koordinatörler doğal olarak birbirine bağlıdır. Bir koordinatörün ürettiği çıktı başka bir koordinatöre girdi olabilir. Bu tür birbirine karşılıklı bağımlı olan koordinatörlere veri akış hattı (data pipeline) denir.

Oozie paket örnek kullanımı: Yukarıdaki günlük log toplama işinden devam ederek örnek verelim. Koordinatör günlük olarak logları kaynaktan alıp, dönüştürüp hedef dizine ayrı ayrı yazıyordu. Paket örneğimizde günlük log toplama işinin haftalık ve aylık olarak içinde bazı hesaplamalar yapılarak gerçekleştirilmesini ekleyelim. Bunun için yeni bir iş akışı ve koordinatör  gerekecektir. Toplamda üç tane koordinatörümüz olmuş oldu:daily-logs-coordinator, weekly-aggregator-coordinator ve monthly-aggregator-coordinator oldu. Bu üçünden oluşan paket de log-processing-bundle olsun.

Parametreler, Değişkenler ve Fonksiyonlar

Bir çok görev çalışırken parametre alır. Örneğin girdi ve çıktı dosya yolları. İş akışı, koordinatör ve paketler gibi her tür Oozie görevi parametre alabilir.  Örneğin günlük olarak logları işleyen bir koordinatör görevi bir önceki güne ait logları nereden alacağına dair bir parametreye ihtiyaç duyar. Basit bir Oozi görevinde job.properties dosyasında parametreler tanımlanır. Örneğin nameNode. Değişkenler ise parametreleri uygulamada tanımlamamızı sağlar. Örneğin workflow.xml dosyasındaki \${nameNode}. Fonksiyonlar ise görev çalışırken değişkenin çözümlenmesine yardım eder. Örneğin \${hadoop:counters(‘ident,ty-MR’)} fonksiyonu MapReduce görevinin sayaç bilgisini dönderir 🙂

Uygulama Dağıtım Modeli (Application Deployment Model)

Bir Oozie uygulaması uygulamanın mantığını açıklayan bir doya ile beraber JAR dosyaları, konfigürasyon dosyaları ve scriptlerden oluşur. Bir iş akış uygulaması ise workflow.xml dosyası, konfigürasyon dosyası, Pig scriptleri, Hive scriptleri, JAR dosyaları ve diğer dosyalardan oluşur. Koordinatör uygulamaları coordinator.xml, paket uygulamalar ise bundle.xml dosyalarından oluşur. Oozie uygulamalarında dizin yapısı ve formatı önemlidir. Ayrıca birbiriyle ilişkili görevlere sahip uygulamalarda göreceli dosya yolu kullanmak önemlidir. Bu kullanım, uygulamanın kolaylıkla dizin değiştirmesine olanak sağlar. JAR dosyaları lib klasörü içinde olmalıdır. Bu klasördeki JAR dosyaları uygulama çalışırken Oozie tarafından otomatik olarak sınıf yoluna dahil edilir.

Oozie Mimarisi

Oozie çalıştığında uygulamayı tarif eden bir XML dosyası okumaya çalışır. Diğer tüm dosyaları HDFS’de bulmayı bekler. Bu sebeple görev çalışmadan önce uygulama dosyalarını HDFS’e kopyalamak gerekir. Oozie sunucusu, Java servlet container içine koşan bir java web uygulamasıdır. Varsayılan olarak Java servlet teknolojisinin açık kaynak projesi olan Apache Tomcat kullanır. Oozie ile etkileşime geçmenin üç yolu vardır:

  • Oozie komut satırı aracı
  • Oozie Java client API
  • Oozie HTTP REST API

İlk ikisi; Oozie sunucusu ile konuşmak için nihayetinde HTTP REST API kullanır. Oozie sunucusu durum bilgisi turmaz. Tüm koşan işler ilişkisel bir veri tabanında tutulur. Görevlerle ilgili durum bilgileri olduğu gibi bu veri tabanındadır. O yüzden web sunucu göçse bile geri dönmesi kolaydır. Dört veri tabnını destekler: Derby, MySQL, Oracle ve PostgreSQL.

Görüşmek dileğiyle…

Yazar Hakkında
Toplam 177 yazı
Erkan ŞİRİN
Erkan ŞİRİN
10 yılı aşkın süredir yurtiçi ve yurtdışında sektörde büyük veri mühendisliği, platform yönetimi ve makine öğrenmesi ile ilgili çalışmalar yürütmekte ve aynı zamanda birçok kurum ve şirkete danışmanlık ve eğitimler vermektedir. Çalışma alanları: Data ve MLOps platformları, gerçek zamanlı veri işleme, değişen veriyi yakalama (CDC) ve Lakehouse.
Yorumlar (Yorum yapılmamış)

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

×

Bir Şeyler Ara