В недавнем сообщении в блоге сообщества OpenML под названием Поиск стандартного формата набора данных для машинного обучения излагается набор требований к формату данных для работы приложений машинного обучения. В статье сформулированы проблемы хранения данных машинного обучения (которые обычно принимают несколько форм, таких как изображения, аудио, видео, таблицы и т. Д.) В общем, совместно используемом и эффективном формате данных. В нем также обсуждаются сильные и слабые стороны форматов-кандидатов, таких как Arrow / Feather, Parquet, SQLite, HDF5 и CSV. В этом сообщении блога мы объясняем, как TileDB решает все эти требования, преодолевая недостатки других форматов-кандидатов, и пользуемся этой возможностью, чтобы получить отзывы и предложения от сообщества.

TileDB стартовал в Массачусетском технологическом институте и Intel Labs в качестве исследовательского проекта в конце 2014 года. В 2017 году он был выделен в TileDB, Inc., компанию, которая с тех пор собрала около 20 миллионов долларов на дальнейшую разработку и поддержку проекта (см. «Серия A объявление"). TileDB состоит из двух предложений:

  • TileDB Embedded, универсальный механизм хранения, основанный на (плотных и разреженных) многомерных массивах, который представляет собой библиотеку C ++ с открытым исходным кодом (лицензия MIT), которая поставляется с многочисленными языковыми API-интерфейсами, а также интеграция с механизмами SQL и популярными инструментами для анализа данных.
  • TileDB Cloud, коммерческое предложение SaaS для обмена данными планетарного масштаба и бессерверных распределенных вычислений.

TileDB Embedded решает проблемы формата данных OpenML, используя открытый исходный код и открытые спецификации. TileDB Cloud - это ортогональная и дополнительная услуга для тех, кто хочет еще больше продвинуть вперед стрелку, когда дело доходит до обмена данными и вычислений в масштабе всей планеты, с упором на исключительную простоту использования, производительность и экономию средств.

Помимо демонстрации того, как TileDB Embedded может способствовать машинному обучению, мы раскрываем важные проблемы, которые преследуют не только приложения машинного обучения, но также базы данных и многие другие приложения в различных областях, таких как геопространственная, геномика и другие. Специалисты по обработке данных и аналитики искали мощный «формат данных» для решения всех своих проблем с управлением данными, часто требуя, чтобы он был «простым» и «однофайловым». Мы считаем, что сообществу пора принять подход «машины данных», который выходит за рамки простого формата данных. Целью должно быть определение и внедрение чистых и стабильных API-интерфейсов, обеспечивающих постоянное технологическое совершенствование механизмов данных и базовых форматов данных.

Краткое изложение требований

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

  1. Должен быть стандартный способ представления определенных типов данных.
  2. Формат должен позволять хранить большинство (обработанных) наборов данных машинного обучения.
  3. Единый внутренний формат данных для сокращения обслуживания как на стороне сервера, так и на стороне клиента
  4. Поддержка хранения разреженных данных
  5. Поддержка хранения двоичных двоичных объектов и векторов разной длины
  6. Поддержка метаданных
  7. Машиночитаемые схемы (на определенном языке), описывающие форматирование данных определенного типа.
  8. Поддержка нескольких «ресурсов» (например, коллекций файлов или нескольких реляционных таблиц)
  9. Контроль версий, способ увидеть различия между версиями
  10. Обнаружение ошибок переворота битов во время хранения или передачи
  11. Поддержка хранилищ объектов (например, S3, GCS, min.io и т. Д.)
  12. Поддержка пакетных данных и добавления данных (потоковая передача)
  13. Это должно быть полезно для хранения и передачи данных
  14. Быстрое чтение / запись и эффективное хранилище
  15. Потоковое чтение / запись для легкого преобразования и повышения эффективности памяти
  16. Парсеры на различных языках программирования, включая хорошо поддерживаемые и стабильные библиотеки.
  17. Формат должен быть стабильным и полностью поддерживаться активным сообществом.

В следующих разделах подробно объясняется, как TileDB удовлетворяет этим требованиям посредством:

  • многомерный массив модель данных
  • open-spec формат данных
  • универсальный механизм хранения с открытым исходным кодом, а также его различные API-интерфейсы и интеграции, а также
  • растущее сообщество

Модель данных TileDB

Модель данных TileDB удовлетворяет требованиям 1–6.

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

Массив (плотный или разреженный) состоит из:

  • Размеры. Размеры d1 и d2 (рисунок выше) вместе с их доменами ориентируют многомерное пространство ячеек. Кортеж значений измерения, например (4,4), называется координатами ячейки. В массиве может быть любое количество измерений.
  • Атрибуты: в каждой ячейке логического макета TileDB хранит кортеж, состоящий из любого количества атрибутов, каждого типа данных (фиксированного или переменного размера). Все ячейки должны хранить кортежи с одинаковым набором и типом атрибутов. На рисунке ячейка (4,4) хранит целочисленное значение для атрибута a1 и строковое значение для a2, и аналогично все другие ячейки могут иметь значения для a1 и a2.
  • Метаданные массива. Это (обычно небольшие) данные типа "ключ-значение", связанные с массивом.
  • Метки осей. Это практически другие (плотные или разреженные) массивы, прикрепленные к каждому измерению, которые упрощают срезку многомерных диапазонов при условиях, отличных от позиционных индексов массива.

TileDB унифицированно обрабатывает как плотные, так и разреженные массивы, но между ними есть несколько различий:

  • Ячейки в разреженных массивах могут быть пустыми, тогда как в плотных массивах все ячейки должны иметь значение; в плотных массивах «пустые» ячейки должны содержать ноль, специальное значение заполнения или быть помечены как пустые). Обычно пустые ячейки в разреженных массивах не материализуются в постоянном формате.
  • Размеры в плотных массивах должны быть однородными (т. Е. Иметь один и тот же тип данных) и поддерживать только целочисленные типы данных. Измерения в разреженных массивах могут быть разнородными (т. Е. Могут иметь разные типы данных), и они поддерживают любой тип данных, даже реальный или строковый.
  • В разреженных массивах может быть множественность ячеек (т. Е. Может быть несколько ячеек с одинаковыми координатами), тогда как в плотных массивах это невозможно.

