Big data

PySpark: cuando pandas ya no aguanta y hay que repartir el trabajo

PySpark es la forma de usar Apache Spark desde Python: se escribe código parecido al de pandas y el motor reparte el cálculo entre los núcleos de un computador o entre muchas máquinas. Se instala con una sola orden, pide Java, y conviene cuando los datos ya no caben con holgura en la memoria de un solo equipo.

Por Jhon Mosquera14 nov 202612 min de lectura

Última actualización: 2026-11-14

Contenido de esta página

El 27 de febrero de 2013, el proyecto Spark anunció su versión 0.7.0 [1]. Era, según sus notas, el lanzamiento más grande hasta entonces: 31 personas aportaron código, y 20 de ellas no eran de Berkeley, la universidad donde nació el proyecto [1]. La novedad que encabezaba la lista era una interfaz para Python llamada PySpark [1].

Las notas nombran a Josh Rosen como su desarrollador principal [1]. Las notas destacan una decisión de diseño: usar el Python de siempre, el intérprete estándar llamado CPython. Así, los programas podían llamar a librerías como NumPy y SciPy, las de cálculo numérico que ya usaban los científicos [1].

Las notas cuentan también, en una frase, cómo llega el código a las máquinas. «Como las API de Scala y Java, PySpark enviará automáticamente las funciones de su programa principal, junto con las variables de las que dependen, al clúster» [1]. Un clúster es un grupo de computadores que trabajan como uno solo. Las citas de esta página son traducción propia.

Trece años después, PySpark se sigue usando así. Usted escribe en Python, pero el trabajo pesado lo hace Spark. Y cada vez que una función de Python tiene que tocar los datos, esos datos salen del motor hacia Python y vuelven: un viaje con un costo que conviene conocer.

Compuerta de riego que reparte el agua en varios canales paralelos en un arrozal al amanecer

¿Qué es PySpark?

PySpark es la interfaz de Python para Apache Spark, el motor gratuito que reparte el análisis de muchos datos entre varias máquinas. Su documentación oficial lo dice así: «PySpark es la API de Python para Apache Spark» [2]. Una API, o interfaz de programación, es el conjunto de órdenes con que un programa le pide trabajo a otro.

Con PySpark se procesan datos a gran escala desde Python, en un entorno distribuido, es decir, repartido entre varias máquinas [2]. Trae además una consola interactiva para explorar datos [2]. Según la misma documentación, soporta todas las funciones de Spark: consultas SQL, DataFrames, flujos de datos continuos y aprendizaje automático, entre otras [2].

La versión estable más reciente es la 4.3.0. Se publicó en PyPI, el registro oficial de paquetes de Python, el 30 de octubre de 2026 [3]. Se distribuye con la licencia Apache 2.0, así que se descarga y se usa sin pagar [3].

Apache Spark vs. PySpark: ¿son lo mismo?

No son lo mismo. Spark es el motor; PySpark es una de las puertas para hablarle. La misma documentación lo deja claro: tanto si usted escribe en Python como en SQL, por debajo trabaja el mismo motor de ejecución [2].

Por eso esta página no repite cómo piensa Spark por dentro. El programa central que reparte tareas, el plan de pasos y el costo de mover datos entre máquinas están explicados en la guía de Apache Spark. Aquí el tema es lo que usted escribe en Python.

Cómo instalar PySpark en su computador

PySpark se instala con pip, el instalador de paquetes de Python. La documentación aclara que esa vía suele usarse para trabajar en local o para conectarse a un clúster que ya existe, no para montar uno [4]. Para aprender, alcanza.

Los requisitos de la versión 4.3.0 son dos. Python 3.11 o posterior [4]. Y Java 17 o posterior, con la variable de entorno JAVA_HOME bien configurada [4]. Una variable de entorno es un ajuste del sistema que les dice a los programas dónde está algo, en este caso Java.

Los pasos son estos:

  1. Compruebe que tiene Java. En una terminal, la orden «java -version» debe responder con la versión 17 o una posterior.
  2. Cree un entorno aislado para no mezclar paquetes. La documentación propone el módulo venv que trae Python [4].
  3. Instale el paquete con «pip install pyspark» [4]. Pip descarga también py4j, la pieza que comunica Python con Java [4].
  4. Compruebe que quedó instalado. La orden «python -c “import pyspark; print(pyspark.__version__)”» debe imprimir el número de versión.

