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.

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

10. Coche
autodirigido

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

20. 9:008:00 14:0013:0012:0011:0010:002:001:00 7:006:005:004:003:00
NOCIÓN DEL INFINITO

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….

24. TRIGGER Y WATERMARK

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

42. ¡GRACIAS!
Rubén Casado Tejedor
ruben.casado.tejedor@accenture.com
ruben_casado
http://www.meetup.com/es-ES/Meetup-de-Apache-Flink-en-Madrid/