Акт IV. Платформа данных · Ночной конвейер

Смотри, у пакетной обработки дурная слава: «ночной монстр, который тормозит и падает». Но в её основе лежит идея настолько простая и мощная, что её стоит прочувствовать отдельно.

Пакетное задание читает неизменяемый вход и заново строит выход. Ключевое слово — неизменяемый. Вход за время работы не меняется: это снимок базы, вчерашние логи, выгрузка. И вот что это даёт:

• Упал на середине — просто запусти заново. Вход-то не изменился. Не надо разбираться, что уже посчитано, а что нет, не надо доштопывать полусостояние — прогнал с нуля, получил тот же результат. Повтор безопасен по построению.
• Нашёл баг в коде — почини и перезапусти. Старый выход выбрасывается, новый строится из того же входа. Никаких «а теперь напиши миграцию, чтобы исправить уже испорченные данные».
• Выход — тоже производное. Его не жалко: индекс, витрина, отчёт всегда пересобираются из источника.

Сравни с обновлением «на лету», которое предлагал Гена: там каждое изменение необратимо меняет состояние на месте. Ошибся — и уже не откатишь просто так; порча копится тихо.

Модель обработки за десятилетия прошла путь от простых утилит (отсортировал, сгруппировал, посчитал) до распределённых движков: MapReduce разложил задачу на «преобразовать каждую запись» и «свести», а современные dataflow-движки вроде Spark берут граф преобразований и сами раскладывают его по десяткам машин. Классический сценарий — ETL: вытащить из источников, преобразовать, сложить в хранилище для аналитики.

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