Análisis De Datos el josiete.com

Polars: Python acelera sus DataFrames con Rust y varios hilos

Thu, 24 Sep 2026 00:00:00 +0000

Python sigue siendo uno de los lenguajes más cómodos para explorar y transformar datos. Sin embargo, la comodidad de un DataFrame no siempre se traduce en velocidad: cuando crecen las columnas y las filas, el coste de memoria y de CPU se vuelve muy visible. Polars aborda ese problema con una librería de DataFrames escrita en Rust y con una API disponible desde Python.

¿Qué es Polars?

Polars es un motor de consultas analíticas y una librería de DataFrames para trabajar con datos tabulares. Su núcleo está escrito en Rust, utiliza un modelo de memoria compatible con Apache Arrow y combina ejecución vectorizada, optimización de consultas y procesamiento por columnas.

La API ofrece dos estilos. El modo eager ejecuta cada operación al momento, algo útil para exploraciones interactivas. El modo lazy construye un plan de consulta: Polars puede reordenar operaciones, eliminar columnas que no hacen falta y aplicar filtros tan pronto como sea posible antes de ejecutar el resultado.

No es una sustitución universal de una base de datos o de un sistema distribuido. Su punto fuerte es exprimir una máquina —portátil o servidor— y trabajar con CSV, Parquet, JSON y otras fuentes sin obligar al usuario a administrar un clúster.

El paralelismo: más de un hilo sin escribir código de concurrencia

Una diferencia importante frente a muchos flujos tradicionales de Python es que Polars no delega todo el trabajo pesado en el hilo principal del intérprete. Las operaciones del motor están implementadas en Rust y su planificador utiliza un thread pool para repartir tareas entre los núcleos disponibles. El motor es vectorizado, columnar y multihilo; por eso un filtro, una agregación o un join puede aprovechar varios cores automáticamente.

En la práctica, esto significa que el usuario escribe expresiones normales de Polars y el motor decide cómo paralelizarlas. No hace falta crear un ThreadPoolExecutor, serializar cada partición ni coordinar manualmente los resultados. La API de Python actúa como una interfaz; el cálculo intensivo ocurre en el núcleo nativo.

Se puede consultar el tamaño del grupo de hilos con pl.thread_pool_size() en versiones actuales. Polars lo configura automáticamente de forma razonable, pero en un entorno compartido —por ejemplo, dentro de un worker que ya limita la CPU— puede fijarse POLARS_MAX_THREADS antes de importar la librería:

POLARS_MAX_THREADS=4 python analizar_ventas.py

Conviene no confundir este paralelismo con la ejecución distribuida: varios hilos aprovechan los núcleos de una sola máquina. Para datos que no caben en memoria, el motor lazy también puede ejecutar en streaming cuando el plan lo permite; para escalar horizontalmente existe una capa distribuida separada.

La empresa detrás del proyecto

Polars nació en 2020 como un proyecto personal de Ritchie Vink, inicialmente para aprender sobre motores de consultas, Apache Arrow y Rust. El 3 de agosto de 2023, Vink y Chiel Peters anunciaron la creación de Polars Inc., una empresa con sede en Ámsterdam orientada a aportar ingeniería y estabilidad a largo plazo al ecosistema.

La empresa no sustituyó al proyecto comunitario: Polars continúa siendo software libre bajo licencia MIT. Su objetivo es financiar el desarrollo del motor, mejorar conectores y ofrecer productos para ejecutar consultas a mayor escala, incluido Polars Cloud. Es una separación interesante: una compañía puede construir servicios comerciales alrededor del proyecto mientras el núcleo abierto sigue disponible para cualquiera.

Un ejemplo en Python

Instalamos la librería con pip y construimos una pequeña transformación. scan_csv devuelve un LazyFrame, por lo que las operaciones se planifican y collect() ejecuta el plan optimizado.

pip install polars

import polars as pl

ventas = pl.scan_csv("ventas.csv")

resultado = (
 ventas
 .filter(pl.col("estado") == "pagado")
 .with_columns(
 (pl.col("unidades") * pl.col("precio")).alias("importe")
 )
 .group_by("categoria")
 .agg(
 pl.col("importe").sum().alias("facturacion"),
 pl.col("unidades").sum().alias("unidades")
 )
 .sort("facturacion", descending=True)
 .collect()
)

print(resultado)

El código expresa qué queremos obtener y deja que Polars decida cómo recorrer las columnas y repartir el trabajo. En un fichero grande, el modo lazy puede evitar leer columnas innecesarias y empujar el filtro hacia la lectura. Si el origen ya es Parquet, pl.scan_parquet("datos/*.parquet") permite mantener el mismo patrón.

