Guía Copa Mundial (PySpark)
Análisis de datos de la Copa Mundial con PySpark: DataFrames, RDDs y Spark SQL en un pipeline único.
01 Problema y contexto
El procesamiento distribuido cambia la forma de escribir un análisis: las operaciones se planifican y se reparten entre particiones antes de ejecutarse, y decisiones como el orden de un join o el número de particiones pesan más que la consulta en sí. Hacía falta un banco de pruebas con suficientes entidades enlazadas para ejercitar eso de verdad.
El procesamiento distribuido cambia la forma de escribir un análisis: las operaciones se planifican y se reparten entre particiones antes de ejecutarse, y decisiones como el orden de un join o el número de particiones pesan más que la consulta en sí. Este trabajo usa un modelo relacional de competencias deportivas como banco de pruebas para ejercitar las tres APIs de Apache Spark sobre un mismo conjunto: RDDs, DataFrames y Spark SQL. El objeto de estudio es el pipeline y el comportamiento de cada API, no las conclusiones deportivas.
02 Solución
Un modelo relacional de cinco fuentes en dos formatos (cuatro CSV y un JSON multilínea) enlazadas por claves foráneas, sobre el que se ejercitan las tres APIs de Spark: RDDs, DataFrames y Spark SQL. Casteo explícito de tipos en vez de inferencia automática, control manual del particionamiento para observar su efecto en el plan de ejecución, y diez agregaciones contrastando la versión declarativa contra su equivalente en DataFrames.
- Modelado relacional de cinco fuentes en dos formatos: cuatro CSV y un JSON multilínea, enlazados por claves foráneas.
- Ingesta y saneamiento: normalización de cabeceras y casteo explícito de tipos, en lugar de confiar en la inferencia automática de esquema.
- Integración: joins entre las cinco entidades resolviendo la ambigüedad de columnas homónimas, y lectura del JSON anidado con multiline activado.
- Control explícito del particionamiento para ejercitar el paralelismo y observar el efecto sobre el plan de ejecución.
- Columnas derivadas mediante reglas condicionales.
- Diez agregaciones analíticas en Spark SQL sobre vistas temporales, contrastando la versión declarativa con su equivalente en DataFrames.
- Ajuste del entorno para que el pipeline corriera de extremo a extremo en instalación local, reescribiendo las operaciones de RDD que fallaban por serialización.
03 Resultados
Cifras verificables en el repositorio y su documentación:
04 Cómo está construido
Proyecto de Big Data sobre la Copa Mundial de la FIFA con Apache Spark (PySpark). Integra cinco fuentes de datos (equipos, estadios, jugadores, partidos en CSV y torneos en JSON multilínea) en un modelo relacional, y ejercita las tres APIs principales de Spark: RDDs, DataFrames y Spark SQL. El notebook cubre desde la limpieza de datos hasta joins, reparticionamiento, columnas calculadas con reglas de negocio y diez agregaciones analíticas en SQL declarativo.
05 Decisiones éticas
- Los datos de jugadores son sintéticos, con nombres, edades y medidas generados para el ejercicio. Se evitó manipular datos biométricos de personas reales en una tarea que no lo necesitaba.
- Las etiquetas derivadas del índice de masa corporal se calculan sobre perfiles ficticios y no constituyen valoración sobre personas reales.
06 Aspectos destacados
- Pipeline completo en PySpark que integra cinco fuentes de datos bajo un modelo relacional con claves foráneas.
- Diez agregaciones analíticas en Spark SQL sobre vistas temporales, además de joins con resolución de ambigüedad de columnas.
- Columnas calculadas con reglas de negocio (IMC de jugadores, etiquetas por edad y puntaje).
- Control explícito de particionamiento para ejercitar paralelismo en RDDs y DataFrames.
07 Limitaciones
El conjunto es sintético y pequeño: quince selecciones, ochenta jugadores, cien partidos, diez estadios y tres torneos, con rankings y resultados generados. De ahí se siguen dos límites que conviene declarar antes que los declare otro. Ninguna conclusión deportiva describe competencias reales; son consultas correctas sobre datos inventados. Y a este volumen Spark no aporta ventaja de rendimiento, porque el sobrecosto de coordinación domina sobre el cómputo, de modo que el particionamiento se ejercita como mecánica del motor y no como optimización medida.