В чем разница между мини-пакетом и потоковой передачей в реальном времени на практике (не в теории)?

Заявление об ограничении ответственности: я являюсь коммиттером и членом PMC Apache Flink. Я знаком с общим дизайном Spark Streaming, но не знаю в деталях его внутреннего устройства.

Модель обработки мини-пакетного потока, реализованная в Spark Streaming, работает следующим образом:

• Записи потока собираются в буфер (мини-пакет).
• Периодически собранные записи обрабатываются с помощью обычного задания Spark. Это означает, что для каждого мини-пакета планируется и выполняется полное задание распределенной пакетной обработки.
• Во время выполнения задания собираются записи для следующего пакета.

Итак, почему неэффективно запускать мини-пакет каждые 1 мс? Просто потому, что это означало бы планировать распределенное пакетное задание каждую миллисекунду. Несмотря на то, что Spark очень быстро составляет расписание заданий, это было бы слишком. Это также значительно снизило бы возможную пропускную способность. Методы пакетной обработки, используемые в ОС или TCP, также не работают, если их пакеты становятся слишком маленькими.

Я знаю, что был принят один ответ, но я думаю, что нужно сказать еще один, чтобы полностью ответить на этот вопрос. Я думаю, что ответ типа «Реальное время Flink быстрее / лучше для потоковой передачи» неверен, потому что это сильно зависит от того, что вы хотите делать.

Модель мини-партии Spark имеет, как было написано в предыдущем ответе, недостаток, заключающийся в том, что для каждой мини-партии должно создаваться новое задание.

Однако в Spark Structured Streaming для триггера времени обработки по умолчанию установлено значение 0, что означает, что чтение новых данных выполняется как можно быстрее. Это означает, что:

1. один запрос начинается
2. данные поступили, но 1-й запрос не закончился
3. 1-й запрос завершен, поэтому данные будут немедленно обработаны.

Задержка в таких случаях очень мала.

Одним из больших преимуществ перед Flink является то, что Spark имеет унифицированные API для пакетной и потоковой обработки из-за этой мини-пакетной модели. Вы можете легко преобразовать пакетное задание в потоковое задание, объединить потоковые данные со старыми данными из пакета. Сделать это с помощью Flink невозможно. Flink также не позволяет выполнять интерактивные запросы с данными, которые вы получили.

Как было сказано ранее, варианты использования для микропакетов и потоковой передачи в реальном времени различаются:

1. Для очень маленьких задержек подойдет Flink или некоторые вычислительные гриды, такие как Apache Ignite. Они подходят для обработки с очень малой задержкой, но не для очень сложных вычислений.
2. Для средних и больших задержек у Spark будет более унифицированный API, который позволит выполнять более сложные вычисления так же, как и пакетные задания, только из-за этой унификации.

Дополнительные сведения о структурированной потоковой передаче см. В этом блоге сообщение

Я много думаю об этом, потому что ответ техническим и нетехническим людям всегда сложно сформулировать.

Я постараюсь ответить на эту часть:

Почему неэффективно запускать мини-пакет с задержкой в ​​1 миллисекунду?

Я считаю, что проблема не в самой модели, а в том, как Spark ее реализует. Это эмпирическое свидетельство того, что слишком большое сокращение окна мини-партии снижает производительность. Фактически было рекомендовано время не менее 0,5 секунды или более для предотвращения такого рода ухудшения. На больших объемах даже этот размер окна был маловат. У меня никогда не было возможности протестировать его на производстве, но у меня никогда не было строгих требований к работе в реальном времени.

Я знаю Flink лучше, чем Spark, поэтому я не очень хорошо знаю его внутреннее устройство, но я считаю, что накладные расходы, внесенные при проектировании пакетного процесса, не имеют значения, если ваша партия обрабатывается не менее нескольких секунд, но становится тяжелой, если они введите фиксированную задержку, и вы не можете ее уменьшить. Чтобы понять природу этих накладных расходов, я думаю, вам придется покопаться в документации Spark, коде и открытых проблемах.

Промышленность прямо сейчас признала, что существует потребность в другой модели, и именно поэтому сейчас растет количество движков, ориентированных на потоковую передачу, и Flink является лидером. Я не думаю, что это просто модные словечки и шумиха, потому что варианты использования этого вида технологий, по крайней мере, на данный момент, чрезвычайно ограничены. По сути, если вам нужно принять автоматизированное решение в режиме реального времени по большим и сложным данным, вам понадобится быстрый механизм обработки данных в реальном времени. В любом другом случае, в том числе в режиме, близком к реальному, потоковая передача в реальном времени - это излишество, и мини-пакет - это нормально.