Вот несколько примеров приложений, которые могут извлечь выгоду из многомерных массивов:

  • Любые табличные данные в виде одномерных плотных векторов или разреженных массивов ND
  • Любые данные временных рядов в виде 1D или ND (плотных или разреженных) массивов
  • Любые точечные данные (например, POI) в виде разреженных 2D- или 3D-массивов (например, LiDAR и AIS)
  • Геномные варианты популяций (коллекции VCF) в виде разреженных двумерных массивов
  • Одноклеточные транскриптомные данные в виде плотных или разреженных двумерных массивов
  • Любые большие плотные или разреженные матрицы, используемые в приложениях линейной алгебры.
  • Данные о погоде (например, поступающие в форме NetCDF) в виде помеченных плотных массивов ND
  • Спутниковые изображения (например, SAR) в виде плотных массивов 2D или стопок временных изображений 3D
  • Биомедицинская визуализация в виде плотных массивов ND
  • Аудио (1D) или видео (3D) приложения
  • Наблюдения за океаническими данными
  • Графы как разреженные матрицы смежности

На уровне определения модели данных вот как TileDB отвечает первым 6 требованиям OpenML:

1. Должен быть стандартный способ представления определенных типов данных

Все типы данных единообразно моделируются как плотные или разреженные массивы ND.

2. Формат должен позволять хранить большинство (обработанных) наборов данных машинного обучения.

Любой тип данных можно смоделировать как плотный или разреженный массив ND.

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

Любой тип данных можно смоделировать как плотный или разреженный массив ND.

4. Поддержка хранения разреженных данных

Модель TileDB изначально поддерживает разреженные массивы.

5. Поддержка хранения двоичных двоичных объектов и векторов разной длины

Модель TileDB позволяет хранить атрибуты размера var любого типа данных.

6. Поддержка метаданных

Произвольные метаданные "ключ-значение" (а также метки осей) являются частью модели массива TileDB.

Формат данных TileDB

Формат данных TileDB удовлетворяет требованиям 7–12.

Формат данных TileDB реализует модель данных массива, описанную в предыдущем разделе, и имеет следующие высокоуровневые цели:

  • Эффективное хранилище с поддержкой компрессоров и других фильтров (например, шифрование, контрольные суммы и т. Д.)
  • Эффективная нарезка ND
  • Эффективный доступ к хранилищам облачных объектов (в дополнение к другим бэкэндам)
  • Поддержка управления версиями данных

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

TileDB использует «многофайловый» формат данных, организованный в иерархии папок (или иерархии префиксов для объектов в облаке). Многофайловый формат абсолютно необходим для поддержки быстрых одновременных обновлений, особенно в хранилищах облачных объектов (например, S3), где все объекты неизменяемы (т. Е. Для изменения одного байта в объекте длиной в ТБ вы в конечном итоге переписываете все ТБ-длинный объект).

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

Формат данных TileDB соответствует следующим требованиям OpenML:

7. Машиночитаемые схемы (на определенном языке), описывающие форматирование данных определенного типа.

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

