Вопросы на собеседовании: MLOps-инженер

Оркестратор пайплайнов отделяет планирование процесса и управление состоянием от выполнения задач и хранения артефактов.

• Парсер или компилятор превращает определение пайплайна в граф и проверяет структурные ограничения.
• Планировщик находит готовые к запуску экземпляры задач по зависимостям, правилам запуска, квотам и состоянию запуска.
• Исполнитель отправляет работу локальным процессам, очередям воркеров или кластеру, но сам задачу не выполняет.
• Хранилище метаданных записывает запуски и состояния задач, а объектное хранилище или база данных содержит крупные результаты.

DAG задаёт конечный частичный порядок, в котором направленные рёбра выражают зависимости задач без циклов.

• Задача становится доступной для запуска, только когда её предшествующие зависимости удовлетворяют настроенным правилам запуска.
• Независимые ветви могут выполняться параллельно, потому что граф не задаёт порядок между ними.
• Разветвление создаёт параллельные ветви, а соединение ожидает необходимые предшествующие ветви.
• Цикл недопустим, потому что для циклических зависимостей нельзя построить топологический порядок выполнения.

Компиляция строит проверенную исполняемую спецификацию, а среда выполнения создаёт конкретные запуски и управляет их состоянием.

• Компиляция фиксирует компоненты, рёбра, плейсхолдеры параметров, условия и настройки выполнения в промежуточном представлении.
• Статические проверки могут отклонить отсутствующие входы, несовместимые типы, циклы и некорректные определения компонентов до отправки.
• Среда выполнения подставляет фактические параметры, создаёт экземпляры задач и вычисляет условия, значения которых пришли из предыдущих задач.
• Среда выполнения записывает переходы состояний и передаёт доступную работу настроенной системе выполнения.

Граница задачи должна охватывать один независимо исполняемый шаг с явным и стабильным контрактом входов и выходов.

• Разделяйте шаги, которым нужны разные образы, профили ресурсов, политики повторов, владельцы или жизненные циклы кеша.
• Оставляйте тесно связанные операции в памяти вместе, если материализация промежуточного результата добавит стоимость без повторного использования.
• Отделяйте побочные эффекты вроде публикации модели от чистых преобразований, чтобы их политика выполнения была видна.
• Избегайте слишком мелких задач, у которых расходы на планирование и запуск контейнера превышают полезную работу.

Задачи должны передавать через оркестратор ссылки на долговечные артефакты, а крупные данные хранить вне его базы метаданных.

• Задача-производитель записывает неизменяемый объект или версионированный датасет в общее хранилище до публикации его URI.
• Запись о результате должна включать тип, схему или формат, контрольную сумму, запуск-производитель и важные метаданные происхождения.
• Задача-потребитель читает только объявленные входы, что сохраняет зависимости явными, а среды выполнения изолированными.
• Атомарная публикация через финальное переименование, манифест или маркер коммита не даёт потребителям увидеть частичный результат.

Расписание создаёт запуски для логических временных интервалов, а событие создаёт их при поступлении определённого внешнего факта.

• Запуски по расписанию должны использовать логический интервал как вход, а не считать временем данных фактическое время выполнения.
• Навёрстывание и заполнение истории материализуют пропущенные исторические интервалы согласно той же семантике расписания.
• Событийные триггеры должны передавать стабильный идентификатор события и ссылку на данные для дедупликации повторной доставки.
• Оба типа триггеров должны вести к одному параметризованному контракту пайплайна, чтобы выполнение оставалось воспроизводимым.

Задача пайплайна идемпотентна, если повторное выполнение с теми же логическими входами сходится к тому же зафиксированному результату.

• Формируйте пути результатов или ключи операций из партиции запуска, версий входов и значимых параметров.
• Для внешних записей используйте upsert, compare-and-set или ограничения уникальности вместо безусловного добавления.
• Сначала записывайте временный результат и открывайте к нему доступ только атомарным шагом коммита.
• Регистрируйте завершённые побочные эффекты по ключу идемпотентности, чтобы повтор мог распознать предыдущее выполнение.

