Algunas diferencias entre Apache Pulsar y Apache Kafka

Pulsar vs Kafka.txt

Resúmen:
Podemos pensar que Apache Pulsar es la competencia de Apache Kafka, pues parece que sirven para lo mismo, pero hay algunas diferencias. Apache Pulsar es ante todo tecnología de entrega de mensajería ordenada distribuida y escalable, mientras que Apache Kafka es ante todo tecnología de streaming de datos distribuida y escalable.
Si para ud es muy importante la entrega de mensajes en orden, entonces Apache Pulsar es la mejor opción, te lo da por defecto, si necesitas entregar y consumir información en streaming y el orden no es importante, entonces, Kafka puede llegar a ser mejor opción.

características Apache Kafka Apache Pulsar
Tipo Streaming Mensajería y streaming
Popularidad Más popular Menos popular
Comunidad Mayor Menor
Durabilidad Sí Sí
Alta disponibilidad Sí Sí
Escalar horizontalmente Sí Sí
Costo Gratuito Gratuito

A continuación, una serie de preguntas y respuestas contra Bard para tratar de averiguar las similitudes y diferencias entre Apacha Kafka y Apache Pulsar:

PREGUNTA:

no ves la diferencia entre mensajería y streaming de datos?, a mis ojos, es casi lo mismo, literalmente, entrega de mensajería a un buzón, un topic, que puede estar particionado, distribuido entre distintos brokers, dichos mensajes pueden tener un esquema para describir un formato y así poder usar un mecanismo para escribir y leer eficientemente.

RESPUESTA:

La mensajería y el streaming de datos son dos conceptos relacionados, parecidos, pero no son exactamente iguales.

La mensajería se refiere al envío de mensajes entre dos o más partes. Los mensajes pueden ser de cualquier tamaño y formato, y pueden contener cualquier tipo de datos. La mensajería se utiliza a menudo para la comunicación entre aplicaciones, servicios o dispositivos.

El streaming de datos se refiere a la transmisión de datos de forma continua. Los datos se pueden transmitir en tiempo real o se pueden almacenar para su procesamiento posterior. El streaming de datos se utiliza a menudo para la recopilación de datos de sensores, redes sociales o aplicaciones móviles.

La principal diferencia entre la mensajería y el streaming de datos es la forma en que se entregan los datos. En la mensajería, los datos se entregan en forma de mensajes individuales. Cada mensaje tiene un encabezado que contiene información sobre el mensaje, como el emisor, el receptor y el tipo de datos. El cuerpo del mensaje contiene los datos reales.

En el streaming de datos, los datos se entregan en forma de flujo continuo. No hay encabezados de mensajes, y los datos se entregan en orden secuencial.

Otra diferencia entre la mensajería y el streaming de datos es el uso de los datos. En la mensajería, los datos suelen utilizarse para la comunicación entre aplicaciones o servicios. En el streaming de datos, los datos suelen utilizarse para el análisis o la visualización.

En mi pregunta inicial, estaba describiendo una plataforma de mensajería y streaming unificada. Esta plataforma utiliza un enfoque de mensajería para entregar los datos. Los mensajes se entregan a un topic, dependiendo de su tipo, se pueden entregar a un topic, o a otro, dependerá de su formato.Un topic puede tener un consumidor o muchos, de la misma manera, puede tener un productor o muchos.

Este enfoque es adecuado para aplicaciones que requieren tanto mensajería como streaming. Por ejemplo, una aplicación de integración de datos podría utilizar esta plataforma para enviar datos de una fuente a otra.

Sin embargo, hay otras plataformas de streaming de datos que utilizan un enfoque diferente. Estas plataformas entregan los datos en forma de flujo continuo. Este enfoque puede ser más eficiente para aplicaciones que requieren el procesamiento de grandes cantidades de datos en tiempo real.

En última instancia, la mejor plataforma para una aplicación determinada dependerá de las necesidades específicas de la aplicación.

Pregunta:

entonces, con pulsar, el orden en el que se entregan los mensajes es importante, mientras que en kafka no lo es.

Respuesta:

Sí, en general, el orden en el que se entregan los mensajes es importante en Pulsar, mientras que en Kafka no lo es. Sin embargo, existen algunas excepciones a esta regla.

En Pulsar, el orden de entrega de los mensajes se garantiza por defecto. Esto significa que los consumidores recibirán los mensajes en el mismo orden en que se enviaron. Sin embargo, los consumidores pueden optar por recibir los mensajes en cualquier orden.

En Kafka, el orden de entrega de los mensajes no se garantiza por defecto. Esto significa que los consumidores pueden recibir los mensajes en cualquier orden. Sin embargo, los consumidores pueden optar por recibir los mensajes en orden.

