Meetup En mi local funciona - Mi primer diseño con Apache Kafka

Agenda :
• Inauguración del Meetup de En Mi Local Funciona Barcelona
• Mi primer diseño con Apache Kafka
• Cervezas y picoteo.

Comenzamos el blog en 2016
Y poco a poco hemos ido creciendo:

Gracias a todos los que lo habéis hecho posible
Más de 90 posts de más de 50 compañeros

Mi primer diseño con
Apache Kafka

Índice
1. Introducción
2. Patrón “Publish / Subscribe Messaging”
3. Apache Kafka
3.1. Conceptos Básicos
4. Preguntas

¿Con qué estoy trabajando?
• Conjunto discreto de valores que
verifica las propiedades : completitud, precisión,
consistencia (evitar contradicciones), unicidad y
temporalidad
• Inicialmente NO ayudan a la toma de
decisiones
• Factor Diferencial
Datos
• Conjunto de datos procesados que tienen un
significado dentro de un contexto y que
tiene utilidad a la hora de tomar decisiones
Información
• Conjunto de información cuyo valor
depende de experiencia y otros
factores
Conocimiento
El problema del…
Activo
Estratégico
Ventaja
Empresarial
¿es un identificador?
¿es algún tipo de tipología?
¿es una cantidad de algo?
….
Poder
Muchos Procesos
de Obtención

La “complejidad” de la aplicaciones …
La complejidad de las aplicaciones actuales se han incrementado enormemente
Orientaciones (Tradicional, SOA, Microservicios, API Manager), Batch, Cloud , Integraciones, Mobile, IoT, …
Número Heterogeneidad Composición Distribuidas
Multi-tiered
Multi –
tecnologías
Multi - vendors
Especialización
JAVA / .NET /
NODE
Complejidad
Código
Stakeholders …

Cualquier aplicación implica crear datos
• Voluntaria o involuntariamente en algún momento de su vida
• En un formato genérico o específico
• Sobre algún sistema de almacenamiento
• Que aporte el valor necesario a la funcionalidad que cubre
• Con un dominio/explotación interno o externo
• Aparecen los flujos complejos de datos
Obtener Manipular Analizar
Generar
salida
Mover

Problemas del Mundo Síncrono
Tiempos de respuesta lentos
Sobrecarga del servicio
“Rotura” del servicio
Cambio de interfaz
Respuestas NO Estándares
Conversiones intermedias
Sobrecarga de Batchs
…
Malos Enfoques
generan
Problemas
Request-Driven
(Imperativo)
Petición-Respuesta
Periodo de
“aceptabilidad”
Acoplamiento
point-to-point
Muchas
integraciones
Tiempo de
Procesamiento
Infraestructura
Comunicaciones
Uso “Online” en
vez de “Offline”
Canal Inadecuado …

Event Store
Enfoque Event-Driven con Microservicios y API Gateway
Plataforma Microservicios
Microservicio Objeto 1
API
Objeto 1
Lógica
Objeto 1
DB
Objeto 1
REST
Microservicio Objeto n
API
Objeto n
Lógica
Objeto n
DB
Objeto n
REST
Comunicaciones
Ejemplo Aplicación 1
Lógica
Ap 1
Interfaz
Ap 1
Lógica
Ap 2
Interfaz
Ap 2
Lógica
Ap 3
Interfaz
Ap 3
API
Manager
Externa
Gateway
Queue 1
Queue n

Event Store
Enfoque Streaming Processing
Comunicaciones
Queue 1
Queue n
Modelos de Streaming
• Event-at-a-time
• Micro Batch / Windowing
• Fixed : nº de unidades en la venta o por tiempo
• Sliding : intervalos de longitud
• Session : secuencia e eventos temporalmente relacionados
• Técnicas de joining
Sensor Data IoT Data
Fuentes Streams
Social Localización
Mobile Click Stream
Telemetría
Comunicaciones
Análisis Resultado
Plataforma Streams
Modelos Dashboard
Search BI
Comunicaciones
Stream = Flujo de datos
• “Una vez que se envía un dato éste no se va a volver a enviar nunca”
• “Los Streams nunca terminan”

