Encontramos el hallazgo a esta dificultad, o por lo menos eso deseamos. Si presentas interrogantes coméntalo, que con placer te ayudaremos
Solución:
Al estructurar sus datos para Kafka, realmente depende de cómo se vayan a consumir.
En mi opinión, un tema es una agrupación de mensajes de un tipo similar que serán consumidos por el mismo tipo de consumidor, por lo que en el ejemplo anterior, solo tendría un solo tema y si decides impulsar algún otro tipo de datos a través de Kafka, puede agregar un nuevo tema para eso más adelante.
Los temas se registran en ZooKeeper, lo que significa que puede tener problemas si intenta agregar demasiados, por ejemplo, el caso en el que tiene un millón de usuarios y ha decidido crear un tema por usuario.
Las particiones, por otro lado, son una forma de paralelizar el consumo de los mensajes y el número total de particiones en un clúster de agentes debe ser al menos el mismo que el número de consumidores en un grupo de consumidores para entender la función de partición. Los consumidores de un grupo de consumidores dividirán la carga de procesar el tema entre ellos de acuerdo con la partición, de modo que un consumidor solo se ocupará de los mensajes en la partición a la que está “asignada”.
El particionamiento se puede configurar explícitamente mediante una partición key en el lado del productor o si no se proporciona, se seleccionará una partición aleatoria para cada mensaje.
Una vez que sepa cómo particionar su flujo de eventos, el nombre del tema será fácil, así que respondamos esa pregunta primero.
@Ludd es correcto: la estructura de partición que elija dependerá en gran medida de cómo desee procesar el flujo de eventos. Idealmente quieres una partición key lo que significa que el procesamiento de su evento es partición-local.
Por ejemplo:
- Si le preocupa el tiempo promedio de permanencia en el sitio de los usuarios, entonces debe dividir por
:user-id. De esa manera, todos los eventos relacionados con la actividad del sitio de un solo usuario estarán disponibles dentro de la misma partición. Esto significa que un motor de procesamiento de flujo como Apache Samza puede calcular el tiempo promedio en el sitio para un usuario dado con solo mirar los eventos en una sola partición. Esto evita tener que realizar cualquier tipo de costoso partición global Procesando - Si le interesan las páginas más populares de su sitio web, debe dividir por
:viewedpágina. Nuevamente, Samza podrá llevar un recuento de las vistas de una página determinada con solo mirar los eventos en una sola partición.
En general, intentamos evitar tener que depender del estado global (como mantener recuentos en una base de datos remota como DynamoDB o Cassandra) y, en su lugar, poder trabajar utilizando el estado local de la partición. Esto se debe a que el estado local es una primitiva fundamental en el procesamiento de flujos.
Si necesita los dos casos de uso anteriores, entonces un patrón común con Kafka es dividir primero por ejemplo :user-id, y luego a volver a particionar por :viewed listo para la siguiente fase de procesamiento.
Sobre los nombres de los temas, uno obvio aquí sería events o user-events. Para ser más específico, podría ir con events-by-user-id y / o events-by-viewed.
Esto no está exactamente relacionado con la pregunta, pero en caso de que ya haya decidido la segregación lógica de registros según los temas y desee optimizar el recuento de temas / particiones en Kafka, esta publicación de blog puede ser útil.
Conclusiones clave en pocas palabras:
-
En general, cuantas más particiones haya en un clúster de Kafka, mayor será el rendimiento que se puede lograr. Deje que el máximo alcanzable en una sola partición para la producción sea pags y el consumo sea C. Digamos que su rendimiento objetivo es t. Entonces necesitas tener al menos max (t/pags, t/C) particiones.
-
Actualmente, en Kafka, cada corredor abre un identificador de archivo tanto del índice como del archivo de datos de cada segmento de registro. Entonces, cuantas más particiones, más alto es el que se necesita para configurar el límite de manejo de archivos abiertos en el sistema operativo subyacente. Por ejemplo, en nuestro sistema de producción, una vez vimos un error que decía
too many files are open, mientras que teníamos alrededor de 3600 particiones temáticas. -
Cuando un corredor se cierra de manera no limpia (por ejemplo, kill -9), la indisponibilidad observada podría ser proporcional al número de particiones.
-
La latencia de un extremo a otro en Kafka se define por el tiempo desde que el productor publica un mensaje hasta que el consumidor lo lee. Como regla general, si le preocupa la latencia, probablemente sea una buena idea limitar el número de particiones por corredor a 100 x B X r, donde B es el número de corredores en un clúster de Kafka y r es el factor de replicación.
Valoraciones y comentarios
Si tienes algún titubeo y capacidad de ascender nuestro escrito te invitamos dejar una apostilla y con gusto lo interpretaremos.