Las herramientas de línea de comandos pueden ser 235 veces más rápidas que un clúster de Hadoop (2014)

• Al procesar aprox. 1.75 GB de datos de partidas de ajedrez con herramientas de línea de comandos en lugar de Hadoop, la tarea terminó en solo 12 segundos, mostrando un rendimiento más de 235 veces superior frente a los 26 minutos de Hadoop
• Combinando comandos básicos del shell como grep, sort, uniq, awk, xargs y mawk se construyó un pipeline de procesamiento en streaming, manteniendo el uso de memoria casi en 0
• Mediante procesamiento paralelo con xargs y optimización con mawk, se aumentó el aprovechamiento de los núcleos de CPU y se minimizó el cuello de botella de IO
• Frente a procesar el mismo dataset con un clúster de Hadoop (7 instancias c1.medium), el enfoque tiene una carga de costos y mantenimiento notablemente menor
• Muestra que incluso en una sola máquina es posible hacer análisis de datos de forma eficiente, y plantea una alerta sobre el uso innecesario de herramientas de Big Data

---

Introducción: procesamiento por línea de comandos más rápido que Hadoop

• Tras ver un caso donde se analizaron unos 2 millones de partidas de ajedrez con Amazon EMR y mrjob, se reprodujo el mismo procesamiento con un enfoque de streaming basado en línea de comandos
  • En un clúster de Hadoop (7 nodos c1.medium) tomó 26 minutos, con una velocidad de procesamiento de 1.14 MB/s
  • En una laptop local terminó en 12 segundos, con una velocidad de procesamiento de 270 MB/s
• Demuestra que para tareas simples de agregación de resultados, un pipeline de shell es mucho más eficiente que Hadoop
• Al combinar comandos de shell, es posible implementar en una sola máquina una estructura de procesamiento de streams en paralelo similar a Storm

Estructura y preparación de los datos

• Los datos están en formato PGN (Portable Game Notation), y el resultado de cada partida aparece en la línea "Result"
  • "1-0" significa victoria de blancas, "0-1" victoria de negras y "1/2-1/2" empate
• Se obtuvo un dataset de aprox. 3.46 GB desde el repositorio rozim/ChessData en GitHub
  • Casi el doble del conjunto usado en el experimento de Tom Hayden (1.75 GB)

Construcción del pipeline básico

• Para medir el límite de IO, al ejecutar cat *.pgn > /dev/null tomó unos 13 segundos (272 MB/s)
• Pipeline básico de análisis:

  cat *.pgn | grep "Result" | sort | uniq -c
  

  • Tiempo de ejecución de aprox. 70 segundos, unas 47 veces más rápido que Hadoop
• En lugar de sort | uniq, se usó AWK para contar directamente los resultados
  • Tiempo de ejecución de 65 segundos, con uso de memoria casi nulo
  • grep ocupaba un solo núcleo de CPU y se convertía en el cuello de botella

Paralelización y optimización

• Se paralelizó grep con xargs

  find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
  

  • Tiempo de ejecución de 38 segundos, una mejora de velocidad de unas 77 veces
• Se eliminó grep y se simplificó el proceso con filtrado solo con AWK
  • Se construyó un pipeline doble con AWK para consolidar los resultados de cada archivo
  • Tiempo de ejecución de 18 segundos, unas 174 veces más rápido
• Al cambiar a mawk se logró una optimización adicional

  find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
  

  • Tiempo de ejecución de 12 segundos, 235 veces más rápido que Hadoop, con una velocidad de procesamiento de 270 MB/s

Conclusión: la eficiencia de la simplicidad

• Salvo cuando se requiere procesamiento distribuido a gran escala, combinar herramientas de shell en una sola máquina es más rápido y económico
• Hadoop suele usarse en exceso incluso para tareas que podrían resolverse con una base de datos relacional o un script simple
• El análisis en streaming basado en línea de comandos es una alternativa superior en rendimiento, costo de implementación y mantenibilidad

[dongho42]

Hace tiempo existía la expresión de programación Taco Bell; parece una filosofía parecida.