Plataforma Stream
Data
Event Store
Enfoque CDC (Change Data Capture)
Queue 1
Queue n
Análisis Resultado
Plataforma Streams
Fuentes de Datos
DB
Objeto 1
DB
Objeto 2
DB
Objeto n
Comunicaciones
Ficheros Extractos
DB
Modelos Dashboard
Search BI
Almacenamiento Proc. Paralel
Plataforma Big Data
Resultados Warehouse
Comunicaciones
Comunicaciones
Sensor Data IoT Data
Fuentes Streams
Social Localización
Mobile Click Stream
Telemetría
Comunicaciones
Comunicaciones
Comunicaciones
DB Triggers
Change Tracking
DB Transaction Log
Scaning

2. Patrón “Publish/Subscribe
Messaging”

¿Qué es Publish/Subscribe Messaging?
Patrón de comunicaciones entre aplicaciones usado dentro de las arquitecturas basadas en colas de mensajes (orientación a
la integración / SOA nacida en los años 90) que puede tener diferentes tipos de configuraciones
• También se denomina "publish / subscribe", "publicador / suscriptor" o "productor / consumidor“ -> Pub/Sub
• Pertenece a los Messaging Patterns
Orientado al movimiento de información “asíncrono” -> Puede incluir aspectos de preparación y modificación
Partes :
• Publisher : Actor / componente encargado de generar un mensaje/dato
• Subscriber : Actor / componente encargado de consumir un mensaje / dato
• Topic : Componente o canal donde se deposita y desde donde es consumido el mensaje/dato
Funcionamiento :
• El publisher NO lo envía de forma directa a la dirección subscriptor (NO es point-to-point)
• Se dispone de una lista topics disponibles y específicos, el publisher clasifica el mensaje en base a una tipología, lo pone sobre un topic
específico y el subscriptor se registra en cada uno de los topics para recibir los mensajes de ese tipo

Patrones EIP (Enterprise Integration Patterns)
Patrones de mensajería (Messaging patterns) son un subtipo de patrones de EIP cuyo foco es el mensaje
• 65 patrones documentados -> Normalmente se usa la combinación de varios
• https://www.enterpriseintegrationpatterns.com/patterns/messaging/

Tipos de configuración Publish/Subscribe Messaging
Tradicional
•Cada subscriber esta asociado a uno o varios topics en concreto
•Diferentes enfoques :
•Cada subscriber está escuchando 1 topic propio
•Cada subscriber está escuchando X topics
•Cada subscriber está escuchando X topics independientes y Z topics
compartidos
Grupo de consumo
•Los subscribers se pueden agrupar en una unidad (grupo con id), este grupo
esta escuchando un topic y sólo un miembro tendrá la capacidad de atender el
mensaje
Radio Difusión
•Todos los subscriber que están escuchando el topic reciben el mensaje
•Cada susbcriber es responsable de interpretar el mensaje de forma
independiente

