Actualmente, dentro del amplio panorama de tecnologías Big Data, el procesamiento en tiempo real  es sin duda uno de los campos más atractivos y dinámicos. Sin embargo, la elección de una tecnología para afrontar los retos asociados a este tipo de aplicaciones puede ser una tarea desafiante ya que no existe un estándar de facto, como puede ser Apache Spark para el procesamiento batch.

Esta situación que hoy en día nos encontramos en el panorama real time se asemeja al vivido hace unos años con las tecnologías NoSQL, ya que la cantidad y diversidad de las mismas, y los pequeños matices que diferenciaban unas de otras, hacía muy complicada la elección de una de ellas para caso de uso específicos, y aún más para arquitecturas de referencias en grandes organizaciones, desarrolladas con la intención de soportar multitud de diferentes casos de uso. Dentro de este escenario fue de gran ayuda la utilización del Teorema de CAP, que establecía unos criterios de clasificación y conceptos básicos estandarizados a la hora de seleccionar una tecnología NoSQL, dejando aparte la responsabildad de identificar otros criterios de clasificación más específicos del caso de uso en curso.

Con estos antecedentes en cuenta, obviamente se echa de menos una especie de “CAP del real time”, el cual actualmente no existe, por eso el objetivo de este post es definir aquellos principios que podrían considerarse como la base para definir y localizar una tecnología en el espectro de las aplicaciones de tiempo real en Big Data.

Estos principios serían los siguientes:

LATENCIA: toda aplicación que quiere procesar en tiempo real debería estar diseñada para tratar cada dato de origen tan pronto como sea recibido, añadiendo el tiempo mínimo de overhead propio de la herramienta. Por otro lado, una alta latencia ( mala ) no está reñida con conseguir un muy alto volumen de datos procesados en un periodo de tiempo ( throughtput ). Lo ideal es tener las dos cosas, baja latencia y alto thorughput; por ello la mejor manera de comparar soluciones es tomar métricas desde ambos puntos de vista:

  • sobre un número total fijo de eventos procesados calcular percentil 95 o 99 de latencia.
  • trabajando a una misma latencia máxima permitida, número de eventos procesados en un intervalo de tiempo ( throughput ).

Dicho esto, hay tecnologías cuyo core engine está orientado a batch, por lo que no permiten       trabajar a unas latencias por debajo de un cierto límite por diseño ( micro batching ), otras en cambio han sido diseñadas con core puramente streaming, por lo que consiguen   latencias realmente bajas. En casos extremos a ciertas latencias por encima del segundo, las tecnologías micro batch consiguen throught por encima de las puramente en streaming. Ver benchmark realizado por yahoo https://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming-computation-engines-at, que es la referencia para este tipo de tecnologías.

SEMÁNTICA: nos referimos con semántica a la posibilidad real de perder o duplicar el procesamiento de datos, debido a situaciones excepcionales como elementos que forman parte de la solución de procesamiento en tiempo real. Al final el término semántica se refiere a la certeza de la consistencia de los datos agregados a partir de los datos origen.

Hay tecnologías que no pueden asegurar el no perder datos (at-most-once) o duplicar su procesamiento (at-least-once), mientras que otras permiten asegurar la consistencia de los datos procesados (exactly-once) a espensas de incrementar la latencia en mayor o menor grado. En determinadas organizaciones y negocios es vital asegurar la consistencia de los datos, mientras que en otras se puede relajar este requisito con el fin de reducir latencia.

ANALÍTICA: algunas de las soluciones de real time existentes han sido diseñadas con el fin de obtener valores agregados sobre datos de diversas fuentes de origen, para lo cual trabajan internamente con ventanas de datos ( agrupación de datos para ser procesados de forma conjunta ), bien por tiempo, número de eventos o relacción funcional de los mismos (p.e. sesión de usuario logado ). Estas herramientas añaden un excesivo overhead ante los casos de uso que requieren procesamiento de datos individuales, pero en cambio ofrecen una gran riqueza de opciones de procesado de ventana, permitiendo ventanas deslizantes en el tiempo, e incluso proporcionando APIs para permitir políticas de ventanas ad-hoc.

Ventana por intervalo de tiempo ( t segundos )

 

Ventana deslizante por intervalo de tiempo (t segundos cada x segundos)

Por otro lado, otras tecnologías han sido concebidas con el fin de procesar datos o eventos individuales, dentro de arquitecturas basadas en eventos y con servicios reactivos. Esto permite una gran flexibilidad y muy baja latencia por evento, pero las mismas van poco a poco incorporando funcionalidades de procesamiento de los mismos en ventanas o agrupaciones, momento en el cual presentan carencias de rendimiento con respecto a las diseñadas específicamente para tal fin.

REFERENCIA TEMPORAL: el procesamiento de datos en tiempo real  tiene un alto grado de dependencia de la referencia temporal de los datos a procesar. Así, los mismos datos pueden generar diferentes resultados si se consideran diferentes referencias temporales. Pero, ¿qué es la referencia temporal del dato?, bien, no es más que un momento en el tiempo (timestamp) que se asocia al dato y que se utiliza para realizar procesamiento analítico del mismo basado en ventanas temporales.

