У чому полягає основна відмінність між Flink та Storm?


137

Flink порівнювали зі Spark , що, як я бачу, є неправильним порівнянням, оскільки він порівнює віконну систему обробки подій з мікросеріями; Так само мені не має такого великого сенсу порівнювати Флінка з Самзою. В обох випадках вона порівнює стратегію обробки подій у режимі реального часу та пакетну обробку, навіть у меншій «шкалі» у випадку Samza. Але мені хотілося б знати, як Флінк порівнює зі Штормом, який концептуально здається набагато подібнішим до нього.

Я знайшов це (слайд №4), який документує основну відмінність як "регульовану затримку" для Flink. Іншим натяком, здається, є стаття Slicon Angle, яка передбачає, що Flink краще інтегрується у світ Іскри чи HadoopMR, однак жодних фактичних деталей не згадується та не згадується. Нарешті, сам Фабіан Хьюске в інтерв'ю зазначає , що "Порівняно з Apache Storm, функція потокового аналізу Flink пропонує API високого рівня та використовує більш легку стратегію відмовостійкості, щоб забезпечити рівномірну гарантію обробки".

Все це для мене трохи рідко, і я не дуже розумію цього. Чи може хтось пояснити, яку проблему (-и?) З потоковою обробкою в Storm (F?) Точно вирішує Flink? На що Hueske має на увазі проблеми API та їх "більш легку стратегію відмовостійкості"?


