paint-brush
Deep Lake, un Lakehouse pour le Deep Learning : discussion et limitespar@dataology
137 lectures

Deep Lake, un Lakehouse pour le Deep Learning : discussion et limites

Trop long; Pour lire

Les chercheurs présentent Deep Lake, un Lakehouse open source pour l'apprentissage profond, optimisant le stockage et le streaming de données complexes pour les cadres d'apprentissage profond.
featured image - Deep Lake, un Lakehouse pour le Deep Learning : discussion et limites
Dataology: Study of Data in Computer Science HackerNoon profile picture
0-item

Auteurs:

(1) Sasun Hambardzumyan, Activeloop, Mountain View, Californie, États-Unis ;

(2) Abhinav Tuli, Activeloop, Mountain View, Californie, États-Unis ;

(3) Levon Ghukasyan, Activeloop, Mountain View, Californie, États-Unis ;

(4) Fariz Rahman, Activeloop, Mountain View, Californie, États-Unis ;.

(5) Hrant Topchyan, Activeloop, Mountain View, Californie, États-Unis ;

(6) David Isayan, Activeloop, Mountain View, Californie, États-Unis ;

(7) Mark McQuade, Activeloop, Mountain View, Californie, États-Unis ;

(8) Mikayel Harutyunyan, Activeloop, Mountain View, Californie, États-Unis ;

(9) Tatevik Hakobyan, Activeloop, Mountain View, Californie, États-Unis ;

(10) Ivo Stranic, Activeloop, Mountain View, Californie, États-Unis ;

(11) Davit Buniatyan, Activeloop, Mountain View, Californie, États-Unis.

Tableau des liens

7. DISCUSSION ET LIMITES

Les principaux cas d'utilisation de Deep Lake incluent (a) la formation du modèle d'apprentissage profond, (b) le lignage des données et le contrôle des versions, (c) l'interrogation et l'analyse des données, (d) l'inspection des données et le contrôle qualité. Nous avons pris les tableaux NumPy [55] comme bloc fondamental et implémenté


Figure 10 : Utilisation du GPU d'une seule machine GPU 16xA100 lors de la formation du modèle CLIP de paramètre 1B [60]. L'ensemble de données est LAION-400M [68] diffusé en continu depuis AWS US-East vers le centre de données GCP US-Central. Chaque couleur démontre l'utilisation d'un seul GPU A100 au cours de l'entraînement.


contrôle de version, chargeurs de données en streaming, moteur de visualisation à partir de zéro.

7.1 Espace de conception de format

Le Tensor Storage Format (TSF) est un format de fichier binaire conçu spécifiquement pour stocker des tenseurs, qui sont des tableaux multidimensionnels de valeurs numériques utilisés dans de nombreux algorithmes d'apprentissage automatique et d'apprentissage profond. Le format TSF est conçu pour être efficace et compact, permettant un stockage et un accès rapides et efficaces aux données tensorielles. L'un des principaux avantages du format TSF est qu'il prend en charge un large éventail de types de données tensorielles, y compris les tenseurs de forme dynamique.


En comparaison, les formats Parquet [79] et Arrow [13] sont des formats de fichiers en colonnes conçus pour stocker et traiter de grands ensembles de données analytiques. Contrairement à TSF, qui est spécifiquement conçu pour les données tensorielles, Parquet et Arrow sont optimisés pour un stockage et une interrogation efficaces des charges de travail analytiques sur des données tabulaires et de séries chronologiques. Ils utilisent des techniques de stockage et de compression en colonnes pour minimiser l'espace de stockage et améliorer les performances, ce qui les rend adaptés aux applications Big Data. Cependant, TSF présente certains avantages par rapport à Parquet et Arrow en ce qui concerne les données tensorielles. TSF peut prendre en charge les opérations tensorielles et le streaming efficace vers des frameworks d'apprentissage en profondeur.


D'autres formats de tenseurs [18, 52, 23, 57] sont efficaces pour les charges de travail massivement parallélisables car ils ne nécessitent pas de coordination entre les morceaux. Le compromis clé du format de stockage Tensor permet de stocker des tableaux de forme dynamique à l'intérieur d'un tenseur sans remplir l'empreinte mémoire. Par exemple, en vision par ordinateur, il est très courant de stocker plusieurs images avec des formes différentes ou des vidéos ayant une longueur dynamique. Pour prendre en charge la flexibilité, une surcharge mineure est introduite sous la forme d'un encodeur de blocs évoqué précédemment et dont, dans la pratique, nous n'avons pas observé d'impact sur les charges de travail de production.

7.2 Chargeur de données

Deep Lake obtient des résultats de pointe dans des environnements locaux et distants, comme le montrent les tests d'itération sur de grandes images (Fig. 7). Principalement, il a été plus rapide que FFCV [39], qui revendiquait une réduction de la formation du modèle ImageNet. jusqu'à 98 cents par formation de modèle. De plus, Deep Lake atteint des performances d'ingestion similaires à celles de WebDataset [19]. Deep Lake surpasse considérablement les images plus grandes. Parquet est optimisé pour les petites cellules et les charges de travail analytiques, tandis que Deep Lake est optimisé pour les données tensorielles volumineuses et façonnées de manière dynamique. Par rapport à d'autres solutions de lac de données, sa conception minimale de package Python permet à Deep Lake d'être facilement intégré à des charges de travail de formation ou d'inférence distribuées à grande échelle.

7.3 Travaux futurs

La mise en œuvre actuelle de Deep Lake offre des possibilités d’amélioration supplémentaire. Premièrement, le format de stockage ne prend pas en charge la commande personnalisée pour une disposition de stockage encore plus efficace requise pour la recherche vectorielle ou l'indexation clé-valeur. Deuxièmement, Deep Lake implémente des verrous basés sur les branches pour un accès simultané. Semblable au modèle de transaction Delta ACID [27], Deep Lake peut être étendu à des charges de travail parallèles hautement performantes. Troisièmement, l'implémentation actuelle de TQL ne prend en charge qu'un sous-ensemble d'opérations SQL (c'est-à-dire qu'elle ne prend pas en charge les opérations telles que la jointure). D'autres travaux viseront à le rendre SQL-complet, en l'étendant à des opérations plus numériques, en exécutant des requêtes fédérées dans des sources de données externes et en effectuant des analyses comparatives avec les moteurs SQL.


Cet article est disponible sur arxiv sous licence CC 4.0.