¿POR QUÉ APACHE FLINK ESMEJOR QUE SPARK?

Dr Rubén Casado Tejedor

• Formación– Doctor en Informática (Ingeniería del Software)

– Ingeniero en Informática

– Ingeniero Técnico en Informática de Sistemas

• Experiencia profesional– Big Data Manager en Accenture Digital

– Director del Master en Arquitectura Big Data en Kschool

– Organizador del Meetup Apache Flink Madrid

– Head of Big Data & Analytics en Treelogic

– Investigador y profesor en la Universidad de Oviedo, Oxford Brookes University (Reino Unido) y

INRIA/LORIA (Francia)

Sobre mi

█ BIG DATA Y STREAMING PROCESSING█ CONCEPTOS CLAVE EN FAST DATA█ DIFERENCIAS ENTRE FLINK Y SPARK‒ Code demo

█ CONCLUSIONES

█ BIG DATA Y STREAMING PROCESSING

VOLUMENGrandes cantidades de datos.

Necesidad de soluciones tecnológica y económicamente escalables.

VARIEDADInformación estructurada, semi y desestructurada. Necesidad de

almacenar y procesar distintos tipos de información.

VELOCIDADAlta frecuencia de generación de

información. Necesidad de producir resultados en tiempo real.

STREAMING PROCESSING es el paradigma de procesamiento para

STORMVELOCIDAD

APACHE FLINK

STREAMING PROCESSINGAnalizar según sucede

Plataforma tradicional de BI Plataforma Big Data batch processing

Analytical Database Data as a platform

Data Ingest

Data Collection

Cocheautodirigido

Waze

¿QUÉ ES STREAMING PROCESSING?

CLASIFICACIÓN EJEMPLOS LATENCIA TOLERANCIA AL RETRASO

Hard • Marcapasos

• Sistema antibloqueo de frenos

• Microsegundos - milisegundos • Ninguna fallo total del sistema, pérdidas de vidashumanas, etc.

Soft • Sistema de reservas online

• VoIP

• Milisegundos - segundos • Baja fallo total del Sistema, sin pérdidas de vidas humanas.

Near • Sistema de video-conferencia

• Domótica

• Segundos - minutos • Alta sin riesgo de fallodel sistema

ARQUITECTURA GENERALSTREAMING PROCESSING SYSTEM

CAPA DE ADQUISICIÓN

COLA DE MENSAJES

CAPA DE PROCESAMIENTO

ALMACENAMIENTO EN MEMORIA

CAPA DE ACCESO

ALMACENAMIENTO LARGA DURACIÓN

ORIGEN

2009UC Berkeley empieza a trabajaren Spark

2010Yahoo! crea S4

2010Cloudera creaFlume

2011Nathan MarzcreaStorm

2014Stratosphere evoluciona a Apache Flink

2013Se publica Spark v0.7 con la primera version de Spark Streaming

2013Linkedin presentaSamza

2012LinkedIn desarrolla Kafka

2015Ebay liberaPulsar

2015DataTorrent liberacomo incubator Apache Apex

2016Se publicaApache Storm v1.0con grandes cambios

2016Google promueveApache Beamcon el apoyo de DataArtisans y Cloudera

2016Se publicaApache Spark 2.0con notables cambios

█ CONCEPTOS CLAVE EN FAST DATA

SEMÁNTICA DE PROCESAMIENTO

AT-LEAST-ONCE AT-MOST-ONCE EXACTLY-ONCE

Cada mensaje se procesa al menos una vez. Se asegura que todos los

mensajes recibidos son procesados, pero podría pasar que algún mensaje

se procesase más de una vez.

Cada mensaje se procesa como máximo una vez. Se asegura que

ningún mensaje es procesado más de una vez, pero podría pasar que algún

mensaje no se procesase.

Cada mensaje se procesa exactamente una vez. Ningún mensaje se queda sin procesar y ningún mensaje se procesa más de una vez. La más compleja de

implementar.

NOCIÓN DEL TIEMPOPr

oces

sing

Tim

e

Event Time

Skew

Event Time Processing Time

Una nueva esperanza Episodio IV 1977

El Imperio Contraataca Episodio V 1980

El Retorno del Jedi Episodio VI 1983

La Amenaza Fantasma Episodio I 1999

El ataque de los Clones Episodio II 2002

La venganza de los Sith Episodio III 2005

El despertar de la fuerza Episodio VII 2015

9:008:00 14:0013:0012:0011:0010:002:001:00 7:006:005:004:003:00

NOCIÓN DEL INFINITO

