Батч-обработка (batch processing)

8 августа 2026 · ~12 мин чтения

Батч-обработка (batch processing)

Батч-обработка — это способ выполнять работу не по одному заданию сразу по мере поступления, а пачками (batch — «партия», «пакет»): накопить, запустить разом, дождаться конца. Противоположность — обработка в реальном времени, когда каждое событие обрабатывается немедленно.

История

Батч-обработка — не просто «один из подходов». Это то, с чего компьютеры вообще начались. Почти вся история вычислительной техники до середины 1960-х — это история батчей.

• 1890, США, Герман Холлерит. Перепись населения США захлебнулась: результаты переписи 1880 года считали вручную около восьми лет, и к следующей переписи стало ясно, что вручную не успеть вообще. Холлерит придумал перфокарты и табулятор — машину, которая обрабатывала карточки пачками. Перепись 1890 года обсчитали за пару лет (по разным оценкам — от двух до трёх). Компания Холлерита через серию слияний стала в 1924 году IBM. Обрати внимание: сама постановка задачи — «вот гора карточек, прогони её всю» — это и есть батч в чистом виде.
• 1956, General Motors. Первая в истории операционная система GM-NAA I/O, написанная GM вместе с North American Aviation для компьютера IBM 704, была по сути «батч-монитором»: она автоматически запускала задания одно за другим, чтобы дорогущая машина не простаивала, пока оператор перекладывает бумажки. Компьютерное время тогда стоило дороже человеческого — поэтому людей выстраивали в очередь к машине, а не наоборот.
• 1964, IBM System/360. Легендарная серия мейнфреймов и её ОС OS/360 с языком JCL (Job Control Language — язык описания заданий). Программист сдавал колоду перфокарт в «окошко», ночью машина прогоняла пачку заданий, утром забирал распечатку. Если в коде была опечатка — узнавал об этом через сутки.
• 1961–1970-е, реакция на батч. Именно мучительность этого цикла породила интерактивные системы: CTSS в MIT (Фернандо Корбато, 1961) и затем time-sharing (разделение времени) — идею, что машина может обслуживать много людей «одновременно». Но батч никуда не делся — он ушёл на ночь.
• 2004, Google. Статья Джеффри Дина и Санджая Гемавата про MapReduce — модель батч-обработки, размазанной по тысячам дешёвых серверов. Из неё вырос Hadoop (Дуг Каттинг, 2006), а затем Spark (Матей Захария, Беркли, 2009–2010) — до сих пор один из главных инструментов обработки больших данных.
• 2020-е, LLM. Батч вернулся в моду в третий раз: у Anthropic и OpenAI есть Batch API — отдаёшь пачку запросов к модели, ждёшь до 24 часов, платишь примерно вдвое меньше.

Что это такое

Идея простая: у любой операции есть накладные расходы на запуск (setup cost) — установить соединение, авторизоваться, прогреть кэш, раскрутить процесс. Если делать операции по одной, ты платишь эти накладные расходы каждый раз. Если собрать тысячу операций в пачку — платишь один раз, а дальше конвейер работает на полную.

Вторая причина — управляемость. Пачка имеет начало и конец. Её можно спланировать («запускаем в 02:00, когда нагрузки нет»), измерить («930 позиций, идём со скоростью 35 в час, осталось ~26 часов»), остановить и продолжить с середины. Поток событий в реальном времени так не выглядит — он бесконечный.

Третья — цена. Батчу не нужен мгновенный ответ, значит, его можно гонять на дешёвых ресурсах: ночью, на спотовых серверах (spot instances — арендуемые со скидкой мощности, которые могут отобрать в любой момент), в моменты низкого тарифа. Скидка 50% на Batch API у LLM-провайдеров — ровно из этой логики: провайдер сам решает, когда ему удобно обработать твою пачку, и заполняет ею простаивающие мощности.

Ключевые пары для различения:

