Dia 4.

Streamming

M.Sc. Ing. Danny Luis Huanca Sevilla

Dimensión 2: Velocidad

2
Dimensión 2: Velocidad

https://localiq.com/blog/what-happens-in-an-internet-minute/
3
Amazon
• En 2005 Amazon lanzó la tarifa plana para sus productos, en una
época en la que la gente podía pagar más por tiempos más cortos de
entrega, esto sacudió el mercado y género la necesidad de concretar
procesos más cortos.
• ¿Cuál fue el éxito de Netflix? ¿Por qué es necesario procesos cortos?
Competitividad – Reducir tiempo siempre genera competitividad
Streaming data
• ¿De que tipo de datos se habla?
• Teléfonos
• Tarjetas de crédito
• Sensores de edificios
• Maquinas
• Termostatos
• Trenes
• Buses
Streaming Data
• Vivimos en un mundo operado en el Ahora
• ¿Qué ejemplos creen de datos en streaming tienen en sus empresas?
• ¿Existe alguna necesidad a nivel ejecutivo para analizar esta data?
Ejemplos de sistemas en tiempo real
• Alguien envía un tweet y en unos momentos lo recibe en un cliente
Tweeter.
• Monitorear los vuelos para determinar en que lugar se encuentra una
persona.
Ejemplos en tiempo real
• https://es.flightaware.com/live/airport/SLCB
Ejemplos en tiempo real
• Una persona monitorea en tiempo real las acciones de una compañía para determinar la compra
de las mismas
• https://www.nasdaq.com/market-activity/stocks/amzn/real-time
Partes de un sistema en tiempo real
Diferencia entre tiempo real y streaming
• Son dos partes del
sistema en tiempo real
que se mueven a
diferentes velocidades.
• La producción y el
consumo.
Diferencia entre tiempo real y streaming
• Los clientes pueden no estar
consumiendo los datos en
tiempo real. Debido a
problemas en la red, el
diseño de la aplicación.
• Los clientes solo consumen la
data que necesitan.
• Esto se llama un sistema de
streaming en el que los datos
se ponen a disposición, en el
momento que un cliente
necesita.
Diferencia entre tiempo real y streaming
• Se generan dos procesos
que se complementan.
• La generación de los
datos y el consumo de
los mismos según la
necesidad.
• Regresando a los
ejemplos en “tiempo
real”.
Ejemplos anteriores en tiempo real
• Alguien envía un tweet y en unos momentos lo recibe en un cliente
Tweeter.
• Monitorear los vuelos para determinar en que lugar se encuentra una
persona.
• Una persona monitorea en tiempo real las acciones de una compañía
para determinar la compra de las mismas
• Se puede concluir que son sistemas en dos tiempos. Sistemas “en el
momento”.
Arquitectura
Continuando con ejemplo
Twitter:
1. Collection – Cuando un
usuario postea un tweet, es
recolectado por un servicio
de Twitter.
2. Cola de mensajes – El
Tweet va a una cola de
mensajes distribuida en
varios servidores.
Como nació streaming: Situación inicial en
una empresa

• Integración entre dos sistemas, se debe

compartir información entre los mismos.
• Fuente – destino una sola ruta
Pasan los años y se requiere mas integración
• Integración de mas sistemas, pasados los años se tiene
esta complejidad.
Mas integración
• Cada integración viene con dificultades alrededor:

• Protocolo – Como la data es transportada ( TCP, HTTP, REST, FTP, JDBC, etc)
• Formato de datos - Como los datos están separados (Binarios, CSV, JSON,
Avro, etc.)
• Esquema de datos y evolución - Como los datos están formados y pueden
cambiar.

• Cabe resaltar que la cantidad de conexiones se incrementará

Acá es donde aparece Kafka
¿Por qué Kafka?
• Distribuido
• Arquitectura Resiliente.
• Tolerante a fallos.
• Escalabilidad horizontal
• Puede escalar a 100 Servidores
• Puede escalar a millones de mensajes por segundo
• Alto rendimiento (latencia de menos de 10ms) – tiempo real
• Usado por mas de 2000 firmas, 35% de las 500 empresas mas grandes
de Fortune.
¿Por qué Kafka? Usos
• Sistemas de mensajería.
• Traqueo de actividades.
• Reunión de métricas de diferentes lugares.
• Recopilación de logs de aplicaciones.
• Procesamiento en stream
• Desacople de dependencias (de sistemas)
• Integración con Spark, Flink, Storm,
Hadoop y muchas otras tecnologías Big
Data.
Ejemplos
• Netflix, usa Kafka para aplicar recomendaciones en tiempo real.
• Uber, usa para juntar al usuario, conductor y datos del viaje en
tiempo real para calcular y pronosticar la demanda, calcular el precio
sugerido en tiempo real
• LinkedIn, usa para prevenir spam, colecciones interacciones entre
usuarios para crear mejores recomendaciones de conexión en tiempo
real.
Conceptos básicos

