Что значит надежный ML/data pipeline
Что для вас надежный pipeline и как проверить, что он действительно надежен?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Надёжный pipeline корректен, идемпотентен, наблюдаем, восстановим и понятен другим людям. Проверяйте его тестами, data-quality checks, freshness alerts, monitoring, backfill/replay drills, rollback и документацией/runbook.
Подробный разбор
Надежность - это не только зеленый DAG. Pipeline должен стабильно производить корректный результат, безопасно переживать retries, иметь владельца, метрики, alerts, понятный recovery path и документацию. Если его может чинить только один человек, он не надежен организационно.
Проверки нужны на нескольких уровнях: unit tests для transformations, integration tests для зависимостей и schemas, data-quality checks для row counts/nulls/duplicates/distributions/freshness, monitoring для task duration, queue time, failure rate, artifact size и publish status. Для ML добавляются feature schema compatibility, model metric regression, prediction distribution, drift и latency.
Хороший pipeline умеет backfill/replay, не портит данные при повторном запуске, логирует версии входов/выходов и имеет rollback к предыдущему артефакту. Runbook должен объяснять, что делать при падении, stale data и просадке качества.
Типичные ошибки
- Считать, что зеленый Airflow task означает хорошие данные.
- Не делать data-quality checks.
- Оставить pipeline без owner, runbook и rollback.
Как сказать на собеседовании
- Перечислите tests, monitoring, alerts, backfill и rollback.
- Скажите, что green DAG не гарантирует good data.
Модуль Kubernetes, сервис, развертывание и узел
Объясните разницу между модулем Kubernetes, сервисом, развертыванием и узлом.
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Узел — это рабочая машина, модуль — наименьшая планируемая единица, содержащая один или несколько контейнеров, развертывание управляет нужными репликами и развертываниями, а служба обеспечивает стабильную работу сети и балансировку нагрузки для модулей.
Подробный разбор
Узел Kubernetes — это рабочая машина, физическая или виртуальная, на которой работают модули. У него есть kubelet, среда выполнения контейнера и сеть, необходимые для размещения рабочих нагрузок.
Модуль — это наименьший планируемый модуль Kubernetes. Обычно он содержит один контейнер приложения, но может содержать тесно связанные дополнительные приложения, которые совместно используют сетевое пространство имен и тома. Поды эфемерны; их можно убить и воссоздать с разными IP-адресами.
Развертывание — это контроллер для реплицируемых рабочих нагрузок без отслеживания состояния. Он управляет набором реплик, желаемым количеством реплик, чередующимися обновлениями, откатами и изменениями шаблонов модулей. Обычно вы обновляете развертывание, а не создаете модули вручную.
Служба обеспечивает стабильную сетевую идентификацию и абстракцию балансировки нагрузки для набора модулей, выбранных по меткам. Поскольку IP-адреса модулей меняются, клиенты обычно вызывают DNS/имя службы, а не отдельные модули.
Типичные ошибки
- Назовите модуль машиной, а не планируемой единицей рабочей нагрузки.
- Путайте развертывание с выпуском кода.
- Забудьте, что сервисы выбирают поды по меткам и скрывают изменение IP-адресов подов.
Как сказать на собеседовании
- Ответьте одним предложением на каждый примитив, а затем соедините их посредством развертывания, создавая модули на узлах позади службы.
- Используйте пример показа модели, если интервьюер работает на платформе ML.
Зачем промышленному ML нужны MLflow, пайплайны, PySpark и хранилище признаков
Какие задачи в промышленном ML решают MLflow, воспроизводимые пайплайны, PySpark и хранилище признаков?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
MLflow фиксирует эксперименты и версии моделей, пайплайны воспроизводят весь расчёт, PySpark обрабатывает большие данные, а хранилище признаков согласует обучение и онлайн-применение.
Подробный разбор
MLflow или аналогичный реестр связывает параметры обучения, код, данные, метрики и артефакт модели. Это позволяет сравнить эксперименты, понять происхождение версии и безопасно продвинуть её между средами.
Оркестратор пайплайнов задаёт зависимости, расписание, повторные запуски и наблюдаемость этапов подготовки данных, обучения, проверки и публикации. PySpark нужен не «для промышленности вообще», а когда объём и характер преобразований действительно требуют распределённой обработки.
Хранилище признаков задаёт единые определения и временную корректность признаков для обучения и применения. Оно помогает избежать расхождения между пакетным расчётом и онлайн-сервисом, но не заменяет контроль качества данных, версионирование и владельцев признаков.
Типичные ошибки
- Перечислять инструменты, не объясняя, какую неисправность предотвращает каждый из них.
- Не различать вычисление признаков для истории и получение свежих значений при запросе.
- Забывать о версиях данных, кода, модели и схеме безопасного отката.
Как сказать на собеседовании
- Свяжите каждый инструмент с одной конкретной обязанностью системы.
- Отдельно объясните, как избежать расхождения признаков при обучении и применении.