Definity повышает эффективность конвейера данных на 70%
Источник: VentureBeat · Sean Michael Kerner
Для большинства команд дата-инженерии управление надежностью конвейеров данных (пайплайнов) зачастую означает ожидание оповещения, ручной поиск сбоев в распределенных заданиях и кластерах, а также устранение проблем уже после того, как они ударили по бизнесу. Агентный ИИ требует, чтобы данные были на месте, чистыми и поступали вовремя. Пайплайн, который дает сбой молча или доставляет устаревшие данные, не просто ломает дашборд — он ломает зависящую от него систему искусственного интеллекта.
Именно этот пробел закрывает Definity, чикагский стартап в сфере операций с конвейерами данных, который внедряет агентов непосредственно в драйвер Spark или DBT для работы во время выполнения пайплайна, а не после него. По данным Definity, один из корпоративных клиентов выявил 33% возможностей для оптимизации уже на первой неделе развертывания и сократил трудозатраты на поиск и устранение неисправностей на 70%. Компания также заявляет, что клиенты решают сложные проблемы со Spark до 10 раз быстрее.
«Для агентных операций с данными вам необходимы три ключевые вещи: полный контекст стека в реальном времени с учетом особенностей рабочей среды, контроль над конвейером и возможность валидации в цикле обратной связи. Без этого вы находитесь в позиции стороннего наблюдателя с доступом только для чтения», — рассказал Рой Дэниел, генеральный директор и соучредитель Definity, в эксклюзивном интервью VentureBeat.
В среду компания объявила о привлечении 12 млн долларов в рамках финансирования раунда Серии А под руководством GreatPoint Ventures при участии Dynatrace и существующих инвесторов StageOne Ventures и Hyde Park Venture Partners.
Почему существующий мониторинг пайплайнов не работает при масштабировании
Существующие инструменты подходят к проблеме снаружи уровня выполнения — Datadog (приобретший в прошлом году монитор качества данных Metaplane), системные таблицы Databricks, а также такие платформы, как Unravel Data и Acceldata, считывают метрики после завершения задания. Dynatrace также обладает возможностями мониторинга и участвовал в раунде Серии А компании Definity.
Подход Definity отличается от других вариантов архитектурой решения. По словам Дэниела, это означает, что к тому моменту, когда инструмент мониторинга платформы обнаруживает проблему, пайплайн уже отработал, а сбой, впустую потраченные вычислительные ресурсы или некачественные данные уже ушли вниз по потоку.
«Это всегда постфактум, — отметил Дэниел. — К тому времени, когда вы узнаете, что что-то произошло, это уже произошло».
Как работают встроенные в процесс выполнения агенты Definity
Основное архитектурное отличие заключается в том, где находится агент — внутри пайплайна, а не наблюдает за ним со стороны.
Встроенная инструментация. Система Definity устанавливает JVM-агент непосредственно внутри уровня выполнения конвейера с помощью одной строки кода, работая ниже уровня платформы и извлекая данные о выполнении напрямую из Spark.
Контекст выполнения во время работы. Агент фиксирует поведение выполнения запросов, нагрузку на память, перекос данных, шаблоны перемешивания (shuffle) и использование инфраструктуры по мере работы конвейера. Он также динамически определяет связи (lineage) между пайплайнами и таблицами — никакой предварительно определенный каталог данных не требуется.
Вмешательство, а не просто наблюдение. Агент может изменять распределение ресурсов в середине процесса, остановить задание до того, как плохие данные распространятся дальше, или остановить конвейер на основе состояния вышестоящих (upstream) данных. Дэниел описал случай из продакшена, когда агент обнаружил, что вышестоящее задание было прервано, а входящая таблица, в которую оно должно было писать, оказалась устаревшей, — и остановил нижестоящий пайплайн до его запуска, не допустив попадания некачественных данных в любые зависимые системы.
Что является реальным временем, а что нет. Обнаружение и предотвращение происходят в реальном времени. Анализ первопричин и рекомендации по оптимизации выполняются по запросу, когда инженер обращается к ассистенту, причем полный контекст выполнения уже собран.
Накладные расходы и локализация данных. Агент добавляет примерно одну секунду вычислений на часовой прогон. Внешне передаются только метаданные; для сред, где ни один бит метаданных не должен покидать периметр компании, доступно полное локальное развертывание (on-premise).
Как выглядит интеллект внутри процесса выполнения в продакшене
Одним из первых пользователей платформы Definity стал Nexxen — рекламная технологическая платформа, запускающая крупномасштабные пайплайны Spark для критически важных рекламных нагрузок в локальной инфраструктуре (on-prem).
Деннис Мейер, директор по дата-инженерии в Nexxen, рассказал VentureBeat, что главной проблемой для него были не сбои конвейеров, а накапливающиеся издержки неэффективности в среде без эластичных облачных мощностей, способных поглотить эти потери.
«Главная сложность заключалась не в поломке пайплайнов, а в управлении все более сложной и крупномасштабной средой, — сказал Мейер. — Поскольку мы работаем локально, у нас нет гибкости мгновенной эластичности, поэтому неэффективность напрямую бьет по затратам».
Существующие инструменты мониторинга давали Nexxen частичную видимость, но недостаточную для систематических действий. «У нас уже были внедрены инструменты мониторинга, но нам требовалась видимость на уровне всего стека, чтобы целостно понимать поведение рабочей нагрузки и систематически расставлять приоритеты для оптимизации», — отметил Мейер.
Nexxen развернула Definity без каких-либо изменений в коде пайплайнов. По словам Мейера, команда выявила 33% возможностей оптимизации уже на первой неделе, а инженерные трудозатраты на поиск и устранение неисправностей сократились на 70%. Платформа высвободила инфраструктурные мощности, позволив команде поддерживать рост рабочих нагрузок без дополнительных инвестиций в «железо».
«Ключевым сдвигом стал переход от реактивного устранения неполадок к проактивной непрерывной оптимизации, — сказал Мейер. — В больших масштабах самым большим препятствием часто являются не инструменты, а доступная для анализа видимость».
Что это значит для корпоративных команд по работе с данными
Для команд дата-инженерии, поддерживающих рабочие среды Spark, переход от реактивного мониторинга к интеллекту внутри процесса выполнения имеет архитектурные и организационные последствия, над которыми стоит задуматься.
Операции с пайплайнами становятся проблемой инфраструктуры ИИ. Конвейеры данных, которые раньше обеспечивали аналитику, теперь поддерживают рабочие нагрузки ИИ с прямыми бизнес-зависимостями. Сбои, которые раньше были просто неудобством, теперь блокируют внедрение ИИ в продакшн.
Время на устранение неполадок — это возвратные затраты. По словам Мейера, после развертывания Definity компания Nexxen сократила инженерные усилия на поиск и устранение неисправностей и оптимизацию на 70%. Для небольших команд высвободившееся время для работы над дорожной картой проекта — самый прямой и быстрый аргумент в пользу оценки этого класса решений.