8. Поддержка нескольких «ресурсов» (например, коллекций файлов или нескольких реляционных таблиц)

Это достигается за счет иерархической организации папок с использованием групп.

9. Контроль версий, способ увидеть различия между версиями

Это возможно благодаря концепции неизменяемых фрагментов с отметками времени.

10. Обнаружение ошибок переворота битов во время хранения или передачи

TileDB поддерживает множество фильтров, которые могут применяться к каждому тайлу данных, включая контрольные суммы MD5 и SHA256.

11. Поддержка хранилищ объектов (например, S3, GCS, min.io и т. Д.)

Формат TileDB оптимизирован для облака и идеально подходит для хранилищ объектов, таких как S3, min.io, GCS и хранилище BLOB-объектов Azure (среди прочих бэкэндов).

12. Поддержка пакетных данных и добавления данных (потоковая передача)

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

Механизм хранения TileDB

Механизм хранения TileDB удовлетворяет требованиям 13–16.

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

С этой целью мы создали мощную библиотеку C ++, имея в виду следующие цели:

  • Быстрая многопоточная запись (из нескольких входных макетов)
  • Быстрое многопоточное чтение (в несколько выходных макетов)
  • Атомарность, параллелизм и (в конечном итоге) согласованность чередующихся операций чтения и записи в соответствии с моделью нескольких записей / нескольких считывателей без блокировки или координации
  • Путешествие во времени
  • Консолидация и вакуумирование
  • Многочисленные эффективные API-интерфейсы и интеграция с растущим набором механизмов SQL и инструментов для анализа данных с применением методов нулевого копирования везде, где это возможно.
  • Модульная и расширяемая конструкция для поддержки растущего набора серверных модулей хранения (локальный диск, S3, GCS, HDFS и т. Д.)
  • Обратная совместимость, поскольку формат TileDB улучшается с новыми версиями
  • Базовая библиотека C ++ должна быть бессерверной!

На рисунке ниже показана архитектура TileDB Embedded. Основная библиотека имеет открытый исходный код и делает все с точки зрения хранения данных и доступа к ним, а также предоставляет C и C ++ API. Остальные API эффективно построены на основе этих двух API. Интеграция с механизмами SQL и другими инструментами осуществляется с использованием этих API, и мы тщательно обнуляем копии везде, где это возможно (т. Е. Мы записываем срезанные результаты непосредственно в буферы памяти, предоставляемые приложениями более высокого уровня, избегая множественных копий данных и, таким образом, повышая производительность. ). Скоро мы опубликуем нашу интеграцию с Apache Arrow, так что ожидайте роста интеграции TileDB. Важно подчеркнуть, что мы намеренно разработали библиотеку для встраивания и, следовательно, бессерверной. Это позволяет легко использовать его через различные API без раскручивания кластеров, а также интегрироваться с распределенными системами (такими как Spark, Dask и Presto), если вам нужна дополнительная масштабируемость. TileDB Embedded, а также его API-интерфейсы и интеграции - все это с открытым исходным кодом.

Чтобы увидеть, как работает TileDB Embedded, ознакомьтесь с примерами C, C ++, Python, R, Java и Go или MariaDB, Spark, Dask, PDAL и GDAL .

Вы можете найти полную документацию по Внутренней механике TileDB Embedded в нашей документации.

Механизм хранения TileDB выполняет следующие требования:

13. Это должно быть полезно для хранения и передачи данных.

Это связано с форматом хранения на основе папок, а также с тем фактом, что TileDB Embedded предлагает множество API-интерфейсов и интеграции для эффективного разделения данных.

14. Быстрое чтение / запись и эффективное хранилище

Это связано с комбинацией формата данных и эффективной реализации механизма хранения TileDB Embedded.

15. Потоковое чтение / запись для упрощения преобразования и повышения эффективности использования памяти.

Все это обрабатывается реализацией механизма хранения.

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

Не просто парсеры, а единая суперэффективная реализация ядра C ++, наряду с многочисленными языковыми API и интеграциями с популярными механизмами SQL и инструментами анализа данных.

Сообщество TileDB

В этом разделе рассматривается последнее (17-е) требование.

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

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

  1. Мы полностью документируем каждую функцию в коде с первого дня.
  2. Мы поддерживаем описание в удобочитаемом формате здесь.
  3. Мы продолжаем улучшать нашу документацию и в процессе публикации серии блогов, руководств и видео об использовании и внутренней механике TileDB.
  4. Мы документируем, как структурирован код, чтобы помочь разработчикам начать вносить свой вклад в проект.

Последнее требование:

17. Формат должен быть стабильным и полностью поддерживаться активным сообществом.