Повторы следует разрешать только для временных классов сбоев и выполнять с ограниченной экспоненциальной задержкой и случайным разбросом.

• Политике повторов нужен лимит попыток, чтобы постоянные ошибки не занимали ресурсы бесконечно.
• Экспоненциальные задержки снижают давление на восстанавливающуюся зависимость, а случайный разброс предотвращает синхронные волны повторов.
• Ошибки валидации, несовместимые схемы и неверные параметры должны завершаться без повтора, потому что повторение их не изменит.
• Безопасность повторов зависит от идемпотентности задачи и одинакового контракта логических входов для каждой попытки.

В оркестрации пайплайнов нужны отдельные лимиты времени для ожидания, выполнения задачи и всего запуска процесса.

• Таймаут очереди ограничивает ожидание воркера или дефицитного ресурса до признания задачи неуспешной.
• Таймаут выполнения ограничивает процесс задачи после фактического старта и должен оставлять время на корректное завершение до принудительной остановки.
• Таймаут сенсора или внешней операции ограничивает общее время ожидания с учётом повторных проверок и отсрочек.
• Таймаут процесса ограничивает запуск целиком, даже если каждая отдельная задача укладывается в собственный лимит.

Кеш задачи повторно использует результаты, только если ключ кеша отражает все входы, способные повлиять на результат.

• Ключ обычно включает код компонента или дайджест образа, версии входных артефактов, параметры и значимую конфигурацию.
• Кешированные артефакты должны оставаться неизменяемыми и доступными не меньше срока жизни записей об их метаданных.
• Недетерминированные входы вроде текущего времени, случайных начальных значений или изменяемых внешних таблиц нужно зафиксировать или включить в ключ.
• Кеширование следует отключать для намеренных побочных эффектов, например уведомлений или публикации модели.

Возобновление пайплайна пропускает уже зафиксированные задачи, а сохранение контрольных точек позволяет восстановить прогресс внутри одного долгого вычисления.

• Оркестратор возобновляет работу по сохранённым состояниям задач и проверяет доступность успешных результатов.
• Возобновлённый запуск должен сохранять исходные параметры и версии входов, если намеренно не создан новый запуск.
• Код обучения периодически записывает в долговечное хранилище контрольные точки с состояниями модели, оптимизатора, планировщика и хода обучения.
• Восстановленная из контрольной точки задача всё равно должна публиковать финальный артефакт через обычный атомарный контракт результата.

Планировщик Airflow превращает разобранные определения DAG и интервалы расписания в готовые к запуску экземпляры задач.

• Обработчики DAG разбирают файлы и сериализуют структуру DAG, поэтому планирование не зависит от импорта кода на воркерах.
• Планировщик создаёт DagRuns, проверяет зависимости задач и правила запуска и переводит доступные экземпляры к состоянию «в очереди».
• До передачи задач исполнителю он применяет ограничения пулов, конкурентности DAG и максимального числа активных запусков.
• Несколько планировщиков координируются через базу метаданных, чтобы решения о планировании оставались согласованными.

Исполнитель Airflow распределяет поставленные в очередь экземпляры задач по вычислительным ресурсам, а воркеры запускают процессы задач.

• LocalExecutor запускает процессы задач на хосте планировщика и подходит для развёртывания на одной машине.
• CeleryExecutor отправляет задачи через брокер постоянному пулу воркеров, которые получают и выполняют их.
• KubernetesExecutor создаёт отдельный под для каждой задачи, позволяя выбирать собственный образ и запросы ресурсов.
• Состояние задач и координация остаются на уровне управления Airflow, даже когда выполнение происходит на внешних воркерах.

Airflow XCom должен содержать небольшие значения или ссылки для обмена между задачами, а не крупные ML-артефакты.