[GN⁺]

Comentarios en Hacker News

• Lo más triste es que este artículo es de 2014
  Ahora hay todavía más capas de abstracción como Airflow, dbt y Snowflake, y se las terminan poniendo encima incluso a datasets que en realidad caben completos en RAM
  Startups se gastan 5 mil dólares al mes en clústeres distribuidos para procesar menos de 10 GB de logs al día. La razón es que usar el ‘Modern Data Stack’ te ayuda a ascender, pero si lo resuelves con un script de bash te lo descartan por ‘no ser escalable’. La eficiencia y los incentivos están totalmente desalineados

  • En entrevistas recientes hablaban de ‘problemas de escalado’, pero en la práctica muchas veces todo cabía sin problema en una sola máquina
    Incluso hubo un caso que ingería 1 GB de JSON al día, y cuando expliqué que “una sola máquina bastaba”, me respondieron “técnicamente es correcto, pero no es la respuesta que queremos” y me rechazaron
    Las máquinas actuales tienen RAM de varios TB y cientos de núcleos. Una sola máquina ya es enorme
  • Esto no es solo un tema de ascensos, sino también de la estructura de contratación
    Al contratar gente de DevOps se enfatiza la experiencia con frameworks vistosos, así que cuando llegan a la empresa repiten exactamente lo mismo
    Como nadie se opone, terminan complicando trabajos que podrían resolverse con una sola desktop
  • Llevo 20 años usando la ‘tecnología correcta’ en vez de la ‘tecnología que se ve cool’, y al final me despidieron
    Llevo más de un año buscando trabajo con un CV casi sin frameworks modernos, y eso me hace sentir como un tonto
  • También vi algo parecido en la empresa. Para mover unos cuantos GB al día entre varios sistemas, algo que antes se resolvía en una semana con scripts de Python ahora tarda meses y se rompe seguido
  • Hoy en día hasta las laptops con 128 GB de RAM son comunes, y los servidores son mucho más grandes
    En 2014 lo normal eran 4 GB, pero ahora también las velocidades de streaming desde SSD son tan altas que a veces leer desde un SSD local rinde mejor que usar un clúster

• ¡Soy el autor!
  Me alegra que un artículo viejo siga siendo útil
  Estoy de acuerdo con quienes dicen que la situación ha empeorado, aunque por otro lado me da gusto ver que también hay un movimiento para salir del culto a los microservicios
  Ánimo para todos los que están trabajando en mejorar el rendimiento. Todavía hay esperanza

  • ¡Gracias, Adam!
    He releído tu artículo varias veces y, inspirado por él, porté Waters-Series a JavaScript para implementar pipeline de streams

• Hoy en la industria está demasiado instalada la idea de que Spark o las herramientas distribuidas son la respuesta correcta para la ingeniería de datos
  Es parecido a la tendencia de abusar de los frameworks SPA en desarrollo web
  Mi consejo es este:

  • Los managers no deberían exigir una tecnología específica (Spark, React), sino dejarlo en manos de ingenieros con capacidad para resolver problemas
  • Los líderes técnicos deberían decir con honestidad: “nuestro pipeline puede manejar hasta 20 GB y, si crece más, planeamos escalar con X/Y/Z”
    Lo que el manager quiere escuchar no es “todo escala infinitamente”, sino la certeza de que “esto funciona de forma estable”
  • La mayoría de las empresas manejan datos pequeños
    El tamaño de los datos sigue una ley de potencia, así que los ingenieros que trabajan con datos a escala de petabytes son una minoría ínfima
    Pero como muchos quieren poner esa experiencia en el CV para ganar más salario, aparece la sobreingeniería
  • Cuando trabajaba en un unicornio famoso, un manager dijo “el próximo trimestre tenemos que usar Spark”
    Cuando le pregunté por qué, respondió “porque sí”. Probablemente era por el currículum o por razones políticas de alguien