En mi equipo, ese último paso imprimió 4.3.0, con Python 3.12.13 y Java 21.

Dos avisos antes de seguir. El primero: la instalación básica no trae pandas ni PyArrow, la librería de Python del formato de datos Arrow. Para la interfaz de pandas sobre Spark hay que pedir el extra «pip install pyspark[pandas_on_spark]» [4]. Para la versión 4.3.0, la tabla de dependencias pide pandas 2.2 o posterior, pero anterior a la 3.0 [4]. Si su proyecto ya trabaja con pandas 3, revise esa compatibilidad antes de mezclarlos.

El segundo aviso es para Windows. Al arrancar, Spark puede quejarse de que no encuentra «winutils.exe» ni la librería nativa de Hadoop. A mí me pasó, y el ejemplo de abajo corrió igual. Hadoop es el ecosistema de almacenamiento y cálculo distribuido del que viene parte del código que Spark empaqueta; la documentación indica que la distribución por defecto usa Hadoop 3.5 [4]. Qué es Hadoop está en la guía de Hadoop.

SparkSession y DataFrame: el primer programa en PySpark

Todo programa de PySpark empieza con una SparkSession, la sesión que funciona como puerta de entrada [5]. Si usted abre la consola de PySpark, la sesión ya viene creada en una variable llamada «spark» [5].

Con la sesión se crean o se leen DataFrames. Un DataFrame es una tabla de dos dimensiones, con columnas que tienen nombre y pueden guardar tipos de dato distintos [6]. La guía lo compara con una hoja de cálculo o con una tabla de una base de datos [6]. Se puede crear a partir de una lista de filas, de un DataFrame de pandas o leyendo archivos [5]. Sirven los de texto separado por comas (CSV) y los formatos que guardan los datos por columnas, como Parquet y ORC (Optimized Row Columnar, un formato de columnas optimizado) [5].

Hay una diferencia de fondo con pandas. Un DataFrame de Spark es inmutable: no se modifica, y cada operación devuelve uno nuevo [6]. Además vive dentro de la sesión que lo creó y desaparece con ella [6].

El ejemplo usa datos inventados: lecturas de sensores de humedad del suelo en tres lotes de un cultivo, tomadas tres veces al día. Hace cinco cosas: crea la sesión, arma dos tablas, encadena transformaciones, pide el resultado y compara dos maneras de escribir la misma regla.

# DATOS SINTÉTICOS: lecturas inventadas de sensores de humedad del suelo en tres lotes de un cultivo
from pyspark.sql import SparkSession
from pyspark.sql import functions as F
from pyspark.sql.types import StringType

# 1. La sesión: la puerta de entrada a PySpark (aquí, en modo local con 2 hilos)
spark = SparkSession.builder.master("local[2]").appName("humedad").getOrCreate()
spark.sparkContext.setLogLevel("ERROR")

# 2. Dos DataFrames pequeños: las lecturas y la ficha de cada sensor
lecturas = spark.createDataFrame(
    [("S1", "06:00", 31.5), ("S1", "12:00", 24.0), ("S2", "06:00", 18.2),
     ("S2", "12:00", 12.9), ("S3", "06:00", 40.1), ("S3", "12:00", 35.7),
     ("S1", "18:00", 22.4), ("S2", "18:00", 11.0), ("S3", "18:00", 33.3)],
    "sensor string, hora string, humedad double",
)
sensores = spark.createDataFrame(
    [("S1", "Lote norte"), ("S2", "Lote sur"), ("S3", "Lote quebrada")],
    "sensor string, lote string",
)

# 3. Transformaciones: seleccionar, filtrar, unir, agrupar y resumir (todavía no se calcula nada)
tarde = lecturas.select("sensor", "humedad").filter(F.col("hora") != "06:00")
resumen = (
    tarde.join(sensores, on="sensor", how="inner")
    .groupBy("lote")
    .agg(F.round(F.avg("humedad"), 2).alias("humedad_media"),
         F.min("humedad").alias("humedad_minima"))
    .orderBy("lote")
)

# 4. La acción: show() pide el resultado y dispara el cálculo
resumen.show()

