Зачем нужна потоковая обработка?

Представьте, что вы заказали продукты с доставкой. В магазине сборщик (сотрудник, который собирает ваш заказ) не нашёл красные яблоки и предлагает вместо них зелёные яблоки¹. Приложение просит вас принять замену или отказаться, а сборщик ждёт ответа. Предложение нужно увидеть, пока сборщик ещё стоит у полки.

Магазин собирает одновременно много таких заказов, а руководителю смены нужна общая картина загрузки. Обе задачи опираются на одни и те же данные: изменения в заказах, которые поступают постоянно. Вопрос в том, когда превращать эти изменения в ответ. Обычно это делают одним из трёх способов.

Считать, когда спросят

Проще всего подождать, пока кто-нибудь посмотрит. Когда вы открываете страницу заказа, приложение отправляет запрос. Сервис читает заказ, определяет его текущий статус и возвращает страницу. Это обработка по запросу (processing on request): вычисление запускается, потому что его попросили.

Так удобно следить за доставкой. Вы заглядываете в заказ несколько раз, прочитать один заказ дёшево, а пока никто не смотрит, сервис ничего не делает.

Слабое место в том, что страница показывает заказ таким, каким он был в момент открытия. Если сборщик предложит замену через минуту, вы увидите её, только когда откроете страницу снова. Приложение могло бы обновлять страницу каждые несколько секунд. Но это всё та же обработка по запросу, и большинство таких запросов не найдёт ничего нового.

Считать по расписанию

Руководителю смены нужно другое: список всех активных заказов. Магазин может накапливать изменения и раз в пятнадцать минут запускать один расчёт. Каждый запуск читает всё накопленное, строит список и сохраняет его как отчёт. Это пакетная обработка (batch processing): накопленный набор данных обрабатывается целиком, за один запуск.

Такой способ подходит для отчёта, который может подождать. Один запуск охватывает сразу много заказов, а для обзора загрузки магазина задержка в пятнадцать минут допустима.

Слабое место здесь в промежутке между запусками. Если вы примете замену сразу после запуска, отчёт ещё до пятнадцати минут будет показывать, что заказ ждёт ответа. Чем чаще запуски, тем короче промежуток, но каждый запуск заново обрабатывает заказы, которые не изменились, и какой-то промежуток остаётся всегда.

Обрабатывать каждое изменение сразу

Для замены отчёт раз в пятнадцать минут слишком медленный. Обновление страницы каждые несколько секунд было бы достаточно быстрым, но тогда пришлось бы снова и снова спрашивать про каждый активный заказ, хотя у большинства из них ничего нового нет.

Поэтому зайдём с другой стороны. Система не ждёт вопроса или расписания, а реагирует на каждое изменение, когда оно поступает. Каждое изменение записывается как событие (event): небольшая запись о том, что произошло, например «предложена замена» или «заказ упакован». Когда приходит предложение, система обновляет страницу вашего заказа. Когда приходит ваш ответ, она обновляет экран сборщика и список заказов магазина, которые ждут ответа покупателя.

Это и есть потоковая обработка (stream processing): обработка непрерывного потока событий по мере их поступления, при которой результаты всё время остаются актуальными.

Цена такого подхода в том, что система работает с каждым изменением, даже когда на результат никто не смотрит. Ещё ей нужен способ получать события и доставлять обновления. Для этого не требуется специальный продукт или большая распределённая система. Небольшое приложение может прочитать событие, применить одно правило и записать новый результат. Специализированные инструменты появляются, когда событий становится больше, у результатов больше читателей и больше мест, где что-то может пойти не так.

Что значит «в реальном времени»

Такие результаты часто называют результатами в реальном времени (real-time). Это не значит «мгновенно». Событие нужно записать, доставить, обработать и показать, и на каждый шаг уходит время. Событие может прийти с опозданием, не по порядку или не прийти вовсе. На практике «в реальном времени» означает, что задержка достаточно мала для конкретной цели. Для замены несколько секунд, скорее всего, допустимы, а несколько минут уже нет.

Какой способ выбрать

Решить помогают четыре вопроса:

1. Как быстро нужен результат?
2. Кому он нужен и как часто на него смотрят?
3. Как часто меняются данные и сколько стоит пересчёт?
4. Что пойдёт не так, если ответ устарел на несколько минут?

Для разных задач сервис доставки отвечает на них по-разному:

	Ход доставки	Обзор магазина	Замена во время сборки
Как быстро?	Когда покупатель смотрит	Раз в пятнадцать минут достаточно	За секунды
Кому и как часто?	Одному покупателю, несколько раз	Руководителю смены, при регулярной проверке загрузки	Покупателю, сборщику и сотрудникам магазина, пока собирают заказ
Изменения и цена пересчёта	Изменений мало; прочитать один заказ дёшево	Меняется много заказов; один запуск охватывает все	Изменения приходят в непредсказуемые моменты по многим заказам
Если ответ устарел на несколько минут?	Ничего страшного; никто не смотрел	Незначительно; отчёт может подождать	Сборщик продолжает ждать, хотя вы уже ответили
Подходит	Обработка по запросу	Пакетная обработка	Потоковая обработка

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

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

Что запомнить

• Результат можно вычислять по запросу, по расписанию над накопленными данными или по мере поступления каждого изменения.
• Потоковая обработка реагирует на события по мере их поступления. Она помогает, когда решения зависят от изменений во время текущей работы.
• У результата в реальном времени всё равно есть задержка, и она должна быть достаточно мала для своей цели.
• В одном сервисе разные задачи могут решаться разными способами.

Источники

1. Uber: Retail Order Fulfillment API Guide.