¿Qué es más rápido y económico para convertir archivos en AWS: Polar o Pandas?

¿que-es-mas-rapido-y-economico-para-convertir-archivos-en-aws:-polar-o-pandas?

Ambas ofrecen una amplia gama de herramientas y ventajas que nos pueden poner en duda cual de los dos escoger en algún momento. No se trata de cambiar todos los procesos de la empresa para que inicien a utilizar Polars o una “muerte” a Pandas (esto no va a pasar en el futuro inmediato). Se trata de conocer otras herramientas que nos pueden ayudar a reducir costos y tiempo en los procesos obteniendo iguales o mejores resultados.

Cuando utilizamos servicios en la nube priorizamos ciertos factores, dentro de los que se encuentran el costo de los mismos. Los servicios que utilizo para este proceso son AWS Lambda con el runtime de Python 3.10 y S3 para almacenar el archivo crudo y el archivo convertido en parquet.

La intención es obtener un archivo CSV como data cruda y procesarlo con pandas y polars con la intención de verificar cual de estas dos bibliotecas nos ofrece una mejor optimización de recursos como memoria y el peso del archivo resultante.

Pandas
Es una biblioteca de Python especializada en la manipulación y análisis de datos, esta escrito en C y su lanzamiento inicial fue en el 2008.

*Polars *
Es una biblioteca de Python y Rust especializada en la manipulación y análisis de datos que permite procesos paralelos y está escrito mayormente en Rust y su lanzamiento fue en el 2022.

La arquitectura del proceso:

Image description

El proyecto es algo sencillo como se muestra en la arquitectura: El usuario deposita un archivo CSV en work/pandas o work/porlas y automáticamente inicia el s3 trigger a procesar el archivo para convertirlo en parquet y depositarlo en processed.

En este pequeño proyecto utilice dos lambdas con la siguiente configuración:
Memoria: 2 GB
Memoria efímera: 2 GB
Tiempo de vida: 600 segundos

Requerimientos
Lambda con pandas: Pandas, Numpy y Pyarrow
Lambda con polars: Polars

El dataset utilizado para la comparación esta disponible en kaggle con el nombre de “Rotten Tomatoes Movie Reviews – 1.44M rows” o puede ser descargado desde aquí.

El repositorio completo está disponible en GitHub puede ser clonado aquí.

Tamaño o Peso
La lambda que utilizada Pandas requiere dos complementos mas para poder crear un archivo parquet en este caso es PyArrow y una versión en especifico de numpy para la versión de pandas que estaba utilizando. Como resultado obtuvimos una lambda con un peso o tamaño de 74.4 MB algo muy cercano al límite que nos permite AWS de peso de la lambda.

La lambda con Polars no requiere otro complemento como PyArrow lo que simplifica la vida y reduce el tamaño de la lambda a menos de la mitad. Como resultado nuestra lambda tiene un peso o tamaño de 30.6 MB comparado con la primera nos da una amplitud para instalar otras dependencias que podremos necesitar para nuestro proceso de transformación.

Performance

Image description
La lambda con Pandas fue optimizada para utilizar compresión luego de la primera versión, sin embargo, se analizó también su comportamiento.
Pandas
Se tardo 18 segundos en procesar el dataset y utilizo 1894 MB de memoria para procesar el archivo CSV y generar un archivo Parquet en comparación con las otras versiones fue la que mas tiempo y recursos utilizo.

Pandas + Compression
Agregando una línea de código permitió mejorar un poco comparada con la versión anterior (Pandas), se tardo 17 segundos en procesar el dataset y utilizo 1837 MB, lo cual, no representa una mejora significativa en procesamiento y tiempo computacional, pero si en el tamaño del archivo resultante.

Polars
Se tardo 12 segundos en procesar el mismo dataset y utilizo solamente 1462 MB, en comparación con las dos anteriores representa un ahorro de tiempo del 44.44% y un consumo de memoria inferior.

Tamaño del archivo de salida

Image description
Pandas
La lambda en la cual no se estableció un proceso de compresión nos genero un archivo parquet de 177.4 MB.

Pandas + Compression
Al configurar la compresión en la lambda no genero un archivo parquet de 121.1 MB. Una pequeña línea u opción nos ayudo a reducir el tamaño del archivo en un 31.74%. Considerando que no es un cambio significativo de código es una muy buena opción.

Polars
Polars nos genero un archivo de 105.8 MB que comprado con la primera versión de pandas representa un ahorro del 40.36% y un 12.63% contra la versión pandas con compression.

Conclusión
No es necesario cambiar todos los procesos internos que utilizan Pandas para que ahora utilicen Polars, sin embargo, es importante considerar que si hablamos de miles o millones de ejecuciones lambdas utilizar Polars nos ayudara no solo con el tiempo de despliegue si no que nos ayudara a tener un costo menor debido al cobro por tiempo que realiza AWS en los servicios Serverless como lo es Lambda.
Asimismo, cuando traducimos ese 40.36% en millones de archivo estamos hablando de GBs o TBs, algo que si tendría un impacto significativo dentro de Datalake o Dataware house o incluso en un almacen de archivos en frio.

La reducción con Polars no solo se limitaría a estos dos factores, porque afectaría mucho la salida de datos y/o objetos de AWS porque es un servicio que si tiene un costo.

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post
day-12:-advanced-aws-concepts-in-devops-–-part-2

Day 12: Advanced AWS Concepts in DevOps – Part 2

Next Post
building-your-first-full-stack-application

Building Your First Full-Stack Application

Related Posts
arkui-x平台差异化

ArkUI-X平台差异化

跨平台使用场景是一套ArkTS代码运行在多个终端设备上,如Android、iOS、OpenHarmony(含基于OpenHarmony发行的商业版,如HarmonyOS Next)。当不同平台业务逻辑不同,或使用了不支持跨平台的API,就需要根据平台不同进行一定代码差异化适配。当前仅支持在代码运行态进行差异化,接下来详细介绍场景及如何差异化适配。 使用场景 平台差异化适用于以下两种典型场景: 1.自身业务逻辑不同平台本来就有差异; 2.在OpenHarmony上调用了不支持跨平台的API,这就需要在OpenHarmony上仍然调用对应API,其他平台通过Bridge桥接机制进行差异化处理; 判断平台类型 可以通过let osName: string = deviceInfo.osFullName;获取对应OS名字,该接口已支持跨平台,不同平台上其返回值如下: OpenHarmony上,osName等于OpenHarmony-XXX Android上,osName等于Android XXX iOS上,osName等于iOS XXX 示例如下:…
Read More