Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Por qué Apache Flink es mejor que Spark

2,135 views

Published on

Charla en Big Data Spain 16. Conceptos clave del streaming processing. Comparación entre Apache Flink y Spark Streaming

Published in: Software

Por qué Apache Flink es mejor que Spark

  1. 1. ¿POR QUÉ APACHE FLINK ES MEJOR QUE SPARK? Dr Rubén Casado Tejedor
  2. 2. █ BIG DATA Y STREAMING PROCESSING █ CONCEPTOS CLAVE EN FAST DATA █ DIFERENCIAS ENTRE FLINK Y SPARK ‒ Code demo █ CONCLUSIONES
  3. 3. █ BIG DATA Y STREAMING PROCESSING
  4. 4. VOLUMEN Grandes cantidades de datos. Necesidad de soluciones tecnológica y económicamente escalables. VARIEDAD Información estructurada, semi y desestructurada. Necesidad de almacenar y procesar distintos tipos de información. VELOCIDAD Alta frecuencia de generación de información. Necesidad de producir resultados en tiempo real.
  5. 5. STREAMING PROCESSING es el paradigma de procesamiento para STORM VELOCIDAD APACHE FLINK
  6. 6. STREAMING PROCESSING Analizar según sucede
  7. 7. Plataforma tradicional de BI Plataforma Big Data batch processing Analytical Database Data as a platform Data Ingest Data Collection
  8. 8. Coche autodirigido
  9. 9. Waze
  10. 10. ¿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 vidas humanas, 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 fallo del sistema
  11. 11. ARQUITECTURA GENERAL STREAMING PROCESSING SYSTEM CAPA DE ADQUISICIÓN COLA DE MENSAJES CAPA DE PROCESAMIENTO ALMACENAMIENTO EN MEMORIA CAPA DE ACCESO ALMACENAMIENTO LARGA DURACIÓN ORIGEN
  12. 12. 2009 UC Berkeley empieza a trabajar en Spark 2010 Yahoo! crea S4 2010 Cloudera crea Flume 2011 NathanMarzcrea Storm 2014 Stratosphere evoluciona a Apache Flink 2013 Se publica Spark v0.7 con la primera version de Spark Streaming 2013 Linkedin presenta Samza 2012 LinkedIn desarrolla Kafka 2015 Ebay libera Pulsar 2015 DataTorrent libera como incubator Apache Apex 2016 Se publica Apache Storm v1.0 con grandes cambios 2016 Google promueve Apache Beam con el apoyo de DataArtisans y Cloudera 2016 Se publica Apache Spark 2.0 con notables cambios
  13. 13. █ CONCEPTOS CLAVE EN FAST DATA
  14. 14. 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.
  15. 15. NOCIÓN DEL TIEMPO ProcessingTime Event Time Skew
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. Fijas Deslizantes 1 2 3 54 Sesiones 2 431 Key 2 Key 1 Key 3 Tiempo Nº elementos 2 3 4 TIPOS DE VENTANAS http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
  20. 20. Cuando juntamos tiempo y ventanas…. http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
  21. 21. TRIGGER Y WATERMARK http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
  22. 22. Estrategia early and late firings http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html
  23. 23. █ DIFERENCIAS ENTRE FLINK Y SPARK ‒ Code demo
  24. 24. ¿QUÉ SON? Plataforma de procesamiento distribuido basado en 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 basado en 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
  25. 25. ¿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
  26. 26. PRINCIPALES DIFERENCIAS ENTRE FLINK Y SPARK STREAMING
  27. 27. EVENT-AT-TIME VS MICRO-BATCHING Diseñ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 el micro-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.
  28. 28. GESTIÓN AVANZADA DEL TIEMPO Funcionalidad 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
  29. 29. CODE DEMO (I) Event time (Flink) vs Processing time (Spark) Basado en código de la comunidad Apache Flink https://github.com/dataArtisans/oscon.git
  30. 30. MODELO DE VENTANAS AVANZADO Funcionalidad 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 condiciones especificadas.
  31. 31. 3 2 VERSIONADO DE APLICACIONES Funcionalidad Para asegurar la semántica exactly-one, la consistencia de estados, y la tolerancia a fallos, tanto Flink como Spark utilizan checkpoints para 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.
  32. 32. CODE DEMO (II) Savepoints (Flink) vs Checkpoints (Spark) Basado en código de la comunidad Apache Flink https://github.com/dataArtisans/oscon.git
  33. 33. ITERACIONES Rendimiento 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).
  34. 34. GESTIÓN DE LA MEMORIA Rendimiento Flink tiene desde sus inicios su propio gestor de memoria dentro de la JVM (estilo C++). La información se se almacena serializada como arrays de 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 User FunctionsFlinkRuntime
  35. 35. THROUGHPUT & LATENCY Rendimiento 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 processing https://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming- computation-engines-at http://data-artisans.com/extending-the-yahoo-streaming-benchmark/
  36. 36. █ CONCLUSIONES
  37. 37. ¿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
  38. 38. 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 once exactly-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
  39. 39. ¡GRACIAS! Rubén Casado Tejedor ruben.casado.tejedor@accenture.com ruben_casado http://www.meetup.com/es-ES/Meetup-de-Apache-Flink-en-Madrid/

×