Primeros pasos con Apache Kafka parte 2

Seguimos con Kafka.

Si bien los mensajes son matrices de bytes opacas para el propio Kafka, se recomienda que se imponga una estructura o esquema adicional en el contenido del mensaje para que se pueda entender fácilmente. Hay muchas opciones disponibles para el esquema de mensajes, según las necesidades individuales de su aplicación. Los sistemas simplistas, como Javascript Object Notation (JSON) y Extensible Markup Language (XML), son fáciles de usar y legibles por humanos. Sin embargo, carecen de características como el manejo de tipos robusto y la compatibilidad entre las versiones del esquema. Muchos desarrolladores de Kafka favorecen el uso de Apache Avro, que es un marco de serialización desarrollado originalmente para Hadoop. Avro proporciona un formato de serialización compacto; esquemas que están separados de las cargas útiles del mensaje y que no requieren que se genere código cuando cambian; y datos sólidos tipado y evolución del esquema, con compatibilidad tanto hacia atrás como hacia adelante.

Un formato de datos coherente es importante en Kafka, ya que permite desacoplar la escritura y la lectura de mensajes. Cuando estas tareas están estrechamente vinculadas, las aplicaciones que se suscriben a los mensajes deben actualizarse para manejar el nuevo formato de datos, en paralelo con el formato anterior. Solo entonces se podrán actualizar las aplicaciones que publican los mensajes para utilizar el nuevo formato. Al utilizar esquemas bien definidos y almacenarlos en un repositorio común, los mensajes en Kafka se puedan entender sin coordinación.

Los mensajes de Kafka se clasifican en temas. Las analogías más cercanas para un tema son una tabla de base de datos o una carpeta en un sistema de archivos. Además, los temas se desglosan en un número de particiones. Volviendo a la descripción del "registro de confirmación", una partición es un registro único. Los mensajes se escriben en él de forma de solo anexo y se leen en orden de principio a fin. Tenga en cuenta que, dado que un tema suele tener varias particiones, no hay garantía de que los mensajes se ordenen por tiempo en todo el tema, solo dentro de una única partición. 

Las particiones también son la forma en que Kafka proporciona redundancia y escalabilidad. Cada partición se puede alojar en un servidor diferente, lo que significa que un solo tema se puede escalar horizontalmente en varios servidores para proporcionar un rendimiento mucho más allá de la capacidad de un solo servidor.

El término stream se usa a menudo cuando se habla de datos dentro de sistemas como Kafka. La mayoría de las veces, se considera que una secuencia es un solo tema de datos, independientemente del número de particiones. Esto representa un único flujo de datos que se mueve de los productores a los consumidores. Esta forma de referirse a los mensajes es más común cuando se habla de procesamiento de flujo, que es cuando los frameworks (algunos de los cuales son Kafka Streams, Apache Samza y Storm) operan en los mensajes en tiempo real. Este método de operación se puede comparar con la forma en que los frameworks offline, a saber, Hadoop, están diseñados para trabajar con datos masivos en un momento posterior.