Consideraciones Importantes
Disponibilidad (Availability)
• Capacidad de estar el mayor tiempo posible
trabajando / activo
• Tener en cuenta : mantenimiento y errores
(detección + reparación)
Escalabilidad (Scalability)
• Capacidad de evolución en un aspecto con el
objetivo de dar soporte a una mayor cantidad de
acciones o elementos
• Dimensiones : mensajes, topics, productores o
consumidores
Enrutamiento Lógico (Routing Logic)
• Capacidad por la que un dato sale d un productor y
llega a un consumidor en base a una lógica de
negocio
• Enfoque 1 “Topic” : Los datos se clasifican por topics
y los subscribers sólo reciben datos relacionados con
los topics
• Enfoque 2 “Contenido” : Los datos se clasifican en
base a una o varias propiedades y los subscriber
pueden establecer filtros y restricciones específicas
sobre un grupo de datos
Desacoplamiento (Decoupling)
• Entidad (Entity) : Los elementos NO necesitan
conocerse entre si
• Tiempo (Time) : Los elementos NO necesitan
participar activamente
• Sincronización (Synchronization) : Si los hilos de
ejecución o los elementos requieren algún tipo de
bloqueo síncrono
Rendimiento (Throughput)
• Capacidad relacionada con la medida de la eficiencia
en lo referente a la cantidad de elementos por
unidad de tiempo con la que trabajar -> nº de bytes
• En algunos casos se llama ancho de banda
(bandwith)
Latencia (Latency)
• Capacidad relacionada con la medida de la eficiencia
en lo referente al pipeline requerido para su
procesamiento -> tiempo requerido para su
procesamiento (tiempo respuesta)
Transaccionalidad (Transaction)
• Capacidad para agrupar acciones o elementos en unidades
atómicas
• “O se ejecutan todas como una única operación o bien no
se ejecuta ninguna”
Precisión (Correctness)
• Combinación de estrategias : duplicidad + ordenación +
perdida de datos
• Estrategias de Entrega
• “como máximo una vez” (at most once) [0|1] :
Sólo se envía una vez, garantiza que no hay
duplicados pero puede perderse
• “al menos una vez” (at least once) [1+] : Garantiza
que no hay perdida pero puede haber duplicidad
• “exactamente una vez” (exactly once) [1] :
Garantiza que no hay duplicados y que tampoco hay
perdidas
• Estrategias de Ordenación
• No hay ordenación (no ordering) : No importa el
orden de recepción -> incrementar el rendimiento
• Ordenación por partición (partitioned ordering) :
Asegura el orden por partición y tiene un coste extra
• Ordenación Global (Global order) : Mayor coste
extra y afecta al rendimiento

¿Y que pasa con la eficiencia?
Latencia
Rendimiento
Alta
Alta
Baja
Tamaño del
Trabajo
El tamaño del mensaje (límite) vendrá dato por el caso de uso : limite de un mensaje o bien cantidad de elementos que
componen el mensaje -> normalmente se mide en bytes

No existe un zapato para todos
Siempre existe una gran variedad de casos de uso y quizás NO puedas reutilizar cosas

Plataforma de sistema de mensajes / streaming Open Source utilizada por la nueva generación de aplicaciones distribuidas
• Origen : Herramienta de “apoyo” en LinkedIn (2010) pero posteriormente se cedió a Apache Community (2011)
• Mejora la forma de trabajo con datos en las aplicaciones a la hora de realizar comunicaciones y/o procesamiento
• Escrita en Java y Scala
Enfoques con los que trabaja :
• Bus de mensajes
• Publish/Subscribe
• Pull-based
• Commit log
Destaca :
• Orientación a Big Data pero también destaca en otros ámbitos : comunicación de aplicaciones, ejecución de procesos batch
• Alternativa a aplicaciones como : JMS, AMQP y RabbitMQ -> Cuando se manejan grandes cantidades de datos y se requiere gran
capacidad de respuesta
• Facilita el trabajo con otras tecnologías como : Flume/Flafka, Spark, Storm, etc
• Dispone de ciertos APIs para su uso : Producer, Consumer, Streams, Connector, etc.
¿Qué es Apache Kafka?
• Grupos de Consumo
• Conectores
• Enrutamiento Simple
• Clientes Ligeros
Necesidad Componente
Almacenamiento Kafka Core
• Básico
• Producer API
• Consumer API
Integración Kafka Connect
Procesamiento Kafka Streams

