Meetup Apache Flink en Madrid. Futuro de Apache Flink y su rivalidad con Spark Streaming

Futuro de Apache Flinky su rivalidad con Spark Streaming

Dr. Rubén Casado

@ruben_casado

#3. 18 de Diciembre de 2016

ruben.casado.tejedor@accenture.com

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

Semejanzas entreApache Flink y

Spark Streaming

¿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

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.

DIFERENCIAS ENTRE APACHE 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.

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

NOCIÓN 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

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

http://beam.incubator.apache.org/beam/capability/2016/04/03/presentation-materials.html

VENTANAS

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

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

VENTANASFuncionalidad

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.

23

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.

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

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/

EL FUTURO DE FLINKEn qué está trabajando la comunidad

Flinkv1.1+trabajos en marcha

27

Connectors

Session Windows

(Stream) SQL

Libraryenhancements

MetricSystem

Operations

Ecosystem ApplicationFeatures

Metrics &Visualization

Dynamic Scaling

Savepointcompatibility Checkpoints

to savepoints

More connectors Stream SQLWindows

Large stateMaintenance

Fine grainedrecovery

Side in-/outputsWindow DSL

BroaderAudience

Security

Cluster management

Dynamic ResourceManagement

Authentication

Queryable State

Security/Authentication

28

• Evitar accesos no autorizados a los datos

• Uso de seguridad basada en Kerberos• Kafka, ZooKeeper, HDFS, YARN, HBase, …

• Evitar tráfico de información entre procesos Flink

sin encriptar• RPC, Data Exchange, Web UI

Contribuciones dirigidas por

• Evitar que usuarios maliciosos espíen dentro de los jobsFlink

Checkpoints/Savepoints

29

• Recuperar un running job en un nuevo job• Recuperar running job en un nuevo cluster

• Compatibilidad• Flink 1.0 hizo el APIs backwards compatible• Ahora se está trabajando en hacer los savepoints

backwards compatible• Las aplicaciones se pueden mover a nuevas versiones de

Flink incluso cuando el state backend cambie v1.x v2.0v1.y

IncrementalCheckpointing• No guardar todos los estados sino la variación con el anterior• Optimización

30

Source

Flink Pipeline HDFSparaCheckpoints

chk 1 chk 2

chk 3

Dynamicscaling

31

• Ajustar el nivel de paralelismo en running jobs• Re-escalar operadores stateless es trivial• Re-escalar operacores stateful (ventanas, estados de usuario)

es complicado

time

WorkloadResources

El re-escalado debe asegurar la semántica exactly-one

Clustermanagement

32

• Serie de mejoras para interoperar de forma nativa con diferentes gestores de clusters• YARN, Mesos, Docker, Standalone, …• Aislamiento adecuado de jobs, soporte eficiente para sesiones con

múltiles jobs

• Adquisición y liberación dinámica de recursos• Uso de contenedores de diferentes tamaños

Dirigido por

Integración con Mesos realizada por

y

Queryable State• Estados internos de Flink consultablesde forma externa• Nueva funcionalidad de un sistema de streaming

• Base de Datos RT• Nueva visión arquitecturas Lambda/Kappa

33

windowassigner

trigger

allowedlateness

windowfunctiontimers

StreamSQL

34

• SQL es el lenguaje estandar para la manipulación de datos.• Parece el medio natural para abrir el streaming processing a más gente• Problema: No existe un estandar de Streaming SQL

• Al menos más allá de las operaciones básicas• Objetivo: incorporar el concepto de ventanas y semántica del tiempo

• La comunidad de Flink está trabajando con la comunidad de Apache Calcite en unapropuesta de estandard de Streaming SQL

SELECT STREAMTUMBLE_START(tStamp, INTERVAL ‘5’ HOUR) AS hour,COUNT(*) AS cnt

FROM eventsWHEREstatus = ‘received’

GROUP BYTUMBLE(tStamp, INTERVAL ‘5’ HOUR)

Cómo sabermás?• FLIP– Flink ImprovementProposals

35https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals