Архитектуры данных без границ: возможности ИИ-агентов там, где хранятся ваши данные
При поддержке Google Cloud
Последние два десятилетия облако было краеугольным камнем модернизации практически во всех отраслях, позволяя предприятиям передать управление инфраструктурой на сторону и сосредоточиться на бизнес-инновациях. Но некоторые данные никогда не должны были никуда переезжать. Нормативные, операционные и бизнес-требования давно удерживали определённые рабочие нагрузки за пределами публичного облака, а предприятиям нужен доступ к современным технологиям работы с данными везде, где эти данные находятся.
Сегодня ИИ делает эту потребность ещё более острой. Стремясь применять ИИ к своим данным, предприятия хотят получить в собственных ЦОД те же лучшие в своём классе возможности, что и в облаке.
ИИ-агентам нужен интеллектуальный доступ к данным, где бы те ни находились. Поэтому всё важнее предоставлять современные возможности ИИ и работы с данными в облаке, на периферии и в частных ЦОД, а не требовать переноса каждой рабочей нагрузки и каждого набора данных в одно место. Эта реальность уже отражается в планировании корпоративного ИИ. Опрос IDC, охвативший более 1 300 лиц, принимающих решения в области ИИ, показал: хотя респонденты ожидают, что большинство ИИ-нагрузок будет размещено в облаке, часть останется локальной — особенно системы, напрямую взаимодействующие с физическим миром. Именно поэтому нынешние усилия по модернизации всё чаще описывают в терминах «безграничных» архитектур данных. Речь идёт о том, чтобы задействовать данные там, где они находятся. Это соответствует реальному положению дел в большинстве корпоративных ИТ-ландшафтов. Данные уже распределены по нескольким облакам, локальным системам и платформам с многолетней историей. Новая архитектурная задача состоит не в том, чтобы всё централизовать, а в том, чтобы дать агентам единый доступ к нужным им данным и метаданным во всех этих средах.
Непрерывность бизнеса теперь требует непрерывности данных
Раньше обеспечить непрерывность бизнеса было просто: поддерживать приложение в рабочем состоянии, а транзакции — в движении. Публичные облака стали исключительно хороши в обеспечении доступности и отказоустойчивости в нескольких регионах, необходимых для выполнения этих требований большинством компаний. Но у крупных коммунальных компаний, организаций здравоохранения, банков и производителей есть нагрузки, которые должны работать при любых обстоятельствах, и они не могут допустить зависимости от какого-либо одного поставщика ни в одной части своего критически важного бизнеса.
Приложениям всё чаще нужны как данные в реальном времени, так и исторические данные, чтобы отвечать на ключевые бизнес-вопросы. Это подтолкнуло компании к объединению операционных и аналитических систем, долгое время существовавших раздельно. ИИ-агенты повышают ставки: чтобы рассуждать и действовать, им нужно и то и другое одновременно. Поддерживать приложение в рабочем состоянии недостаточно, если оно теряет доступ к данным, от которых зависит.
Возьмём сценарий «вынужденного выхода» (stressed exit). Договорная проблема или сбой у поставщика может вынудить компанию срочно перенести критически важную нагрузку. Что произойдёт, если такое решение придётся принять за одну ночь, сохранив при этом непрерывность обслуживания клиентов?
Это меняет представление об успешном переходе на резервную систему. Недостаточно просто перезапустить приложение в другом месте. Приложения должны сохранять единое представление о данных в реальном времени и исторических данных, даже когда меняется нижележащая инфраструктура. Для критически важных нагрузок это может потребовать полной реплики, работающей локально или у второго поставщика, с одной и той же реализацией базы данных в каждой среде. Цель — непрерывность без перестройки слоя данных посреди кризиса.
Агентному ИИ нужен слой данных по принципу «написал один раз — запускай где угодно»
Компании полагаются на облачных провайдеров в выполнении основной работы по управлению инфраструктурой. Но работа во всё большем числе сред не должна означать перепроектирование архитектуры для каждой площадки. Когда разработчикам приходится жонглировать разными СУБД в облаке и локальных средах, возникают трения, замедляющие агентов. Разные реализации, диалекты и наборы инструментов заставляют команды тратить время на управление различиями платформ, а не на бизнес-логику.
Вместо этого разработчики должны иметь возможность проектировать, тестировать и отлаживать, используя одно и то же ядро базы данных, одинаковую семантику транзакций и такие возможности, как встроенные в движок графовый, полнотекстовый и векторный поиск, — в облаке, частных ЦОД и других средах.
Такая согласованность снимает и распространённое возражение против безграничной архитектуры данных — разрастание операционной сложности. Вместо того чтобы добавлять новый стек управления для каждой среды, команды могут упаковывать эту технологию для инфраструктуры, которую компании уже используют, включая Kubernetes, виртуальные машины и «голое железо», придерживаясь при этом открытых стандартов, таких как PostgreSQL.
Открытые стандарты дают разработчикам переносимость, не ограниченную одним поставщиком. Это значит, что их вложения можно использовать и за пределами экосистемы конкретного вендора, сохраняя единый технологический стек и унифицированные конвейеры CI/CD. Это упрощает инструментарий, ускоряет проверки на соответствие требованиям и сокращает время вывода на рынок в гибридных, суверенных и мультиоблачных средах.
Интеллект облачного масштаба — для данных, которые нельзя перемещать
Единое представление, от которого зависит непрерывность, — это и то, что обеспечивает работу агентных рассуждений. Агенты поднимают планку ещё выше: им часто нужны операционные и аналитические данные вместе в рамках одной транзакции, независимо от их местоположения.
Эти требования опираются на встроенные примитивы баз данных — графовые структуры, векторное индексирование и полнотекстовый поиск. Графовые возможности, например, позволяют агентам понимать связи между транзакциями, продуктами и пользователями. Объединение этих возможностей позволяет агентам рассуждать на основе свежих операционных данных, не перемещая их между отдельными системами. Новые движки баз данных способны выполнять аналитические запросы до 100 раз быстрее стандартного PostgreSQL.
Но эти возможности не всегда могут размещаться там, где удобнее инфраструктурным командам. Некоторые агентные нагрузки крайне чувствительны к задержкам или по нормативным причинам должны работать в определённых географических границах. Например, DORA — один из регламентов ЕС для финансового сектора — может требовать, чтобы финансовые нагрузки оставались в суверенных средах. Здравоохранение даёт ещё более наглядный пример: электронные медицинские карты и телеметрия пациентов могут не иметь права покидать пределы локальных клинических систем, поэтому предиктивная диагностика и локальный ИИ-инференс должны выполняться за защищёнными межсетевыми экранами.
Модернизация означает доставку этих же возможностей непосредственно туда, где работают нагрузки.
Интеллект баз данных освобождается от нижележащей инфраструктуры
Подобно тому как виртуализация отвязала приложения от физических серверов, интеллект баз данных теперь освобождается от нижележащей инфраструктуры.
Программное обеспечение теперь берёт на себя функции, прежде привязанные к специализированной инфраструктуре, — например, синхронизацию часов для глобальной согласованности и сам слой хранения. В результате возможности баз данных облачного масштаба одинаково работают в облаке, локально, на периферии и в суверенных средах.
Отделение интеллекта баз данных от физического местоположения меняет само понятие модернизации. Руководители в сфере технологий теперь могут доставлять облачные возможности прямо туда, где находятся их данные, а не заставлять переносить нагрузки.
Узнайте, как базы данных Google Cloud работают с вашими данными в локальных, периферийных и мультиоблачных средах благодаря встроенному в движок векторному поиску и агентному ИИ, опирающемуся на достоверные данные.
Радж Пай — вице-президент по управлению продуктами в направлении облачных баз данных Google Cloud.
Спонсорские статьи — это материалы, подготовленные компанией, которая либо платит за публикацию, либо имеет деловые отношения с VentureBeat; такие материалы всегда чётко помечаются. За дополнительной информацией обращайтесь по адресу sales@venturebeat.com.