• Батч vs реальное время (real-time/online). Батч: высокая пропускная способность (throughput), высокая задержка (latency). Реальное время: наоборот. Зарплата начисляется батчем раз в месяц; перевод по номеру телефона проходит за секунды.
• Батч vs стриминг (streaming). Стриминг — обработка событий по мере поступления, но конвейерно и непрерывно (Kafka, Flink). Грань размыта: «микробатчи» Spark Streaming — это батчи по несколько секунд.
• Батч vs интерактив. Интерактив — человек ждёт ответа прямо сейчас. Батч — человек ушёл спать, а работа идёт.

Аналогии из жизни

Стиральная машина. Никто не стирает носки по одному: копишь корзину, загружаешь разом. Накладные расходы (вода, электричество, твоё время на запуск) делятся на всю партию. Где ломается: если тебе нужна конкретная рубашка через час — батч бесполезен, придётся стирать вручную (переход на «реальное время» ради латентности). И второе: если в партию попала одна красная вещь, брак распространяется на всю пачку — в батчах одна ядовитая запись может испортить весь прогон, если нет обработки ошибок по элементам.

Фура против курьера. Дальнобойщик не выезжает с одной коробкой — он ждёт, пока фура заполнится: цена доставки одной коробки падает в сотни раз. Где ломается: пока фура собирается, первая загруженная коробка лежит и ждёт. Это классический компромисс батча — ради дешевизны каждая отдельная единица работы ждёт дольше. Для донорской почки нужен курьер с мигалкой, а не фура.

Заготовки на ресторанной кухне. Утром повар батчем нарезает овощи и варит бульоны на весь день (mise en place), вечером в час пик только собирает блюда. Где ломается: заготовки протухают. Если данные «скоропортящиеся» (курс валют, остатки на складе), батч, посчитанный утром, к вечеру врёт. Чем длиннее цикл батча, тем более устаревшим будет результат.

Как это работает

Разберём анатомию типичного батч-задания — неважно, ночной ли это биллинг в банке или парсинг каталога на 930 позиций.

1. Формирование очереди. Сначала строится полный список работы: какие записи обрабатываем, в каком порядке. Это отдельный шаг — и важный: список фиксирует объём («930 позиций»), без него невозможно ни считать прогресс, ни продолжить после сбоя.

2. Разбиение на чанки (chunk — «ломоть»). Пачку режут на куски разумного размера: по 100 записей, по 10 МБ, по одной странице API. Чанк — единица повторного запуска: упал чанк — перезапускаем чанк, а не всю пачку.

3. Воркер (worker — процесс-исполнитель) идёт по очереди. Классический цикл:

для каждого элемента из очереди:
    если элемент уже обработан → пропустить      # идемпотентность
    попытаться обработать
    если ошибка → повторить с паузой              # retry + backoff
    если снова ошибка → пометить и идти дальше    # не ронять весь батч
    записать результат и отметку «сделано»        # чекпоинт
    подождать N секунд                            # rate limit

4. Чекпоинты (checkpoint — точка сохранения). После каждого элемента или чанка воркер записывает «докуда дошёл». Ночной батч на 27 часов обязательно переживёт что-нибудь: обрыв сети, перезагрузку, лимит API. Без чекпоинта падение на 900-й позиции из 930 означает начать с нуля. С чекпоинтом — продолжить с 901-й.

5. Идемпотентность (повторяемость без побочного эффекта). Повторная обработка уже сделанного элемента не должна портить данные: не списать деньги дважды, не задублировать строку. Обычно решается проверкой «а не сделано ли уже» перед работой — тогда батч можно безбоязненно перезапускать сколько угодно.

6. Троттлинг (throttling — искусственное замедление). Батч легко превращается в DDoS самого себя: тысяча запросов в секунду к чужому API — и тебя банят. Поэтому в цикл встраивают паузы, а скорость подбирают под лимиты источника. Отсюда парадокс: батч часто специально медленный. Пачка на 930 позиций со скоростью «одна позиция в полторы-две минуты» — это ~26–28 часов, и это нормально.

7. Прогресс и ETA (estimated time of arrival — оценка времени завершения). Раз объём известен заранее, можно считать: сделано 207 из 930, средняя скорость такая-то, осталось ~26,6 часа. ETA считается по скользящей средней скорости и постоянно уточняется. Человеку при этом не нужно смотреть в экран — батч шлёт уведомления о вехах: «каждые 5 позиций», «раз в час», «по завершении».