La siguiente tabla resume las reglas generales para el orden de entrega de mensajes en Pulsar y Kafka:

Plataforma	Orden de entrega de mensajes
Pulsar	Garantizado por defecto
Kafka	No garantizado por defecto

En la práctica, la importancia del orden de entrega de mensajes depende de las necesidades específicas de la aplicación. Si la aplicación requiere que los mensajes se reciban en el mismo orden en que se enviaron, entonces Pulsar es una buena opción. Si la aplicación no requiere que los mensajes se reciban en un orden específico, entonces Kafka puede ser una mejor opción.

Aquí hay algunos ejemplos de cómo el orden de entrega de mensajes puede ser importante:

• Integración de datos: Si una aplicación de integración de datos necesita combinar datos de diferentes fuentes, entonces es importante que los datos se reciban en el mismo orden en que se enviaron.
• Notificaciones: Si una aplicación de notificaciones necesita enviar notificaciones a los usuarios en un orden específico, entonces es importante que los mensajes se reciban en el mismo orden en que se enviaron.
• Análisis de datos: Si una aplicación de análisis de datos necesita analizar datos en tiempo real, entonces es importante que los datos se reciban en un orden específico.

El orden de entrega de mensajes es una de las características más importantes que diferencian a Pulsar y Kafka.

Otras características que pueden ser importantes para la elección de una plataforma incluyen:

Popularidad: Kafka es más popular que Pulsar, lo que significa que tiene una mayor base de usuarios y una comunidad más activa. Es lógico, pues Kafka lleva más tiempo en el mercado.
Costo: Ambas plataformas son gratuitas, pero Kafka tiene una licencia propietaria para algunas funciones avanzadas.
Escalabilidad: Tanto Pulsar como Kafka se pueden escalar horizontalmente para satisfacer las necesidades de las aplicaciones de alto tráfico.
Durabilidad: Ambas plataformas almacenan los mensajes de forma duradera, pero Pulsar ofrece una mayor flexibilidad en la forma en que se almacenan los datos.

Pregunta:

A día de hoy, Apache Pulsar y Apache Kafka se pueden desplegar en alguna nube privada? se puede desplegar on premise en un cluster de mi elección?

Respuesta:

Si, tanto la gente de Apache Pulsar como la de Apache Kafka se dieron cuenta que tenían un producto diferenciador y se largaron a fundar sus propias empresas para así dar servicio especializado de esta tecnología tan necesaria, en mi opinión. Los de Apache Kafka crearon la tecnología para Linkedin, para luego fundar Confluent, mientras que los de Pulsar fundaron Streamnative. Ambas tecnologías se pueden instalar descargando un zip en cada una de las máquinas, o creando brokers virtuales corriendo en contenedores bajo un hypervisor, mediante un gestor de contenedores como k8s y helm.

Pregunta:

A día de hoy, Pulsar solo produce la escala más baja de la piramide de funcionalidades que si ofrece Kafka, no? abajo del todo están los productores y consumidores, despues viene kafka-streams, por encima, ksqldb, arriba del todo kafka-connect. Mientras que Apache Pulsar por ahora parece que se centra en la base de la pirámide, no? los productores y consumidores

Respuesta:

Sí, en términos generales, Pulsar ofrece una capa más baja de funcionalidad que Kafka. Pulsar se centra en la entrega de mensajes, mientras que Kafka ofrece una gama más amplia de funciones, incluyendo:

Kafka Streams: un marco de procesamiento de flujos de datos que permite a los desarrolladores construir aplicaciones de streaming de datos sin servidor.
KSQLDB: un motor de consulta SQL para datos de streaming.
Kafka Connect: un marco para la integración de datos entre Kafka y otras fuentes de datos.
Pulsar está trabajando para ampliar su funcionalidad para competir con Kafka en estas áreas. Por ejemplo, Pulsar ya ofrece soporte para procesamiento de flujos de datos a través de su módulo Functions. Pulsar también está desarrollando un marco de consulta SQL para datos de streaming.

Sin embargo, todavía hay algunas áreas en las que Kafka ofrece más funcionalidad que Pulsar. Por ejemplo, Kafka Connect ofrece una gama más amplia de conectores para fuentes de datos que Pulsar. Además, Connect digamos que es una solución no code, interactúas a través de una terminal o un dashboard tu intención. Muy avanzado, aunque también creo que al final siempre vas a necesitar crear algo ad hoc para que verdaderamente sea no code para personas no técnicas.

En última instancia, la mejor plataforma para una aplicación determinada dependerá de las necesidades específicas de la aplicación. Si la aplicación requiere una funcionalidad específica que no ofrece Pulsar, entonces Kafka puede ser una mejor opción.

Pregunta:

Apache Pulsar tiene algo equivalente a kafka-streams y a KSQLDB?

Respuesta:

Sí, Apache Pulsar tiene algo equivalente a Kafka Streams y a KSQLDB.

Kafka Streams es un marco de procesamiento de flujos de datos que permite a los desarrolladores construir aplicaciones de streaming de datos sin servidor. Pulsar ofrece soporte para procesamiento de flujos de datos a través de su módulo Functions. Las funciones son fragmentos de código que se ejecutan en los brokers de Pulsar. Las funciones se pueden utilizar para procesar mensajes de forma asíncrona, sin necesidad de crear un proceso o servicio separado.

KSQLDB es un motor de consulta SQL para datos de streaming. Pulsar está desarrollando un marco de consulta SQL para datos de streaming. Este marco aún está en desarrollo, pero ya ofrece soporte para una serie de operaciones SQL básicas, como la selección, el filtrado y la agregación.

En general, Pulsar ofrece una funcionalidad similar a Kafka Streams y a KSQLDB. Sin embargo, todavía hay algunas diferencias entre las dos plataformas. Por ejemplo, Kafka Streams ofrece una gama más amplia de operaciones de procesamiento de flujos de datos que Pulsar. KSQLDB también ofrece una gama más amplia de operaciones de consulta SQL que Pulsar.

En última instancia, la mejor plataforma para una aplicación determinada dependerá de las necesidades específicas de la aplicación. Si la aplicación requiere una funcionalidad específica que no ofrece Pulsar, entonces Kafka puede ser una mejor opción.

Pregunta:
Está pensado para ser usado en producción Apache Pulsar? está en producción por alguna empresa?

Respuesta:
Sí, Apache Pulsar está pensado para ser usado en producción. De hecho, hay muchas empresas que ya lo están utilizando en producción.

Algunas empresas que utilizan Apache Pulsar en producción incluyen:

Bloomberg: Bloomberg utiliza Pulsar para la entrega de mensajes a sus aplicaciones de trading.
Spotify: Spotify utiliza Pulsar para la integración de datos y el análisis de datos.
Netflix: Netflix utiliza Pulsar para la entrega de mensajes a sus aplicaciones de contenido.
Twitter: Twitter utiliza Pulsar para la entrega de mensajes a sus aplicaciones de redes sociales.
Pulsar ofrece una serie de características que lo hacen adecuado para su uso en producción, incluyendo:

Escalabilidad: Pulsar se puede escalar horizontalmente para satisfacer las necesidades de las aplicaciones de alto tráfico.
Durabilidad: Pulsar almacena los mensajes de forma duradera, lo que garantiza que los datos no se pierdan.
Seguridad: Pulsar ofrece una serie de características de seguridad para proteger los datos.

Apache Pulsar es un sistema de mensajería distribuido que proporciona una serie de características de seguridad para proteger los mensajes durante su transmisión. Estas características incluyen:

• Cifrado de mensajes: Pulsar puede cifrar los mensajes de extremo a extremo utilizando una variedad de algoritmos de cifrado, como AES-256, RSA y ECDSA. El cifrado de mensajes ayuda a proteger los datos contra el acceso no autorizado.
• Autenticación de mensajes: Pulsar puede autenticar los mensajes utilizando firmas digitales. La autenticación de mensajes ayuda a garantizar que los mensajes no hayan sido modificados durante su transmisión.
• Control de acceso: Pulsar proporciona un sistema de control de acceso que permite a los administradores restringir el acceso a los mensajes. El control de acceso ayuda a proteger los mensajes contra el acceso no autorizado.

Para entregar mensajes cifrados, Pulsar utiliza el protocolo TLS (Transport Layer Security) para proteger la conexión entre el productor y el consumidor de mensajes. TLS utiliza un par de claves públicas y privadas para cifrar y descifrar los datos.

El proceso de entrega de mensajes cifrados en Pulsar es el siguiente:

1. El productor de mensajes cifra los mensajes utilizando una clave privada.
2. El productor de mensajes envía los mensajes cifrados al consumidor de mensajes.
3. El consumidor de mensajes utiliza la clave pública del productor de mensajes para descifrar los mensajes.

En concreto, Pulsar utiliza TLS para cifrar los siguientes datos:

• Los encabezados de los mensajes, que contienen información sobre el mensaje, como el destino, el remitente y el tamaño del mensaje.
• Los datos del mensaje, que son los datos reales que se transmiten.

Pulsar también utiliza TLS para autenticar los mensajes. Para ello, el productor de mensajes firma digitalmente los mensajes utilizando su clave privada. El consumidor de mensajes utiliza la clave pública del productor de mensajes para verificar la firma.

En conclusión, Apache Pulsar proporciona una serie de características de seguridad para proteger los mensajes durante su transmisión. Estas características incluyen el cifrado de mensajes, la autenticación de mensajes y el control de acceso.

Pregunta:

Se parece mucho al mecanismo de Kafka no? el tamaño del mensaje cifrado será mucho más grande, no? cuanto más grande de media?

Respuesta:

Sí, el mecanismo de seguridad de Apache Pulsar es muy similar al de Kafka. Ambos sistemas utilizan el protocolo TLS para cifrar los mensajes, lo que implica añadir una cabecera TLS al mensaje. Esta cabecera TLS contiene información sobre la clave utilizada para cifrar el mensaje, así como información sobre la autenticación del mensaje.

El tamaño de la cabecera TLS depende del algoritmo de cifrado utilizado. Para los algoritmos de cifrado más comunes, como AES-256, el tamaño de la cabecera TLS es de aproximadamente 256 bytes. Por lo tanto, el tamaño del mensaje cifrado será aproximadamente un 25% mayor que el tamaño del mensaje original.

En cuanto al tamaño medio del mensaje cifrado, esto dependerá de la aplicación específica. En general, los mensajes de tamaño pequeño, como los mensajes de control, tendrán un aumento de tamaño más pequeño que los mensajes de tamaño grande, como los mensajes de datos.

Por ejemplo, si un mensaje original tiene un tamaño de 1 KB, el mensaje cifrado tendrá un tamaño de aproximadamente 1,25 KB. Si un mensaje original tiene un tamaño de 100 KB, el mensaje cifrado tendrá un tamaño de aproximadamente 125 KB.

En general, Apache Pulsar es una plataforma de mensajería y streaming sólida que es adecuada para su uso en producción.

Pregunta:

Si la entrega ordenada de datos es algo asegurado en Pulsar, mientras que no lo es en Kafka, podríamos argumentar que el rendimiento a la hora de escribir y leer en topics distribuidos y particionados es superior en Apache Kafka, incluso si llegamos al punto de escribir a disco el offset de los datos, no?

Respuesta:

En general, sí, es posible que el rendimiento a la hora de escribir y leer en topics distribuidos y particionados sea superior en Apache Kafka que en Apache Pulsar.

En Kafka, los mensajes se escriben y leen directamente de los brokers de Kafka. Los brokers de Kafka son responsables de la entrega de los mensajes a los consumidores. Kafka no garantiza la entrega ordenada de los mensajes, pero los consumidores pueden usar el offset de los mensajes para garantizar que se reciban en el orden correcto.

En Pulsar, los mensajes se escriben y leen de los topics. Los topics se componen de particiones, que son unidades de datos que se pueden distribuir y replicar entre los brokers de Pulsar. Pulsar garantiza la entrega ordenada de los mensajes dentro de cada partición.

Para garantizar la entrega ordenada de los mensajes en Pulsar, los brokers de Pulsar deben mantener un registro de los mensajes que se han entregado. Este registro puede afectar al rendimiento de la escritura y la lectura de mensajes.

Si los consumidores en Kafka usan el offset de los mensajes para garantizar la entrega ordenada, entonces el rendimiento de la escritura y la lectura de mensajes puede ser similar al de Pulsar. Sin embargo, si los consumidores no usan el offset de los mensajes, entonces el rendimiento de la escritura y la lectura de mensajes puede ser superior en Kafka.

En general, la mejor plataforma para una aplicación determinada dependerá de las necesidades específicas de la aplicación. Si la aplicación requiere una entrega ordenada de los mensajes, entonces Pulsar es una buena opción. Si la aplicación no requiere una entrega ordenada de los mensajes, entonces Kafka puede ser una mejor opción.

Aquí hay algunos factores que pueden afectar al rendimiento de la escritura y la lectura de mensajes en Kafka y Pulsar:

El número de particiones: Cuanto mayor sea el número de particiones, menor será el rendimiento de la escritura y la lectura de mensajes.
El tamaño de los mensajes: Cuantos más grandes sean los mensajes, menor será el rendimiento de la escritura y la lectura de mensajes.
El número de consumidores: Cuantos más consumidores haya, menor será el rendimiento de la escritura y la lectura de mensajes.
En general, es importante realizar pruebas para determinar la plataforma que ofrece el mejor rendimiento para una aplicación determinada.