Un caso típico p.e. sería contabilizar el número de mensajes enviados por un móvil en un periodo de tiempo, si tomamos como referencia temporal de cada mensaje el momento en el que se inicia su procesamiento por la solución utilizada (ingestion time), tendríamos un resultado. ¿Qué pasa si la red telefónica sufre una caída en uno de sus repetidores o el mensaje es enviado desde un área sin cobertura, p.e. un túnel, y uno de los mensajes llega con 10 minutos de retraso con respecto a los otros enviados en la misma franja temporal? … posiblemente no serían computados en la misma ventana analítica por lo que el resultado obtenido no sería real. Para este tipo de casuística se suele asociar la referencia temporal del dato en el momento en el que se genera en origen (event time), y viaje con éste hasta el momento que es procesado, así nos aseguramos que dicho dato se computa en su correspondiente ventana analítica.

Dependiendo de la referencia temporal, el dato 5 se procesa en una u otra ventana analítica

 

Esta solución abre nuevas cuestiones como…

  • ¿cuánto tiempo espero en una ventana analítica a la llegada de datos que vienen retrasados para generar su resultado ?
  • ¿se pueden generar N resultados en dicha ventana?: De forma que los primeros son imprecisos y se van completando y ajustando a la realidad conforme se van procesando datos retrasados en sucesivas emisiones de resultados

GESTIÓN DE ESTADO: definimos estado como aquella información contextual al procesamiento actual que es requerida en el procesamiento de un determinado evento o dato.

Hay soluciones real time que no contemplan el estado en sus operaciones, y requiere que el proyecto que las utiliza gestione el mismo. Otras soluciones dan la posibilidad de gestionar el estado de forma transparente mediante APIs de la propia tecnología, abstrayendo al proyecto de la problemática propia del procesamiento con estado como es la recuperación del mismo ante caídas parciales o totales de la topología sobre la que corre la aplicación, o el escalado de la topología.

Una vez definidas las dimensiones que nos permiten localizar las tecnologías real time Big Data, en sucesivas entradas del blog pasaremos a definir diferentes tecnologías según dichas dimensiones, entrando en detalle en los matices o particularidades y grado de cumplimiento de los mismos por cada una de ellas. El objetivo final para cualquier solución sería alcanzar el mayor grado de cumplimiento de dichos principios para obtener la solución más completa(**), aunque algunos de los principios se pueden relajar o priorizar en función de los requisitos de casos de usos específicos.

(**) “Carl” Lewis, apodado El Hijo del Viento, atleta estadounidense con 10 medallas olímpicas que destacó no sólo por su velocidad, sino que por su elegancia técnica y completitud como atleta, dominando otras especialidades como el salto de longitud (http://yunga-youth.weebly.com/carl-lewis.html).

 

Tecnologías a evaluar en sucesivas entradas del blog:

  • Apache Spark-Streaming

 

  • Apache Flink

 

  • Apache Storm

 

  • Apache Heron

 

  • Kafka Streams
  • Apache Apex

 

  • Apache Samza

 

  • Hazelcast Jet

 

  • Google Data Flow

De entre la lista de tecnologías muchos habréis echado de menos Apache Beam (https://beam.apache.org) , y no es por subestimar a la misma, sino todo lo contrario, ya que consideramos Apache Beam como la tecnología que actualmente está sentando las bases del procesamiento en tiempo real, y sirve como referente y espejo en el que las demás tecnologías se quieren reflejar. No es casualidad que haya sido impulsada por Google, la cual tras años de experiencia con el procesamiento en cloud por separado de Batch y Tiempo real con grandes cantidades de datos (¡¡y ellos si tiene grandes cantidades de datos!!),  han ido definiendo las bases para unificar el procesamiento en ambos modos, y han hecho público parte de su conocimiento al igual que hicieron con MapReduce y GFS, sirviendo de guía al resto de players dentro del procesamiento en tiempo real. De hecho los principios definidos en este post están basados en los establecidos de forma más detallada en la definición de Apache Beam.

Muchos podrían ver esta defensa de Apache Beam en contradición con la anterior afirmación sobre la complejidad  de elegir una tecnología de procesamiento en tiempo real; lamentablemente Apache Beam define unos conceptos y una capa de abstracción a la hora de programar el procesamiento en tiempo real y batch, pero no ejecuta internamente dicho procesamiento sino que lo delega en algunas de las tecnologías de las anteriormente citadas ( Spark Streaming, Flink, Google Data Flow, Apex….), ahí reside lo bonito de Apache Beam, define el qué, cuándo, dónde y cómo procesar datos en tiempo real (https://cloud.google.com/blog/big-data/2016/05/why-apache-beam-a-google-perspective), y establece las pautas para ello a alto nivel. Por lo tanto, seguimos teniendo el problema de elegir tecnología de tiempo real, aunque usemos Apache Beam, para ejecutar realmente el procesamiento en Streaming; aunque eso sí, Apache Beam nos da en teoría la posibilidad de migrar nuestros desarrollos de una a otra tecnología sobre la que corre Beam, de forma “casi” automática.

Conclusiones

Debido a la variedad de opciones y auge actual en cuanto al procesamiento en tiempo real en Big Data, es difícil seleccionar la opción más adecuada para cada caso de uso, especialmente porque muchas veces no se realiza el ejercicio de escarbar en el marketing y “aureola” que rodea a cada una de las tecnologías, para extraer las propiedades de la misma que permitan de forma objetiva compararla con sus competidoras. En este post se ha intentado establecer unos criterios o principios para poder comparar cada una de las tecnologías indicadas de la forma más objetiva posible, facilitando la compresión y situación dentro del mapa de cada una de ellas, con vistas a su selección para diferentes casos de uso.

By Francisco Jose Guerrero Sánchez, Principal Big Data and Solutions Architect at Indizen.