¿Modelado de datos con Kafka? Temas y particiones

Una de las primeras cosas en las que pienso cuando uso un nuevo servicio (como un almacén de datos que no es RDBMS o una cola de mensajes) es: "¿Cómo debo estructurar mis datos?".

He leído y visto algunos materiales introductorios. En particular, tome, por ejemplo, Kafka: un sistema de mensajería distribuida para el procesamiento de registros , que escribe:

• "un tema es el contenedor con el que están asociados los mensajes"
• "La unidad más pequeña de paralelismo es la partición de un tema. Esto implica que todos los mensajes que ... pertenecen a una partición particular de un tema serán consumidos por un consumidor en un grupo de consumidores".

Sabiendo esto, ¿cuál sería un buen ejemplo que ilustra cómo usar temas y particiones? ¿Cuándo debería ser algo un tema? ¿Cuándo debería ser algo una partición?

Como ejemplo, digamos que mis datos (Clojure) se ven así:

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

¿Debería basarse el tema user-id? viewed? at? ¿Qué hay de la partición?

¿Cómo decido?

Al estructurar sus datos para Kafka, realmente depende de cómo se consuma.

En mi opinión, un tema es una agrupación de mensajes de un tipo similar que será consumido por el mismo tipo de consumidor, por lo que en el ejemplo anterior, solo tendría un solo tema y si decides impulsar otro tipo de datos a través de Kafka, puede agregar un nuevo tema para eso más adelante.

Los temas están registrados en ZooKeeper, lo que significa que puede tener problemas si intenta agregar demasiados, por ejemplo, en el caso de que tenga un millón de usuarios y haya 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 intermediarios debe ser al menos igual al número de consumidores en un grupo de consumidores para que la función de partición tenga sentido. Los consumidores en un grupo de consumidores dividirán la carga de procesar el tema entre ellos de acuerdo con la partición para que un consumidor solo se preocupe por los mensajes en la partición en sí "asignados".

La partición se puede establecer explícitamente utilizando una clave de partición 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 secuencia 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 la secuencia de eventos. Idealmente, desea una clave de partición, lo que significa que el procesamiento de su evento es partición local .

Por ejemplo:

1. Si le importa el tiempo promedio 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 determinado con solo mirar los eventos en una sola partición. Esto evita tener que realizar ningún tipo de procesamiento costoso de partición global
2. Si le interesan las páginas más populares de su sitio web, debe dividirlas por :viewedpágina. Una vez más, 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, estamos tratando de evitar tener que depender del estado global (como mantener los recuentos en una base de datos remota como DynamoDB o Cassandra) y, en su lugar, poder trabajar utilizando el estado local de partición. Esto se debe a que el estado local es una primitiva fundamental en el procesamiento de flujo .

Si necesita tanto de los casos de uso anteriores, entonces un patrón común con Kafka es a primera partición por ejemplo :user-id, y luego a volver a la partición por :viewedlisto para la siguiente fase de procesamiento.

Sobre los nombres de los temas, uno obvio aquí sería eventso user-events. Para ser más específico, podría ir con events-by-user-idy / 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 los registros en función de los temas y desee optimizar el recuento de temas / particiones en Kafka, este 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 p y el consumo sea c . Digamos que su rendimiento objetivo es t . Entonces necesita tener al menos max ( t / p , 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. Por lo tanto, cuantas más particiones, mayor será la necesidad de configurar el límite de identificador de archivo abierto 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 teníamos alrededor de 3600 particiones temáticas.

• Cuando un broker se cierra impuro (p. Ej., Kill -9), la indisponibilidad observada podría ser proporcional al número de particiones.

• La latencia de extremo a extremo en Kafka se define desde el momento en que el productor publica un mensaje hasta que el consumidor lo lee. Como regla general, si le importa 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 grupo de Kafka y r es el factor de replicación.

Creo que el nombre del tema es una conclusión de un tipo de mensajes, y el mensaje de publicación del productor al tema y el mensaje de suscripción del consumidor a través del tema de suscripción.

Un tema podría tener muchas particiones. La partición es buena para el paralelismo. la partición también es la unidad de replicación, por lo que en Kafka, el líder y el seguidor también se dice a nivel de partición. En realidad, una partición es una cola ordenada cuyo orden es el pedido recibido del mensaje. Y el tema está compuesto por una o más colas en una palabra simple. Esto nos sirve para modelar nuestra estructura.

LinkedIn desarrolla Kafka para la agregación y entrega de registros. Esta escena es muy buena como ejemplo.

Su servidor web puede registrar los eventos del usuario en su web o aplicación y luego enviarlos al agente de Kafka a través del productor. En el productor, puede especificar el método de partición, por ejemplo: tipo de evento (un evento diferente se guarda en una partición diferente) o tiempo de evento (partición de un día en un período diferente según la lógica de su aplicación) o tipo de usuario o simplemente no lógica y equilibrar todos los registros en muchas particiones.

Sobre su caso en cuestión, puede crear un tema llamado "page-view-event" y crear N particiones a través de claves hash para distribuir los registros en todas las particiones de manera uniforme. O puede elegir una lógica de partición para que su espíritu distribuya los registros.