8,935 чтения

Руководство архитектора по 10 лучшим инструментам, необходимым для создания современного озера данных

к MinIO8m2024/08/27

Слишком долго; Читать

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

featured image - Руководство архитектора по 10 лучшим инструментам, необходимым для создания современного озера данных

Ранее я писал о современная эталонная архитектура озера данных , решая проблемы каждого предприятия — увеличение объема данных, устаревание инструментария Hadoop (в частности, HDFS) и повышение требований к RESTful API (S3) и производительности — но я хочу заполнить некоторые пробелы.

Современное озеро данных, иногда называемое data lakehouse, представляет собой наполовину озеро данных и наполовину хранилище данных на основе спецификации Open Table Format (OTF). Оба построены на основе современного объектного хранилища.

В то же время мы глубоко задумались о том, как организации могут построить инфраструктуру данных ИИ, которая может поддерживать все ваши потребности в ИИ/МО — а не только сырое хранилище ваших обучающих наборов, проверочных наборов и тестовых наборов. Другими словами, она должна содержать вычисления, необходимые для обучения больших языковых моделей, инструментарий MLOps, распределенное обучение и многое другое. В результате этой линии размышлений мы составили еще одну статью о том, как использовать современное озеро данных Референтная архитектура для поддержки вашего AI/ML потребности. График ниже иллюстрирует современная эталонная архитектура озера данных с акцентом на возможности, необходимые для генеративного ИИ.

Источник: AI/ML в современном озере данных

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

1.Озеро данных

Корпоративные озера данных построены на объектном хранилище. Не ваше старое, основанное на устройствах объектное хранилище, которое обслуживало дешевые и глубокие архивные сценарии использования, а современные, производительные, программно-определяемые и собственные хранилища объектов Kubernetes, краеугольные камни современного стека GenAI. Они доступны как услуга (AWS, GCP, Azure) или локально или гибридно/и то и другое, например MinIO. Эти озера данных должны поддерживать потоковые рабочие нагрузки, должны иметь высокоэффективное шифрование и кодирование стирания, должны хранить метаданные атомарно с объектом и поддерживать такие технологии, как вычисления Lambda. Учитывая, что эти современные альтернативы являются облачными, они будут интегрироваться со всем стеком других облачных технологий — от брандмауэров до наблюдаемости, пользователей и управления доступом — прямо из коробки.

2. Хранилище данных на основе OTF

Объектное хранилище также является базовым решением для хранилища данных на основе OTP. Использование объектного хранилища для хранилища данных может показаться странным, но хранилище данных, построенное таким образом, представляет собой следующее поколение хранилищ данных. Это стало возможным благодаря спецификациям OTF, разработанным Netflix, Uber и Databricks, которые позволяют без проблем использовать объектное хранилище в хранилище данных.

OTF — Apache Iceberg, Apache Hudi и Delta Lake — были написаны, потому что на рынке не было продуктов, которые могли бы справиться с потребностями создателей в данных. По сути, все они (по-разному) определяют хранилище данных, которое может быть построено поверх объектного хранилища. Объектное хранилище обеспечивает сочетание масштабируемой емкости и высокой производительности, чего не могут другие решения для хранения. Поскольку это современные спецификации, у них есть расширенные функции, которых нет у устаревших хранилищ данных, такие как эволюция разделов, эволюция схем и ветвление с нулевым копированием.

Два партнера MinIO, которые могут запустить свое хранилище данных на основе OTF поверх MinIO, — это Dremio и Starburst.

Dremio Sonar (движок обработки хранилища данных)

Dremio Arctic (каталог хранилища данных)

Open Data Lakehouse | Starburst (каталог и механизм обработки)

3. Операции машинного обучения (MLOps)

MLOps для машинного обучения — то же, что DevOps для традиционной разработки ПО. Оба представляют собой набор практик и принципов, направленных на улучшение взаимодействия между инженерными командами (Dev или ML) и командами ИТ-операций (Ops). Цель — оптимизировать жизненный цикл разработки с помощью автоматизации, от планирования и разработки до развертывания и эксплуатации. Одним из основных преимуществ этих подходов является постоянное совершенствование.

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

