apache kafka - applications - Modelado de datos con Kafka? Temas y Particiones

apache kafka windows (4)

Al estructurar sus datos para Kafka, realmente depende de cómo debe consumirse.

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, así que en el ejemplo anterior, solo tendría un tema en particular y si decides impulsar algún otro tipo de datos a través de Kafka, puede agregar un nuevo tema para más tarde.

Los temas se registran en ZooKeeper, lo que significa que puede tener problemas si intenta agregar demasiados, por ejemplo, el caso en que tiene un millón de usuarios y ha decidido crear un tema por usuario.

Por otro lado, las particiones 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 dar sentido a la función de partición. Los consumidores en 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 preocupe por los mensajes en la partición en sí "asignada".

El particionamiento puede establecerse 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 de las primeras cosas 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 debería estructurar mis datos?".

He leído y visto algunos materiales de introducción. 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 se asocian 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"}

¿El tema debe basarse en user-id ? viewed ? at ? ¿Qué hay de la partición?

¿Cómo decido?

Creo que el nombre del tema es la conclusión de un tipo de mensaje y el productor publica el mensaje al tema y el consumidor se suscribe 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, líder y seguidor también se dice en el nivel de partición. En realidad, una partición es una cola ordenada que es el orden en el que ha llegado el mensaje. Y el tema está compuesto por una o más colas en una palabra simple. Esto es útil para nosotros para modelar nuestra estructura.

Kafka es desarrollado por LinkedIn para la agregación y entrega de registros. esta escena es muy buena como ejemplo.

Los eventos del usuario en su web o aplicación pueden ser registrados por su servidor web y luego enviados a Kafka Broker a través del productor. En productor, puede especificar el método de partición, por ejemplo: tipo de evento (evento diferente se guarda en diferentes particiones) o tiempo de evento (partición por día en 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.

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

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 tema / partición en Kafka, this blog podría ser útil.

Puntos 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 producción sea p y el consumo sea c . Digamos que el rendimiento objetivo es t . Entonces necesitas tener al menos particiones máximas ( t / p , t / c ).
Actualmente, en Kafka, cada intermediario 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, más alta es 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 al decir que había too many files are open , mientras que teníamos alrededor de 3600 particiones de temas.
Cuando un intermediario se cierra imprudentemente (por ejemplo, kill -9), la indisponibilidad observada podría ser proporcional al número de particiones.
La latencia de extremo a extremo 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 intermediario a 100 x b x r , donde b es el número de intermediarios en un clúster de Kafka yr es el factor de replicación.

Una vez que sepa cómo particionar su secuencia de eventos, el nombre del tema será fácil, así que vamos a responder esa pregunta primero.

@Ludd es correcto: la estructura de partición que elijas dependerá en gran medida de cómo quieras procesar la secuencia de eventos. Lo ideal es que desee una clave de partición, lo que significa que el procesamiento de su evento es local de partición .

Por ejemplo:

Si te preocupa el tiempo promedio en el sitio de los usuarios, entonces debes dividir por :user-id . De esta forma, 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 simplemente observando los eventos en una sola partición. Esto evita tener que realizar cualquier tipo de partición costosa : procesamiento global
Si le importan las páginas más populares de su sitio web, debe particionar por la página :viewed . Una vez más, Samza podrá contar las vistas de una página determinada simplemente observando los eventos en una sola partición

En general, tratamos de evitar tener que depender del estado global (como mantener conteos en una base de datos remota como DynamoDB o Cassandra) y, en su lugar, podemos trabajar usando el estado de partición local. Esto se debe a que el estado local es una primitiva fundamental en el procesamiento de flujo .

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

En los nombres de los temas, uno obvio aquí sería events o events user-events . Para ser más específico, puede ir con events-by-user-id y / o events-by-viewed .