Etiqueta: realtime-processing

Apache Kafka : Brokers y réplica de datos

por raidentrance, posted in Español

En el post anterior hablamos sobre el ecosistema de Apache Kafka en el post Apache Kafka: El ecosistema y los conceptos básicos, ahora es el turno de hablar de brokers y replicación de datos.

Brokers

Un cluster de Apache Kafka se compone de multiples brokers (servidores), cada uno de ellos contiene un id y  particiones. Una vez que te conectas a un broker, estarás conectado al cluster completo.

Un cluster de Kafka esta constituido de la siguiente forma:

brokers

Como se puede ver en la imagen tendremos lo siguiente:

  • Un cluster de Kafka puede tener multiples brokers
  • Un topic puede tener multiples particiones
  • Cada partición puede vivir en diferentes brokers
  • Un topic puede vivir el múltiples brokers

Replication factor

La traducción literal de replication factor es factor de replicas, esto se refiere a cuantas copias tendré de mi topic, a continuación se muestran algunos puntos a considerar para asignarlo:

  • Se debe asignar un replication factor mayor que cero
  • El número máximo de replicas es el número máximo de brokers en el servidor
  • Si un nodo está abajo, otro nodo que cuente con una replica puede entregar los datos
  • Las particiones también se replican

Veamos la siguiente imagen:

replication

Analicemos la imagen anterior:

  • Se tienen 3 brokers
  • Se tiene 1 topic llamado Topic 1
  • Topic 1 tiene 2 particiones
  • Topic 1 tiene un replication factor 2

Con lo anterior imaginemos los siguientes escenarios:

  1. Broker 1 se cae

broker1

Si esto sucede aun tendremos funcionando el Topic 1 debido a que la partición 0 se encuentra en broker 2 y la partición 1 se encuentra en el broker 3.

2. Broker 2 se cae

broker2

Si esto sucede el Topic 1 seguiría funcionando de forma correcta debido a que Broker 1 contiene la partición 0 y broker 3 contiene la partición 1.

3. Broker 3 se cae

broker3

Por último si el broker 3 se cae el Topic 1 seguiría funcionando de forma correcta debido a que la partición 0 se encuentra en el broker 1 y la partición 1 se encuentra en el broker 2.

Es importante mencionar que existen sistemas que requieren alta disponibilidad que cuentan hasta con 100 brokers funcionando de forma simultanea, esto nos puede dar una idea del nivel de confianza que les podemos dar.

Partition Leader

Como pueden ver un topic puede tener multiples particiones, esto trae el concepto de partition leader o partición líder. Solo un broker puede ser el líder para una partición en específico y solo ese líder puede enviar y recibir datos, los demás brokers solo se utilizarán para sincronizar los datos.

Si recordamos lo que mencionamos anteriormente si un topic tiene 3 particiones cada partición vivirá en un broker diferente, si a esto agregamos que un topic puede tener un replication factor digamos de 3 entonces tendremos el número de particiones multiplicadas por 3, esto significa que una de esas 3 particiones un broker será el líder y los demás se conocerán como ISR (In sync replica).

Si te gusta el contenido y quieres enterarte cuando realicemos un post nuevo síguenos en nuestras redes sociales https://twitter.com/geeks_mx y https://www.facebook.com/geeksJavaMexico/.

Autor: Alejandro Agapito Bautista

Twitter: @raidentrance

Contacto:raidentrance@gmail.com

Apache Kafka: El ecosistema y los conceptos básicos

por raidentrance, posted in Español

En este post explicaremos el ecosistema de Apache Kafka, si aún no tienes configurado tu cluster te recomendamos leer el post Primeros pasos con Apache Kafka en Español !.

Antes de empezar veamos la siguiente imagen que representa el ecosistema básico de Kafka.ecosistema basico

En el diagrama anterior tenemos los siguientes componentes:

  • Una fuente de datos: esta puede ser un api, base de datos, motor de búsqueda, etc.
  • Producer API: Es un api que permite colocar mensajes en lugares llamados topics dentro de un cluster de Kafka.
  • Kafka / Zookeeper : Más adelante explicaremos más a detalle como funcionan estos dos componentes en el ecosistema pero por ahora consideremos que serán quienes almacenarán los mensajes en lugares llamados topics.
  • Consumer API: Es un api que permite leer mensajes desde los topics de kafka.
  • Target system: Sistema destino que recibirá la información que se está procesando.

Una vez que entendemos como funciona el ecosistema básico de Kafka ahora veamos el Kafka Extended API:

kafka extended.png

Veamos punto por punto:

  • Fuente de datos: Del mismo modo que en el ecosistema básico tendremos una fuente de datos a procesar.
  • Kafka connect source: Sabemos que existe un producer API, pero, al darse cuenta que existen muchas fuentes de datos similares, se decidió crear este proyecto, el cual define un conjunto de conectores a fuentes de datos comunes para que solo lo configures en tu cluster y este lea la información y la mande a algún topic de kafka.
  • Kafka connect sink: Del mismo modo que en el punto anterior existen sistemas de destino comunes, para esto se creó este proyecto que de igual modo contiene conectores los cuales envían información a esos sistemas destino.
  • Kafka streams: La mayoría de las veces no solo necesitas leer información y escribirla en un sistema destino, sino que deseas realizar algunas transformaciones a los datos, kafka steams permite realizar esas operaciones.
  • Target systems: Del mismo modo que en el ecosistema básico tendremos sistemas destino que recibirán la información que procesamos.

Conceptos básicos

A continuación presentaremos los conceptos básicos que debes entender antes de continuar utilizando Apache Kafka:

  • Topic : Un topic es un flujo de datos del mismo contexto al cuál se le asigna un nombre, en un cluster de Kafka es posible crear multiples topics del mismo modo que en una base de datos es posible crear muchas tablas.
  • Partition : Un topic es dividido en particiones, las cuales son ordenadas, de este modo podemos ver una partición como parte de un topic.
  • Message: Un mensaje es información que colocamos en un topic.
  • Offset: Cada mensaje colocado dentro de una partición recibe un id incremental al que se le conoce como offset.

Si tratamos de visualizar lo anterior se verá del siguiente modo:

Captura de pantalla 2018-03-21 a las 12.24.07 p.m.

Puntos importantes:

  • Un offset solo tiene significado dentro de una partición, si vemos la imagen anterior podemos ver que podemos tener el offset 0 en las 3 particiones, pero esto no significa que el valor dentro de las 3 particiones es el mismo.
  • El orden está garantizado pero solo dentro de la misma partición no en las otras particiones.
  • A diferencia de otros brokers los mensajes que se entregan en Kafka se almacenarán por un periodo de tiempo, por default este periodo es de 2 semanas.
  • Una vez que la información se almacena en una partición esta no se puede cambiar.
  • Puedes tener las particiones que quieras en un topic de Kafka.
  • Tu no colocas los mensajes en una partición en específico, tu lo haces en topics, la asignación de particiones sobre los mensajes se hace de manera aleatoria a menos que tengas una llave.
  • Entre más particiones tengas puedes tener más paralelismo, esto significa que puedes tener más consumers leyendo al mismo tiempo.

En el siguiente post explicaremos como funcionan los brokers, la replicación de los datos, el envío y recepción de mensajes con Java, etc.

Si te gusta el contenido y quieres enterarte cuando realicemos un post nuevo síguenos en nuestras redes sociales https://twitter.com/geeks_mx y https://www.facebook.com/geeksJavaMexico/.

Autor: Alejandro Agapito Bautista

Twitter: @raidentrance

Contacto:raidentrance@gmail.com