Fırtına tanıtımı ve Spark Streaming ile karşılaştırma
Ocak büyük veri
1 Fırtınaya Giriş
Storm, Twitter tarafından açık kaynaklı, dağıtılmış, yüksek hataya dayanıklı gerçek zamanlı bir işlem sistemidir. Ortaya çıkışı, sürekli akış hesaplamayı kolaylaştırır ve Hadoop toplu işlemenin karşılayamayacağı gerçek zamanlı gereksinimleri telafi eder. Storm genellikle gerçek zamanlı analiz, çevrimiçi makine öğrenimi, sürekli bilgi işlem, dağıtılmış uzaktan aramalar ve ETL'de kullanılır.
Storm kümesinde iki tür düğüm vardır: kontrol düğümü (Ana Düğüm) ve çalışan düğümü (İşçi Düğümü). Nimbus adı verilen bir süreç, kaynak tahsisi ve durum izleme için kullanılan kontrol düğümünde çalışır; her çalışan düğümü, makinesine atanan işi izleyen ve iş sürecini gerektiği gibi başlatan / durduran bir Denetleyici sürecini çalıştırır. Fırtına kümesi mimarisi aşağıdaki şekilde gösterilmektedir:
Şekil 1 Fırtına kümesi mimarisi
Fırtına kümesindeki her bileşen şu şekilde açıklanmıştır:
l Nimbus: Kümede kod göndermekten, makinelere iş atamaktan ve durumu izlemekten sorumlu, kümede Hadoop'taki JobTracker'a benzeyen yalnızca bir tane var.
l ZooKeeper: Storm'un büyük ölçüde dayandığı harici kaynaklar. Nimbus, Supervisor, Worker, vb. tümü, kalp atışı verilerini ZooKeeper'da depolar. Nimbus ayrıca, ZooKeeper'daki kalp atışına ve görev çalıştırma durumuna göre görevleri planlar ve dağıtır.
l Süpervizör: Çalışan düğümde, atanan görevleri izleyin ve gerektiği şekilde çalışan sürecini başlatın veya kapatın. Storm'u çalıştırmak için her makinede bir Süpervizör çalıştırın ve makinenin yapılandırmasına göre yukarıda tahsis edilen yuva sayısını ayarlayın.
l Worker: Supervisor'da oluşturulan bir JVM örneği, Executor Worker'da çalışır ve Executor, Task için bir konteyner olarak çalışır.
l Yürütücü: Görevin çalışma zamanında bulunduğu ve Yürütücüdeki Görevin işleme mantığını yürüttüğü doğrudan kapsayıcı. Bir veya daha fazla Yürütme örneği aynı Çalışan işleminde çalışabilir ve bir veya daha fazla Görev, aynı Yürütücüde çalıştırılabilir; çalışan işlem paralelliği temelinde, Yürütücü paralelleştirilebilir ve Görev, Yürütücüye dayalı paralel hesaplama da uygulayabilir
l Görev: Çalışma zamanında Spout / Bolt tarafından görüntülenen varlıklara Görevler denir.Bir Spout / Bolt, çalışma zamanında bir veya daha fazla Spout Görevine veya Cıvata Görevine karşılık gelebilir ve bu, Topoloji yazılırken gerçek konfigürasyonla ilgilidir. Storm 0.8'den sonra, Görev artık fiziksel bir iş parçacığına karşılık gelmez Aynı Spout Görevi veya Bolt Görevi, Executor adı verilen fiziksel bir iş parçacığını paylaşabilir.
Storm'un çalıştırması için gönderdiği programa Topoloji adı verilir ve işlediği en küçük mesaj birimi, rastgele nesneler dizisi olan bir Tuple'dır. Topoloji Spout ve Bolt'tan oluşur. Spout, Tuple'ı gönderen düğümdür.Cıvt, Bolt tarafından isteğe bağlı olarak gönderilen belirli bir Spout veya Tuple'a abone olabilir. Aşağıdaki şekil, Topology tarafından tasarlanan bir mantık diyagramı örneğidir:
Şekil 2 Topoloji tasarımının mantık diyagramı
l Topoloji: Topoloji kavramı, Hadoop'taki MapReduce işine benzer. Bir dizi hesaplama mantığı bileşenini (Spout, Bolt) düzenlemek ve barındırmak için kullanılan bir nesnedir (Hadoop MapReduce'daki bir iş, bir dizi Harita görevi ve Azaltma görevini içerir). Grup hesaplama bileşenleri, daha sorumlu bir hesaplama mantığı nesnesi, yani Topoloji oluşturmak için DAG diyagramları (veri akışı dağıtımının akışını kontrol etmek için Akış Gruplamaları seçilerek) şeklinde düzenlenebilir. Bir Topoloji çalıştıktan sonra durdurulamaz.Manuel müdahale (bin / fırtına öldürmenin açık bir şekilde yürütülmesi) veya beklenmedik bir hata (kapatma veya tüm Fırtına kümesinin kapanması gibi) ile sonlandırılmadığı sürece süresiz olarak çalışacaktır.
l Spout: Spout, Topology'nin mesaj üretiminin kaynağıdır. Spout, sürekli olarak mesaj üreten bir bileşendir.Örneğin, harici İstemci bağlantılarını dinleyen ve mesajlar gönderen bir Soket Sunucusu olabilir veya bir mesaj kuyruğu (MQ) tüketimi olabilir. Flume Agent'ın havuzu vb. Tarafından gönderilen mesajları almak için kullanılan bir hizmet olabilir. Spout tarafından üretilen mesajlar, Tuples in Storm olarak soyutlanır.Tüm Topolojinin birden fazla hesaplama bileşeni, bir akış oluşturmak için gerektiğinde soyut olarak oluşturulmuş Tuple mesajlarıyla birbirine bağlanır.
l Bolt: Storm'daki mesaj işleme mantığı Bolt bileşeninde kapsüllenmiştir.Herhangi bir işleme mantığı Bolt'ta yürütülebilir. İşleme süreci sıradan hesaplama uygulamalarından farklı değildir.Sadece Storm'un hesaplama anlamlarına göre bileşenlerin makul bir şekilde ayarlanması gerekir. Mesaj akışının bildirimi, dağıtımı ve bağlantısı yeterlidir. Bolt, bir veya daha fazla Spout'tan Tuple mesajlarını, diğer Cıvatalardan Tuple mesajlarını veya Spout ve diğer Boltların bir kombinasyonu ile gönderilen Tuple mesajlarını alabilir.
l Akış Gruplaması: Storm, çeşitli hesaplama bileşenleri (Spout ve Bolt) arasındaki akışların bağlantısını, gruplandırmasını ve dağıtım ilişkilerini tanımlamak için kullanılır. Storm, aşağıdaki 7 dağıtım stratejisini tanımlar: Karışık Gruplama (rastgele gruplama), Alan Gruplama (alana göre gruplama), Tüm Gruplama (yayın gruplama), Küresel Gruplama (küresel gruplama), Gruplamasız (gruplama değil), Doğrudan Gruplama (doğrudan gruplama) ), Yerel veya Karışık Gruplama (yerel / rastgele gruplama), çeşitli stratejilerin özel anlamı, anlaşılması daha kolay olan resmi Storm belgelerine başvurabilir.
Storm'da veriler, basit seri veya birden çok akış işleminin kombinasyonu yoluyla işlenebilir:
l Fırtına bileşenleri basit seridir
Bu yöntem en basit ve en sezgiseldir, Storm bileşenlerini (Spout veya Bolt) serileştirdiğimiz sürece, yalnızca bu bileşenleri yazmanın temel yöntemini anlamamız gerekir. Pratik uygulamalarda, belirli bir veri kaynağından sürekli olarak mesaj almamız ve ardından her bir talebi sırayla işlememiz gerekirse, işlemek için bu seri yöntemi kullanabiliriz. İşlem biriminin mantığı çok karmaşıksa, işlem mantığının ayrılması gerekir ve aynı tip işleme ait olan mantık, bileşenler arasında zayıf bir bağlantı elde etmek için bir işleme bileşeni içinde kapsüllenir.
Şekil 3 Storm bileşenlerinin basit serileştirilmesi
l Fırtına, birden fazla akış işlemini birleştirir
Storm, birleştirilmiş işleme için birden çok bileşenden gelen verileri aynı işleme bileşeninde toplayabilen akış toplama işlemlerini destekler. Akış yoluyla birden fazla Spout bileşenini tek bir Bolt bileşeninde toplayabilir (Sout'tan Cıvata çoktan bire, çoktan çoğa işlemler) Ayrıca, akış yoluyla birden fazla Cıvatanın başka bir Cıvata bileşenine toplanabileceğini de fark edebilir (Cıvatadan Cıvataya çoktan bire, çoktan çoğa işlemler).
Şekil 4 Fırtına, çoklu akış işlemlerini birleştirir
Aşağıdaki şekil, Topolojinin gönderim akış şemasıdır:
Şekil 5 Topoloji gönderme akış şeması
1. İstemci, program jar paketini Nimbus arabirimi aracılığıyla Nimbus Gelen Kutusu dizinine yükler.Yükleme tamamlandıktan sonra, gönderme yöntemi aracılığıyla Nimbus'a bir Topoloji gönderin.
2. Nimbus Topology gönderim komutunu aldıktan sonra, alınan program jar paketini serileştirir ve serileştirilmiş sonucu Nimbus düğümünün stormdist dizinine koyar.Aynı zamanda, mevcut Storm çalışan konfigürasyonuyla bir stormconf.ser dosyası oluşturur. Bu dizine koyun. Statik bilgi ayarlandıktan sonra, görevler sinyal bilgisi aracılığıyla makine düğümlerine atanır. Topoloji ile ilişkili Muslukları ve Cıvataları ayarlarken, mevcut Musluğun ve Cıvatanın Yürütücü ve Görevlerinin sayısını aynı anda ayarlayabilirsiniz.Varsayılan olarak, bir Topolojinin görevlerinin toplamı Yürütücülerin toplamı ile aynıdır. Bundan sonra, sistem bu görevlerin yerine getirilmesini çalışan sayısına göre mümkün olduğunca eşit bir şekilde dağıtır. Çalışanın hangi Süpervizör düğümünde çalışacağı Storm tarafından belirlenir.
3. Görev tahsis edildikten sonra, Nimbus düğümü görev bilgilerini ZooKeeper kümesine gönderecektir.Aynı zamanda, ZooKeeper kümesinde, mevcut Topolojinin tüm çalışan işlemlerinin kalp atışı bilgilerini depolayan bir Çalışan gönderme düğümü olacaktır.
4. Süpervizör düğümü, ZooKeeper kümesini sürekli olarak sorgulayacaktır.Tüm Topoloji görev atama bilgileri, kod depolama dizinleri ve görevler arasındaki ilişki ZooKeeper gönderim düğümünde saklanır.Süpervizör, sorgulama yoluyla bu düğümün içeriğini toplar. Kendi görevi, çalıştırmak için İşçi sürecini başlatın.
5. Bir Topoloji çalıştıktan sonra, Spout aracılığıyla Akış akışlarını sürekli olarak gönderir ve alınan veri akışlarını Bolt aracılığıyla sürekli olarak işler.
2 Kıvılcım Akışı ve Fırtına Karşılaştırması
Storm ve Spark Streaming, dağıtılmış akış işleme için açık kaynaklı çerçevelerdir, ancak aralarında hala bazı farklılıklar vardır.Burada bunları karşılaştırıp önemli farklılıklarına işaret edeceğiz.
1. İşleme modeli ve gecikme
Bu iki çerçeve hem ölçeklenebilirlik hem de hata toleransı sağlasa da, işleme modelleri temelde farklıdır. Storm, her geçtiğinde bir olayı işlerken, Spark Streaming belirli bir zaman penceresi içinde olay akışlarını işler. Bu nedenle, bir olayı işleyen Storm, bir saniyenin altında bir gecikmeye ulaşabilirken, Kıvılcım Akışında ikinci bir gecikme olur.
2. Hata toleransı ve veri güvencesi
Hataya dayanıklı veri garantisinin değiş tokuşu açısından Spark Streaming, hataya dayanıklı durum hesaplaması için daha iyi destek sağlar. Storm'da, her kayıt sistemden geçerken izlenmelidir, böylece Storm en azından her kaydın bir kez işleneceğini garanti edebilir, ancak hatalardan kurtarma sırasında yinelenen kayıtlara izin verir, bu da değişken durumların mümkün olabileceği anlamına gelir. Yanlışlıkla iki kez güncellendi. Spark Streaming'in yalnızca toplu iş düzeyinde kayıtları izlemesi gerekir, böylece bir düğüm başarısız olsa bile her kaydın bir kez işleneceğini etkili bir şekilde garanti edebilir. Storm'un Trident kütüphanesi aynı zamanda eksiksiz bir tek seferlik işlem işlevi de sağlar. Ancak durumu güncellemek işleme bağlıdır ve bu işlem çok yavaştır ve genellikle kullanıcı tarafından uygulanmalıdır.
Kısacası, saniyenin altındaki gecikmelere ihtiyacınız varsa, Storm veri kaybı olmadan iyi bir seçimdir. Durum bilgisi içeren hesaplamalara ihtiyacınız varsa ve her olayın yalnızca bir kez işleneceğini tam olarak garanti etmek istiyorsanız, Spark Streaming daha iyidir. Spark Streaming programlama mantığı, özellikle toplu işlemleri (küçük de olsa) kullandığınızda toplu işlemeye benzer olduğu için daha kolay olabilir.
3. Uygulama ve programlama API'si
Storm esas olarak Clojure dili tarafından, Spark Streaming ise Scala tarafından uygulanmaktadır. Bu iki çerçevenin nasıl uygulandığını görmek istiyorsanız veya bir şeyi özelleştirmek istiyorsanız, bunu aklınızda bulundurmalısınız. Storm, BackType ve Twitter tarafından geliştirildi, Spark Streaming ise UC Berkeley'de geliştirildi.
Storm bir Java API sağlar, ancak diğer dillerdeki API'leri de destekler. Spark Streaming, Scala ve Java dillerini destekler (aslında Python'u da destekler). Ek olarak, Spark Streaming'in harika bir özelliği, Spark çerçevesinde çalışmasıdır. Bu şekilde, diğer toplu işlem kodları gibi Spark Streaming programları yazabilir veya Spark'ta etkileşimli olarak sorgulayabilirsiniz. Bu, ayrı akış toplu işleme programları ve geçmiş veri işleme programları yazma ihtiyacını azaltır.
4. Üretim Desteği
Fırtına uzun yıllardır etrafta dolaşıyor ve 2011'den beri Twitter'ın iç üretim ortamında ve diğer şirketlerde kullanılıyor. Spark Streaming yeni bir projedir ve yalnızca Sharethrough tarafından 2013 yılında kullanılmıştır (yazarın bildiği kadarıyla).
Storm, Hortonworks Hadoop veri platformunda akış işleme için bir çözümdür, Spark Streaming ise MapR'nin dağıtılmış platformunda ve Cloudera'nın kurumsal veri platformunda görünür. Ek olarak Databricks, Spark Streaming dahil olmak üzere Spark için teknik destek sağlayan bir şirkettir.
5. Küme yönetimi entegrasyonu
Her iki sistem de kendi kümelerinde çalışsa da, Storm ayrıca Mesos üzerinde çalışabilirken, Spark Streaming YARN ve Mesos üzerinde çalışabilir.