VENTANAS

13:00 14:008:00 9:00 10:00 11:00 12:00

Fijas Deslizantes1 2 3

54

Sesiones

2

431

Key 2

Key 1

Key 3

TiempoNº elementos

2 3 4

TIPOS DE VENTANAS

Cuando juntamos tiempo y ventanas….

TRIGGER Y WATERMARK

What Where When How

Estrategia early and late firings

█ DIFERENCIAS ENTRE FLINK Y SPARK‒ Code demo

¿QUÉ SON?

Plataforma de procesamiento distribuido basadoen memoria para data-at-rest y data-in-motion.

• Motor de procesamiento streaming‒ Batch como caso especial de streaming

• API sencillo para batch y streaming en múltiples lenguajes‒ Java, Scala, SQL, Python (WIP), R (WIP)

• Librerías para CEP, ML y Grafos

• Integración con ecosistema Big Data ‒ Hadoop, Kafka, HBase, etc.

• Open Source‒ Proyecto Apache desde 2014

‒ Evolución del prroyecto I+D europeo Stratosphere comenzado en 2010

‒ Apoyo de la empresa DataArtisans

Plataforma de procesamiento distribuido basadoen memoria para data-at-rest y data-in-motion.

• Motor de procesamiento batch‒ Streaming mediante micro-batching

• API sencillo para batch y streaming en múltiples lenguajes‒ Java, Scala, SQL, Python, R

• Librerías para ML y Grafos

• Integración con ecosistema Big Data ‒ Hadoop, Kafka, HBase, etc.

• Open Source‒ Liberado en 2010 y proyecto Apache desde 2013

(incubating) – 2014 (top)‒ Comenzado en 2009 por UC Berkeley‒ Apoyo de la empresa Databricks

Apache Flink Apache Spark

¿CÓMO SON?

• Arquitectura maestro-esclavo‒ Client‒ JobManager‒ TaskManager‒ TaskSlot

• Modelo workflow DAG‒ Map, Reduce, GroupBy, Join, etc.

• Stateful‒ Memoria, disco, RockDB

• Shell interactivo de Scala• Tolerancia a fallos mediante checkpoints• Optimizador del plan de ejecución ‒ Nativo, diferenciado para batch y streaming

• Control de back pressure

• Arquitectura maestro-esclavo‒ Driver‒ Cluster Manager‒ Worker Node‒ Task

• Modelo workflow DAG‒ Map, Reduce, GroupBy, Join, etc.

• Stateful‒ Memoria, externo (v2.x)

• Shell interactivo de Scala• Tolerancia a fallos mediante checkpoints• Optimizador del plan de ejecución ‒ Catalyst (v2.x). Solo para APIs de alto nivel

• Control de back pressure

Apache Flink Apache Spark

PRINCIPALES DIFERENCIAS ENTRE FLINK Y SPARK STREAMING

EVENT-AT-TIME VS MICRO-BATCHINGDiseño

Al utilizar un motor para batch, Spark tiene que simular el streaming hacienda “batches pequeños” micro-batching.

Esto provoca una latencia ya que es necesario terminar elmicro-batch de elementos antes de empezar a procesarlo. Tamaño mínimo 0,5 sg.

Flink es un motor streaming nativo por lo que procesa elemento a elemento evitando esa latencia.

GESTIÓN AVANZADA DEL TIEMPOFuncionalidad

Flink proporciona API para poder utilizar el event time o el processing time de forma sencilla. En caso de usar el event time, Flink se encarga automáticamente de gestionar los eventos desordenados (watermarks).Spark Streaming solo trabaja con processing time por lo que no puede gestionar eventos desordenados.

• Planificado event time para Structured Streaming

CODE DEMO (I)Event time (Flink) vs Processing time (Spark)

Basado en código de la comunidad Apache Flinkhttps://github.com/dataArtisans/oscon.git

MODELO DE VENTANAS AVANZADOFuncionalidad

Flink proporciona API para la gestión de los 3 tipos de ventanas permitiendo definir el tamaño e intervalo por tiempo y nº de elementos. Spark NO incluye ventanas por sesión y el tamaño de las NO se puede definir por nº de elementos. Flink incluye otros conceptos avanzados para gestión de ventanas• Triggers: permite lanzar la ejecución de una ventana sin terminar al cumplirse las

condiciones especificadas.

• Evictors: permite eliminar elementos de la ventana bajo las condicionesespecificadas.

34

VERSIONADO DE APLICACIONESFuncionalidad

