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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

Для получения более подробной информации о структурном Streaming посмотрите на this blog post