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 Kennzahlen zur CPU-Auslastung von Mitarbeitern. KCL verfolgt diese Metadaten mithilfe von DynamoDB-Tabellen. Für jede Amazon Kinesis Data Streams-Anwendung erstellt KCL 3.x standardmäßig drei DynamoDB-Tabellen zur Verwaltung der Metadaten: Leasing-Tabelle, Worker-Metriktabelle und Koordinator-Statustabelle. Ab KCL 3.5 können Sie das Einzeltabellenformat verwenden, um alle Metadaten in der Leasing-Tabelle zu konsolidieren. Weitere Informationen finden Sie unter Einzeltabellenformat für KCL.
Anmerkung
KCL 3.x führte zwei neue Metadatentabellen ein: Worker-Metriken und Koordinator-Statustabellen. Ab KCL 3.5 können Sie diese Tabellen in der Leasing-Tabelle konsolidieren, indem Sie das Einzeltabellenformat verwenden.
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 Für KCL-Verbraucheranwendungen 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-Verbraucheranwendung 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 eindeutige Amazon DynamoDB-Tabelle, mit der die Shards nachverfolgt werden, die von den Schedulern der KCL-Verbraucheranwendung geleast und verarbeitet werden. Jede KCL-Verbraucheranwendung erstellt ihre eigene Leasetabelle. KCL verwendet standardmäßig den Namen der Verbraucheranwendung für den 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 Leasing-Tabelle 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-Leasingtabelle 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
-
Jeder Name der KCL-Consumer-Anwendung muss eindeutig sein, um zu verhindern, dass der Name der Leasing-Tabelle dupliziert wird.
-
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 Leasing-Tabelle steht für einen Shard, der von den Schedulern Ihrer Consumer-Anwendung 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 sie wie folgt strukturiert
account-id:StreamName:streamCreationTimestamp:ShardId. LeaseKey ist der Partitionsschlüssel der Leasetabelle. Weitere Hinweise zur Multistream-Verarbeitung finden Sie unter. Multi-stream Verarbeitung mit KCL -
checkpoint: Die letzte Prüfpunkt-Sequenznummer des Shards.
-
CheckpointSubSequenceNumber: Wenn Sie die Aggregationsfunktion der Kinesis Producer Library verwenden, handelt es sich um eine Erweiterung von Checkpoint, die einzelne Benutzerdatensätze innerhalb des Kinesis-Datensatzes verfolgt.
-
LeaseCounter: Wird verwendet, um zu überprüfen, ob ein Mitarbeiter den Mietvertrag gerade aktiv bearbeitet. LeaseCounter erhöht sich, wenn das Leasingverhältnis auf einen anderen Arbeiter übertragen wird.
-
LeaseOwner: Der aktuelle Mitarbeiter, der diesen Mietvertrag innehat.
-
EigentümerSwitchesSinceCheckpoint: Wie oft hat dieser Leasingvertrag seit dem letzten Checkpoint den Arbeitnehmer gewechselt?
-
ElternteilShardId: ID des übergeordneten Elements dieses Shards. Stellt sicher, dass der übergeordnete Shard vollständig verarbeitet ist, bevor die Verarbeitung der untergeordneten Shards beginnt, wobei die korrekte Reihenfolge der Datensatzverarbeitung beibehalten wird.
-
childShardId: Liste der untergeordneten Shard-IDs, die sich aus dem Teilen oder Zusammenführen dieses Shards ergeben. Wird verwendet, um die Herkunft der Shards zu verfolgen und die Verarbeitungsreihenfolge bei Resharding-Vorgängen zu verwalten.
-
StartHashKey: Die Untergrenze des Hash-Schlüsselbereichs für diesen Shard.
-
EndeHashKey: Die obere Grenze des Hash-Schlüsselbereichs für diesen Shard.
Wenn Sie die Multistream-Verarbeitung mit KCL verwenden, werden in der Leasetabelle die folgenden zwei zusätzlichen Felder angezeigt. Weitere Informationen finden Sie unter Multi-stream Verarbeitung mit KCL.
-
shardID: Die ID des Shards.
-
streamName: Der Bezeichner des Datenstroms im folgenden Format:.
account-id:StreamName:streamCreationTimestamp
Tabelle mit Worker-Metriken
Die Worker-Metriktabelle ist eine eindeutige Amazon DynamoDB-Tabelle für jede KCL-Anwendung und wird verwendet, um CPU-Auslastungsmetriken für jeden Worker aufzuzeichnen. Diese Kennzahlen werden von KCL zur effizienten Durchführung von Leasingaufträgen verwendet, um eine ausgewogene Ressourcenauslastung aller Mitarbeiter zu erreichen. KCL verwendet standardmäßig KCLApplicationName-WorkerMetricStats für den Namen der Worker-Metriken eine Tabelle.
Statustabelle des Koordinators
Eine Koordinator-Statustabelle ist eine eindeutige Amazon DynamoDB-Tabelle für jede KCL-Anwendung und wird zum Speichern interner Statusinformationen für Mitarbeiter verwendet. In der Koordinatoren-Statustabelle werden beispielsweise Daten zur Wahl des Leiters oder Metadaten im Zusammenhang mit der direkten Migration von KCL 2.x zu KCL 3.x gespeichert. KCL verwendet standardmäßig die KCLApplicationName-CoordinatorState Statustabelle für den Namen des Koordinators.
DynamoDB-Kapazitätsmodus für von KCL erstellte Metadatentabellen
Standardmäßig erstellt die Kinesis Client Library (KCL) DynamoDB-Metadatentabellen wie Leasing-Tabellen, Worker-Metriktabellen und Koordinator-Statustabellen im On-Demand-Kapazitätsmodus. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode.html In diesem Modus wird die Lese- und Schreibkapazität automatisch an den Datenverkehr angepasst, ohne dass eine Kapazitätsplanung erforderlich ist. Wir empfehlen Ihnen dringend, den Kapazitätsmodus im On-Demand-Modus beizubehalten, um diese Metadatentabellen effizienter nutzen zu können.
Wenn Sie sich dafür entscheiden, die Leasetabelle in den Modus für bereitgestellte Kapazität umzuschalten, folgen Sie diesen bewährten Methoden:
-
Analysieren Sie die Nutzungsmuster:
-
Überwachen Sie die Lese- und Schreibmuster und Nutzungen Ihrer Anwendung (RCU, WCU) mithilfe von Amazon-Metriken. CloudWatch
-
Machen Sie sich mit den Anforderungen für den Spitzendurchsatz und den durchschnittlichen Durch
-
-
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 die automatische Skalierung von DynamoDB, 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 das Kapazitätslimit erreicht und gedrosselt wird.
-
-
Regelmäßige Überwachung und Optimierung:
-
Überwachen Sie kontinuierlich die CloudWatch Kennzahlen für
ThrottledRequests. -
Passen Sie die Kapazität an, wenn sich Ihre Arbeitslast im Laufe der Zeit ändert.
-
Wenn Sie feststellen, dass die Metadaten ProvisionedThroughputExceededException der DynamoDB-Tabellen für Ihre KCL-Consumer-Anwendung nicht ausreichen, müssen Sie die bereitgestellte Durchsatzkapazität der DynamoDB-Tabelle erhöhen. Wenn Sie bei der ersten Erstellung Ihrer Consumer-Anwendung ein bestimmtes Maß an Lesekapazitätseinheiten (RCU) und Schreibkapazitätseinheiten (WCU) festlegen, reicht dies möglicherweise nicht aus, wenn Ihre Nutzung zunimmt. Wenn Ihre KCL-Verbraucheranwendung beispielsweise häufig Checkpoints durchführt oder mit 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 den Arbeitern Leasingverträge zuweist und die Last ausgleicht
KCL erfasst und überwacht kontinuierlich Kennzahlen zur CPU-Auslastung der Rechenhosts, auf denen die Worker ausgeführt werden, um eine gleichmäßige Verteilung der Arbeitslast sicherzustellen. Diese CPU-Auslastungsmetriken werden in der Worker-Metriktabelle in DynamoDB gespeichert. Wenn KCL feststellt, dass einige Mitarbeiter eine höhere CPU-Auslastung aufweisen als andere, werden die Leasingverträge den Mitarbeitern neu zugewiesen, um die Belastung stark ausgelasteter Mitarbeiter zu verringern. Das Ziel besteht darin, die Arbeitslast auf die gesamte Palette der Verbraucheranwendungen gleichmäßiger zu verteilen und so zu verhindern, dass einzelne Mitarbeiter überlastet werden. Da KCL die CPU-Auslastung auf den gesamten Bestand an Verbraucheranwendungen verteilt, können Sie die Kapazität Ihrer Consumer-Anwendungen richtig dimensionieren, indem Sie die richtige Anzahl von Mitarbeitern auswählen oder Auto Scaling verwenden, um die Rechenkapazität effizient zu verwalten und so die Kosten zu senken.
Wichtig
KCL kann Kennzahlen zur CPU-Auslastung von Mitarbeitern nur dann erheben, wenn bestimmte Voraussetzungen erfüllt sind. Details hierzu finden Sie unter Voraussetzungen. Wenn KCL die CPU-Auslastungsmetriken von Mitarbeitern nicht erfassen kann, verwendet KCL wieder den Durchsatz pro Mitarbeiter, um Leasingverträge zuzuweisen und die Auslastung der Mitarbeiter in der Flotte auszugleichen. KCL überwacht den Durchsatz, den jeder Mitarbeiter zu einem bestimmten Zeitpunkt erhält, und weist die Leasingverträge neu zu, um sicherzustellen, dass jeder Mitarbeiter aus den ihm zugewiesenen Leasingverträgen einen ähnlichen Gesamtdurchsatz erzielt.
