Uso de Apache Kafka
Apache Kafka es una plataforma de mensajería distribuida de publicación y suscripción de código abierto diseñada específicamente para manejar datos de transmisión en tiempo real para transmisión distribuida, canalización y reproducción de fuentes de datos para operaciones rápidas y escalables. Kafka es una solución basada en agentes que opera manteniendo flujos de datos como registros dentro de un cluster de servidores.
En los clusters de Big Data Service, Kafka se puede utilizar de las siguientes formas.
- Cree un cluster de perfil de Kafka:
- Crear Cluster.
- En el campo Perfil de cluster, seleccione Kafka.
- Cree un cluster de perfil Hadoop_Extended y agregue Kafka al cluster:
- Crear Cluster.
- En el campo Cluster profile (Perfil de cluster), seleccione Hadoop_Extended.
- Agregue Kafka al cluster.
Propiedades de configuración de Kafka
Propiedades de configuración de Kafka incluidas en Big Data Service 3.1.1 o posterior.
| Configuración | Propiedad | Descripción |
|---|---|---|
kafka-env |
kafka_opts |
Opciones de Kafka |
kerberos_param |
Parámetro de Kerberos de Kafka | |
kafka_jmx_opts |
Opciones de Kafka JMX | |
kafka_classpath |
Classpath de Kafka |
Mejores prácticas de Apache Kafka
Requisitos de hardware
Apache Kafka, para su funcionamiento normal, necesita una pequeña cantidad de recursos, especialmente con algunos ajustes de configuración. Por defecto, Kafka se puede ejecutar en 1 núcleo y 1 GB de memoria con almacenamiento escalado en función de los requisitos de retención de datos.
La CPU rara vez es un cuello de botella porque Kafka tiene mucha E/S. Sin embargo, una CPU de tamaño moderado con suficientes threads es importante para manejar conexiones simultáneas y tareas en segundo plano.
- Nodo de agente de Kafka: ocho núcleos, de 64 GB a 128 GB de RAM, dos o más discos de 2 TB (estándar 2,8 o superior, preferiblemente DenseIO o equivalente)
- Un mínimo de tres nodos de agente de Kafka
- Perfil de hardware: Más RAM y discos de alta velocidad son mejores
- Instale agentes de Kafka en nodos de trabajador, ya que pueden crecer horizontalmente en tamaño
Topología de cluster de Kafka recomendada
- Eliminar gestor de nodos del nodo de trabajador
- Debido a que los agentes de Kafka necesitan al menos tres nodos para la replicación/HA, podría considerar aprovisionar nodos de trabajador adicionales para Kafka.
- Aprovisione nodos de trabajador de HDFS adicionales y desactive el nodo de datos y el gestor de nodos. Nota
Los nodos de trabajador actuales se modelan después de los nodos de trabajador de HDFS, que se están reutilizando para los nodos de broker de Kafka. Por lo tanto, si los nodos de agente de Kafka se ejecutan junto con los nodos de datos de HDFS, HDFS pierde el almacenamiento efectivo.
Algunos parámetros comunes para ajustar al configurar Kafka son los siguientes:
| Funciones para ajustar | Parámetros para ajustar |
|---|---|
| Retención de Mensajes | Tamaño en disco |
| Rendimiento de cliente (productor y consumidor) | Capacidad de red |
| Rendimiento del productor | E/S de Disco |
| Rendimiento del consumidor | Memoria |
Estos parámetros varían de un caso a otro y deben configurarse cuidadosamente para lograr un mejor rendimiento. No hay una configuración única para todos los casos de uso.
ZooKeeper
ZooKeeper es un componente importante de un cluster de Kafka que actúa como un servicio de coordinación distribuido. ZooKeeper se encarga de supervisar y preservar los metadatos del cluster, coordinar las operaciones de muchos nodos y garantizar la estabilidad y coherencia generales del cluster de Kafka.
Los clusters de alta disponibilidad de Big Data Service incluyen tres hosts de Zookeeper. Sin embargo, para casos de uso de producción más grandes, recomendamos escalar horizontalmente los hosts de Zookeeper, ya que se comparten entre otros servicios con el cluster de Big Data Service.
Consideraciones sobre el rendimiento
Kafka está optimizado y listo para usar. Sin embargo, es necesario realizar algunos ajustes para mejorar el rendimiento del cluster. Considere dos métricas principales:
- Rendimiento: el número de mensajes que llegan en un tiempo determinado.
- Latencia: cantidad de tiempo que se tarda en procesar cada mensaje.
Agentes de ajuste
Puede controlar el número de particiones de un tema. El aumento del número de particiones y el número de agentes en un cluster conduce a un mayor paralelismo del consumo de mensajes, lo que a su vez mejora el rendimiento de un cluster de Kafka. Sin embargo, el tiempo necesario para replicar datos entre juegos de réplicas también aumenta.
Productores de Ajuste
Puede ejecutar un productor en dos modos diferentes: síncrono y asíncrono. En modo síncrono, tan pronto como se publica un mensaje, el productor envía una solicitud al broker. Por lo tanto, si está produciendo 100 mensajes por segundo, el productor envía 100 solicitudes por segundo al broker. Esto disminuye el rendimiento y actúa como una operación de bloqueo. Por lo tanto, al publicar un gran número de mensajes, es mejor ejecutar productores en modo asíncrono.
En el modo asíncrono, debe ajustar dos parámetros para obtener el mejor rendimiento: batch.size y linger.ms (tiempo de lector). El tamaño de lote es el tamaño de los datos que se enviarán en un lote, medido en bytes. Por ejemplo, si define el tamaño de lote en 100, el productor espera hasta que los mensajes suman hasta 100 bytes antes de realizar una llamada al broker. Si la producción de mensajes es baja y define un tamaño de lote alto, el productor espera mucho tiempo antes de producir mensajes. Esto reduce el rendimiento y aumenta la latencia de entrega de mensajes. Por lo tanto, según el número de mensajes que se produzcan, este valor se debe optimizar. El tamaño de lote por defecto es 16.384.
El tiempo de inactividad es otra métrica basada en cuándo un productor decide enviar una solicitud a un corredor. Con el ejemplo anterior, si el tamaño del lote se define en 100 bytes y solo se producen 50 bytes por segundo, el productor debe esperar dos segundos antes de publicar esos mensajes. Para evitar este retraso, puede ajustar el tiempo de espera (medido en milisegundos) para asegurarse de que el productor no espere demasiado antes de enviar mensajes. Si se establece el tiempo de espera en 500 ms en este ejemplo, el productor espera medio segundo como máximo.
La compresión también puede mejorar la latencia. Por defecto, los mensajes de Kafka no están comprimidos, pero puede configurar productores para que los compriman. A continuación, los agentes y los consumidores tienen la sobrecarga adicional de descomprimir mensajes, pero la latencia general debe reducirse a medida que el tamaño físico de los datos transmitidos a través de la red sea menor.
Ajuste de Consumidores
Los consumidores reciben mensajes en lotes, de forma similar a cómo los productores publican en lotes. Si se extraen muchos mensajes y se tarda mucho tiempo en procesar cada uno, el rendimiento se ve afectado. Del mismo modo, si sondea al broker por un único mensaje cada vez, el número de solicitudes al broker puede disminuir el rendimiento.
Tener más particiones y consumidores dentro de un grupo de consumidores puede ayudar a mejorar el rendimiento. Pero recuerde que a medida que aumenta el número de consumidores, también aumenta el número de solicitudes de compromiso de compensación al corredor. Puesto que la confirmación de un desplazamiento está enviando un mensaje de Kafka a un tema interno, esto aumenta la carga del broker de forma indirecta. Por lo tanto, tener un número óptimo de consumidores es crucial.
MirrorMaker Optimización del Rendimiento
Kafka MirrorMaker es una herramienta que se utiliza para duplicar los mensajes de Kafka de un centro de datos o cluster en otro. Debido a que esto está produciendo mensajes internamente a Kafka, la mayoría de las técnicas de optimización ya discutidas también son ciertas aquí. Debido a que esto también implica la transmisión de mensajes a largas distancias, hay algunos parámetros de configuración más que se pueden ajustar para un mejor rendimiento.
Al realizar el ajuste, asegúrese de basar sus acciones en las necesidades de su caso de uso de negocio.
- MirrorMaker2 Ubicación: MirrorMaker se puede instalar en el origen o en el destino. Sin embargo, recomendamos instalar en el destino porque producir mensajes a largas distancias aumenta las posibilidades de perder datos durante la transmisión.
- Compresión: por defecto, la compresión de mensajes en los productores de Kafka está definida en none. Sin embargo, para comprimir los mensajes que salen del origen al destino, cambie la compresión a gzip. Esto ayuda con tamaños de lote más grandes.
- Tamaño de lote: el aumento del tamaño de lote de los mensajes aumenta el rendimiento. La combinación de esto con la compresión garantiza que un gran número de mensajes se transmiten rápidamente. Si el tamaño de lote de destino está tardando más tiempo que el tiempo de espera configurado, los lotes que se envían no se rellenan por completo. Esto reduce la eficiencia de compresión y desperdicia ancho de banda. Por lo tanto, es importante ajustar el tamaño del lote junto con activar la compresión y ajustar el tiempo de espera.
- Tiempo de espera: Aumentar el tiempo de espera para permitir que los lotes se llenen por completo es importante. Esto puede aumentar la latencia, pero el rendimiento general mejora. Debe tener en cuenta la importancia de la latencia para su caso de uso empresarial.
- Aumentar el paralelismo: para aumentar aún más el rendimiento, puede desplegar varias instancias de MirrorMaker en el mismo grupo de consumidores. Esto facilita la recepción de varios consumidores MirrorMaker desde el mismo origen y la producción al destino en paralelo.
Configuraciones del servidor de producción en el ajuste de Kafka
Se pueden ajustar otros parámetros de configuración para mejorar el rendimiento de Kafka en un entorno de producción. Los siguientes parámetros mejoran el rendimiento de replicación de los mensajes dentro de las particiones:
num.replica.fetchers: especifica el número de threads utilizados para replicar mensajes del líder a los seguidores. Un mayor número de recuperadores de réplica mejora el paralelismo en la replicación.replica.fetch.max.bytes: indica el número de bytes de datos que se van a recuperar del líder. Un número mayor indica que se está recuperando una mayor parte de los datos, lo que mejora el rendimiento de la replicación.num.partitions: especifica el número máximo de consumidores que un tema puede tener en un grupo de usuarios específico, que es igual al número de particiones disponibles en ese tema. El aumento de las particiones aumenta el paralelismo y, por lo tanto, el rendimiento. Sin embargo, muchas particiones también consumen más recursos, por lo que también debe ampliar los recursos.
Equilibrio de clusters de Apache Kafka
Cada vez que se agrega un nuevo broker a un cluster de Kafka, las particiones existentes no se distribuyen a través del nuevo broker. Esto significa que el nuevo corredor no está ocupado, y si uno o más corredores antiguos caen, la replicación y los líderes potenciales se reducen. Esto se conoce como el sesgo de líder. Puede evitar esto asegurándose de que cualquier broker recién agregado obtenga una parte de las particiones. Es importante volver a equilibrar el cluster. Del mismo modo, si un broker tiene más del número medio de particiones para un tema, conocido como sesgo de broker, puede provocar problemas de rendimiento.
Optimización del rendimiento de Kafka
Al ejecutar Kafka como cluster, existen varias formas de optimizar su rendimiento. Puede ajustar varios parámetros de configuración para lograr un equilibrio entre el rendimiento y la latencia. La ingeniería consiste en calcular los mejores valores para algunos de estos parámetros, como el tiempo de espera, el tamaño del lote, el número de particiones, etc. En función del caso de uso, puede decidir que el rendimiento es más importante que la latencia, que la latencia es más importante que el rendimiento o que es mejor un equilibrio entre ambos.