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

в чем разница между мини-пакетной и потоковой передачей в реальном времени на практике (не теория)? Теоретически, я понимаю, что mini batch-это то, что пакеты в заданном временном интервале, тогда как потоковая передача в реальном времени больше похожа на что-то, когда данные поступают, но мой самый большой вопрос: почему бы не иметь mini batch с временным интервалом epsilon (скажем, одну миллисекунду), или я хотел бы понять, почему один будет эффективным решением, чем другой?

Я недавно наткнулся на один пример где mini-batch (Apache Spark) используется для обнаружения мошенничества и потоковой передачи в реальном времени (Apache Flink), используемой для предотвращения мошенничества. Кто-то также прокомментировал, что мини-пакеты не будут эффективным решением для предотвращения мошенничества (поскольку цель состоит в том, чтобы предотвратить транзакцию, как это произошло), теперь я задаюсь вопросом, почему это не было бы так эффективно с mini batch (Spark) ? почему не эффективно запускать мини-пакет с задержкой в 1 миллисекунду? дозирование-это используемая техника везде, включая ОС и стек TCP/IP ядра, где данные на диск или сеть действительно буферизованы, так что какой убедительный фактор здесь сказать, что один более эффективен, чем другой?

10
apache-flink apache-spark batch-processing data-processing stream-processing

3 ответов

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

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

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

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

11

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

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

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

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

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

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

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

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

для получения более подробной информации о структурированной потоковой передаче, пожалуйста, посмотрите на этот блог

7

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

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

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

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

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

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

3