¿Qué es un Commit Log?
Estructura de datos ordenada y persistente
• Similar a un Ledger (Libro Mayor o registro)
• Representa “la verdad de lo que ocurre” -> log
• CON / SIN distribución
• Los datos pueden ser cualquier cosa -> array bytes
Proporciona un procesamiento determinista
Capacidad de construir el estado de un sistema de forma consistente
Funcionamiento
• Sólo se permite añadir por el final -> Anexar
• NO se pueden modificar ni borrar registros
• Funcionamientos con “punteros de localización”
• Puede tener diferentes lecturas
• Se pueden invalidar registros según algún criterio
Problemática de la ordenación cuando hay distribución
“append-only”
0 1 2 3 4 5 6
New
7
Old
WriteRead 1 Read 2

¿En que se parece Apache Kafka a un Documento de Texto?
“Hay que rellenar
el parte semanal
de actividad”
usa
• Creamos un documento
• Tratamos que no sea
“temp”
• Dividimos en secciones
• Actualizamos durante el
día
Desarrollador Editor Texto
genera
*** Lunes 1 ***
8:00 - 10:30 Trabajo sencillo (2,5h)
10:30 - 14:00 Trabajo muy duro (3,5h)
*** Martes 2 ***
8:00 – 12:00 Reunión Cliente (4h)
12:30 – 15:30 Trabajo muy duro (3h)
…
Documento “Registro Horas”
• No tiene una estructura fija
• Se guarda hasta que se usa o
bien sirve “comodín jurídico”
• Persistencia Local
Problemas :
• Backup
• Redundancia a fallos (por
ejemplo hacer un “Víctor”)
• Acceso
particionar
*** Lunes 1 ***
*** Martes 2 ***
…
Segmentos “Registro Horas”
• División del documento original
a segmentos lógicos en base a
un valor clave
Problemas :
• Backup
• Redundancia a fallos (por
ejemplo hacer un “Víctor”)
• Acceso solo al mismo
distribuir
*** Lunes 1 ***
*** Martes 2 ***
…
Segmentos “Registro Horas”
• Separación en su ubicación
(servidor /disco duro)
• Replicar las particiones en el
resto de ubicaciones
Problemas :
• Complejidad
M
L
X J V
X J V
Sistema de registro masivo de mensajes por tipo, distribuido, escalable y tolerante a fallos ☺

Características Apache Kafka 1/2
Alto Rendimiento
•Poca latencia
•Enfoque “Zero Copy”
•Escritura secuencial en disco
•No acceso aleatorio a datos
•Trabajo en lotes
•Alta velocidad
•Volumen alto de datos
Distribuido
•División en nodos
•Ejecución en clúster
•Visión de usuario como un
único nodo
•Proporciona “Escalado”
•Proporciona “tolerancia a
fallos”
Escalado horizontal
•Fácil escalado
•Poco tiempo
•No tiempos de inactividad
•No existen “límites”
•Sharding
•Varias dimensiones
Durabilidad/Persistencia
•Persistencia en el sistema de
ficheros (Por defecto)
•Replicación del clúster
•Criterios de invalidación
Tolerancia a fallos
•No tiene un único punto de
fallo bloqueante al replicar las
particiones en varios nodos
•> Tolerancia -> < rendimiento
Replicación
• Uso de los nodos
• Alta disponibilidad
• Recuperación
inmediata
Políglota
• Comunicaciones
basadas en TCP
• Varias
implementaciones en
diferentes lenguajes
Retro Compatible
• Correcto
funcionamiento con
versiones anteriores

