Чем отличаются пакетная и потоковая обработка данных, где подходит расчёт по расписанию и когда бизнесу важна быстрая реакция на события.
Отчёт за день и сигнал сейчас
Представим условную гостиничную сеть. Руководителю нужен итог продаж за вчера, а сотруднику ресепшена — актуальная информация о только что изменившемся бронировании. Данные могут относиться к одному бизнесу, но допустимое время ожидания у этих задач разное.
Пакетный и потоковый подходы помогают организовать обработку с учётом такого различия. При выборе важно спросить, какое действие произойдёт после получения результата. Если решение принимают утром следующего дня, обновление каждую секунду может ничего не менять для пользователя.
Что называют пакетной обработкой
При пакетной обработке система берёт ограниченную порцию накопленных данных и выполняет работу над ней. Например, может собрать события за завершившийся день и подготовить сводку. Порцию задают не только календарём: важно, что у текущей работы есть определённый набор входных сведений.
В объяснении AWS пакетный подход сопоставляется с обработкой постоянно поступающих данных. Для нашей условной гостиницы ночной расчёт может подойти для итогов по категориям номеров. Но время его завершения должно соответствовать ожиданиям: отчёт, готовый после утренней встречи, уже опоздал относительно этой задачи.
Что меняется при работе с потоком
При потоковом подходе обработка организована вокруг поступающих событий и продолжается по мере их появления. Событие — сообщение об изменении, например о бронировании или отмене. Система не обязана ждать окончания суток, чтобы начать учитывать такую информацию.
Однако слово «потоковая» не означает нулевую задержку. Сведения должны дойти до обработчика, пройти нужные действия и стать доступными пользователю. Конкретная реализация может собирать небольшие порции событий: такой режим описан в документации Spark. Поэтому требование «в реальном времени» полезно заменить понятным для задачи сроком, а затем проверить, способен ли весь путь данных его выдержать.
Почему поздние события требуют договорённости
В условной гостинице связь могла прерваться, и сообщение об отмене пришло позже остальных. Возникает вопрос: к какому периоду отнести изменение и нужно ли пересчитать уже показанный итог? Обработку поздних данных разбирает документация Microsoft; правило нужно выбирать с учётом задачи.
Можно отдельно показывать предварительный и уточнённый результат, если это подходит пользователям. Главное — договориться о смысле этих состояний и объяснить его в отчёте. Иначе обновившаяся цифра будет выглядеть как ошибка, хотя система просто получила сведения, которых раньше не было. У скорости и окончательности результата разные роли.
Оба подхода могут существовать рядом
Одной команде может быть нужен оперативный сигнал, а другой — согласованный итог за период. Не обязательно выбирать единственный режим для всех задач компании. Можно обрабатывать изменения для быстрой реакции и отдельно готовить итоговую сводку с дополнительными проверками.
В такой схеме важно согласовать определения. Если два процесса по-разному трактуют отмену бронирования, результаты будут расходиться даже при исправной передаче данных. Пакетная или потоковая обработка отвечает на вопрос об организации вычислений во времени. Сами бизнес-правила всё равно нужно определить и проверять отдельно.
Как обсудить выбор с технической командой
Сформулируйте четыре вещи: какое событие важно, какое действие должно последовать, сколько можно ждать и что делать при задержке. Например, для условной внутренней сводки допустимо дождаться следующего обновления, а для другой задачи потребуется явное предупреждение о неактуальности сведений.
Затем обсудите поддержку: кто следит за работой, как узнаёт о пропуске и как восстанавливает результат. Постоянный поток требует постоянного внимания к состоянию процесса, а расчёт по расписанию — контроля своевременного завершения. Начинать полезно с нужной пользователю свежести, после чего выбирать устройство системы и оценивать его стоимость.
По теме
Следующий шаг
Если интереснее продумывать устройство системы целиком, посмотрите интенсив «Архитектор данных». Сопоставьте его программу со своими знаниями и задачами. Это интенсив по архитектуре, а не обещание освоить любую потоковую платформу за один курс. Полезно заранее описать, какое решение и с какой задержкой должна поддерживать ваша будущая система.