¿Cuándo elegirlo?

Polars encaja especialmente bien en pipelines de transformación, análisis exploratorio con volúmenes grandes, preparación de datos para modelos y servicios que necesitan respuestas rápidas sin levantar un sistema distribuido. Si el proyecto depende de un ecosistema concreto de pandas, la migración requiere revisar algunas operaciones y tipos; aun así, ambas librerías pueden convivir y Polars permite convertir a pandas cuando sea necesario.

La idea central es sencilla: Python conserva una interfaz expresiva, mientras Rust se ocupa del trabajo intensivo, la memoria y el paralelismo. Esa combinación convierte a Polars en una opción muy atractiva cuando un DataFrame deja de ser pequeño, pero todavía queremos que el análisis viva cerca de nuestro código.

DuckDB: el pato analítico que acaba de aterrizar en AWS

Wed, 23 Sep 2026 00:00:00 +0000

Hay herramientas que aparecen en los pipelines de datos porque una gran empresa las impone y otras que se extienden porque resuelven un problema cotidiano con una elegancia difícil de ignorar. DuckDB pertenece a la segunda categoría. Es una base de datos analítica embebida, pequeña, rápida y capaz de consultar archivos locales o remotos con SQL. En los últimos años se ha convertido en una pieza habitual del trabajo de Data Engineering, Data Science y Analytics Engineering.

Y ahora está en el centro de una noticia importante: Amazon ha incorporado DuckLabs a AWS, la empresa de Ámsterdam creada alrededor del equipo que desarrolla DuckDB. La operación se anunció en agosto de 2026 y DuckLabs confirmó que se completó el 31 de agosto. La parte importante para los usuarios es que no se ha comprado el proyecto open source: DuckDB continúa bajo la tutela independiente de la DuckDB Foundation y bajo licencia MIT.

¿Qué es DuckDB?

DuckDB es un sistema gestor de bases de datos relacional orientado a análisis —OLAP—. A diferencia de una base de datos servidor tradicional, se ejecuta dentro del proceso de la aplicación: se importa como una librería de Python, R, Go, Java, Rust, Node.js o C++, o se usa desde su CLI.

SELECT country, sum(amount) AS total
FROM 'sales/*.parquet'
GROUP BY country
ORDER BY total DESC;

No hace falta levantar un clúster ni crear primero una tabla intermedia. DuckDB puede consultar directamente CSV, Parquet, JSON y otros formatos, incluidos datos accesibles mediante HTTP(S) o S3. Su motor vectorizado procesa lotes de valores en cada operación y está optimizado para escanear, filtrar, agregar y combinar cantidades grandes de datos.

La comparación que mejor lo explica es con SQLite: ambos son sencillos, embebidos y portables, pero SQLite está pensado principalmente para cargas transaccionales y DuckDB para consultas analíticas. No es un sustituto universal de PostgreSQL, una cola de eventos o un warehouse distribuido. Su virtud es ocupar un lugar muy concreto y hacerlo extraordinariamente bien.

¿Quién lo mantiene?

DuckDB nació en el grupo de arquitecturas de bases de datos de CWI Amsterdam, con Hannes Mühleisen y Mark Raasveldt entre sus creadores. El desarrollo profesional se organizó en DuckDB Labs, que posteriormente pasó a llamarse DuckLabs.

La pieza de gobernanza clave es la DuckDB Foundation, una fundación neerlandesa sin ánimo de lucro que posee la propiedad intelectual y las marcas del Duck Stack. Su consejo incluye a los creadores de DuckDB y a Peter Boncz, investigador de sistemas de bases de datos. DuckLabs aporta el equipo de ingeniería; la Foundation protege el proyecto y su licencia abierta.

¿Por qué es software libre?

DuckDB se distribuye bajo la licencia MIT, una licencia permisiva que permite usar, estudiar, modificar y redistribuir el software, también dentro de productos comerciales. La propia documentación de DuckDB explica que el proyecto nació en un entorno de investigación pública neerlandesa y que sus autores consideran una responsabilidad social hacer accesibles sus resultados.

La libertad no es solo una cuestión moral o académica. En una herramienta que se coloca en medio de un pipeline, poder inspeccionar el motor, compilarlo para distintas arquitecturas y añadir extensiones reduce el riesgo de dependencia. También permite que universidades, empresas, fabricantes de herramientas y usuarios individuales trabajen sobre la misma base.

¿Por qué se ha puesto tan de moda en Data Engineering?

La popularidad de DuckDB no se explica por una única característica, sino por cómo encajan varias:

Cero infraestructura para empezar: se instala como una librería y no exige administrar servidores.
SQL sobre archivos: convierte un directorio de Parquet o CSV en una fuente consultable sin cargarlo antes en un sistema central.
Velocidad analítica: su ejecución columnar y vectorizada encaja con agregaciones, joins y escaneos completos.
Portabilidad: funciona en un portátil, un contenedor, una función, un navegador mediante WebAssembly o un servidor grande.
Encaje con Python y R: permite pasar de un DataFrame a SQL y volver sin mover innecesariamente los datos.
Interoperabilidad: Parquet, JSON, HTTP(S), S3, extensiones y formatos de lakehouse forman parte de su ecosistema.
Reproducibilidad: un fichero de base de datos o un script SQL puede acompañar al proyecto y ejecutarse en CI, en local o en un notebook.

Esto cambia el orden tradicional de algunos flujos. En vez de subir todos los datos a un warehouse para empezar a explorar, un ingeniero puede hacer una primera transformación local sobre los objetos del lake, validar una hipótesis y materializar solo lo que merece convertirse en un proceso permanente. DuckDB no elimina el warehouse: hace más barato y rápido el trabajo que ocurre antes, al lado o entre sus consultas.

La adquisición de Amazon: qué ha pasado realmente

Conviene ser preciso con los términos. AWS ha adquirido DuckLabs, no el proyecto DuckDB como si fuera una aplicación cerrada. Según Amazon, Hannes Mühleisen y Mark Raasveldt seguirán liderando el equipo y la dirección técnica del proyecto. Según el anuncio de DuckLabs, el equipo permanece unido en Ámsterdam, DuckDB, DuckLake y Quack continúan bajo la Foundation y el software sigue bajo MIT.

El interés de AWS es comprensible: DuckDB es una capa muy eficaz para trabajar cerca de los datos, especialmente en S3, y puede conectar ficheros, notebooks, aplicaciones, lakehouses y servicios analíticos. La combinación da a AWS acceso a talento especializado y al proyecto le da recursos, infraestructura y una distribución comercial mucho mayores.

¿Cambiará el diseño de DuckDB?

Todavía es pronto para afirmar qué decisiones concretas cambiarán. Los anuncios públicos dicen que no cambian la licencia, la gobernanza ni la hoja de ruta inmediata. Lo que sí podemos hacer es plantear hipótesis razonables:

Más profundidad en el ecosistema cloud. Es probable que veamos más trabajo en S3, formatos de lakehouse, catálogos, permisos y conexiones con servicios de AWS. El reto será mejorar esa integración sin convertir DuckDB en un cliente privilegiado de un solo proveedor.
Más inversión en funcionamiento remoto. DuckDB nació como motor embebido, pero su ecosistema ya explora protocolos y escenarios distribuidos. AWS puede acelerar características que permitan pasar de la exploración local a datos remotos sin perder la sencillez del modelo.
Mayor presión sobre extensiones y compatibilidad. La Foundation y DuckLabs han indicado que quieren ampliar la comunidad y el sistema de extensiones. Eso puede traer más conectores y formatos, pero también exige mantener APIs estables, seguridad y una experiencia coherente.
Diseño vendor-neutral como decisión estratégica. Paradójicamente, para que AWS obtenga valor a largo plazo, DuckDB debe seguir siendo útil fuera de AWS. La adopción que lo hizo valioso depende de que funcione en local, en otras nubes, en notebooks y dentro de productos de terceros.

Estas son inferencias, no compromisos publicados. La prueba será observar si las nuevas integraciones se diseñan como extensiones abiertas y si la comunidad conserva capacidad real para discutir la hoja de ruta. La Foundation ya ha anunciado un consejo asesor técnico con participación de la comunidad, algo que puede ayudar a convertir esa apertura en práctica de diseño.

La pregunta interesante

La compra no responde solo a si Amazon puede sacar provecho de DuckDB. La pregunta más interesante es si una empresa cloud puede financiar un componente de infraestructura que siga siendo neutral, pequeño y agradable de usar, incluso cuando ese componente haga más sencillo trabajar fuera de su propia nube.

Por ahora, la respuesta oficial es tranquilizadora: DuckDB sigue siendo libre, la licencia MIT permanece y la Foundation conserva la tutela del proyecto. El futuro dependerá de las decisiones menos visibles: qué se prioriza, qué se mantiene fuera del núcleo, cómo se aceptan extensiones, cómo se cuida la portabilidad y quién tiene voz cuando hay un conflicto entre la comunidad y los intereses de AWS.

DuckDB se puso de moda porque redujo la distancia entre una pregunta y una respuesta sobre datos. Su siguiente etapa será interesante si consigue reducir también la distancia entre el mundo local y la nube sin obligarnos a escoger una sola de las dos cosas.