# 5. La misma regla de negocio, escrita dos veces
#    a) con una UDF de Python: cada valor viaja al proceso de Python y vuelve
@F.udf(returnType=StringType())
def estado_udf(humedad):
    if humedad is None:
        return None
    return "seco" if humedad < 20 else "normal"

#    b) con funciones integradas de Spark: el cálculo se queda dentro del motor
estado_integrado = F.when(F.col("humedad") < 20, "seco").otherwise("normal")

comparacion = lecturas.select(
    "sensor", "hora", "humedad",
    estado_udf("humedad").alias("con_udf"),
    estado_integrado.alias("integrada"),
)
comparacion.orderBy("sensor", "hora").show()
print("Filas en las que difieren:", comparacion.filter(F.col("con_udf") != F.col("integrada")).count())

print("Spark", spark.version)
spark.stop()

Lo ejecuté el 14 de noviembre de 2026 con PySpark 4.3.0, Python 3.12.13 y Java 21, en un portátil con Windows. Esta fue la salida, sin los avisos de arranque ni las barras de progreso:

+-------------+-------------+--------------+
|         lote|humedad_media|humedad_minima|
+-------------+-------------+--------------+
|   Lote norte|         23.2|          22.4|
|Lote quebrada|         34.5|          33.3|
|     Lote sur|        11.95|          11.0|
+-------------+-------------+--------------+

+------+-----+-------+-------+---------+
|sensor| hora|humedad|con_udf|integrada|
+------+-----+-------+-------+---------+
|    S1|06:00|   31.5| normal|   normal|
|    S1|12:00|   24.0| normal|   normal|
|    S1|18:00|   22.4| normal|   normal|
|    S2|06:00|   18.2|   seco|     seco|
|    S2|12:00|   12.9|   seco|     seco|
|    S2|18:00|   11.0|   seco|     seco|
|    S3|06:00|   40.1| normal|   normal|
|    S3|12:00|   35.7| normal|   normal|
|    S3|18:00|   33.3| normal|   normal|
+------+-----+-------+-------+---------+

Filas en las que difieren: 0
Spark 4.3.0

El resumen solo usa las lecturas del mediodía y de la tarde, porque el filtro descarta las de la mañana. El lote norte, por ejemplo, promedia sus lecturas del mediodía y de la tarde y da 23,2. Las dos versiones de la regla clasifican igual las nueve lecturas.

De pandas a PySpark: la misma operación en las dos librerías

Quien viene de pandas, la librería de Python para tablas en la memoria de un computador, reconoce casi todas las operaciones. Los nombres cambian poco. Lo que cambia es cuándo se ejecutan y dónde quedan los datos.

OperaciónEn PySparkEn pandasNota
Crear una tablaspark.createDataFrame(filas, esquema)pd.DataFrame(datos)PySpark también acepta un DataFrame de pandas como entrada [5]
Leer un archivospark.read.csv(ruta) o spark.read.parquet(ruta)pd.read_csv(ruta) o pd.read_parquet(ruta)La guía de inicio muestra CSV, Parquet y ORC [5]
Elegir columnasdf.select(“a”, “b”)df[[“a”, “b”]]En PySpark, elegir una columna no dispara ningún cálculo [5]
Filtrar filasdf.filter(F.col(“x”) > 0) o df.where(…)df[df[“x”] > 0] o df.query(“x > 0”)Devuelve un DataFrame nuevo; el original no cambia [6]
Crear una columnadf.withColumn(“y”, expresión)df[“y”] = expresión o df.assign(y=…)En pandas la asignación cambia la tabla; en PySpark, no: es inmutable [6]
Agrupar y resumirdf.groupBy(“k”).agg(F.sum(“v”))df.groupby(“k”).agg({“v”: “sum”})PySpark agrupa con la estrategia de separar, aplicar y combinar [5]
Unir dos tablasdf.join(otra, on=”k”, how=”inner”)df.merge(otra, on=”k”, how=”inner”)La guía de PySpark nombra la unión entre sus operaciones básicas [6]; los tipos de unión se explican en joins de SQL
Ver el resultadodf.show() o df.collect()print(df) o df.head()collect trae todos los datos al computador que dirige el trabajo y puede agotar su memoria [5]
Pasar a la otra libreríadf.toPandas()spark.createDataFrame(pdf)toPandas también reúne todo en un solo computador [5]

Hay un atajo para quien no quiere aprender nombres nuevos: la interfaz de pandas sobre Spark. Llegó con la versión 3.2.0 de Spark, publicada el 13 de octubre de 2021, cuyas notas prometen escalar una aplicación de pandas «cambiando una línea de código» [15]. Se importa como «pyspark.pandas» y conserva la forma de escribir de pandas [2].

La documentación pone dos condiciones. La interfaz no busca ser 100 % compatible ni con pandas ni con PySpark, así que a veces hay que ajustar código [11]. Y su recomendación es clara: si usted ya sabe pandas, use esa interfaz; si aprende Spark desde cero, empiece por el DataFrame de PySpark [11].

Transformaciones y acciones en la API de PySpark

En PySpark los métodos se dividen en dos grupos, y saber cuál es cuál evita sorpresas. La guía de inicio lo explica así: cuando Spark transforma datos, no calcula de inmediato, sino que planea cómo hacerlo después [5]. El cálculo empieza cuando se llama una acción como collect [5]. Por qué Spark funciona así está en la guía de Apache Spark.

GrupoMétodos de uso diarioQué pasa al llamarlos
Transformacionesselect, filter, where, withColumn, join, groupBy con agg, orderByDevuelven un DataFrame nuevo y solo anotan el paso [5][6]
Accionesshow, collect, count, take, first, toPandasPiden un resultado y ponen a trabajar el motor [5][7]

La consecuencia práctica es un error frecuente de principiante: escribir diez transformaciones y creer que el programa ya hizo algo. No ha hecho nada todavía. Otro error es el opuesto: llamar collect o toPandas sobre una tabla enorme. La guía advierte que eso puede agotar la memoria, porque reúne todos los datos en un solo computador [5]. Para mirar unas pocas filas, sugiere take o tail [5].

¿Por qué una UDF de Python puede salir cara?

Una UDF, o función definida por el usuario, es una función de Python que usted escribe y aplica a una columna, como estado_udf en el ejemplo. Es útil cuando ninguna función de Spark hace lo que usted necesita. Pero tiene un costo, y su origen es la decisión de 2013 de usar el Python de siempre: los datos tienen que ir hasta un proceso de Python y volver.

Spark corre sobre la JVM, la máquina virtual de Java, el programa que ejecuta el código de Java. Su código de Python, en cambio, corre en procesos de Python aparte [8]. Para que una UDF trabaje, los datos tienen que serializarse, es decir, convertirse en bytes, pasar a Python y volver [8][10].

La documentación de PySpark distingue tres tipos de UDF [8]:

  1. UDF escalares de Python. Reciben y devuelven objetos de Python, una fila a la vez, y se serializan con pickle, el formato propio de Python para guardar objetos, o con Arrow [8].
  2. UDF de pandas, o vectorizadas. Reciben y devuelven series o tablas de pandas, por bloques, y se serializan con Apache Arrow [8]. Arrow es un formato estándar para guardar datos por columnas en memoria y pasarlos entre lenguajes [8].
  3. UDF de Arrow. Trabajan directamente con arreglos de Arrow [8].

Sobre las primeras, la guía es franca: las UDF escalares que dependen de pickle encuentran cuellos de botella de rendimiento, sobre todo con entradas y salidas de datos grandes [8]. Por eso existen las UDF optimizadas con Arrow, que según la guía evitan los métodos de serialización tradicionales, más lentos [8]. Desde la versión 4.2 de Spark, esa optimización viene activada por defecto para las UDF normales de Python [9].

Hay un detalle que vi en mi propia corrida. Con la instalación básica, sin pandas ni PyArrow, PySpark avisó que no pudo activar la optimización de Arrow y que usaba la UDF sin ella. El resultado fue correcto, como muestra la tabla de arriba. Pero el camino fue el antiguo.

¿Entonces cuándo usar una UDF? La documentación de Databricks, una plataforma comercial construida sobre Spark, lo resume así: las funciones integradas de Spark están optimizadas para el cálculo distribuido y rinden mejor a escala [10]. Reserva las UDF para la lógica difícil de expresar con esas funciones [10]. Scala es otro lenguaje que corre sobre la plataforma de Java. Según la misma documentación, las UDF de Python y de pandas tienden a ser más lentas que las de Scala, porque deben serializar los datos y sacarlos de la JVM [10].

La regla del ejemplo cabía en una función integrada, F.when, y dio lo mismo que la UDF. No medí tiempos para sacar una regla: en nueve filas, cualquier diferencia diría más del arranque del programa que del método. De lo que dicen las dos fuentes se desprende un orden de preferencia. Primero, una función integrada. Si no existe, una UDF de pandas o con Arrow. Y al final, la UDF fila por fila sin optimizar.

pandas, Polars, Dask o PySpark: cuál usar según el tamaño de los datos

No hay un número mágico de gigas que diga cuándo cambiar de herramienta. Cada documentación habla de su propio alcance y ofrece criterios, y con ellos se arma esta tabla.

HerramientaDónde correQué hace cuando los datos no caben en memoriaCuándo la sugiere su propia documentación
pandasUn computador, con los datos en memoria [12]Le resulta «algo complicado»; propone cargar menos columnas, usar tipos más livianos, procesar por partes u otras librerías [12]Cuando la tabla cabe con holgura; hasta una tabla que ocupa buena parte de la memoria se vuelve difícil de manejar [12]
PolarsUn computador, usando todos sus núcleos [13]Tiene un modo de procesamiento por flujo que no exige tener todos los datos en memoria a la vez [13]Tablas grandes en una sola máquina; su meta declarada incluye datos mucho más grandes que la memoria disponible [13]
DaskUn portátil o un clúster de computadores [14]Reparte el trabajo entre muchos DataFrames de pandas, que pueden vivir en disco o en otras máquinas [14]Suele usarse cuando los datos son demasiado grandes o el cálculo demasiado lento y otras técnicas no funcionan; si son pequeños, probablemente convenga quedarse con pandas [14]
PySparkUn computador en modo local o un clúster [2][4]Reparte el cálculo en el motor de Spark, entre núcleos o entre máquinas [2]Procesar datos a gran escala en un entorno distribuido [2]; la interfaz de pandas sobre Spark permite llevar código de pandas a varias máquinas [2]

Una sola cifra aparece en estas fuentes, y viene con su alcance. La documentación de Dask afirma que funciona con 100 GiB en un portátil o con 100 TiB en un clúster [14]. Es lo que el proyecto dice de sí mismo, no un umbral para elegir.

Las cuatro herramientas no compiten en el mismo terreno. El uso diario de pandas, NumPy y Dask como librerías está en la guía de Python para análisis de datos. Lo propio de PySpark es el último paso: cuando el problema ya no es de un computador, sino de varios.

Para un analista en Colombia, el punto de partida tiene costo cero de licencia: PySpark es gratuito y corre en modo local en el mismo portátil [3][4]; pandas también es software libre. El costo aparece después, si hay que alquilar un clúster. Por eso conviene agotar antes las salidas baratas que propone la guía de pandas, como cargar menos columnas o procesar por partes [12]. Los modelos que se entrenan con MLlib, la biblioteca de aprendizaje automático de Spark, son tema de machine learning. El panorama de por qué los datos llegan a ese tamaño está en la guía de big data.

Cómo sacarle partido a PySpark sin pagar el peaje de Python

Voy a decirlo como lo veo, y es una opinión. El mayor error con PySpark no es instalarlo mal. Es usarlo como si fuera pandas con otro nombre: llenarlo de UDF fila por fila, pedir toPandas a cada rato y sorprenderse de que vaya lento.

PySpark rinde cuando usted le deja el trabajo al motor. Eso significa escribir con las funciones integradas, encadenar transformaciones y pedir resultados solo al final. Escribir en el Python de siempre, la decisión de 2013, fue una comodidad con peaje: cada dato que toca una UDF tiene que salir del motor y volver.

Si sus datos todavía caben en su computador, quédese en pandas sin culpa. Y el día que no quepan, aprenda primero qué funciones trae Spark antes de escribir la suya.

Preguntas frecuentes

¿PySpark es gratis? Sí. El paquete se distribuye en PyPI con la licencia Apache 2.0 y se instala sin pagar [3]. Lo que puede costar es la infraestructura: si los datos exigen un clúster, hay que montarlo o alquilarlo en la nube.

¿Necesito saber Java o Scala para usar PySpark? No para escribir el código, que va todo en Python. Pero Java tiene que estar instalado: la versión 4.3.0 pide Java 17 o posterior, con la variable JAVA_HOME configurada [4]. Spark corre sobre la máquina virtual de Java y PySpark se comunica con ella mediante py4j [4].

¿Qué versión de Python pide PySpark? La documentación de instalación de la versión 4.3.0 pide Python 3.11 o posterior [4]. PyPI registra el mismo requisito para el paquete [3]. Si tiene una versión anterior de Python, la instalación con pip no ofrecerá esta versión de PySpark.

¿Puedo usar PySpark en un computador sin clúster? Sí. La instalación con pip está pensada, entre otras cosas, para el uso local [4]. En modo local, Spark usa los núcleos de su propio equipo como si fueran varias máquinas, y el mismo código sirve después en un clúster.

¿Es mejor la API de pandas sobre Spark o el DataFrame de PySpark? Depende de dónde venga usted. La documentación recomienda la interfaz de pandas sobre Spark a quien ya domina pandas. Y el DataFrame de PySpark a quien aprende Spark desde el principio [11]. También advierte que la primera no es 100 % compatible con pandas [11].

Referencias

  1. The Apache Software Foundation. Spark Release 0.7.0 y Spark 0.7.0 released — anuncio del 27 de febrero de 2013 (archivo de noticias); «Most notable are a Python API for Spark»; 31 contribuyentes, 20 de ellos externos a Berkeley; PySpark usa el intérprete estándar CPython y puede llamar a NumPy y SciPy; «PySpark will automatically ship functions from your main program, along with the variables they depend on, to the cluster»; Josh Rosen, «Python API (lead developer)». Apache Spark: notas de la versión 0.7.0 · Apache Spark: archivo de noticias — Consultada: 2026-11-14.
  2. The Apache Software Foundation. PySpark Overview, documentación de PySpark 4.3.0 — «PySpark is the Python API for Apache Spark»; procesamiento a gran escala en un entorno distribuido; consola interactiva; soporta Spark SQL, DataFrames, Structured Streaming, MLlib, Pipelines y Spark Core; con Python o SQL se usa el mismo motor de ejecución; la interfaz de pandas sobre Spark permite escalar cargas de pandas ejecutándolas en varios nodos. Apache Spark: PySpark Overview — Consultada: 2026-11-14.
  3. Python Package Index. pyspark — versión 4.3.0 subida el 30 de octubre de 2026; licencia Apache-2.0; requiere Python 3.11 o posterior. PyPI: pyspark — Consultada: 2026-11-14.
  4. The Apache Software Foundation. Installation, documentación de PySpark 4.3.0 — Python 3.11 y posteriores; «pip install pyspark», usual para uso local o como cliente de un clúster; extras sql, pandas_on_spark y connect; entorno con venv; distribución por defecto con Hadoop 3.5; py4j requerido para interactuar con la JVM; pandas >=2.2.0,<3.0.0 y pyarrow >=18.0.0 para Spark SQL y la interfaz de pandas sobre Spark; «PySpark requires Java 17 or later with JAVA_HOME properly set». Apache Spark: PySpark Installation — Consultada: 2026-11-14.
  5. The Apache Software Foundation. Quickstart: DataFrame, documentación de PySpark 4.3.0 — los DataFrames se evalúan de forma perezosa; Spark planea la transformación y calcula cuando se llama una acción como collect(); SparkSession como punto de entrada y variable spark en la consola; creación desde listas, filas, DataFrame de pandas o RDD; collect() y toPandas() reúnen los datos en el driver y pueden causar errores de memoria; take() y tail() para evitarlo; seleccionar una columna no dispara el cálculo; agrupación con la estrategia separar-aplicar-combinar; lectura de CSV, Parquet y ORC. Apache Spark: Quickstart DataFrame — Consultada: 2026-11-14.
  6. The Apache Software Foundation. Chapter 1: DataFrames – A view into your structured data, guía de usuario de PySpark 4.3.0 — estructura de datos de dos dimensiones con columnas de tipos posiblemente distintos, comparable a una hoja de cálculo o una tabla SQL; operaciones para seleccionar columnas, filtrar, unir y agregar; «A DataFrame is an immutable distributed collection of data, only available in the current Spark session». Apache Spark: PySpark DataFrames — Consultada: 2026-11-14.
  7. The Apache Software Foundation. RDD Programming Guide, documentación de Apache Spark 4.3.0 — tabla de acciones comunes: reduce, collect, count, first, take, entre otras. Apache Spark: RDD Programming Guide — Consultada: 2026-11-14.
  8. The Apache Software Foundation. Chapter 5: Unleashing UDFs & UDTFs, guía de usuario de PySpark 4.3.0 — tres categorías: UDF escalares de Python (pickle o Arrow, fila a fila), UDF de pandas o vectorizadas (Arrow, por bloques) y UDF de Arrow; las UDF escalares con cloudpickle «encounter performance bottlenecks, particularly when dealing with large data inputs and outputs»; Arrow como representación en memoria por columnas, estándar entre lenguajes, para el intercambio entre los procesos de la JVM y de Python. Apache Spark: PySpark UDFs and UDTFs — Consultada: 2026-11-14.
  9. The Apache Software Foundation. Apache Arrow in PySpark, documentación de PySpark 4.3.0 — «Since Spark 4.2, Arrow optimization is enabled by default for regular Python UDFs»; se desactiva con spark.sql.execution.pythonUDF.arrow.enabled en false. Apache Spark: Arrow in PySpark — Consultada: 2026-11-14.
  10. Databricks. User-defined functions (UDFs) (última actualización: 11 de noviembre de 2026) — usar UDF para lógica difícil de expresar con funciones integradas; «Built-in Apache Spark functions are optimized for distributed processing and offer better performance at scale»; las UDF de Python y de pandas tienden a ser más lentas que las de Scala porque deben serializar los datos y sacarlos de la JVM hacia el intérprete de Python. Databricks: User-defined functions — Consultada: 2026-11-14.
  11. The Apache Software Foundation. FAQ y From/to pandas and PySpark DataFrames, interfaz de pandas sobre Spark, documentación de PySpark 4.3.0 — recomienda la interfaz de pandas sobre Spark a quien ya conoce pandas y el API de PySpark a quien aprende Spark desde cero; la interfaz no busca 100 % de compatibilidad con pandas ni con PySpark. Apache Spark: FAQ de pandas sobre Spark · Apache Spark: From/to pandas and PySpark — Consultada: 2026-11-14.
  12. pandas development team. Scaling to large datasets, documentación de pandas 3.1.1 — estructuras para análisis en memoria, lo que hace «somewhat tricky» analizar datos más grandes que la memoria; incluso datos que ocupan una fracción considerable de la memoria se vuelven difíciles de manejar; recomendaciones: cargar menos datos, tipos eficientes, procesar por fragmentos y usar otras librerías. pandas: Scaling to large datasets — Consultada: 2026-11-14.
  13. Polars. Polars user guide — biblioteca de DataFrames con núcleo escrito en Rust; usa todos los núcleos disponibles de la máquina; la API de streaming procesa sin exigir todos los datos en memoria a la vez; entre sus metas, manejar conjuntos de datos mucho más grandes que la memoria disponible. Polars: user guide — Consultada: 2026-11-14.
  14. Dask. Dask DataFrame — procesa datos tabulares grandes paralelizando pandas, en un portátil o en un clúster; «Works on 100 GiB on a laptop, or 100 TiB on a cluster»; colección de muchos DataFrames de pandas que pueden vivir en disco o en otras máquinas; usar Dask si los datos son demasiado grandes o el cálculo demasiado lento, quedarse con pandas si los datos son pequeños. Dask: DataFrame — Consultada: 2026-11-14.
  15. The Apache Software Foundation. Spark Release 3.2.0 y Spark 3.2.0 released — anuncio del 13 de octubre de 2021; «Spark supports the Pandas API layer on Spark. Pandas users can scale out their applications on Spark with one line code change». Apache Spark: notas de la versión 3.2.0 · Apache Spark: archivo de noticias — Consultada: 2026-11-14.
Cómo investigamos esta página
  • Pregunta que responde: Qué es PySpark, cómo se instala y se usa desde Python, cuánto cuestan sus funciones propias y cuándo conviene frente a pandas, Polars y Dask.
  • Fuentes: identificadas 34 → incluidas 15
  • Criterios de inclusión: documentación oficial de PySpark 4.3.0, pandas, Polars, Dask y Databricks, más el registro PyPI; sin blogs, cursos ni cifras de velocidad publicitarias.
  • Fecha de corte de los datos: 2026-11-14
Scroll to Top