Presentación realizada el 8/11/2019 en la tercera edición de las RETATalks que organiza regularmente el departamento técnico del grupo RETABet. Se trata de una introducción a los conceptos clave para diseñar sistemas software de alta escalabilidad para desarrolladores sin experiencia en sistemas distribuidos.
Streaming data, datos que entran por los que van saliendo
1. Streaming data
“los datos que entran por
los que van saliendo”
1
José Antonio Arroba González
Departamento técnico Grupo RETABet
joseantonio.arroba@ekasa.net
9. ¿Qué es un sistema de datos
en streaming?
9
• Sistema in-the-moment: sistema que está continuamente preparando y
devolviendo los datos que un cliente puede necesitar en un momento dado
• Ejemplo: tweets de las personas que sigo desde la ultima vez que me
conecté
• Diferente a un sistema de monitorización cardiaca o de seguridad de un
vehículo
• Diferente a un sistema de envío de video bajo demanda
10. ¿Y no podemos continuar
con el escalado vertical?
10
11. Ley de Moore
11
“Cada dos años se duplica el número de transistores
en un microprocesador”
Formulada por Gordon E. Moore en
1965, cofundador de Intel
12. Ley de Moore
12
• Constante aumento de
potencia y descenso de
precio
• Esta última década ha
necesitado la
incorporación de múltiples
núcleos para cumplirse
• Los límites de la física
impiden mantener este
ritmo
• El propio Moore anunció
en 2015 en fin de su ley
para la próxima década
13. Escalado horizontal
13
Replicar la aplicación n veces (balanceo de carga)
Ejemplo: Aplicación web replicada accesible con un balanceador de carga
15. Escalado horizontal
15
Particionar las bases de datos
• Los datos se agrupan en shards (filas o documentos independientes)
• La ubicación de cada shard deberá ser la óptima para su consulta
• Para mejorar el rendimiento y prevenir pérdida de datos los shards deberán
estar replicados
16. ACID
16
• Cada operación que modifica el estado del sistema se
realiza en el ámbito de una transacción
• Una transacción debe cumplir las propiedades ACID:
• Atomic
• Consistent
• Isolated
• Durable
• ¿Puede cumplirse dentro de un sistema distribuido?
17. Teorema CAP
17
• Formulado por Eric Brewer en el año 2000
• Tres requisitos comunes para los sistemas
distribuidos:
• Consistencia (C)
• Disponibilidad (A)
• Tolerancia a particiones (P)
• Al escalar un sistema distribuido solo
podemos mantener dos requisitos
• En la práctica solo podremos elegir entre
consistencia o disponibilidad
18. BASE
18
Las propiedades ACID para un sistema distribuido pasarán a
conocerse como BASE:
• Basically Available. Disponible siempre aunque algún
subsistema no lo esté.
• Soft state. El estado del sistema puede variar en
cualquier momento aunque no haya peticiones
• Eventually consistent. Tras cierto tiempo sin peticiones el
sistema se quedará en un estado consistente
20. Ingesta de datos
20
• Backpressure, escritura y
lectura a diferente
velocidad
• Sistema distribuido de
colas de mensajes
distribuido para evitar
este fenómeno
• Ejemplos: Apache Kafka,
RabbitMQ
C
C
C
er er a a ro er ClientsClients
pplications
roduce
essa es
c an es
oute and ilter
essa es
ueues
tore and or ard
essa es
pplications
Consume
essa es
21. Ingesta de datos
21
• Problemas en la ingesta de
datos fuera de una
transacción
• ¿Qué garantías queremos?
• At most once
• At least once
• Exactly once
22. Análisis
22
• Trabajo con datos en movimiento, no almacenados
• Ejemplos: Spark, Flink, Storm, Samza…
Streaming
manager
Application
driver
Stream processor
Stream processor
Stream processor
Datos
Datos
Datos
Datos
Stream processor
23. Análisis
23
• Basado en la ejecución continua de una query
• Ventana temporal:
• Cada cuanto tiempo se ejecuta la query
• Sobre qué datos se ejecutará
24. Análisis
24
• ¿Cómo consultar datos más allá de la
ventana de tiempo?
• Algoritmos probabilísticos:
• Número distinto de elementos: HyperLogLog
• Pertenencia a un grupo: Bloom filters
(https://llimllib.github.io/bloomfilter-tutorial/)
25. Almacenamiento
25
• Persistir los resultados de análisis o enviarlos como
nueva entrada de streaming
• ¿Cómo escribir a la velocidad de procesado? Sistemas
de mensajería de colas
• El resultado se deberá escribir en estructuras pensadas
para su posterior uso
• Soporte: Bases de datos NoSQL (MongoDB,
Elasticsearch… , ases de datos en memoria edis,
Memcached…
26. Publicación
26
• De nuevo el problema de publicar más
rápido que la velocidad de consumo
• WebSockets, comunicación bidireccional
entre cliente y servidor
• https://www.pubnub.com/developers/realtime-data-streams/twitter-
stream/
• http://meetup.github.io/stream/rsvpTicker/
27. Conclusiones
27
• Escalado horizontal total e ilimitado
• Replicar
• Decidir entre consistencia y disponibilidad
• Desacoplar elementos que se comunican
entre si a distinto ritmo
• No bloquear, responder de forma asíncrona
• Utilizar heurísticas, no resultados exactos
28. Conclusiones
28
• Las arquitecturas tradicionales siguen siendo
apropiadas para los escenarios donde se deben seguir
cumpliendo las propiedades ACID
• Los sistemas acaban siendo más complejos porque
tienen que convivir diferentes modelos de arquitecturas
29. Referencias
29
• Andrew G. Psaltis (2017). Streaming data:
Understanding the real-time pipeline. Editorial
Manning