Para asegurar la semántica exactly-one, la consistencia de estados, y la tolerancia a fallos, tanto Flink como Spark utilizan checkpointspara guardar snapshots de su estado.

Basado en ese mismo mecanismo Flink proporciona un API para savepoints, permitiendo hacer versionado de aplicaciones.

Una nueva aplicación Flink (v1) puede partir del savepoint de una versión anterior de la aplicación (v0). Esto se puede usar para A/B Testing, implementar Arquitecturas Kappa, hacer rollbacks de versiones, etc.

Los checkpoints de Spark Streaming no proporcionan la misma funcionalidad.

CODE DEMO (II)Savepoints (Flink) vs Checkpoints (Spark)

Basado en código de la comunidad Apache Flinkhttps://github.com/dataArtisans/oscon.git

36

ITERACIONESRendimiento

Flink tiene un API para soporte nativo de Iteraciones. Importante para algoritmos iterativos muy habituales en machine learning y graph processing:

• Iterate: se ejecuta sobre el resultado anterior (o el dataset inicial)

• Delta Iterate: se ejecutan solo sobre la información que ha cambiado

En Spark las iteraciones se tienen que programar como un bucle tradicional. Por tanto, en cada iteración se planifican y ejecutan las operaciones. Además no es posible hacer iteraciones delta.

En Flink solo hay una planificiación y se pueden usar interaciones delta. El API DeltaIterate de Flink solo es válido para batch (DataSet).

GESTIÓN DE LA MEMORIARendimiento

Flink tiene desde sus inicios su propio gestor de memoria dentro de la JVM (estilo C++). La información se se almacena serializada como arraysde bytes dentro de la JVM. La memoria se reserva/libera y usa usando una buffer interno.

• Evita lanzar excepciones de OutOfMemory.

• Reduce el Gargabe Collection

• No necesita optimizaciones

• Más robusto y mejor rendimiento

Spark comenzó el proyecto Tungsten en la v1.4 (beta), y primera oficial en v1.6. Evolución en v2.x

JVM Heap

Use

rFu

nctio

nsFl

ink

Run

time

THROUGHPUT & LATENCYRendimiento

El comportamiento de Flink es lineal, mientras que el de Spark es a escalones debido a su diseño de micro-batching.

Flink consigue menor latencia ante el mismo throughput de Spark Streaming.

Flink consigue una mejor relación troughput/latency que Spark Streaming

Flink bate a Spark Streaming en el benchmark de referencia actualmente sobre tecnologías de streaming processinghttps://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming-computation-engines-athttp://data-artisans.com/extending-the-yahoo-streaming-benchmark/

█ CONCLUSIONES

¿CUÁNDO USAR …?

• Necesidad de latencia baja

• Diseño de una arquitectura pura de streaming

• Necesidad de una lógica de ventanas complicada

• Montar una arquitectura de datos donde la parte de streaming es la principal y la batch secundaria

• Poder beneficiarse en la parte batch de las iteraciones nativas

• No hay un requisito estricto de baja latencia

• Existe ya una arquitectura de datos con Spark

• Montar una arquitectura de datos donde la parte batch es la principal y la de streaming secundaria

• La lógica de negocio se puede implementar con ventanas por tiempo

• Poder beneficiarse de las librerías de SQL y ML en la arquitectura

Apache Flink Apache Spark

COMPARACIÓN CON OTRAS TECNOLOGÍAS

Procesamiento Event-at-time Micro-batching Event-at-time Event-at-time

Gestión de estado Sí en 1.x. Externa Si. Memoria. Si. Memoria y BD embebida. Si. BD embebida.

Semántica at least onceexactly-once con Trident exactly once exactly once at least once

Ventana deslizante Sí en 1.x. Por tiempo y nº eventos Si. Por tiempo Si. Por tiempo y nº

eventos. No

Ventana no-deslizante Sí en 1.x. Por tiempo y nº eventos

Si. Por tiempo (micro-batch)

Si. Por tiempo y nº eventos. Si. Por tiempo

Ventana por sesión No No Sí No

Gestión eventos desordenados Sí en 1.x No Sí No

Latencia < segundos segundos < segundos < segundos

Rendimiento Medio-Alto Medio-Alto Alto Alto

Lenguajes Java, Scala, Ruby, Python, Javascript, Perl Scala, Java, Python, R Java, Scala, Python Java, Scala

¡GRACIAS!Rubén Casado Tejedor

ruben.casado.tejedor@accenture.com

ruben_casado

http://www.meetup.com/es-ES/Meetup-de-Apache-Flink-en-Madrid/