Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
DynamoDB-Metadatentabellen und Lastenausgleich in KCL
KCLverwaltet Metadaten wie Leasingverträge und CPU Nutzungskennzahlen von Mitarbeitern. KCLverfolgt diese Metadaten mithilfe von DynamoDB-Tabellen. KCLErstellt für jede Amazon Kinesis Data Streams Streams-Anwendung drei DynamoDB-Tabellen zur Verwaltung der Metadaten: Leasetabelle, Worker-Metriktabelle und Koordinatorstatustabelle.
Anmerkung
KCL3.x führte zwei neue Metadatentabellen ein: Worker-Metriken und Koordinatorstatustabellen.
Wichtig
Sie müssen die entsprechenden Berechtigungen für KCL Anwendungen hinzufügen, um Metadatentabellen in DynamoDB zu erstellen und zu verwalten. Details hierzu finden Sie unter IAMBerechtigungen, die für Verbraucheranwendungen erforderlich sind KCL.
KCLDie Verbraucheranwendung entfernt diese drei DynamoDB-Metadatentabellen nicht automatisch. Stellen Sie sicher, dass Sie diese von der Verbraucheranwendung erstellten DynamoDB-Metadatentabellen entfernen, wenn Sie Ihre KCL Verbraucheranwendung außer Betrieb nehmen, um unnötige Kosten zu vermeiden.
Tabelle leasen
Die Leasing-Tabelle ist eine einzigartige Amazon DynamoDB-Tabelle, mit der die Shards nachverfolgt werden, die von den Schedulern der Verbraucheranwendung geleast und verarbeitet werden. KCL Jede KCL Verbraucheranwendung erstellt ihre eigene Leasing-Tabelle. KCLverwendet standardmäßig den Namen der Verbraucheranwendung als Namen der Leasetabelle. Sie können mithilfe der Konfiguration einen benutzerdefinierten Tabellennamen festlegen. KCLerstellt außerdem einen globalen sekundären Index für die Leasetabelle mit dem Partitionsschlüssel von, leaseOwner um eine effiziente Leasing-Erkennung zu ermöglichen. Der globale sekundäre Index spiegelt das leaseKey Attribut aus der Basis-Leasing-Tabelle wider. Wenn die Leasingtabelle für Ihre KCL Consumer-Anwendung beim Start der Anwendung nicht vorhanden ist, erstellt einer der Mitarbeiter die Leasingtabelle für Ihre Anwendung.
Sie können die Leasetabelle mit der Amazon-DynamoDB-Konsole anzeigen, während die Konsumentenanwendung ausgeführt wird.
Wichtig
-
Jeder Name der KCL Verbraucheranwendung muss eindeutig sein, um zu verhindern, dass der Name der Leasetabelle doppelt vorkommt.
-
Ihr Konto wird neben den Kosten für Kinesis Data Streams mit den Kosten belastet, die für die DynamoDB-Tabelle anfallen.
Jede Zeile in der Leasetabelle steht für einen Shard, der von den Schedulern Ihrer Verbraucheranwendung verarbeitet wird. Zu den wichtigsten Feldern gehören die folgenden:
-
leaseKey: Bei der Single-Stream-Verarbeitung ist dies die Shard-ID. Für die Multistream-Verarbeitung mit KCL ist sie strukturiert als.
account-id:StreamName:streamCreationTimestamp:ShardIdleaseKey ist der Partitionsschlüssel der Leasetabelle. Weitere Hinweise zur Multistream-Verarbeitung finden Sie unterMultistream-Verarbeitung mit KCL . -
checkpoint: Die letzte Prüfpunkt-Sequenznummer des Shards.
-
checkpointSubSequenceNummer: Wenn Sie die Aggregationsfunktion der Kinesis Producer Library verwenden, ist dies eine Erweiterung des Checkpoints, mit der einzelne Benutzerdatensätze innerhalb des Kinesis-Datensatzes verfolgt werden.
-
leaseCounter: Wird verwendet, um zu überprüfen, ob ein Mitarbeiter den Leasingvertrag derzeit aktiv bearbeitet. leaseCounter steigt, wenn das Leasingverhältnis auf einen anderen Mitarbeiter übertragen wird.
-
leaseOwner: Der aktuelle Arbeitnehmer, der diesen Mietvertrag innehat.
-
ownerSwitchesSinceCheckpoint: Wie oft hat dieser Mietvertrag seit dem letzten Checkpoint die Mitarbeiter gewechselt?
-
parentShardId: ID des übergeordneten Elements dieses Shards. Stellt sicher, dass der übergeordnete Shard vollständig verarbeitet ist, bevor die Verarbeitung der untergeordneten Shards beginnt. Dabei wird die korrekte Reihenfolge der Datensatzverarbeitung beibehalten.
-
childShardId: Liste der untergeordneten Shards, die beim IDs Teilen oder Zusammenführen dieses Shards entstanden sind. Wird verwendet, um die Herkunft des Shards nachzuverfolgen und die Verarbeitungsreihenfolge bei Resharding-Vorgängen zu verwalten.
-
startingHashKey: Die Untergrenze des Hash-Schlüsselbereichs für diesen Shard.
-
endingHashKey: Die Obergrenze des Hash-Schlüsselbereichs für diesen Shard.
Wenn Sie die Multistream-Verarbeitung mit verwendenKCL, werden die folgenden zwei zusätzlichen Felder in der Leasing-Tabelle angezeigt. Weitere Informationen finden Sie unter Multistream-Verarbeitung mit KCL .
-
shardID: Die ID des Shards.
-
streamName: Die Kennung des Datenstroms im folgenden Format:
account-id:StreamName:streamCreationTimestamp.
Tabelle mit Arbeitsmetriken
Die Tabelle mit den Worker-Metriken ist eine eindeutige Amazon DynamoDB-Tabelle für jede KCL Anwendung und wird verwendet, um CPU Nutzungsmetriken für jeden Worker aufzuzeichnen. Diese Kennzahlen werden verwendet, KCL um effiziente Leasingaufträge durchzuführen, um eine ausgewogene Ressourcennutzung durch alle Mitarbeiter zu erreichen. KCLverwendet standardmäßig KCLApplicationName-WorkerMetricStats für den Namen der Tabelle mit den Arbeitskräftekennzahlen.
Tabelle mit Status des Koordinators
Die Coordinator-Statustabelle ist eine eindeutige Amazon DynamoDB-Tabelle für jede KCL Anwendung und wird verwendet, um interne Statusinformationen für Mitarbeiter zu speichern. In der Tabelle mit dem Status des Koordinators werden beispielsweise Daten zur Wahl des Vorsitzenden oder Metadaten im Zusammenhang mit der direkten Migration von KCL 2.x auf 3.x gespeichert. KCL KCLwird standardmäßig KCLApplicationName-CoordinatorState für den Namen der Tabelle mit dem Status des Koordinators verwendet.
DynamoDB-Kapazitätsmodus für Metadatentabellen, erstellt von KCL
Standardmäßig erstellt die Kinesis Client Library (KCL) DynamoDB-Metadatentabellen wie Leasing-Tabellen, Worker-Metrik-Tabellen und Koordinatorstatustabellen im On-Demand-Kapazitätsmodus. In diesem Modus wird die Lese- und Schreibkapazität automatisch an den Datenverkehr angepasst, ohne dass eine Kapazitätsplanung erforderlich ist. Es wird dringend empfohlen, den Kapazitätsmodus als On-Demand-Modus beizubehalten, um einen effizienteren Betrieb dieser Metadatentabellen zu gewährleisten.
Wenn Sie sich dafür entscheiden, die Leasetabelle in den Modus „Bereitgestellte Kapazität“ umzuschalten, befolgen Sie diese bewährten Methoden:
-
Analysieren Sie Nutzungsmuster:
-
Überwachen Sie die Lese- und Schreibmuster und Nutzungen Ihrer Anwendung (RCU,WCU) mithilfe von CloudWatch Amazon-Metriken.
-
Machen Sie sich mit den Spitzen- und Durchschnittsdurchsatzanforderungen vertraut.
-
-
Berechnen Sie die erforderliche Kapazität:
-
Schätzen Sie die Lesekapazitätseinheiten (RCUs) und die Schreibkapazitätseinheiten (WCUs) auf der Grundlage Ihrer Analyse.
-
Berücksichtigen Sie Faktoren wie die Anzahl der Shards, die Häufigkeit der Checkpoints und die Anzahl der Mitarbeiter.
-
-
Implementieren Sie Auto Scaling:
-
Verwenden Sie DynamoDB Auto Scaling, um die bereitgestellte Kapazität automatisch anzupassen und angemessene Mindest- und Höchstkapazitätsgrenzen festzulegen.
-
DynamoDB Auto Scaling hilft zu verhindern, dass Ihre KCL Metadatentabelle die Kapazitätsgrenze erreicht und gedrosselt wird.
-
-
Regelmäßige Überwachung und Optimierung:
-
Überwachen Sie kontinuierlich die CloudWatch Metriken für
ThrottledRequests. -
Passen Sie die Kapazität an, wenn sich Ihre Arbeitslast im Laufe der Zeit ändert.
-
Wenn Sie Erfahrung ProvisionedThroughputExceededException mit DynamoDB-Metadatentabellen für Ihre KCL Verbraucheranwendung haben, müssen Sie die bereitgestellte Durchsatzkapazität der DynamoDB-Tabelle erhöhen. Wenn Sie bei der ersten Erstellung Ihrer Anwendung für Privatanwender ein bestimmtes Maß an Lesekapazitätseinheiten (RCUWCU) und Schreibkapazitätseinheiten () festlegen, ist dies möglicherweise nicht ausreichend, wenn Ihre Nutzung zunimmt. Wenn Ihre KCL Privatanwenderanwendung beispielsweise häufig Checkpoints durchführt oder auf einem Stream mit vielen Shards arbeitet, benötigen Sie möglicherweise mehr Kapazitätseinheiten. Informationen zum bereitgestellten Durchsatz in DynamoDB finden Sie unter DynamoDB-Durchsatzkapazität und Aktualisierung einer Tabelle im Amazon DynamoDB Developer Guide.
Wie werden den Mitarbeitern Leasingverträge KCL zugewiesen und die Auslastung verteilt
KCLsammelt und überwacht kontinuierlich CPU Nutzungskennzahlen von Rechenhosts, auf denen die Worker laufen, um eine gleichmäßige Verteilung der Arbeitslast sicherzustellen. Diese CPU Nutzungsmetriken werden in der Tabelle mit den Worker-Metriken in DynamoDB gespeichert. Wenn KCL festgestellt wird, dass einige Mitarbeiter im Vergleich zu anderen eine höhere CPU Auslastung aufweisen, werden die Leasingverträge zwischen den Mitarbeitern neu vergeben, um die Belastung stark ausgelasteter Mitarbeiter zu verringern. Ziel ist es, die Arbeitslast gleichmäßiger auf die gesamte Anwendungsflotte für Privatanwender zu verteilen und so zu verhindern, dass einzelne Mitarbeiter überlastet werden. Da die CPU Nutzung auf die gesamte Anwendungsflotte KCL verteilt wird, können Sie die Kapazität Ihrer Anwendungsflotte für Privatanwender anpassen, indem Sie die richtige Anzahl von Mitarbeitern wählen oder Auto Scaling verwenden, um die Rechenkapazität effizient zu verwalten und so die Kosten zu senken.
Wichtig
KCLkann nur dann CPU Nutzungskennzahlen von Mitarbeitern erheben, wenn bestimmte Voraussetzungen erfüllt sind. Details hierzu finden Sie unter Voraussetzungen. Wenn es KCL nicht möglich ist, CPU Nutzungskennzahlen von Mitarbeitern zu sammeln, KCL wird auf den Durchsatz pro Mitarbeiter zurückgegriffen, um Leasingverträge zuzuweisen und die Auslastung auf die Mitarbeiter in der Flotte zu verteilen. KCLüberwacht den Durchsatz, den jeder Mitarbeiter zu einem bestimmten Zeitpunkt erhält, und weist Leasingverträge neu zu, um sicherzustellen, dass jeder Mitarbeiter einen ähnlichen Gesamtdurchsatz aus seinen zugewiesenen Mietverträgen erhält.
