Развитие управления данными в организации

Поддержка деятельности по машинному обучению с помощью более дисциплинированного управления данными

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

Одним из первых примеров является TRILL от Microsoft, который используется в развертываниях SCOPE и YARN. Клиентская библиотека Google F1 Query служит вторым примером. Эта библиотека используется в Google разнообразными рабочими нагрузками, включая их механизм обработки потока данных, механизм запросов почти в реальном времени Procella и их озеро данных Napa. Google и Microsoft были первыми новаторами в использовании фреймворков MapReduce и дезагрегации вычислительных хранилищ. Именно в этих развертываниях «озера данных» закрепилось использование общей библиотеки ускорения базы данных.

Параллельно с Google и Microsoft, Databricks и их проект Spark возникли в Калифорнийском университете в Беркли. Примерно в то же время Meta (ранее Facebook) выпустила свой механизм запросов Presto SQL. Как Spark-SQL, так и Presto SQL представляют собой механизмы обработки запросов с массовым параллелизмом, которые работают с данными, которые находятся в удаленном дезагрегированном хранилище. Другими словами, механизмы запросов Databricks и Presto работают в той же области озера данных, что и Google и Microsoft. Разница между ними заключается в том, что Spark-SQL — это приложение на основе Scala, работающее в вычислительной среде Spark. Напротив, механизм запросов Presto не зависит от конкретной вычислительной среды. Фактически, сообщество Presto позволило Presto работать как приложение Spark на основе Scala. В этом развертывании функция Presto предоставляется в виде библиотеки на основе Java.

Компания Databricks недавно представила собственную библиотеку ускорения базы данных Photon на основе C++ как часть своей платформы «программное обеспечение как услуга» (SaaS) на основе Spark. Photon является собственностью Databricks, поэтому, как и библиотеки Google F1 Query и Microsoft TRILL, недоступны для общего сообщества разработчиков. С сегодняшним объявлением о программном обеспечении с открытым исходным кодом (OSS), собственной библиотеке ускорения баз данных Velox на основе C++, разработчики получили альтернативу этим проприетарным библиотекам с закрытым исходным кодом.

Более года Intel работает с Meta, Ahana, Voltron и другими участниками сообщества Velox. Наш вклад двоякий. Во-первых, мы работаем с Meta и Voltron, чтобы использовать проект Apache Arrow в качестве стандартного столбчатого представления для обмена данными между библиотекой Velox и другими библиотеками и приложениями. Intel расширяет Velox поддержкой абстрактного представления вычислительной модели механизма запросов с использованием проекта Substrait.io. Во-вторых, проект Intel OAP на основе OSS был рефакторинг для поддержки библиотеки Velox.

Мы предполагаем, что разнообразный набор движков запросов будет реорганизован, чтобы перенести их вычисления в библиотеку Velox. К ним относятся механизмы потоковой обработки, такие как Apache Flink, механизмы запросов почти в реальном времени, такие как Apache Druid, Apache Pinot и другие. Механизмы запросов озера данных, такие как PrestoDB, и конвейеры управления данными, поддерживаемые платформами машинного обучения (ML), такими как PyTorch, TensorFlow и другими.

Мы работаем над набором конвейеров управления данными для поддержки платформы системы рекомендаций. К ним относятся:

  1. Автономный пакетный конвейер ETL на основе PrestoDB для записи данных в формате Parquet в озеро данных.
  2. Конвейер предварительной обработки на основе PyTorch для обработки преобразования этих файлов Parquet в плотные встроенные функции, которые будут использоваться графическими процессорами при обучении моделей, используемых в процессах отзыва и ранжирования механизма рекомендаций.
  3. Возможность поиска сходства векторов на основе Spark-SQL:
    Во-первых, конвейер пакетного обслуживания, который можно настроить для использования таких библиотек, как FAISS, HSNW и других, для создания функции, встраивающей инвертированный индекс на основе предварительно обученной модели.< br /> Во-вторых, механизм запросов, который выполняет поиск сходства векторов пользователя с использованием индекса, созданного на предыдущем шаге.
  4. Конвейер на основе Flink, который обрабатывает микропакеты событий журнала взаимодействия с пользователем для обновления встроенных функций, используемых в предварительно обученной модели ранжирования.

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

Я представлю более подробную информацию об этом Сквозном управлении данными в поддержку ML RecSys на предстоящем семинаре по компонуемым системам управления данными (CDMS) в пятницу, 9 сентября. Семинар является частью ежегодного Международного Конференция по очень большим базам данных (VLDB) пройдет в этом году в Сиднее, Австралия. Meta опубликует свою статью Velox: унифицированный механизм выполнения Meta в промышленной версии VLDB, а пока вы можете прочитать Представляем Velox: унифицированный механизм выполнения с открытым исходным кодом.