Явная договорённость между источником и потребителем: какие поля, каких типов и с какими гарантиями.
Ключевые тезисы
- Контракт описывает схему, семантику полей, по свежести и правила изменения.
- Обратно совместимые изменения (добавление поля) разрешены, ломающие — только через версию.
- Реестр схем (Schema Registry) делает контракт исполняемым, а не документом на вики.
Подробный разбор
- Схема: поля, типы, обязательность, допустимые значения.
- Семантика: что именно означает поле и в каких единицах.
- : частота обновления, максимальная , ожидаемый объём.
- Правила изменения: что считается обратно совместимым, а что требует новой версии.
- Владелец: кто отвечает за источник и кому писать при поломке.
- Схема описывается машиночитаемо (Avro/Protobuf/JSON Schema) и лежит в реестре.
- Продюсер валидирует данные при записи, а не потребитель при чтении.
- CI источника падает при ломающем изменении схемы.
- Нарушения контракта видны на дашборде и имеют владельца.
Для ML контракт особенно важен: модель зависит от распределения , а не только от их наличия. Поэтому в контракт полезно включать и ожидаемые статистики.
Видеолекции
Тайм-кода именно на эту тему в записях нет. Но глава «Инженерия данных» разобрана в курсе целиком — с той оговоркой, что место в записи придётся искать самому.
Связанные темы
Надёжность данных · Безопасность и приватность ML · Безопасная эксплуатация
Monitoring93%
Мониторинг · MLOpsНаблюдение за инфраструктурой, данными и качеством предсказаний после релиза.
Data Quality85%
Качество данных · Инженерия данныхАвтоматические проверки, которые ловят поломку источника раньше, чем она попадёт в модель.
Idempotency & Exactly-once85%
Идемпотентность и гарантии доставки · Инженерия данныхЧто происходит при повторной обработке события и как не задвоить данные.
Change Data Capture85%
Захват изменений (CDC) · Инженерия данныхЧтение журнала изменений базы вместо периодических полных выгрузок.
Feature Stores85%
Хранилища признаков · MLOpsЦентрализованное хранилище признаков, единое для обучения и онлайн-инференса.
Data leakage85%
Утечка данных · ДанныеСитуация, когда в обучении присутствует информация, недоступная в момент реального предсказания. Главная причина «слишком хороших» метрик.
Data leakage85%
Утечка данных · Практика MLСамая дорогая ошибка в ML: модель отлично работает офлайн и разваливается в проде.
Data preprocessing85%
Предобработка данных · ДанныеПриведение сырых данных к виду, пригодному для обучения: типы, форматы, дубликаты, согласованность единиц измерения.
Secure Inference75%
Защита инференса · Безопасность ИИПериметр вокруг работающей модели: что происходит с запросом до того, как он дойдёт до весов, и после того, как ответ получен.
AI Governance75%
Управление рисками ИИ · Безопасность ИИПроцесс вокруг модели: классификация риска, документация, контроль изменений и ответственность за решения.
Reliability75%
Отказоустойчивость · Системный дизайн ML-сервисовЧто происходит, когда модель недоступна, отвечает медленно или выдаёт мусор.
Observability75%
Наблюдаемость · Системный дизайн ML-сервисовЛоги, метрики и трассировки, по которым можно восстановить, что произошло с конкретным запросом.
Privacy and Security70%
Приватность и безопасность · Системный дизайн ML-сервисовПерсональные данные, доступы и специфические для ML риски.
Agents70%
Агенты · Генеративный ИИLLM, которая планирует, вызывает инструменты и итеративно движется к цели.
Prompting70%
Промптинг · Генеративный ИИУправление поведением модели через формулировку запроса, без изменения весов.
Профильная компетенция для роли: Data Engineer.
Усиливает профиль: Аналитик данных, MLOps-инженер.
Спрашивают на собеседовании: Сбер — Промышленный ML и MLOps, ВТБ — Данные и витрины, билайн — Продукты на данных, BI.ZONE — Данные и аналитика угроз.
Тема встречается в тестах по направлениям — ошибки приведут обратно на эту страницу.
Разбор архитектуры, где эта тема — один из кирпичей: требования, развилки, цифры и режимы отказа.
Глава «Инженерия данных» последний раз правилась . Нашли ошибку — напишите.