Capítulo 1. Analizar los Big Data

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Cuando la gente dice que vivimos en la era de los grandes datos, se refiere a que disponemos de herramientas para recopilar, almacenar y procesar información a una escala hasta ahora desconocida. Las siguientes tareas sencillamente no podrían haberse realizado hace 10 ó 15 años:

Construye un modelo para detectar el fraude con tarjetas de crédito utilizando miles de características y miles de millones de transacciones
Recomienda de forma inteligente millones de productos a millones de usuarios
Estimar el riesgo financiero mediante simulaciones de carteras que incluyen millones de instrumentos
Manipula fácilmente datos genómicos de miles de personas para detectar asociaciones genéticas con enfermedades
Evaluar el uso del suelo agrícola y el rendimiento de los cultivos para mejorar la elaboración de políticas mediante el procesamiento periódico de millones de imágenes de satélite.

Detrás de estas capacidades hay un ecosistema de software de código abierto que puede aprovechar grupos de servidores para procesar cantidades masivas de datos. La introducción/lanzamiento de Apache Hadoop en 2006 ha llevado a la adopción generalizada de la informática distribuida. El ecosistema y las herramientas de big data han evolucionado a gran velocidad desde entonces. En los últimos cinco años también se han introducido y adoptado muchas bibliotecas de aprendizaje automático (ML) y aprendizaje profundo de código abierto. Estas herramientas pretenden aprovechar las enormes cantidades de datos que ahora recopilamos y almacenamos.

Pero al igual que un cincel y un bloque de piedra no hacen una estatua, hay un abismo entre tener acceso a estas herramientas y a todos estos datos y hacer algo útil con ellos. A menudo, "hacer algo útil" significa colocar un esquema sobre los datos tabulares y utilizar SQL para responder a preguntas como "De los billones de usuarios que llegaron a la tercera página en nuestro proceso de registro, ¿cuántos tienen más de 25 años?". El campo de cómo diseñar el almacenamiento de datos y organizar la información (almacenes de datos, lagos de datos, etc.) para facilitar la respuesta a estas preguntas es muy rico, pero en este libro evitaremos sus complejidades.

A veces, "hacer algo útil" requiere un poco de trabajo extra. SQL puede seguir siendo el núcleo del enfoque, pero para trabajar en torno a las idiosincrasias de los datos o realizar análisis complejos, necesitamos un paradigma de programación que sea más flexible y con una funcionalidad más rica en áreas como el aprendizaje automático y la estadística. Aquí es donde entra en juego la ciencia de datos y de eso es de lo que vamos a hablar en este libro.

En este capítulo, empezaremos introduciendo el concepto de big data y discutiremos algunos de los retos que surgen al trabajar con grandes conjuntos de datos. A continuación, presentaremos Apache Spark, un marco de código abierto para la computación distribuida, y sus componentes clave. Nos centraremos en PySpark, la API Python de Spark, y en cómo encaja en un ecosistema más amplio. A continuación hablaremos de los cambios introducidos por Spark 3.0, la primera versión importante del marco en cuatro años. Terminaremos con una breve nota sobre cómo PySpark aborda los retos de la ciencia de datos y por qué es una gran adición a tu conjunto de habilidades.

Las ediciones anteriores de este libro utilizaban la API Scala de Spark de para los ejemplos de código. Decidimos utilizar PySpark en su lugar debido a la popularidad de Python en la comunidad de la ciencia de datos y a una mayor atención por parte del equipo central de Spark para dar un mejor soporte al lenguaje. Al final de este capítulo, apreciarás idealmente esta decisión.

Trabajar con Big Data

Muchas de nuestras herramientas favoritas de small data chocan contra un muro cuando trabajan con big data. Bibliotecas como pandas no están equipadas para tratar con datos que no caben en nuestra memoria RAM. Entonces, ¿cómo debería ser un proceso equivalente que pueda aprovechar los clusters de ordenadores para conseguir los mismos resultados en grandes conjuntos de datos? Los retos de la informática distribuida nos obligan a replantearnos muchos de los supuestos básicos en los que confiamos en los sistemas de un solo nodo. Por ejemplo, como los datos deben repartirse entre muchos nodos de un clúster, los algoritmos que tienen amplias dependencias de datos sufrirán por el hecho de que las velocidades de transferencia de la red son órdenes de magnitud más lentas que los accesos a la memoria. A medida que aumenta el número de máquinas que trabajan en un problema, aumenta la probabilidad de que se produzca un fallo. Estos hechos requieren un paradigma de programación que sea sensible a las características del sistema subyacente: uno que desaliente las malas elecciones y facilite la escritura de código que se ejecute de forma altamente paralela.

¿Cómo de grande es el Big Data?

Sin un punto de referencia, el término big data es ambiguo. Además, la antigua definición en dos niveles de pequeños y grandes datos puede resultar confusa. Cuando se trata del tamaño de los datos, es más útil una definición de tres niveles (ver Tabla 1-1).

Tabla 1-1. Una definición escalonada del tamaño de los datos
Tipo de conjunto de datos	¿Cabe en la RAM?	¿Cabe en el disco local?
Pequeño conjunto de datos	Sí	Sí
Conjunto de datos medio	No	Sí
Gran conjunto de datos	No	No

Según la tabla, si el conjunto de datos puede caber en la memoria o el disco de un solo sistema, no puede denominarse big data. Esta definición no es perfecta, pero actúa como una buena regla general en el contexto de una máquina media.

El objetivo de este libro es que puedas trabajar eficazmente con big data. Si tu conjunto de datos es pequeño y cabe en la memoria, aléjate de los sistemas distribuidos. Para analizar conjuntos de datos de tamaño medio, una base de datos o el paralelismo pueden ser suficientes en ocasiones. En otras ocasiones, puede que tengas que montar un clúster y utilizar herramientas de big data. Esperemos que la experiencia que adquirirás en los capítulos siguientes te ayude a tomar esas decisiones.

Las herramientas monomáquina que han cobrado importancia recientemente en la comunidad del software no son las únicas que se utilizan para el análisis de datos. Los campos científicos como la genómica, que trabajan con grandes conjuntos de datos, llevan décadas aprovechando los marcos de la informática paralela. Hoy en día, la mayoría de las personas que procesan datos en estos campos están familiarizadas con un entorno de computación en clúster denominado HPC (computación de alto rendimiento). Mientras que las dificultades con Python y R residen en su incapacidad para escalar, las dificultades con HPC residen en su relativamente bajo nivel de abstracción y dificultad de uso. Por ejemplo, para procesar en paralelo un gran archivo lleno de lecturas de secuenciación de ADN, debemos dividirlo manualmente en archivos más pequeños y enviar un trabajo para cada uno de esos archivos al programador del clúster. Si algunos de ellos fallan, el usuario debe detectar el fallo y volver a enviarlos manualmente. Si el análisis requiere operaciones de todos contra todos, como ordenar todo el conjunto de datos, el gran conjunto de datos debe transmitirse a través de un único nodo, o el científico debe recurrir a marcos distribuidos de nivel inferior como MPI, que son difíciles de programar sin amplios conocimientos de C y de sistemas distribuidos/en red.

Las herramientas escritas para entornos HPC no suelen desacoplar los modelos de datos en memoria de los modelos de almacenamiento de nivel inferior. Por ejemplo, muchas herramientas sólo saben leer datos de un sistema de archivos POSIX en un único flujo, lo que dificulta la paralelización natural de las herramientas o el uso de otros backends de almacenamiento, como las bases de datos. Los modernos marcos de computación distribuida proporcionan abstracciones que permiten a los usuarios tratar un clúster de ordenadores más como un único ordenador: dividir automáticamente los archivos y distribuir el almacenamiento entre muchas máquinas, dividir el trabajo en tareas más pequeñas y ejecutarlas de forma distribuida, y recuperarse de los fallos. Pueden automatizar muchas de las molestias de trabajar con grandes conjuntos de datos y son mucho más baratas que la HPC.

Una forma sencilla de pensar en los sistemas distribuidos es que son un grupo de ordenadores independientes que al usuario final le parecen un único ordenador. Permiten el escalado horizontal. Esto significa añadir más ordenadores en lugar de actualizar un único sistema (escalado vertical). Esto último es relativamente caro y a menudo insuficiente para grandes cargas de trabajo. Los sistemas distribuidos son estupendos para el escalado y la fiabilidad, pero también introducen complejidad a la hora del diseño, la construcción y la depuración. Hay que entender esta compensación antes de optar por una herramienta de este tipo.

Presentación de Apache Spark y PySpark

Entra en Apache Spark, un marco de código abierto que combina un motor para distribuir programas a través de clusters de máquinas con un elegante modelo para escribir programas sobre él. Spark se originó en el AMPLab de la Universidad de California, Berkeley, y desde entonces ha contribuido a la Apache Software Foundation. Cuando se lanzó, fue posiblemente el primer software de código abierto que hizo la programación distribuida realmente accesible a los científicos de datos.

Componentes

Aparte del motor de cálculo central (Spark Core), Spark consta de cuatro componentes principales. El código Spark escrito por un usuario, utilizando cualquiera de sus APIs, se ejecuta en las JVMs (Máquinas Virtuales Java) de los trabajadores a través del clúster (ver Capítulo 2). Estos componentes están disponibles como bibliotecas distintas, como se muestra en la Figura 1-1:

Spark SQL y DataFrames + Conjuntos de datos: Un módulo para trabajar con datos estructurados.
MLlib: Una biblioteca de aprendizaje automático escalable.
Streaming estructurado: Esto hace que sea fácil construir aplicaciones de streaming escalables y tolerantes a fallos.

GraphX (heredado): GraphX es la biblioteca de Apache Spark para grafos y computación paralela a grafos. Sin embargo, para el análisis de grafos, se recomienda GraphFrames en lugar de GraphX, que no se está desarrollando tan activamente y carece de enlaces a Python. GraphFrames es una biblioteca general de procesamiento de grafos de código abierto similar a GraphX de Apache Spark, pero que utiliza API basadas en DataFrame.

Comparación con MapReduce

Una forma esclarecedora de entender Spark es en términos de sus avances sobre su predecesor, MapReduce de Apache Hadoop. MapReduce revolucionó la computación sobre enormes conjuntos de datos al ofrecer un modelo sencillo y resistente para escribir programas que pudieran ejecutarse en paralelo en cientos o miles de máquinas. Dividía el trabajo en pequeñas tareas y podía acomodar con gracia los fallos de las tareas sin comprometer el trabajo al que pertenecían.

Spark mantiene la escalabilidad lineal y la tolerancia a fallos de MapReduce , pero la amplía de tres formas importantes:

En primer lugar, en lugar de basarse en un formato rígido de map-then-reduce, su motor puede ejecutar un grafo acíclico dirigido más general de operadores. Esto significa que en situaciones en las que MapReduce debe escribir resultados intermedios en el sistema de archivos distribuido, Spark puede pasarlos directamente al siguiente paso de la cadena.
En segundo lugar, complementa su capacidad de cálculo con un rico conjunto de transformaciones que permiten a los usuarios expresar el cálculo de forma más natural. Se proporcionan funciones listas para usar para diversas tareas, como el cálculo numérico, el procesamiento de fechas y horas y la manipulación de cadenas.
En tercer lugar, Spark amplía a sus predecesores con el procesamiento en memoria. Esto significa que los pasos futuros que quieran tratar con el mismo conjunto de datos no necesitan volver a calcularlo o recargarlo del disco. Spark es muy adecuado para algoritmos altamente iterativos, así como para consultas ad hoc.

PySpark

PySpark es la API Python de Spark. En palabras más sencillas, PySpark es una envoltura basada en Python sobre el marco central de Spark, que está escrito principalmente en Scala. PySpark proporciona un entorno de programación intuitivo para los profesionales de la ciencia de datos y ofrece la flexibilidad de Python con las capacidades de procesamiento distribuido de Spark.

PySpark nos permite trabajar a través de modelos de programación. Por ejemplo, un patrón común es realizar cargas de trabajo de extracción, transformación y carga (ETL) a gran escala con Spark y, a continuación, recoger los resultados en una máquina local y manipularlos con pandas. Exploraremos tales modelos de programación mientras escribimos código PySpark en los próximos capítulos. Aquí tienes un ejemplo de código de la documentación oficial para que te hagas una idea de lo que está por venir:

from pyspark.ml.classification import LogisticRegression

# Load training data
training = spark.read.format("libsvm").load("data/mllib/sample_libsvm_data.txt")

lr = LogisticRegression(maxIter=10, regParam=0.3, elasticNetParam=0.8)

# Fit the model
lrModel = lr.fit(training)

# Print the coefficients and intercept for logistic regression
print("Coefficients: " + str(lrModel.coefficients))
print("Intercept: " + str(lrModel.intercept))

# We can also use the multinomial family for binary classification
mlr = LogisticRegression(maxIter=10, regParam=0.3, elasticNetParam=0.8,
                         family="multinomial")

# Fit the model
mlrModel = mlr.fit(training)

# Print the coefficients and intercepts for logistic regression
# with multinomial family
print("Multinomial coefficients: " + str(mlrModel.coefficientMatrix))
print("Multinomial intercepts: " + str(mlrModel.interceptVector))

Ecosistema

Spark es lo más parecido a una navaja suiza que tenemos en el ecosistema de los grandes datos. Por si fuera poco, se integra bien con el resto del ecosistema y es extensible. Spark desacopla el almacenamiento y el cálculo, a diferencia de Apache Hadoop y los sistemas HPC descritos anteriormente. Eso significa que podemos utilizar Spark para leer datos almacenados en muchas fuentes -Apache Hadoop, Apache Cassandra, Apache HBase, MongoDB, Apache Hive, RDBMS y más- y procesarlos todos en memoria. Las API DataFrameReader y DataFrameWriter de Spark también pueden ampliarse para leer datos de otras fuentes, como Apache Kafka, Amazon Kinesis, Azure Storage y Amazon S3, sobre las que puede operar. También admite múltiples modos de implementación, desde entornos locales hasta clústeres de Apache YARN y Kubernetes.

También existe una amplia comunidad a su alrededor. Esto ha llevado a la creación de muchos paquetes de terceros. Puedes encontrar una lista de estos paquetes creada por la comunidad aquí. Los principales proveedores de la nube(AWS EMR, Azure Databricks, GCP Dataproc) también ofrecen opciones de terceros para ejecutar cargas de trabajo Spark gestionadas. Además, hay conferencias dedicadas y grupos de encuentro locales que pueden ser interesantes para conocer aplicaciones interesantes y buenas prácticas.

Spark 3.0

En 2020, Apache Spark publicó en su primera versión importante desde 2016, cuando se publicó Spark 2.0: Spark 3.0. La última edición de esta serie, publicada en 2017, cubría los cambios introducidos por Spark 2.0. Spark 3.0 no introduce tantos cambios importantes en la API como la última versión importante. Esta versión se centra en mejorar el rendimiento y la usabilidad sin introducir incompatibilidades retroactivas significativas.

El módulo SQL de Spark ha visto en importantes mejoras de rendimiento en forma de ejecución adaptativa de consultas y poda dinámica de particiones. En términos más sencillos, permiten a Spark adaptar un plan de ejecución físico durante el tiempo de ejecución y omitir datos que no son necesarios en los resultados de una consulta, respectivamente. Estas optimizaciones abordan el importante esfuerzo que los usuarios tenían que dedicar anteriormente al ajuste y la optimización manuales. Spark 3.0 es casi dos veces más rápido que Spark 2.4 en TPC-DS, una referencia de procesamiento analítico estándar del sector. Dado que la mayoría de las aplicaciones Spark están respaldadas por el motor SQL, se han beneficiado todas las bibliotecas de nivel superior, como MLlib y el streaming estructurado, y las API de nivel superior, como SQL y DataFrames. El cumplimiento de la norma ANSI SQL hace que la API SQL sea más utilizable.

Python se ha convertido en el líder en términos de adopción en el ecosistema de la ciencia de datos. En consecuencia, Python es ahora el lenguaje más utilizado en Spark. PySpark tiene más de cinco millones de descargas mensuales en PyPI, el Índice de Paquetes de Python. Spark 3.0 mejora sus funcionalidades y usabilidad. Se han rediseñado las funciones definidas por el usuario (UDF) de pandas para que admitan sugerencias de tipos de Python e iteradores como argumentos. Se han incluido nuevos tipos de UDF de pandas, y el tratamiento de errores es ahora más pitónico. Las versiones de Python inferiores a la 3.6 han quedado obsoletas. A partir de Spark 3.2, el soporte de Python 3.6 también ha quedado obsoleto.

En los últimos cuatro años, el ecosistema de la ciencia de datos también ha cambiado a gran velocidad. Cada vez se presta más atención a la puesta en producción de modelos de aprendizaje automático. El aprendizaje profundo ha proporcionado resultados notables y el equipo de Spark está experimentando actualmente para permitir que el programador del proyecto aproveche aceleradores como las GPU.

PySpark aborda los retos de la ciencia de datos

Para que un sistema que pretenda hacer posible el análisis complejo de grandes datos en tenga éxito, debe estar informado por -o al menos no entrar en conflicto con- algunos retos fundamentales a los que se enfrentan los científicos de datos.

En primer lugar, la inmensa mayoría del trabajo que conlleva la realización de análisis satisfactorios reside en el preprocesamiento de los datos. Los datos son desordenados, y limpiarlos, triturarlos, fundirlos, mezclarlos y muchos otros verbos son requisitos previos para hacer algo útil con ellos.
En segundo lugar, la iteración es una parte fundamental de la ciencia de datos. El modelado y el análisis suelen requerir múltiples pasadas sobre los mismos datos.Los procedimientos de optimización más populares, como el descenso de gradiente estocástico, implican repetidas exploraciones sobre sus entradas para alcanzar la convergencia. La iteración también es importante dentro del propio flujo de trabajo del científico de datos. Elegir las características correctas, seleccionar los algoritmos adecuados, ejecutar las pruebas de significación correctas y encontrar los hiperparámetros adecuados requiereexperimentación.
En tercer lugar, la tarea no termina cuando se ha construido un modelo de buen rendimiento. El objetivo de la ciencia de datos es hacer que los datos sean útiles para los no científicos de datos. Los usos de los motores de recomendación de datos y los sistemas de detección de fraudes en tiempo real culminan en las aplicaciones de datos. En estos sistemas, los modelos pasan a formar parte de un servicio de producción y puede ser necesario reconstruirlos periódicamente o incluso en tiempo real.

PySpark aborda bien los retos antes mencionados de la ciencia de datos, reconociendo que el mayor cuello de botella en la creación de aplicaciones de datos no es la CPU, el disco o la red, sino la productividad del analista. Colapsar todo el proceso, desde el preprocesamiento hasta la evaluación del modelo, en un único entorno de programación puede acelerar el desarrollo. Al empaquetar un modelo de programación expresivo con un conjunto de bibliotecas analíticas en un entorno REPL (bucle de lectura-evaluación-impresión), PySpark evita las idas y vueltas a los IDE. Cuanto más rápido puedan experimentar los analistas con sus datos, más probabilidades tendrán de hacer algo útil con ellos.

Un bucle de lectura-evaluación-impresión, o REPL, es un entorno informático en el que se leen y evalúan las entradas del usuario, y luego se le devuelven los resultados.

Las API centrales de PySpark proporcionan una base sólida para la transformación de datos, independientemente de cualquier funcionalidad en estadística, aprendizaje automático o álgebra matricial. Al explorar y hacerse una idea de un conjunto de datos, los científicos de datos pueden mantener los datos en memoria mientras ejecutan consultas, y almacenar fácilmente en caché las versiones transformadas de los datos, sin sufrir un viaje al disco. Como marco que facilita el modelado, pero que también se adapta bien a los sistemas de producción, es una gran victoria para el ecosistema de la ciencia de datos.

¿Adónde vamos ahora?

Spark cubre la brecha entre los sistemas diseñados para el análisis exploratorio y los sistemas diseñados para el análisis operativo. A menudo se dice que un científico de datos es alguien que es mejor en ingeniería que la mayoría de los estadísticos y mejor en estadística que la mayoría de los ingenieros. Como mínimo, Spark es mejor como sistema operativo que la mayoría de los sistemas exploratorios y mejor para la exploración de datos que las tecnologías utilizadas habitualmente en los sistemas operativos. Esperamos que este capítulo te haya sido útil y que ahora estés deseando ponerte manos a la obra con PySpark. ¡Eso es lo que haremos a partir del próximo capítulo!

Get Analítica avanzada con PySpark now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial