Cómo elegir entre kafka-python y confluent-kafka

kafka-python: El Salvaje Oeste

kafka-python es el cliente Kafka Python más popular. Nunca hemos tenido problemas al usarlo en el pasado y también lo usé en mi libro Agile Data Science 2.0. Sin embargo, en este proyecto reciente, encontró un problema grave. Descubrimos que cuando KafkaConsumer se usa de manera documentada y el consumidor obtiene mensajes de la cola de mensajes de forma iterativa, los mensajes transportados por el consumidor que eventualmente llegan al tema generalmente se pierden. Verificamos esto a través del análisis del consumidor de la consola.

Para explicarlo con más detalle, kafka-python y KafkaConsumer se utilizan junto con un servicio Kafka protegido por SSL (como Aiven Kafka), de la siguiente manera:

kafka_consumer = KafkaConsumer(

tema,

enable_auto_commit=True,

group_id=group_id,

bootstrap_servers=config.kafka.host,

p>

api_version=(0, 10),

security_protocol='SSL',

ssl_check_hostname=True,

ssl_cafile=config .kafka_pem,

ssl_certfile=config.kafka.service_cert,

ssl_keyfile=config.kafka.service_key

)

para mensaje en kafka_consumer:

application_message = json.loads(message.value.decode())

...

Cuando se usa de esta forma recomendada, KafkaConsumer Se perderán mensajes. Pero existe una solución alternativa: conservar todos los mensajes. Esta solución nos la proporciona el soporte de Aiven, proveedor de servicios de Kafka. Se ve así:

mientras es Verdadero:

raw_messages = consumer.poll(timeout_ms=1000, max_records=5000)

para topic_partition, mensajes en raw_messages. items():

application_message = json.loads(message.value.decode())

...

Aunque esta solución alternativa puede funcionar, pero el El método en README descarta el mensaje y pierdo interés en él. Entonces encontré una alternativa.

confluent-kafka: soporte empresarial

Me sorprendió gratamente cuando descubrí el módulo Python de coufluent-kafka. Se puede utilizar como paquete exterior de librdkafka y es muy compacto. librdkafka es una biblioteca kafka escrita en lenguaje C, que es la base de Go y .NET. Además, funciona con Confluent.

Me encanta el código abierto, pero cuando "propiedad informal o apoyado por la comunidad" no es suficiente, tal vez sea hora de considerar darle a la alternativa el sello oficial de propiedad o soporte de una empresa. Sin embargo, no adquirimos soporte comercial. Sabemos que alguien mantendrá la calidad del software de esta biblioteca y es fantástico tener la opción de comprar o no soporte comercial.

Es muy sencillo sustituir kafka-python por confluent-kafka. confluent-kafka utiliza el método de encuesta, que es similar a la solución alternativa mencionada anteriormente para acceder a kafka-python.

kafka_consumer = Consumidor(

{

"api.version.request": Verdadero,

"enable.auto.commit" : Verdadero,

"group.id": group_id,

"bootstrap.servers": config.kafka.host,

"security.protocol": "ssl",

"ssl.ca.location": config.kafka.ca_pem,

"ssl.certificate.location": config.kafka.service_cert,

"ssl.key.location": config.kafka.service_key,

"default.topic.config": {"auto.offset.reset": "más pequeño"}

}

)

consumer.subscribe([topic])

# Ahora haga un bucle en el consumidor para leer los mensajes

en ejecución = Verdadero

durante la ejecución:

mensaje = kafka_consumer.poll()

application_message = json.load(message.value.decode())

kafka_consumer.close()

Ahora podemos recibir todos los mensajes. No digo que la herramienta kafka-python sea mala, creo que la comunidad reaccionará ante sus problemas y los resolverá. Pero de ahora en adelante me limitaré a confluente-kafka.

Gobernanza de código abierto

El código abierto es poderoso, pero cuando se trata de herramientas complejas de "grandes datos" y NoSQL, generalmente es necesario que haya una gran empresa detrás del desarrollo de la herramienta. De esa manera sabrás que si la herramienta está disponible para esa empresa, debería tener una buena funcionalidad básica. Su aparición puede ser informal, como cuando una empresa lanza un proyecto como software libre, pero también puede ser formal, como cuando una empresa proporciona soporte comercial para una herramienta. Eso sí, mirándolo desde otra perspectiva, si una empresa que trabaja en contra de la comunidad de código abierto se encarga de desarrollar una herramienta, pierdes el control. Es posible que su opinión no importe a menos que sea un cliente que paga.

La situación ideal sería adoptar una gobernanza de código abierto, como la Fundación Apache, y aumentar el número de opciones de soporte comercial disponibles. Esto simplemente no es posible con la mayoría del software gratuito en Internet. Limitarse a herramientas que tengan el sello de aprobación de su empresa limitará gravemente su libertad. Esta puede ser la elección correcta para algunas tiendas, pero no para nosotros. Me encanta probar herramientas, y si la herramienta es pequeña y hace una cosa, la usaré.

Confíe en el código abierto

Para herramientas más grandes, el proceso de evaluación de decisiones anterior es más complejo. Normalmente, miro la cantidad de problemas de confirmación y contribuyentes, así como la fecha de la última confirmación. Podría preguntarle a un amigo sobre una herramienta o, a veces, en Twitter. Cuando seleccionas un proyecto de Github después de realizar una verificación, confías en que la comunidad producirá buenas herramientas. Para la mayoría de las herramientas esto no supone ningún problema.

Pero confiar en las comunidades puede ser problemático. Para una herramienta en particular, puede que no haya una buena razón para confiar en que la comunidad produzca un buen software. Las comunidades varían en cuanto a objetivos, experiencia y tiempo dedicado a proyectos de código abierto. Es importante tener cuidado al seleccionar herramientas y no permitir que los ideales nublen su juicio.