- El debate sobre un Kafka optimizado para la nube se ha intensificado con KIP-1150 (Kafka sin disco) y el proyecto de fork de Kafka de AutoMQ
- Si se reconstruyera Kafka, se propone eliminar la estructura de particiones existente y adoptar un enfoque centrado en claves
- Se necesitan funciones de control de concurrencia y soporte de esquemas del lado del broker
- También se enfatiza la necesidad de integrar características de sistemas modernos como escalabilidad, snapshots y multi-tenancy
- A partir de Kafka, se imagina un verdadero sistema de registro de eventos cloud-native que supere las limitaciones del Kafka actual
Si reconstruyéramos Kafka
- Recientemente se anunciaron KIP-1150 (Kafka sin disco) y el fork de Kafka de AutoMQ, con el objetivo de integrar Kafka con almacenamiento de objetos como S3 para mejorar la elasticidad en entornos cloud y reducir costos
- Se proponen varias mejoras al imaginar un sistema de registro de eventos cloud-native que vaya más allá de las limitaciones del Kafka actual
Propuesta de una estructura sin particiones
- Como el almacenamiento de objetos en la nube puede comportarse como almacenamiento prácticamente infinito, disminuye la necesidad de particiones de topic
- En muchos casos, lo importante es el orden global de los mensajes o solo el orden de los mensajes con la misma clave
- Se podría ocultar el concepto de partición a los usuarios y ofrecer una experiencia de uso más simple
Enfoque centrado en claves
- Se propone un diseño que permita acceder y reproducir rápidamente todos los mensajes de una clave específica, en lugar de escanear particiones
- Podría soportar streams a nivel de millones de entidades, ajustando dinámicamente la cantidad de consumidores según la demanda
- Como los fallos quedan aislados por clave, aumenta la eficiencia de procesamiento del sistema completo
- Es una estructura ideal para event sourcing o sistemas basados en el modelo de actores
Soporte para jerarquía de topics
- Como en sistemas como Solace, se debería elevar una parte del payload del mensaje a un identificador de topic con forma de ruta estructurada para permitir suscripciones basadas en patrones
- El broker podría soportar filtrado eficiente de suscripciones sin necesidad de parsear el mensaje completo
Funciones de control de concurrencia
- Actualmente Kafka no tiene una forma de evitar conflictos de concurrencia al momento de escribir
- Si se soportara optimistic locking por clave, se podría verificar que el mensaje fue escrito después de haber visto el estado más reciente
- Esto permitiría evitar el problema de actualizaciones perdidas
Soporte de esquemas del lado del broker
- Actualmente Kafka trata los mensajes como simples arreglos de bytes y depende de registros de esquemas externos
- Se propone la necesidad de soportar de forma nativa, a nivel broker, información de esquema como metadatos de AsyncAPI para asegurar la consistencia de esquemas
- Esto también permitiría integrarse fácilmente con formatos de tabla abiertos como Apache Iceberg
Escalabilidad y estructura de plugins
- Se propone una estructura con extensibilidad y capacidad de plugins como Postgres o Kubernetes
- Debería ser posible implementar fácilmente filtros o transformaciones a nivel broker sin proxies con conocimiento del protocolo (como Kroxylicious)
- Funciones como limitación de velocidad, cifrado de topics o soporte de backend basado en tablas Iceberg deberían poder implementarse como plugins
Callback síncrono de commit
- Actualmente Kafka solo garantiza consistencia eventual
- Se propone la necesidad de una estructura donde, después de que el productor envíe un mensaje, pueda confirmar de inmediato si los datos derivados correspondientes ya fueron actualizados
- Al soportar read-your-own-writes, Kafka podría usarse como un verdadero log de base de datos
Función de snapshots
- La compactación actual de Kafka solo conserva el último mensaje, lo cual solo es válido cuando ese mensaje contiene el estado completo
- Si solo se registran cambios, el tiempo aumenta porque hay que reproducir todos los eventos por clave
- Se necesita una función de compactación lógica que resuma eventos por clave en snapshots
Soporte nativo para multi-tenancy
- Todo sistema de datos moderno debería considerar multi-tenancy como una característica base
- Debería ser posible crear entornos para nuevos tenants de manera inmediata y a bajo costo, con separación estricta de recursos, seguridad y control de acceso
Otras observaciones
- Algunas funciones ya existen en sistemas como S2 (streams de alta cardinalidad), Waltz (optimistic locking) y Apache Pulsar (multi-tenancy)
- Sin embargo, no existe un sistema open source que soporte todas las funciones propuestas al mismo tiempo
- Este artículo refleja la opinión personal de un autor de Confluent y no representa una postura oficial
- Se menciona que, en teoría, una arquitectura basada en árboles LSM sería una opción prometedora
2 comentarios
Ya lo llamamos Redis.
Opinión de Hacker News
De acuerdo. Vale la pena resolver el problema de bloqueo en cabeza de línea para ciertos casos de uso
NATS.io es más fácil de usar que Kafka y ya resuelve varios puntos, como eliminar particiones, soporte para streams basados en claves y una jerarquía de temas flexible
Mi recorrido con Kafka ha sido en gran parte similar
En ciertos casos de uso, sería útil poder garantizar que, cuando se aprueba una solicitud de creación, la vista de datos derivada ya fue actualizada
Hice esta pregunta hace 6 años
¿Kafka sobre almacenamiento de objetos? Eso aumentaría la latencia y el costo 10 veces
Sobre "eliminar particiones" y "streams a nivel de clave"
Hay que poner atención a Northguard
Me pregunto cuántos de los problemas de Apache Kafka se resuelven cambiándose a Apache Pulsar
Es un experimento mental útil