Upload
ruben-casado-tejedor
View
259
Download
1
Embed Size (px)
Citation preview
Futuro de Apache Flinky su rivalidad con Spark Streaming
Dr. Rubén Casado
@ruben_casado
#3. 18 de Diciembre de 2016
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