Comencemos con una cita de la Wikipedia:
KISS es el acrónimo de «Keep it simple, stupid», un principio de diseño que apareció en la marina de los EEUU en 1960. El principio KISS dice que la mayoría de los sistemas funcionan mejor si se mantienen sencillos en vez de complicados; por tanto, la simplicidad debe ser un objetivo de diseño y se debe evitar la complejidad innecesaria.
Usamos el mismo acrónimo con el mismo significado, Kafka mantiene las cosas sencillas y es la clave del éxito del streaming.
K.I.S.S., Kafka Is Streaming Success
Si no has oído nunca hablar de ello, Kafka es un proyecto Apache de plataforma de mensajería/streaming.
Una plataforma de streaming tiene tres funcionalidades principales:
- Publicar y suscribirse a flujos de registros, similar a una cola de mensajes o a un sistema de mensajería empresarial.
- Almacenar flujos de registros de manera permanente y con tolerancia a fallos.
- Procesar flujos de registros en tiempo real.
Kafka se usa generalmente para dos tipos de aplicaciones:
- Construcción de canales de datos entre sistemas o aplicaciones de manera garantizada.
- Construcción de canales de datos entre sistemas o aplicaciones que transforman o reaccionan a los flujos de datos.
Aquí puedes consultar más documentación en el portal de Kafka.
Seguro que se te están ocurriendo mil ideas de nuevos proyectos, o de reformular los que ya tienes. Y es lo normal, pero adentrémonos primero en las capacidades de Kafka.
Un consejo sencillo para cualquiera que acabe de conocer Kafka es: olvídate de todas las limitaciones, recuerda tus necesidades. Claramente estamos exagerando pero tanto desarrolladores, administradores, operadores como arquitectos verán en Kafka otra forma de hacer las cosas:
- ¿Necesitas reprocesar registros? Sin problema, los registros se pueden guardar en los brokers tanto tiempo como sea necesario. Por defecto son dos semanas, pero se puede cambiar a meses con el coste de disco asociado, sin penalizaciones de rendimiento. Tu aplicación es la dueña de la referencia, los mensajes está ahí para ella.
- ¿Necesitas incrementar la capacidad del sistema? No te preocupes, añade más brokers, más discos. Redistribuye la carga. Esta es la piedra filosofal de los administradores de sistemas: alta disponibilidad y balanceo de carga.
- ¿Tu aplicación necesita más consumidores para lidiar con la carga? Añádelos al mismo grupo y se coordinarán automáticamente.
- ¿Los registros deben llegar en orden? Shhh no todo iban a ser buenas noticias, sin embargo, hay modos de solucionarlo 😉
- ¿Flujo de datos más rápido? Conseguido.
De hecho, estas características son las que nos indican las aplicaciones de más éxito en Kafka. Las de registro de actividad, métricas y logs. Todas ellas nos llevan al procesamiento de flujos de registros.
Y es gracias a esta entrega de registros, prácticamente en tiempo real, que una vez que un productor y un consumidor se conectan a Kafka, el flujo de información es prácticamente instantáneo.
Los chicos de Kafka hicieron un estudio muy interesante que muestra que escribir y leer de disco puede ser casi tan rápido como hacerlo de memoria si se hace de la manera adecuada, y además es mucho más barato. Dos trucos: Kafka no elimina automáticamente los mensajes consumidos ni los reorganiza en disco (usa escritura secuencial) y también evita copiar los mensajes entre muchas capas de software (realizar un técnica de cero-copias con la llamada al sistema sendfile).
Kafka también tiene Streams API, su propio framework para procesamiento en streaming. Tiene muchas funcionalidades interesantes, pero hay una que lo diferencia de los sistemas de mensajería tradicionales: en vez de trabajar con peticiones de recogida de datos (pull) que funcionan con lotes de mensajes para mejorar el rendimiento Streams API, trabaja con entrega (push) de un flujo continuo de registros con latencias de milisegundos.
Pero siendo sinceros, no es necesario usar Kafka Streams para tener un flujo de datos continuo. Hortonworks hizo una interesante comparativa de los framework de flujos de datos. También hay buena documentación y vídeos de Streams API aquí. Eso es, sin embargo, sólo la elección del framework de procesamiento. Kafka sigue siendo la capa subyacente que sirve los mensajes, algo a lo que no se acerca ningún otro sistema de mensajería.
Esta imagen ha sido extraída de Hortonworks.
¿No hay alternativas reales a Kafka?
Hay un proyecto, NATS Streaming, una extensión de NATS que provee capacidades de flujo de mensajes sobre un sistema de mensajería clásico, aunque muy reciente y rico en tecnología y nuevos conceptos de mensajería. Sin embargo, la versión 0.10.0 parece aún un poco inmadura. El resto de los productos disponibles son simplemente mejores o peores implementaciones de sistemas de mensajería clásicos.
Finalmente, no olvidemos que Kafka es open source y seguramente tu compañía quiera soporte. Hay varias compañías que pueden ofrecerlo (las grandes empresas de Big Data como Cloudera y Hortonworks – recientemente fusionadas-, Confluent o TIBCO)
Sigue leyendo:
Juan Tavira
Universia
Especialista, arquitecto y friki multidisciplinar apasionado de todas las innovaciones. Esto es fácil de decir por uno mismo, pero cuando lo dicen mis compañeros informáticos, mis amigos geeks de los juegos e incluso mi mujer, algo de verdad tendrá ;-). Me gusta construir violines como hobby. En ocasiones veo código.
