paint-brush
Deep Lake, домик у озера для глубокого обучения: текущие проблемык@dataology
122 чтения

Deep Lake, домик у озера для глубокого обучения: текущие проблемы

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

Исследователи представляют Deep Lake, озеро с открытым исходным кодом для глубокого обучения, оптимизирующее сложное хранение и потоковую передачу данных для структур глубокого обучения.
featured image - Deep Lake, домик у озера для глубокого обучения: текущие проблемы
Dataology: Study of Data in Computer Science HackerNoon profile picture
0-item

Авторы:

(1) Сасун Амбарцумян, Activeloop, Маунтин-Вью, Калифорния, США;

(2) Абхинав Тули, Activeloop, Маунтин-Вью, Калифорния, США;

(3) Левон Гукасян, Activeloop, Маунтин-Вью, Калифорния, США;

(4) Фариз Рахман, Activeloop, Маунтин-Вью, Калифорния, США;.

(5) Грант Топчян, Activeloop, Маунтин-Вью, Калифорния, США;

(6) Дэвид Исаян, Activeloop, Маунтин-Вью, Калифорния, США;

(7) Марк Маккуэйд, Activeloop, Маунтин-Вью, Калифорния, США;

(8) Микаел Арутюнян, Activeloop, Маунтин-Вью, Калифорния, США;

(9) Татевик Акопян, Activeloop, Маунтин-Вью, Калифорния, США;

(10) Иво Странич, Activeloop, Маунтин-Вью, Калифорния, США;

(11) Давид Буниатян, Activeloop, Маунтин-Вью, Калифорния, США.

Таблица ссылок

2. ТЕКУЩИЕ ПРОБЛЕМЫ

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

2.1 Сложные типы данных в базах данных

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

2.2 Сложные данные в табличных форматах

Увеличение крупномасштабных аналитических и BI-рабочих нагрузок побудило к разработке сжатых структурированных форматов, таких как Parquet, ORC, Avro, или временных форматов в памяти, таких как Arrow [79, 6, 20, 13]. По мере того как табличные форматы получили распространение, появились попытки расширить эти форматы, такие как Petastorm [18] или Feather [7] для глубокого обучения. Насколько нам известно, эти форматы еще не получили широкого распространения. Этот подход в первую очередь выигрывает от встроенной интеграции с Modern Data Stack (MDS). Однако, как обсуждалось ранее, исходные инструменты требуют фундаментальных модификаций для адаптации к приложениям глубокого обучения.

2.3 Объектное хранилище для глубокого обучения

В настоящее время облачным решением для хранения больших неструктурированных наборов данных является объектное хранилище, такое как AWS S3 [1], Google Cloud Storage (GCS) [3] или MinIO [17]. Объектное хранилище предлагает три основных преимущества по сравнению с распределенными сетевыми файловыми системами. Они (а) экономичны, (б) масштабируемы и (в) служат хранилищем, не зависящим от формата. Однако облачные хранилища не лишены недостатков. Во-первых, они приводят к значительным задержкам, особенно при переборе множества небольших файлов, таких как текст или JSON. Далее, прием неструктурированных данных без контроля метаданных может привести к «болоту данных». Более того, объектное хранилище имеет встроенный контроль версий; он редко используется в рабочих процессах обработки данных. Наконец, данные из объектного хранилища копируются на виртуальную машину перед обучением, что приводит к увеличению затрат на хранение и дополнительным затратам.

2.4 Второе поколение озер данных

Озера данных второго поколения, возглавляемые Delta, Iceberg, Hudi [27, 15, 10], расширяют хранилище объектов за счет управления файлами табличного формата со следующими основными свойствами.


(1) Операции обновления: вставка или удаление строки поверх файла табличного формата.


(2) Потоковая передача : прием данных нисходящего потока со свойствами ACID и интеграция восходящего потока с механизмом запросов, открывающим интерфейс SQL.


(3) Эволюция схемы: развитие столбчатой структуры при сохранении обратной совместимости.


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


(5) Оптимизация макета: встроенная функция для оптимизации размеров файлов и сжатия данных с поддержкой индивидуального заказа. Значительно ускоряет обработку запросов.


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


Этот документ доступен на arxiv под лицензией CC 4.0.