Flink ve Storm arasındaki temel farklar nelerdir?


137

Flink, gördüğüm gibi yanlış bir karşılaştırma olan Spark ile karşılaştırıldı, çünkü pencereli bir olay işleme sistemini mikro yığınlarla karşılaştırıyor; Benzer şekilde, Flink ile Samza'yı karşılaştırmak benim için pek mantıklı değil. Her iki durumda da, Samza örneğinde daha küçük bir “ölçekte” bile olsa, gerçek zamanlı ve toplu olay işleme stratejisini karşılaştırır. Ama Flink'in kavramsal olarak ona çok daha benzeyen Fırtına ile nasıl karşılaştırıldığını bilmek istiyorum.

Flink için ana farkı "ayarlanabilir gecikme" olarak belgeleyen bunu (Slayt # 4) buldum . Başka bir ipucu, Slicon Angle'ın Flink'in bir Spark veya HadoopMR dünyasına daha iyi entegre olduğunu gösteren bir makale gibi görünüyor , ancak gerçek detaylardan bahsedilmiyor veya referans verilmiyor. Son olarak, Fabian Hueske kendisi notları bir röportajda "Flink akışı analizi işlevselliği üst düzey bir API sunar ve tam olarak-once işleme teminat. Sağlamak için daha hafif hata toleransı stratejisini kullanır Apache Fırtına kıyasla" olduğunu

Bütün bunlar benim için biraz seyrek ve tam olarak anlamıyorum. Birisi fırtınada akış işleme ile hangi problem (ler) Flink tarafından tam olarak çözüldü açıklayabilir misiniz? Hueske, API sorunları ve "daha hafif hata tolerans stratejisi" ne değinmektedir?


2
Apache Spark'ın (bağlantılı sorunun odağı) Apache Storm (buradaki soru) ile aynı olmadığını unutmayın - yani, hayır, bu kesinlikle bir kopya değildir.
fnl

Yanıtlar:


213

Feragatname : Ben bir Apache Flink komutanı ve PMC üyesiyim ve sadece Storm'un üst düzey tasarımına aşinayım.

Apache Flink, birleşik akış ve toplu işlem için bir çerçevedir. Flink'in çalışma zamanı, ardışık düzen karışıklıkları içeren paralel görevler arasında ardışık veri aktarımları nedeniyle her iki etki alanını da yerel olarak destekler. Kayıtlar, görev üretmekten görev almaya (ağ aktarımı için bir arabellekte toplandıktan sonra) hemen gönderilir. Toplu işler isteğe bağlı olarak veri aktarımlarını engelleme kullanılarak yürütülebilir.

Apache Spark, toplu iş ve akış işlemeyi de destekleyen bir çerçevedir. Flink'in toplu API'si oldukça benzer görünüyor ve Spark ile benzer kullanım durumlarını ele alıyor, ancak dahili olarak farklı. Akış için, her iki sistem de onları farklı uygulamalar için uygun kılan çok farklı yaklaşımları (mini gruplar arası akış) izler. Spark ve Flink'i karşılaştırmanın geçerli ve kullanışlı olduğunu söyleyebilirim, ancak Spark, Flink'e en benzer akış işleme motoru değil.

Orijinal soruya gelen Apache Storm, toplu iş yetenekleri olmayan bir veri akışı işlemcisidir. Aslında, Flink'in boru hattı motoru dahili olarak Storm'a biraz benziyor, yani Flink'in paralel görevlerinin arayüzleri Storm'un cıvatalarına benziyor. Storm ve Flink ortak olarak boru hatlı veri aktarımlarıyla düşük gecikmeli akış işlemeyi hedefliyorlar. Ancak Flink, Storm'a kıyasla daha yüksek seviyeli bir API sunuyor. Bir veya daha fazla okuyucu ve toplayıcı içeren bir cıvatanın işlevselliğini uygulamak yerine, Flink'in DataStream API'sı Harita, GroupBy, Pencere ve Birleştirme gibi işlevler sağlar. Bu işlevselliğin birçoğu Storm kullanılırken manuel olarak uygulanmalıdır. Diğer bir fark işleme semantiği. Fırtına en az bir kez işlemeyi garanti ederken, Flink tam bir kez sağlar. Bu işleme garantilerini veren uygulamalar biraz farklıdır. Storm rekor düzeyde alındı ​​bildirimlerini kullanırken, Flink Chandy-Lamport algoritmasının bir varyantını kullanır. Özetle, veri kaynakları düzenli olarak veri akışına işaretleyiciler enjekte eder. Bir operatör böyle bir işaretleyici aldığında, dahili durumunu kontrol eder. Tüm veri havuzları tarafından bir işaretleyici alındığında, işaretçi (ve daha önce işlenmiş olan tüm kayıtlar) işlenir. Bir arıza durumunda, tüm kaynak operatörleri son taahhüt edilen işaretçiyi gördüklerinde durumlarına sıfırlanır ve işleme devam edilir. Bu işaretçi kontrol noktası yaklaşımı, Storm'un rekor seviye onaylarından daha hafiftir. Bu veri kaynakları düzenli olarak veri akışına işaretleyiciler enjekte eder. Bir operatör böyle bir işaretleyici aldığında, dahili durumunu kontrol eder. Tüm veri havuzları tarafından bir işaretleyici alındığında, işaretçi (ve daha önce işlenmiş olan tüm kayıtlar) işlenir. Bir arıza durumunda, tüm kaynak operatörleri son taahhüt edilen işaretçiyi gördüklerinde durumlarına sıfırlanır ve işleme devam edilir. Bu işaretçi kontrol noktası yaklaşımı, Storm'un rekor seviye onaylarından daha hafiftir. Bu veri kaynakları düzenli olarak veri akışına işaretleyiciler enjekte eder. Bir operatör böyle bir işaretleyici aldığında, dahili durumunu kontrol eder. Tüm veri havuzları tarafından bir işaretleyici alındığında, işaretçi (ve daha önce işlenmiş olan tüm kayıtlar) işlenir. Bir arıza durumunda, tüm kaynak operatörleri son taahhüt edilen işaretçiyi gördüklerinde durumlarına sıfırlanır ve işleme devam edilir. Bu işaretçi kontrol noktası yaklaşımı, Storm'un rekor seviye onaylarından daha hafiftir. Bu son kaynak işaretçisini gördüklerinde ve işlemeye devam edildiğinde tüm kaynak operatörleri durumlarına sıfırlanır. Bu işaretçi kontrol noktası yaklaşımı, Storm'un rekor seviye onaylarından daha hafiftir. Bu son kaynak işaretçisini gördüklerinde ve işlemeye devam edildiğinde tüm kaynak operatörleri durumlarına sıfırlanır. Bu işaretçi kontrol noktası yaklaşımı, Storm'un rekor seviye onaylarından daha hafiftir. Buslayt seti ve ilgili konuşma Flink'in hata toleransı, kontrol noktası ve durum işleme dahil akış işleme yaklaşımını tartışır.

Storm aynı zamanda Trident adında bir kez daha yüksek seviyeli bir API sunar. Ancak, Trident mini partilere dayanıyor ve bu nedenle Spark'a Flink'ten daha benziyor.

Flink'in ayarlanabilir gecikmesi, Flink'in kayıtları bir görevden diğerine gönderme yolunu ifade eder. Daha önce de söylemiştim, Flink hazır veri aktarımlarını kullanıyor ve üretilir üretilmez kayıtları iletiyor. Verimlilik için, bu kayıtlar, dolduğunda veya belirli bir zaman eşiği karşılandığında ağ üzerinden gönderilen bir tamponda toplanır. Bu eşik, kayıtların gecikmesini kontrol eder, çünkü bir kaydın bir sonraki göreve gönderilmeden arabellekte kalacağı maksimum süreyi belirtir. Ancak, bir kaydın bir programdan ayrılmasına kadar geçen süre hakkında kesin garantiler vermek için kullanılamaz, çünkü bu aynı zamanda görevler içindeki işlem süresine ve diğer şeylerin yanı sıra ağ aktarımlarının sayısına da bağlıdır.


2
Gerçekten çok teşekkür ederim! Belki bir açık nokta, sizi bir kez daha rahatsız edebilirsem: Bu "ayarlanabilir gecikme" sorunu ne hakkında? Bu, farklı uygulama alanlarının bu açıdan farklı gereksinimleri olacağı göz önüne alındığında oldukça alakalı görünmektedir. Bunun ne anlama geldiğini en azından Flink açısından açıklayabilir misiniz?
fnl

6
Elbette cevabımı uzattım ve ayarlanabilir gecikmeyi tartıştım. Başka sorularınız varsa bana bildirin.
Fabian Hueske

Flink, örneğin Erlang kullanarak gerçekleştirilebileceği için DAG iş akışında "sıcak" değişikliklere izin veriyor mu? IE. Çalışma sırasında DAG değiştirilebilir mi?
Thomas Browne

1
Etkin kod değişimi mümkün değil. Ancak, uygulamanın durumunu kayıt noktası olarak devam ettirebilirsiniz. Kayıt noktası değiştirilmiş bir uygulamayı başlatmak için kullanılabilir. Bu, orijinal uygulama hala çalışırken, çıktının bir noktada çevrilebileceği şekilde yapılabilir. Mevcut bir kayıt noktasından devam ettirilirken uygulamaların keyfi olarak değiştirilemeyeceğini unutmayın.
Fabian Hueske

1
Flink'in ilginç ve büyük avantajı, Apache Beam'i daha yüksek seviyeli API ile çalıştırabilmektir. Beam için en zengin ve eksiksiz koşuculardan biri.
Piotr Gwiazda

47

Fabian Hueske'nin cevabına ek olarak:

Flink, Storm üzerinde ek olarak aşağıdaki şekillerde de iyileşir:

  • Geri basınç: Farklı operatörler farklı hızlarda çalıştığında Flink'in akış çalışma zamanı iyi davranır, çünkü aşağı akış operatörleri, yukarı akış operatörlerini çok iyi bir şekilde basınçlandırır, ancak ağ katmanı arabellek havuzlarını yönetir.

  • Kullanıcı tanımlı durum: Flink, programların operatörlerinizdeki özel durumu korumasına izin verir. Bu durum, özel olarak kullanıcı tanımlı durum için tam olarak bir kez garanti vererek, hata toleransı için kontrol noktasına gerçekten katılabilir. Veri akışı ile birlikte sürekli olarak kontrol edilen, bir operatör içindeki kullanıcı tanımlı durum makinesi örneğine bakın .

  • Akış Pencereleri: Akış pencereleme ve pencere toplamaları, veri akışlarını analiz etmek için çok önemli bir yapı taşıdır. Flink, birçok pencere türünü destekleyen oldukça güçlü bir pencere sistemi ile birlikte gelir.


2
İlk noktanızla ilgili olarak, Fırtına, 1.0 itibariyle geri basınç altında iyi davranıyor (Nisan 2016'da çıktı)
Colin Nichols

Fırtına karşı basıncı "spout_max_pending" özelliği kullanılarak azaltılabilir. Onay bekleyen bir musluğun içinde bulunabilecek maksimum tuples için bir eşik belirler. Ağız, ack gerçekleşene kadar ilerleyen tuples tüketmeyecektir.
Aman Garg

3

Fırtına ve Flink deneyimlerime dayanarak. Bu araçların aynı sorunu farklı yaklaşımlarla çözebileceğini hissediyorum. @Stephan Ewen tarafından bahsedilen Flink'in her özelliği şimdi Storm tarafından dahili API (ör. Parçaları ve cıvatalar ) ve Trident API ile eşleştirilebilir . Birisi, Trident'in mini-toplu tarzı olduğunu iddia ederken, devletle veya toplulaştırmaya sahip karmaşık uygulamaların çoğunun sadece pencere stiliyle toplu işleme bağlı olabileceğini düşünüyorum. Bu yüzden burada hangisinin daha iyi olduğunu söylemeden bazı temel farklılıkları listeliyorum.

  • Geliştirme tarzı . Flink'te bilgi işlem odaklı (örneğin zincirlenebilir operatör) ve Storm'da veri akışı odaklı (örn addSpolt()/addBolt().).
  • Yüksek seviye API . Flink'teki işlevler (örn. Harita, Pencere, Akış düzeyine katıl), Yerel Pencere ve Fırtınada Trident.
  • Garantili mesaj işleme (GMP. Yani, bir kerede ) . Harici durum makinesiyle veya Fırtınada Trident ile Flink'e Karşı İki Fazlı Komple Konnektörlü Kontrol Noktası (örn. KafkaConsumer).
  • Hata toleransı . Flink'te işaretçi kontrol noktası, Fırtınada kayıt düzeyi-ACK'ya karşılık.
  • İç mimari . Flink'teki basit soyutlama ve göreceli paralellik (ör., CPU çekirdeği ile değerlendirilen her iş parçacığı için yuva) ve Çok katmanlı soyutlamaların (örneğin, denetleyicide çalışan ve her bir denetçinin her bir JVM için yuvada birçok çalışanı olabilir) Fırtınada.

3

Feragatname: Ben, Storm ve (yakında) Flink'in büyük destekçisi Cloudera'nın bir çalışanıyım.

fonksiyonel

Birçok iyi teknik nokta zaten sunulmuştur. Vurgulananların kısa bir özeti:

  • Hem Flink hem de Storm olay başına işlem yapabilir
  • Storm, olay zamanını kutudan çıkarıyor gibi görünmüyor
  • Storm, SQL desteğini deneme aşamasından kaldırmadı

Sigara Fonksiyonel

  • Birçok müşteri Fırtına (kullanımı) zor
  • Fırtınanın benimsenmesi yavaşladı ve Flink topluluğu artık Fırtına'dan daha aktif görünüyor
  • Flink'in hala yapması gereken bazı şeyler var (örneğin belgelenmiş örnekler), ancak genel olarak aklınıza gelebilecek hemen hemen her alanda yakalandı

Sonuç

Cloudera son zamanlarda Fırtına'nın (HDP'de) kullanımdan kaldırıldığını duyurdu. Ve aynı anda Flink halefi olarak ilan edildi.

Yani, fırtınada kullanımınız varsa, elbette çalışmaya devam edecekler. Ancak yeni kullanımlar için Flink veya diğer akış motorlarına bakarım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.