Более важно, чтобы формат мог постоянно улучшаться и плавно развиваться для реализации новых функций и использования будущих технологических достижений (например, инноваций в хранилищах облачных объектов или NVMe). Вместо того, чтобы быть стабильным и негибким, он должен поставляться с полностью обслуживаемым механизмом хранения, который обеспечивает обратную совместимость для поддержки более старых версий формата. Кроме того, механизм хранения должен иметь стабильные API, которые должны проходить плавные циклы устаревания, когда абсолютно необходимо внести критические изменения в API. Наша команда на 100% привержена поддержке проекта TileDB Embedded и расширению его сообщества пользователей и разработчиков.

Необходимость в движках и API, а не в форматах

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

  1. Проблема №1: Простые или однофайловые форматы.
    Возьмите Parquet и ORC для табличных данных, COG для геопространственных изображений, VCF для геномных вариантов, LAZ для облаков точек LiDAR, и я могу продолжать и продолжать. Любой однофайловый формат можно спроектировать так, чтобы он был самодостаточным и потрясающим, используя знания предметной области и вдаваясь в подробности. Проблемы начинаются, когда обновления, путешествия во времени, облачное хранилище и анализ огромных коллекций файлов срывают вечеринку. Однофайловые форматы просто не подходят для хранилищ объектов. Обновления и путешествия во времени неизбежно добавляют сложности. Анализ миллионов файлов страдает от производительности из-за отсутствия локальности ввода-вывода, и вы быстро попадаете в ад управления метаданными. Вышесказанное естественным образом привело к появлению многофайловых форматов, таких как Delta Lake, Zarr и, конечно же, TileDB.
  2. Проблема №2: спецификации формата без учета программной реализации.
    Любого формата данных, каким бы элегантным и мощным он ни был, недостаточно. Также недостаточно просто синтаксических анализаторов формата. Чтобы получить максимальную производительность из тщательно разработанного формата данных, вам понадобятся серьезные инженерные решения для создания на его основе мощного программного обеспечения. Если вокруг формата нет механизма хранения или если этот механизм не совместим со многими языками и инструментами, на пользователей ложится бремя восстановления с нуля этого сложного механизма, что является огромным мероприятием. Например, Zarr изначально построен на Python и использует Dask для параллелизма (также написанный на Python). Чтобы получить доступ к данным Zarr на C ++, Java, Go и т. Д., Необходимо переписать весь механизм хранения с нуля эффективным (например, многопоточным) способом.
  3. Проблема №3: ​​стандарты форматов.
    Фиксированные форматы не могут пережить инновации или то, что будет дальше. Например, данные о погоде часто хранятся в формате NetCDF, который основан на HDF5, отличном однофайловом формате, который не спроектирован так, чтобы хорошо работать с хранилищами облачных объектов. Следовательно, из-за потребности в дешевом облачном хранилище выбор формата NetCDF в качестве стандартного формата для данных о погоде был неправильным выбором в ретроспективе, и теперь сообщество переходит на другие облачные форматы, такие как Zarr и TileDB (например, см. эту красивую статью, написанную Метеорологическим бюро Великобритании на TileDB). Выбор стандартного формата мешает инновациям.

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

TileDB Embedded - это наш вариант этого решения, разработанный с учетом следующих целей:

  1. Разработайте эффективный формат данных с открытой спецификацией, позволяющий ему развиваться со временем
  2. Создайте вокруг него мощный механизм хранения с открытым исходным кодом на быстром языке (например, C ++)
  3. Расширяемая поддержка многочисленных серверных ВМ
  4. Создавайте многочисленные эффективные языковые API-интерфейсы на ядре ядра, используя методы нулевого копирования.
  5. Используйте API-интерфейсы для интеграции с механизмами SQL и инструментами обработки данных
  6. При желании передать вычислительные примитивы в подсистему хранения модульным способом.
  7. Помогите определить и внедрить стандартные API

Мы рады работать с сообществом машинного обучения - и многими другими - над решением постоянно меняющихся задач в области расширенного управления и анализа данных. Вся заслуга в описанной выше великолепной работе принадлежит нашей блестящей команде, участникам, пользователям и клиентам. Если то, что вы читаете здесь, находит отклик у вас, мы рекомендуем вам стать участниками, подписаться на нас в Twitter и LinkedIn, публиковать сообщения на нашем форуме, запрашивать функции или просто написать нам письмо по адресу hello @ tiledb.com. И последнее, но не менее важное: мы стремимся пополнить нашу команду более замечательными людьми. Посмотрите наши открытые вакансии на https://apply.workable.com/tiledb/ и подайте заявку сегодня!