• Типичные значения включают URI объектного хранилища, идентификатор раздела, версию модели или компактные метаданные состояния.
• По умолчанию строки XCom находятся в слое метаданных, поэтому крупные данные повышают расходы базы и сериализации.
• Большие датасеты, контрольные точки и модели должны лежать в долговечном хранилище артефактов, а в XCom остаются только ссылки.
• Пользовательский бэкенд XCom на объектном хранилище может выгружать сериализованные значения, но явные контракты артефактов понятнее.

Режимы сенсоров Airflow отличаются тем, занимает ли ожидание слот воркера и как назначается следующая проверка.

• В режиме poke задача ожидает внутри запущенного процесса и сохраняет за ней слот воркера между проверками.
• Режим reschedule освобождает слот воркера и просит планировщик выполнить новую проверку позже.
• Отложенный сенсор передаёт ожидание асинхронному компоненту triggerer и возобновляет задачу, когда срабатывает её триггер.
• Для долгого ожидания обычно подходят отложенный режим или reschedule, а для коротких проверок может быть оправдан режим poke.

Пулы Airflow и ограничения конкурентности сдерживают разные области готовых к запуску экземпляров задач.

• Пул представляет общий ресурс, например GPU-задачи или доступ к сервису с ограничением частоты запросов, а задачи занимают настроенное число слотов.
• Глобальный параметр parallelism ограничивает число экземпляров задач во всей установке Airflow.
• Ограничение конкурентности на уровне DAG задаёт число одновременных экземпляров задач одного DAG во всех активных запусках.
• Параметр maximum active runs ограничивает пересекающиеся DagRuns и не даёт частому расписанию многократно увеличить нагрузку на последующие этапы.

Спецификация компонента Kubeflow Pipelines определяет переносимый типизированный интерфейс и контейнерное выполнение его реализации.

• Входы и выходы объявляют имена параметров или артефактов, типы и необязательные значения по умолчанию.
• Секция контейнера фиксирует образ, команду, аргументы и плейсхолдеры, связывающие объявленные входы и выходы.
• Запросы ресурсов, окружение, параметры кеширования и настройки конкретной платформы можно добавить при использовании компонента.
• Стабильный контракт компонента позволяет авторам пайплайна менять версии реализации без изменения связей с последующими компонентами.

Kubeflow Pipelines использует параметры для небольших значений, а типизированные артефакты для долговечных файловых результатов.

• Параметры переносят скалярные или структурированные управляющие значения, которые бэкенд подставляет в аргументы компонента.
• Артефакты предоставляют путь или URI хранилища вместе с типом и метаданными, не встраивая сами данные в состояние пайплайна.
• Среда выполнения назначает расположение входов и выходов и записывает происхождение артефактов в сервис метаданных.
• Объявленные типы артефактов Dataset, Model и Metrics делают совместимость и происхождение видимыми между компонентами.

Компиляция Kubeflow превращает программу построения пайплайна в статический пакет PipelineSpec для отправки.

• Вызовы компонентов становятся узлами задач с явными зависимостями, каналами входов, каналами выходов и плейсхолдерами.
• Управляющие конструкции вроде условий, циклов и обработки завершения кодируются в промежуточном представлении.
• Компилятор проверяет связи графа и совместимость типов, которые можно определить без значений среды выполнения.
• Позже бэкенд создаёт запуск из пакета и разрешает параметры среды выполнения, расположение артефактов и платформенные детали выполнения.

Argo WorkflowTemplates хранят переиспользуемые определения процессов и шаблонов, которые объекты Workflow могут подключать по ссылке или запускать.

• Шаблон может определять шаги, задачи DAG, контейнеры, скрипты, входы, выходы и настройки синхронизации.
• Workflow может ссылаться на WorkflowTemplate в пространстве имён через templateRef вместо копирования его реализации.
• ClusterWorkflowTemplates дают переиспользование на уровне кластера и поэтому требуют осознанного управления доступом.
• Версионированные имена шаблонов или манифесты под управлением Git привязывают вызывающие стороны к проверенному контракту выполнения.