• Topicos
• Particiones
• Offsets
Tópico
• Tópico es un flujo particular de datos
• Similar a una tabla en una base de datos.
• Se pueden tener tantos tópicos como se quiera
• Un tópico esta identificado por un nombre
• Los tópicos se dividen en particiones (este número debe ser especificado al
momento de crear)
• Cada partición esta ordenada
• Cada mensaje en una partición contiene un id incremental llamado offset
Topico
• Tópico A
• Cada mensaje se almacena en un offset
que tiene un identificador único en la
partición pero no así en el tópico.
Servidor Bootstrap
• Todos los servidores en un cluster Kafka se denominan boostrap.
• Esto implica que es suficiente conectarse a uno para que un cliente
entienda toda la arquitectura del cluster y la ubicación de cada uno de sus
componentes a través del intercambio de metadatos.
• Cada bróker conoce acerca de los otros brokers, tópicos y particiones.
Zookeeper
• Zookeeper es el orquestador de todo el cluster.
• Administra los brokers (mantiene una lista de todos).
• Ayuda en la elección de los líderes y particiones.
• Envía notificaciones a Kafka en caso de cambios (ejemplo: nuevos
tópicos, caída de brokers, borrado de tópicos, etc… ).
• Kafka no puede funcionar sin Zookeeper.
• Por diseño opera con un número impar de servidores (3, 5, 7).
• Tiene un líder (maneja escritura) el resto de los servidores son
seguidores (manejan lecturas).
Zookeeper
Kafka inicio
• Se utilizo la versión Confluent.
• Confluent ya tiene el servidor zookeeper funcionando y configurado.
• El servidor de Kafka también se inicializa con la sentencia:
• iniciarConfluent
• Esta sentencia contiene los siguientes comandos que usa la
plataforma Confluent.

• confluent local start

• confluent local start ksql-server
Kafka – Creación de un tópico
• Kafka-topics
• Script que permite crear, borrar, describir o realizar cambios sobre los tópicos
Kafka – Creación de un tópico
• Crear un tópico
• kafka-topics --zookeeper 127.0.0.1:2181 --topic primer_topico --create --
partitions 3 --replication-factor 1
Kafka – Creación de un topico
• Listar los tópicos creados
• kafka-topics --zookeeper 127.0.0.1:2181 --list

• Describir características del tópico

• kafka-topics --zookeeper 127.0.0.1:2181 --topic primer_topico --describe
• El líder se encuentra en el bróker 0 que es el que esta corriendo.
Kafka – Creación de un tópico
• Crear otro tópico para borrarlo
• kafka-topics --zookeeper 127.0.0.1:2181 --topic segundo_topico --create --
partitions 8 --replication-factor 1
• kafka-topics --zookeeper 127.0.0.1:2181 --topic segundo_topico --describe
Borrado de Tópico
• Para borrar el tópico creado
• kafka-topics --zookeeper 127.0.0.1:2181 --topic segundo_topico --delete

• Listando de nuevo los tópicos.

Como funciona

Cada 20 Métrica de
segundos
control de
GPS
servicio

• Se tiene una flota de camiones, cada camión envía su posición GPS

• Se puede crear un tópico GPScamiones que contiene la posición de
todos los camiones cada 20 segundos (latitud y longitud)
• Se escoge crear el tópico con 3 particiones.
Como funciona

• Los offsets solo tienen significado en una partición específica.

• Ej el offset 3 en la partición 0 no representa los mismos datos que el offset 3 en la
partición 1
• El orden solo es garantizado en una sola partición, son independientes
• Los datos son mantenidos por un tiempo limitado (por defecto una
semana).
• Los datos en una partición son inmutables
Brokers
• ¿Dónde se almacenan procesas los tópicos y particiones?
• En brokers (servidores) que se colocan en clusters denominados Kafka cluster.
• Cada bróker esta identificado con su ID (entero).
• Cada bróker contiene ciertas particiones de tópicos.
• Después de conectarse a un bróker (denominado bootstrap), se esta conectado a todo el
cluster.
• Un buen número para empezar son 3 brokers, pero algunos clusters contienen mas de
100 brokers.
Brokers y topicos
• Topico A con 2 particiones
• Topico B con 3 particiones
Factor de replicación de tópicos
• Los tópicos tienen un factor de replicación que normalmente es entre 2 y 3
(3 es el mas seguro).
• De esta manera si un bróker esta abajo, otro bróker puede servir los datos.
• Ejemplo: El tópico A tiene 2 particiones y un factor de replicación de 2.
Factor de replicación de tópicos
• ¿Qué pasaría si el bróker 2 se cae?
• No se perdería la data. Ese es el objetivo.
Concepto de líder para una partición
• En cualquier momento solamente un bróker puede ser un líder para una
partición.
• Solamente el líder puede recibir y servir datos para una partición.
• Los otros brokers sincronizarán los datos.
• Por lo tanto cada partición tiene un líder y múltiples replicas.

