¿Lo tuvo con Apache Storm? Garza se lanza al rescate

El año pasado, Twitter lanzó dos bombas. Primero, ya no usaría Apache Storm en producción. En segundo lugar, lo había reemplazado por un sistema de procesamiento de datos de cosecha propia, Heron.

A pesar de publicar un documento que detalla la arquitectura de Heron, la alternativa de Twitter a Storm permaneció oculta en los centros de datos de Twitter. Todo eso cambió la semana pasada cuando Twitter lanzó Heron bajo una licencia de código abierto. Entonces, ¿qué es Heron y dónde encaja en el mundo del procesamiento de datos a escala?

Un motor de procesamiento de datos de gráfico acíclico dirigido (DAG), Heron es otra entrada en un campo muy concurrido en este momento. Pero Heron no es un "¡mira, yo también!" solución o un intento de convertir los motores DAG en el equivalente de Big Data de FizzBuzz.

Heron surgió de las preocupaciones reales que tenía Twitter con su gran despliegue de topologías Storm. Estos incluyeron dificultades con la creación de perfiles y el razonamiento sobre los trabajadores de Storm cuando se escalan a nivel de datos y a nivel de topología, la naturaleza estática de la asignación de recursos en comparación con un sistema que se ejecuta en Mesos o YARN, falta de soporte de contrapresión y más.

Aunque Twitter podría haber adoptado Apache Spark o Apache Flink, eso habría implicado reescribir todo el código existente de Twitter. (No lo olvides, Twitter ha usado Storm por más tiempo que nadie, adquiriendo BackType, el creador de Storm, en 2011 antes de que fuera de código abierto). En cambio, Twitter adoptó un enfoque diferente: un nuevo marco de procesamiento de transmisión con una API compatible con Storm. .

En este punto de nuestro recorrido por un nuevo marco, normalmente revisaría algunos ejemplos para mostrarle cómo se siente la codificación en el marco, pero no tiene mucho sentido con Heron: escribe Storm bolts y tuplas exactamente de la misma manera que lo harías con Storm. Todo lo que necesita hacer para ejecutar su código Storm en Heron es agregar esta sección a las dependencias de su pom.xml:

 com.twitter.heron

 heron-api

 SNAPSHOT

 compile

 com.twitter.heron

 heron-storm

 SNAPSHOT

 compile

Luego eliminas las dependencias de plugin de plugin de clojure y de código de tormenta. Vuelva a compilar y su código se ejecutará en Heron sin más cambios necesarios. ¡Simple! (Sobre todo, de todos modos, pero volveremos a eso).

Operacionalmente, la implementación actual de Heron se ejecuta sobre Apache Mesos, utilizando Apache Aurora, el marco de programación de Mesos desarrollado por Twitter (¡sorpresa!). Desde que cambió todas sus topologías Storm a Heron, Twitter logró reducir los recursos de hardware dedicados a las topologías en un factor de tres mientras aumentaba el rendimiento y reducía la latencia en el procesamiento, nada mal.

Quizás uno de los aspectos más interesantes de Heron es que, si bien el código se escribirá en Java (o Scala), y los componentes de la interfaz de usuario basados ​​en la web están escritos en Python, las partes críticas del marco, el código que administra las topologías. y las comunicaciones de red no están escritas en ningún lenguaje JVM.

De hecho, en el corazón de Heron, encontrarás código en un lenguaje que quizás no esperes: C ++. Creo que este es un aspecto del mundo de los macrodatos que veremos más en los próximos años. 

Los mantenedores de Apache Storm han eliminado muchos elementos de su código Clojure original en favor de las reimplementaciones de Java, y el proyecto Apache Spark actualmente genera código Java sobre la marcha para acelerar su procesamiento de DataFrame. Pero ambos todavía están vinculados a la JVM, y la JVM tiene problemas a escala. No me malinterpretes, la JVM es una creación asombrosa que ha resistido la prueba del tiempo durante 20 años, pero cuando se ejecuta en máquinas con grandes cantidades de RAM y procesa enormes cantidades de datos, surgen problemas con la recolección de basura, sin importar qué esquema de coleccionista de lujo que utiliza.

En ese momento, volver a un lenguaje como C ++ comienza a parecer atractivo. Como ejemplo, Scylla, una reimplementación en C ++ de Apache Cassandra, tiene 10 veces el rendimiento de Cassandra sin ninguna de las pausas de GC por las que Cassandra es conocida en grandes implementaciones. Estoy bastante seguro de que pronto veremos el enfoque de Heron extenderse a otros marcos. Esto puede ser ayudado por el intento del Proyecto Panamá de mejorar la interfaz entre Java y otros lenguajes.

Dado que Heron requiere menos recursos y proporciona más rendimiento y menos latencia que Apache Storm, debería mover todas sus topologías a Heron ahora mismo, ¿no? Bien quizás. Heron está actualmente vinculado a Mesos, por lo que si no tiene la infraestructura de Mesos existente, deberá configurarla también, lo cual no es una empresa pequeña. Además, si está utilizando las funciones de DRPC de Storm, están obsoletas en Heron.

En el lado positivo, Heron ha estado ejecutando todas las necesidades de procesamiento de Twitter en producción durante más de un año, por lo que debería poder manejar cualquier cosa que pueda arrojarle. Además, Twitter señala que Heron se usa en Microsoft y otras compañías de Fortune 500, por lo que puede estar relativamente seguro de que se mantendrá.

Por otro lado, Storm no se ha quedado quieto. El equipo de Apache Storm podría objetar la descripción de Twitter de Heron como la "próxima generación de Apache Storm". Mientras Twitter estaba trabajando en Heron, Apache Storm alcanzó 1.0, que incluye soporte para contrapresión, opciones mejoradas de depuración y creación de perfiles, una disminución del 60 por ciento en la latencia y una mejora de velocidad de hasta 16 veces.

In addition, Storm 1.0 adds pacemaker, a daemon for offloading heartbeat traffic from ZooKeeper, freeing larger topologies from the infamous ZooKeeper bottleneck. Heron's speed improvements are measured from the Storm 0.8.x code it diverged from, not the current version; if you have migrated over to Storm 1.0 already, you might not see much more improvement over your current Storm topologies, and you may run into incompatibilities between the implementation of new features like back-pressure support between Storm and Heron.

En general, no creo que Heron pueda causar una gran mella en la adopción de marcos de procesamiento de datos como Apache Spark, Apache Flink o Apache Beam. Sus abstracciones y API de nivel superior proporcionan una experiencia mucho más amigable para el desarrollador que las API Storm / Trident de nivel inferior. Sin embargo, creo que la combinación de código JVM con módulos que no son JVM para las rutas críticas será un enfoque más popular en el futuro, y en este aspecto, Heron nos muestra toda la dirección en la que viajaremos en los meses y años. venir.