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.
Dans cette section, nous discutons des défis actuels et historiques de la gestion des données non structurées ou complexes.
Il n’est généralement pas recommandé de stocker des données binaires, comme des images, directement dans une base de données. En effet, les bases de données ne sont pas optimisées pour stocker et servir des fichiers volumineux et peuvent entraîner des problèmes de performances. De plus, les données binaires ne s'intègrent pas bien dans le format structuré d'une base de données, ce qui les rend difficiles à interroger et à manipuler. Cela peut entraîner des temps de chargement lents pour les utilisateurs. Les bases de données sont généralement plus coûteuses à exploiter et à entretenir que les autres types de stockage, tels que les systèmes de fichiers ou les services de stockage cloud. Par conséquent, stocker de grandes quantités de données binaires dans une base de données peut s’avérer plus coûteux que d’autres solutions de stockage.
L'augmentation des charges de travail analytiques et BI à grande échelle a motivé le développement de formats structurés compressés comme Parquet, ORC, Avro, ou de formats en mémoire transitoires comme Arrow [79, 6, 20, 13]. À mesure que les formats tabulaires ont été adoptés, des tentatives pour étendre ces formats, tels que Petastorm [18] ou Feather [7] pour l'apprentissage en profondeur, ont émergé. À notre connaissance, ces formats n’ont pas encore été largement adoptés. Cette approche bénéficie principalement des intégrations natives avec Modern Data Stack (MDS). Cependant, comme indiqué précédemment, les outils en amont nécessitent des modifications fondamentales pour s'adapter aux applications d'apprentissage profond.
Le choix cloud natif actuel pour stocker de grands ensembles de données non structurés est le stockage d'objets tel qu'AWS S3 [1], Google Cloud Storage (GCS) [3] ou MinIO [17]. Le stockage objet offre trois avantages principaux par rapport aux systèmes de fichiers réseau distribués. Ils sont (a) rentables, (b) évolutifs et (c) servent de référentiel indépendant du format. Cependant, les stockages cloud ne sont pas sans inconvénients. Premièrement, ils introduisent une surcharge de latence importante, en particulier lors de l'itération sur de nombreux petits fichiers tels que du texte ou du JSON. Ensuite, l’ingestion de données non structurées sans contrôle des métadonnées peut produire des « marécages de données ». De plus, le stockage objet dispose d’un contrôle de version intégré ; il est rarement utilisé dans les flux de travail de science des données. Enfin, les données sur le stockage objet sont copiées sur une machine virtuelle avant la formation, ce qui entraîne une surcharge de stockage et des coûts supplémentaires.
Les lacs de données de deuxième génération dirigés par Delta, Iceberg, Hudi [27, 15, 10] étendent le stockage d'objets en gérant des fichiers au format tabulaire avec les propriétés principales suivantes.
(1) Opérations de mise à jour : insertion ou suppression d'une ligne au-dessus d'un fichier au format tabulaire.
(2) Streaming : ingestion de données en aval avec les propriétés ACID et intégration en amont avec le moteur de requête exposant l'interface SQL.
(3) Evolution du schéma : évolution de la structure en colonnes tout en préservant la rétrocompatibilité.
(4) Voyage dans le temps et suivi du journal d'audit : préservation de l'état historique avec une propriété de restauration où les requêtes peuvent être reproductibles. En outre, prise en charge du contrôle au niveau des lignes sur le lignage des données.
(5) Optimisation de la mise en page : fonctionnalité intégrée pour optimiser la taille des fichiers et le compactage des données avec prise en charge des commandes personnalisées. Accélère considérablement les requêtes.
Cependant, les lacs de données de deuxième génération sont toujours limités par les formats de données inhérents à l’apprentissage profond, comme indiqué précédemment dans la section 2.2. Par conséquent, dans cet article, nous étendons la deuxième génération de capacités de lac de données aux cas d'utilisation du deep learning en repensant le format et les fonctionnalités en amont, notamment l'interrogation, la visualisation et l'intégration native aux frameworks de deep learning pour compléter le cycle de vie du ML, comme le montre la figure 2. .
Cet article est disponible sur arxiv sous licence CC 4.0.