Replica
Zookeper

Replica
Productores - ¿Quién genera los datos?
• Los productores escriben datos a los tópicos (los cuales están hechos
de particiones).
• Los productores saben automáticamente a cual bróker y partición
escribir.
• En caso un bróker falle, los productores se recuperaran
automáticamente.
Productores
Kafka- CLI, Creación de un cliente productor
• kafka-console-producer

• kafka-console-producer --broker-list 127.0.0.1:9092 --topic primer_topico

Consumidores
• Los consumidores leen datos de un tópico (identificado por su nombre).
• Los consumidores conocen de que bróker leer.
• En caso un bróker falle, los consumidores conocen como recuperarse.
• Los datos son leídos en orden dentro de cada partición.
Kafka- CLI, Creación de un consumidor
• kafka-console-consumer

• kafka-console-consumer --bootstrap-server 127.0.0.1:9092 --topic

primer_topico
Kafka- CLI – Interacción productor
consumidor
Kafka- CLI – Interacción productor
consumidor
• Productor

• Consumidor
Kafka- CLI – Interacción productor
consumidor
• Se lee desde el momento de la conexión. Ejemplo creando otro
consumidor:
Kafka- CLI – Interacción productor
consumidor
Kafka- CLI – Interacción productor
consumidor
• En caso se requiere leer desde el principio los mensajes se debe
realizar lo siguiente:
• kafka-console-consumer --bootstrap-server 127.0.0.1:9092 --topic
primer_topico --from-beginning
• Cabe resaltar que el orden es a nivel de partición.
Kafka- CLI – Interacción productor
consumidor
Grupos de Consumidores
• Los consumidores leer los datos en grupos.
• Cada consumidor en un grupo lee de particiones exclusivas.
Consumo en grupo
• La idea es crear un grupo de consumidores que comparten un
identificador creado por la opción --group al iniciar el consumidor.
• Todos los consumidores que apunten a ese grupo recibirán los
mensajes distribuidos entre ellos.
Consumo en grupo
• Crear 2 consumidores que apunten al grupo grupoBD, que
consuman del productor primer_tópico
• kafka-console-consumer --bootstrap-server 127.0.0.1:9092 --topic
primer_topico --group grupoBD
Consumo en grupo
• El consumo en un grupo se considera como si fuera de un solo consumidor. Esto
implica que si se lee desde el inicio se hace commit en los offsets para todo el grupo.
kafka-console-consumer --bootstrap-server 127.0.0.1:9092 --topic primer_topico --group
mi_segundo_grupo --from-beginning
Consumo en grupo
• ¿Qué sucede si se crea otro consumidor del mismo segundo grupo?
• kafka-console-consumer --bootstrap-server 127.0.0.1:9092 --topic primer_tópico --group
mi_segundo_grupo --from-beginning

• El segundo consumidor no lee nada ya que pertenece al mismo grupo del

anterior que ya hizo commit desde el inicio para los primeros mensajes. Si se
escriben nuevo mensajes solo se distribuirán los últimos que envié.
Consumo en grupo
Consumo en grupo
• Para listar los grupos de consumo se utiliza el siguiente script:
• kafka-consumer-groups --bootstrap-server 127.0.0.1:9092 --list

• Para listar características del grupo de consumo:

• kafka-consumer-groups --bootstrap-server 127.0.0.1:9092 --describe --group
mi_segundo_grupo
Consumo en grupo
Consumo en grupo
• Ejecutando el mismo script para el primer grupo.
• kafka-consumer-groups --bootstrap-server 127.0.0.1:9092 --describe --group
grupoBD

• Se puede apreciar que existen mensajes que todavía no fueron consumidos

por este grupo y eso se refleja en todas las particiones del tópico.
Manejo de offsets
• Resetear los offsets de tal manera que se pueda ver de nuevo todo el
tópico con un consumidor.
• kafka-consumer-groups --bootstrap-server 127.0.0.1:9092 --group grupoBI --reset-offsets --
shift-by -2 --execute --topic primer_topico