Polars

 (pola.rs)
4 puntos por GN⁺ 2024-01-09 | 1 comentarios | Compartir por WhatsApp
  • Una biblioteca DataFrame de código abierto orientada a entornos que necesitan procesamiento de datos rápido en una sola máquina, con más de 575 millones de descargas y más de 38,000 estrellas en GitHub
  • La clave de su rendimiento está en un motor de consultas multihilo basado en Rust, junto con procesamiento orientado a columnas, vectorización, SIMD y ejecución en paralelo
  • Sigue ofreciéndose como una biblioteca de código abierto bajo licencia MIT, y también incluye Polars Cloud, que permite escalar hasta cargas de trabajo de producción con la misma API
  • Destaca mejoras de rendimiento de más de 30 veces frente a pandas, y el benchmark derivado de TPC-H se ejecutó en c3-highmem-22 con scale factor 10 e incluyendo I/O
  • Soporta CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, bases de datos principales, además de almacenamiento S3 y Azure, por lo que es fácil integrarlo en un stack de datos existente

Cómo se ofrece Polars

  • Polars es una biblioteca de código abierto para manipulación de datos, y se ha posicionado como una de las soluciones de procesamiento de datos más rápidas para una sola máquina
  • Ofrece una API estructurada y tipada, con el objetivo de combinar expresividad y facilidad de uso
  • Las métricas públicas actuales son las siguientes
    • 575M+ descargas
    • 38k+ estrellas en GitHub
  • La documentación inicial puede consultarse en Get started

  • Polars de código abierto

    • Polars es una biblioteca de código abierto disponible gratuitamente bajo licencia MIT
    • Se ofrece como una biblioteca DataFrame de alto rendimiento y su instalación también es sencilla
    • Los ejemplos de instalación son los siguientes
      • Python: pip install polars
      • Rust: polars = { version = "x", features = ["lazy", ...]}
      • Node.js: const pl = require('nodejs-polars');

  • Polars Cloud

    • Polars Cloud es una solución administrada que amplía las consultas de Polars en entornos de notebook hacia cargas de trabajo de producción en la nube o on-premises
    • Puede escalarse usando la misma API sin cambios en el código
    • Soporta despliegue en Cloud o On-Prem
    • La facturación se realiza solo por la ejecución de consultas
    • Puede probarse en Polars Cloud

Modelo de rendimiento e integración de datos

  • La base del rendimiento de Polars es un motor de consultas multihilo basado en Rust y un diseño pensado para el procesamiento en paralelo
  • La vectorización y el procesamiento orientado a columnas permiten algoritmos con coherencia de caché y alto rendimiento en procesadores modernos
  • Se comparó con varias soluciones en un benchmark TPC-H derivado e independiente, con el objetivo de reproducir tareas reales de limpieza de datos
    • Puede ofrecer mejoras de rendimiento de más de 30 veces frente a pandas
    • El benchmark se ejecutó en c3-highmem-22 con scale factor 10 e incluyendo I/O
    • Las consultas están publicadas como open source
    • Más detalles en Learn more

  • Usabilidad y optimización de ejecución

    • El usuario escribe las consultas de la forma que desea, y el optimizador de consultas de Polars determina la manera más eficiente de ejecutarlas
    • Divide el trabajo entre los núcleos de CPU disponibles y lo ejecuta en paralelo sin configuración adicional ni sobrecarga de serialización
    • Usa el modelo de memoria de Apache Arrow, lo que permite integrarlo con herramientas de datos existentes
    • El intercambio de datos zero-copy puede reducir el costo de colaboración entre herramientas
    • Está diseñado para operar cerca de la máquina sin dependencias externas, lo que permite controlar la API, la memoria y la ejecución
    • Los conjuntos de datos más grandes que la memoria pueden procesarse con la API de streaming sin necesidad de cargar todos los datos en memoria

  • Formatos de datos compatibles

    • Polars soporta lectura y escritura de formatos de datos comunes, por lo que puede integrarse con un stack de datos existente
    • El alcance del soporte es el siguiente
      • Text: CSV, JSON
      • Binary: Parquet, Delta Lake, AVRO, Excel
      • IPC: Feather, Arrow
      • Databases: MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
      • Cloud storage: S3, Azure Blob, Azure File

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-09
Opiniones de Hacker News

  • Es demasiado evidente que esta página está escrita para gente que ya sabe qué está viendo. Desde la primera frase empieza hablando de calidad, como “Polars is written from the ground up with performance in mind”, en vez de explicar la herramienta, y el resto sigue en la misma línea.
    ¿Alguien puede decirme como si tuviera 5 años qué es esto y para qué necesidad es una buena solución?
    Edición: al final lo entendí como una implementación alternativa de Pandas DataFrame. Según la explicación que encontré en Google en https://realpython.com/pandas-dataframe/, un DataFrame es una estructura que contiene datos bidimensionales y etiquetas, se usa mucho en áreas intensivas en datos como ciencia de datos, machine learning y cómputo científico, y se parece a una tabla SQL o a una hoja de cálculo de Excel/Calc.

    • Esta es precisamente una desventaja molesta de muchos productos técnicos. Es natural querer hablarle al público objetivo —en este caso, científicos de datos a quienes les gusta Pandas pero lo sienten lento y poco flexible—, pero a los principiantes les da la sensación de quedar excluidos.
      Yo soy parte del público objetivo de Polars y llevo meses queriendo probarlo, pero lo sigo posponiendo. Mantengo cierta lealtad a Pandas porque Wes McKinney, su creador, escribió un libro útil que explica herramientas comunes de análisis: https://wesmckinney.com/book/.
    • Es Pandas, pero rápido. Pandas es la biblioteca original open source de dataframes; es sólida y se usa mucho, pero parece tener un alcance amplio y ser más lenta que esta recién llegada. La palabra “dataframe” ya funciona como señal inmediata para quienes la han usado.
    • Cada vez que veo páginas como esta me siento más humilde. “DataFrame para la nueva era”: me pregunto si de verdad sé qué es un dataframe; y cuando veo “motor de consultas multihilo”, pienso si será algo parecido a una base de datos.
      Aparece una gráfica comparándolo con cosas llamadas pandas, modin y vaex, pero tampoco sé nada de ellas, así que al final siento que esto no es para mí. Me gusta leer y aprender sobre tecnologías o proyectos nuevos, pero aquí no encuentro de dónde agarrarme.
      Probablemente esto es lo que le pasa a la gente común cuando hablo de mis insignificantes temas de desarrollo web.
    • Para ser justos, el título de la página es “Dataframes for the new Era”, y el enlace Get Started debajo del título apunta a la documentación en la página de GitHub. GitHub les explica qué es esta biblioteca a personas con contexto en análisis de datos: https://github.com/pola-rs/polars
    • Ahora me están arrastrando hacia trabajos del lado de “datos”, y esto se siente como un universo paralelo con su propio trasfondo y cultura. Hay muchas expresiones del estilo “conectar a una instancia de Antelope o Meringue con la usabilidad de Nincompoop y el rendimiento de ARSE2”.
      Lo interesante de Polars es que se parece a Pandas, pero usa Arrow, un backend en Rust más eficiente, y tiene algo como un planificador de consultas que hace más eficientes las combinaciones de operaciones. En general, Polars es mucho más eficiente que Pandas, por lo que muchas tareas que antes requerían infraestructura compleja ahora suelen poder hacerse en una sola máquina.
      Es una competencia muy amistosa creada por un desarrollador principal de Pandas; parece que a todos les gusta y, con el tiempo, tiene muchas posibilidades de reemplazar a Pandas.

  • Artículos relacionados:
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - agosto de 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - agosto de 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - enero de 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - enero de 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - enero de 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - diciembre de 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - diciembre de 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - julio de 2020

  • Usé Pandas durante años, pero siempre se sintió como empujar una piedra cuesta arriba. Incluso en tareas simples como los joins, y tampoco hay que olvidarse de restablecer el índice
    Polars se siente mejor que Pandas en casi todos los aspectos. Es más rápido, usa múltiples núcleos, consume menos memoria y su API es más intuitiva. Todavía es una biblioteca relativamente joven y tiene desventajas, pero si es un proyecto nuevo, al menos vale la pena evaluarla
    También es excelente poder aprovechar fácilmente el ecosistema de Rust. Escribí un plugin propio para paralelizar una función e hice que parte de código geoespacial fuera 100 veces más rápido

    • Es un poco irónico que hayas puesto los joins como ejemplo. Siempre pensé que el mayor problema de Pandas era la documentación. Por ejemplo, ¿sabías que hay una forma de hacer join de dataframes sin usar índices? No se llama “join”, sino merge
      Pandas al principio estuvo muy influenciado por la terminología y los patrones de uso de R, y en R “merge” ya era una palabra común para decir “join”. Si cuando empecé a aprender Pandas, alrededor de 2015, no hubiera conocido ya R, creo que me habría costado aprenderlo rápido
    • Me interesa saber qué opinan de PRQL(prql-lang.org). Personalmente, creo que combina la sensación de uso y la experiencia de desarrollo de Polars o Pandas con el poder y la universalidad de SQL
      Las consultas pueden ejecutarse no solo en Polars y Pandas, sino también en cualquier motor de ejecución compatible con SQL que prefieras, como DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite, etc.
      La sintaxis y la semántica de los joins son una de las partes más difíciles, así que recientemente las estamos discutiendo de nuevo. Son el núcleo del álgebra relacional y también corresponden a la R de PRQL. La mayoría de las transformaciones básicas de PRQL son manipulaciones simples de listas como map, filter y reduce, pero los joins requieren cuidado si se quiere preservar la composición monádica. Dejé mis ideas aquí: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      Ese issue ya está cerrado, pero sería bueno que abrieras uno nuevo o me etiquetaras como @snth para compartir tu opinión. Como referencia, soy contribuidor de PRQL
    • Me da curiosidad qué es lo difícil al combinar dataframes en Pandas

  • Al evaluarlo, la mayor ventaja fue que la API era mucho más consistente y fácil de entender que la de Pandas. Tiene sentido, porque seguramente aprendieron de las 20 versiones principales de Pandas
    Pero como se usa mucho menos, Copilot no escribía bien código de Polars. Así que por ahora sigo usando Pandas y Copilot. Esta fue la primera vez que sentí que existe esa barrera en general para las bibliotecas nuevas

    • Es la primera vez que veo a alguien decir públicamente que prefiere una biblioteca por el soporte de Copilot. No lo digo para juzgar, me parece interesante
      Aun así, Copilot aprende muy rápido dentro de un repositorio. Yo uso un stack extremadamente personalizado armado con TS-Plus, un fork de TypeScript que ni siquiera su propio autor usa o recomienda, y Copilot produce código TS-Plus bastante bueno
      Después de ver algunos ejemplos, conviene no subestimar que Copilot puede volverse bastante bueno en la etapa de código repetitivo
    • El soporte de Copilot es un problema del huevo y la gallina. Tiene que aprender del código de otras personas, pero si la gente no escribe código de Polars sin Copilot, Copilot tampoco llegará a escribir mejor código de Polars
    • Me pasó algo parecido al usar danfo.js, otra biblioteca de dataframes para JS. Copilot simplemente alucinaba funciones y nombres de métodos
      No era un gran problema porque podía leer la documentación, pero era molesto que Copilot no pudiera escupir de inmediato lo que necesitaba
    • ¿Reconoces que la API es más consistente y fácil de entender, pero aun así te quedarías en Pandas solo porque Copilot te lo facilita? Tanto para ti como para la innovación open source, conviene usar la herramienta que reconoces como mejor
      He usado durante mucho tiempo la API de Pandas y la odiaba. Soy bastante proactivo a la hora de seguir mejorando mi aprendizaje, herramientas, formas de pensar y habilidades
    • La biblioteca Polars cambia rápido. No uso Copilot, pero con ChatGPT obtuve resultados bastante buenos poniendo en las instrucciones del sistema información actualizada, por ejemplo que with_column cambió a with_columns, y agregando contenido de la documentación

  • Cuando Deno lanzó soporte para Jupyter, nodejs-polars fue una de las bibliotecas clave de ciencia de datos que soportaron
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    Personalmente no soy alguien del área de ciencia de datos, pero considerando que el ecosistema JS/Jupyter todavía está en una etapa temprana, fue sorprendentemente rápido levantar análisis basados en pola.rs desde TypeScript
    Los bindings de JS claramente tienen cosas por pulir, pero espero que la mayor accesibilidad impulse mejoras iterativas

    • Siempre quise algo tipo Pandas en JS; recién me entero de esto

  • Polars realmente me entusiasma y su rendimiento en velocidad es impresionante, pero me molesta que comparen vaex, modin y dask en el mismo benchmark
    Todas esas bibliotecas apuntan al procesamiento de datos fuera del núcleo, es decir, a casos en que los datos son demasiado grandes y el cálculo debe distribuirse entre varias máquinas. Compararlas con una biblioteca de dataframes para una sola máquina es raro, y como inevitablemente tienen bastante overhead, van a ser más lentas
    No hay muchos casos en los que usarías Polars en el mismo contexto que esas bibliotecas, así que mostrarlas en el benchmark como si fueran equivalentes resulta un poco ridículo. Además, DuckDB, que sí puede usarse en el mismo contexto que Polars y en muchos casos es más rápido, no aparece en el benchmark
    La ingeniería de software de Polars es un trabajo excelente y no necesita benchmarks que puedan llevar a malentendidos

    • No sé sobre las demás, pero Dask también se puede usar en una sola máquina, y de hecho esa es la forma más fácil de usarlo. Divide el dataframe en particiones y las procesa en cada núcleo para paralelizar las operaciones
      Sin configuración, se puede lograr una mejora de rendimiento de 2 veces frente a Pandas, y en ciertas operaciones he visto hasta 5 veces
    • Ibis, un dataframe de Python creado por el fundador de Pandas, usa DuckDB como backend predeterminado y, salvo algunas excepciones en consultas, normalmente vence a Polars en este tipo de benchmarks

  • No uso Polars directamente, sino como formato materializado en un flujo de trabajo con DuckDB.
    duckdb.query(sql).pl() es mucho más rápido que duckdb.query(sql).df(). Con Polars es zero-copy y termina de inmediato, pero con Pandas, si el DataFrame es grande, tarda bastante. Además, se puede manipular como un DataFrame de Pandas; la sintaxis solo cambia un poco.
    Es muy bueno para manejar datasets grandes.

  • Creo que podría haber un corolario de la décima regla de Greenspun (https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)): toda biblioteca de análisis de datos lo suficientemente compleja termina implementando la mitad de SQL de manera improvisada, con una especificación no oficial, llena de bugs y lenta.
    Uso Pandas de vez en cuando y probablemente también pruebe esto, pero siempre pienso que habría sido mejor simplemente meter los datos en los que estoy trabajando en Postgres desde el principio.
    Aunque no soy experto en bases de datos y Python me resulta mucho más cómodo, para seleccionar, ordenar, filtrar y unir datos tabulares, SQL es mucho mejor.

    • Recomiendo ver DuckDB y la extensión duckdb-prql.
      DuckDB permite trabajar directamente con datos en formato Polars, Pandas y Arrow usando SQL, sin copiar ni duplicar datos.
      duckdb-prql permite usar PRQL (prql-lang.org) y, personalmente, creo que combina la potencia y universalidad de SQL con la sensación de uso y la experiencia de desarrollo de Polars o Pandas. Como referencia, soy contribuidor de PRQL.
    • Se puede hacer eso, pero si son consultas “analíticas”, es muy probable que el rendimiento sea mucho peor y que también pierdas flexibilidad y expresividad.
      En cambio, vale la pena echarle un vistazo a DuckDB. Su implementación de SQL no es improvisada, ni está llena de bugs, ni es lenta o incompleta. No sé qué tan formal sea su especificación, pero es compatible con Polars.
    • Personalmente, la sintaxis de dataframes diferidos me parece un frontend mucho mejor para un motor de consultas. Polars también soporta SQL, pero los bugs normalmente no vienen del frontend, sino del motor de consultas.
      Para el tipo de consultas que se hacen con estos motores, Postgres probablemente sea un orden de magnitud más lento que un motor de consultas OLAP.
    • Por este motivo, el creador de Pandas hizo Ibis, con backend para Postgres: https://ibis-project.org/backends/postgresql
      Es un mejor enfoque para usar juntos dataframes de Python y SQL.

  • Hace unos meses intenté migrar una gran base de código en Pandas a Polars. No me gusta mucho hacer análisis o pipelines de datos en Python, porque las transformaciones complejas tardan 2 a 5 veces más en Pandas que en Julia o R (usando dataframes.jl, dplyr).
    Lamentablemente, Polars tampoco fue la respuesta. Tenía demasiados bugs en operaciones estándar y la interoperabilidad con Pandas era inestable. Eso es un problema porque muchas bibliotecas exigen un DataFrame de Pandas como entrada. La API también es muy verbosa para una biblioteca moderna de dataframes, aunque aun así es mejor que Pandas.
    Espero que se resuelva con el tiempo, pero por ahora lo que mejor me funcionó fue usar DuckDB sobre Pandas. Es tan rápido como Polars, pero más estable y con mejor interoperabilidad.
    Ojalá algún día el ecosistema de dataframes en Python llegue a un punto similar al de R, donde sea fácil usar en conjunto una biblioteca de dataframes orientada al análisis con una API intuitiva (dplyr) y una biblioteca de dataframes de alto rendimiento (data.table).

    • A mí también me molestó lo verboso que es. Pandas también es bastante verboso comparado con algo como data.table, pero Polars se siente más como usar una API que como una “herramienta de manipulación de datos”.
      Probablemente no lo usaría para análisis exploratorio de datos o investigación, pero empecé a usarlo en algunos scripts de producción por su mejor rendimiento.
      La combinación dplyr + data.table de R sigue siendo mi experiencia favorita para manipulación de datos. Eso sí, ojalá R tuviera algo como Matplotlib. ggplot es demasiado de alto nivel y los gráficos base son demasiado de bajo nivel. Scikit-Learn también es mucho más modular que Caret, así que no extraño Caret.
    • Me da curiosidad qué opinas de PRQL (prql-lang.org). Su objetivo es dar la sensación de uso de dplyr en cualquier lugar donde se use SQL, y compila a SQL.
      Personalmente, creo que combina la experiencia de desarrollo de dplyr, Polars y Pandas con la potencia y universalidad de SQL. Las consultas se pueden ejecutar no solo en Polars y Pandas, sino también en cualquier motor de ejecución compatible con SQL que prefieras, como DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite, etc.
      Me gustaría escuchar tus ideas en las discusiones de GitHub (https://github.com/PRQL/prql/discussions) o en Discord (https://discord.com/invite/XWxbCrWr). Como referencia, soy contribuidor de PRQL.
    • Qué bueno que tengas experiencia con dataframes en R, Python y Julia. Me da curiosidad cuál te gusta más. Sé que los ecosistemas no son directamente comparables, pero en tareas como operaciones básicas, ¿cuál te pareció mejor?
    • También vale la pena probar Ibis con backend DuckDB. Personalmente, Polars también me gusta bastante. En general, sus desarrolladores responden bastante rápido a los issues.

  • Nuestro equipo de ciencia de datos evaluó Polars y los resultados fueron mixtos. Si hubiera tramos donde el rendimiento fuera crítico, consideraríamos adoptarlo, pero fuera de eso estuvimos algo negativos por el costo de reemplazar Pandas en decenas de proyectos

    • Creo que esa evaluación es correcta. Ahora lo veo más como un momento para experimentar que para reemplazar Pandas que ya funciona bien
      La API todavía tiene cambios incompatibles previsibles, y en varios proyectos eso puede convertirse en una carga de mantenimiento. Aun así, la API ya se siente más consistente y, en general, parece ir en la dirección correcta
    • Es mejor no reescribir todo el código. Pero en código nuevo sí vale la pena adoptarlo o evaluarlo
      En especial porque el costo de interoperar con Pandas es muy bajo, y si se usa el backend de Arrow, también es bastante fácil hacer una conversión zero-copy a Pandas
    • Para el futuro está https://github.com/fugue-project/fugue
    • Me da curiosidad si en el equipo usan pandasql o si principalmente usan directamente la API de Pandas