2
Зауважте, що Apache Spark (фокус пов'язаного питання) не такий, як Apache Storm (це питання тут) - так, ні, це аж ніяк не дублікат.
fnl

Відповіді:


212

Відмова : Я є виконавцем Apache Flink та членом PMC і лише знайомий з дизайном високого рівня Storm, а не з його внутрішнім середовищем.

Apache Flink - це основа для уніфікованої обробки потоку та пакетної обробки. Flink під час виконання обох доменів підтримує обидва домени завдяки конвеєрній передачі даних між паралельними завданнями, що включає переміщення в конвеєрному режимі. Записи негайно відправляються від створення завдань до прийому завдань (після того, як вони будуть зібрані в буфер для передачі мережі). Пакетні завдання можна необов'язково виконувати за допомогою блокування передачі даних.

Apache Spark - це структура, яка також підтримує пакетну та потокову обробку. Пакетний API Flink виглядає досить схожим і розглядає подібні випадки використання, як Spark, але відрізняється внутрішніми. Для потокової передачі обидві системи дотримуються дуже різних підходів (міні-партії проти потокової передачі), що робить їх придатними для різних програм. Я б сказав, що порівняння Spark і Flink є дійсним і корисним, однак Spark - не самий подібний движок обробки потоків для Flink.

Приходячи до початкового питання, Apache Storm - це процесор потоку даних без пакетних можливостей. Насправді конвеєрний двигун Flink всередині зовні трохи схожий на Storm, тобто інтерфейси паралельних завдань Flink схожі на болти Storm. Шторм і Flink мають спільне те, що вони спрямовані на обробку потоків з низькою затримкою за допомогою конвеєрних передач даних. Однак Flink пропонує більш високий рівень API порівняно з Storm. Замість того, щоб реалізувати функціональність болтів з одним або декількома читачами та колекторами, API DataStream Flink надає такі функції, як Map, GroupBy, Window та Join. Багато цього функціоналу потрібно вручну реалізувати при використанні Storm. Ще одна відмінність - це обробка семантики. Шторм гарантує хоча б один раз обробку, тоді як Flink забезпечує рівно один раз. Реалізації, які дають ці гарантії обробки, відрізняються зовсім небагато. У той час як Storm використовує підтвердження рівня запису, Flink використовує варіант алгоритму Chandy-Lamport. У двох словах, джерела даних періодично вводять маркери в потік даних. Щоразу, коли оператор отримує такий маркер, він перевіряє його внутрішній стан. Коли маркер отримав усі потоки даних, маркер (і всі записи, які раніше були оброблені), здійснюються. У разі відмови всі оператори джерела повертаються до свого стану, коли бачать останній здійснений маркер і обробка продовжується. Такий підхід до контрольно-пропускного пункту є легшим, ніж підтвердження рекордів Storm. Це джерела даних періодично вводять маркери в потік даних. Щоразу, коли оператор отримує такий маркер, він перевіряє його внутрішній стан. Коли маркер отримав усі потоки даних, маркер (і всі записи, які раніше були оброблені), здійснюються. У разі відмови всі оператори джерела повертаються до свого стану, коли бачать останній здійснений маркер і обробка продовжується. Такий підхід до контрольно-пропускного пункту є легшим, ніж підтвердження рекордів Storm. Це джерела даних періодично вводять маркери в потік даних. Щоразу, коли оператор отримує такий маркер, він перевіряє його внутрішній стан. Коли маркер отримав усі потоки даних, маркер (і всі записи, які раніше були оброблені), здійснюються. У разі відмови всі оператори джерела повертаються до свого стану, коли бачать останній здійснений маркер і обробка продовжується. Такий підхід до контрольно-пропускного пункту є легшим, ніж підтвердження рекордів Storm. Це всі оператори джерела повертаються до свого стану, коли бачили останній здійснений маркер і обробка продовжується. Такий підхід до контрольно-пропускного пункту є легшим, ніж підтвердження рекордів Storm. Це всі оператори джерела повертаються до свого стану, коли бачили останній здійснений маркер і обробка продовжується. Такий підхід до контрольно-пропускного пункту є легшим, ніж підтвердження рекордів Storm. ЦеНабір слайдів та відповідна розмова обговорюють підхід обробки потоку Flink, включаючи відмову, перевірку та обробку стану.

Storm також пропонує API одночасно високого рівня, який називається Trident. Однак Trident заснований на міні-партіях і, отже, більше схожий на Spark ніж Flink.

Регульована затримка Flink відноситься до того, як Flink надсилає записи з одного завдання в інше. Я говорив раніше, що Flink використовує конвеєрні передачі даних і передає записи, як тільки вони виробляються. Для ефективності ці записи збираються у буфер, який надсилається по мережі, коли він заповнений або визначений поріг часу. Цей поріг контролює затримку записів, оскільки він визначає максимальну кількість часу, який записуватиметься в буфері, не надсилаючись до наступного завдання. Однак він не може бути використаний для надання жорстких гарантій щодо часу, необхідного для запису від вступу до виходу з програми, оскільки це також залежить від часу обробки в межах завдань та кількості мережевих передач серед іншого.


2
Велике спасибі, дійсно! Можливо, одна відкрита точка, якщо я можу вас ще раз заважати: в чому полягає ця проблема "затримки", що регулюється? Це здається, що це може бути досить актуальним, враховуючи, що в різних областях додатків будуть виникати різні вимоги в цьому відношенні. Чи можете ви пояснити, що це означає, принаймні, з точки зору Flink?
fnl

6
Звичайно, я продовжив свою відповідь і обговорив регульовану затримку. Повідомте мене, якщо у вас є додаткові запитання.
Fabian Hueske

Чи Flink допускає "гарячі" зміни в робочому процесі DAG, як це можна реалізувати, наприклад, за допомогою Erlang? IE. Чи можна змінити DAG під час виконання?
Томас Браун

1
Заміна гарячого коду неможлива. Однак ви можете зберігати стан програми як точку збереження. Точку збереження можна використовувати для запуску модифікованої програми. Це можна зробити, поки оригінальна програма все ще працює таким чином, що вихід може бути перевернутий в якийсь момент. Зауважте, що програми не можуть бути довільно змінені під час відновлення з існуючої точки збереження.
Фабіан Уеске

1
Цікавою та величезною перевагою Flink є можливість роботи Apache Beam з ще більш високим рівнем API. Це один з найбагатших і найповніших бігунів для Біма.
Piotr Gwiazda

47

Додавання до відповіді Фабіана Уескі:

Flink покращує Storm додатково також такими способами:

  • Зворотний тиск: час виконання потоку Flink добре поводиться, коли різні оператори працюють з різною швидкістю, тому що оператори нижче за течією спрацьовують проти тиску вищестоящих операторів, хоча мережевий рівень управляє буферними пулами.

  • Зазначений користувачем стан: Flink дозволяє програмам підтримувати власний стан у ваших операторах. Цей стан може фактично брати участь у контрольній точці щодо відмовостійкості, забезпечуючи одноразові гарантії для призначеного користувачем стану. Дивіться цей приклад визначеної користувачем державної машини всередині оператора, яка послідовно перевіряється разом із потоком даних.

  • Потокове передавання Windows: Вікно потоку та агрегація вікон є важливим складовим елементом для аналізу потоків даних. Flink постачається з досить потужною системою вікон, яка підтримує багато типів вікон.


2
Що стосується Вашого першого пункту, Storm добре поводиться під тиском станом на 1.0 (вийшов квітня 2016)
Колін Ніколс

Штормовий тиск можна зменшити за допомогою властивості "spout_max_pending". Він встановлює поріг для максимальних кортежів, які можуть бути присутніми в носику, який очікує на підтвердження. Носик не буде споживати більше кортежів, які йдуть вперед, поки не трапиться акра.
Аман Гарг

3

На основі мого досвіду Бурі та Флінка. Я думаю, що ці інструменти можуть вирішити одну і ту ж проблему за допомогою різних підходів. Кожна функція Flink, яку згадує @Stephan Ewen, тепер може відповідати Storm за допомогою внутрішнього API (тобто, spolts та болтів ) та API Trident . Хтось стверджує, що Trident - це міні-пакетний стиль, хоча я думаю, що більшість складних додатків, пов’язаних із станом або агрегацією, можуть залежати лише від пакетної обробки зі стилем вікна. Тому я лише перелічу деякі основні відмінності тут, не кажучи, що краще.

  • Стиль розвитку . орієнтована на обчислення (наприклад, оператор, що можна змінити) у Flink порівняно з потоком даних (наприклад, addSpolt()/addBolt()) у Storm.
  • API високого рівня . Функції (наприклад, Map, Window, Join in Streaming level) у Flink vs. Native Window та Trident in Storm.
  • Гарантована обробка повідомлень (GMP. Тобто, точно рівно ) . Контрольно-пропускний пункт з двофазним з'єднувачем для з’єднання (наприклад, KafkaConsumer) у Flink проти Tuple-дерева з зовнішньою машиною стану або Trident in Storm
  • Толерантність до відмов . Маркерна контрольна точка у Flink порівняно з рівнем ACK у Storm.
  • Внутрішня архітектура . Проста абстракція та відносний паралелізм (наприклад, проріз для кожної нитки, розглянутої з центральними процесорними ядрами) у Flink проти багатошарових абстракцій (наприклад, слот для кожного JVM як працівника в супервізорі, і кожен керівник може мати багато працівників) у Storm.

3

Відмова: Я працівник компанії Cloudera, головного прихильника Шторму та (незабаром) Флінка.

Функціональний

Уже представлено багато хороших технічних моментів. Дуже короткий підсумок важливих моментів:

  • Як Flink, так і Storm можуть виконувати обробку подій
  • Здається, шторм не підтримує час події поза рамками
  • Шторм не зняв підтримку SQL з експериментальної стадії

Нефункціональний

  • Багато клієнтів вважають, що Storm (занадто) важкий у використанні
  • Прийняття бурі сповільнилося, і громада Flink тепер, здається, активніша, ніж Шторм
  • Flink все ще має наздоганяти (наприклад, задокументовані приклади), але загалом він охопив майже кожну область, про яку ви могли б подумати.

Висновок

Cloudera нещодавно оголосив про зняття Бурі (в HDP). І одночасно Flink був оголошений як його наступник.

Тож, якщо у вас є випадки використання на штормі, вони, звичайно, продовжуватимуть працювати. Але для нових випадків використання я би роздивився Flink або інші потокові двигуни.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.