8. Финализация. В конце — сводка: сколько успешно, сколько с ошибками, сколько пропущено и почему. Список ошибок — это, по сути, готовая очередь для следующего, маленького батча-«доборщика».

Где встречается в обычной жизни

• Зарплата и платежи. Зарплата «приходит ночью» не случайно: банковские проводки исторически гоняются ночными батчами. Межбанковские переводы в США (система ACH) идут 1–3 дня именно потому, что обрабатываются пачками по расписанию. В России платёжная система ЦБ долго работала «рейсами» — несколько батчей в день; мгновенный СБП появился как раз в противовес.
• Выписки и начисления. Проценты по вкладу, кэшбэк, детализация у сотового оператора, начисления ЖКХ — всё считается периодическими батчами, а не в момент каждой транзакции.
• Телефон ночью на зарядке. Бэкап фото в облако, индексация галереи, обновление приложений — ОС копит эти задачи и запускает пачкой, когда есть Wi-Fi, зарядка и простой.
• Закрытие смены на кассе. Когда продавец «закрывает терминал» в конце дня, происходит batch settlement: все транзакции дня одной пачкой уходят в банк на клиринг. У Visa и Mastercard это буквально называется батчем.
• Email-рассылка. «Письмо придёт в течение часа» — значит, ты в очереди на батч-отправку: провайдеры рассылок шлют миллионы писем волнами, чтобы не попасть в спам-фильтры.

Где встречается в IT и бизнесе

• ETL и ночные отчёты. Классика: ночью выгрузить данные из рабочих систем, преобразовать, загрузить в хранилище, к утру построить дашборды. Нужно, когда отчётам не требуется секундная свежесть.
• Биллинг. Посчитать всем клиентам стоимость за период — по определению пачка: полный список клиентов, тарифы, скидки, итог.
• Парсинг и сбор данных. Обойти каталог из сотен позиций, по каждой сходить в API или на страницу, соблюдая лимиты источника. Здесь батч — единственный вариант: слишком много позиций, слишком строгие лимиты.
• Массовые LLM-задачи. Прогнать 10 000 документов через модель на классификацию — это Batch API: вдвое дешевле, результат в течение суток. Нужно, когда объём большой, а срочности нет.
• Миграции и переиндексация. Переложить миллионы записей в новую схему, пережать все картинки в новый формат, перестроить поисковый индекс — батч с чекпоинтами, потому что за один присест не влезет.

Кто пользуется

• Банки и платёжные системы. Ядро банковского бэк-офиса до сих пор во многом батчевое; ночной «end-of-day batch» — стандартный термин. Мейнфреймы IBM Z, наследники System/360, живут в банках именно ради этого.
• Google. В статье MapReduce (2004) описывалась обработка терабайтов в день на кластерах из тысяч машин; к концу 2000-х Google, по публичным докладам, прогонял через MapReduce порядка десятков петабайт в день. Точные текущие цифры не публикуются.
• Yahoo, затем весь биг-дата-мир. Yahoo к 2008 году гоняла Hadoop на кластерах в тысячи узлов; сегодня Spark-батчи — стандарт у Netflix, Uber, Airbnb для аналитики и ML-пайплайнов.
• Anthropic и OpenAI. Оба провайдера дают ~50% скидку на батч-запросы к моделям с обработкой в пределах 24 часов — именно чтобы заполнять простаивающие GPU.
• Рендер-фермы. Каждый кадр анимационного фильма — задание в гигантском батче; у Pixar счёт идёт на десятки миллионов процессоро-часов на фильм (порядок, точные цифры разнятся от фильма к фильму).

Альтернативы и конкуренты

• Стриминговая обработка (Kafka + Flink и т.п.).
  Плюсы: секундная свежесть данных, нет «окна ожидания», нагрузка размазана ровно.
  Минусы: заметно сложнее в разработке и эксплуатации; сложнее гарантировать точность («ровно один раз» — отдельная боль); дороже в поддержке.