MLRun (Iguazio, приобретен McKinsey & Company)

MLflow (Databricks)

Kubeflow (Google)

4.Фреймворк машинного обучения

Ваша структура машинного обучения — это библиотека (обычно для Python), которую вы используете для создания своих моделей и написания кода, который их обучает. Эти библиотеки богаты функциями, поскольку они предоставляют набор различных функций потерь, оптимизаторов, инструментов преобразования данных и предварительно созданных слоев для нейронных сетей. Самая важная функция, которую предоставляют эти две библиотеки, — это тензор. Тензоры — это многомерные массивы, которые можно перемещать на GPU. Они также имеют автоматическую дифференциацию, которая используется во время обучения модели.

На сегодняшний день двумя наиболее популярными фреймворками машинного обучения являются PyTorch (от Facebook) и Tensorflow (от Google).

PyTorch

TensorFlow

5.Распределенное обучение

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

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

DeepSpeed (от Microsoft)

Хоровод (из Uber)

Рэй (из Anyscale)

Дистрибьютор Spark PyTorch (от Databricks)

Распределитель Spark TensorFlow (из Databricks)

6. Модельный концентратор

Модельный хаб на самом деле не является частью современной архитектуры эталонных озер данных, но я все равно включаю его, потому что он важен для быстрого начала работы с генеративным ИИ. Hugging Face стал местом, куда можно обратиться за большими языковыми моделями. Hugging Face размещает модельный хаб, где инженеры могут загружать предварительно обученные модели и делиться моделями, которые они создают сами. Hugging Face также является автором библиотек Transformers и Datasets, которые работают с большими языковыми моделями (LLM) и данными, используемыми для их обучения и тонкой настройки.

Есть и другие хабы моделей. Все основные поставщики облачных услуг имеют возможность загружать и делиться моделями, но Hugging Face со своей коллекцией моделей и библиотек стал лидером в этой области.

Обнимающее лицо

7. Структура приложения

Фреймворк приложения помогает включить LLM в приложение. Использование LLM отличается от использования стандартного API. Необходимо проделать большую работу, чтобы превратить запрос пользователя в то, что LLM может понять и обработать. Например, если вы создаете приложение чата и хотите использовать Retrieval Augmented Generation (RAG), вам нужно будет токенизировать запрос, превратить токены в вектор, интегрировать с векторной базой данных (описано ниже), создать подсказку, а затем вызвать свой LLM. Фреймворк приложения для генеративного ИИ позволит вам объединить эти действия в цепочку. Наиболее широко используемым фреймворком приложения на сегодняшний день является LangChain. Он имеет интеграцию с другими технологиями, например, библиотекой Hugging Face Transformer и библиотекой Unstructured для обработки документов. Он многофункционален и может быть немного сложным в использовании, поэтому ниже перечислены некоторые альтернативы для тех, у кого нет сложных требований и кто хочет чего-то более простого, чем LangChain.

TensorFlow (API Keras)

8. Обработка документов

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

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

Неструктурированный

Открыть-анализ

9. Векторные базы данных

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

 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...

Этот ручной поиск по сходству не только трудоемкий и подвержен ошибкам, но и сам поиск очень медленный. Векторная база данных может принять запрос, как показано ниже, и выполнить запрос быстрее и с большей точностью. Возможность быстро и точно выполнять семантические запросы важна, если вы хотите использовать Retrieval Augmented Generation.

 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }

Ниже перечислены четыре популярные векторные базы данных.

10. Исследование и визуализация данных

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

Заключение

Вот вам: 10 возможностей, которые можно найти в современной эталонной архитектуре озера данных, а также конкретные продукты и библиотеки поставщиков для каждой возможности. Ниже приведена таблица, обобщающая эти инструменты.