Características Apache Kafka 2/2
Integrabilidad
•Ecosistema que proporciona un
proxy REST
•Integración HTTP y JSON
Soporte Avro/Schema
•Facilita la gestión de esquemas
Seguridad
• Soporte : SSL, SASL (PLAINTEXT y
SCRAM), GSSAPI (Kerberos), ACL, etc
• Autenticación de conexiones de
brokers con Zookeeper (fichero JAAS)
• Crifrado de datos entre brokers y
clientes / herramientas / productores
/ consumidores (con soporte SSL)
• El cifrado es sólo en vuelo
Instalación
•Facilidad a la hora de instalar
•Facilidad a la hora de configurar
Variado
•Ejecución en una JVM
•Proporciona pack de herramientas para
su gestión
•Proporciona KSQL
•Replicación de clústers
•Migrar bróker entre versiones
•Solución Hosted
•Documentación, recursos, etc.
•…
Aspectos a tener en cuenta :
• Extra de mantenimiento si sus componentes se diseñan/implementa de forma descontrolada
• Mal enfoque: uso inadecuado de diseños/planteamientos sin patrones, sin arquitectura, falta de ritmo, problemas
en la descompresión de mensajes, nº de topics se incrementa, etc.-> problemas de rendimiento
• No hay selección “*” / comodin : No permite el envío de mensajes a todos los topics
• Monitorización : Las herramientas no son muy buenas : Burrow, KafkaOffsetMonitor, Grafana, etc.
• Ajustes de mensajes : muchos ajustes repercuten (empeoran) en el rendimiento
• Complejidad
• …

Casos de uso de Apache Kafka
Arquitecturas Streaming de
datos en tiempo real
(Stream Processing)
Envío / Intercambio /
Transformación de
información
(Messaging, Pub/Sub, Data
Integration y ETL)
Manejo de flujos de datos
grandes (logs, tracking
actividades, métricas, etc)
(Data Pipelines y Log
Aggregation)
Procesamiento de eventos
complejos (CEP)
(Event Sourcing)
Uso de “cache”
persistencia
(Storage)
“Durabilidad” en
microservicios in-memory”
(Storage)
…

3.1. Conceptos Básicos
3. Apache Kafka

Práctica 1 : Instalar la Plataforma Apache Kafka “Core”
PASOS :
• Verificar que se tiene instalada la versión de Java : 8
• Descargar Apache Kafka desde la página :
https://kafka.apache.org/downloads
• Extraer en un directorio de instalación
(KAFKA_HOME)
• Por ejemplo :
C:Softwareapache-kafkakafka_2.11-1.1.1
• Hacer 2 copias (para disponer de 2 clúster diferentes
para pruebas) en local
• Añadir algún elemento diferencial al nombre del
directorio de cada clúster (por ejemplo : un sufijo, etc.)
• Por ejemplo :
%KAFKA_HOME%kafka_2.11-1.1.1-cluster_1
%KAFKA_HOME%kafka_2.11-1.1.1-cluster_2
Aspectos a tener en cuenta :
• Entorno Unix : Todos los ejecutables .sh se encuentran bajo el directorio %KAFKA_HOME%<cluster>bin
• Entorno Windows : Todos los ejecutables .bat se encuentran bajo el directorio %KAFKA_HOME%<cluster>binwindows

Zookeeper Broker Clúster Mensaje Esquema
Topic /
Tema
Partición Offset Productor Consumidor
Grupo de
consumidore
s
Connect /
Connector
Streams
Conceptos Apache Kafka
Lo veremos
No lo veremos

