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
KCL verwaltet Metadaten wie Leasingverträge und CPU-Nutzungskennzahlen von Mitarbeitern. KCL verfolgt diese Metadaten mithilfe von DynamoDB-Tabellen. Für jede Amazon Kinesis Data Streams Streams-Anwendung erstellt KCL drei DynamoDB-Tabellen zur Verwaltung der Metadaten: Leasetabelle, Worker-Metriktabelle und Koordinatorstatustabelle.
Anmerkung
Mit KCL 3.x wurden zwei neue Metadatentabellen eingeführt: Worker-Metriken und Tabellen mit Koordinatorstatus.
Wichtig
Sie müssen die richtigen Berechtigungen für KCL-Anwendungen hinzufügen, um Metadatentabellen in DynamoDB zu erstellen und zu verwalten. Details hierzu finden Sie unter Für KCL-Anwendungen für Privatanwender sind IAM-Berechtigungen erforderlich.
Die KCL-Verbraucheranwendung entfernt diese drei DynamoDB-Metadatentabellen nicht automatisch. Stellen Sie sicher, dass Sie diese DynamoDB-Metadatentabellen, die von der KCL-Consumer-Anwendung erstellt wurden, entfernen, wenn Sie Ihre Consumer-Anwendung außer Betrieb nehmen, um unnötige Kosten zu vermeiden.
Tabelle leasen
Eine Leasing-Tabelle ist eine einzigartige Amazon DynamoDB-Tabelle, mit der die Shards nachverfolgt werden, die von den Schedulern der KCL-Consumer-Anwendung geleast und verarbeitet werden. Jede KCL-Consumer-Anwendung erstellt ihre eigene Leasing-Tabelle. KCL verwendet standardmäßig den Namen der Verbraucheranwendung als Namen der Leasetabelle. Sie können mithilfe der Konfiguration einen benutzerdefinierten Tabellennamen festlegen. KCL erstellt außerdem einen globalen sekundären Index für die Leasetabelle mit dem Partitionsschlüssel von LeaseOwner für eine effiziente Leasing-Erkennung. Der globale sekundäre Index spiegelt das LeaseKey-Attribut aus der Basisleasingtabelle wider. Wenn die Leasing-Tabelle für Ihre KCL-Consumer-Anwendung beim Start der Anwendung nicht vorhanden ist, erstellt einer der Worker die Leasing-Tabelle für Ihre Anwendung.
Sie können die Leasetabelle mit der Amazon-DynamoDB-Konsole anzeigen, während die Konsumentenanwendung ausgeführt wird.
Wichtig
-
Der Name jeder KCL-Consumer-Anwendung 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: Für die Single-Stream-Verarbeitung ist dies die Shard-ID. Für die Multistream-Verarbeitung mit KCL ist es wie folgt strukturiert
account-id:StreamName:streamCreationTimestamp:ShardId. leaseKey ist der Partitionsschlüssel der Leasetabelle. Weitere Hinweise zur Multistream-Verarbeitung finden Sie unter. Multistream-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 Mietvertrag gerade aktiv bearbeitet. LeaseCounter erhöht sich, wenn der Leasingbesitz 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 KCL verwenden, werden die folgenden zwei zusätzlichen Felder in der Leasetabelle angezeigt. Weitere Informationen finden Sie unter Multistream-Verarbeitung mit KCL .
-
shardID: Die ID des Shards.
-
StreamName: Der Bezeichner des Datenstroms im folgenden Format:.
account-id:StreamName:streamCreationTimestamp
Tabelle mit den Arbeitsmetriken
Die Tabelle mit den Worker-Metriken ist eine eindeutige Amazon DynamoDB-Tabelle für jede KCL-Anwendung und wird verwendet, um die CPU-Nutzungsmetriken für jeden Worker aufzuzeichnen. Diese Kennzahlen werden von KCL verwendet, um effiziente Leasingaufträge durchzuführen, um eine ausgewogene Ressourcennutzung aller Mitarbeiter zu erreichen. KCL verwendet standardmäßig KCLApplicationName-WorkerMetricStats für den Namen der Tabelle mit den Arbeitsmetriken.
Tabelle mit Status des Koordinators
Eine Koordinatorstatustabelle 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 zu KCL 3.x gespeichert. KCL verwendet standardmäßig KCLApplicationName-CoordinatorState für den Namen der Koordinatorstatustabelle.
DynamoDB-Kapazitätsmodus für von KCL erstellte Metadatentabellen
Standardmäßig erstellt die Kinesis Client Library (KCL) DynamoDB-Metadatentabellen wie Leasetabellen, 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 (RCU, WCU) Ihrer Anwendung mithilfe von Amazon-Metriken. CloudWatch
-
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 ProvisionedThroughputExceededException in Metadaten-DynamoDB-Tabellen für Ihre KCL-Consumer-Anwendung feststellen, müssen Sie die bereitgestellte Durchsatzkapazität der DynamoDB-Tabelle erhöhen. Wenn Sie bei der ersten Erstellung Ihrer Verbraucheranwendung ein bestimmtes Niveau an Lesekapazitätseinheiten (RCU) und Schreibkapazitätseinheiten (WCU) festlegen, ist dies möglicherweise nicht ausreichend, wenn Ihre Nutzung zunimmt. Wenn Ihre KCL-Consumer-Anwendung 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 KCL Mitarbeitern Leasingverträge zuweist und die Arbeitslast verteilt
KCL sammelt und überwacht kontinuierlich Metriken zur CPU-Auslastung 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 feststellt, 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 KCL die CPU-Auslastung auf die gesamte Anwendungsflotte verteilt, können Sie die Kapazität Ihrer Anwendungsflotte für Privatanwender anpassen, indem Sie die richtige Anzahl von Workern wählen oder Auto Scaling verwenden, um die Rechenkapazität effizient zu verwalten und so die Kosten zu senken.
Wichtig
KCL kann nur dann CPU-Nutzungsdaten von Mitarbeitern sammeln, wenn bestimmte Voraussetzungen erfüllt sind. Details hierzu finden Sie unter Voraussetzungen. Wenn KCL keine Kennzahlen zur CPU-Auslastung von Mitarbeitern sammeln kann, verwendet KCL den Durchsatz pro Mitarbeiter, 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 aus seinen zugewiesenen Leasingverträgen einen ähnlichen Gesamtdurchsatz erhält.