• Обработка по запросу (on-demand, по одному).
  Плюсы: максимально просто, результат сразу, нет очередей.
  Минусы: накладные расходы на каждый вызов; не масштабируется на тысячи элементов; легко упереться в лимиты внешних API.
• Микробатчи (Spark Streaming, батчи по секундам/минутам).
  Плюсы: компромисс — почти свежие данные при батчевой простоте.
  Минусы: и задержка не нулевая, и сложность уже не батчевая; два набора граблей вместо одного.
• Событийная архитектура (очереди сообщений, обработка по событию).
  Плюсы: реагирует на факты по мере появления, естественно масштабируется воркерами.
  Минусы: нет понятия «всё обработано» — сложнее сводить итоги и считать полноту; отладка распределённых событий тяжелее.

Когда НЕ стоит использовать

• Когда важна латентность. Антифрод должен решить «пропустить платёж или нет» за миллисекунды — батч, который посчитает мошенников к утру, бесполезен: деньги уже ушли.
• Когда объём маленький. Ради 20 записей строить очередь, чекпоинты и мониторинг — оверинжиниринг. Проще обработать в лоб за минуту.
• Когда данные быстро протухают. Если результат нужен на основе состояния «прямо сейчас» (остатки, цены, свободные слоты), долгий батч выдаст красивый, подробный и уже неверный ответ. Правило: длительность батча должна быть заметно меньше срока годности данных.

Связанные понятия

• Очередь (queue) — структура «первым пришёл — первым обработан», хребет любого батча.
• Чекпоинт (checkpoint) — сохранённая точка прогресса, с которой можно продолжить после сбоя.
• Идемпотентность — свойство операции переживать повторный запуск без побочных эффектов.
• Rate limit / троттлинг — ограничение скорости запросов; батч должен его уважать, а не пробивать.
• ETA — оценка времени завершения по текущей скорости и остатку очереди.
• ETL (extract, transform, load) — классический класс батч-задач: извлечь, преобразовать, загрузить.
• Cron / launchd — планировщики, которые запускают батчи по расписанию.

Литература и источники

• Wikipedia (en): Batch processing — история от перфокарт до наших дней.
• Wikipedia (ru): Пакетная обработка — короче английской, но основа есть.
• Мартин Клеппман, «Designing Data-Intensive Applications» (2017, есть русский перевод «Высоконагруженные приложения»). Глава 10 — целиком про батч-обработку, глава 11 — про стриминг как её развитие. Лучшее системное чтение по теме.
• Jeffrey Dean, Sanjay Ghemawat, «MapReduce: Simplified Data Processing on Large Clusters» (2004) — классическая статья; искать по названию, PDF лежит на research.google.
• Документация Anthropic Message Batches API — практичный современный пример батч-экономики; искать «Anthropic Batch API» в официальной документации.
• Про историю мейнфреймов и JCL — искать «IBM System/360 history» или лекции Кена Ширриффа (Ken Shirriff) о железе IBM.

Где встретилось у меня

Вчера почти сутки в фоне шёл батч-сбор данных из 2ГИС по каталогу примерно из 930 жилых комплексов: очередь позиций, обработка по одной с паузами под лимиты источника, чекпоинты с продолжением после перезапуска и прогресс-уведомления вида «207 из 930, осталось ~26 часов». Практически все пункты «анатомии батча» из этой статьи вчера были видны вживую в логах.

Краткое резюме

• Батч — это «накопить и обработать пачкой»: высокая пропускная способность ценой задержки.
• Это старейший режим вычислений: от перфокарт Холлерита (1890) и мейнфреймов IBM до MapReduce и Batch API у LLM-провайдеров.
• Анатомия правильного батча: очередь → чанки → воркер с ретраями → чекпоинты → идемпотентность → троттлинг → прогресс с ETA → итоговая сводка.
• Батч выбирают ради дешевизны и управляемости; реальное время — ради латентности. Скидка 50% на LLM-батчи — плата провайдера за право самому выбирать, когда считать.
• Не используй батч там, где данные протухают быстрее, чем длится прогон, и где ответ нужен за миллисекунды.