• Una historia histórica relacionada con el artículo
  La herramienta mrjob también podía ejecutarse en modo local, sin Hadoop
  Con datasets pequeños era muchísimo más rápida que un clúster, especialmente que clústeres efímeros como AWS EMR
  Aun así, da la impresión de que el enfoque del autor habría sido todavía más eficiente
  MapReduce facilitaba escalar a gran tamaño, pero para datos pequeños imponía muchas restricciones ineficientes
  A inicios de la década de 2010 procesé datos a escala de petabytes con mrjob, pero hoy casi ya no se usa

• Cuando trabajaba como ingeniero de datos, reescribí scripts de Bash/Python en C# y llevé la velocidad de procesamiento de JSON hasta 1 GB/s
  Solo con optimizaciones como el parsing en streaming ya se lograban diferencias enormes
  Así que me da curiosidad: ¿a partir de qué volumen de datos realmente empieza a tener sentido usar clústeres?

  • Al revés, hace 15 años también me pasó que reemplacé un sistema complejo en C# por bash + Python y quedó muchísimo más rápido
    Para mí, si una tarea tarda más de un día, ya vale la pena considerar procesamiento distribuido
  • Hace tiempo, en un panel de PyCon, un científico de datos famoso dijo que “Excel es mejor que Pandas”
    Cuando los datos eran grandes, hacía muestreo y analizaba la muestra en Excel. Hoy además, gracias a los LLM, es fácil escribir scripts simples en Python o Bash
  • Además del tiempo de procesamiento, otro criterio es cuando los datos ya no caben en el disco local
    Hoy se puede leer y escribir directamente en almacenamiento de objetos como S3, y ya es posible llegar a 100 GB/s
  • El dataset de ajedrez mencionado en este comentario tiene unos 14 TB
    Cabe en disco, pero es demasiado grande para una laptop normal
  • Me da curiosidad cómo hacer parsing de JSON en streaming. La mayoría de los parsers necesitan leer todo para validar la sintaxis; quisiera saber cómo resolvieron eso

• El ‘tamaño’ de los datos depende de qué quieres hacer con ellos
  Por ejemplo, con datos quirúrgicos, unas estadísticas simples bastan con bash, pero si quieres calcular la correlación entre la experiencia del médico y la tasa de éxito, la complejidad sube de golpe
  Por eso, para una empresa es mucho más fácil decir “usamos Spark” que decir “creamos un motor a la medida para cada pregunta”

  • Aun así, con solo SQLite puedes procesar entre 50 GB y 2 TB
    Todos los problemas mencionados pueden resolverse en un solo servidor con herramientas sencillas

• Este artículo ya apareció varias veces en HN
  La versión de 2018, la versión de 2022 y la versión de 2024 fueron enviadas por la misma persona

• Me recordó el texto de presentación del antiguo sitio web de Shakti
  “1K rows: Excel / 1M rows: Pandas / 1B rows: Shakti / 1T rows: Only Shakti”
  Fuente

• Muchos desarrolladores aprendieron en entornos Windows, así que no están familiarizados con las herramientas de CLI
  Pero la CLI ofrece capacidades potentes como loops implícitos, separación automática de campos y aplicación paralela de expresiones regulares
  Gracias a eso, permite crear rápido soluciones ad-hoc y sirve como muy buen punto de partida antes de pasar a sistemas grandes

• Me pregunto qué pasaría si se ampliaran mucho más los datos de ajedrez y se repitiera el benchmark
  Hoy el dataset de Lichess tiene unos 7B juegos, 2.34 TB comprimidos (14 TB sin comprimir)
  Me da curiosidad si a esa escala Hadoop podría ganar

  • Si metes varios SSD rápidos en un solo servidor, todavía parece probable que siga siendo más rápido que EMR+S3
    Aunque eso sí exige administrar un servidor dedicado
    EMR está diseñado para un modelo en el que el acceso a los datos es poco frecuente (1 a 10 veces al día) y se busca paralelismo
  • Los datos comprimidos caben sin problema en SSD locales y además se puede hacer descompresión en streaming
  • Me da curiosidad qué se podría calcular con esos datos. Sería divertido probar en NVL72