Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Tables de métadonnées DynamoDB et équilibrage de charge dans KCL
KCLgère les métadonnées telles que les baux et les indicateurs CPU d'utilisation des travailleurs. KCLeffectue le suivi de ces métadonnées à l'aide de tables DynamoDB. Pour chaque application Amazon Kinesis Data StreamsKCL, créez trois tables DynamoDB afin de gérer les métadonnées : table des baux, table des métriques des travailleurs et table de l'état des coordinateurs.
Note
KCL3.x a introduit deux nouvelles tables de métadonnées : les métriques des travailleurs et les tables d'état des coordinateurs.
Important
Vous devez ajouter les autorisations appropriées pour que les KCL applications puissent créer et gérer des tables de métadonnées dans DynamoDB. Pour plus de détails, consultez IAMautorisations requises pour les applications KCL destinées aux consommateurs.
KCLl'application grand public ne supprime pas automatiquement ces trois tables de métadonnées DynamoDB. Assurez-vous de supprimer ces tables de métadonnées DynamoDB créées KCL par l'application client lorsque vous mettez celle-ci hors service afin d'éviter des coûts inutiles.
Tableau des baux
Une table de location est une table Amazon DynamoDB unique utilisée pour suivre les partitions louées et traitées par les planificateurs de l'application client. KCL Chaque application KCL client crée sa propre table de location. KCLutilise le nom de l'application client comme nom de la table des baux par défaut. Vous pouvez définir un nom de table personnalisé à l'aide de la configuration. KCLcrée également un index secondaire global sur la table des baux avec la clé de partition de leaseOwner pour une découverte efficace des baux. L'index secondaire global reflète l' leaseKey attribut de la table des baux de base. Si la table des baux de votre application KCL client n'existe pas au démarrage de l'application, l'un des travailleurs crée la table des baux pour votre application.
Vous pouvez consulter cette table à l'aide de la console Amazon DynamoDB lors que l'application est en cours d'exécution.
Important
-
Chaque nom d'application KCL client doit être unique afin d'éviter la duplication du nom de la table des baux.
-
Votre compte est facturé pour les coûts associés à la table DynamoDB, en plus des coûts associés au service Kinesis Data Streams lui-même.
Chaque ligne du tableau des baux représente une partition en cours de traitement par les planificateurs de votre application client. Les principaux champs sont les suivants :
-
leaseKey: pour le traitement en flux unique, il s'agit de l'ID de partition. Pour le traitement multi-flux avecKCL, il est structuré comme
account-id:StreamName:streamCreationTimestamp:ShardId. leaseKey est la clé de partition de la table des baux. Pour plus d'informations sur le traitement multiflux, consultezTraitement multi-flux avec KCL . -
checkpoint : le plus récent numéro de séquence de point de contrôle de la partition.
-
checkpointSubSequenceNuméro : lorsque vous utilisez la fonctionnalité d'agrégation de la bibliothèque Kinesis Producer, il s'agit d'une extension du point de contrôle qui permet de suivre les enregistrements utilisateur individuels au sein de l'enregistrement Kinesis.
-
leaseCounter: Utilisé pour vérifier si un travailleur traite actuellement activement le bail. leaseCounter augmente si la propriété du bail est transférée à un autre travailleur.
-
leaseOwner: Le travailleur actuel titulaire de ce bail.
-
ownerSwitchesSincePoint de contrôle : combien de fois ce bail a changé de travailleurs depuis le dernier point de contrôle.
-
parentShardId: ID du parent de cette partition. Assurez-vous que la partition parent est entièrement traitée avant que le traitement ne commence sur les partitions enfants, en maintenant le bon ordre de traitement des enregistrements.
-
childShardId: Liste des fragments enfants IDs résultant de la division ou de la fusion de ce fragment. Utilisé pour suivre la lignée des partitions et gérer l'ordre de traitement lors des opérations de repartage.
-
startingHashKey: limite inférieure de la plage de clés de hachage pour cette partition.
-
endingHashKey: limite supérieure de la plage de clés de hachage pour cette partition.
Si vous utilisez le traitement multi-flux avecKCL, les deux champs supplémentaires suivants s'affichent dans le tableau des baux. Pour de plus amples informations, veuillez consulter Traitement multi-flux avec KCL .
-
shardID : ID de la partition.
-
streamName: L'identifiant du flux de données au format suivant :
account-id:StreamName:streamCreationTimestamp.
Tableau des indicateurs relatifs aux travailleurs
La table des métriques des travailleurs est une table Amazon DynamoDB unique pour KCL chaque application et est utilisée pour CPU enregistrer les métriques d'utilisation de chaque travailleur. Ces indicateurs seront utilisés pour KCL effectuer des assignations de bail efficaces afin d'assurer une utilisation équilibrée des ressources entre les travailleurs. KCLutilise KCLApplicationName-WorkerMetricStats par défaut le nom de la table des métriques de travail.
Tableau des états des coordinateurs
Une table d'état des coordinateurs est une table Amazon DynamoDB unique pour KCL chaque application. Elle est utilisée pour stocker les informations d'état internes des travailleurs. Par exemple, la table d'état du coordinateur stocke les données concernant l'élection du leader ou les métadonnées associées à la migration sur place de la version KCL 2.x vers KCL la version 3.x. KCLutilise KCLApplicationName-CoordinatorState par défaut le nom de la table d'état du coordinateur.
Mode de capacité DynamoDB pour les tables de métadonnées créées par KCL
Par défaut, la bibliothèque cliente Kinesis (KCL) crée des tables de métadonnées DynamoDB telles que la table des baux, la table des métriques des travailleurs et la table d'état des coordinateurs en utilisant le mode de capacité à la demande. Ce mode adapte automatiquement la capacité de lecture et d'écriture pour s'adapter au trafic sans nécessiter de planification de la capacité. Nous vous recommandons vivement de conserver le mode capacité en mode à la demande pour un fonctionnement plus efficace de ces tables de métadonnées.
Si vous décidez de passer la table des baux en mode capacité provisionnée, suivez les meilleures pratiques suivantes :
-
Analysez les modèles d'utilisation :
-
Surveillez les modèles de lecture et d'écriture et les utilisations de votre application (RCU,WCU) à l'aide CloudWatch des métriques Amazon.
-
Comprenez les exigences de débit de pointe et de débit moyen.
-
-
Calculez la capacité requise :
-
Estimez les unités de capacité de lecture (RCUs) et les unités de capacité d'écriture (WCUs) en fonction de votre analyse.
-
Tenez compte de facteurs tels que le nombre de fragments, la fréquence des points de contrôle et le nombre de travailleurs.
-
-
Implémentez le dimensionnement automatique :
-
Utilisez le dimensionnement automatique DynamoDB pour ajuster automatiquement la capacité allouée et définir les limites de capacité minimale et maximale appropriées.
-
La mise à l'échelle automatique de DynamoDB vous aidera à KCL éviter que votre table de métadonnées n'atteigne la limite de capacité et ne soit limitée.
-
-
Surveillance et optimisation régulières :
-
Surveillez en permanence CloudWatch les métriques pour
ThrottledRequests. -
Ajustez la capacité en fonction de l'évolution de votre charge de travail.
-
Si vous rencontrez des tables DynamoDB intégrées aux métadonnées pour KCL votre application grand public, vous devez augmenter la capacité de débit allouée à la table DynamoDB. ProvisionedThroughputExceededException Si vous définissez un certain niveau d'unités de capacité de lecture (RCU) et d'unités de capacité d'écriture (WCU) lorsque vous créez votre application grand public pour la première fois, il se peut que cela ne soit pas suffisant à mesure que votre utilisation augmente. Par exemple, si votre application KCL grand public effectue des points de contrôle fréquents ou fonctionne sur un flux contenant de nombreux fragments, vous aurez peut-être besoin d'unités de capacité supplémentaires. Pour plus d'informations sur le débit alloué dans DynamoDB, consultez les sections Capacité de débit DynamoDB et mise à jour d'un tableau dans le manuel Amazon DynamoDB Developer Guide.
Comment KCL attribuer les baux aux travailleurs et équilibrer la charge
KCLcollecte et surveille en permanence les indicateurs CPU d'utilisation des hôtes de calcul qui exécutent les travailleurs afin de garantir une répartition uniforme de la charge de travail. Ces mesures CPU d'utilisation sont stockées dans le tableau des métriques de travail de DynamoDB. S'il KCL détecte que certains travailleurs affichent des taux d'CPUutilisation plus élevés que d'autres, il réattribuera les baux aux travailleurs afin de réduire la charge de travail des travailleurs très sollicités. L'objectif est d'équilibrer la charge de travail de manière plus uniforme au sein du parc d'applications grand public, afin d'éviter qu'un seul travailleur ne soit surchargé. Lorsque CPU l'KCLutilisation est répartie sur l'ensemble du parc d'applications grand public, vous pouvez ajuster la capacité de votre parc d'applications grand public en choisissant le bon nombre de travailleurs ou utiliser le dimensionnement automatique pour gérer efficacement la capacité de calcul afin de réduire les coûts.
Important
KCLne peut collecter CPU des indicateurs d'utilisation auprès des travailleurs que si certaines conditions préalables sont remplies. Pour plus de détails, consultez Prérequis. Si vous KCL ne pouvez pas collecter les indicateurs d'CPUutilisation auprès des travailleurs, KCL vous aurez recours au débit par travailleur pour attribuer des baux et équilibrer la charge entre les travailleurs de la flotte. KCLsurveillera le débit reçu par chaque travailleur à un moment donné et réattribuera les baux pour s'assurer que chaque travailleur obtient un niveau de débit total similaire pour les baux qui lui ont été attribués.
