Why Apache Flink is better than Spark by Rubén Casado
2 recomendaciones1,532 vistas
El documento compara Apache Flink y Apache Spark en términos de procesamiento de datos en tiempo real y eficiencia. Flink se destaca por su latencia baja, capacidad de manejar eventos desordenados y soporte nativo para iteraciones, mientras que Spark utiliza un enfoque de micro-batching que introduce latencias y limitaciones en la gestión de ventanas. Se concluye que Flink es preferible para arquitecturas centradas en streaming y situaciones que requieren procesamiento en tiempo real.
Why Apache Flink is better than Spark by Rubén Casado
- 2. ¿POR QUÉ APACHE FLINK ES MEJOR QUE SPARK? Dr Rubén Casado Tejedor
- 3. • 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
- 4. █ BIG DATA Y STREAMING PROCESSING █ CONCEPTOS CLAVE EN FAST DATA █ DIFERENCIAS ENTRE FLINK Y SPARK ‒ Code demo █ CONCLUSIONES
- 5. █ BIG DATA Y STREAMING PROCESSING
- 6. 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.
- 7. STREAMING PROCESSING es el paradigma de procesamiento para STORM VELOCIDAD APACHE FLINK
- 8. STREAMING PROCESSING Analizar según sucede
- 9. Plataforma tradicional de BI Plataforma Big Data batch processing Analytical Database Data as a platform Data Ingest Data Collection
- 11. Waze
- 13. ¿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
- 14. 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
- 15. 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
- 16. █ CONCEPTOS CLAVE EN FAST DATA
- 17. 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.
- 18. NOCIÓN DEL TIEMPO ProcessingTime Event Time Skew
- 19. 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
- 21. VENTANAS 13:00 14:008:00 9:00 10:00 11:00 12:00
- 22. Fijas Deslizantes 1 2 3 54 Sesiones 2 431 Key 2 Key 1 Key 3 Tiempo Nº elementos 2 3 4 TIPOS DE VENTANAS
- 23. Cuando juntamos tiempo y ventanas….
- 25. Estrategia early and late firings
- 26. █ DIFERENCIAS ENTRE FLINK Y SPARK ‒ Code demo
- 27. ¿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
- 28. ¿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
- 29. PRINCIPALES DIFERENCIAS ENTRE FLINK Y SPARK STREAMING
- 30. 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.
- 31. 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
- 32. 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
- 33. 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.
- 34. 3 4 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.
- 35. CODE DEMO (II) Savepoints (Flink) vs Checkpoints (Spark) Basado en código de la comunidad Apache Flink https://github.com/dataArtisans/oscon.git
- 36. 3 6 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).
- 37. 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
- 38. 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/
- 39. █ CONCLUSIONES
- 40. ¿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
- 41. 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