Zookeeper
Software que proporciona una servicio centralizado de coordinación para aplicaciones
distribuidas (https://zookeeper.apache.org/)
• Manager/gestor del clúster (coordina la topología de los brokers / clúster)
• Almacén Clave-Valor distribuido con los aspectos de control de la plataforma
Características :
• Lo usan muchas compañías (Netflix, LinkedIn,…) y muchos proyectos (Kafka, Storm, Hbase,…)
• Proporciona : gestión de la configuración, registro de cambios, servicio de descubrimiento, naming,
sincronización, locking, etc.
• Intercambia metadatos con : brokers, productores y consumidores
• Direcciones con brokers, offsets de los mensajes consumidos, detección carga de trabajo, etc.
Funcionamiento :
• Seleccionar la partición leader de un topic entre los brokers
• Seleccionar broker leader donde se almacenará la partición leader
• Tupla liderazgo (broker, partición del topic)
• Seleccionar un controlador del clúster / grupo de brokers
• Responsable de las operaciones administrativas, particiones, monitorización de fallos, etc.
• Ante un fallo se selecciona otro broker
Nodos Contexto
1 No permite fallos
3 Permite el fallo de un nodo
5 Permite el fallo de dos nodos
2n+1 …
“Se entera de todo”

Práctica 2 : Configuración/Ejecución del Zookeeper
PASOS DE CONFIGURACION DE ZOOKEEPER EN “*-cluster_1” :
• Editar el fichero de configuración :
• %KAFKA_HOME%kafka_2.11-1.1.1-cluster_1configzookeeper.properties
Propiedad Valor
clientPort 2181 (Valor por defecto)
dataDir C:/Software/apache-kafka/kafka_2.11-1.1.1-cluster_1/zookeeper
PASOS DE EJECUCION DE ZOOKEEPER “*-cluster_1” :
• Ubicarse en la siguiente localización por consola :
• %KAFKA_HOME%kafka_2.11-1.1.1-cluster_1 binwindows
• Ejecutar el siguiente comando por consola
• zookeeper-server-start.bat ....configzookeeper.properties
• Requiere pasar el parámetro del fichero de configuración
• Verificar por consola el estado del arranque
• Opcional : Verificar la creación del directorio “dataDir”

Broker y Clúster
Instancia/nodo/servidor de Kafka -> 1 o N Brokers (Message Broker)
• Topología de almacenamiento
• Mediador de las comunicaciones para la entrega de los mensajes
Características :
• Contiene la/s partición/es de uno o varios topic/s
• Cada broker tiene un tipo de partición de un topic : leader o replica
• Sólo un broker del clúster puede tener la partición leader , el resto son replicas
• Comunicación frecuente con el Zookeeper
• Cada uno tiene un rendimiento específico -> HW + configuración
• Tiene ID -> Requiere configuración
• Se aconseja su ejecución en máquinas independientes
Escritura
•El broker con la partición leader del topic recibe las peticiones
de escritura de los mensajes de los productores
• Determina offset a utilizar
• Confirma/commit los mensajes en el almacenamiento
• Solicita la actualización de las réplicas
Lectura
• El broker con la partición leader del topic recibe las peticiones
de lectura de los mensajes de los consumidores
• Determina el offset definido para ese consumidor
Fallos
• Si el broker con la partición leader del topic se cae realizando
alguna operativa, se le asignará otro broker y su partición
replica se convertirá en leader debido al ISR (In-Sync Replica)
Funcionamiento :
Clúster : Agrupación de 1 o N Brokers + Zookeeper
• Se pueden tener múltiples clúster (ayuda a segregar
datos, establecer requisitos, recuperación desastres, etc.)
• Mayor tolerancia a fallos -> configurar un clúster con un
mayor factor de replicación
• Usar “Mirror Maker” -> recuperación de desastres

Zookeeper
Broker 0 Broker 1 Broker 2 Broker XBroker X-1
Kafka Cluster

Práctica 3 : Configuración de los Brokers
PASOS DE CONFIGURACION DE LOS DIFERENTES BROKERS (4 Brokers)
• Editar cada uno de los ficheros de configuración anteriores
PASOS PREVIOS (SINGLE NODE – MULTIPLE BROKERS) :
• Crear un directorio de “logs” asociado al clúster “-cluster_1”
• Por ejemplo : %KAFKA_HOME%kafka_2.11-1.1.1-cluster_1logs
• Crear 4 copias del fichero de configuración : %KAFKA_HOME%/<CLUSTER>/config/server.properties
• Cada una se corresponderá con la configuración de un bróker
• Añadir algún elemento diferencial al nombre del fichero de configuración (por ejemplo : un sufijo, etc)
• Por ejemplo : %KAFKA_HOME%kafka_2.11-1.1.1-cluster_1configserver-0.properties
%KAFKA_HOME%kafka_2.11-1.1.1-cluster_1configserver-1.properties
Propiedad Valor
broker.id Poner valor del elemento diferencial (valor entero)
listeners Descomentar y cambiar la referencia
Ayuda poner el valor del puerto en referente al id anterior
log.dirs C:/Software/apache-kafka/kafka_2.11-1.1.1-cluster_1/logs/broker_X
zookeeper.connect localhost:2181,localhost:2182

Práctica 4 : Ejecución de los Brokers
PASOS DE CONFIGURACION DE LOS DIFERENTES BROKERS (4 Brokers)
• Ejecutar el siguiente comando por consola para cada broker
• kafka-server-start.bat ....configserver-X.properties
• Requiere pasar el parámetro del fichero de configuración
• Opcional : Verificar la creación de contenido directorio “logs”

Mensaje y/o Esquema
Unidad de datos/comunicaciones con las que trabaja Kafka
• Array de bytes -> Serialización / Deserialización
• Par (Clave[opcional],Valor) + timestamp
• “Registro” / “Record” / “Message”
Características :
• No tiene una estructura, formato o significado específico para Kafka -
• Se pueden usar esquemas : JSON, XML y/o Apache Avro
• Ser persiste dentro de un partición de un topic
• Tiene un tamaño máximo -> Se puede comprimir
• Bit Opcional de medatados que se denomina “clave”/key -> Facilita establecer
criterios de asignación de partición (por defecto reparto equitativo)
• Agrupación en batches / lotes -> Mejor rendimiento
• Estados :
• Confirmado : Cuando todas las particiones ISR (In-Sync Replica) tiene escrito
el mensaje en su log
• No confirmado : Cuando al menos una partición ISR NO tiene escrito el
mensaje en su log

Categoría o criterio con el que se pueden agrupar/clasificar los mensajes en Kafka
• Colección de mensajes conforman un topic
• Stream de un tipo de datos
• “Contenedor" de mensajes
Características :
• Pueden existir 1 o más topics -> No hay limitación
• Se almacenan en logs (ficheros)
• Cada topic tiene una configuración específica -> una estructura independiente dentro de Kafka (Zookeeper)
• Almacena de forma permanente los mensajes a menos que se establezca algún criterio de retención -> permite el trabajo asíncrono y no
en tiempo real (no pierde datos)
• Se utiliza para la escritura y lectura de los mensajes
• Kafka dispone de una herramienta específica para su gestión
Funcionamiento :
• Requiere configuración
• Se identifica por nombre
Topic / Tema
Productor
Topic
Consumidor
1 0..NEscritura Lecturaappend-only
Configuración Descripción
Id “Nombre” de identificación de forma única
Nº de
Particiones
Cantidad de fragmentos de división del “topic log”
Nota : Depende de la cantidad de brokers
Factor de
replicación
Nº de replicaciones/copias de las particiones que se mantendrán
Nota : nº <= nº de brokers (al menos 2 para resolver el fallo de AZ)
Criterio de
retención
Reglas para invalidar los mensajes de un topic -> “caducidad”
Tipos : nunca, tiempo, tamaño y compactación
• Compactación : sólo conserva el último mensaje con una clave específica
Topic Log
Particion 1..N

Partición
Secuencia de mensajes ordenada e inmutable
• Cada uno de los partes en las que se puede fragmentar/dividir el "Topic Log" de un topic
• Unidad de replicación de un topic
Características :
• Cada partición se puede encontrar en uno o varios brokers diferentes -> Replicación
• [1] broker con partición leader + [0-n] brokers con particiones followers/"replica“
• El broker leader controla todas las peticiones de lectura y escritura sobre una partición del topic
• Los brokers followers replican a los leaders y toman el control si el leader establecido "muere“
• Al grupo de particiones réplicas sincronizadas se las llama ISR (In-Sync Replicas)
• Facilita la redundancia, escalabilidad y fragmentar las lecturas y escrituras en el log del topic -> mayor velocidad
• "append-only" para cada una de las particiones de forma independiente
• Las particiones permiten la manipulación "paralela" de los consumidores dentro de uno o varios grupos al mismo
Funcionamiento :
• Escritura en la partición leader asignada mediante su offset -> Normalmente hay balanceo de carga pero se puede cambiar
• Problema ordenación : Con una partición se mantiene y cuando hay varias la ordenación es por partición
Topic Log
división
“append-only”
Partición-1
“append-only”
Partición-2
“append-only”
Partición-n
“append-only”
…

Offset
Identificador único de cada mensaje en base a su ubicación dentro de una partición
• Bit de metadatos que se corresponde con un valor entero incremental / secuencia
• La posición del consumidor en el topic log o en una de sus particiones
• “Desplazamiento" o "compensación"
Características :
• Kafka guarda su información en un topic llamado "_consumer_offset"
• Tipología:
• "Log end offset" (offset de fin de registro) : offset del último registro escrito en la partición y donde los productores escribirán a
continuación el siguiente mensaje
• "High Watermark" : offset del último registro que se replico con éxito en todos las particiones followers réplicas
Partition 0 0 1 2 3 4 5 6
Topic “TEST”
Old
New
7

Práctica 5 : Creación de Topics
PASOS DE CREACION DEL TOPICS :
• Ejecutar el siguiente comando por consola
Ejemplo 1 : un topic con nombre “example1” SIN Replicación y SIN Distribución
kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic example1
Ejemplo 2 : un topic con nombre “example2” CON Replicación (1 backup) y SIN Distribución
kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 2 --partitions 1 --topic example2
Ejemplo 3 : un topic con nombre “example3” CON Replicación (2 backups) y CON Distribución (10 fragmentos)
kafka-topics.bat –create –zookeeper localhost:2181 –replication-factor 3 –partitions 10 –topic example3
• Opcional : Verificar la creación del topic y su detalle
Recordatorio de Gestion de Topics con la herramienta : kafka-topics
• LISTADO kafka-topics.bat --list --zookeeper <DIREC>
• DETALLE kafka-topics.bat --describe --zookeeper <DIREC> --topic <NOMBRE>
• CREAR kafka-topics.bat --create --zookeeper <DIREC> --replication-factor X --partitions Y --topic <NOMBRE>
• BORRAR kafka-topics.bat --delete --zookeeper <DIREC> --topic <NOMBRE>

Práctica 6 : Uso productor/consumidor línea de comandos
PASOS DE EJECUCION DE UN CONSUMIDOR:
• Ejecutar el siguiente comando por consola (consolas independientes)
1 Productor + 2 Consumidores + Topic “example3”
• kafka-console-producer.bat --broker-list localhost:9090,localhost:9091,localhost:9092,localhost:9093 --topic example3
• kafka-console-consumer.bat --bootstrap-server localhost:9090,localhost:9091,localhost:9092,localhost:9093 --topic example3
• kafka-console-consumer.bat --bootstrap-server localhost:9090,localhost:9091,localhost:9092,localhost:9093 --topic example3
• Escribir : “Mensaje 1”, “Mensaje 2” y “Mensaje 3”
• Para un consumidor
• Escribir : “Mensaje 4” y arrancarlo
• Escribir : “Mensaje 5”
• Para un consumidor y arrancarlo con : --from-beginning (Se mostraran todos los mensajes)
• Para el consumidor y arrancarlo con : --max-messages 1 (Se parara el consumidor)
• Para los 2 consumidores y arrancarlo con : --consumer-property group.id=myconsumergroup (se procesaran de forma específica)
• Escribir : “Mensaje 8”, “Mensaje 9” y “Mensaje 10”

Meetup En mi local funciona - Mi primer diseño con Apache Kafka

Meetup En mi local funciona - Mi primer diseño con Apache Kafka

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Meetup En mi local funciona - Mi primer diseño con Apache Kafka

Similar a Meetup En mi local funciona - Mi primer diseño con Apache Kafka (20)

Más de atSistemas

Más de atSistemas (20)

Meetup En mi local funciona - Mi primer diseño con Apache Kafka