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   Résumé et introduction   Défis actuels   Format de stockage Tensor   Aperçu du système Deep Lake   Cas d'utilisation de l'apprentissage automatique   Repères de performances   Discussion et limites   Travaux connexes   Conclusions, remerciements et références  4. APERÇU DU SYSTÈME DEEP LAKE  Comme le montre la figure 1, Deep Lake stocke les données brutes et les vues dans un stockage d'objets tel que S3 et matérialise des ensembles de données avec une lignée complète. Les requêtes de streaming, Tensor Query Language et le moteur de visualisation s'exécutent avec le calcul d'apprentissage en profondeur ou sur le navigateur sans nécessiter de service externe géré ou centralisé.  4.1 Ingestion    Parfois, les métadonnées peuvent déjà résider dans une base de données relationnelle. Nous avons également construit un connecteur de destination ETL en utilisant Airbyte[3] [22]. Le framework permet de se connecter à n'importe quelle source de données prise en charge, y compris les bases de données SQL/NoSQL, les lacs de données ou les entrepôts de données, et de synchroniser les données dans Deep Lake. Le protocole du connecteur transforme les données dans un format en colonnes. 4.1.1 Extraire.    Pour accélérer considérablement les flux de travail de traitement des données et libérer les utilisateurs de se soucier de la disposition des fragments, Deep Lake propose une option pour exécuter des transformations Python en parallèle. La transformation prend en compte un ensemble de données, parcourt la première dimension par échantillon et génère un nouvel ensemble de données. Une fonction python définie par l'utilisateur attend deux arguments requis 𝑠𝑎𝑚𝑝𝑙𝑒_𝑖𝑛, 𝑠𝑎𝑚𝑝𝑙𝑒_𝑜𝑢𝑡 et est décorée avec @𝑑𝑒𝑒𝑝𝑙𝑎𝑘𝑒. 𝑐𝑜𝑚𝑝𝑢𝑡𝑒. Un seul 𝑠𝑎𝑚𝑝𝑙𝑒_𝑖𝑛 peut créer dynamiquement plusieurs 𝑠𝑎𝑚𝑝𝑙𝑒_𝑜𝑢𝑡𝑠. Il permet des transformations un-à-un et un-à-plusieurs. La transformation peut également être appliquée sur place sans créer de nouvel ensemble de données.  4.1.2 Transformation.  En coulisses, le planificateur regroupe les transformations par échantillons opérant sur des morceaux proches et les planifie sur un pool de processus. En option, le calcul peut être délégué à un cluster Ray [53]. Au lieu de définir un ensemble de données d'entrée, l'utilisateur peut fournir un itérateur arbitraire avec des objets personnalisés pour créer des workflows d'ingestion. Les utilisateurs peuvent également empiler plusieurs transformations et définir des pipelines complexes.  4.2 Contrôle des versions  Deep Lake répond également au besoin de reproductibilité des expériences et de respect d’un lignage complet des données. Différentes versions de l'ensemble de données existent dans le même stockage, séparées par des sous-répertoires. Chaque sous-répertoire agit comme un ensemble de données indépendant avec ses fichiers de métadonnées. Contrairement à un ensemble de données non versionné, ces sous-répertoires ne contiennent que des morceaux modifiés dans la version particulière, ainsi qu'un chunk_set correspondant par tenseur contenant les noms de tous les morceaux modifiés. Un fichier d'informations de contrôle de version présent à la racine du répertoire assure le suivi de la relation entre ces versions sous la forme d'une arborescence de contrôle de version ramifiée. Lors de l'accès à n'importe quel morceau d'un tenseur à une version particulière, l'arborescence de contrôle de version est parcourue à partir de la validation actuelle, en direction de la première validation. Pendant le parcours, l'ensemble de morceaux de chaque version est vérifié pour l'existence du morceau requis. Si le morceau est trouvé, le parcours est arrêté et les données sont récupérées. Pour suivre les différences entre les versions, pour chaque version, un fichier de comparaison de validation est également stocké par tenseur. Cela accélère la comparaison entre les versions et les branches. De plus, les identifiants des échantillons sont générés et stockés lors du remplissage de l'ensemble de données. Ceci est important pour garder une trace des mêmes échantillons lors des opérations de fusion. L'interface de contrôle de version de Deep Lake est l'API Python, qui permet aux ingénieurs en apprentissage automatique de versionner leurs ensembles de données dans leurs scripts de traitement de données sans basculer entre la CLI. Il prend en charge les commandes suivantes :  •   : crée un instantané immuable de l'état actuel de l'ensemble de données. Commit  •   : extrait une branche/un commit existant ou crée une nouvelle branche s'il n'en existe pas. Checkout  •   : compare les différences entre 2 versions du jeu de données. Diff  •   : fusionne deux versions différentes de l'ensemble de données, résolvant les conflits selon la politique définie par l'utilisateur. Fusionner  4.3 Visualisation des tenseurs  La visualisation des données est un élément crucial des flux de travail ML, en particulier lorsque les données sont difficiles à analyser analytiquement. Une visualisation rapide et transparente permet une collecte de données, des annotations, une inspection qualité et des itérations de formation plus rapides. Le moteur de visualisation Deep Lake fournit une interface Web permettant de visualiser des données à grande échelle directement à partir de la source. Il prend en compte le type des tenseurs pour déterminer la meilleure disposition pour la visualisation. Les tenseurs principaux, tels que l'image, la vidéo et l'audio, sont affichés en premier, tandis que les données et annotations secondaires, telles que le texte, class_label, bbox et binaire_mask, sont superposées. Le visualiseur prend également en compte les informations de type méta, telles que la séquence, pour fournir une vue séquentielle des données, où les séquences peuvent être lues et passer à la position spécifique de la séquence sans récupérer l'intégralité des données, ce qui est pertinent pour les cas d'utilisation vidéo ou audio. . Visualizer répond aux besoins critiques des flux de travail de ML, permettant aux utilisateurs de comprendre et de dépanner les données, de décrire leur évolution, de comparer les prédictions à la vérité terrain ou d'afficher plusieurs séquences d'images (par exemple, des images de caméra et des cartes de disparité) côte à côte.  4.4 Langage de requête tenseur  L'interrogation et l'équilibrage des ensembles de données sont une étape courante dans la formation des workflows d'apprentissage en profondeur. Généralement, cela est réalisé à l'intérieur d'un chargeur de données en utilisant des stratégies d'échantillonnage ou des étapes de prétraitement distinctes pour sous-sélectionner l'ensemble de données. D’un autre côté, les lacs de données traditionnels se connectent à des moteurs de requêtes analytiques externes [66] et diffusent des Dataframes vers les flux de travail de science des données. Pour résoudre l'écart entre le format et l'accès rapide aux données spécifiques, nous fournissons un moteur de requête intégré de type SQL implémenté en C++ appelé Tensor Query Language (TQL). Un exemple de requête est présenté sur la figure 5. Alors que l'analyseur SQL a été étendu à partir de Hyrise [37] pour concevoir le langage de requête tensoriel, nous avons implémenté notre planificateur et notre moteur d'exécution qui peuvent éventuellement déléguer le calcul à des cadres de calcul tensoriels externes. Le plan de requête génère un graphique informatique des opérations tensorielles. Ensuite, le planificateur exécute le graphique de requête.   L'exécution de la requête peut être déléguée à des cadres de calcul tensoriels externes tels que PyTorch [58] ou XLA [64] et utiliser efficacement le matériel accéléré sous-jacent. En plus des fonctionnalités SQL standard, TQL implémente également le calcul numérique. Il y a deux raisons principales pour implémenter un nouveau langage de requête. Premièrement, le SQL traditionnel ne prend pas en charge les opérations sur les tableaux multidimensionnels telles que le calcul de la moyenne des pixels de l'image ou la projection de tableaux sur une dimension spécifique. TQL résout ce problème en ajoutant une indexation de style Python/NumPy, en découpant les tableaux et en fournissant un large éventail de fonctions pratiques pour travailler avec des tableaux, dont beaucoup sont des opérations courantes prises en charge dans NumPy. Deuxièmement, TQL permet une intégration plus approfondie de la requête avec d'autres fonctionnalités de Deep Lake, telles que le contrôle de version, le moteur de streaming et la visualisation. Par exemple, TQL permet d'interroger des données sur des versions spécifiques ou potentiellement sur plusieurs versions d'un ensemble de données. TQL prend également en charge des instructions spécifiques pour personnaliser la visualisation du résultat de la requête ou une intégration transparente avec le chargeur de données pour le streaming filtré. Le moteur de requête intégré s'exécute avec le client lors de la formation d'un modèle sur une instance de calcul distante ou dans un navigateur compilé sur WebAssembly. TQL étend SQL avec des calculs numériques au-dessus de colonnes multidimensionnelles. Il construit des vues d'ensembles de données, qui peuvent être visualisées ou directement diffusées vers des cadres d'apprentissage en profondeur. Toutefois, les vues de requête peuvent être rares, ce qui peut affecter les performances de streaming.  4.5 Matérialisation  La plupart des données brutes utilisées pour le deep learning sont stockées sous forme de fichiers bruts (compressés dans des formats comme JPEG), soit localement, soit sur le cloud. Une manière courante de construire des ensembles de données consiste à conserver les pointeurs vers ces fichiers bruts dans une base de données, à les interroger pour obtenir le sous-ensemble de données requis, à récupérer les fichiers filtrés sur une machine, puis à entraîner un modèle itérant sur les fichiers. De plus, le traçage des données doit être maintenu manuellement avec un fichier de provenance. Tensor Storage Format simplifie ces étapes à l'aide de tenseurs liés - stockant des pointeurs (liens/URL vers un ou plusieurs fournisseurs de cloud) vers les données d'origine. Les pointeurs au sein d'un même tenseur peuvent être connectés à plusieurs fournisseurs de stockage, permettant ainsi aux utilisateurs d'obtenir une vue consolidée de leurs données présentes dans plusieurs sources. Toutes les fonctionnalités de Deep Lake, notamment les requêtes, le contrôle de version et le streaming vers des frameworks d'apprentissage profond, peuvent être utilisées avec des tenseurs liés. Cependant, les performances du streaming de données ne seront pas aussi optimales que celles des tenseurs par défaut. Un problème similaire existe avec les vues clairsemées créées en raison de requêtes, qui seraient diffusées de manière inefficace en raison de la disposition des blocs. De plus, la matérialisation transforme la vue de l'ensemble de données en une présentation optimale à diffuser dans des cadres d'apprentissage en profondeur pour itérer plus rapidement. La matérialisation implique de récupérer les données réelles à partir de liens ou de vues et de les disposer efficacement en morceaux. Effectuer cette étape vers la fin des flux de travail d'apprentissage automatique conduit à une duplication minimale des données tout en garantissant des performances de streaming optimales et une duplication minimale des données, avec une traçabilité complète des données.  4.6 Chargeur de données en streaming  À mesure que les ensembles de données deviennent plus volumineux, le stockage et le transfert sur le réseau à partir d’un stockage distribué à distance deviennent inévitables. Le streaming de données permet de former des modèles sans attendre que toutes les données soient copiées sur une machine locale. Le chargeur de données en streaming assure la récupération des données, la décompression, l'application des transformations, le classement et le transfert des données vers le modèle de formation. Les chargeurs de données de Deep Learning délèguent généralement la récupération et la transformation à des processus exécutés en parallèle pour éviter les calculs synchrones. Ensuite, les données sont transférées au travailleur principal via une communication inter-processus (IPC), ce qui introduit une surcharge de copie de mémoire ou utilise la mémoire partagée avec certains problèmes de fiabilité. En revanche, le chargeur de données Deep Lake délègue la récupération hautement parallèle et la décompression sur place en C++ par processus pour éviter le verrouillage global de l'interpréteur. Ensuite, il transmet le pointeur en mémoire à la fonction de transformation définie par l'utilisateur et les rassemble avant de les exposer à la boucle de formation dans la disposition de la mémoire native du Deep Learning. La transformation s'exécute simultanément en parallèle lorsqu'elle utilise uniquement des appels de routine de bibliothèque native et libère le verrouillage global de l'interpréteur Python (GIL) en conséquence. En conséquence, nous obtenons :  •   : fournir des données au modèle d'apprentissage profond suffisamment rapidement pour que le GPU soit pleinement utilisé ou soit gêné par le calcul. Performance  •   : différencie dynamiquement la priorité des tâches gourmandes en CPU par rapport aux tâches moins intensives. Smart Scheduler    : prévoir la consommation de mémoire pour éviter d'interrompre le processus de formation en raison d'un remplissage excessif de la mémoire. • Allocation efficace des ressources  Cet article est   sous licence CC 4.0. disponible sur arxiv  [3] Code source disponible : https://github.com/activeloopai/airbyte sur la branche @feature/connector/deeplake

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Dataology.TECH

Dataology is the study of data. We publish the highest quality university papers & blog posts about the essence of data.

Dataology

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Boost your HackerNoon story @ $159.99! 🚀

Deep Lake, une Lakehouse pour le Deep Learning : aperçu du système Deep Lake

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps