Análisis de macrodatos en servidores bare metal

Ejecutar Hadoop o Spark en una infraestructura en la nube tiene sentido cuando se están creando prototipos. Cuando se procesan terabytes de datos de producción a diario, la economía cambia. Las instancias puntuales en la nube se interrumpen a mitad del trabajo. Los clústeres EMR gestionados se facturan por segundos, pero suman cientos o miles al mes para cargas de trabajo analíticas sostenidas.

Los servidores dedicados bare metal ofrecen a las cargas de trabajo de big data algo que las máquinas virtuales en la nube no pueden garantizar: acceso directo al hardware sin la sobrecarga del hipervisor, rendimiento predecible de E/S desde NVMe y un coste mensual fijo que no se dispara cuando tus trabajos ETL se prolongan más de lo esperado.

¿Qué diferencia al bare metal para el big data?

La carga del hipervisor es real. Las máquinas virtuales en la nube que se ejecutan en hardware físico compartido experimentan robos de tiempo de CPU, presión de memoria por parte de los usuarios adyacentes y fluctuaciones de E/S de red que son invisibles a nivel de API, pero que se reflejan claramente en la variación de la duración de los trabajos de Spark. Una etapa de Spark que se completa en 4 minutos el lunes puede tardar 7 minutos el jueves sin motivo aparente.

En el hardware físico, la CPU, el bus de memoria y NVMe pertenecen por completo a tu carga de trabajo. Las operaciones de mezcla de Spark, que requieren lecturas y escrituras de alto rendimiento sostenido en el almacenamiento local, se ejecutan a la velocidad nominal máxima de las unidades, en lugar de tener que pasar por una capa de virtualización.

También está la cuestión de la memoria. La mayoría de los tipos de instancias gestionadas en la nube que ofrecen 192 GB de RAM cuestan entre 800 y 1400 dólares al mes. El servidor dedicado ExtremeInMotion Hosting ofrece 192 GB de RAM DDR5 ECC junto con un procesador AMD EPYC 4545P por 349,99 dólares al mes en un centro de datos gestionado.

Hadoop en hardware dedicado

Hadoop de un solo nodo frente a Hadoop de múltiples nodos

Los clústeres HDFS multinodo siguen siendo la arquitectura adecuada para conjuntos de datos que realmente superan la capacidad de un solo servidor, normalmente por encima de los 50-100 TB de datos sin procesar. Para los equipos analíticos que trabajan con conjuntos de datos de entre 1 y 20 TB, un único servidor dedicado con mucha memoria que ejecute HDFS en modo pseudodistribuido o, lo que es más práctico, que ejecute Spark directamente en NVMe local, elimina la sobrecarga de replicación y los costes de reorganización de la red de un clúster distribuido.

Las NVMe duales de 3,84 TB del nivel Extreme de InMotion te ofrecen 7,68 TB de almacenamiento bruto, con RAID 1 (mdadm) que proporciona 3,84 TB de espacio útil tolerante a fallos. Para el espacio de trabajo temporal y los datos intermedios, puedes configurar la segunda unidad fuera de RAID como un volumen Spark dedicado, lo que mantiene tus datos permanentes protegidos y elimina los conflictos de escritura durante los trabajos intensivos.

Configuración de HDFS para implementaciones en un solo servidor

Ejecutar HDFS en una sola máquina significa configurar el factor de replicación en 1. Esto elimina la sobrecarga de almacenamiento 3x de la replicación HDFS estándar, lo cual es aceptable cuando se dispone de RAID para proteger las unidades subyacentes. Parámetros de configuración clave que vale la pena ajustar en un sistema de 192 GB:

• Establece dfs.datanode.data.dir en el punto NVMe para un almacenamiento en bloques rápido.
• Configura dfs.blocksize en 256 MB o 512 MB para archivos analíticos de gran tamaño con el fin de reducir la sobrecarga de metadatos de NameNode.
• Establece mapreduce.task.io.sort.mb en 512 MB por mapeador para reducir la frecuencia de desbordamiento en hardware con mucha memoria.
• Asigna entre 120 y 140 GB de los 192 GB disponibles a la gestión de recursos YARN, dejando espacio libre para el sistema operativo y NameNode.

Apache Spark: donde el hardware sin sistema operativo resulta más rentable

Asignación de memoria en sistemas de 192 GB

El rendimiento de Spark depende fundamentalmente de la memoria. La fracción de un trabajo que se transfiere al disco en lugar de completarse en la memoria determina si un trabajo tarda 3 minutos o 30. En instancias en la nube con 32 o 64 GB de RAM, la transferencia es habitual. En un sistema de 192 GB, la mayoría de las cargas de trabajo analíticas se completan íntegramente en la memoria.

Una asignación práctica en un servidor Extreme de 192 GB con 16 núcleos:

• Memoria del controlador Spark: 8 GB (suficiente para la mayoría de las cargas de trabajo analíticas)
• Memoria del ejecutor Spark: 160 GB asignados entre los ejecutores (dejando 24 GB para el sistema operativo, el servicio de aleatorización y los gastos generales).
• spark.memory.fraction: 0 ,8 (asigna el 80 % del montón del ejecutor para la memoria de ejecución y almacenamiento)
• Núcleos del ejecutor: 4 núcleos por ejecutor, 4 ejecutores = 16 núcleos totales utilizados.

Esta configuración permite que un único ejecutor mantenga un DataFrame de 100 GB en la memoria sin desbordamientos, lo que cambia el perfil de rendimiento de los algoritmos de múltiples pasadas, como el aprendizaje automático iterativo y el análisis de grafos.

Rendimiento de NVMe

Las transformaciones de unión por ordenación y fusión y las transformaciones amplias de Spark escriben datos aleatorios en el disco local. En las unidades SSD SATA, las escrituras aleatorias alcanzan un pico de aproximadamente 500 MB/s. NVMe mantienen un rendimiento de escritura secuencial de entre 3000 y 5000 MB/s. Para un trabajo que escribe 200 GB de datos aleatorios, la diferencia es de aproximadamente 40 segundos en NVMe 6 minutos en SATA. Esa diferencia se acumula a lo largo de docenas de trabajos diarios.

Configura spark.local.dir para que apunte al NVMe para escrituras aleatorias. Si dispones de una segunda NVMe fuera de RAID, dedícatela por completo al directorio aleatorio de Spark para eliminar la contienda entre la E/S aleatoria y las lecturas de datos del volumen principal.

Análisis en tiempo real: Kafka y Spark Streaming

Spark Structured Streaming, que consume datos de Kafka, requiere un procesamiento de micro lotes con baja latencia. En la infraestructura de nube, la combinación de la latencia de red a un clúster Kafka gestionado y la fluctuación de la CPU de la máquina virtual puede aumentar los tiempos de procesamiento de micro lotes por encima de los 5 segundos, incluso con un rendimiento modesto. Ejecutar Kafka y Spark en el mismo servidor físico o en servidores dedicados coubicados elimina la variable de red.

Un sistema AMD EPYC de 16 núcleos gestiona entre 50 000 y 200 000 mensajes por segundo a través de Kafka sin saturar la CPU, lo que deja un margen considerable para que los consumidores de Spark Structured Streaming procesen y agreguen en paralelo.

Almacenamiento columnar y rendimiento NVMe

Los archivos Parquet y ORC se benefician de manera desproporcionada de NVMe. Ambos formatos utilizan predicado pushdown y poda de columnas, lo que significa que una consulta que lee el 5 % de las columnas en un conjunto de datos de 1 TB solo puede realizar 50 GB de E/S reales. En NVMe que mantienen lecturas secuenciales de 5 GB/s, ese escaneo de 50 GB se completa en aproximadamente 10 segundos. En un volumen en la nube conectado a una red de 1 Gbps con un límite de 125 MB/s, el mismo escaneo tarda casi 7 minutos.

Para las cargas de trabajo analíticas basadas en Parquet u ORC, NVMe en bare metal no es una mejora marginal. Cambia qué consultas son interactivas y cuáles son por lotes.

Comparación de costes: Bare Metal frente a la nube para big data

Configuración	Coste mensual	RAM	Almacenamiento	Notas
AWS EMR (nodos r5.4xlarge x2)	~980 $ al mes	256 GB en total	EBS (coste adicional)	Los precios al contado añaden riesgo de interrupción.
AWS EC2 r6i.4xlarge (dedicado)	~780 $ al mes	128 GB	EBS (coste adicional)	Sin gestión incluida
InMotion Extreme Dedicado	349,99 $ al mes	192 GB DDR5 ECC	3,84 TB NVMe RAID 1)	Coste fijo
InMotion Avanzado Dedicado	149,99 $ al mes	64 GB DDR4	1,92 TB NVMe RAID 1)	Adecuado para conjuntos de datos de menos de 500 GB en memoria.

La ventaja en cuanto a costes es considerable, pero lo más importante es la previsibilidad. Las tareas ETL que se ejecutan durante más tiempo del previsto no generan facturas inesperadas en el hardware.

Cuándo utilizar varios servidores frente a un servidor con mucha memoria

Un servidor potente gestiona la mayoría de las cargas de trabajo analíticas por debajo de 3 TB de datos activos. Los casos en los que se hace necesaria una arquitectura multiservidor:

• El tamaño del conjunto de datos sin procesar supera realmente NVMe de un solo servidor (más de 7 TB de datos de origen).
• Los usuarios analíticos simultáneos superan lo que Spark con un solo servidor puede programar sin colas.
• Los requisitos de alta disponibilidad implican que un único servidor genera un riesgo inaceptable de tiempo de inactividad para los procesos de producción.
• La separación de funciones entre la ingesta de Kafka, el procesamiento de Spark y las capas de servicio requiere aislamiento físico.

Para la mayoría de los equipos analíticos del mercado medio, un único servidor dedicado Extreme gestiona la carga de trabajo con margen para crecer. Cuando necesites un segundo servidor, el equipo APS de InMotion puede ayudarte a diseñar la configuración multinodo.

Infraestructura gestionada para equipos de ingeniería de datos

Los equipos de ingeniería de datos deberían dedicarse a escribir canalizaciones, en lugar de responder a alertas a las 3 de la madrugada sobre el espacio en disco del servidor o los bloqueos por falta de memoria. El equipo de asistencia técnica avanzada de InMotion se encarga de los problemas a nivel del sistema operativo en servidores dedicados, lo que significa que tu equipo recibe una alerta y una solución, en lugar de un ticket para trabajar.

Premier Care añade 500 GB de almacenamiento de copia de seguridad automatizada para configuraciones de canalización, instantáneas de datos y archivos jar de aplicaciones Spark, además de protección contra malware Monarx para el entorno del servidor. Para los equipos de datos que almacenan información comercialmente sensible, esa protección es importante.

Vale la pena utilizar la consulta mensual de 1 hora de InMotion Solutions incluida en Premier Care específicamente para el ajuste de Spark y Hadoop. Los errores de configuración, como directorios de mezcla de tamaño insuficiente o límites de memoria YARN mal configurados, son comunes y resultan costosos en tiempo de trabajo.

Cómo empezar

El primer paso adecuado es comparar la duración actual de tus trabajos en la infraestructura en la nube y, a continuación, ejecutar los mismos trabajos en una configuración de prueba de InMotion Extreme. La diferencia de rendimiento en los trabajos de Spark con gran cantidad de mezclas suele justificar la migración en el primer mes.

Para los equipos que ejecutan múltiples trabajos Spark al día en conjuntos de datos de más de 100 GB, el ahorro mensual con respecto a una infraestructura en la nube equivalente suele cubrir con creces el coste del servidor. La consistencia del rendimiento es más difícil de cuantificar, pero se refleja a diario en la fiabilidad del SLA del proceso.