Инженеры, автоматизировавшие учение по изоляции региона, сохранили сервисные метрики с шагом тридцать секунд в формате Parquet в S3-совместимом хранилище, агрегировали их через DuckDB, а классификацию результатов failover поручили ИИ-агенту. Прототип выпустил структурированные отчеты без общего lakehouse и каталога, но движок запросов никуда не исчез. Он стал встроенным компонентом внутри агентного процесса. Этот вывод важен, потому что команды теперь выбирают между легкими агентными конвейерами и управляемыми платформами данных.

ИИ-агенты меняют доступ к данным, а не потребность в СУБД

Как работал конвейер анализа учений

Во время учений один регион намеренно изолировали, а трафик должен был перейти в surviving регионы. По каждому сервису команде нужно было проверить факт переключения трафика, поведение success rate и задержек, а затем классифицировать итог. Сырые метрики экспортировали, преобразовали в самодостаточные Parquet-активы с манифестами и хранили в версионированных каталогах для каждого учения. Затем агент выбирал нужные входы, генерировал ограниченный DuckDB SQL или Python и запускал вычисления для ответа на три операционных вопроса.

Архитектура включала три логических слоя: подготовку данных, детерминированные вычисления и интерпретацию через агента, а воспроизводимость обеспечивалась сквозным образом. DuckDB работал по обе стороны хранилища: на загрузке читал сырые записи, сортировал и сжимал их, а также формировал контрольную статистику для манифеста. На этапе анализа он фильтровал временные окна, соединял метаданные сервисов и вычислял компактные пакеты фактов с объемами трафика, метками времени, процентными изменениями и статусом SLO. Повторно используемая логика сборки создавалась один раз, а входы, факты, конфигурация и метаданные запусков сохранялись для повтора.

Контроль обеспечивал детерминированный слой проверки между генерацией и исполнением. Агент создавал только read-only запросы по заданным таблицам и временным диапазонам, которые сверялись с allowlist доступных наборов данных и операций. Одобренные запросы выполнялись в изолированной песочнице, а прикладной код превращал строки в пакет фактов, не позволяя модели придумывать значения. Авторы подчеркивают, что DuckDB не подавался как универсально лучший вариант, чем Spark, Trino или управляемый lakehouse. Нагрузке пока просто не требовался общий распределенный движок.

Что это значит для решений о платформе данных

Для компаний, внедряющих ИИ-аналитику, такой подход снижает порог входа в анализ инцидентов и учений. Небольшая команда может хранить Parquet-файлы в объектном хранилище, повторно использовать встроенную логику агрегации и запрашивать у агента объяснения без каталога и кластера. Крупная организация с регулярными учениями по многим сервисам может один раз стандартизировать манифесты, проверку и пакеты фактов, а затем масштабировать интерпретацию. В обоих случаях видимый интерфейс меняется: вместо панелей и ручных запросов появляется запрос с ответом, подкрепленным доказательствами.

Ограничение в том, что суждение заслуживает доверия, только если лежащие в его основе факты детерминированы. Рост QPS может оказаться недостаточным для поглощения потерянного трафика, снижение success rate может включать ожидаемые бизнес-отклонения, а всплеск задержек может быть безвредным при быстром возврате к стабильному состоянию. Агент разрешал такие противоречия, сравнивая переходное и стабильное окна, уровень сервиса, насыщение зависимостей и поведение очередей. Новость не означает, что SQL, таблицы и управление данными устарели, поэтому перед внедрением стоит спросить, что входит в allowlist, как устроены песочница, версионирование и независимая проверка.

Маркером станет широкое закрепление принципа determinism split: точные вычисления остаются в движках и коде, а контекстные рассуждения переходят к моделям. Если больше команд опубликуют агентные конвейеры со встроенными движками, манифестами и четырьмя сигналами для перехода на управляемый lakehouse, разделение станет практикой. Если воспроизводимость и контроль доступа будут отставать, предприятия сохранят централизованные платформы как стандарт для регулируемой аналитики.