Modélisation des données avec Kafka ? Sujets et partitions

Question

L'une des premières choses auxquelles je pense lorsque j'utilise un nouveau service (tel qu'un magasin de données non-RDBMS ou une file de messages) est la suivante : "Comment dois-je structurer mes données ?".

J'ai lu et regardé quelques documents d'introduction. En particulier, prenez, par exemple, Kafka : un système de messagerie distribué pour le traitement des journaux. qui écrit :

• "un Sujet est le conteneur avec lequel les messages sont associés"
• "la plus petite unité de parallélisme est la partition d'un sujet. Cela implique que tous les messages qui ... appartiennent à une partition particulière d'un sujet seront consommés par un consommateur dans un groupe de consommateurs."

Sachant cela, quel serait un bon exemple illustrant l'utilisation des sujets et des partitions ? Quand un élément doit-il être un sujet ? Quand un élément doit-il être une partition ?

A titre d'exemple, disons que mes données (Clojure) ressemblent à :

{: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"}

Le sujet doit-il être basé sur user-id ? viewed ? at ? Et la partition ?

Comment puis-je décider ?

Answer 1

Une fois que vous savez comment partitionner votre flux d'événements, le nom du sujet sera facile, alors répondons d'abord à cette question.

@Ludd a raison - la structure de partition que vous choisirez dépendra largement de la façon dont vous voulez traiter le flux d'événements. Idéalement, vous voulez une clé de partition qui signifie que votre traitement des événements est partition-local .

Par exemple :

1. Si vous vous intéressez au temps moyen passé par les utilisateurs sur le site, vous devez diviser par :user-id . Ainsi, tous les événements liés à l'activité du site d'un seul utilisateur seront disponibles au sein d'une même partition. Cela signifie qu'un moteur de traitement de flux tel que Apache Samza peut calculer le temps moyen passé sur place pour un utilisateur donné en examinant simplement les événements d'une seule partition. Cela permet d'éviter d'avoir à effectuer des calculs coûteux. partition-globale traitement
2. Si vous vous préoccupez des pages les plus populaires de votre site web, vous devriez vous cloisonner par le :viewed page. Là encore, Samza pourra tenir le compte des consultations d'une page donnée en examinant simplement les événements d'une seule partition.

En général, nous essayons d'éviter d'avoir à compter sur un état global (tel que la conservation des comptes dans une base de données distante comme DynamoDB ou Cassandra), et de pouvoir travailler en utilisant l'état local de la partition. Cela est dû au fait que L'état local est une primitive fondamentale dans le traitement en flux. .

Si vous avez besoin des deux cas d'utilisation ci-dessus, alors un modèle commun avec Kafka est de partitionner d'abord par disons :user-id et ensuite à re-partitionner par :viewed prêt pour la phase suivante du traitement.

Sur les noms de sujets - un nom évident ici serait events ou user-events . Pour être plus précis, vous pourriez utiliser events-by-user-id et/ou events-by-viewed .

Answer 2

Ceci n'est pas exactement lié à la question, mais au cas où vous avez déjà décidé de la séparation logique des enregistrements en fonction des sujets, et que vous voulez optimiser le nombre de sujets/partitions dans Kafka, ce Cet article de blog pourrait vous être utile.

Les principaux points à retenir en bref :

• En général, plus il y a de partitions dans un cluster Kafka, plus le débit que l'on peut atteindre est élevé. Soit le débit maximal réalisable sur une seule partition pour la production, soit p et la consommation être c . Disons que votre débit cible est de t . Alors vous devez avoir au moins max( t / p , t / c ) partitions.

• Actuellement, dans Kafka, chaque broker ouvre un handle de fichier à la fois de l'index et du fichier de données de chaque segment de log. Donc, plus il y a de partitions, plus il faut configurer la limite d'ouverture de handle de fichier dans le système d'exploitation sous-jacent. Par exemple, dans notre système de production, nous avons vu une fois une erreur disant too many files are open alors que nous avions environ 3600 partitions de sujets.

• Lorsqu'un courtier est arrêté sans ménagement (par exemple, kill -9), l'indisponibilité observée pourrait être proportionnelle au nombre de partitions.

• La latence de bout en bout dans Kafka est définie par le temps écoulé entre le moment où un message est publié par le producteur et celui où le message est lu par le consommateur. En règle générale, si vous vous souciez de la latence, il est probablement judicieux de limiter le nombre de partitions par courtier à 100 x b x r où b est le nombre de brokers dans un cluster Kafka et r est le facteur de réplication.

Answer 3

Je pense que le nom du sujet est une conclusion d'un type de messages, et que le producteur publie un message dans le sujet et que le consommateur s'abonne au message par le biais du sujet d'abonnement.

Un sujet peut avoir plusieurs partitions. La partition est bonne pour le parallélisme. La partition est aussi l'unité de réplication, donc dans Kafka, le leader et le suiveur sont aussi dits au niveau de la partition. En fait, une partition est une file d'attente ordonnée dont l'ordre correspond à l'ordre d'arrivée des messages. Et le sujet est composé d'une ou plusieurs files d'attente en un mot simple. Cela nous est utile pour modéliser notre structure.

Kafka est développé par LinkedIn pour l'agrégation et la diffusion des journaux. Cette scène est un très bon exemple.

Les événements de l'utilisateur sur votre web ou application peuvent être enregistrés par votre serveur web et ensuite envoyés au courtier Kafka par le producteur. Dans le producteur, vous pouvez spécifier la méthode de partition, par exemple : le type d'événement (chaque événement est enregistré dans une partition différente) ou l'heure de l'événement (partitionner un jour en différentes périodes selon la logique de votre application) ou le type d'utilisateur ou simplement aucune logique et équilibrer tous les journaux dans plusieurs partitions.

Pour votre cas en question, vous pouvez créer un sujet appelé "page-view-event", et créer N partitions par le biais de clés de hachage pour distribuer les journaux dans toutes les partitions de manière égale. Ou vous pouvez choisir une logique de partition pour faire la distribution des logs par votre esprit.