Qu'est-ce qui est plus rapide et moins cher pour convertir des fichiers dans AWS : Polar ou Pandas ?

Les deux offrent une large gamme d'outils et d'avantages qui peuvent nous faire douter lequel des deux choisir à un moment donné. Il ne s'agit pas de changer tous les processus de l'entreprise pour qu'elle commence à utiliser des Polars ou de « tuer » les Pandas (cela n'arrivera pas dans un avenir immédiat). Il s'agit de connaître d'autres outils qui peuvent nous aider à réduire les coûts et les délais dans les processus, en obtenant des résultats identiques ou meilleurs.

Lorsque nous utilisons des services cloud, nous donnons la priorité à certains facteurs, notamment leur coût. Les services que j'utilise pour ce processus sont AWS Lambda avec le runtime Python 3.10 et S3 pour stocker le fichier brut et le fichier parquet converti.

L'intention est d'obtenir un fichier CSV sous forme de données brutes et de le traiter avec des pandas et des polaires dans le but de vérifier laquelle de ces deux bibliothèques nous offre la meilleure optimisation des ressources telles que la mémoire et le poids du fichier résultant.

Pandas
Il s'agit d'une bibliothèque Python spécialisée dans la manipulation et l'analyse de données, elle est écrite en C et sa sortie initiale date de 2008.

*Polaires*
Il s'agit d'une bibliothèque Python et Rust spécialisée dans la manipulation et l'analyse de données qui permet des processus parallèles et est principalement écrite en Rust et a été publiée en 2022.

L'architecture du processus :

Le projet est quelque chose de simple comme le montre l'architecture : L'utilisateur dépose un fichier CSV dans work/pandas ou work/porlas et démarre automatiquement le déclencheur s3 pour traiter le fichier pour le convertir en parquet et le déposer en traitement.

Dans ce petit projet j'ai utilisé deux lambdas avec la configuration suivante :
Mémoire : 2 Go
Mémoire éphémère : 2 Go
Durée de vie : 600 secondes

Exigences
Lambda avec des pandas : Pandas, Numpy et Pyarrow
Lambda avec polaires : Polaires

L'ensemble de données utilisé pour la comparaison est disponible sur kaggle sous le nom « Rotten Tomatoes Movie Reviews – 1,44M rows » ou peut être téléchargé à partir d'ici.

Le référentiel complet est disponible sur GitHub et peut être cloné ici.

Taille ou poids
Le lambda utilisé par Pandas nécessite deux plugins supplémentaires pour créer un fichier parquet, dans ce cas il s'agit de PyArrow et d'une version spécifique de numpy pour la version de Pandas que j'utilisais. En conséquence, nous avons obtenu un lambda avec un poids ou une taille de 74,4 Mo, quelque chose de très proche de la limite qu'AWS nous autorise pour le poids du lambda.

Le lambda avec Polars ne nécessite pas d'autre plugin comme PyArrow ce qui simplifie la vie et réduit la taille du lambda à moins de la moitié. En conséquence, notre lambda a un poids ou une taille de 30,6 Mo par rapport au premier, ce qui nous laisse de la place pour installer d'autres dépendances dont nous pourrions avoir besoin pour notre processus de transformation.

Performances

Le lambda avec Pandas a été optimisé pour utiliser la compression après la première version, cependant, son comportement a également été analysé.
Pandas
Il a fallu 18 secondes pour traiter l'ensemble de données et utilisé 1894 Mo de mémoire pour traiter le fichier CSV et générer un fichier Parquet par rapport aux autres versions, c'est celle qui a utilisé le plus de temps et de ressources.

Pandas + Compression
L'ajout d'une ligne de code nous a permis de nous améliorer un peu par rapport à la version précédente (Pandas), il fallait 17 secondes pour traiter le jeu de données et utilisé 1837 Mo, ce qui ne représente pas une amélioration significative du temps de traitement et de calcul, mais de la taille. du fichier résultant.

Polaires
Il a fallu 12 secondes pour traiter le même jeu de données et j'ai utilisé seulement 1462 Mo, par rapport aux deux précédents cela représente un gain de temps de 44,44% et une consommation de mémoire inférieure.

Taille du fichier de sortie

Pandas
Le lambda dans lequel un processus de compression n'a pas été établi a généré un fichier parquet de 177,4 Mo.

Pandas + Compression
Lors de la configuration de la compression dans le lambda, je ne génère pas de fichier parquet de 121,1 Mo. Une petite ligne ou option nous a aidé à réduire la taille du fichier de 31,74 %. Considérant qu'il ne s'agit pas d'un changement de code significatif, c'est une très bonne option.

Polaires
Polars a généré un fichier de 105,8 Mo qui, acheté avec la première version de Pandas, représente une économie de 40,36 % et 12,63 % par rapport à la version Pandas avec compression.

Conclusion
Il n'est pas nécessaire de modifier tous les processus internes qui utilisent Pandas pour qu'ils utilisent désormais Polars, cependant, il est important de considérer que si nous parlons de milliers ou de millions d'exécutions lambda, l'utilisation de Polars nous aidera non seulement dans le déploiement. temps, mais cela nous aidera également à réduire les coûts grâce à la facturation basée sur le temps qu'AWS effectue pour les services sans serveur tels que Lambda.
De même, lorsque nous traduisons ces 40,36 % en millions de fichiers, nous parlons de Go ou de To, ce qui aurait un impact significatif au sein d'un Datalake ou d'un Dataware house ou même dans un stockage de fichiers froid.

La réduction avec Polars ne se limiterait pas seulement à ces deux facteurs, car elle affecterait grandement la sortie de données et/ou d'objets d'AWS car c'est un service qui a un coût.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!