Один и тот же набор данных не должен существовать дважды, чтобы быть полезным. Однако в большинстве сред это происходит. Одна версия хранится в файловой системе, предназначенной для корпоративных пользователей и приложений, которые ожидают путей, каталогов и изменяемого состояния. Другая версия экспортируется в объектное хранилище, чтобы распределенные движки и конвейеры искусственного интеллекта могли эффективно ее обрабатывать. Эти копии создаются не намеренно. Они являются артефактами несовместимых интерфейсов хранения, пишет на портале BigDataWire Арон Бранд, технический директор CTERA.

В небольших масштабах это дублирование допустимо. В масштабах ИИ оно становится структурной неэффективностью. Объемы хранения увеличиваются быстрее, чем сами данные, конвейеры накапливают логику синхронизации, а вычисления все больше зависят от перемещения данных, а не от их обработки.

Почему это происходит?

Две модели, два предположения о данных

Файловые системы и объектные хранилища не являются взаимозаменяемыми абстракциями. Они кодируют принципиально разные предположения о том, как ведут себя данные.

Файловые системы отдают приоритет структуре, координации и изменяемости. Объектное хранилище отдает приоритет экзабайтному масштабу, простоте и параллелизму.

Ни одна из моделей не является ошибочной. Каждая оптимизирована для разных классов рабочих нагрузок. Проблема в том, что современные конвейеры данных требуют одновременного применения обеих моделей.

Рабочие нагрузки ИИ охватывают оба мира

Конвейеры ИИ не всегда четко согласуются с одной из парадигм.

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

Это создает постоянное несоответствие.

На практике организации компенсируют это перемещением данных. Файловые наборы данных экспортируются в объектное хранилище для аналитики. Объектные данные восстанавливаются в файловых системах для последующих рабочих процессов. Конвейеры расширяются, включая этапы подготовки, копирования и преобразования в качестве основных шагов. То, что начинается как интеграция, превращается в зависимость, и в конечном итоге конвейер формируется скорее ограничениями хранилища, чем логикой данных.

Объектное хранилище как плоскость данных ИИ

Объектное хранилище стало основой по умолчанию для крупномасштабной аналитики и ИИ, поскольку оно соответствует поведению современных вычислительных систем.

Распределенные задачи обучения, механизмы запросов и конвейеры обработки признаков предполагают параллельный доступ, взаимодействие без сохранения состояния и большие последовательные операции чтения на неизменяемых наборах данных. Объектное хранилище естественным образом удовлетворяет этим предположениям.

Недавние достижения укрепили эту роль. Высокопроизводительное объектное хранилище все чаще поддерживает прямые пути передачи данных, такие как S3 через RDMA, что снижает участие ЦП и позволяет данным перемещаться непосредственно в память графического процессора. На этом этапе пропускная способность хранилища — это не просто фоновая проблема. Она напрямую определяет использование вычислительных кластеров.

Это имеет архитектурные последствия. При пропускной способности в сотни Гбит/с любой слой, который перехватывает или преобразует операции ввода-вывода между вычислительными ресурсами и объектным хранилищем, вносит накладные расходы на ЦП и ограничивает пропускную способность. В масштабах ИИ эти накладные расходы уже не являются незначительными. Часто они становятся узким местом.

Файлы как интерфейс для агентов ИИ

Если объектное хранилище становится плоскостью данных, то файлы вновь становятся плоскостью управления для систем, управляемых ИИ, в рамках федеративной ткани данных.

Агенты ИИ обладают состоянием. Они создают контекст, сохраняют промежуточные результаты и координируют действия во времени. Файловая система поддерживает это естественным образом: каталоги организуют работу, пути кодируют связи, а само пространство имен становится общей памятью, в которой могут перемещаться как люди, так и агенты.

В отличие от этого, объектное хранилище является плоским. Агенты должны восстанавливать структуру, выводить связи и управлять состоянием извне, что добавляет сложности.

Файловая система делает контекст явным и непосредственно используемым. Это особенно важно для мультиагентных рабочих процессов. Файлы выступают в качестве уровня координации, где агенты взаимодействуют, читая и записывая артефакты, организуя задачи и отслеживая прогресс в общем рабочем пространстве.

Сдвиг происходит не в плане ухода от объектного хранилища, а в сторону наложения на него семантики файлов. Объектное хранилище остается масштабируемой основой, в то время как файлы обеспечивают интерфейс, который лучше соответствует тому, как работают агенты: управление контекстом, памятью и взаимодействием.

Компромиссные подходы создают новые узкие места

Исторически усилия по унификации доступа к файлам и объектам принимали две формы.

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

Подходы, основанные на шлюзах, преобразуют протоколы в реальном времени, предоставляя доступ к файловым данным через объектные API. Это позволяет избежать дублирования, но вносит накладные расходы на преобразование, зависящие от ЦП, и ограничивает пропускную способность.

Оба подхода решают часть проблемы, но усиливают другую. Один оптимизирует формат данных, другой — согласованность доступа. Ни один из них не устраняет фундаментальное несоответствие.

К унифицированной архитектуре хранения

В современных платформах данных наблюдается тенденция к конвергенции, а не к трансляции.

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

Разница очевидна и существенна. Промежуточные этапы исчезают. Данные не нужно перемещать, изменять или повторно предоставлять, прежде чем их можно будет использовать.

Хранилище перестает быть чем-то, вокруг чего работают конвейеры, и становится тем, с чем они работают напрямую. Для инженеров данных это коренным образом меняет проектирование конвейеров. Вместо того чтобы рассматривать перемещение данных как необходимое условие, конвейеры могут работать непосредственно с авторитетным набором данных. Доступ заменяет извлечение в качестве первого шага. Преобразование и анализ выполняются без промежуточных этапов.

Это снижает сложность конвейера, повышает актуальность данных и уменьшает накладные расходы на хранение. Что еще важнее, это восстанавливает согласованность между вычислительными ресурсами и данными. Рабочие нагрузки выполняются там, где данные уже существуют, вместо того, чтобы ждать их перемещения.

Это также открывает новые возможности для взаимодействия. Существующие наборы объектных данных могут быть немедленно доступны в виде файловых систем без миграции. Данные, создаваемые приложениями, могут использоваться конвейерами ИИ в режиме реального времени. Агенты могут работать непосредственно с живыми наборами данных, используя файловую семантику для навигации и одновременно объектное хранилище для масштабируемости.

Заключение

Файловое и объектное хранение не являются конкурирующими парадигмами. Это взаимодополняющие абстракции, которые развивались в различных условиях.

Изменилась природа рабочих нагрузок. Системы ИИ, и все чаще агенты ИИ, требуют и того, и другого. Им необходима масштабируемость и параллелизм объектного хранилища, а также структура и доступность файловых систем.

Поддержание их в качестве отдельных систем заставляет инженеров данных преодолевать разрыв посредством копирования, преобразования и оркестровки. Такой подход не масштабируется. Сейчас наметился способ решения этой проблемы. Благодаря конвергенции доступа к файлам и объектам в единую, федеративную ткань данных, хранилище данных становится соответствующим тому, как на самом деле работают современные системы. Оно перестает быть чем-то, что конвейеры обходят стороной. Оно становится частью самой модели выполнения.