Airflow: ночной расчёт и управляемый повтор этапов
Сервисная компания каждую ночь готовит ведомость выполненных работ по объектам. Исходные данные уже приняты, но дальше сотрудники вручную запускают несколько программ: собирают период, выполняют расчёт, сверяют итоги и выпускают файл. Если второй этап остановился, утром непонятно, что можно повторить и какой результат действующий. Apache Airflow можно использовать для управления такой регулярной цепочкой, сохраняя отдельные состояния этапов и понятный порядок восстановления работы.
Запросить сервер для Airflow
В OmegaIntegral аппаратную платформу обсуждаем на основе AI Server Manager 256. Карточка посвящена другому прикладному процессу; Airflow и расчётная цепочка согласуются самостоятельным проектом. «Суперинтеллект» — название серверного направления. Оркестрация заданий сама по себе не требует нейросети, а число 256 не означает объём RAM, видеопамяти или готовую производительность.
От принятой партии до выпущенной ведомости
Для первого процесса задайте результат целиком. Например, за завершившийся день получить одну датированную ведомость по объектам с согласованными показателями и отметкой проверки. Этапы могут включать выбор принятой версии данных, расчёт, сверку контрольных сумм и выпуск результата. Правила приёма исходных файлов и формулы должны существовать отдельно: планировщик не придумывает их вместо владельца процесса.
В архитектуре Airflow рабочая цепочка представлена DAG — задачами с зависимостями. Связи задают допустимый порядок выполнения. В нашем примере выпуск ведомости не должен считаться успешным, пока не завершены расчёт и предусмотренные проверки. Специальные условия запуска следующих этапов согласуют явно; зелёная отметка в интерфейсе ещё не доказывает правильность бизнес-результата.
Период расчёта отличается от времени запуска
Ночной процесс должен знать, за какой день он работает. Если запуск задержался до утра, он не должен незаметно захватить часть нового дня только потому, что программа читает «последние данные». В задании фиксируют границы периода, часовой пояс компании и версию исходного набора, принятую для этого выпуска.
В Airflow есть понятие интервала данных, связанного с запуском. Оно не равнозначно фактическому времени начала исполнения. Документация DAG Runs отдельно рассматривает плановые, ручные и исторические запуски. Поэтому ручной пересчёт вчерашней ведомости должен получать согласованный период, а не полагаться на случайное совпадение дат интерфейса и расчётной программы.
Повтор этапа не должен создавать второй результат
Временная недоступность источника и ошибка самих данных требуют разных действий. Для первого случая можно согласовать ограниченное число повторов и паузу. Для второго нужен разбор ответственным сотрудником. Бесконечная попытка запустить один и тот же ошибочный расчёт не заменяет решение причины.
Airflow поддерживает повторное выполнение задач, но безопасный результат зависит от их реализации. Рекомендации Apache подчёркивают повторяемость операции и привязку чтения и записи к определённой части данных. В проекте нашей ведомости повтор расчёта не должен добавить те же работы второй раз или незаметно перезаписать уже утверждённый выпуск.
До внедрения определяют идентификатор выпуска и правило замены: временный результат, прошедший проверку результат либо новая редакция после исправления входов. После сбоя сотрудник видит завершённые и неуспешные этапы, журналы и разрешённую границу повтора. Автоматическое проведение документов в учётной системе в этот пример не включено.
Пропущенная неделя — отдельная нагрузка
Если цепочка не работала несколько дней, восстановление исторических периодов может столкнуться с обычным ежедневным запуском. Политику catchup и пересчёта прошлых интервалов выбирают под процесс. Не каждый проект должен автоматически догонять весь пропуск: иногда сначала требуется проверить наличие принятых исходников и решение владельца отчёта.
Согласуйте число одновременно обрабатываемых периодов и ограничение обращений к исходной системе. Несколько свободных процессорных ядер не означают, что корпоративная база выдержит столько же тяжёлых запросов. Приоритет текущей ведомости и порядок исторического пересчёта становятся частью коммерческого задания, а не скрытой настройкой после поставки.
Сервер управляет исполнением, данные остаются в своей системе
Для выбранной редакции Airflow определяют scheduler, executor, обработку DAG, API-интерфейс, базу метаданных и рабочие процессы. Метаданные о состоянии задач не заменяют исходные таблицы, файлы результатов или их резервные копии. Крупные промежуточные файлы размещают в согласованном хранилище, доступном нужным этапам; локальный путь одного исполнителя нельзя считать общим автоматически.
Доступ к интерфейсу, права запуска и право менять код цепочки различаются. Модель безопасности Airflow описывает доверие к авторам DAG и администраторам. Учётные данные подключений, сетевые ограничения и управление секретами включают в проект отдельно. Простой вход по паролю не обещает изоляцию любых программ разных авторов.
Что проверить перед подбором оборудования
Для пилота достаточно одного обычного периода, согласованного сбоя этапа, повторной попытки и исторического пересчёта. Проверяют единственность принятой ведомости, связь с исходной версией, понятность журналов и отсутствие преждевременного выпуска. Восстановление метаданных, кода цепочки, необходимых настроек и внешних результатов испытывают в согласованных границах.
CPU, RAM, накопители и сеть выбирают по длительности этапов, объёмам и одновременной работе. GPU и несколько узлов не становятся обязательными из-за Airflow; один сервер не обещает высокую доступность. Пришлите описание цепочки, периодичность, размеры, рабочее окно и ответственных. Цена, наличие и конфигурация по запросу; оборудование, программирование этапов, интеграция, эксплуатация и доставка по России либо в Казахстан согласуются отдельно.
Сервер и согласованная расчётная цепочка
AI Server Manager 256
Цена по запросу. Текущая карточка описывает поиск по паспортам приборов; проект Airflow и расчётные этапы согласуются отдельно. Фактические CPU, RAM, накопители, сеть, программы, состояние, наличие и срок подтверждаются спецификацией и предложением. Число 256 не определяет объём памяти. Развёртывание, интеграция, прикладной код, испытания и сопровождение раскрываются отдельными работами.
Согласовать этапы и составДля сравнения состава платформы есть собственный AI Server Manager 128. Его номер также не определяет память; готовая настройка Airflow или аппаратная избыточность автоматически не включены.
Первичные источники приведены по месту в тексте. Документация Apache Airflow не подтверждает предустановку, выполнение расчётов, готовое разграничение доступа или испытание на предлагаемом сервере.