После остановки нужно знать, какие события уже обработаны и какой итог накоплен. Объясняем роль потоковой контрольной точки, источника и получателя результата без кода.
Сервер запустился, но откуда продолжать
Представим условный поток заказов магазина. Расчёт ведёт счётчик покупок по каждому пункту выдачи. Во время работы приложение останавливается. После запуска мало снова увидеть источник событий: нужно понять, что уже было принято обработкой и какие накопленные сведения понадобятся для следующей порции. Начало с произвольного места может дать пропуски или повторный учёт.
Structured Streaming — механизм потоковой обработки Apache Spark. Для восстановления ему нужен сохранённый контекст выполнения. Контрольная точка потока, или checkpoint, содержит сведения о продвижении обработки и её состоянии. Она не включает сервер автоматически: запуск приложения и наличие доступного сохранённого контекста — разные части восстановления.
Позиция чтения и накопленный результат
В руководстве Spark описано сохранение прогресса, обработанных позиций источника и текущих агрегатов. Агрегат — сводное значение, например количество заказов по группе. Когда после сбоя продолжается тот же совместимый потоковый расчёт, этот контекст позволяет восстановить предыдущую работу.
Представим две бумажные записи: закладку в журнале поступлений и ведомость уже накопленных итогов. Только закладка не объясняет сумму по пункту выдачи, а только сумма не показывает, какие записи в неё вошли. Это упрощённая аналогия. Настоящий механизм согласует обработку порций и их фиксацию, поэтому вручную исправлять отдельные служебные файлы нельзя.
Условный сбой между подготовкой и завершением
Допустим, одна порция заказов завершена, а следующая успела только начать обработку. После остановки часть вычислений может понадобиться повторить. Вопрос для команды — не просто «прочитаны ли события», а «что считается завершённым шагом и что уже увидел получатель результата». Эти моменты не следует смешивать в одном сообщении об успешном запуске.
Для учебного разбора предложим нарисовать словами три состояния: до получения порции, во время её расчёта и после принятия результата. Затем для каждого описать ожидаемое продолжение. Если получатель повторно принимает одно и то же сообщение как новую покупку, восстановленный поток ещё не гарантирует правильный итог всей внешней цепочки.
Почему важно сохранить нужную контрольную точку
Документация Databricks перечисляет позиции источника, сведения о принятых порциях и сохранённое состояние. Для разных потоковых расчётов нужны разные места контрольных точек. Удаление такого содержимого или переход к новому месту означает начало с новым контекстом, а не обычное продолжение прежнего.
В нашем примере полезно заранее уточнить, где хранится этот контекст, переживает ли он потерю вычислительного узла и кто отвечает за его доступность. Но даже сохранная точка не вернёт события, которые источник уже перестал отдавать. Срок хранения исходных событий и возможность повторного чтения нужно проверять отдельно по конкретному источнику.
Изменённая обработка может оказаться несовместимой
При восстановлении нельзя без проверки одновременно менять смысл расчёта. В документации Spark и Databricks описаны ограничения на изменение источников, операций с состоянием и других частей задачи при использовании прежней точки. Совместимость зависит от конкретного изменения. Поэтому «вчера работало» не является достаточным основанием для продолжения после произвольной переделки.
Также важны гарантии получателя. В Spark разные способы записи поддерживают разные условия защиты от повторов; универсальное обещание однократного внешнего действия здесь неверно. Предложим проверять всю цепочку: доступность исходных событий, чтение сохранённого контекста, совместимость задачи и повторное принятие результата. Это понятнее, чем объявлять само наличие папки полной защитой от потери данных.
Как подготовить проверяемый сценарий восстановления
Опишите ожидаемый результат до остановки и после неё на небольшом условном наборе. Не запускайте такой эксперимент в рабочей системе без согласованного плана. Устройство совместных вычислений объясняет статья о распределении работы Spark, а назначение файлового представления — материал о Parquet.
Изучать потоковую обработку и её ограничения можно на курсе PySpark для инженеров и аналитиков данных. Полезный первый результат — объяснить, какая сохранённая информация нужна для продолжения и почему перезапуск процесса сам по себе ещё не доказывает корректность отчёта.
