Nota prawna: Jestem uczestnikiem Apache Flink i członkiem PMC, który zna tylko zaawansowany projekt Storma, a nie jego elementy wewnętrzne.
Apache Flink to platforma do ujednoliconego przetwarzania strumieniowego i przetwarzania wsadowego. Środowisko wykonawcze Flink natywnie obsługuje obie domeny z powodu potokowanych transferów danych między równoległymi zadaniami, które obejmują tasowanie potokowe. Rekordy są natychmiast wysyłane z zadań produkcyjnych do zadań odbieranych (po zebraniu bufora do transferu sieciowego). Zadania wsadowe można opcjonalnie wykonywać za pomocą blokowania przesyłania danych.
Apache Spark to framework obsługujący przetwarzanie wsadowe i strumieniowe. Interfejs API wsadu Flink wygląda dość podobnie i odnosi się do podobnych przypadków użycia, takich jak Spark, ale różni się w wewnętrznych. W przypadku przesyłania strumieniowego oba systemy stosują bardzo różne podejścia (mini-partie a streaming), dzięki czemu nadają się do różnych zastosowań. Powiedziałbym, że porównywanie Spark i Flink jest poprawne i użyteczne, jednak Spark nie jest najbardziej podobnym do Flinka procesem przetwarzania strumienia.
Przechodząc do pierwotnego pytania, Apache Storm jest procesorem strumienia danych bez funkcji przetwarzania wsadowego. W rzeczywistości, silnik potoku Flink wygląda wewnętrznie podobnie jak Storm, tzn. Interfejsy równoległych zadań Flink są podobne do rygli Storma. Storm and Flink mają wspólną cechę, że dążą do przetwarzania strumienia o małym opóźnieniu przez przesyłanie danych potokowych. Jednak Flink oferuje bardziej zaawansowane API w porównaniu do Storm. Zamiast implementować funkcjonalność śrub z jednym lub większą liczbą czytników i kolektorów, Flink's DataStream API udostępnia funkcje takie jak Map, GroupBy, Window i Join. Duża część tej funkcjonalności musi zostać ręcznie zaimplementowana podczas korzystania z usługi Storm. Kolejną różnicą jest przetwarzanie semantyki. Storm gwarantuje co najmniej jednokrotne przetwarzanie, podczas gdy Flink zapewnia dokładnie jeden raz. Implementacje, które dają te gwarancje przetwarzania, różnią się nieco. Podczas gdy Storm używa potwierdzeń na poziomie rekordu, Flink używa wariantu algorytmu Chandy-Lamport. W skrócie, źródła danych okresowo wprowadzają znaczniki do strumienia danych. Kiedy operator otrzymuje taki znacznik, sprawdza jego stan wewnętrzny. Kiedy znacznik został odebrany przez wszystkie pochłaniacze danych, znacznik (i wszystkie rekordy, które zostały wcześniej przetworzone) zostały zatwierdzone. W przypadku awarii wszystkie operatory źródeł są resetowane do stanu, gdy zobaczyły ostatni zatwierdzony znacznik i przetwarzanie jest kontynuowane. To podejście oparte na punktach kontrolnych jest bardziej lekkie niż potwierdzenia rekordów Storma. Ten slide set i odpowiadający mu talk omawiają sposób przetwarzania strumieniowego Flink, obejmujący tolerancję błędu, punkt kontrolny i obsługę stanu.
Storm oferuje również dokładnie jednokrotne API wysokiego poziomu o nazwie Trident. Jednak Trident opiera się na mini-partiach, a więc bardziej przypomina Spark niż Flink.
Regulowane opóźnienie migotania odnosi się do sposobu, w jaki funkcja Miga wysyła rekordy z jednego zadania do drugiego. Powiedziałem wcześniej, że Flink wykorzystuje przesyłanie danych potokowych i przekazuje rekordy natychmiast po ich wyprodukowaniu. W celu uzyskania efektywności te zapisy są gromadzone w buforze, który jest przesyłany przez sieć, gdy jest pełny lub określony próg czasowy jest spełniony. Ten próg kontroluje opóźnienie rekordów, ponieważ określa maksymalny czas pozostania rekordu w buforze bez przesłania go do następnego zadania. Nie można jednak jej użyć do udzielenia twardych gwarancji co do czasu, w jakim rekord wchodzi do opuszczenia programu, ponieważ zależy to również od czasu przetwarzania w ramach zadań i liczby transferów sieciowych między innymi.
Zauważ, że Apache * Spark * (przedmiotem połączonym pytanie) nie jest taka sama jak Apache * Burza * (To pytanie tutaj) - tak, nie, to nie jest bynajmniej duplikat. – fnl