Por qué Apache Flink es mejor que Spark
-
Upload
ruben-casado-tejedor -
Category
Software
-
view
541 -
download
4
Transcript of Por qué Apache Flink es mejor que Spark
¿POR QUÉ APACHE FLINK ESMEJOR QUE SPARK?
Dr Rubén Casado Tejedor
█ 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
http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
VENTANAS
13:00 14:008:00 9:00 10:00 11:00 12:00
http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
Fijas Deslizantes1 2 3
54
Sesiones
2
431
Key 2
Key 1
Key 3
TiempoNº elementos
2 3 4
TIPOS DE VENTANAS
http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
Cuando juntamos tiempo y ventanas….
http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
TRIGGER Y WATERMARK
http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
What Where When How
Estrategia early and late firings
http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
█ 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.
32
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
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
http://www.meetup.com/es-ES/Meetup-de-Apache-Flink-en-Madrid/