Apache Kafka vs.Apache Pulsar: cómo elegir

En estos días, la mensajería pub / sub masivamente escalable es virtualmente sinónimo de Apache Kafka. Apache Kafka sigue siendo la opción sólida, de código abierto y de referencia para aplicaciones de transmisión distribuida, ya sea que esté agregando algo como Apache Storm o Apache Spark para procesar o utilizando las herramientas de procesamiento proporcionadas por el propio Apache Kafka. Pero Kafka no es el único juego en la ciudad.

Desarrollado por Yahoo y ahora un proyecto de la Apache Software Foundation, Apache Pulsar busca la corona de mensajería que Apache Kafka ha usado durante muchos años. Apache Pulsar ofrece el potencial de un rendimiento más rápido y una latencia más baja que Apache Kafka en muchas situaciones, junto con una API compatible que permite a los desarrolladores cambiar de Kafka a Pulsar con relativa facilidad. 

¿Cómo elegir entre el venerable Apache Kafka y el advenedizo Apache Pulsar? Veamos sus ofertas centrales de código abierto y lo que aportan las ediciones empresariales de los mantenedores centrales.

Apache Kafka

Desarrollado por LinkedIn y lanzado como código abierto en 2011, Apache Kafka se ha extendido por todas partes, convirtiéndose prácticamente en la opción predeterminada para muchos cuando piensan en agregar un bus de servicio o un sistema de pub / subs a una arquitectura. Desde el debut de Apache Kafka, el ecosistema de Kafka ha crecido considerablemente, agregando Scheme Registry para hacer cumplir los esquemas en la mensajería de Apache Kafka, Kafka Connect para una transmisión sencilla desde otras fuentes de datos como bases de datos a Kafka, Kafka Streams para el procesamiento de transmisiones distribuidas y, más recientemente, KSQL para realizar consultas de tipo SQL sobre temas de Kafka. (Un tema en Kafka es el nombre de un canal en particular).

El caso de uso estándar para muchas canalizaciones en tiempo real construidas en los últimos años ha sido enviar datos a Apache Kafka y luego usar un procesador de flujo como Apache Storm o Apache Spark para extraer datos, realizar y procesar, y luego publicar salida a otro tema para el consumo posterior. Con Kafka Streams y KSQL, todas sus necesidades de canalización de datos se pueden manejar sin tener que abandonar el proyecto Apache Kafka en cualquier momento, aunque, por supuesto, aún puede utilizar un servicio externo para procesar sus datos si es necesario.

Si bien Apache Kafka siempre ha sido muy amigable desde el punto de vista del desarrollador, operacionalmente ha sido una especie de bolsa mixta. Poner en funcionamiento un clúster pequeño es relativamente fácil, pero mantener un clúster grande a menudo está plagado de problemas (por ejemplo, el intercambio de partición líder después de una falla del corredor de Kafka).

Además, el enfoque adoptado para respaldar la tenencia múltiple, a través de una utilidad llamada MirrorMaker, ha sido una forma segura de lograr que los SRE se tomen el pelo. De hecho, MirrorMaker se considera un problema tal que empresas como Uber han creado su propio sistema para replicar en los centros de datos (uReplicator). Confluent incluye Confluent Replicator como parte de su oferta empresarial de Apache Kafka. Hablando como alguien que ha tenido que mantener una configuración de MirrorMaker, es una pena que Replicator no sea parte de la versión de código abierto.

Sin embargo, definitivamente no todas son malas noticias en el frente operativo. Se ha trabajado mucho en la actual serie Apache Kafka 1.x para reducir algunos de los dolores de cabeza de ejecutar un clúster. Recientemente, ha habido algunos cambios que permiten que el sistema ejecute grandes grupos de más de 200,000 particiones de una manera más ágil, y mejoras como agregar colas de "letra muerta" a Kafka Connect hacen que la identificación y recuperación de problemas en fuentes de datos y sumideros sea tan importante. más fácil. También es probable que veamos soporte a nivel de producción para ejecutar Apache Kafka en Kubernetes en 2019 (a través de gráficos de Helm y un operador de Kubernetes).

En 2014, tres de los desarrolladores originales de Kafka (Jun Rao, Jay Kreps y Neha Narkhede) formaron Confluent, que proporciona funciones empresariales adicionales en su plataforma Confluent, como el Replicator, el Centro de control, los complementos de seguridad adicionales y la oferta habitual de soporte y servicios profesionales. Confluent también tiene una oferta en la nube, Confluent Cloud, que es un servicio de Confluent Platform totalmente administrado que se ejecuta en Amazon Web Services o Google Cloud Platform, si prefiere no lidiar con algunos de los gastos generales operativos de ejecutar clústeres usted mismo.

Si está atrapado en AWS y utiliza los servicios de Amazon, tenga en cuenta que Amazon ha presentado una vista previa pública de Amazon Managed Streaming para Kafka (MSK), que es un servicio Kafka completamente administrado dentro del ecosistema de AWS. (Tenga en cuenta también que Amazon MSK no se proporciona en asociación con Confluent, por lo que ejecutar MSK no le brindará todas las funciones de la plataforma Confluent, sino solo las que se proporcionan en el código abierto Apache Kafka).

Apache Pulsar

Dada la predilección de Apache Software Foundation por seleccionar proyectos que parecen duplicar la funcionalidad (¿le gustaría Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark o Apache Storm para sus necesidades de procesamiento de datos de gráficos acíclicos dirigidos?), perdónese por mirar más allá de los anuncios sobre Apache Pulsar convirtiéndose en un proyecto Apache de alto nivel antes de seleccionar Apache Kafka como una opción confiable para sus necesidades de mensajería. Pero Apache Pulsar merece una mirada.

Apache Pulsar nació en Yahoo, donde se creó para abordar las necesidades de la organización que otras ofertas de código abierto no podían proporcionar en ese momento. Como resultado, Pulsar se creó desde cero para manejar millones de temas y particiones con soporte completo para la replicación geográfica y la tenencia múltiple.

Bajo las sábanas, Apache Pulsar usa Apache BookKeeper para mantener sus necesidades de almacenamiento, pero hay un giro: Apache Pulsar tiene una función llamada Almacenamiento por niveles que es bastante. Uno de los problemas de los sistemas de registro distribuidos es que, si bien desea que los datos permanezcan en la plataforma de registro durante el mayor tiempo posible, las unidades de disco no tienen un tamaño infinito. En algún momento, toma la decisión de eliminar esos mensajes o almacenarlos en otro lugar, donde potencialmente se pueden reproducir a través de la canalización de datos si es necesario en el futuro. Lo que funciona, pero puede resultar complicado desde el punto de vista operativo. Apache Pulsar, a través de Tiered Storage, puede mover automáticamente datos más antiguos a Amazon S3, Google Cloud Storage o Azure Blog Storage, y aún presentar una vista transparente al cliente;el cliente puede leer desde el principio del tiempo como si todos los mensajes estuvieran presentes en el registro.

Al igual que Apache Kafka, Apache Pulsar ha desarrollado un ecosistema para el procesamiento de datos (aunque también proporciona adaptadores para Apache Spark y Apache Storm). Pulsar IO es el equivalente de Kafka Connect para conectarse a otros sistemas de datos como fuentes o sumideros, y Pulsar Functions proporciona la funcionalidad de procesamiento de datos. Las consultas SQL se proporcionan mediante un adaptador para el motor Presto de código abierto de Facebook.

Un aspecto interesante es que Pulsar Functions y Pulsar IO se ejecutan dentro de un clúster Pulsar estándar en lugar de ser procesos separados que podrían ejecutarse en cualquier lugar. Si bien se trata de una reducción de la flexibilidad, simplifica mucho las cosas desde un punto de vista operativo. (Hay un modo de ejecución local del que se podría abusar para ejecutar funciones fuera del clúster, pero la documentación hace todo lo posible para decir "¡No hagas esto!")

Apache Pulsar también ofrece diferentes métodos para ejecutar funciones dentro del clúster: se pueden ejecutar como procesos separados, como contenedores Docker o como subprocesos que se ejecutan en un proceso JVM de un corredor. Esto se relaciona con el modelo de implementación de Apache Pulsar, que ya es compatible con Kubernetes o Mesosphere DC / OS en producción. Una cosa a tener en cuenta es que Pulsar Functions, Pulsar IO y SQL son adiciones relativamente nuevas a Apache Pulsar, así que espere algunos bordes afilados si los usa.

También hay un contenedor de API limitado, solo compatible con Java y Kafka, por lo que puede integrar potencialmente las aplicaciones Apache Kafka existentes en una infraestructura Apache Pulsar. Esto probablemente sea más adecuado para pruebas exploratorias y un plan de migración provisional que una solución de producción, ¡pero es bueno tenerlo!

De manera similar a Confluent, los desarrolladores de Apache Pulsar en Yahoo (Matteo Merli y Sijie Guo) han formado una empresa derivada, Streamlio, donde son cofundadores junto con los creadores de Apache Heron (Karthik Ramasamy y Sanjeev Kulkarni). . La oferta empresarial de Streamlio incluye el soporte comercial habitual y las soluciones de servicios profesionales, junto con una consola de administración de código cerrado, pero cosas como el soporte de múltiples inquilinos eficiente y duradero son parte del producto central de código abierto.

Apache Kafka o Apache Pulsar?

Apache Kafka es un producto maduro, resistente y probado en batalla. Tiene clientes escritos en casi todos los idiomas populares, así como una gran cantidad de conectores compatibles para diferentes fuentes de datos en Kafka Connect. Con los servicios administrados que ofrecen Amazon y Confluent, es fácil poner en marcha, ejecutar y mantener un gran clúster de Kafka, mucho más fácil que en años anteriores. Sigo usando Apache Kafka en nuevos proyectos, y probablemente lo seguiré haciendo durante muchos años.

Sin embargo, si va a crear un sistema de mensajería que debe ser multiinquilino o replicar geográficamente desde el principio, o que tiene grandes necesidades de almacenamiento de datos, además de la necesidad de consultar y procesar fácilmente todos esos datos sin importar cómo hace mucho tiempo en el pasado, entonces sugiero patear los neumáticos de Apache Pulsar. Definitivamente se adapta a algunos casos de uso con los que Apache Kafka puede tener problemas, al mismo tiempo que funciona bien en términos de las características principales que necesita de una plataforma de registro distribuida. Y si no le importa estar a la vanguardia en términos de documentación y respuestas a las preguntas de Stack Overflow, ¡mucho mejor!