Apache Parquet offre plusieurs avantages pour le stockage et la récupération de données par rapport aux méthodes traditionnelles telles que CSV.
Le format Parquet est conçu pour un traitement plus rapide des données de types complexes. Dans cet article, nous expliquons comment le format Parquet est adapté aux besoins de données sans cesse croissants d'aujourd'hui.
Avant d'entrer dans les détails du format Parquet, comprenons ce que sont les données CSV et les défis qu'elles posent pour le stockage des données.
Qu'est-ce que le stockage CSV ?
Nous avons tous beaucoup entendu parler de CSV (Cmaman Séparé Vvaleurs) – l'une des manières les plus courantes d'organiser et de formater les données. Le stockage des données CSV est basé sur les lignes. Les fichiers CSV sont stockés avec l'extension .csv. Nous pouvons stocker et ouvrir des données CSV en utilisant Excel, Google Sheets ou tout autre éditeur de texte. Les données sont facilement visible une fois le fichier ouvert.
Eh bien, ce n'est pas bon – certainement pas pour un format de base de données.
De plus, à mesure que le volume de données augmente, il devient difficile d'interroger, de gérer et de récupérer.
Voici un exemple de données stockées dans un fichier .CSV :
EmpId,First name,Last name, Division
2012011,Sam,Butcher,IT
2013031,Mike,Johnson,Human Resource
2010052,Bill,Matthew,Architect
2010079,Jose,Brian,IT
2012120,Adam,James,Solutions
Si nous le visualisons dans Excel, nous pouvons voir une structure ligne-colonne comme ci-dessous :
Défis avec le stockage CSV
Les stockages basés sur des lignes tels que CSV conviennent à Crecréer, Umise à jour et Dsuppression des opérations.
Que dire de la Read dans CRUD, alors?
Imaginez un million de lignes dans le fichier .csv ci-dessus. Il faudrait un temps raisonnable pour ouvrir le fichier et rechercher les données que vous recherchez. Pas si cool. La plupart des fournisseurs de cloud comme AWS facturent les entreprises en fonction de la quantité de données numérisées ou stockées - encore une fois, les fichiers CSV consomment beaucoup d'espace.
Le stockage CSV n'a pas d'option exclusive pour stocker les métadonnées, ce qui rend l'analyse des données fastidieuse.
Alors, quelle est la solution rentable et optimale pour effectuer toutes les opérations CRUD ? Explorons.
Qu'est-ce que le stockage de données Parquet ?
Parquet est un format de stockage open source pour stocker des données. Il est largement utilisé dans Hadoop et les écosystèmes Spark. Les fichiers Parquet sont stockés sous l'extension .parquet.
Le parquet est un format très structuré. Il peut également être utilisé pour optimiser les données brutes complexes présentes en masse dans les lacs de données. Cela peut réduire considérablement le temps de requête.
Parquet rend le stockage des données efficace et la récupération plus rapide grâce à une combinaison de formats de stockage en ligne et en colonnes (hybrides). Dans ce format, les données sont partitionnées aussi bien horizontalement que verticalement. Le format Parquet élimine également dans une large mesure les frais généraux d'analyse.
Le format restreint le nombre total d'opérations d'E/S et, en fin de compte, le coût.
Parquet stocke également les métadonnées, qui stockent des informations sur les données telles que le schéma de données, le nombre de valeurs, l'emplacement des colonnes, la valeur minimale, la valeur maximale, le nombre de groupes de lignes, le type d'encodage, etc. Les métadonnées sont stockées à différents niveaux du fichier. , rendant l'accès aux données plus rapide.
Dans un accès basé sur des lignes comme CSV, la récupération des données prend du temps car la requête doit parcourir chaque ligne et obtenir les valeurs de colonne particulières. Avec le stockage Parquet, toutes les colonnes nécessaires sont accessibles en même temps.
En résumé,
- Le parquet est basé sur la structure en colonnes pour le stockage des données
- Il s'agit d'un format de données optimisé pour stocker des données complexes en vrac dans des systèmes de stockage
- Le format Parquet comprend diverses méthodes de compression et d'encodage des données
- Il réduit considérablement le temps d'analyse des données et le temps de requête et prend moins d'espace disque par rapport à d'autres formats de stockage comme CSV
- Minimise le nombre d'opérations d'E/S, réduisant le coût de stockage et d'exécution des requêtes
- Comprend des métadonnées qui facilitent la recherche de données
- Fournit un support open source
Format des données du parquet
Avant d'entrer dans un exemple, comprenons plus en détail comment les données sont stockées au format Parquet :
Nous pouvons avoir plusieurs partitions horizontales appelées groupes de lignes dans un seul fichier. Au sein de chaque groupe de lignes, un partitionnement vertical est appliqué. Les colonnes sont divisées en plusieurs blocs de colonnes. Les données sont stockées sous forme de pages à l'intérieur des blocs de colonnes. Chaque page contient les valeurs de données codées et les métadonnées. Comme nous l'avons mentionné précédemment, les métadonnées de l'ensemble du fichier sont également stockées dans le pied de page du fichier au niveau du groupe de lignes.
Comme les données sont divisées en blocs de colonnes, il est également facile d'ajouter de nouvelles données en encodant les nouvelles valeurs dans un nouveau bloc et un nouveau fichier. Les métadonnées sont ensuite mises à jour pour les fichiers et les groupes de lignes concernés. Ainsi, on peut dire que Parquet est un format flexible.
Parquet prend en charge nativement la compression des données à l'aide de techniques de compression de page et d'encodage de dictionnaire. Voyons un exemple simple de compression de dictionnaire :
Notez que dans l'exemple ci-dessus, nous voyons la division informatique 4 fois. Ainsi, lors du stockage dans le dictionnaire, le format encode les données avec une autre valeur facile à stocker (0,1,2…) ainsi que le nombre de fois qu'il est répété en continu - IT, IT est changé en 0,2 pour enregistrer plus d'espace. L'interrogation des données compressées prend moins de temps.
Comparatif en tête-à-tête
Maintenant que nous avons une bonne idée de l'apparence des formats CSV et Parquet, il est temps de comparer les deux formats avec quelques statistiques :
CSV | Parquet |
Format de stockage basé sur les lignes. | Un hybride de formats de stockage basés sur des lignes et des colonnes. |
Il consomme beaucoup d'espace car aucune option de compression par défaut n'est disponible. Par exemple, un fichier de 1 To occupera le même espace lorsqu'il sera stocké sur Amazon S3 ou tout autre nuage. | Compresse les données lors du stockage, consommant ainsi moins d'espace. Un fichier de 1 To stocké au format Parquet n'occupera que 130 Go d'espace. |
Le temps d'exécution de la requête est lent en raison de la recherche basée sur les lignes. Pour chaque colonne, chaque ligne de données doit être récupérée. | Le temps de requête est environ 34 fois plus rapide en raison du stockage basé sur des colonnes et de la présence de métadonnées. |
Plus de données doivent être analysées par requête. | Environ 99 % de données en moins sont analysées pour l'exécution de la requête, donc optimisation des performances. |
La plupart des périphériques de stockage facturent en fonction de l'espace de stockage, donc le format CSV signifie le coût de stockage élevé. | Moins de coûts de stockage car les données sont stockées dans un format compressé et codé. |
Le schéma de fichier doit être soit déduit (conduisant à des erreurs) soit fourni (ennuyeux). | Le schéma de fichier est stocké dans les métadonnées. |
Le format convient aux types de données simples. | Parquet convient même aux types complexes comme les schémas imbriqués, les tableaux, les dictionnaires. |
Conclusion
Nous avons vu à travers des exemples que Parquet est plus efficace que CSV en termes de coût, de flexibilité et de performance. C'est un mécanisme efficace pour stocker et récupérer des données, surtout lorsque le monde entier se dirige vers stockage cloud et l'optimisation de l'espace. Toutes les grandes plateformes comme Azure, AWS et BigQuery prennent en charge le format Parquet.