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.
# Daten aus Amazon Kinesis Data Streams lesen
Ein *Konsument* ist eine Anwendung, die alle Daten aus einem Kinesis-Datenstrom verarbeitet. Wenn ein Verbraucher *Enhanced Fan-Out* verwendet, erhält er seinen eigenen Lesedurchsatz MB/sec von 2 zugeteilt, sodass mehrere Verbraucher Daten aus demselben Stream parallel lesen können, ohne mit anderen Verbrauchern um den Lesedurchsatz zu kämpfen. Informationen zum Verwenden der Shard-Funktionen für erweiterte Rundsendungen erhalten Sie unter [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md).
Sie können Consumer für Kinesis Data Streams mithilfe der Kinesis Client Library (KCL) oder erstellen. AWS SDK für Java Sie können Kunden auch mithilfe anderer AWS Dienste wie AWS Lambda Amazon Managed Service für Apache Flink und Amazon Data Firehose gewinnen. Kinesis Data Streams unterstützt Integrationen mit anderen AWS Diensten wie Amazon EMR, Amazon und Amazon Redshift. Es unterstützt auch Integrationen von Drittanbietern wie Apache Flink AWS Glue, Adobe Experience Platform, Apache Druid, Apache Spark, Databricks, Confluent Platform, Kinesumer und Talend. EventBridge
**Topics**
+ [
# Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz
](enhanced-consumers.md)
+ [
# Verwenden Sie den Data Viewer in der Kinesis-Konsole
](data-viewer.md)
+ [
# Fragen Sie Ihre Datenströme in der Kinesis-Konsole ab
](querying-data.md)
+ [
# Verwenden Sie die Kinesis-Clientbibliothek
](kcl.md)
+ [
# Entwickeln Sie Verbraucher mit dem AWS SDK für Java
](develop-consumers-sdk.md)
+ [
# Entwickeln Sie Verbraucher mit AWS Lambda
](lambda-consumer.md)
+ [
# Entwickeln Sie Kunden mithilfe von Amazon Managed Service für Apache Flink
](kda-consumer.md)
+ [
# Entwickeln Sie Verbraucher mithilfe von Amazon Data Firehose
](kdf-consumer.md)
+ [
# Daten aus Kinesis Data Streams mithilfe anderer AWS Dienste lesen
](using-other-services-read.md)
+ [
# Lesen Sie mithilfe von Integrationen von Drittanbietern aus Kinesis Data Streams
](using-services-third-party-read.md)
+ [
# Problembehandlung bei Kinesis Data Streams Streams-Verbrauchern
](troubleshooting-consumers.md)
+ [
# Optimieren Sie die Verbraucher von Amazon Kinesis Data Streams
](advanced-consumers.md)
# Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz
In Amazon Kinesis Data Streams können Sie Verbraucher erstellen, die ein Feature namens *erweiterte Rundsendungen* verwenden. Mit dieser Funktion können Verbraucher Datensätze aus einem Stream mit einem Datendurchsatz von bis zu 2 MB pro Sekunde und Shard empfangen. Dieser Durchsatz ist dediziert, d. h. dass Verbraucher, die ein erweitertes Rundsenden verwenden, nicht mit anderen Verbrauchern konkurrieren müssen, die Daten aus dem Stream empfangen. Kinesis Data Streams überträgt Datensätze aus dem Stream zu den Verbrauchern die ein erweitertes Rundsenden verwenden. Aus diesem Grund müssen diese Verbraucher keine Daten abfragen.
**Wichtig**
Im On-Demand-Advantage-Modus können Sie bis zu 50 Verbraucher pro Stream registrieren, um den erweiterten Fan-Out zu nutzen. Bei den On-Demand-Streams Standard und Provisioned können Sie bis zu 20 Verbraucher pro Stream registrieren, um den erweiterten Fan-Out zu nutzen.
Das folgende Diagramm zeigt die Architektur für das erweiterte Rundsenden. Wenn Sie die Version 2.0 oder höher der Amazon Kinesis Client Library (KCL) verwenden, um einen Verbraucher zu erstellen, richtet die KCL den Verbraucher so ein, dass er erweitertes Rundsenden verwendet, um Daten von allen Shards des Streams zu empfangen. Wenn Sie die API verwenden, um einen Verbraucher zu erstellen, der ein erweitertes Rundsenden verwendet, können Sie einzelne Shards abonnieren.
![\[Workflow-Diagramm der Architektur für erweitertes Rundsenden mit zwei Shards und zwei Verbrauchern. Jeder der beiden Verbraucher verwendet erweitertes Rundsenden, um Daten von beiden Shards des Streams zu empfangen.\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/images/enhanced_fan-out.png)
Das Diagramm zeigt Folgendes:
+ Einen Stream mit zwei Shards.
+ Zwei Verbraucher, die erweitertes Rundsenden verwenden, um Daten vom Stream zu empfangen: Consumer X und Consumer Y. Beide Verbraucher haben alle Shards und alle Datensätze im Stream abonniert. Wenn Sie die Version 2.0 oder höher der KCL verwenden, um einen Verbraucher zu erstellen, abonniert die KCL automatisch alle Shards des Streams. Wenn Sie dagegen die API verwenden, um einen Verbraucher zu erstellen, können Sie einzelne Shards abonnieren.
+ Pfeile stellen die Pipes für das erweiterte Rundsenden dar, die die Verbraucher verwenden, um Daten aus dem Stream zu erhalten. Eine erweiterte Fanout-Pipe stellt bis zu 2 MB/sec Daten pro Shard bereit, unabhängig von anderen Pipes oder der Gesamtzahl der Verbraucher.
**Topics**
+ [
## Unterschiede zwischen einem Verbraucher mit gemeinsamem Durchsatz und einem Verbraucher mit erweitertem Fan-Out-Anschluss
](#enhanced-consumers-differences)
+ [
## Unterstützte Regionen für bis zu 50 erweiterte Fan-Out-Nutzer (nur On-Demand-Vorteil)
](#supported-regions)
+ [
# Verwalten Sie Nutzer mit erweitertem Fan-Out-Status mit der Option oder AWS CLI APIs
](building-enhanced-consumers-console.md)
## Unterschiede zwischen einem Verbraucher mit gemeinsamem Durchsatz und einem Verbraucher mit erweitertem Fan-Out-Anschluss
In der folgenden Tabelle werden Standardverbraucher mit gemeinsamem Durchsatz und Verbrauchern mit erweitertem Fan-Out-Wert verglichen. Die Verzögerung der Nachrichtenweiterleitung ist definiert als die Zeit in Millisekunden, die eine Nutzlast, die mithilfe des Payload-Dispatchings APIs (like `PutRecord` und`PutRecords`) gesendet wurde, bis sie die Verbraucheranwendung über die nutzlastverbrauchende Anwendung (like und) erreicht. APIs `GetRecords` `SubscribeToShard`
**In dieser Tabelle werden Verbraucher mit gemeinsamem Durchsatz und Verbrauchern mit erweitertem Fan-Out-Wert verglichen**
| Merkmale | Verbraucher mit gemeinsamem Durchsatz ohne erweiterten Fan-Out-Wert | Verbraucher mit verbesserter Fan-Out-Funktionalität |
| --- | --- | --- |
| Lesedurchsatz | Der Wert wurde auf insgesamt 2 MB/sec pro Shard festgelegt. Wenn mehrere Konsumenten aus demselben Shard lesen, teilen sie sich diesen Durchsatz. Die Summe des Lesedurchsatzes der einzelnen Konsumenten eines Shards beträgt maximal 2 MB/s. | Der Wert erhöht sich nur, wenn Konsumenten für erweiterte Rundsendungen registriert werden. Jeder für erweiterte Rundsendungen registrierte Konsument erhält einen eigenen Lesedurchsatz von bis zu 2 MB/s pro Shard, den er nicht mit anderen Konsumenten teilen muss. |
| Verzögerung der Nachrichtenverbreitung | Ein Durchschnitt von etwa 200 ms, wenn Sie einen Verbraucher haben, der aus dem Stream liest. Dieser Durchschnitt steigt bis zu 1000 ms an, wenn Sie fünf Verbraucher haben. | In der Regel durchschnittlich 70 ms, unabhängig davon, ob Sie einen oder fünf Verbraucher haben. |
| Cost (Kosten) | Nicht zutreffend | Es gibt Datenabrufkosten und Konsumenten-Shard-Stundensätze. Weitere Informationen finden Sie unter [Preise für Amazon Kinesis Daten-Streams](https://aws.amazon.com/kinesis/data-streams/pricing/?nc=sn&loc=3). |
| Datensatzbereitstellungsmodell | Modell über HTTP abrufen mit GetRecords. | Kinesis Data Streams überträgt die Datensätze über HTTP/2 an Sie. SubscribeToShard |
## Unterstützte Regionen für bis zu 50 erweiterte Fan-Out-Nutzer (nur On-Demand-Vorteil)
Support für bis zu 50 erweiterte Fanout-Kunden im On-Demand-Advantage-Modus ist nur in den folgenden AWS Regionen verfügbar:
| AWS Region | Name der Region |
| --- | --- |
| eu-north-1 | Europa (Stockholm) |
| me-south-1 | Middle East (Bahrain) |
| ap-south-1 | Asien-Pazifik (Mumbai) |
| eu-west-3 | Europa (Paris) |
| ap-southeast-3 | Asien-Pazifik (Jakarta) |
| us-east-2 | USA Ost (Ohio) |
| af-south-1 | Afrika (Kapstadt) |
| eu-west-1 | Europa (Irland) |
| me-central-1 | Naher Osten (VAE) |
| eu-central-1 | Europa (Frankfurt) |
| sa-east-1 | Südamerika (São Paulo) |
| ap-east-1 | Asien-Pazifik (Hongkong) |
| ap-south-2 | Asien-Pazifik (Hyderabad) |
| us-east-1 | USA Ost (Nord-Virginia) |
| ap-northeast-2 | Asien-Pazifik (Seoul) |
| ap-northeast-3 | Asien-Pazifik (Osaka) |
| eu-west-2 | Europa (London) |
| ap-southeast-4 | Asien-Pazifik (Melbourne) |
| ap-northeast-1 | Asien-Pazifik (Tokio) |
| us-west-2 | USA West (Oregon) |
| us-west-1 | USA West (Nordkalifornien) |
| ap-southeast-1 | Asien-Pazifik (Singapur) |
| ap-southeast-2 | Asien-Pazifik (Sydney) |
| il-central-1 | Israel (Tel Aviv) |
| ca-central-1 | Kanada (Zentral) |
| ca-west-1 | Kanada West (Calgary) |
| eu-south-2 | Europa (Spain) |
| cn-northwest-1 | China (Ningxia) |
| eu-central-2 | Europa (Zürich) |
| us-gov-east-1 | AWS GovCloud (US-Ost) |
| us-gov-west-1 | AWS GovCloud (US-West) |
# Verwalten Sie Nutzer mit erweitertem Fan-Out-Status mit der Option oder AWS CLI APIs
Verbraucher, die ein *erweitertes Rundsenden* in Amazon Kinesis Data Streams verwenden, können Datensätze aus einem Datenstrom mit einem dedizierten Durchsatz von bis zu 2 MB Daten pro Sekunde pro Shard empfangen. Weitere Informationen finden Sie unter [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md).
Sie können AWS CLI oder Kinesis Data Streams verwenden, um einen Verbraucher APIs zu registrieren, zu beschreiben, aufzulisten und die Registrierung aufzuheben, der das erweiterte Fan-Out in Kinesis Data Streams verwendet.
## Verwalten Sie Verbraucher mit dem AWS CLI
Mit dem können Sie erweiterte Fan-Out-Nutzer registrieren, beschreiben, auflisten und deren Registrierung aufheben. AWS CLI Beispiele finden Sie in der folgenden Dokumentation.
[register-stream-consumer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kinesis/register-stream-consumer.html)
Registriert einen Verbraucher für einen Kinesis-Datenstream. Sie können bei der Registrierung des Verbrauchers Tags anwenden.
[describe-stream-consumer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kinesis/describe-stream-consumer.html)
Ruft die Beschreibung eines registrierten Verbrauchers mit einer Kombination aus Verbraucher-ARN oder einer Kombination aus Verbrauchername und Stream-ARN ab.
[list-stream-consumers](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kinesis/list-stream-consumers.html)
Führt die Verbraucher auf, die registriert sind, um Daten aus einem Stream mithilfe eines erweiterten Fan-Outs zu empfangen.
[deregister-stream-consumer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kinesis/deregister-stream-consumer.html)
Melden Sie einen Verbraucher entweder mit einem Verbraucher-ARN oder einer Kombination aus Verbrauchername und Stream-ARN ab.
## Verbraucher mithilfe der Kinesis Data Streams verwalten APIs
Mithilfe der Kinesis Data Streams können Sie erweiterte Fan-Out-Verbraucher registrieren, beschreiben, auflisten und deren Registrierung aufheben. APIs Beispiele finden Sie in der folgenden Dokumentation.
[RegisterStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_RegisterStreamConsumer.html)
Registriert einen Verbraucher für einen Kinesis-Datenstrom mit Tags. Sie können Tags bei der Registrierung des Verbrauchers anwenden.
[DescribeStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_DescribeStreamConsumer.html)
Ruft die Beschreibung eines registrierten Verbrauchers mit einer Kombination aus Verbraucher-ARN oder einer Kombination aus Verbrauchername und Stream-ARN ab.
[ListStreamConsumers](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ListStreamConsumers.html)
Führt die Verbraucher auf, die registriert sind, um Daten aus einem Stream mithilfe eines erweiterten Fan-Outs zu empfangen.
[DeregisterStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_DeregisterStreamConsumer.html)
Melden Sie einen Verbraucher entweder mit einem Verbraucher-ARN oder einer Kombination aus Verbrauchername und Stream-ARN ab.
## Verbraucher kennzeichnen
Sie können Streams und erweiterten Fan-Out-Consumern, die Sie in Kinesis Data Streams erstellen, Ihre eigenen Metadaten in Form von Tags zuweisen. Sie können Tags verwenden, um die Kosten Ihrer Kunden zu kategorisieren und nachzuverfolgen. Sie können den Zugriff auf Verbraucher auch mithilfe von Tags mit [attributebasierter Zugriffskontrolle (ABAC) steuern](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html). Weitere Informationen finden Sie unter [Kennzeichnen Sie Ihre Amazon Kinesis Data Streams Streams-Ressourcen](tagging.md).
# Verwenden Sie den Data Viewer in der Kinesis-Konsole
Mit dem Data Viewer in der Kinesis Management Console können Sie Datensätze innerhalb des angegebenen Shards Ihres Datenstroms anzeigen, ohne eine Verbraucheranwendung entwickeln zu müssen. Gehen Sie folgendermaßen vor, um den Data Viewer zu verwenden:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Kinesis-Konsole unter [https://console.aws.amazon.com/kinesis](https://console.aws.amazon.com/kinesis).
1. Wählen Sie den aktiven Datenstrom aus, dessen Datensätze Sie mit dem Data Viewer anzeigen möchten, und wählen Sie dann die Registerkarte **Data Viewer**.
1. Wählen Sie auf der Registerkarte **Data Viewer** für den ausgewählten aktiven Datenstrom den Shard aus, dessen Datensätze Sie anzeigen möchten, wählen Sie die **Startposition** aus und klicken Sie dann auf **Datensätze abrufen**. Sie können die Startposition auf einen der folgenden Werte stellen:
+ **Bei Sequenznummer**: Zeigt Datensätze von der Position an, die durch die im Feld Sequenznummer angegebene Sequenznummer gekennzeichnet ist.
+ **Nach Sequenznummer**: Zeigt Datensätze direkt nach der Position an, die durch die im Feld Sequenznummer angegebene Sequenznummer gekennzeichnet ist.
+ **Bei Zeitstempel**: Zeigt Datensätze von der Position an, die durch den im Zeitstempelfeld angegebenen Zeitstempel gekennzeichnet ist.
+ **Horizont kürzen**: Zeigt Datensätze am letzten nicht getrimmten Datensatz im Shard an, der der älteste Datensatz im Shard ist.
+ **Aktuell**: Zeigt Datensätze direkt nach dem neuesten Datensatz im Shard an, sodass Sie immer die neuesten Daten im Shard lesen.
Die generierten Datensätze, die mit der angegebenen Shard-ID und Startposition übereinstimmen, werden dann in einer Datensatztabelle in der Konsole angezeigt. Es werden maximal 50 Datensätze gleichzeitig angezeigt. Um die nächste Gruppe von Datensätzen anzuzeigen, klicken Sie auf die Schaltfläche **Weiter**.
1. Klicken Sie auf einen einzelnen Datensatz, um die Nutzdaten dieses Datensatzes im Rohdaten- oder JSON-Format in einem separaten Fenster anzuzeigen.
Beachten Sie, dass, wenn Sie im **Data Viewer** auf die Schaltflächen „**Datensätze abrufen**“ oder „**Weiter**“ klicken, dadurch die **GetRecords**API aufgerufen wird. Dies gilt auch für das **GetRecords**API-Limit von 5 Transaktionen pro Sekunde.
# Fragen Sie Ihre Datenströme in der Kinesis-Konsole ab
Auf der Registerkarte Data Analytics in der Kinesis Data Streams Console können Sie Ihre Datenströme mit SQL abfragen. Gehen Sie folgendermaßen vor, um diese Funktion zu nutzen:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Kinesis-Konsole unter [https://console.aws.amazon.com/kinesis](https://console.aws.amazon.com/kinesis).
1. Wählen Sie den aktiven Datenstream aus, den Sie mit SQL abfragen möchten, und wählen Sie dann die Registerkarte **Datenanalyse**.
1. Auf der Registerkarte **Datenanalyse** können Sie Datenströme mit einem Managed Apache Flink Studio-Notebook überprüfen und visualisieren. Mit Apache Zeppelin können Sie Ad-hoc-SQL-Abfragen durchführen, um Ihren Datenstrom zu überprüfen und die Ergebnisse innerhalb von Sekunden anzuzeigen. Wählen Sie auf der Registerkarte **Datenanalyse** die Option **Ich stimme zu** und wählen Sie dann **Notizbuch erstellen aus, um ein Notizbuch** zu erstellen.
1. Nachdem das Notizbuch erstellt wurde, wählen Sie **In Apache Zeppelin öffnen**. Dadurch wird Ihr Notizbuch in einem neuen Tab geöffnet. Ein Notizbuch ist eine interaktive Oberfläche, über die Sie Ihre SQL-Abfragen einreichen können. Wählen Sie die Notiz aus, die den Namen Ihres Streams enthält.
1. Sie sehen eine Notiz mit einer `SELECT` Beispielabfrage zur Ausgabe der Daten im Stream, der bereits läuft. Auf diese Weise können Sie das Schema für Ihren Datenstream anzeigen.
1. Wählen Sie auf der Registerkarte **Datenanalyse** die Option **Beispielabfragen anzeigen aus, wenn Sie andere Abfragen** ausprobieren möchten, wie z. B. sich öffnende oder verschiebbare Fenster. Kopieren Sie die Abfrage, passen Sie sie an Ihr Datenstromschema an, und führen Sie sie dann in einem neuen Absatz in Ihrer Zeppelin-Notiz aus.
# Verwenden Sie die Kinesis-Clientbibliothek
## Was ist die Kinesis Client Library?
Kinesis Client Library (KCL) ist eine eigenständige Java-Softwarebibliothek, die entwickelt wurde, um den Prozess der Nutzung und Verarbeitung von Daten aus Amazon Kinesis Data Streams zu vereinfachen. KCL bewältigt viele der komplexen Aufgaben im Zusammenhang mit verteilter Datenverarbeitung, sodass sich Entwickler auf die Implementierung ihrer Geschäftslogik für die Datenverarbeitung konzentrieren können. Es verwaltet Aktivitäten wie den Lastenausgleich zwischen mehreren Workern, die Reaktion auf Ausfälle von Mitarbeitern, die Überprüfung verarbeiteter Datensätze und die Reaktion auf Änderungen der Anzahl der Shards im Stream.
KCL wird häufig aktualisiert, um neuere Versionen der zugrunde liegenden Bibliotheken, Sicherheitsverbesserungen und Bugfixes zu integrieren. Wir empfehlen Ihnen, die neueste Version von KCL zu verwenden, um bekannte Probleme zu vermeiden und von allen aktuellen Verbesserungen zu profitieren. [Die neueste KCL-Version finden Sie auf KCL Github.](https://github.com/awslabs/amazon-kinesis-client)
**Wichtig**
Wir empfehlen, die neueste KCL-Version zu verwenden, um bekannte Fehler und Probleme zu vermeiden. Wenn Sie KCL 2.6.0 oder früher verwenden, führen Sie ein Upgrade auf KCL 2.6.1 oder höher durch, um ein seltenes Problem zu vermeiden, das die Shard-Verarbeitung blockieren kann, wenn sich die Stream-Kapazität ändert.
KCL ist eine Java-Bibliothek. Support für andere Sprachen als Java wird über einen Java-basierten Daemon namens bereitgestellt. MultiLangDaemon MultiLangDaemoninteragiert mit der KCL-Anwendung über STDIN und STDOUT. Weitere Informationen zum On finden Sie unter. MultiLangDaemon GitHub [Entwickeln Sie Verbraucher mit KCL in Nicht-Java-Sprachen](develop-kcl-consumers-non-java.md)
Verwenden Sie die AWS SDK für Java Versionen 2.27.19 bis 2.27.23 nicht mit KCL 3.x. Diese Versionen enthalten ein Problem, das einen Ausnahmefehler im Zusammenhang mit der DynamoDB-Nutzung von KCL verursacht. Wir empfehlen, die AWS SDK für Java Version 2.28.0 oder höher zu verwenden, um dieses Problem zu vermeiden.
## Die wichtigsten Funktionen und Vorteile von KCL
Im Folgenden sind die wichtigsten Funktionen und die damit verbundenen Vorteile des KCL aufgeführt:
+ **Skalierbarkeit**: Mit KCL können Anwendungen dynamisch skalieren, indem die Verarbeitungslast auf mehrere Worker verteilt wird. Sie können Ihre Anwendung manuell oder mit automatischer Skalierung nach innen oder außen skalieren, ohne sich Gedanken über die Lastumverteilung machen zu müssen.
+ **Lastenausgleich**: KCL verteilt die Verarbeitungslast automatisch auf die verfügbaren Mitarbeiter, was zu einer gleichmäßigen Verteilung der Arbeit auf die Mitarbeiter führt.
+ **Checkpointing**: KCL verwaltet das Checkpointing verarbeiteter Datensätze, sodass Anwendungen die Verarbeitung an der zuletzt erfolgreich verarbeiteten Position fortsetzen können.
+ **Fehlertoleranz**: KCL bietet integrierte Fehlertoleranzmechanismen, die sicherstellen, dass die Datenverarbeitung auch dann fortgesetzt wird, wenn einzelne Mitarbeiter ausfallen. KCL bietet at-least-once auch die Lieferung an.
+ **Umgang mit Änderungen auf Stream-Ebene**: KCL passt sich an Splits und Zusammenführungen von Shards an, die aufgrund von Änderungen des Datenvolumens auftreten können. Es behält die Reihenfolge bei, indem es sicherstellt, dass untergeordnete Shards erst verarbeitet werden, nachdem der übergeordnete Shard fertiggestellt und mit einem Checkpoint versehen wurde.
+ **Überwachung**: KCL lässt sich in Amazon integrieren, um die Überwachung auf CloudWatch Verbraucherebene zu ermöglichen.
+ **Mehrsprachenunterstützung**: KCL unterstützt Java nativ und ermöglicht mehrere Nicht-Java-Programmiersprachen. MultiLangDaemon
# KCL-Konzepte
In diesem Abschnitt werden die Kernkonzepte und Interaktionen der Kinesis Client Library (KCL) erläutert. Diese Konzepte sind grundlegend für die Entwicklung und Verwaltung von KCL-Verbraucheranwendungen.
+ **KCL-Consumer-Anwendung** — eine maßgeschneiderte Anwendung zum Lesen und Verarbeiten von Datensätzen aus Kinesis-Datenströmen mithilfe der Kinesis Client Library.
+ **Worker** — KCL-Anwendungen für Privatanwender sind in der Regel verteilt, wobei ein oder mehrere Worker gleichzeitig ausgeführt werden. KCL koordiniert die Mitarbeiter so, dass sie Daten aus dem Stream auf verteilte Weise nutzen, und verteilt die Last gleichmäßig auf mehrere Mitarbeiter.
+ **Scheduler** — eine Klasse auf hoher Ebene, die ein KCL-Worker verwendet, um mit der Datenverarbeitung zu beginnen. Jeder KCL-Worker hat einen Scheduler. Der Scheduler initialisiert und überwacht verschiedene Aufgaben, darunter das Synchronisieren von Shard-Informationen aus Kinesis-Datenströmen, das Verfolgen von Shard-Zuweisungen zwischen Workern und das Verarbeiten von Daten aus dem Stream auf der Grundlage der dem Worker zugewiesenen Shards. Der Scheduler kann verschiedene Konfigurationen annehmen, die sich auf das Verhalten des Schedulers auswirken, z. B. den Namen des zu verarbeitenden Streams und die Anmeldeinformationen. AWS Der Scheduler initiiert die Übertragung von Datensätzen aus dem Stream an die Datensatzprozessoren.
+ **Datensatzprozessor** — definiert die Logik dafür, wie Ihre KCL-Consumer-Anwendung die Daten verarbeitet, die sie aus den Datenströmen empfängt. Sie müssen Ihre eigene benutzerdefinierte Datenverarbeitungslogik im Record Processor implementieren. Ein KCL-Worker instanziiert einen Scheduler. Der Scheduler instanziiert dann einen Datensatzprozessor für jeden Shard, für den er eine Lease hält. Ein Worker kann mehrere Datensatzprozessoren ausführen.
+ **Lease** — definiert die Zuordnung zwischen einem Worker und einem Shard. KCL-Anwendungen für Privatanwender verwenden Leases, um die Verarbeitung von Datensätzen auf mehrere Mitarbeiter zu verteilen. Jeder Shard ist jeweils nur an einen Arbeiter durch einen Leasingvertrag gebunden, und jeder Arbeiter kann einen oder mehrere Leasingverträge gleichzeitig abschließen. Wenn ein Arbeitnehmer aufgrund einer Kündigung oder eines Versagens den Mietvertrag beendet, beauftragt KCL einen anderen Mitarbeiter mit der Übernahme des Leasingvertrags. Weitere Informationen zum Leasing finden Sie in der [Github-Dokumentation: Lease](https://github.com/awslabs/amazon-kinesis-client/blob/master/docs/lease-lifecycle.md#lease-lifecycle) Lifecycle.
+ **Leasing-Tabelle** — ist eine einzigartige Amazon DynamoDB-Tabelle, mit der alle Leasingverträge für die KCL-Verbraucheranwendung verfolgt werden. Jede KCL-Consumer-Anwendung erstellt ihre eigene Leasing-Tabelle. Die Leasing-Tabelle wird verwendet, um den Status aller Mitarbeiter aufrechtzuerhalten und die Datenverarbeitung zu koordinieren. Weitere Informationen finden Sie unter [DynamoDB-Metadatentabellen und Lastenausgleich in KCL](kcl-dynamoDB.md).
+ **Checkpointing** — ist der Prozess, bei dem die Position des zuletzt erfolgreich verarbeiteten Datensatzes dauerhaft in einem Shard gespeichert wird. KCL verwaltet Checkpoints, um sicherzustellen, dass die Verarbeitung von der letzten Checkpoint-Position aus wieder aufgenommen werden kann, falls ein Worker ausfällt oder die Anwendung neu gestartet wird. Checkpoints werden in der DynamoDB-Leasetabelle als Teil der Metadaten des Leases gespeichert. Auf diese Weise können Mitarbeiter die Verarbeitung dort fortsetzen, wo der vorherige Mitarbeiter aufgehört hat.
# 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](kcl-iam-permissions.md).
Die KCL-Verbraucheranwendung entfernt diese drei DynamoDB-Metadatentabellen nicht automatisch. Stellen Sie sicher, dass Sie diese von der KCL-Consumer-Anwendung erstellten DynamoDB-Metadatentabellen 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html) 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 Basis-Leasing-Tabelle 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ConsoleDynamoDB.html) 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 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 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](kcl-multi-stream.md)
+ **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](kcl-multi-stream.md).
+ **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.](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. 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“](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/provisioned-capacity-mode.html) 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/provisioned-capacity-mode.html#ddb-autoscaling), 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.UpdateTable) im Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html) Developer Guide.
## Wie KCL Mitarbeitern Leasingverträge zuweist und die Auslastung 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](develop-kcl-consumers-java.md#develop-kcl-consumers-java-prerequisites). 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.
# Entwickeln Sie Verbraucher mit KCL
Sie können die Kinesis Client Library (KCL) verwenden, um Verbraucheranwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten.
KCL ist in mehreren Sprachen verfügbar. Dieses Thema behandelt die Entwicklung von KCL-Consumer in Java- und Nicht-Java-Sprachen.
+ Die Javadoc-Referenz zur Kinesis Client Library finden Sie in der [Amazon Kinesis](https://javadoc.io/doc/software.amazon.kinesis/amazon-kinesis-client/latest/index.html) Client Library Javadoc.
+ Informationen zum Herunterladen von GitHub KCL für Java finden Sie unter [Amazon Kinesis Client Library for](https://github.com/awslabs/amazon-kinesis-client) Java.
+ Informationen zur KCL für Java auf Apache Maven finden Sie im [KCL](https://central.sonatype.com/artifact/software.amazon.kinesis/amazon-kinesis-client) Maven Central Repository.
**Topics**
+ [
# Entwickeln Sie Verbraucher mit KCL in Java
](develop-kcl-consumers-java.md)
+ [
# Entwickeln Sie Verbraucher mit KCL in Nicht-Java-Sprachen
](develop-kcl-consumers-non-java.md)
# Entwickeln Sie Verbraucher mit KCL in Java
## Voraussetzungen
Bevor Sie mit der Verwendung von KCL 3.x beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Java Development Kit (JDK) 8 oder höher
+ AWS SDK für Java 2.x
+ Maven oder Gradle für das Abhängigkeitsmanagement
KCL sammelt Metriken zur CPU-Auslastung, wie z. B. die CPU-Auslastung, von dem Rechenhost, auf dem die Worker arbeiten, um die Last so zu verteilen, dass eine gleichmäßige Ressourcenauslastung für alle Mitarbeiter erreicht wird. Damit KCL die CPU-Nutzungsmetriken von Workern erfassen kann, müssen Sie die folgenden Voraussetzungen erfüllen:
**Amazon Elastic Compute Cloud(Amazon EC2)**
+ Ihr Betriebssystem muss Linux OS sein.
+ Sie müssen es [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)in Ihrer EC2-Instance aktivieren.
**Amazon Elastic Container Service (Amazon ECS) auf Amazon EC2**
+ Ihr Betriebssystem muss Linux OS sein.
+ Sie müssen den [ECS-Endpunkt für Task-Metadaten, Version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ec2-metadata.html), aktivieren.
+ Ihre Amazon ECS-Container-Agent-Version muss 1.39.0 oder höher sein.
**Amazon ECS auf AWS Fargate**
+ Sie müssen den [Fargate-Task-Metadaten-Endpunkt Version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html) aktivieren. Wenn Sie die Fargate-Plattformversion 1.4.0 oder höher verwenden, ist dies standardmäßig aktiviert.
+ Fargate-Plattformversion 1.4.0 oder höher.
**Amazon Elastic Kubernetes Service (Amazon EKS) auf Amazon EC2**
+ Ihr Betriebssystem muss Linux OS sein.
**Amazon EKS auf AWS Fargate**
+ Fargate-Plattform 1.3.0 oder höher.
**Wichtig**
Wenn KCL keine Kennzahlen zur CPU-Auslastung von Mitarbeitern sammeln kann, greift KCL auf den Durchsatz pro Mitarbeiter zurück, um Leasingverträge zuzuweisen und die Auslastung auf die Mitarbeiter in der Flotte zu verteilen. Weitere Informationen finden Sie unter [Wie KCL Mitarbeitern Leasingverträge zuweist und die Auslastung verteilt](kcl-dynamoDB.md#kcl-assign-leases).
## Installieren und fügen Sie Abhängigkeiten hinzu
Wenn Sie Maven verwenden, fügen Sie Ihrer `pom.xml` Datei die folgende Abhängigkeit hinzu. Stellen Sie sicher, dass Sie 3.x.x durch die neueste KCL-Version ersetzt haben.
```
software.amazon.kinesis
amazon-kinesis-client
3.x.x
```
Wenn Sie Gradle verwenden, fügen Sie Ihrer Datei Folgendes hinzu. `build.gradle` Stellen Sie sicher, dass Sie 3.x.x durch die neueste KCL-Version ersetzt haben.
```
implementation 'software.amazon.kinesis:amazon-kinesis-client:3.x.x'
```
[Sie können im Maven Central Repository nach der neuesten Version der KCL suchen.](https://search.maven.org/artifact/software.amazon.kinesis/amazon-kinesis-client)
## Implementieren Sie den Verbraucher
Eine KCL-Verbraucheranwendung besteht aus den folgenden Schlüsselkomponenten:
**Topics**
+ [
### RecordProcessor
](#implementation-recordprocessor)
+ [
### RecordProcessorFactory
](#implementation-recordprocessorfactory)
+ [
### Scheduler
](#implementation-scheduler)
+ [
### Hauptanwendung für Privatanwender
](#implementation-main)
### RecordProcessor
RecordProcessor ist die Kernkomponente, in der sich Ihre Geschäftslogik für die Verarbeitung von Kinesis-Datenstream-Datensätzen befindet. Es definiert, wie Ihre Anwendung die Daten verarbeitet, die sie vom Kinesis-Stream empfängt.
Wichtigste Aufgaben:
+ Initialisieren Sie die Verarbeitung für einen Shard
+ Batches von Datensätzen aus dem Kinesis-Stream verarbeiten
+ Die Verarbeitung für einen Shard herunterfahren (z. B. wenn der Shard geteilt oder zusammengeführt wird oder der Lease an einen anderen Host übergeben wird)
+ Verwalte Checkpoints, um den Fortschritt zu verfolgen
Im Folgenden wird ein Implementierungsbeispiel gezeigt:
```
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;
import software.amazon.kinesis.exceptions.InvalidStateException;
import software.amazon.kinesis.exceptions.ShutdownException;
import software.amazon.kinesis.lifecycle.events.*;
import software.amazon.kinesis.processor.ShardRecordProcessor;
public class SampleRecordProcessor implements ShardRecordProcessor {
private static final String SHARD_ID_MDC_KEY = "ShardId";
private static final Logger log = LoggerFactory.getLogger(SampleRecordProcessor.class);
private String shardId;
@Override
public void initialize(InitializationInput initializationInput) {
shardId = initializationInput.shardId();
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Initializing @ Sequence: {}", initializationInput.extendedSequenceNumber());
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
@Override
public void processRecords(ProcessRecordsInput processRecordsInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Processing {} record(s)", processRecordsInput.records().size());
processRecordsInput.records().forEach(r ->
log.info("Processing record pk: {} -- Seq: {}", r.partitionKey(), r.sequenceNumber())
);
// Checkpoint periodically
processRecordsInput.checkpointer().checkpoint();
} catch (Throwable t) {
log.error("Caught throwable while processing records. Aborting.", t);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
@Override
public void leaseLost(LeaseLostInput leaseLostInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Lost lease, so terminating.");
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
@Override
public void shardEnded(ShardEndedInput shardEndedInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Reached shard end checkpointing.");
shardEndedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at shard end. Giving up.", e);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
@Override
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Scheduler is shutting down, checkpointing.");
shutdownRequestedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at requested shutdown. Giving up.", e);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
}
```
Im Folgenden finden Sie eine detaillierte Erläuterung der einzelnen in diesem Beispiel verwendeten Methoden:
**initialisieren (InitializationInputInitializationInput)**
+ Zweck: Richten Sie alle erforderlichen Ressourcen oder den Status für die Verarbeitung von Datensätzen ein.
+ Wann es aufgerufen wird: Einmal, wenn KCL diesem Datensatzprozessor einen Shard zuweist.
+ Die wichtigsten Punkte:
+ `initializationInput.shardId()`: Die ID des Shards, den dieser Prozessor verarbeiten wird.
+ `initializationInput.extendedSequenceNumber()`: Die Sequenznummer, von der aus die Verarbeitung gestartet werden soll.
**processRecords () ProcessRecordsInput processRecordsInput**
+ Zweck: Verarbeitet die eingehenden Datensätze und überprüft optional den Fortschritt.
+ Wann es aufgerufen wird: Wiederholt, solange der Datensatzprozessor den Leasingvertrag für den Shard hält.
+ Die wichtigsten Punkte:
+ `processRecordsInput.records()`: Liste der zu verarbeitenden Datensätze.
+ `processRecordsInput.checkpointer()`: Wird verwendet, um den Fortschritt zu überprüfen.
+ Stellen Sie sicher, dass Sie alle Ausnahmen während der Verarbeitung behandelt haben, um zu verhindern, dass KCL fehlschlägt.
+ Diese Methode sollte idempotent sein, da derselbe Datensatz in einigen Szenarien mehrfach verarbeitet werden kann, z. B. bei Daten, die vor einem unerwarteten Absturz oder Neustart des Workers nicht überprüft wurden.
+ Leeren Sie vor dem Checkpoint stets alle gepufferten Daten, um die Datenkonsistenz sicherzustellen.
**LeaseLost () LeaseLostInput leaseLostInput**
+ Zweck: Bereinigen Sie alle Ressourcen, die für die Verarbeitung dieses Shards spezifisch sind.
+ Wann es aufgerufen wird: Wenn ein anderer Scheduler den Lease für diesen Shard übernimmt.
+ Die wichtigsten Punkte:
+ Checkpointing ist bei dieser Methode nicht erlaubt.
**ShardEnded () ShardEndedInput shardEndedInput**
+ Zweck: Beenden Sie die Verarbeitung für diesen Shard und diesen Checkpoint.
+ Zeitpunkt des Aufrufs: Wenn der Shard geteilt oder zusammengeführt wird, was bedeutet, dass alle Daten für diesen Shard verarbeitet wurden.
+ Die wichtigsten Punkte:
+ `shardEndedInput.checkpointer()`: Wird verwendet, um das letzte Checkpointing durchzuführen.
+ Checkpointing ist bei dieser Methode zwingend erforderlich, um die Verarbeitung abzuschließen.
+ Wenn die Daten und der Checkpoint hier nicht geleert werden, kann dies zu Datenverlust oder doppelter Verarbeitung führen, wenn der Shard erneut geöffnet wird.
**ShutdownRequestedInput shutdownRequestedInputshutdownRequested ()**
+ Zweck: Checkpoint und Bereinigen von Ressourcen, wenn KCL heruntergefahren wird.
+ Wann es aufgerufen wird: Wenn KCL heruntergefahren wird (z. B. wenn die Anwendung beendet wird).
+ Die wichtigsten Punkte:
+ `shutdownRequestedInput.checkpointer()`: Wird verwendet, um Checkpoints vor dem Herunterfahren durchzuführen.
+ Stellen Sie sicher, dass Sie Checkpointing in der Methode implementiert haben, damit der Fortschritt gespeichert wird, bevor die Anwendung beendet wird.
+ Wenn die Daten und der Checkpoint hier nicht geleert werden, kann dies zu Datenverlust oder zur erneuten Verarbeitung von Datensätzen führen, wenn die Anwendung neu gestartet wird.
**Wichtig**
KCL 3.x sorgt dafür, dass weniger Daten erneut verarbeitet werden, wenn der Mietvertrag von einem Mitarbeiter an einen anderen übergeben wird, indem ein Checkpoint ausgeführt wird, bevor der vorherige Mitarbeiter geschlossen wird. Wenn Sie die Checkpoint-Logik nicht in der `shutdownRequested()` Methode implementieren, werden Sie diesen Vorteil nicht sehen. Stellen Sie sicher, dass Sie in der Methode eine Checkpoint-Logik implementiert haben. `shutdownRequested()`
### RecordProcessorFactory
RecordProcessorFactory ist verantwortlich für die Erstellung neuer RecordProcessor Instanzen. KCL verwendet diese Factory, um RecordProcessor für jeden Shard, den die Anwendung verarbeiten muss, eine neue zu erstellen.
Wichtigste Aufgaben:
+ Erstellen Sie bei Bedarf neue RecordProcessor Instanzen
+ Stellen Sie sicher, dass jede ordnungsgemäß initialisiert RecordProcessor ist
Im Folgenden finden Sie ein Implementierungsbeispiel:
```
import software.amazon.kinesis.processor.ShardRecordProcessor;
import software.amazon.kinesis.processor.ShardRecordProcessorFactory;
public class SampleRecordProcessorFactory implements ShardRecordProcessorFactory {
@Override
public ShardRecordProcessor shardRecordProcessor() {
return new SampleRecordProcessor();
}
}
```
In diesem Beispiel erstellt die Factory bei SampleRecordProcessor jedem Aufruf von shardRecordProcessor () ein neues. Sie können dies um jede erforderliche Initialisierungslogik erweitern.
### Scheduler
Der Scheduler ist eine Komponente auf hoher Ebene, die alle Aktivitäten der KCL-Anwendung koordiniert. Es ist für die gesamte Orchestrierung der Datenverarbeitung verantwortlich.
Wichtigste Aufgaben:
+ Managen Sie den Lebenszyklus von RecordProcessors
+ Erledigen Sie das Leasingmanagement für Shards
+ Koordinieren Sie die Checkpoints
+ Verteilen Sie die Shard-Verarbeitungslast auf mehrere Worker Ihrer Anwendung
+ Bewältigen Sie Signale für ein ordnungsgemäßes Herunterfahren und Beenden von Anwendungen
Der Scheduler wird normalerweise in der Hauptanwendung erstellt und gestartet. Das Implementierungsbeispiel von Scheduler finden Sie im folgenden Abschnitt, Main Consumer Application.
### Hauptanwendung für Privatanwender
Die Hauptanwendung für Verbraucher verbindet alle Komponenten miteinander. Sie ist verantwortlich für die Einrichtung des KCL-Consumer, die Erstellung der erforderlichen Clients, die Konfiguration des Schedulers und die Verwaltung des Lebenszyklus der Anwendung.
Wichtigste Aufgaben:
+ AWS Service-Clients einrichten (Kinesis, DynamoDB,) CloudWatch
+ Konfigurieren Sie die KCL-Anwendung
+ Erstellen und starten Sie den Scheduler
+ Behandelt das Herunterfahren der Anwendung
Im Folgenden finden Sie ein Implementierungsbeispiel:
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.cloudwatch.CloudWatchAsyncClient;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClient;
import software.amazon.awssdk.services.kinesis.KinesisAsyncClient;
import software.amazon.kinesis.common.ConfigsBuilder;
import software.amazon.kinesis.common.KinesisClientUtil;
import software.amazon.kinesis.coordinator.Scheduler;
import java.util.UUID;
public class SampleConsumer {
private final String streamName;
private final Region region;
private final KinesisAsyncClient kinesisClient;
public SampleConsumer(String streamName, Region region) {
this.streamName = streamName;
this.region = region;
this.kinesisClient = KinesisClientUtil.createKinesisAsyncClient(KinesisAsyncClient.builder().region(this.region));
}
public void run() {
DynamoDbAsyncClient dynamoDbAsyncClient = DynamoDbAsyncClient.builder().region(region).build();
CloudWatchAsyncClient cloudWatchClient = CloudWatchAsyncClient.builder().region(region).build();
ConfigsBuilder configsBuilder = new ConfigsBuilder(
streamName,
streamName,
kinesisClient,
dynamoDbAsyncClient,
cloudWatchClient,
UUID.randomUUID().toString(),
new SampleRecordProcessorFactory()
);
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig(),
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig()
);
Thread schedulerThread = new Thread(scheduler);
schedulerThread.setDaemon(true);
schedulerThread.start();
}
public static void main(String[] args) {
String streamName = "your-stream-name"; // replace with your stream name
Region region = Region.US_EAST_1; // replace with your region
new SampleConsumer(streamName, region).run();
}
}
```
KCL erstellt standardmäßig einen Enhanced Fan-Out (EFO) -Consumer mit dediziertem Durchsatz. Weitere Informationen zu Enhanced Fan-Out finden Sie unter. [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md) Wenn Sie weniger als 2 Verbraucher haben oder keine Verzögerungen bei der Leseverteilung unter 200 ms benötigen, müssen Sie im Scheduler-Objekt die folgende Konfiguration festlegen, um Verbraucher mit gemeinsamem Durchsatz zu verwenden:
```
configsBuilder.retrievalConfig().retrievalSpecificConfig(new PollingConfig(streamName, kinesisClient))
```
Der folgende Code ist ein Beispiel für die Erstellung eines Scheduler-Objekts, das Verbraucher mit gemeinsamem Durchsatz verwendet:
**Importe:**
```
import software.amazon.kinesis.retrieval.polling.PollingConfig;
```
**Kode**:
```
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig(),
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig().retrievalSpecificConfig(new PollingConfig(streamName, kinesisClient))
);/
```
# Entwickeln Sie Verbraucher mit KCL in Nicht-Java-Sprachen
In diesem Abschnitt wird die Implementierung von Verbrauchern mithilfe der Kinesis Client Library (KCL) in Python, Node.js, .NET und Ruby behandelt.
KCL ist eine Java-Bibliothek. Die Support für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle namens bereitgestellt. `MultiLangDaemon` Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine KCL mit einer anderen Sprache als Java verwenden. Wenn Sie also KCL für Nicht-Java-Sprachen installieren und Ihre Consumer-App vollständig in Nicht-Java-Sprachen schreiben, muss Java aufgrund der trotzdem auf Ihrem System installiert sein. `MultiLangDaemon` Darüber hinaus `MultiLangDaemon` verfügt es über einige Standardeinstellungen, die Sie möglicherweise für Ihren Anwendungsfall anpassen müssen (z. B. die AWS-Region, mit der eine Verbindung hergestellt wird). Weitere Informationen dazu finden Sie unter [ MultiLangDaemon KCL-Projekt](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang). `MultiLangDaemon` GitHub
Die Kernkonzepte bleiben zwar in allen Sprachen gleich, es gibt jedoch einige sprachspezifische Überlegungen und Implementierungen. Die Kernkonzepte zur Entwicklung von KCL-Verbrauchern finden Sie unter. [Entwickeln Sie Verbraucher mit KCL in Java](develop-kcl-consumers-java.md) Ausführlichere Informationen zur Entwicklung von KCL-Consumern in Python, Node.js, .NET und Ruby sowie die neuesten Updates finden Sie in den folgenden GitHub Repositorys:
+ Python: [amazon-kinesis-client-python](https://github.com/awslabs/amazon-kinesis-client-python)
+ Node.js: [amazon-kinesis-client-nodejs](https://github.com/awslabs/amazon-kinesis-client-nodejs)
+ .NET: [amazon-kinesis-client-net](https://github.com/awslabs/amazon-kinesis-client-net)
+ Rubin: [amazon-kinesis-client-ruby](https://github.com/awslabs/amazon-kinesis-client-ruby)
**Wichtig**
Verwenden Sie nicht die folgenden Nicht-Java-Versionen der KCL-Bibliothek, wenn Sie JDK 8 verwenden. Diese Versionen enthalten eine Abhängigkeit (Logback), die mit JDK 8 nicht kompatibel ist.
KCL Python 3.0.2 und 2.2.0
KCL Node.js 2.3.0
KCL.NET 3.1.0
KCL Ruby 2.2.0
Wir empfehlen, bei der Arbeit mit JDK 8 Versionen zu verwenden, die entweder vor oder nach diesen betroffenen Versionen veröffentlicht wurden.
# Multistream-Verarbeitung mit KCL
In diesem Abschnitt werden die erforderlichen Änderungen in KCL beschrieben, die es Ihnen ermöglichen, KCL-Consumer-Anwendungen zu erstellen, die mehr als einen Datenstrom gleichzeitig verarbeiten können.
**Wichtig**
Die Multistream-Verarbeitung wird nur in KCL 2.3 oder höher unterstützt.
Die Multistream-Verarbeitung wird *nicht* für KCL-Benutzer unterstützt, die in anderen Sprachen als Java geschrieben sind und mit ausgeführt werden. `multilangdaemon`
*Die Multistream-Verarbeitung wird in keiner Version von KCL 1.x unterstützt.*
+ **MultistreamTracker Schnittstelle**
+ Um eine Verbraucheranwendung zu erstellen, die mehrere Streams gleichzeitig verarbeiten kann, müssen Sie eine neue Schnittstelle namens implementieren [MultistreamTracker](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/processor/MultiStreamTracker.java). Diese Schnittstelle enthält die `streamConfigList`-Methode, die die Liste der Datenströme und ihrer Konfigurationen zurückgibt, die von der KCL-Konsumentenanwendung verarbeitet werden sollen. Beachten Sie, dass die Datenströme, die verarbeitet werden, während der Laufzeit der Verbraucheranwendung geändert werden können. `streamConfigList`wird regelmäßig von KCL aufgerufen, um mehr über die Änderungen der zu verarbeitenden Datenströme zu erfahren.
+ Das `streamConfigList` füllt die Liste auf [StreamConfig](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/StreamConfig.java#L23).
```
package software.amazon.kinesis.common;
import lombok.Data;
import lombok.experimental.Accessors;
@Data
@Accessors(fluent = true)
public class StreamConfig {
private final StreamIdentifier streamIdentifier;
private final InitialPositionInStreamExtended initialPositionInStreamExtended;
private String consumerArn;
}
```
+ Die Felder `StreamIdentifier` und `InitialPositionInStreamExtended` sind Pflichtfelder, während sie optional `consumerArn` sind. Sie müssen das `consumerArn` nur angeben, wenn Sie KCL verwenden, um eine erweiterte Fan-Out-Anwendung für Privatanwender zu implementieren.
+ Weitere Informationen `StreamIdentifier` dazu finden Sie unter [https://github.com/awslabs/amazon-kinesis-client/blob/v2.5.8/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/StreamIdentifier.java \$1L129.](https://github.com/awslabs/amazon-kinesis-client/blob/v2.5.8/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/StreamIdentifier.java#L129) Um eine zu erstellen`StreamIdentifier`, empfehlen wir, eine Multistream-Instanz aus dem `streamArn` und dem zu erstellen`streamCreationEpoch`, das in KCL 2.5.0 oder höher verfügbar ist. Erstellen Sie in KCL v2.3 und v2.4, die dies nicht unterstützen`streamArm`, eine Multistream-Instanz mithilfe des folgenden Formats. `account-id:StreamName:streamCreationTimestamp` Dieses Format ist veraltet und wird ab der nächsten Hauptversion nicht mehr unterstützt.
+ MultistreamTracker beinhaltet auch eine Strategie zum Löschen von Leasingverträgen alter Streams in der Leasetabelle (). formerStreamsLeases DeletionStrategy Beachten Sie, dass die Strategie während der Laufzeit der Konsumentenanwendung NICHT geändert werden kann. Weitere Informationen finden Sie unter [https://github.com/awslabs/amazon-kinesis-clientb/amazon-kinesis-client/src/main/java/software/amazon/kinesis/processor/FormerStreamsLeasesDeletionStrategy/blob/0c5042dadf794fe988438436252a5a8fe70b6b0](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/processor/FormerStreamsLeasesDeletionStrategy.java) .java.
+ [ConfigsBuilder](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/ConfigsBuilder.java)ist eine anwendungsweite Klasse, mit der Sie alle KCL-Konfigurationseinstellungen angeben können, die beim Erstellen Ihrer KCL-Consumer-Anwendung für KCL-Version 2.x oder höher verwendet werden sollen. `ConfigsBuilder`Die Klasse unterstützt jetzt die Schnittstelle. `MultistreamTracker` Sie können ConfigsBuilder entweder mit dem Namen des einen Datenstroms initialisieren, aus dem Datensätze abgerufen werden sollen:
```
/**
* Constructor to initialize ConfigsBuilder with StreamName
* @param streamName
* @param applicationName
* @param kinesisClient
* @param dynamoDBClient
* @param cloudWatchClient
* @param workerIdentifier
* @param shardRecordProcessorFactory
*/
public ConfigsBuilder(@NonNull String streamName, @NonNull String applicationName,
@NonNull KinesisAsyncClient kinesisClient, @NonNull DynamoDbAsyncClient dynamoDBClient,
@NonNull CloudWatchAsyncClient cloudWatchClient, @NonNull String workerIdentifier,
@NonNull ShardRecordProcessorFactory shardRecordProcessorFactory) {
this.appStreamTracker = Either.right(streamName);
this.applicationName = applicationName;
this.kinesisClient = kinesisClient;
this.dynamoDBClient = dynamoDBClient;
this.cloudWatchClient = cloudWatchClient;
this.workerIdentifier = workerIdentifier;
this.shardRecordProcessorFactory = shardRecordProcessorFactory;
}
```
Oder Sie können ConfigsBuilder mit initialisieren, `MultiStreamTracker` wenn Sie eine KCL-Consumer-Anwendung implementieren möchten, die mehrere Streams gleichzeitig verarbeitet.
```
* Constructor to initialize ConfigsBuilder with MultiStreamTracker
* @param multiStreamTracker
* @param applicationName
* @param kinesisClient
* @param dynamoDBClient
* @param cloudWatchClient
* @param workerIdentifier
* @param shardRecordProcessorFactory
*/
public ConfigsBuilder(@NonNull MultiStreamTracker multiStreamTracker, @NonNull String applicationName,
@NonNull KinesisAsyncClient kinesisClient, @NonNull DynamoDbAsyncClient dynamoDBClient,
@NonNull CloudWatchAsyncClient cloudWatchClient, @NonNull String workerIdentifier,
@NonNull ShardRecordProcessorFactory shardRecordProcessorFactory) {
this.appStreamTracker = Either.left(multiStreamTracker);
this.applicationName = applicationName;
this.kinesisClient = kinesisClient;
this.dynamoDBClient = dynamoDBClient;
this.cloudWatchClient = cloudWatchClient;
this.workerIdentifier = workerIdentifier;
this.shardRecordProcessorFactory = shardRecordProcessorFactory;
}
```
+ Da die Multistream-Unterstützung für Ihre KCL-Consumer-Anwendung implementiert ist, enthält jede Zeile der Leasetabelle der Anwendung jetzt die Shard-ID und den Stream-Namen der mehreren Datenströme, die diese Anwendung verarbeitet.
+ Wenn Multistream-Unterstützung für Ihre KCL-Verbraucheranwendung implementiert ist, hat der LeaseKey die folgende Struktur:. `account-id:StreamName:streamCreationTimestamp:ShardId` Beispiel, `111111111:multiStreamTest-1:12345:shardId-000000000336`.
**Wichtig**
Wenn Ihre bestehende KCL-Consumer-Anwendung so konfiguriert ist, dass sie nur einen Datenstrom verarbeitet, ist der `leaseKey` (der Partitionsschlüssel für die Leasetabelle) die Shard-ID. Wenn Sie eine bestehende KCL-Consumer-Anwendung so umkonfigurieren, dass sie mehrere Datenströme verarbeitet, wird Ihre Leasing-Tabelle beschädigt, da die `leaseKey` Struktur wie folgt aussehen muss: `account-id:StreamName:StreamCreationTimestamp:ShardId` um Multistream zu unterstützen.
# Verwenden Sie die AWS Glue Schemaregistrierung mit KCL
Sie können Kinesis Data Streams in die AWS Glue Schema-Registry integrieren. Mit der AWS Glue Schema-Registry können Sie Schemas zentral erkennen, steuern und weiterentwickeln und gleichzeitig sicherstellen, dass die erstellten Daten kontinuierlich anhand eines registrierten Schemas validiert werden. Ein Schema definiert die Struktur und das Format eines Datensatzes. Ein Schema ist eine versionierte Spezifikation für zuverlässige Datenveröffentlichung, -nutzung oder -speicherung. Mit der AWS Glue Schemaregistrierung können Sie die end-to-end Datenqualität und Datenverwaltung in Ihren Streaming-Anwendungen verbessern. Weitere Informationen finden Sie unter [AWS Glue Schema Registry](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html). Eine Möglichkeit, diese Integration einzurichten, ist KCL für Java.
**Wichtig**
AWS Glue Die Schemaregistrierungsintegration für Kinesis Data Streams wird nur in KCL 2.3 oder höher unterstützt.
AWS Glue Die Schemaregistrierungsintegration für Kinesis Data Streams wird *nicht* für KCL-Verbraucher unterstützt, die in Nicht-Java-Sprachen geschrieben sind und mit ausgeführt werden. `multilangdaemon`
AWS Glue *Die Schemaregistrierungsintegration für Kinesis Data Streams wird in keiner Version von KCL 1.x unterstützt.*
Detaillierte Anweisungen zum Einrichten der Integration von Kinesis Data Streams mit der AWS Glue Schemaregistry mithilfe von KCL finden Sie im Abschnitt „Interaktion mit Daten mithilfe der KPL/KCL Bibliotheken“ unter [Anwendungsfall: Integration von Amazon Kinesis Data Streams mit](https://docs.aws.amazon.com/glue/latest/dg/schema-registry-integrations.html#schema-registry-integrations-kds) der Schemaregistry. AWS Glue
# Für KCL-Anwendungen für Privatanwender sind IAM-Berechtigungen erforderlich
Sie müssen der IAM-Rolle oder dem Benutzer, der Ihrer KCL-Consumer-Anwendung zugeordnet ist, die folgenden Berechtigungen hinzufügen.
Bewährte Sicherheitsmethoden für AWS schreiben die Verwendung detaillierter Berechtigungen vor, um den Zugriff auf verschiedene Ressourcen zu kontrollieren. AWS Identity and Access Management (IAM) ermöglicht die Verwaltung von Benutzern und Benutzerberechtigungen in. AWS Eine IAM-Richtlinie führt explizit zulässige Aktionen sowie Ressourcen auf, für die diese Aktionen relevant sind.
In der folgenden Tabelle sind die IAM-Mindestberechtigungen aufgeführt, die im Allgemeinen für KCL-Verbraucheranwendungen erforderlich sind:
**Minimale IAM-Berechtigungen für KCL-Verbraucheranwendungen**
| Service | Aktionen | Ressourcen () ARNs | Zweck |
| --- | --- | --- | --- |
| Amazon Kinesis Data Streams | `DescribeStream` `DescribeStreamSummary` `RegisterStreamConsumer` | Kinesis-Datenstream, aus dem Ihre KCL-Anwendung die Daten verarbeitet.`arn:aws:kinesis:region:account:stream/StreamName` | Vor dem Versuch, Datensätze zu lesen, prüft der Verbraucher, ob der Daten-Stream vorhanden und ob er aktiv ist und ob Shards im Daten-Stream enthalten sind. Registriert Verbraucher auf einem Shard. |
| Amazon Kinesis Data Streams | `GetRecords` `GetShardIterator` `ListShards` | Kinesis-Datenstream, aus dem Ihre KCL-Anwendung die Daten verarbeitet.`arn:aws:kinesis:region:account:stream/StreamName` | Auslesen von Datensätzen aus einem Shard. |
| Amazon Kinesis Data Streams | `SubscribeToShard` `DescribeStreamConsumer` | Kinesis-Datenstream, aus dem Ihre KCL-Anwendung die Daten verarbeitet. Fügen Sie diese Aktion nur hinzu, wenn Sie Enhanced Fanout (EFO) -Verbraucher verwenden. `arn:aws:kinesis:region:account:stream/StreamName/consumer/*` | Abonniert einen Shard für Enhanced Fan-Out (EFO) -Verbraucher. |
| Amazon DynamoDB | `CreateTable` `DescribeTable` `UpdateTable` `Scan` `GetItem` `PutItem` `UpdateItem` `DeleteItem` | Leasetabelle (von KCL erstellte Metadatentabelle in DynamoDB). `arn:aws:dynamodb:region:account:table/KCLApplicationName` | Diese Aktionen sind erforderlich, damit KCL die in DynamoDB erstellte Leasetabelle verwalten kann. |
| Amazon DynamoDB | `CreateTable` `DescribeTable` `Scan` `GetItem` `PutItem` `UpdateItem` `DeleteItem` | Von KCL erstellte Worker-Metriken und Koordinatorstatustabelle (Metadatentabellen in DynamoDB). `arn:aws:dynamodb:region:account:table/KCLApplicationName-WorkerMetricStats` `arn:aws:dynamodb:region:account:table/KCLApplicationName-CoordinatorState` | Diese Aktionen sind erforderlich, damit KCL die Worker-Metriken und die Koordinatorstatus-Metadatentabellen in DynamoDB verwalten kann. |
| Amazon DynamoDB | `Query` | Globaler sekundärer Index in der Leasing-Tabelle. `arn:aws:dynamodb:region:account:table/KCLApplicationName/index/*` | Diese Aktion ist erforderlich, damit KCL den globalen sekundären Index der in DynamoDB erstellten Leasetabelle lesen kann. |
| Amazon CloudWatch | `PutMetricData` | \$1 | Laden Sie Metriken hoch CloudWatch , die für die Überwachung der Anwendung nützlich sind. Das Sternchen (\$1) wird verwendet, weil es keine bestimmte Ressource gibt, für die die `PutMetricData` Aktion aufgerufen wird. CloudWatch |
**Anmerkung**
Ersetzen Sie „Region“, „Konto“, „StreamName“ und „KCLApplicationName“ in der ARNs durch Ihre eigene AWS-Konto Nummer AWS-Region, den Kinesis-Datenstromnamen bzw. den KCL-Anwendungsnamen. KCL 3.x erstellt zwei weitere Metadatentabellen in DynamoDB. Einzelheiten zu DynamoDB-Metadatentabellen, die von KCL erstellt wurden, finden Sie unter. [DynamoDB-Metadatentabellen und Lastenausgleich in KCL](kcl-dynamoDB.md) Wenn Sie Konfigurationen verwenden, um die Namen der von KCL erstellten Metadatentabellen anzupassen, verwenden Sie diese angegebenen Tabellennamen anstelle des KCL-Anwendungsnamens.
Im Folgenden finden Sie ein Beispiel für ein Richtliniendokument für eine KCL-Verbraucheranwendung.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:DescribeStreamSummary",
"kinesis:RegisterStreamConsumer",
"kinesis:GetRecords",
"kinesis:GetShardIterator",
"kinesis:ListShards"
],
"Resource": "arn:aws:kinesis:us-east-1:123456789012:stream/STREAM_NAME"
},
{
"Effect": "Allow",
"Action": [
"kinesis:SubscribeToShard",
"kinesis:DescribeStreamConsumer"
],
"Resource": "arn:aws:kinesis:us-east-1:123456789012:stream/STREAM_NAME/consumer/*"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:CreateTable",
"dynamodb:DescribeTable",
"dynamodb:UpdateTable",
"dynamodb:GetItem",
"dynamodb:UpdateItem",
"dynamodb:PutItem",
"dynamodb:DeleteItem",
"dynamodb:Scan"
],
"Resource": [
"arn:aws:dynamodb:us-east-1:123456789012:table/KCL_APPLICATION_NAME"
]
},
{
"Effect": "Allow",
"Action": [
"dynamodb:CreateTable",
"dynamodb:DescribeTable",
"dynamodb:GetItem",
"dynamodb:UpdateItem",
"dynamodb:PutItem",
"dynamodb:DeleteItem",
"dynamodb:Scan"
],
"Resource": [
"arn:aws:dynamodb:us-east-1:123456789012:table/KCL_APPLICATION_NAME-WorkerMetricStats",
"arn:aws:dynamodb:us-east-1:123456789012:table/KCL_APPLICATION_NAME-CoordinatorState"
]
},
{
"Effect": "Allow",
"Action": [
"dynamodb:Query"
],
"Resource": [
"arn:aws:dynamodb:us-east-1:123456789012:table/KCL_APPLICATION_NAME/index/*"
]
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*"
}
]
}
```
------
Bevor Sie diese Beispielrichtlinie verwenden, überprüfen Sie die folgenden Punkte:
+ Ersetzen Sie REGION durch Ihr AWS-Region (zum Beispiel us-east-1).
+ Ersetzen Sie ACCOUNT\$1ID durch Ihre ID. AWS-Konto
+ Ersetzen Sie STREAM\$1NAME durch den Namen Ihres Kinesis-Datenstreams.
+ Ersetzen Sie CONSUMER\$1NAME durch den Namen Ihres Verbrauchers, normalerweise Ihren Anwendungsnamen, wenn Sie KCL verwenden.
+ Ersetzen Sie KCL\$1APPLICATION\$1NAME durch den Namen Ihrer KCL-Anwendung.
# KCL-Konfigurationen
Sie können Konfigurationseigenschaften festlegen, um die Funktionalität der Kinesis Client Library an Ihre spezifischen Anforderungen anzupassen. In der folgenden Tabelle werden die Konfigurationseigenschaften und Klassen beschrieben.
**Wichtig**
In KCL 3.x zielt der Load-Balancing-Algorithmus darauf ab, eine gleichmäßige CPU-Auslastung für alle Worker zu erreichen und nicht die gleiche Anzahl von Leases pro Worker. Wenn der `maxLeasesForWorker` Wert zu niedrig ist, schränken Sie möglicherweise die Fähigkeit von KCL ein, die Arbeitslast effektiv auszugleichen. Wenn Sie die `maxLeasesForWorker` Konfiguration verwenden, sollten Sie erwägen, ihren Wert zu erhöhen, um eine bestmögliche Lastverteilung zu ermöglichen.
**Diese Tabelle zeigt die Konfigurationseigenschaften für KCL**
| Konfigurationseigenschaft | Konfigurationsklasse | Description | Standardwert |
| --- | --- | --- | --- |
| applicationName | ConfigsBuilder | Der Name für die KCL-Anwendung. Wird als Standard für tableName und consumerName verwendet. | Nicht zutreffend |
| tableName | ConfigsBuilder | Ermöglicht das Überschreiben des für die Lease-Tabelle von Amazon DynamoDB verwendeten Tabellennamens. | Nicht zutreffend |
| streamName | ConfigsBuilder | Der Name des Streams, dessen Datensätze diese Anwendung verarbeitet. | Nicht zutreffend |
| workerIdentifier | ConfigsBuilder | Eine eindeutige Kennung, die die Instanziierung des Anwendungsprozessors repräsentiert. Dieser Wert muss eindeutig sein. | Nicht zutreffend |
| failoverTimeMillis | LeaseManagementConfig | Anzahl Millisekunden, nach deren Ablauf unterstellt werden kann, dass ein Lease-Eigentümer fehlgeschlagen ist. Für Anwendungen mit einer großen Anzahl von Shards kann diese Zahl auf eine höhere Anzahl festgelegt werden, um die Anzahl der DynamoDB-IOPS zu reduzieren, die für die Nachverfolgung von Leases erforderlich sind. | 10.000 (10 Sekunden) |
| shardSyncIntervalMillis | LeaseManagementConfig | Die Zeit zwischen Shard-Synchronisierungsaufrufen. | 60.000 (60 Sekunden) |
| cleanupLeasesUponShardCompletion | LeaseManagementConfig | Wenn diese Option aktiviert ist, werden Leases entfernt, sobald die untergeordneten Leases die Verarbeitung gestartet haben. | TRUE |
| ignoreUnexpectedChildShards | LeaseManagementConfig | Wenn diese Option aktiviert ist, werden untergeordnete Shards, die einen offenen Shard aufweisen, ignoriert. Dies gilt hauptsächlich für DynamoDB Streams. | FALSE |
| maxLeasesForWorker | LeaseManagementConfig | Die maximale Anzahl von Leasingverträgen, die ein einzelner Arbeitnehmer annehmen sollte. Eine zu niedrige Einstellung kann zu Datenverlusten führen, wenn Mitarbeiter nicht alle Shards verarbeiten können, was zu einer suboptimalen Leasingzuweisung zwischen den Mitarbeitern führen kann. Berücksichtigen Sie bei der Konfiguration die Gesamtzahl der Shards, die Anzahl der Worker und die Verarbeitungskapazität der Mitarbeiter. | Unbegrenzt |
| maxLeaseRenewalThreads | LeaseManagementConfig | Steuert die Größe des Lease-Renewer-Thread-Pools. Dieser Pool muss größer sein, wenn die Anwendung mehr Leases annehmen kann. | 20 |
| billingMode | LeaseManagementConfig | Bestimmt den Kapazitätsmodus der in DynamoDB erstellten Leasetabelle. Es gibt zwei Optionen: den On-Demand-Modus (PAY\$1PER\$1REQUEST) und den Bereitstellungsmodus. Wir empfehlen, die Standardeinstellung des On-Demand-Modus zu verwenden, da dieser automatisch an Ihre Arbeitslast angepasst wird, ohne dass eine Kapazitätsplanung erforderlich ist. | PAY\$1PER\$1REQUEST (On-Demand-Modus) |
| initialLeaseTableReadCapacity | LeaseManagementConfig | Die DynamoDB-Lesekapazität, die verwendet wird, wenn die Kinesis-Clientbibliothek eine neue DynamoDB-Leasetabelle mit bereitgestelltem Kapazitätsmodus erstellen muss. Sie können diese Konfiguration ignorieren, wenn Sie in der Konfiguration den standardmäßigen On-Demand-Kapazitätsmodus verwenden. billingMode | 10 |
| initialLeaseTableWriteCapacity | LeaseManagementConfig | Die DynamoDB-Lesekapazität, die verwendet wird, wenn die Kinesis-Clientbibliothek eine neue DynamoDB-Leasetabelle erstellen muss. Sie können diese Konfiguration ignorieren, wenn Sie in der Konfiguration den standardmäßigen On-Demand-Kapazitätsmodus verwenden. billingMode | 10 |
| initialPositionInStreamExtended | LeaseManagementConfig | Die ursprüngliche Position im Stream, an der die Anwendung starten soll. Dieser Wert wird nur im Rahmen der Lease-Erstellung verwendet. | InitialPositionInStream.TRIM\$1HORIZON |
| reBalanceThresholdPercentage | LeaseManagementConfig | Ein Prozentwert, der bestimmt, wann der Load-Balancing-Algorithmus die Neuzuweisung von Shards unter Workern in Betracht ziehen sollte. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | 10 |
| dampeningPercentage | LeaseManagementConfig | Ein Prozentwert, der verwendet wird, um die Menge an Last zu dämpfen, die bei einem einzigen Ausgleichsvorgang vom überlasteten Arbeiter abtransportiert wird. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | 60 |
| allowThroughputOvershoot | LeaseManagementConfig | Ermittelt, ob dem überlasteten Worker weiterhin zusätzliche Leasingverträge abgenommen werden müssen, auch wenn dadurch der gesamte Leasing-Durchsatz den gewünschten Durchsatz übersteigt. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | TRUE |
| disableWorkerMetrics | LeaseManagementConfig | Legt fest, ob KCL bei der Neuzuweisung von Leasingverträgen und beim Lastenausgleich Ressourcenmetriken von Workern (z. B. CPU-Auslastung) ignorieren soll. Setzen Sie diesen Wert auf TRUE, wenn Sie verhindern möchten, dass KCL einen Lastenausgleich auf der Grundlage der CPU-Auslastung durchführt. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | FALSE |
| maxThroughputPerHostKBps | LeaseManagementConfig | Höhe des maximalen Durchsatzes, der einem Mitarbeiter während der Leasingzuweisung zugewiesen werden soll. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | Unbegrenzt |
| isGracefulLeaseHandoffEnabled | LeaseManagementConfig | Steuert das Verhalten bei der Übergabe von Leasingverträgen zwischen Mitarbeitern. Wenn dieser Wert auf „true“ gesetzt ist, versucht KCL, Leasingverträge ordnungsgemäß zu übertragen, indem dem Shard RecordProcessor genügend Zeit eingeräumt wird, um die Verarbeitung abzuschließen, bevor der Leasing an einen anderen Worker übergeben wird. Dies kann dazu beitragen, die Datenintegrität und reibungslose Übergänge zu gewährleisten, kann jedoch die Übergabezeit verlängern. Wenn der Wert auf „Falsch“ gesetzt ist, wird der Leasingvertrag sofort übergeben, ohne darauf RecordProcessor zu warten, dass er ordnungsgemäß beendet wird. Dies kann zu schnelleren Übergaben führen, es besteht jedoch die Gefahr einer unvollständigen Bearbeitung. Hinweis: Checkpointing muss innerhalb der shutdownRequested () -Methode von implementiert werden, um von der Funktion „Graceful Lease Handoff“ RecordProcessor zu profitieren. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | TRUE |
| gracefulLeaseHandoffTimeoutMillis | LeaseManagementConfig | Gibt die Mindestzeit (in Millisekunden) an, um zu warten, bis die aktuellen Shards ordnungsgemäß heruntergefahren wurden, bevor das Leasing gewaltsam RecordProcessor an den nächsten Besitzer übertragen wird. Wenn Ihre ProcessRecords-Methode normalerweise länger als der Standardwert ausgeführt wird, sollten Sie erwägen, diese Einstellung zu erhöhen. Dadurch wird sichergestellt, dass genügend Zeit zur Verfügung RecordProcessor steht, um die Verarbeitung abzuschließen, bevor die Leasingübertragung erfolgt. Dies ist eine neue Konfiguration, die in KCL 3.x eingeführt wurde. | 30.000 (30 Sekunden) |
| maxRecords | PollingConfig | Ermöglicht das Einstellen der maximalen Anzahl an Datensätzen, die Kinesis zurückgibt. | 10.000 |
| retryGetRecordsInSeconds | PollingConfig | Konfiguriert die Verzögerung zwischen GetRecords Fehlversuchen. | Keine |
| maxGetRecordsThreadPool | PollingConfig | Die Thread-Pool-Größe, die für GetRecords verwendet wird. | Keine |
| idleTimeBetweenReadsInMillis | PollingConfig | Legt fest, wie lange KCL zwischen GetRecords Aufrufen wartet, um die Daten aus Datenströmen abzufragen. Die Einheit ist Millisekunden. | 1.500 |
| callProcessRecordsEvenForEmptyRecordList | ProcessorConfig | Wenn diese Option aktiviert ist, wird der Datensatzprozessor aufgerufen, auch wenn Kinesis keine Datensätze bereitgestellt hat. | FALSE |
| parentShardPollIntervalMillis | CoordinatorConfig | Gibt an, wie oft ein Datensatzprozessor abfragen soll, ob der übergeordnete Shard abgeschlossen wurde. Die Einheit ist Millisekunden. | 10.000 (10 Sekunden) |
| skipShardSyncAtWorkerInitializationIfLeaseExist | CoordinatorConfig | Synchronisieren der Shard-Daten deaktivieren, wenn die Lease-Tabelle Leases enthält. | FALSE |
| shardPrioritization | CoordinatorConfig | Welche Shard-Priorisierung verwendet werden soll. | NoOpShardPrioritization |
| ClientVersionConfig | CoordinatorConfig | Legt fest, in welchem KCL-Versionskompatibilitätsmodus die Anwendung ausgeführt wird. Diese Konfiguration ist nur für die Migration von früheren KCL-Versionen vorgesehen. Bei der Migration auf 3.x müssen Sie diese Konfiguration auf einstellen. `CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X` Sie können diese Konfiguration entfernen, wenn Sie die Migration abgeschlossen haben. | CLIENT\$1VERSION\$1CONFIG\$13X |
| taskBackoffTimeMillis | LifecycleConfig | Die Wartezeit für die Wiederholung fehlgeschlagener KCL-Aufgaben. Die Einheit ist Millisekunden. | 500 (0,5 Sekunden) |
| logWarningForTaskAfterMillis | LifecycleConfig | Wartezeit, bevor eine Warnung protokolliert wird, wenn eine Aufgabe nicht abgeschlossen wurde. | Keine |
| listShardsBackoffTimeInMillis | RetrievalConfig | Die Anzahl der zwischen Aufrufen von ListShards abzuwartenden Millisekunden, wenn es zu Fehlern kommt. Die Einheit ist Millisekunden. | 1.500 (1,5 Sekunden) |
| maxListShardsRetryAttempts | RetrievalConfig | Die maximale Anzahl Wiederholungsversuche durch ListShards, bevor abgebrochen wird. | 50 |
| metricsBufferTimeMillis | MetricsConfig | Gibt die maximale Dauer (in Millisekunden) an, für die Metriken zwischengespeichert werden sollen, bevor sie veröffentlicht werden. CloudWatch | 10.000 (10 Sekunden) |
| metricsMaxQueueSize | MetricsConfig | Gibt die maximale Anzahl von Metriken an, die vor der Veröffentlichung zwischengespeichert werden sollen CloudWatch. | 10.000 |
| metricsLevel | MetricsConfig | Gibt die Granularitätsstufe der CloudWatch Metriken an, die aktiviert und veröffentlicht werden sollen. Mögliche Werte: NONE, SUMMARY, DETAILLIERT. | MetricsLevel. DETAILLIERT |
| metricsEnabledDimensions | MetricsConfig | Steuert die zulässigen Dimensionen für CloudWatch Metriken. | Alle Dimensionen |
**Nicht mehr verfügbare Konfigurationen in KCL 3.x**
Die folgenden Konfigurationseigenschaften sind in KCL 3.x nicht mehr verfügbar:
**Die Tabelle zeigt die nicht mehr verfügbaren Konfigurationseigenschaften für KCL 3.x**
| Konfigurationseigenschaft | Konfigurationsklasse | Description |
| --- | --- | --- |
| maxLeasesToStealAtOneTime | LeaseManagementConfig | Die maximale Anzahl der Leases, die eine Anwendung zu einem gegebenen Zeitpunkt zu stehlen versuchen sollte. KCL 3.x ignoriert diese Konfiguration und weist Leasingverträge auf der Grundlage der Ressourcennutzung der Mitarbeiter neu zu. |
| enablePriorityLeaseAssignment | LeaseManagementConfig | Steuert, ob Mitarbeiter der Annahme sehr abgelaufener Leasingverträge (Leasingverträge, die nicht um das Dreifache der Failover-Zeit verlängert werden) und neuen Shard-Leases Priorität einräumen sollen, unabhängig von der Anzahl der angestrebten Leasingverträge, aber unter Einhaltung der maximalen Leasing-Limits. KCL 3.x ignoriert diese Konfiguration und verteilt abgelaufene Leasingverträge immer auf die Mitarbeiter. |
**Wichtig**
Während der Migration von früheren KCL-Versionen zu KCL 3.x müssen Sie weiterhin über die Eigenschaften der nicht mehr verfügbaren Konfiguration verfügen. Während der Migration startet der KCL-Worker zunächst mit dem KCL 2.x-kompatiblen Modus und wechselt in den KCL 3.x-Funktionsmodus, wenn er feststellt, dass alle KCL-Worker der Anwendung bereit sind, KCL 3.x auszuführen. Diese eingestellten Konfigurationen werden benötigt, solange KCL-Worker den KCL 2.x-kompatiblen Modus ausführen.
# Lebenszyklus-Richtlinie für KCL-Versionen
In diesem Thema wird die Versionslebenszyklusrichtlinie für die Amazon Kinesis Client Library (KCL) beschrieben. AWS stellt regelmäßig neue Versionen für KCL-Versionen bereit, um neue Funktionen und Verbesserungen, Bugfixes, Sicherheitspatches und Abhängigkeitsupdates zu unterstützen. Wir empfehlen Ihnen, up-to-date bei den KCL-Versionen zu bleiben, um über die neuesten Funktionen, Sicherheitsupdates und die zugrunde liegenden Abhängigkeiten auf dem Laufenden zu bleiben. Wir empfehlen **nicht,** weiterhin eine KCL-Version zu verwenden, die nicht unterstützt wird.
Der Lebenszyklus der wichtigsten KCL-Versionen besteht aus den folgenden drei Phasen:
+ **Allgemeine Verfügbarkeit (GA)** — Während dieser Phase wird die Hauptversion vollständig unterstützt. AWS bietet regelmäßige Versionen von Neben- und Patch-Versionen, die Unterstützung für neue Funktionen oder API-Updates für Kinesis Data Streams sowie Fehler- und Sicherheitskorrekturen beinhalten.
+ **Wartungsmodus** — AWS Beschränkt die Veröffentlichung von Patch-Versionen auf kritische Bugfixes und Sicherheitsprobleme. Die Hauptversion erhält keine Updates für neue Funktionen oder APIs für Kinesis Data Streams.
+ **E nd-of-support** — Die Hauptversion wird keine Updates oder Releases mehr erhalten. Zuvor veröffentlichte Versionen werden weiterhin über öffentliche Paketmanager verfügbar sein und der Code bleibt aktiviert GitHub. Die Verwendung einer Version, die erreicht wurde, end-of-support erfolgt nach eigenem Ermessen des Benutzers. Wir empfehlen Ihnen, auf die neueste Hauptversion zu aktualisieren.
| Hauptversion | Aktuelle Phase | Datum der Veröffentlichung | Datum des Wartungsmodus | End-of-support Datum |
| --- | --- | --- | --- | --- |
| KCL 1.x | Wartungsmodus | 19.12.2013 | 2025-04-17 | 2026-01-30 |
| KCL 2.x | Allgemeine Verfügbarkeit | 02.08.2018 | -- | -- |
| KCL 3.x | Allgemeine Verfügbarkeit | 2024-11-06 | -- | -- |
# Migrieren Sie von früheren KCL-Versionen
In diesem Thema wird erklärt, wie Sie von früheren Versionen der Kinesis Client Library (KCL) migrieren.
## Was ist neu in KCL 3.0?
Kinesis Client Library (KCL) 3.0 bietet mehrere wichtige Verbesserungen im Vergleich zu früheren Versionen:
+ Es senkt die Rechenkosten für Privatanwenderanwendungen, indem die Arbeit automatisch von überlasteten Mitarbeitern auf nicht ausgelastete Mitarbeiter in der Anwenderflotte für Privatanwender verteilt wird. Dieser neue Load-Balancing-Algorithmus sorgt für eine gleichmäßige Verteilung der CPU-Auslastung auf die Mitarbeiter und macht eine Überbelegung der Mitarbeiter überflüssig.
+ Es reduziert die mit KCL verbundenen DynamoDB-Kosten, indem Lesevorgänge in der Leasetabelle optimiert werden.
+ Es minimiert die erneute Verarbeitung von Daten, wenn Leasingverträge einem anderen Mitarbeiter zugewiesen werden, indem der aktuelle Mitarbeiter die Überprüfung der von ihm verarbeiteten Datensätze durchführen kann.
+ Es verwendet AWS SDK for Java 2.x verbesserte Leistungs- und Sicherheitsfunktionen, wodurch die Abhängigkeit von 1.x vollständig beseitigt wird. AWS SDK für Java
Weitere Informationen finden Sie in den [Versionshinweisen zu KCL 3.0](https://github.com/awslabs/amazon-kinesis-client/blob/master/CHANGELOG.md).
**Topics**
+ [
## Was ist neu in KCL 3.0?
](#kcl-migration-new-3-0)
+ [
# Migrieren Sie von KCL 2.x zu KCL 3.x
](kcl-migration-from-2-3.md)
+ [
# Rollback zu einer früheren KCL-Version
](kcl-migration-rollback.md)
+ [
# Rollforward zu KCL 3.x nach einem Rollback
](kcl-migration-rollforward.md)
+ [
# Bewährte Methoden für die Leasetabelle mit dem Modus „Bereitgestellte Kapazität“
](kcl-migration-lease-table.md)
+ [
# Migrieren von KCL 1.x zu KCL 3.x
](kcl-migration-1-3.md)
# Migrieren Sie von KCL 2.x zu KCL 3.x
Dieses Thema enthält step-by-step Anweisungen zur Migration Ihres Verbrauchers von KCL 2.x zu KCL 3.x. KCL 3.x unterstützt die direkte Migration von KCL 2.x-Verbrauchern. Sie können weiterhin die Daten aus Ihrem Kinesis-Datenstrom nutzen und gleichzeitig Ihre Mitarbeiter fortlaufend migrieren.
**Wichtig**
KCL 3.x verwendet dieselben Schnittstellen und Methoden wie KCL 2.x. Daher müssen Sie Ihren Datensatzverarbeitungscode während der Migration nicht aktualisieren. Sie müssen jedoch die richtige Konfiguration festlegen und die erforderlichen Schritte für die Migration überprüfen. Wir empfehlen Ihnen dringend, die folgenden Migrationsschritte zu befolgen, um eine reibungslose Migration zu gewährleisten.
## Schritt 1: Voraussetzungen
Bevor Sie mit der Verwendung von KCL 3.x beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Java Development Kit (JDK) 8 oder höher
+ AWS SDK für Java 2.x
+ Maven oder Gradle für das Abhängigkeitsmanagement
**Wichtig**
Verwenden Sie nicht die AWS SDK für Java Versionen 2.27.19 bis 2.27.23 mit KCL 3.x. Diese Versionen enthalten ein Problem, das einen Ausnahmefehler im Zusammenhang mit der DynamoDB-Nutzung von KCL verursacht. Wir empfehlen, die AWS SDK für Java Version 2.28.0 oder höher zu verwenden, um dieses Problem zu vermeiden.
## Schritt 2: Abhängigkeiten hinzufügen
Wenn Sie Maven verwenden, fügen Sie Ihrer `pom.xml` Datei die folgende Abhängigkeit hinzu. Stellen Sie sicher, dass Sie 3.x.x durch die neueste KCL-Version ersetzt haben.
```
software.amazon.kinesis
amazon-kinesis-client
3.x.x
```
Wenn Sie Gradle verwenden, fügen Sie Ihrer Datei Folgendes hinzu. `build.gradle` Stellen Sie sicher, dass Sie 3.x.x durch die neueste KCL-Version ersetzt haben.
```
implementation 'software.amazon.kinesis:amazon-kinesis-client:3.x.x'
```
[Sie können im Maven Central Repository nach der neuesten Version der KCL suchen.](https://search.maven.org/artifact/software.amazon.kinesis/amazon-kinesis-client)
## Schritt 3: Richten Sie die migrationsbezogene Konfiguration ein
Um von KCL 2.x zu KCL 3.x zu migrieren, müssen Sie den folgenden Konfigurationsparameter festlegen:
+ CoordinatorConfig. clientVersionConfig: Diese Konfiguration bestimmt, in welchem KCL-Versionskompatibilitätsmodus die Anwendung ausgeführt wird. Bei der Migration von KCL 2.x auf 3.x müssen Sie diese Konfiguration auf einstellen. `CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X` Um diese Konfiguration festzulegen, fügen Sie bei der Erstellung Ihres Scheduler-Objekts die folgende Zeile hinzu:
```
configsBuilder.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_WITH_2X)
```
Im Folgenden finden Sie ein Beispiel dafür, wie Sie den `CoordinatorConfig.clientVersionConfig` für die Migration von KCL 2.x auf 3.x festlegen. Sie können andere Konfigurationen nach Bedarf an Ihre spezifischen Anforderungen anpassen:
```
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_WITH_2X),
configsBuilder.leaseManagementConfig(),
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig()
);
```
Es ist wichtig, dass alle Worker in Ihrer Consumer-Anwendung zu einem bestimmten Zeitpunkt denselben Load-Balancing-Algorithmus verwenden, da KCL 2.x und 3.x unterschiedliche Load-Balancing-Algorithmen verwenden. Das Ausführen von Workern mit unterschiedlichen Load-Balancing-Algorithmen kann zu einer suboptimalen Lastverteilung führen, da die beiden Algorithmen unabhängig voneinander arbeiten.
Diese KCL 2.x-Kompatibilitätseinstellung ermöglicht es Ihrer KCL 3.x-Anwendung, in einem mit KCL 2.x kompatiblen Modus zu laufen und den Load-Balancing-Algorithmus für KCL 2.x zu verwenden, bis alle Worker in Ihrer Consumer-Anwendung auf KCL 3.x aktualisiert wurden. Wenn die Migration abgeschlossen ist, wechselt KCL automatisch in den vollen KCL 3.x-Funktionsmodus und beginnt mit der Verwendung eines neuen KCL 3.x-Lastenausgleichsalgorhythmus für alle laufenden Worker.
**Wichtig**
Wenn Sie Konfigurationen nicht verwenden, `ConfigsBuilder` sondern ein `LeaseManagementConfig` Objekt erstellen, müssen Sie einen weiteren Parameter hinzufügen, der `applicationName` in KCL-Version 3.x oder höher aufgerufen wird. Einzelheiten finden Sie unter [Kompilierungsfehler mit dem LeaseManagementConfig Konstruktor](https://docs.aws.amazon.com/streams/latest/dev/troubleshooting-consumers.html#compiliation-error-leasemanagementconfig). Wir empfehlen die Verwendung`ConfigsBuilder`, um KCL-Konfigurationen festzulegen. `ConfigsBuilder`bietet eine flexiblere und wartungsfreundlichere Methode zur Konfiguration Ihrer KCL-Anwendung.
## Schritt 4: Folgen Sie den bewährten Methoden für die Implementierung der Methode shutdownRequested ()
Mit KCL 3.x wird eine Funktion namens *Graceful Lease Handoff* eingeführt, um die erneute Verarbeitung von Daten zu minimieren, wenn ein Mietvertrag im Rahmen der Neuzuweisung eines Leasingvertrags an einen anderen Mitarbeiter übergeben wird. Dies wird erreicht, indem die zuletzt verarbeitete Sequenznummer in der Leasetabelle vor der Leasing-Übergabe überprüft wird. Um sicherzustellen, dass die ordnungsgemäße Lease-Übergabe ordnungsgemäß funktioniert, müssen Sie sicherstellen, dass Sie das `checkpointer` Objekt innerhalb der `shutdownRequested` Methode in Ihrer Klasse aufrufen. `RecordProcessor` Wenn Sie das `checkpointer` Objekt nicht innerhalb der `shutdownRequested` Methode aufrufen, können Sie es wie im folgenden Beispiel dargestellt implementieren.
**Wichtig**
Das folgende Implementierungsbeispiel ist eine Mindestanforderung für die reibungslose Leasing-Übergabe. Sie können es bei Bedarf um zusätzliche Logik im Zusammenhang mit dem Checkpointing erweitern. Wenn Sie eine asynchrone Verarbeitung durchführen, stellen Sie sicher, dass alle an den Downstream übermittelten Datensätze verarbeitet wurden, bevor Sie Checkpointing aufrufen.
Eine reibungslose Leasing-Übergabe verringert zwar die Wahrscheinlichkeit einer erneuten Verarbeitung von Daten bei Leasing-Übertragungen erheblich, schließt diese Möglichkeit jedoch nicht vollständig aus. Um Datenintegrität und Konsistenz zu wahren, sollten Sie Ihre nachgelagerten Verbraucheranwendungen so gestalten, dass sie idempotent sind. Das bedeutet, dass sie in der Lage sein sollten, die Verarbeitung potenzieller doppelter Datensätze ohne nachteilige Auswirkungen auf das Gesamtsystem zu bewältigen.
```
/**
* Invoked when either Scheduler has been requested to gracefully shutdown
* or lease ownership is being transferred gracefully so the current owner
* gets one last chance to checkpoint.
*
* Checkpoints and logs the data a final time.
*
* @param shutdownRequestedInput Provides access to a checkpointer, allowing a record processor to checkpoint
* before the shutdown is completed.
*/
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
try {
// Ensure that all delivered records are processed
// and has been successfully flushed to the downstream before calling
// checkpoint
// If you are performing any asynchronous processing or flushing to
// downstream, you must wait for its completion before invoking
// the below checkpoint method.
log.info("Scheduler is shutting down, checkpointing.");
shutdownRequestedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at requested shutdown. Giving up.", e);
}
}
```
## Schritt 5: Überprüfen Sie die KCL 3.x-Voraussetzungen für die Erfassung von Arbeitskräftekennzahlen
KCL 3.x sammelt Metriken zur CPU-Auslastung, wie z. B. die CPU-Auslastung von Mitarbeitern, um die Auslastung gleichmäßig auf die Mitarbeiter verteilen zu können. Anwendungsarbeiter für Privatanwender können auf Amazon EC2, Amazon ECS, Amazon EKS oder AWS Fargate ausgeführt werden. KCL 3.x kann Metriken zur CPU-Auslastung von Workern nur erfassen, wenn die folgenden Voraussetzungen erfüllt sind:
**Amazon Elastic Compute Cloud(Amazon EC2)**
+ Ihr Betriebssystem muss Linux OS sein.
+ Sie müssen es [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)in Ihrer EC2-Instance aktivieren.
**Amazon Elastic Container Service (Amazon ECS) auf Amazon EC2**
+ Ihr Betriebssystem muss Linux OS sein.
+ Sie müssen den [ECS-Endpunkt für Task-Metadaten, Version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ec2-metadata.html), aktivieren.
+ Ihre Amazon ECS-Container-Agent-Version muss 1.39.0 oder höher sein.
**Amazon ECS auf AWS Fargate**
+ Sie müssen den [Fargate-Task-Metadaten-Endpunkt Version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html) aktivieren. Wenn Sie die Fargate-Plattformversion 1.4.0 oder höher verwenden, ist dies standardmäßig aktiviert.
+ Fargate-Plattformversion 1.4.0 oder höher.
**Amazon Elastic Kubernetes Service (Amazon EKS) auf Amazon EC2**
+ Ihr Betriebssystem muss Linux OS sein.
**Amazon EKS auf AWS Fargate**
+ Fargate-Plattform 1.3.0 oder höher.
**Wichtig**
Wenn KCL 3.x keine CPU-Auslastungsmetriken von Workern sammeln kann, weil die Voraussetzungen nicht erfüllt sind, verteilt es die Last auf das Durchsatzniveau pro Lease. Dieser Ausweichmechanismus stellt sicher, dass alle Mitarbeiter einen ähnlichen Gesamtdurchsatz aus den Leasingverträgen erhalten, die jedem Mitarbeiter zugewiesen wurden. Weitere Informationen finden Sie unter [Wie KCL Mitarbeitern Leasingverträge zuweist und die Auslastung verteilt](kcl-dynamoDB.md#kcl-assign-leases).
## Schritt 6: Aktualisieren Sie die IAM-Berechtigungen für KCL 3.x
Sie müssen der IAM-Rolle oder -Richtlinie, die mit Ihrer KCL 3.x-Verbraucheranwendung verknüpft ist, die folgenden Berechtigungen hinzufügen. Dies beinhaltet die Aktualisierung der vorhandenen IAM-Richtlinie, die von der KCL-Anwendung verwendet wird. Weitere Informationen finden Sie unter [Für KCL-Anwendungen für Privatanwender sind IAM-Berechtigungen erforderlich](kcl-iam-permissions.md).
**Wichtig**
In Ihren vorhandenen KCL-Anwendungen wurden die folgenden IAM-Aktionen und Ressourcen möglicherweise nicht zur IAM-Richtlinie hinzugefügt, da sie in KCL 2.x nicht benötigt wurden. Stellen Sie sicher, dass Sie sie hinzugefügt haben, bevor Sie Ihre KCL 3.x-Anwendung ausführen:
Aktionen: `UpdateTable`
Ressourcen (ARNs): `arn:aws:dynamodb:region:account:table/KCLApplicationName`
Aktionen: `Query`
Ressourcen (ARNs): `arn:aws:dynamodb:region:account:table/KCLApplicationName/index/*`
Aktionen:`CreateTable`, `DescribeTable``Scan`,`GetItem`,`PutItem`,`UpdateItem`, `DeleteItem`
Ressourcen (ARNs):`arn:aws:dynamodb:region:account:table/KCLApplicationName-WorkerMetricStats`, `arn:aws:dynamodb:region:account:table/KCLApplicationName-CoordinatorState`
Ersetzen Sie „Region“, „Konto“ und „KCLApplicationName“ in der ARNs durch Ihre eigene AWS-Region AWS-Konto Nummer bzw. den Namen der KCL-Anwendung. Wenn Sie Konfigurationen verwenden, um die Namen der von KCL erstellten Metadatentabellen anzupassen, verwenden Sie diese angegebenen Tabellennamen anstelle des KCL-Anwendungsnamens.
## Schritt 7: Stellen Sie Ihren Mitarbeitern KCL 3.x-Code bereit
Nachdem Sie die für die Migration erforderliche Konfiguration festgelegt und alle vorherigen Migrationschecklisten abgeschlossen haben, können Sie Ihren Code erstellen und für Ihre Mitarbeiter bereitstellen.
**Anmerkung**
Wenn Sie einen Kompilierungsfehler mit dem `LeaseManagementConfig` Konstruktor sehen, finden Sie Informationen zur Problembehandlung unter [Kompilierungsfehler mit dem LeaseManagementConfig Konstruktor](https://docs.aws.amazon.com/streams/latest/dev/troubleshooting-consumers.html#compilation-error-leasemanagementconfig).
## Schritt 8: Schließen Sie die Migration ab
Während der Bereitstellung von KCL 3.x-Code verwendet KCL weiterhin den Lease-Zuweisungsalgorithmus aus KCL 2.x. Wenn Sie erfolgreich KCL 3.x-Code für alle Ihre Mitarbeiter bereitgestellt haben, erkennt KCL dies automatisch und wechselt auf den neuen Algorithmus für die Leasingzuweisung, der auf der Ressourcennutzung der Mitarbeiter basiert. Weitere Informationen zum neuen Algorithmus für die Leasingzuweisung finden Sie unter. [Wie KCL Mitarbeitern Leasingverträge zuweist und die Auslastung verteilt](kcl-dynamoDB.md#kcl-assign-leases)
Während der Bereitstellung können Sie den Migrationsprozess anhand der folgenden Metriken überwachen, die an gesendet CloudWatch werden. Sie können die Metriken während des `Migration` Vorgangs überwachen. Bei allen Metriken handelt es sich um per-KCL-application Metriken, die auf `SUMMARY` Metrik-Ebene festgelegt sind. Wenn die `Sum` Statistik der `CurrentState:3xWorker` Metrik mit der Gesamtzahl der Mitarbeiter in Ihrer KCL-Anwendung übereinstimmt, bedeutet dies, dass die Migration zu KCL 3.x erfolgreich abgeschlossen wurde.
**Wichtig**
Es dauert mindestens 10 Minuten, bis KCL auf den neuen Algorithmus für die Zuweisung von Mietverträgen umgestellt hat, nachdem alle Mitarbeiter bereit sind, ihn auszuführen.
**CloudWatch Metriken für den KCL-Migrationsprozess**
| Kennzahlen | Description |
| --- | --- |
| CurrentState:3xWorker | Die Anzahl der KCL-Worker, die erfolgreich auf KCL 3.x migriert wurden und den neuen Leasing-Zuweisungsalgorithmus ausführen. Wenn die `Sum` Anzahl dieser Metrik mit der Gesamtzahl Ihrer Mitarbeiter übereinstimmt, bedeutet dies, dass die Migration zu KCL 3.x erfolgreich abgeschlossen wurde. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/kcl-migration-from-2-3.html) |
| CurrentState:2xCompatibleWorker | Die Anzahl der KCL-Worker, die während des Migrationsprozesses im KCL 2.x-kompatiblen Modus ausgeführt werden. Ein Wert ungleich Null für diese Metrik bedeutet, dass die Migration noch im Gange ist. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/kcl-migration-from-2-3.html) |
| Fault | Die Anzahl der Ausnahmen, die während des Migrationsprozesses aufgetreten sind. Bei den meisten dieser Ausnahmen handelt es sich um vorübergehende Fehler, und KCL 3.x versucht automatisch erneut, die Migration abzuschließen. Wenn Sie einen dauerhaften `Fault` Metrikwert beobachten, überprüfen Sie Ihre Protokolle aus dem Migrationszeitraum zur weiteren Fehlerbehebung. Wenn das Problem weiterhin besteht, wenden Sie sich an Support. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/kcl-migration-from-2-3.html) |
| GsiStatusReady | Der Status der Erstellung des globalen Sekundärindex (GSI) in der Leasingtabelle. Diese Metrik gibt an, ob der GSI in der Leasetabelle erstellt wurde. Dies ist eine Voraussetzung für die Ausführung von KCL 3.x. Der Wert ist 0 oder 1, wobei 1 für eine erfolgreiche Erstellung steht. Während eines Rollback-Status wird diese Metrik nicht ausgegeben. Nachdem Sie erneut einen Rollforward durchgeführt haben, können Sie die Überwachung dieser Metrik fortsetzen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/kcl-migration-from-2-3.html) |
| workerMetricsReady | Status der Arbeitnehmer misst die Emissionen aller Arbeitnehmer. Die Metriken geben an, ob alle Mitarbeiter Kennzahlen wie die CPU-Auslastung ausgeben. Der Wert ist 0 oder 1, wobei 1 bedeutet, dass alle Mitarbeiter erfolgreich Kennzahlen ausgeben und für den neuen Algorithmus zur Leasingzuweisung bereit sind. Während eines Rollback-Status wird diese Metrik nicht ausgegeben. Nachdem Sie erneut einen Rollforward durchgeführt haben, können Sie die Überwachung dieser Metrik fortsetzen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/kcl-migration-from-2-3.html) |
KCL bietet während der Migration die Möglichkeit, auf den 2.x-kompatiblen Modus zurückzugreifen. Nach erfolgreicher Migration auf KCL 3.x empfehlen wir Ihnen, die `CoordinatorConfig.clientVersionConfig` Einstellung „`CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X`Wenn ein Rollback nicht mehr erforderlich ist“ zu entfernen. Durch das Entfernen dieser Konfiguration wird die Ausgabe migrationsbezogener Metriken aus der KCL-Anwendung gestoppt.
**Anmerkung**
Wir empfehlen Ihnen, die Leistung und Stabilität Ihrer Anwendung für einen bestimmten Zeitraum während der Migration und nach Abschluss der Migration zu überwachen. [Wenn Sie Probleme feststellen, können Sie Workers mithilfe des KCL-Migrationstools auf die Verwendung von KCL 2.x-kompatiblen Funktionen zurücksetzen.](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py)
# Rollback zu einer früheren KCL-Version
In diesem Thema werden die Schritte erläutert, mit denen Sie Ihren Kunden auf die vorherige Version zurücksetzen können. Wenn Sie ein Rollback durchführen müssen, erfolgt dies in zwei Schritten:
1. Führen Sie das [KCL Migration Tool](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py) aus.
1. Stellen Sie den Code der vorherigen KCL-Version erneut bereit (optional).
## Schritt 1: Ausführen des KCL Migration Tools
Wenn Sie zur vorherigen KCL-Version zurückkehren möchten, müssen Sie das KCL Migration Tool ausführen. Das KCL-Migrationstool erfüllt zwei wichtige Aufgaben:
+ Es entfernt die Metadatentabelle für Worker-Metriken und den globalen sekundären Index aus der Leasetabelle in DynamoDB. Diese beiden Artefakte wurden von KCL 3.x erstellt, werden aber nicht benötigt, wenn Sie zur vorherigen Version zurückkehren.
+ Dadurch werden alle Worker in einem mit KCL 2.x kompatiblen Modus ausgeführt und beginnen, den Load-Balancing-Algorithmus zu verwenden, der in früheren KCL-Versionen verwendet wurde. Eventuelle Probleme mit dem neuen Load-Balancing-Algorithmus in KCL 3.x werden dadurch sofort behoben.
**Wichtig**
Die Koordinatorstatustabelle in DynamoDB muss vorhanden sein und darf während des Migrations-, Rollback- und Rollforward-Prozesses nicht gelöscht werden.
**Anmerkung**
Es ist wichtig, dass alle Worker in Ihrer Verbraucheranwendung zu einem bestimmten Zeitpunkt denselben Load-Balancing-Algorithmus verwenden. Das KCL-Migrationstool stellt sicher, dass alle Worker in Ihrer KCL 3.x-Consumer-Anwendung in den KCL 2.x-kompatiblen Modus wechseln, sodass alle Mitarbeiter während der Rückzahlung auf Ihre vorherige KCL-Version denselben Load-Balancing-Algorithmus verwenden.
[Sie können das [KCL-Migrationstool im Skriptverzeichnis des KCL-Repositorys](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py) herunterladen. GitHub](https://github.com/awslabs/amazon-kinesis-client/tree/master) Das Skript kann von jedem Ihrer Worker oder jedem Host ausgeführt werden, der über die erforderlichen Berechtigungen verfügt, um in die Tabelle mit den Koordinatorstatus zu schreiben, die Tabelle mit den Worker-Metriken zu löschen und die Leasing-Tabelle zu aktualisieren. Die erforderlichen IAM-Berechtigungen [Für KCL-Anwendungen für Privatanwender sind IAM-Berechtigungen erforderlich](kcl-iam-permissions.md) zur Ausführung des Skripts finden Sie unter. Sie dürfen das Skript nur einmal pro KCL-Anwendung ausführen. Sie können das KCL-Migrationstool mit dem folgenden Befehl ausführen:
```
python3 ./KclMigrationTool.py --region --mode rollback [--application_name ] [--lease_table_name ] [--coordinator_state_table_name ] [--worker_metrics_table_name ]
```
**Parameter**
+ --region: Ersetze es `` durch dein. AWS-Region
+ --application\$1name: Dieser Parameter ist erforderlich, wenn Sie Standardnamen für Ihre DynamoDB-Metadatentabellen (Leasetabelle, Koordinatorstatustabelle und Worker-Metriktabelle) verwenden. Wenn Sie benutzerdefinierte Namen für diese Tabellen festgelegt haben, können Sie diesen Parameter weglassen. Ersetzen Sie es durch Ihren `` tatsächlichen KCL-Anwendungsnamen. Das Tool verwendet diesen Namen, um die Standardtabellennamen abzuleiten, wenn keine benutzerdefinierten Namen angegeben werden.
+ --lease\$1table\$1name (optional): Dieser Parameter wird benötigt, wenn Sie in Ihrer KCL-Konfiguration einen benutzerdefinierten Namen für die Leasetabelle festgelegt haben. Wenn Sie den Standardtabellennamen verwenden, können Sie diesen Parameter weglassen. `leaseTableName`Ersetzen Sie ihn durch den benutzerdefinierten Tabellennamen, den Sie für Ihre Leasingtabelle angegeben haben.
+ --coordinator\$1state\$1table\$1name (optional): Dieser Parameter wird benötigt, wenn Sie in Ihrer KCL-Konfiguration einen benutzerdefinierten Namen für die Koordinatorstatentabelle festgelegt haben. Wenn Sie den Standardtabellennamen verwenden, können Sie diesen Parameter weglassen. Ersetzen Sie ihn durch den benutzerdefinierten `` Tabellennamen, den Sie für Ihre Koordinatorstatustabelle angegeben haben.
+ --worker\$1metrics\$1table\$1name (optional): Dieser Parameter wird benötigt, wenn Sie in Ihrer KCL-Konfiguration einen benutzerdefinierten Namen für die Tabelle mit den Worker-Metriken festgelegt haben. Wenn Sie den Standardtabellennamen verwenden, können Sie diesen Parameter weglassen. Ersetzen Sie ihn durch den benutzerdefinierten `` Tabellennamen, den Sie für Ihre Worker-Metriktabelle angegeben haben.
## Schritt 2: Stellen Sie den Code erneut mit der vorherigen KCL-Version bereit (optional)
Nachdem das KCL Migration Tool den Rollback ausgeführt hat, wird eine der folgenden Meldungen angezeigt:
+ **Meldung 1:** „Rollback abgeschlossen. Ihre KCL-Anwendung lief im KCL 2.x-kompatiblen Modus. Wenn Sie keine Abmilderung der Regression sehen, kehren Sie bitte zu Ihren vorherigen Anwendungsbinärdateien zurück, indem Sie den Code mit Ihrer vorherigen KCL-Version bereitstellen.“
+ **Erforderliche Maßnahme:** Das bedeutet, dass Ihre Mitarbeiter im KCL 2.x-kompatiblen Modus gearbeitet haben. Wenn das Problem weiterhin besteht, stellen Sie den Code mit der vorherigen KCL-Version erneut für Ihre Mitarbeiter bereit.
+ **Meldung 2:** „Rollback abgeschlossen. In Ihrer KCL-Anwendung wurde der KCL 3.x-Funktionsmodus ausgeführt. Ein Rollback zu den vorherigen Anwendungsbinärdateien ist nicht erforderlich, es sei denn, Sie sehen innerhalb von 5 Minuten keine Lösung für das Problem. Wenn Sie immer noch ein Problem haben, führen Sie bitte ein Rollback zu Ihren vorherigen Anwendungsbinärdateien durch, indem Sie den Code mit Ihrer vorherigen KCL-Version bereitstellen.“
+ **Erforderliche Maßnahme:** Das bedeutet, dass Ihre Worker im KCL 3.x-Modus liefen und das KCL-Migrationstool alle Worker in den KCL 2.x-kompatiblen Modus umgestellt hat. Wenn das Problem behoben ist, müssen Sie den Code nicht erneut mit der vorherigen KCL-Version bereitstellen. Wenn das Problem weiterhin besteht, stellen Sie den Code mit der vorherigen KCL-Version erneut für Ihre Mitarbeiter bereit.
# Rollforward zu KCL 3.x nach einem Rollback
In diesem Thema werden die Schritte erläutert, mit denen Sie Ihren Kunden nach einem Rollback wieder auf KCL 3.x umstellen können. Wenn Sie ein Rollforward durchführen müssen, müssen Sie einen zweistufigen Prozess durchlaufen:
1. Führen Sie das [KCL Migration Tool](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py) aus.
1. Stellen Sie den Code mit KCL 3.x bereit.
## Schritt 1: Ausführen des KCL Migration Tools
Führen Sie das KCL Migration Tool aus. KCL-Migrationstool mit dem folgenden Befehl für den Rollforward auf KCL 3.x:
```
python3 ./KclMigrationTool.py --region --mode rollforward [--application_name ] [--coordinator_state_table_name ]
```
**Parameter**
+ --region: Ersetze es durch dein. `` AWS-Region
+ --application\$1name: Dieser Parameter ist erforderlich, wenn Sie Standardnamen für Ihre Koordinatorstatentabelle verwenden. Wenn Sie benutzerdefinierte Namen für diese Tabelle festgelegt haben, können Sie diesen Parameter weglassen. Ersetzen Sie ihn `` durch Ihren tatsächlichen KCL-Anwendungsnamen. Das Tool verwendet diesen Namen, um die Standardtabellennamen abzuleiten, wenn keine benutzerdefinierten Namen angegeben werden.
+ --coordinator\$1state\$1table\$1name (optional): Dieser Parameter wird benötigt, wenn Sie in Ihrer KCL-Konfiguration einen benutzerdefinierten Namen für die Koordinatorstatentabelle festgelegt haben. Wenn Sie den Standardtabellennamen verwenden, können Sie diesen Parameter weglassen. Ersetzen Sie ihn durch den benutzerdefinierten `` Tabellennamen, den Sie für Ihre Koordinatorstatustabelle angegeben haben.
Nachdem Sie das Migrationstool im Roll-Forward-Modus ausgeführt haben, erstellt KCL die folgenden DynamoDB-Ressourcen, die für KCL 3.x erforderlich sind:
+ einen globalen sekundären Index für die Leasetabelle
+ eine Tabelle mit Worker-Metriken
## Schritt 2: Bereitstellen des Codes mit KCL 3.x
Nachdem Sie den Rollforward mit dem KCL Migration Tool ausgeführt haben, stellen Sie Ihren Code mit KCL 3.x für Ihre Worker bereit. Folgen Sie [Schritt 8: Schließen Sie die Migration ab](kcl-migration-from-2-3.md#kcl-migration-from-2-3-finish) den Anweisungen, um Ihre Migration abzuschließen.
# Bewährte Methoden für die Leasetabelle mit dem Modus „Bereitgestellte Kapazität“
Wenn die Leasetabelle Ihrer KCL-Anwendung in den Modus für bereitgestellte Kapazität umgestellt wurde, erstellt KCL 3.x einen globalen sekundären Index in der Leasetabelle mit dem bereitgestellten Abrechnungsmodus und denselben Lesekapazitätseinheiten (RCU) und Schreibkapazitätseinheiten (WCU) wie in der Basis-Leasetabelle. Wenn der globale sekundäre Index erstellt wird, empfehlen wir, die tatsächliche Nutzung des globalen sekundären Index in der DynamoDB-Konsole zu überwachen und die Kapazitätseinheiten bei Bedarf anzupassen. Eine ausführlichere Anleitung zum Umschalten des Kapazitätsmodus von DynamoDB-Metadatentabellen, die von KCL erstellt wurden, finden Sie unter. [DynamoDB-Kapazitätsmodus für von KCL erstellte Metadatentabellen](kcl-dynamoDB.md#kcl-capacity-mode)
**Anmerkung**
Standardmäßig erstellt KCL im On-Demand-Kapazitätsmodus Metadatentabellen wie die Leasetabelle, die Tabelle mit den Worker-Metriken und den Koordinatorstatus-Tabellen sowie den globalen Sekundärindex für die Leasing-Tabelle. Wir empfehlen, den On-Demand-Kapazitätsmodus zu verwenden, um die Kapazität automatisch an Ihre Nutzungsänderungen anzupassen.
# Migrieren von KCL 1.x zu KCL 3.x
In diesem Thema werden die Anweisungen zur Migration Ihres Verbrauchers von KCL 1.x auf KCL 3.x erläutert. KCL 1.x verwendet im Vergleich zu KCL 2.x und KCL 3.x andere Klassen und Schnittstellen. Sie müssen zuerst die Klassen Record Processor, Record Processor Factory und Worker auf das KCL 2.x/3.x-kompatible Format migrieren und dann die Migrationsschritte für die Migration von KCL 2.x zu KCL 3.x befolgen. Sie können direkt von KCL 1.x auf KCL 3.x aktualisieren.
+ **Schritt 1: Migrieren Sie den Aufnahmeprozessor**
Folgen Sie dem Abschnitt [Den Datensatzprozessor migrieren](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-migration) [auf der Seite Verbraucher von KCL 1.x zu KCL 2.x](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-migration) migrieren.
+ **Schritt 2: Migrieren Sie den Record Processor ab Werk**
Folgen Sie auf [der Seite [Verbraucher von KCL 1.x auf KCL 2.x migrieren](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-migration) im Abschnitt Werkseinstellungen für den Record Processor](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-factory-migration) migrieren.
+ **Schritt 3: Migrieren Sie den Worker**
Folgen Sie dem Abschnitt [Den Worker](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#worker-migration) [migrieren auf der Seite Verbraucher von KCL 1.x zu KCL 2.x](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-migration) migrieren.
+ **Schritt 4: Migrieren Sie die KCL 1.x-Konfiguration**
Folgen Sie dem Abschnitt [Amazon Kinesis Kinesis-Client konfigurieren](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#client-configuration) auf der Seite [Verbraucher von KCL 1.x zu KCL 2.x migrieren](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-migration).
+ **Schritt 5: Überprüfen Sie die Entfernung der Leerlaufzeiten und die Entfernung der Client-Konfiguration**
Folgen Sie den Abschnitten [Entfernung von Leerlaufzeiten und Entfernen](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#idle-time-removal) der [Client-Konfiguration auf](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#client-configuration-removals) der Seite [Verbraucher von KCL 1.x zu KCL 2.x migrieren](https://docs.aws.amazon.com/streams/latest/dev/kcl-migration.html#recrod-processor-migration).
+ **Schritt 6: Folgen Sie den step-by-step Anweisungen im Migrationshandbuch von KCL 2.x zu KCL 3.x**
Folgen Sie den Anweisungen auf der [Migrieren Sie von KCL 2.x zu KCL 3.x](kcl-migration-from-2-3.md) Seite, um die Migration abzuschließen. Wenn Sie nach einem Rollback zur vorherigen KCL-Version zurückkehren oder ein Rollforward zu KCL 3.x durchführen müssen, finden Sie weitere Informationen unter und. [Rollback zu einer früheren KCL-Version](kcl-migration-rollback.md) [Rollforward zu KCL 3.x nach einem Rollback](kcl-migration-rollforward.md)
**Wichtig**
Verwenden Sie die AWS SDK für Java Versionen 2.27.19 bis 2.27.23 nicht mit KCL 3.x. Diese Versionen enthalten ein Problem, das einen Ausnahmefehler im Zusammenhang mit der DynamoDB-Nutzung von KCL verursacht. Wir empfehlen, die AWS SDK für Java Version 2.28.0 oder höher zu verwenden, um dieses Problem zu vermeiden.
# Dokumentation zu früheren KCL-Versionen
Die folgenden Themen wurden archiviert. Die aktuelle Dokumentation zur Kinesis Client Library finden Sie unter[Verwenden Sie die Kinesis-Clientbibliothek](kcl.md).
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
**Topics**
+ [
# Informationen zu KCL 1.x und 2.x
](shared-throughput-kcl-consumers.md)
+ [
# Entwickeln Sie benutzerdefinierte Verbraucher mit gemeinsamem Durchsatz
](shared-throughput-consumers.md)
+ [
# Migrieren Sie Verbraucher von KCL 1.x zu KCL 2.x
](kcl-migration.md)
# Informationen zu KCL 1.x und 2.x
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird am 30. Januar 2026 end-of-support verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Eine der Methoden zur Entwicklung benutzerdefinierter Verbraucheranwendungen, die Daten aus KDS-Datenströmen verarbeiten können, ist die Verwendung der Kinesis Client Library (KCL).
**Topics**
+ [
## Über KCL (frühere Versionen)
](#shared-throughput-kcl-consumers-overview)
+ [
## Frühere Versionen von KCL
](#shared-throughput-kcl-consumers-versions)
+ [
## KCL-Konzepte (frühere Versionen)
](#shared-throughput-kcl-consumers-concepts)
+ [
## Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden
](#shared-throughput-kcl-consumers-leasetable)
+ [
## Verarbeiten Sie mehrere Datenströme mit derselben KCL 2.x für Java-Consumer-Anwendung
](#shared-throughput-kcl-multistream)
+ [
## Verwenden Sie die KCL mit der Schema Registry AWS Glue
](#shared-throughput-kcl-consumers-glue-schema-registry)
**Anmerkung**
Sowohl für KCL 1.x als auch für KCL 2.x wird empfohlen, je nach Nutzungsszenario ein Upgrade auf die neueste KCL-1.x-Version oder KCL-2.x-Version durchzuführen. Sowohl KCL 1.x als auch KCL 2.x werden regelmäßig mit neueren Versionen aktualisiert, die die neuesten Abhängigkeits- und Sicherheitspatches, Bugfixes und abwärtskompatible neue Features enthalten. [Weitere Informationen finden Sie unter /releases. https://github.com/awslabs/ amazon-kinesis-client](https://github.com/awslabs/amazon-kinesis-client/releases)
## Über KCL (frühere Versionen)
KCL unterstützt Sie bei der Nutzung und Verarbeitung von Daten aus einem Kinesis-Datenstrom, indem sie sich um viele der komplexen Aufgaben kümmert, die mit verteilter Datenverarbeitung verbunden sind. Dazu gehören der Lastenausgleich über mehrere Anwendungs-Instances hinweg, die Reaktion auf Ausfälle von Verbraucheranwendungs-Instances, die Überprüfung verarbeiteter Datensätze und die Reaktion auf Resharding. Die KCL kümmert sich um all diese Unteraufgaben, sodass Sie sich darauf konzentrieren können, Ihre benutzerdefinierte Logik für die Verarbeitung von Datensätzen zu schreiben.
Die KCL unterscheidet sich von den Kinesis Data Streams APIs , die in der verfügbar sind. AWS SDKs Die Kinesis Data Streams APIs helfen Ihnen bei der Verwaltung vieler Aspekte von Kinesis Data Streams, darunter das Erstellen von Streams, das Resharding sowie das Einfügen und Abrufen von Datensätzen. Die KCL bietet eine Abstraktionsebene für all diese Unteraufgaben, sodass Sie sich auf die benutzerdefinierte Datenverarbeitungslogik Ihrer Verbraucheranwendung konzentrieren können. Informationen zur Kinesis-Data-Streams-API finden Sie in der [Amazon-Kinesis-API-Referenz](https://docs.aws.amazon.com/kinesis/latest/APIReference/Welcome.html).
**Wichtig**
Die KCL ist eine Java-Bibliothek. Die Support für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle namens bereitgestellt. MultiLangDaemon Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine andere KCL-Sprache als Java verwenden. Wenn Sie beispielsweise die KCL für Python installieren und Ihre Consumer-Anwendung vollständig in Python schreiben, müssen Sie trotzdem Java auf Ihrem System installiert haben, da MultiLangDaemon Darüber hinaus MultiLangDaemon verfügt es über einige Standardeinstellungen, die Sie möglicherweise an Ihren Anwendungsfall anpassen müssen, z. B. an die AWS Region, mit der eine Verbindung hergestellt wird. Weitere Informationen dazu finden Sie unter [ MultiLangDaemon KCL-Projekt](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang). MultiLangDaemon GitHub
Die KCL dient als Vermittler zwischen Ihrer Datensatzverarbeitungslogik und Kinesis Data Streams.
## Frühere Versionen von KCL
Derzeit können Sie eine der folgenden unterstützten Versionen von KCL verwenden, um Ihre benutzerdefinierten Anwendungen für Privatanwender zu erstellen:
+ **KCL 1.x**
Weitere Informationen finden Sie unter [Entwickeln Sie KCL 1.x-Verbraucher](developing-consumers-with-kcl.md).
+ **KCL 2.x**
Weitere Informationen finden Sie unter [Entwickeln Sie KCL 2.x-Verbraucher](developing-consumers-with-kcl-v2.md).
Sie können entweder KCL 1.x oder KCL 2.x verwenden, um Verbraucheranwendungen zu erstellen, die einen gemeinsamen Durchsatz verwenden. Weitere Informationen finden Sie unter [Entwickeln Sie mithilfe von KCL benutzerdefinierte Verbraucher mit gemeinsamem Durchsatz](custom-kcl-consumers.md).
Um Verbraucheranwendungen zu erstellen, die einen dedizierten Durchsatz verwenden (Enhanced Fan-Out-Consumer), können Sie nur KCL 2.x verwenden. Weitere Informationen finden Sie unter [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md).
Informationen zu den Unterschieden zwischen KCL 1.x und KCL 2.x sowie Anweisungen zur Migration von KCL 1.x zu KCL 2.x finden Sie unter [Migrieren Sie Verbraucher von KCL 1.x zu KCL 2.x](kcl-migration.md).
## KCL-Konzepte (frühere Versionen)
+ **KCL-Konsumentenanwendung** – eine Anwendung, die unter Verwendung von KCL kundenspezifisch entwickelt wurde und zum Lesen und Verarbeiten von Datensätzen aus Datenströmen bestimmt ist.
+ **Konsumentenanwendungs-Instance** – KCL-Konsumentenanwendungen werden in der Regel verteilt, wobei eine oder mehrere Anwendungs-Instances gleichzeitig ausgeführt werden, um Fehler zu koordinieren und einen dynamischen Lastenausgleich bei der Verarbeitung von Datensätzen vorzunehmen.
+ **Worker** – eine übergeordnete Klasse, die eine KCL-Konsumentenanwendungs-Instance verwendet, um mit der Datenverarbeitung zu beginnen.
**Wichtig**
Jede KCL-Konsumentenanwendungs-Instance hat einen Worker.
Der Worker initialisiert und überwacht verschiedene Aufgaben, darunter das Synchronisieren von Shard- und Leasing-Informationen, das Verfolgen von Shard-Zuweisungen und das Verarbeiten von Daten aus den Shards. Ein Worker stellt KCL die Konfigurationsinformationen für die Consumer-Anwendung zur Verfügung, z. B. den Namen des Datenstroms, dessen Datensätze diese KCL-Consumer-Anwendung verarbeiten wird, und die AWS Anmeldeinformationen, die für den Zugriff auf diesen Datenstrom erforderlich sind. Der Worker startet außerdem die spezifische Instance der KCL-Konsumentenanwendung, um Datensätze aus dem Datenstrom an die Datensatzprozessoren zu übermitteln.
**Wichtig**
In KCL 1.x heißt diese Klasse **Worker**. [Weitere Informationen (dies sind die Java-KCL-Repositorys) finden Sie unter/.java. https://github.com/awslabs/ amazon-kinesis-client blob/v1.x/src/main/java/com/amazonaws/services/kinesis/clientlibrary/lib/worker/Worker](https://github.com/awslabs/amazon-kinesis-client/blob/v1.x/src/main/java/com/amazonaws/services/kinesis/clientlibrary/lib/worker/Worker.java) In KCL 2.x heißt diese Klasse **Scheduler**. Der Zweck von Scheduler in KCL 2.x ist identisch mit dem Zweck von Worker in KCL 1.x. [Weitere Informationen zur Scheduler-Klasse in KCL 2.x finden Sie unter/.java. https://github.com/awslabs/ amazon-kinesis-client blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/Scheduler](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/Scheduler.java)
+ **Lease** – Daten, die die Bindung zwischen einem Worker und einem Shard definieren. Verteilte KCL-Konsumentenanwendungen nutzen Leases, um die Verarbeitung von Datensätzen auf eine ganze Flotte von Workern zu verteilen. Zu einem bestimmten Zeitpunkt ist jeder Shard von Datensätzen durch einen Lease, der durch die **leaseKey**-Variable identifiziert wird, an einen bestimmten Worker gebunden.
Standardmäßig kann ein Mitarbeiter einen oder mehrere Leasingverträge (abhängig vom Wert der Variablen **maxLeasesForWorker**) gleichzeitig abschließen.
**Wichtig**
Jeder Worker versucht, alle verfügbaren Leases für alle verfügbaren Shards in einem Datenstrom zu halten. Aber es kann nur jeweils ein Worker jeden Lease zu einem bestimmten Zeitpunkt erfolgreich halten.
Wenn Sie beispielsweise eine Konsumentenanwendungs-Instance A mit Worker A haben, die einen Datenstrom mit 4 Shards verarbeitet, kann Worker A Leases für die Shards 1, 2, 3 und 4 gleichzeitig halten. Wenn Sie jedoch zwei Konsumentenanwendungs-Instances haben: A und B mit Worker A und Worker B und diese Instances einen Datenstrom mit 4 Shards verarbeiten, können Worker A und Worker B nicht gleichzeitig den Lease für Shard 1 halten. Ein Worker hält den Lease für einen bestimmten Shard, bis er bereit ist, die Verarbeitung der Datensätze dieses Shards zu beenden, oder bis er ausfällt. Wenn ein Worker den Lease beendet, nimmt ein anderer Worker den Lease auf und hält ihn.
[Weitere Informationen (dies sind die Java-KCL-Repositorys) finden Sie unter [https://github.com/awslabs/amazon-kinesis-client/blob/v1.x/src/main/java/com/amazonaws/services/kinesis/leases/impl/Lease.java für KCL 1.x und https://github.com/awslabs/amazon-kinesis-client/.java](https://github.com/awslabs/amazon-kinesis-client/blob/v1.x/src/main/java/com/amazonaws/services/kinesis/leases/impl/Lease.java) für KCL 2.x. blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/leases/Lease](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/leases/Lease.java)
+ **Leasetabelle** – Eine einzigartige Amazon-DynamoDB-Tabelle, die verwendet wird, um die Shards in einem KDS-Datenstrom zu verfolgen, die von den Workern der KCL-Konsumentenanwendung geleast und verarbeitet werden. Die Leasetabelle muss (innerhalb eines Workers und für alle Worker) mit den neuesten Shard-Informationen aus dem Datenstrom synchronisiert bleiben, während die KCL-Konsumentenanwendung ausgeführt wird. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](#shared-throughput-kcl-consumers-leasetable).
+ **Datensatzprozessor** – Die Logik, die definiert, wie Ihre KCL-Konsumentenanwendung die Daten verarbeitet, die sie aus den Datenströmen erhält. Zur Laufzeit instanziiert eine KCL-Konsumentenanwendungs-Instance einen Worker, und dieser Worker instanziiert einen Datensatzprozessor für jeden Shard, für den er einen Lease hat.
## Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden
**Topics**
+ [
### Was ist eine Leasingtabelle
](#shared-throughput-kcl-consumers-what-is-leasetable)
+ [
### Durchsatz
](#shared-throughput-kcl-leasetable-throughput)
+ [
### So wird eine Leasing-Tabelle mit den Shards in einem Kinesis-Datenstrom synchronisiert
](#shared-throughput-kcl-consumers-leasetable-sync)
### Was ist eine Leasingtabelle
Für jede Anwendung mit Amazon Kinesis Data Streams verwendet KCL eine einzigartige Leasetabelle (gespeichert in einer Amazon-DynamoDB-Tabelle), die verwendet wird, um die Shards in einem KDS-Datenstrom zu verfolgen, die von den Workern der KCL-Konsumentenanwendung geleast und verarbeitet werden.
**Wichtig**
KCL verwendet den Namen der Konsumentenanwendung, um den Namen der Leasetabelle zu erstellen, die diese Konsumentenanwendung verwendet. Daher muss der Name jeder Konsumentenanwendung eindeutig sein.
Sie können die Leasetabelle mit der [Amazon-DynamoDB-Konsole](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ConsoleDynamoDB.html) anzeigen, während die Konsumentenanwendung ausgeführt wird.
Wenn die Leasetabelle für Ihre KCL-Konsumentenanwendung beim Start der Anwendung nicht vorhanden ist, erstellt einer der Worker die Leasetabelle für diese Anwendung.
**Wichtig**
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 stellt einen Shard dar, der von den Workern Ihrer Konsumentenanwendung verarbeitet wird. Wenn Ihre KCL-Konsumentenanwendung nur einen Datenstrom verarbeitet, dann ist `leaseKey`, der Hash-Schlüssel für die Leasetabelle, die Shard-ID. Wenn Sie [Verarbeiten Sie mehrere Datenströme mit derselben KCL 2.x für Java-Consumer-Anwendung](#shared-throughput-kcl-multistream) sind, dann sieht die Struktur des leaseKey wie folgt aus: `account-id:StreamName:streamCreationTimestamp:ShardId`. Beispiel, `111111111:multiStreamTest-1:12345:shardId-000000000336`.
Neben der Shard-ID enthält jede Zeile noch folgende Daten:
+ **checkpoint:** Die letzte Prüfpunkt-Sequenznummer des Shards. Dieser Wert ist für alle Shards im Datenstrom eindeutig.
+ **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 für ein Lease Versioning verwendet, damit Auftragnehmer erkennen, wenn ihr Lease von einem anderen Auftragnehmer übernommen wurde.
+ **leaseKey:** Eine eindeutige Kennung für einen Lease. Jeder Lease gilt für einen bestimmten Shard im Datenstrom und wird immer nur von einem Worker gehalten.
+ **leaseOwner:** Der Auftragnehmer, dem der Lease gehört.
+ **ownerSwitchesSinceCheckpoint:** Wie oft hat dieser Leasingvertrag seit der letzten Erstellung eines Checkpoints die Mitarbeiter gewechselt?
+ **parentShardId:** Wird verwendet, um sicherzustellen, dass der übergeordnete Shard vollständig verarbeitet ist, bevor die Verarbeitung der untergeordneten Shards beginnt. So wird sichergestellt, dass Datensätze in der gleichen Reihenfolge verarbeitet werden, in der sie in den Stream eingespeist wurden.
+ **hashrange:** Wird von `PeriodicShardSyncManager` verwendet, um regelmäßige Synchronisierungen durchzuführen, um fehlende Shards in der Leasetabelle zu finden und bei Bedarf Leases für sie zu erstellen.
**Anmerkung**
Diese Daten sind in der Leasetabelle für jeden Shard enthalten, der mit KCL 1.14 und KCL 2.3 beginnt. Weitere Hinweise zu `PeriodicShardSyncManager` und die periodische Synchronisierung zwischen Leases und Shards finden Sie unter [So wird eine Leasing-Tabelle mit den Shards in einem Kinesis-Datenstrom synchronisiert](#shared-throughput-kcl-consumers-leasetable-sync).
+ **childshards:** Wird von `LeaseCleanupManager` verwendet, um den Verarbeitungsstatus des untergeordneten Shards zu überprüfen und zu entscheiden, ob der übergeordnete Shard aus der Leasetabelle gelöscht werden kann.
**Anmerkung**
Diese Daten sind in der Leasetabelle für jeden Shard enthalten, der mit KCL 1.14 und KCL 2.3 beginnt.
+ **shardID:** Die ID des Shards.
**Anmerkung**
Diese Daten sind nur dann in der Leasetabelle enthalten, wenn Sie [Verarbeiten Sie mehrere Datenströme mit derselben KCL 2.x für Java-Consumer-Anwendung](#shared-throughput-kcl-multistream) sind. Dies wird nur in KCL 2.x für Java unterstützt, beginnend mit KCL 2.3 für Java und höher.
+ **Streamname** Die Kennung des Datenstroms im folgenden Format: `account-id:StreamName:streamCreationTimestamp`.
**Anmerkung**
Diese Daten sind nur dann in der Leasetabelle enthalten, wenn Sie [Verarbeiten Sie mehrere Datenströme mit derselben KCL 2.x für Java-Consumer-Anwendung](#shared-throughput-kcl-multistream) sind. Dies wird nur in KCL 2.x für Java unterstützt, beginnend mit KCL 2.3 für Java und höher.
### Durchsatz
Wenn Ihre Amazon Kinesis Data Streams-Anwendung Ausnahmen für den bereitgestellten Durchsatz erhält, sollten Sie den bereitgestellten Durchsatz für die DynamoDB-Tabelle erhöhen. Die KCL erstellt die Tabelle mit einem bereitgestellten Durchsatz von 10 Lese- und 10 Schreibvorgängen pro Sekunde, dies reicht aber möglichweise für Ihre Anwendung nicht aus. Beispiel: Wenn Ihre Amazon Kinesis Data Streams-Anwendung häufig Prüfpunkte setzt oder einen Stream verarbeitet, der aus vielen Shards besteht, müssen Sie den Durchsatz möglicherweise erhöhen.
Weitere Informationen zum bereitgestellten Durchsatz in DynamoDB finden Sie unter [Lese-/Schreibkapazitätsmodus](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html) und [Arbeiten mit Tabellen und Daten](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithDDTables.html) im *Amazon-DynamoDB-Entwicklerhandbuch*.
### So wird eine Leasing-Tabelle mit den Shards in einem Kinesis-Datenstrom synchronisiert
Worker in KCL-Konsumentenanwendungen verwenden Leases, um Shards aus einem bestimmten Datenstrom zu verarbeiten. Die Informationen darüber, welcher Worker zu einem bestimmten Zeitpunkt welchen Shard least, werden in einer Leasetabelle gespeichert. Die Leasetabelle muss mit den neuesten Shard-Informationen aus dem Datenstrom synchronisiert bleiben, während die KCL-Konsumentenanwendung ausgeführt wird. KCL synchronisiert die Leasetabelle mit den Shard-Informationen, die während des Bootstrapings der Konsumentenanwendung (entweder wenn die Konsumentenanwendung initialisiert oder neu gestartet wird) vom Dienst Kinesis Data Streams erfasst werden und auch immer dann, wenn ein Shard, der gerade verarbeitet wird, ein Ende erreicht (Resharding), erreicht. Mit anderen Worten, die Worker oder eine KCL-Konsumentenanwendung werden mit dem Datenstrom synchronisiert, den sie beim ersten Bootstrap der Konsumentenanwendung verarbeiten, und immer dann wenn die Konsumentenanwendung auf ein Reshard-Ereignis des Datenstroms trifft.
**Topics**
+ [
#### Synchronisation in KCL 1.0–1.13 und KCL 2.0–2.2
](#shared-throughput-kcl-consumers-leasetable-sync-old)
+ [
#### Synchronisation in KCL 2.x, beginnend mit KCL 2.3 und höher
](#shared-throughput-kcl-consumers-leasetable-sync-new-kcl2)
+ [
#### Synchronisation in KCL 1.x, beginnend mit KCL 1.14 und höher
](#shared-throughput-kcl-consumers-leasetable-sync-new-kcl1)
#### Synchronisation in KCL 1.0–1.13 und KCL 2.0–2.2
In KCL 1.0-1.13 und KCL 2.0-2.2 synchronisiert KCL beim Bootstraping der Verbraucheranwendung und auch bei jedem Reshard-Ereignis des Datenstroms die Leasetabelle mit den Shard-Informationen, die vom Kinesis Data Streams Streams-Dienst abgerufen wurden, indem die oder die Erkennung aufgerufen wird. `ListShards` `DescribeStream` APIs In allen oben aufgeführten KCL-Versionen führt jeder Worker einer KCL-Consumer-Anwendung die folgenden Schritte durch, um den lease/shard Synchronisationsprozess während des Bootstrappings der Consumer-Anwendung und bei jedem Stream-Reshard-Ereignis durchzuführen:
+ Ruft alle Shards für Daten des Streams ab, der gerade verarbeitet wird
+ Ruft alle Shard-Leases aus der Leasetabelle ab
+ Filtert jeden offenen Shard heraus, für den es in der Leasetabelle keinen Lease gibt
+ Iteriert über alle gefundenen offenen Shards und für jeden offenen Shard ohne offenes übergeordnetes Element:
+ Durchläuft den Hierarchiebaum über den Pfad der Vorgänger, um festzustellen, ob der Shard ein Nachfolger ist. Ein Shard wird als untergeordnetes Element betrachtet, wenn gerade ein Vorgänger-Shard verarbeitet wird (der Leaseeintrag für den Vorgänger-Shard ist in der Leasetabelle vorhanden) oder wenn ein Vorgänger-Shard verarbeitet werden soll (wenn die Anfangsposition beispielsweise `TRIM_HORIZON` oder `AT_TIMESTAMP` ist)
+ Handelt es sich bei dem offenen Shard im Kontext um einen Nachfolger-Shard, überprüft KCL den Shard anhand seiner Ausgangsposition und erstellt, falls erforderlich, Leaseverträge für die übergeordneten Shard
#### Synchronisation in KCL 2.x, beginnend mit KCL 2.3 und höher
Beginnend mit den neuesten unterstützten Versionen von KCL 2.x (KCL 2.3) und höher unterstützt die Bibliothek nun die folgenden Änderungen am Synchronisationsprozess. Diese lease/shard Synchronisierungsänderungen reduzieren die Anzahl der API-Aufrufe, die von KCL-Consumer-Anwendungen an den Kinesis Data Streams Streams-Service getätigt werden, erheblich und optimieren das Leasing-Management in Ihrer KCL-Consumer-Anwendung.
+ Wenn beim Bootstraping der Anwendung die Leasetabelle leer ist, verwendet KCL die Filteroption der `ListShard`-API (den optionalen Anforderungsparameter von `ShardFilter`), um Leases nur für einen Snapshot von Shards abzurufen und zu erstellen, die zu dem durch den `ShardFilter`-Parameter angegebenen Zeitpunkt geöffnet waren. Mit dem `ShardFilter`-Parameter können Sie die Antwort der `ListShards`-API herausfiltern. Die einzige erforderliche Eigenschaft des `ShardFilter`-Parameters ist `Type`. KCL verwendet die `Type`-Filtereigenschaft und die folgenden gültigen Werte, um offene Shards, für die möglicherweise neue Leases erforderlich sind, zu identifizieren und eine Momentaufnahme zurückzugeben:
+ `AT_TRIM_HORIZON` – Die Antwort umfasst alle Shards, die am `TRIM_HORIZON` geöffnet waren.
+ `AT_LATEST` – Die Antwort enthält nur die aktuell geöffneten Shards des Datenstroms.
+ `AT_TIMESTAMP` – Die Antwort umfasst alle Shards, deren Startzeitstempel kleiner oder gleich dem angegebenen Zeitstempel sind und deren Endzeitstempel größer oder gleich dem angegebenen Zeitstempel ist oder solche, die noch offen sind.
`ShardFilter` wird verwendet, wenn Leases für eine leere Leasetabelle erstellt werden, um Leases für einen Snapshot von Shards zu initialisieren, die unter `RetrievalConfig#initialPositionInStreamExtended` angegeben sind.
Mehr über `ShardFilter` erfahren Sie unter [https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ShardFilter.html](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ShardFilter.html).
+ Anstatt dass alle Worker die lease/shard Synchronisation durchführen, um die Leasetabelle mit den neuesten Shards im Datenstrom auf dem neuesten Stand zu halten, führt ein einziger gewählter Worker-Leiter die Leasing-/Shard-Synchronisierung durch.
+ KCL 2.3 verwendet den `ChildShards` Rückgabeparameter von `GetRecords` und, `SubscribeToShard` APIs um die lease/shard Synchronisation durchzuführen, die bei geschlossenen Shards stattfindet, sodass ein KCL-Worker nur Leases `SHARD_END` für die untergeordneten Shards des Shards erstellen kann, dessen Verarbeitung abgeschlossen ist. Bei Anwendungen, die von allen Benutzern gemeinsam genutzt werden, verwendet diese Optimierung der lease/shard Synchronisation den API-Parameter. `ChildShards` `GetRecords` Für Verbraucheranwendungen mit dediziertem Durchsatz (erweiterter Fan-Out) verwendet diese Optimierung der lease/shard Synchronisation den `ChildShards` `SubscribeToShard` API-Parameter. Weitere Informationen finden Sie unter [GetRecords](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html), [SubscribeToShards](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_SubscribeToShard.html) und [ChildShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ChildShard.html).
+ Mit den oben genannten Änderungen ändert sich das Verhalten von KCL von dem Modell, dass alle Worker über alle vorhandenen Shards lernen, hin zu dem Modell, dass Worker nur noch über die untergeordneten Shards der Shards lernen, die jeder Worker besitzt. Daher führt KCL jetzt zusätzlich zu der Synchronisation, die beim Bootstraping von Verbraucheranwendungen und bei Reshard-Ereignissen stattfindet, auch zusätzliche regelmäßige shard/lease Scans durch, um potenzielle Lücken in der Leasetabelle zu identifizieren (mit anderen Worten, um mehr über alle neuen Shards zu erfahren), um sicherzustellen, dass der gesamte Hash-Bereich des Datenstroms verarbeitet wird, und um bei Bedarf Leases für sie zu erstellen. `PeriodicShardSyncManager`ist die Komponente, die für die regelmäßige Ausführung von Scans verantwortlich ist. lease/shard
Weitere Informationen zu `PeriodicShardSyncManager` KCL 2.3 finden Sie unter [https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/leases/LeaseManagementConfig.java \$1L201](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/leases/LeaseManagementConfig.java#L201-L213) -L213.
In KCL 2.3 stehen neue Konfigurationsoptionen, um `PeriodicShardSyncManager` in `LeaseManagementConfig` zu konfigurieren:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/shared-throughput-kcl-consumers.html)
Außerdem werden jetzt neue CloudWatch Messwerte ausgegeben, um den Zustand von zu überwachen. `PeriodicShardSyncManager` Weitere Informationen finden Sie unter [PeriodicShardSyncManager](monitoring-with-kcl.md#periodic-task).
+ Einschließlich einer Optimierung auf `HierarchicalShardSyncer`, um nur Leases für eine Shard-Ebene zu erstellen.
#### Synchronisation in KCL 1.x, beginnend mit KCL 1.14 und höher
Beginnend mit den neuesten unterstützten Versionen von KCL 1.x (KCL 1.14) und höher unterstützt die Bibliothek nun die folgenden Änderungen am Synchronisationsprozess. Diese lease/shard Synchronisierungsänderungen reduzieren die Anzahl der API-Aufrufe, die von KCL-Consumer-Anwendungen an den Kinesis Data Streams Streams-Service getätigt werden, erheblich und optimieren das Leasing-Management in Ihrer KCL-Consumer-Anwendung.
+ Wenn beim Bootstraping der Anwendung die Leasetabelle leer ist, verwendet KCL die Filteroption der `ListShard`-API (den optionalen Anforderungsparameter von `ShardFilter`), um Leases nur für einen Snapshot von Shards abzurufen und zu erstellen, die zu dem durch den `ShardFilter`-Parameter angegebenen Zeitpunkt geöffnet waren. Mit dem `ShardFilter`-Parameter können Sie die Antwort der `ListShards`-API herausfiltern. Die einzige erforderliche Eigenschaft des `ShardFilter`-Parameters ist `Type`. KCL verwendet die `Type`-Filtereigenschaft und die folgenden gültigen Werte, um offene Shards, für die möglicherweise neue Leases erforderlich sind, zu identifizieren und eine Momentaufnahme zurückzugeben:
+ `AT_TRIM_HORIZON` – Die Antwort umfasst alle Shards, die am `TRIM_HORIZON` geöffnet waren.
+ `AT_LATEST` – Die Antwort enthält nur die aktuell geöffneten Shards des Datenstroms.
+ `AT_TIMESTAMP` – Die Antwort umfasst alle Shards, deren Startzeitstempel kleiner oder gleich dem angegebenen Zeitstempel sind und deren Endzeitstempel größer oder gleich dem angegebenen Zeitstempel ist oder solche, die noch offen sind.
`ShardFilter` wird verwendet, wenn Leases für eine leere Leasetabelle erstellt werden, um Leases für einen Snapshot von Shards zu initialisieren, die unter `KinesisClientLibConfiguration#initialPositionInStreamExtended` angegeben sind.
Mehr über `ShardFilter` erfahren Sie unter [https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ShardFilter.html](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ShardFilter.html).
+ Anstatt dass alle Worker die lease/shard Synchronisation durchführen, um die Leasetabelle mit den neuesten Shards im Datenstrom auf dem neuesten Stand zu halten, führt ein einziger gewählter Worker-Leiter die Leasing-/Shard-Synchronisierung durch.
+ KCL 1.14 verwendet den `ChildShards` Rückgabeparameter von `GetRecords` und, `SubscribeToShard` APIs um die lease/shard Synchronisation durchzuführen, die bei geschlossenen Shards stattfindet, sodass ein KCL-Worker nur Leases `SHARD_END` für die untergeordneten Shards des Shards erstellen kann, dessen Verarbeitung abgeschlossen ist. Weitere Informationen erhalten Sie unter [GetRecords](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html) und [ChildShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ChildShard.html).
+ Mit den oben genannten Änderungen ändert sich das Verhalten von KCL von dem Modell, dass alle Worker über alle vorhandenen Shards lernen, hin zu dem Modell, dass Worker nur noch über die untergeordneten Shards der Shards lernen, die jeder Worker besitzt. Daher führt KCL jetzt zusätzlich zu der Synchronisation, die beim Bootstraping von Verbraucheranwendungen und bei Reshard-Ereignissen stattfindet, auch zusätzliche regelmäßige shard/lease Scans durch, um potenzielle Lücken in der Leasetabelle zu identifizieren (mit anderen Worten, um mehr über alle neuen Shards zu erfahren), um sicherzustellen, dass der gesamte Hash-Bereich des Datenstroms verarbeitet wird, und um bei Bedarf Leases für sie zu erstellen. `PeriodicShardSyncManager`ist die Komponente, die für die regelmäßige Ausführung von Scans verantwortlich ist. lease/shard
Wenn `KinesisClientLibConfiguration#shardSyncStrategyType` auf `ShardSyncStrategyType.SHARD_END` gesetzt ist, wird `PeriodicShardSync leasesRecoveryAuditorInconsistencyConfidenceThreshold` verwendet, um den Schwellenwert für die Anzahl der aufeinanderfolgenden Scans mit Lücken in der Leasetabelle zu bestimmen, nach dem eine Shard-Synchronisierung erzwungen werden soll. Wenn `KinesisClientLibConfiguration#shardSyncStrategyType` auf `ShardSyncStrategyType.PERIODIC` gesetzt ist, wird `leasesRecoveryAuditorInconsistencyConfidenceThreshold` ignoriert.
Weitere Informationen zu `PeriodicShardSyncManager` KCL 1.14 finden Sie unter [https://github.com/awslabs/amazon-kinesis-client/blob/v1.x/src/main/java/com/amazonaws/services/kinesis/clientlibrary/lib/worker/KinesisClientLibConfiguration.java](https://github.com/awslabs/amazon-kinesis-client/blob/v1.x/src/main/java/com/amazonaws/services/kinesis/clientlibrary/lib/worker/KinesisClientLibConfiguration.java#L987-L999) \$1L987 -L999.
In KCL 1.14 ist eine neue Konfigurationsoption verfügbar, um `PeriodicShardSyncManager` in `LeaseManagementConfig` zu konfigurieren:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/shared-throughput-kcl-consumers.html)
Außerdem werden jetzt neue CloudWatch Messwerte ausgegeben, um den Zustand von zu überwachen. `PeriodicShardSyncManager` Weitere Informationen finden Sie unter [PeriodicShardSyncManager](monitoring-with-kcl.md#periodic-task).
+ KCL 1.14 unterstützt jetzt auch die verzögerte Lease-Bereinigung. Leases werden asynchron von `LeaseCleanupManager` bei Erreichen von `SHARD_END` gelöscht, wenn ein Shard entweder die Aufbewahrungsfrist des Datenstroms überschritten hat oder wenn er aufgrund eines Resharding-Vorgangs geschlossen wurde.
Es stehen neue Konfigurationsoptionen zur Verfügung, um `LeaseCleanupManager` zu konfigurieren.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/streams/latest/dev/shared-throughput-kcl-consumers.html)
+ Einschließlich einer Optimierung auf `KinesisShardSyncer`, um nur Leases für eine Shard-Ebene zu erstellen.
## Verarbeiten Sie mehrere Datenströme mit derselben KCL 2.x für Java-Consumer-Anwendung
In diesem Abschnitt werden die folgenden Änderungen in KCL 2.x für Java beschrieben, mit denen Sie KCL-Verbraucheranwendungen erstellen können, die mehr als einen Datenstrom gleichzeitig verarbeiten können.
**Wichtig**
Die Multistream-Verarbeitung wird nur in KCL 2.x für Java unterstützt, beginnend mit KCL 2.3 für Java und höher.
Die Multistream-Verarbeitung wird NICHT für andere Sprachen unterstützt, in denen KCL 2.x implementiert werden kann.
Die Multistream-Verarbeitung wird in keiner Version von KCL 1.x unterstützt.
+ **MultistreamTracker Schnittstelle**
Um eine Verbraucheranwendung zu erstellen, die mehrere Streams gleichzeitig verarbeiten kann, müssen Sie eine neue Schnittstelle namens implementieren [MultistreamTracker](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/processor/MultiStreamTracker.java). Diese Schnittstelle enthält die `streamConfigList`-Methode, die die Liste der Datenströme und ihrer Konfigurationen zurückgibt, die von der KCL-Konsumentenanwendung verarbeitet werden sollen. Beachten Sie, dass die Datenströme, die verarbeitet werden, während der Laufzeit der Konsumentenanwendung geändert werden können. `streamConfigList` wird regelmäßig von der KCL aufgerufen, um mehr über die Änderungen der zu verarbeitenden Datenströme zu erfahren.
Die `streamConfigList` Methode füllt die [StreamConfig](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/StreamConfig.java#L23)Liste auf.
```
package software.amazon.kinesis.common;
import lombok.Data;
import lombok.experimental.Accessors;
@Data
@Accessors(fluent = true)
public class StreamConfig {
private final StreamIdentifier streamIdentifier;
private final InitialPositionInStreamExtended initialPositionInStreamExtended;
private String consumerArn;
}
```
Beachten Sie, dass es sich bei den Feldern `StreamIdentifier` und `InitialPositionInStreamExtended` um Pflichtfelder handelt, während `consumerArn` optional ist. Sie müssen den `consumerArn` nur angeben, wenn Sie KCL 2.x verwenden, um eine erweiterte Fan-Out-Konsumentenanwendung zu implementieren.
Weitere Informationen dazu finden Sie `StreamIdentifier` unter [https://github.com/awslabs/amazon-kinesis-client/blob/v2.5.8/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/StreamIdentifier.java \$1L129.](https://github.com/awslabs/amazon-kinesis-client/blob/v2.5.8/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/StreamIdentifier.java#L129) Um eine zu erstellen`StreamIdentifier`, empfehlen wir, dass Sie eine Multistream-Instanz aus der `streamArn` und der erstellen`streamCreationEpoch`, die in Version 2.5.0 und höher verfügbar ist. Erstellen Sie in KCL v2.3 und v2.4, die dies nicht unterstützen`streamArm`, eine Multistream-Instanz mithilfe des folgenden Formats. `account-id:StreamName:streamCreationTimestamp` Dieses Format ist veraltet und wird ab der nächsten Hauptversion nicht mehr unterstützt.
`MultistreamTracker` beinhaltet auch eine Strategie zum Löschen von Leases alter Streams in der Leasetabelle (`formerStreamsLeasesDeletionStrategy`). Beachten Sie, dass die Strategie während der Laufzeit der Konsumentenanwendung NICHT geändert werden kann. [Weitere Informationen finden Sie unter https://github.com/awslabs/ amazon-kinesis-client /blob/0c5042dadf794fe988438436252a5a8fe70b6b0 .java b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/processor/FormerStreamsLeasesDeletionStrategy](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/processor/FormerStreamsLeasesDeletionStrategy.java)
+ [ConfigsBuilder](https://github.com/awslabs/amazon-kinesis-client/blob/0c5042dadf794fe988438436252a5a8fe70b6b0b/amazon-kinesis-client/src/main/java/software/amazon/kinesis/common/ConfigsBuilder.java)ist eine anwendungsweite Klasse, mit der Sie alle KCL 2.x-Konfigurationseinstellungen angeben können, die beim Erstellen Ihrer KCL-Consumer-Anwendung verwendet werden sollen. `ConfigsBuilder`Die Klasse unterstützt jetzt die Schnittstelle. `MultistreamTracker` Sie können ConfigsBuilder entweder mit dem Namen des einen Datenstroms initialisieren, aus dem Datensätze abgerufen werden sollen:
```
/**
* Constructor to initialize ConfigsBuilder with StreamName
* @param streamName
* @param applicationName
* @param kinesisClient
* @param dynamoDBClient
* @param cloudWatchClient
* @param workerIdentifier
* @param shardRecordProcessorFactory
*/
public ConfigsBuilder(@NonNull String streamName, @NonNull String applicationName,
@NonNull KinesisAsyncClient kinesisClient, @NonNull DynamoDbAsyncClient dynamoDBClient,
@NonNull CloudWatchAsyncClient cloudWatchClient, @NonNull String workerIdentifier,
@NonNull ShardRecordProcessorFactory shardRecordProcessorFactory) {
this.appStreamTracker = Either.right(streamName);
this.applicationName = applicationName;
this.kinesisClient = kinesisClient;
this.dynamoDBClient = dynamoDBClient;
this.cloudWatchClient = cloudWatchClient;
this.workerIdentifier = workerIdentifier;
this.shardRecordProcessorFactory = shardRecordProcessorFactory;
}
```
Oder Sie können ConfigsBuilder mit initialisieren, `MultiStreamTracker` wenn Sie eine KCL-Consumer-Anwendung implementieren möchten, die mehrere Streams gleichzeitig verarbeitet.
```
* Constructor to initialize ConfigsBuilder with MultiStreamTracker
* @param multiStreamTracker
* @param applicationName
* @param kinesisClient
* @param dynamoDBClient
* @param cloudWatchClient
* @param workerIdentifier
* @param shardRecordProcessorFactory
*/
public ConfigsBuilder(@NonNull MultiStreamTracker multiStreamTracker, @NonNull String applicationName,
@NonNull KinesisAsyncClient kinesisClient, @NonNull DynamoDbAsyncClient dynamoDBClient,
@NonNull CloudWatchAsyncClient cloudWatchClient, @NonNull String workerIdentifier,
@NonNull ShardRecordProcessorFactory shardRecordProcessorFactory) {
this.appStreamTracker = Either.left(multiStreamTracker);
this.applicationName = applicationName;
this.kinesisClient = kinesisClient;
this.dynamoDBClient = dynamoDBClient;
this.cloudWatchClient = cloudWatchClient;
this.workerIdentifier = workerIdentifier;
this.shardRecordProcessorFactory = shardRecordProcessorFactory;
}
```
+ Da die Multistream-Unterstützung für Ihre KCL-Konsumentenanwendung implementiert ist, enthält jede Zeile der Leasetabelle der Anwendung jetzt die Shard-ID und den Stream-Namen der mehreren Datenströme, die diese Anwendung verarbeitet.
+ Wenn die Multistream-Unterstützung für Ihre KCL-Konsumentenanwendung implementiert ist, hat der leaseKey die folgende Struktur: `account-id:StreamName:streamCreationTimestamp:ShardId`. Beispiel, `111111111:multiStreamTest-1:12345:shardId-000000000336`.
**Wichtig**
Wenn Ihre vorhandene KCL-Konsumentenanwendung so konfiguriert ist, dass sie nur einen Datenstrom verarbeitet, ist der leaseKey (der Hash-Schlüssel für die Leasetabelle) die Shard-ID. Wenn Sie diese vorhandene KCL-Konsumentenanwendung für die Verarbeitung mehrerer Datenströme neu konfigurieren, wird Ihre Leasetabelle beschädigt, da bei Multistream-Unterstützung die leaseKey-Struktur wie folgt aussehen muss: `account-id:StreamName:StreamCreationTimestamp:ShardId`.
## Verwenden Sie die KCL mit der Schema Registry AWS Glue
Sie können Ihre Kinesis-Datenströme in die AWS Glue Schema Registry integrieren. Mit der AWS Glue Schema Registry können Sie Schemas zentral erkennen, steuern und weiterentwickeln und gleichzeitig sicherstellen, dass die erstellten Daten kontinuierlich anhand eines registrierten Schemas validiert werden. Ein Schema definiert die Struktur und das Format eines Datensatzes. Ein Schema ist eine versionierte Spezifikation für zuverlässige Datenveröffentlichung, -nutzung oder -speicherung. Mit der AWS Glue Schema Registry können Sie die end-to-end Datenqualität und Datenverwaltung in Ihren Streaming-Anwendungen verbessern. Weitere Informationen finden Sie unter [AWS Glue Schema Registry](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html). Eine Möglichkeit, diese Integration einzurichten, ist die KCL in Java.
**Wichtig**
Derzeit wird die Integration von Kinesis Data Streams und AWS Glue Schema Registry nur für Kinesis-Datenstreams unterstützt, die in Java implementierte KCL 2.3-Consumer verwenden. Mehrsprachige Unterstützung wird nicht bereitgestellt. KCL-1.0-Konsumenten werden nicht unterstützt. KCL-2.x-Konsumenten vor KCL 2.3 werden nicht unterstützt.
Detaillierte Anweisungen zur Einrichtung der Integration von Kinesis Data Streams mit Schema Registry mithilfe der KCL finden Sie im Abschnitt „Interaktion mit Daten mithilfe der KPL/KCL Bibliotheken“ unter [Anwendungsfall: Integration von Amazon Kinesis Data Streams mit der AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/schema-registry-integrations.html#schema-registry-integrations-kds) Schema Registry.
# Entwickeln Sie benutzerdefinierte Verbraucher mit gemeinsamem Durchsatz
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Wenn Sie keinen spezifischen Durchsatz beim Empfangen von Daten von Kinesis Data Streams und keine Verbreitungswerte für Leseoperationen von unter 200 ms benötigen, können Sie Konsumentenanwendungen wie in den folgenden Themen beschrieben erstellen. Sie können die Kinesis Client Library (KCL) oder die verwenden. AWS SDK für Java
**Topics**
+ [
# Entwickeln Sie mithilfe von KCL benutzerdefinierte Verbraucher mit gemeinsamem Durchsatz
](custom-kcl-consumers.md)
Für Informationen zum Erstellen von Verbrauchern, die Datensätze aus Kinesis-Datenströmen mit dediziertem Durchsatz empfangen können, siehe [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md).
# Entwickeln Sie mithilfe von KCL benutzerdefinierte Verbraucher mit gemeinsamem Durchsatz
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Eine der Methoden zur Entwicklung einer benutzerdefinierten Verbraucheranwendung mit gemeinsamem Durchsatz ist die Verwendung der Kinesis Client Library (KCL).
Wählen Sie eines der folgenden Themen für die KCL-Version, die Sie verwenden.
**Topics**
+ [
# Entwickeln Sie KCL 1.x-Verbraucher
](developing-consumers-with-kcl.md)
+ [
# Entwickeln Sie KCL 2.x-Verbraucher
](developing-consumers-with-kcl-v2.md)
# Entwickeln Sie KCL 1.x-Verbraucher
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird am 30. Januar 2026 end-of-support verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können eine Verbraucheranwendung für Amazon Kinesis Data Streams entwickeln, indem Sie die Kinesis Client Library (KCL) verwenden.
Weitere Informationen zu KCL finden Sie unter [Über KCL (frühere Versionen)](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-overview).
Wählen Sie je nach der Option, die Sie verwenden möchten, aus den folgenden Themen.
**Topics**
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in Java
](kinesis-record-processor-implementation-app-java.md)
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in Node.js
](kinesis-record-processor-implementation-app-nodejs.md)
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in .NET
](kinesis-record-processor-implementation-app-dotnet.md)
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in Python
](kinesis-record-processor-implementation-app-py.md)
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in Ruby
](kinesis-record-processor-implementation-app-ruby.md)
# Entwickeln Sie einen Kinesis Client Library-Consumer in Java
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Kinesis Client Library (KCL) verwenden, um Anwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten. Die Kinesis Client Library ist in mehreren Sprachen verfügbar. In diesem Thema wird Java behandelt. [Die Javadoc-Referenz finden Sie im Javadoc-Thema für Class.AWS AmazonKinesisClient](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/kinesis/AmazonKinesisClient.html)
Gehen Sie zur [Kinesis Client Library (Java) GitHub, um die Java-KCL](https://github.com/awslabs/amazon-kinesis-client) von herunterzuladen. Um die Java KCL auf Apache Maven zu finden, navigieren Sie zur Seite für die [KCL-Suchergebnisse](https://search.maven.org/#search|ga|1|amazon-kinesis-client). Um Beispielcode für eine Java-KCL-Verbraucheranwendung herunterzuladen GitHub, gehen Sie auf die Projektseite [KCL for Java-Beispielprojekt unter](https://github.com/aws/aws-sdk-java/tree/master/src/samples/AmazonKinesis). GitHub
Die Beispielanwendung verwendet [Apache Commons Logging](http://commons.apache.org/proper/commons-logging/guide.html). Sie können die Konfiguration der Protokollierung in der statischen Methode `configure` ändern, die in der Datei `AmazonKinesisApplicationSample.java` definiert ist. *Weitere Informationen zur Verwendung von Apache Commons Logging mit Log4j und AWS Java-Anwendungen finden Sie unter [Logging with Log4j](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-logging.html) im Developer Guide.AWS SDK für Java *
Sie müssen die folgenden Aufgaben durchführen, wenn Sie eine KCL-Konsumentenanwendung in Java implementieren:
**Topics**
+ [
## Implementieren Sie die Methoden des Prozessors IRecord
](#kinesis-record-processor-implementation-interface-java)
+ [
## Implementieren Sie eine Klassenfabrik für die IRecord Prozessorschnittstelle
](#kinesis-record-processor-implementation-factory-java)
+ [
## Erstellen Sie einen Worker
](#kcl-java-worker)
+ [
## Ändern Sie die Konfigurationseigenschaften
](#kinesis-record-processor-initialization-java)
+ [
## Migrieren Sie zu Version 2 der Record Processor-Schnittstelle
](#kcl-java-v2-migration)
## Implementieren Sie die Methoden des Prozessors IRecord
Die KCL unterstützt zurzeit zwei Versionen der `IRecordProcessor`-Schnittstelle: die ursprüngliche Schnittstelle, die mit der ersten Version der KCL verfügbar war, und Version 2, die ab KCL Version 1.5.0 verfügbar ist. Beide Schnittstellen werden vollständig unterstützt. Ihre Wahl hängt von den speziellen Anforderungen Ihres Anwendungsfalls ab. Um mehr über Unterschiede zu erfahren, betrachten Sie die lokal entwickelten Javadocs oder den Quellcode. In den folgenden Abschnitten wird die Mindestimplementierung für die ersten Schritte beschrieben.
**Topics**
+ [
### Ursprüngliche Schnittstelle (Version 1)
](#kcl-java-interface-original)
+ [
### Aktualisierte Schnittstelle (Version 2)
](#kcl-java-interface-v2)
### Ursprüngliche Schnittstelle (Version 1)
Die ursprüngliche `IRecordProcessor` Schnittstelle (`package com.amazonaws.services.kinesis.clientlibrary.interfaces`) stellt die folgenden Datensatzverarbeitermethoden bereit, die Ihr Konsument implementieren muss. Das Beispiel stellt Implementierungen bereit, die Sie als Ausgangspunkt verwenden können (siehe `AmazonKinesisApplicationSampleRecordProcessor.java`).
```
public void initialize(String shardId)
public void processRecords(List records, IRecordProcessorCheckpointer checkpointer)
public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason reason)
```
**initialize**
Die KCL ruft die Methode `initialize` auf, wenn der Datensatzverarbeiter instanziiert wird, und übergibt eine spezifische Shard-ID als Parameter. Dieser Datensatzverarbeiter verarbeitet nur diese Shard und in der Regel ist dies auch umgekehrt der Fall (diese Shard wird nur durch diesen Datensatverarbeiter verarbeitet). Ihr Konsument sollte jedoch die Möglichkeit berücksichtigen, dass ein Datensatz mehr als einmal verarbeitet werden könnte. Kinesis Data Streams besitzt eine Semantik nach dem Grundsatz *mindestens einmal*. Das bedeutet, dass jeder Datensatz aus einer Shard mindestens einmal von einem Worker in Ihrem Konsumenten verarbeitet wird. Weitere Informationen zu Fällen, in denen eine bestimmte Shard möglicherweise durch mehr als einen Auftragnehmer verarbeitet wird, finden Sie unter [Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern](kinesis-record-processor-scaling.md).
```
public void initialize(String shardId)
```
**processRecords**
Die KCL ruft die Methode `processRecords` auf und übergibt eine Liste der Datensätze aus der Shard, die von der Methode `initialize(shardId)` angegeben wird. Der Datensatzverarbeiter verarbeitet die Daten in diesen Datensätzen entsprechend der Semantik des Konsumenten. Beispielsweise kann der Auftragnehmer eine Transformation für die Daten ausführen und das Ergebnis dann in einem Amazon Simple Storage Service (Amazon S3)-Bucket speichern.
```
public void processRecords(List records, IRecordProcessorCheckpointer checkpointer)
```
Zusätzlich zu den Daten selbst enthält der Datensatz auch eine Sequenznummer und einen Partitionsschlüssel. Der Auftragnehmer kann diese Werte beim Verarbeiten der Daten verwenden. Beispielsweise könnte der Auftragnehmer basierend auf dem Wert des Partitionsschlüssels den S3-Bucket wählen, in dem die Daten gespeichert werden sollen. Die Klasse `Record` stellt die folgenden Methoden bereit, die Zugriff auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel bieten.
```
record.getData()
record.getSequenceNumber()
record.getPartitionKey()
```
In diesem Beispiel weist die private Methode `processRecordsWithRetries` Code auf, der zeigt, wie ein Auftragnehmer auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel zugreifen kann.
Kinesis Data Streams erfordert, dass der Datensatzverarbeiter die Datensätze nachverfolgt, die bereits in einer Shard verarbeitet wurden. Die KCL übernimmt diese Nachverfolgung für Sie, indem ein Checkpointer (`IRecordProcessorCheckpointer`) an `processRecords` übergeben wird. Der Datensatzverarbeiter ruft die Methode `checkpoint` auf dieser Schnittstelle auf, um die KCL über die Fortschritte zu informieren, die sie beim Verarbeiten der Datensätze in der Shard gemacht hat. Wenn der Auftragnehmer fehlschlägt, verwendet die KCL diese Informationen, um die Verarbeitung der Shard mit dem letzten bekannten Datensatz neu zu starten.
Im Fall einer Teilungs- oder Zusammenführungsoperation beginnt die KCL erst dann mit der Verarbeitung der neuen Shards, wenn die Verarbeiter für die ursprünglichen Shards `checkpoint` aufgerufen haben, um zu signalisieren, dass die Verarbeitung der ursprünglichen Shards vollständig abgeschlossen ist.
Wenn Sie keinen Parameter übergeben, nimmt die KCL an, dass der Aufruf von `checkpoint` bedeutet, dass alle Datensätze bis zum letzten Datensatz, der an den Datensatzverarbeiter übergeben wurde, verarbeitet wurden. Daher sollte der Datensatzverarbeiter die Methode `checkpoint` erst aufrufen, wenn er alle Datensätze in der Liste, die ihm übergeben wurden, verarbeitet hat. Datensatzverarbeiter müssen `checkpoint` nicht bei jedem Aufruf von `processRecords` aufrufen. Ein Prozessor könnte beispielsweise `checkpoint` bei jedem dritten Aufruf von `processRecords` aufrufen. Sie können optional die exakte Sequenznummer eines Datensatzes als Parameter für `checkpoint` angeben. In diesem Fall nimmt die KCL an, dass alle Datensätze nur bis zu diesem Datensatz verarbeitet wurden.
Im Beispiel zeigt die private Methode `checkpoint`, wie `IRecordProcessorCheckpointer.checkpoint` mithilfe der entsprechenden Ausnahmebehandlung und Wiederholungslogik aufgerufen wird.
Die KCL ist bei der Behandlung von Ausnahmen, die während der Verarbeitung der Datensätze auftreten, von `processRecords` abhängig. Wenn `processRecords` eine Ausnahme aufwirft, überspringt die KCL die Datensätze, die vor der Ausnahme übergeben wurden. Das heißt, diese Datensätze werden nicht erneut an den Datensatzprozessor gesendet, der die Ausnahme ausgelöst hat, oder an einen anderen Datensatzprozessor im Verbraucher.
**shutdown**
Die KCL ruft die Methode `shutdown` entweder auf, wenn die Verarbeitung beendet wird (Grund für das Herunterfahren ist `TERMINATE`) oder wenn der Auftragnehmer nicht mehr reagiert (Grund für das Herunterfahren ist `ZOMBIE`).
```
public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason reason)
```
Die Verarbeitung endet, wenn der Datensatzverarbeiter keine weiteren Datensätze aus der Shard erhält, entweder weil die Shard geteilt oder zusammengeführt wurde oder weil der Stream gelöscht wurde.
Die KCL übergibt auch eine `IRecordProcessorCheckpointer`-Schnittstelle an `shutdown`. Wenn der Grund für das Herunterfahren `TERMINATE` ist, sollte der Datensatzverarbeiter alle Datensätze fertigstellen und dann die Methode `checkpoint` in seiner Schnittstelle aufrufen.
### Aktualisierte Schnittstelle (Version 2)
Die aktualisierte `IRecordProcessor` Schnittstelle (`package com.amazonaws.services.kinesis.clientlibrary.interfaces.v2`) stellt die folgenden Datensatzverarbeitermethoden bereit, die Ihr Konsument implementieren muss:
```
void initialize(InitializationInput initializationInput)
void processRecords(ProcessRecordsInput processRecordsInput)
void shutdown(ShutdownInput shutdownInput)
```
Sie können auf alle Argumente aus der ursprünglichen Version der Schnittstelle über Get-Methoden für die Container-Objekte zugreifen. Um die Liste der Datensätze in `processRecords()` abzurufen, können Sie `processRecordsInput.getRecords()` verwenden.
Ab Version 2 dieser Schnittstelle (KCL 1.5.0 und höher) sind zusätzlich zu den Eingaben durch die ursprüngliche Schnittstelle die folgenden neuen Eingaben verfügbar:
Startsequenznummer
Im `InitializationInput`-Objekt, das an die Operation `initialize()` übergeben wird, die Startsequenznummer, aus der Datensätze für die Datenverarbeiter-Instance bereitgestellt würden. Dies ist die Sequenznummer, die zuletzt durch die Datensatzverarbeiter-Instance überprüft wurde, die dieselbe Shard zuvor verarbeitet hat. Sie wird für den Fall angegeben, dass Ihre Anwendung diese Informationen benötigt.
Ausstehende Checkpoint-Sequenznummer
Im `InitializationInput`-Objekt, das an die Operation `initialize()` übergeben wird, die ausstehende Checkpoint-Sequenznummer (wenn vorhanden), die nicht übergeben werden konnte, bevor die vorherige Datensatzverarbeiter-Instance angehalten wurde.
## Implementieren Sie eine Klassenfabrik für die IRecord Prozessorschnittstelle
Sie müssen darüber hinaus eine Factory für die Klasse implementieren, die die Datensatzverarbeitermethoden implementiert. Wenn der Konsument den Auftragnehmer instanziiert, übergibt er dieser Factory eine Referenz.
Im Beispiel wird die Factory-Klasse in der Datei `AmazonKinesisApplicationSampleRecordProcessorFactory.java` mithilfe der ursprünglichen Datensatzverarbeiter-Schnittstelle implementiert. Wenn Sie möchten, dass die Class Factory Datensatzverarbeiter mit Version 2 erstellt, verwenden Sie den Paketnamen `com.amazonaws.services.kinesis.clientlibrary.interfaces.v2`.
```
public class SampleRecordProcessorFactory implements IRecordProcessorFactory {
/**
* Constructor.
*/
public SampleRecordProcessorFactory() {
super();
}
/**
* {@inheritDoc}
*/
@Override
public IRecordProcessor createProcessor() {
return new SampleRecordProcessor();
}
}
```
## Erstellen Sie einen Worker
Wie in [Implementieren Sie die Methoden des Prozessors IRecord](#kinesis-record-processor-implementation-interface-java) beschrieben, gibt es zwei Versionen der KCL-Datensatzverarbeiterschnittstelle zur Auswahl. Die Version hat Auswirkungen auf die Art, wie Sie einen Worker erstellen. Die ursprüngliche Datensatzverarbeiterschnittstelle verwendet die folgende Codestruktur, um einen Auftragnehmer zu erstellen:
```
final KinesisClientLibConfiguration config = new KinesisClientLibConfiguration(...)
final IRecordProcessorFactory recordProcessorFactory = new RecordProcessorFactory();
final Worker worker = new Worker(recordProcessorFactory, config);
```
Mit Version 2 der Datensatzverarbeiterschnittstelle können Sie `Worker.Builder` verwenden, um einen Auftragnehmer zu erstellen, ohne sich Gedanken über den Konstruktor und die Reihenfolge der Argumente zu machen. Die aktualisierte Datensatzverarbeiterschnittstelle verwendet die folgende Codestruktur, um einen Auftragnehmer zu erstellen:
```
final KinesisClientLibConfiguration config = new KinesisClientLibConfiguration(...)
final IRecordProcessorFactory recordProcessorFactory = new RecordProcessorFactory();
final Worker worker = new Worker.Builder()
.recordProcessorFactory(recordProcessorFactory)
.config(config)
.build();
```
## Ändern Sie die Konfigurationseigenschaften
Das Beispiel zeigt Standardwerte für Konfigurationseigenschaften. Diese Konfigurationsdaten für den Auftragnehmer werden anschließend in einem `KinesisClientLibConfiguration`-Objekt konsolidiert. Dieses Objekt und eine Referenz auf die Class Factory für `IRecordProcessor` werden an den Aufruf übergeben, der den Auftragnehmer instanziiert. Sie können diese Eigenschaften mithilfe einer Java-Eigenschaftendatei (siehe `AmazonKinesisApplicationSample.java`) durch eigene Werte überschreiben.
### Anwendungsname
Die KCL erfordert einen Anwendungsnamen, der unter Ihren Anwendungen sowie den Amazon-DynamoDB-Tabellen in derselben Region eindeutig ist. Sie verwendet den Wert der Anwendungsnamenkonfiguration auf folgende Arten:
+ Für mit diesem Anwendungsnamen verknüpfte Auftragnehmer wird angenommen, dass sie gemeinsam im gleichen Stream arbeiten. Diese Auftragnehmer können auf mehrere Instances verteilt sein. Wenn Sie eine zusätzliche Instance desselben Anwendungscodes ausführen, jedoch mit einem anderen Anwendungsnamen, behandelt die KCL die zweite Instance als eine völlig getrennte Anwendung, die ebenfalls im selben Stream arbeitet.
+ Die KCL erstellt eine DynamoDB-Tabelle mit dem Namen der Anwendung und verwendet die Tabelle für die Verwaltung von Statusinformationen für die Anwendung (wie Checkpoints und Auftragnehmer-Shard-Zuweisungen). Jede Anwendung verfügt über eine eigene DynamoDB-Tabelle. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
### Richten Sie Anmeldeinformationen ein
Sie müssen Ihre AWS Anmeldeinformationen einem der Anmeldeinformationsanbieter in der Kette der Standardanmeldedienstanbieter zur Verfügung stellen. Wenn Sie beispielsweise Ihren Konsumenten auf einer EC2-Instance ausführen, empfehlen wir, die Instance mit einer IAM-Rolle zu starten. AWS -Anmeldeinformationen, die die mit dieser IAM-Rolle verknüpften Berechtigungen widerspiegeln, werden den Anwendungen auf der Instance über deren Instance-Metadaten zur Verfügung gestellt. Dies ist die sicherste Art, Anmeldeinformationen für einen Konsumenten zu verwalten, der auf einer EC2-Instance ausgeführt wird.
Die Beispielanwendung versucht zunächst, IAM-Anmeldeinformationen aus den Instance-Metadaten abzurufen:
```
credentialsProvider = new InstanceProfileCredentialsProvider();
```
Wenn die Beispielanwendung keine Anmeldeinformationen aus den Instance-Metadaten abrufen kann, versucht sie, Anmeldeinformationen aus einer Eigenschaftendatei abzurufen:
```
credentialsProvider = new ClasspathPropertiesFileCredentialsProvider();
```
Weitere Informationen zu Instance-Metadaten finden Sie unter [Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
### Verwenden Sie die Worker-ID für mehrere Instances
Derselbe Initialisierungscode erstellt unter Verwendung des Namens des lokalen Computers und Anfügung eines global eindeutigen Bezeichners eine ID für den Auftragnehmer, `workerId`, wie im folgenden Codeauszug gezeigt. Dieser Ansatz unterstützt das Szenario mit mehreren Instances der Konsumentenanwendung, die auf einem einzigen Computer ausgeführt werden.
```
String workerId = InetAddress.getLocalHost().getCanonicalHostName() + ":" + UUID.randomUUID();
```
## Migrieren Sie zu Version 2 der Record Processor-Schnittstelle
Wenn Sie Code migrieren möchten, der die ursprüngliche Schnittstelle verwendet, sind zusätzlich zu den zuvor beschriebenen Schritten die folgenden Schritte erforderlich:
1. Ändern der Datensatzverarbeiterklasse, um Version 2 der Datensatzverarbeiterschnittstelle zu importieren:
```
import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor;
```
1. Ändern der Referenzen zu Eingaben, um `get`-Methoden für die Container-Objekte zu verwenden. In der Operation `shutdown()` ändern Sie beispielsweise „`checkpointer`“ in „`shutdownInput.getCheckpointer()`“.
1. Ändern der Datensatzverarbeiter-Factory, um Version 2 der Datensatzverarbeiter-Factory zu importieren:
```
import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessorFactory;
```
1. Ändern der Konstruktion für den Auftragnehmer, um `Worker.Builder` zu verwenden. Beispiel:
```
final Worker worker = new Worker.Builder()
.recordProcessorFactory(recordProcessorFactory)
.config(config)
.build();
```
# Entwickeln Sie einen Kinesis Client Library-Consumer in Node.js
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Kinesis Client Library (KCL) verwenden, um Anwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten. Die Kinesis Client Library ist in mehreren Sprachen verfügbar. In diesem Thema wird Node.js behandelt.
Die KCL ist eine Java-Bibliothek. Unterstützung für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle bereitgestellt, die als. *MultiLangDaemon* Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine andere KCL-Sprache als Java verwenden. Wenn Sie also die KCL für Node.js installieren und Ihre App für Privatanwender vollständig in Node.js schreiben, müssen Sie trotzdem Java auf Ihrem System installieren, und zwar aufgrund der. MultiLangDaemon Darüber hinaus MultiLangDaemon verfügt es über einige Standardeinstellungen, die Sie möglicherweise an Ihren Anwendungsfall anpassen müssen, z. B. die AWS Region, mit der eine Verbindung hergestellt wird. Weitere Informationen dazu finden Sie MultiLangDaemon auf GitHub der [ MultiLangDaemon KCL-Projektseite](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang).
Um die Node.js KCL von herunterzuladen GitHub, gehen Sie zur [Kinesis Client Library (Node.js)](https://github.com/awslabs/amazon-kinesis-client-nodejs).
**Downloads von Beispiel-Code**
Es gibt zwei Code-Beispiele für die KCL in Node.js:
+ [basic-sample](https://github.com/awslabs/amazon-kinesis-client-nodejs/tree/master/samples/basic_sample)
Wird in den folgenden Abschnitten verwendet, um die Grundlagen zum Erstellen einer KCL-Konsumentenanwendung in Node.js zu zeigen.
+ [click-stream-sample](https://github.com/awslabs/amazon-kinesis-client-nodejs/tree/master/samples/click_stream_sample)
Etwas komplexere und verwendet ein reales Szenario, nachdem Sie sich mit dem grundlegenden Beispiel-Code vertraut gemacht haben. Dieses Beispiel wird hier nicht behandelt. Es gibt jedoch eine Readme-Datei mit weiteren Informationen.
Sie müssen die folgenden Aufgaben durchführen, wenn Sie eine KCL-Konsumentenanwendung in Node.js implementieren:
**Topics**
+ [
## Implementieren Sie den Record Processor
](#kinesis-record-processor-implementation-interface-nodejs)
+ [
## Ändern Sie die Konfigurationseigenschaften
](#kinesis-record-processor-initialization-nodejs)
## Implementieren Sie den Record Processor
Der einfachste Konsument, der die KCL für Node.js verwenden kann, muss die Funktion `recordProcessor` implementieren. Diese enthält wiederum die Funktionen `initialize`, `processRecords`, und `shutdown`. Das Beispiel zeigt eine Implementierung, die Sie als Ausgangspunkt verwenden können (siehe `sample_kcl_app.js`).
```
function recordProcessor() {
// return an object that implements initialize, processRecords and shutdown functions.}
```
**initialize**
Die KCL ruft die Funktion `initialize` auf, wenn der Datensatzverarbeiter gestartet wird. Dieser Datensatzverarbeiter verarbeitet nur die Shard-ID, die als `initializeInput.shardId` übergeben wird. In der Regel ist dies auch umgekehrt der Fall (diese Shard wird nur durch diesen Datensatverarbeiter verarbeitet). Ihr Konsument sollte jedoch die Möglichkeit berücksichtigen, dass ein Datensatz mehr als einmal verarbeitet werden könnte. Das liegt daran, dass Kinesis Data Streams eine Semantik nach dem Grundsatz *mindestens einmal* hat. Das bedeutet, dass jeder Datensatz aus einer Shard mindestens einmal von einem Worker in Ihrem Konsumenten verarbeitet wird. Weitere Informationen zu Fällen, in denen eine bestimmte Shard möglicherweise durch mehr als einen Auftragnehmer verarbeitet wird, finden Sie unter [Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern](kinesis-record-processor-scaling.md).
```
initialize: function(initializeInput, completeCallback)
```
**processRecords**
Die KCL ruft diese Funktion mit einer Eingabe auf, die eine Liste von Datensätzen aus der für die Funktion `initialize` angegebenen Shard enthält. Der von Ihnen implementierte Datensatzverarbeiter verarbeitet die Daten in diesen Datensätzen entsprechend der Semantik Ihres Konsumenten. Beispielsweise kann der Auftragnehmer eine Transformation für die Daten ausführen und das Ergebnis dann in einem Amazon Simple Storage Service (Amazon S3)-Bucket speichern.
```
processRecords: function(processRecordsInput, completeCallback)
```
Zusätzlich zu den Daten enthält der Datensatz auch eine Sequenznummer und einen Partitionsschlüssel, die der Auftragnehmer beim Verarbeiten der Daten verwenden kann. Beispielsweise könnte der Auftragnehmer basierend auf dem Wert des Partitionsschlüssels den S3-Bucket wählen, in dem die Daten gespeichert werden sollen. Das `record`-Anmeldeverzeichnis stellt die folgenden Schlüssel-Wert-Paare für den Zugriff auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel bereit:
```
record.data
record.sequenceNumber
record.partitionKey
```
Beachten Sie, dass die Daten Base64-kodiert sind.
Im einfachen Beispiel weist die Funktion `processRecords` Code auf, der zeigt, wie ein Auftragnehmer auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel zugreifen kann.
Kinesis Data Streams erfordert, dass der Datensatzverarbeiter die Datensätze nachverfolgt, die bereits in einer Shard verarbeitet wurden. Die KCL übernimmt die Nachverfolgung durch ein `checkpointer`-Objekt, das als `processRecordsInput.checkpointer` übergeben wird. Der Datensatzverarbeiter ruft die Funktion `checkpointer.checkpoint` auf, um die KCL über die Fortschritte zu informieren, die er beim Verarbeiten der Datensätze in der Shard gemacht hat. Wenn der Auftragnehmer fehlschlägt, verwendet die KCL diese Informationen, wenn Sie die Verarbeitung der Shard erneut starten, damit sie den Vorgang ab dem letzten bekannten Datensatz fortsetzt.
Im Fall einer Teilungs- oder Zusammenführungsoperation beginnt die KCL erst dann mit der Verarbeitung der neuen Shards, wenn die Verarbeiter für die ursprünglichen Shards `checkpoint` aufgerufen haben, um zu signalisieren, dass die Verarbeitung der ursprünglichen Shards vollständig abgeschlossen ist.
Wenn Sie die Sequenznummer nicht an die `checkpoint`-Funktion übergeben, nimmt die KCL an, dass der Aufruf von `checkpoint` bedeutet, dass alle Datensätze bis zum letzten Datensatz, der an den Datensatzverarbeiter übergeben wurde, verarbeitet wurden. Daher sollte der Datensatzverarbeiter die Methode `checkpoint` **erst** aufrufen, wenn er alle Datensätze in der Liste, die ihm übergeben wurden, verarbeitet hat. Datensatzverarbeiter müssen `checkpoint` nicht bei jedem Aufruf von `processRecords` aufrufen. Ein Prozessor könnte beispielsweise bei jedem dritten Anruf oder `checkpoint` bei einem Ereignis außerhalb Ihres Aufzeichnungsprozessors, z. B. bei einem benutzerdefinierten verification/validation Dienst, den Sie implementiert haben, aufrufen.
Sie können optional die exakte Sequenznummer eines Datensatzes als Parameter für `checkpoint` angeben. In diesem Fall nimmt die KCL an, dass alle Datensätze nur bis zu diesem Datensatz verarbeitet wurden.
Die einfache Beispielanwendung zeigt den einfachsten möglichen Aufruf der Funktion `checkpointer.checkpoint`. Sie können weitere Checkpoint-Logik hinzufügen, die Sie an diesem Punkt in der Funktion für Ihren Konsumenten benötigen.
**shutdown**
Die KCL ruft die Funktion `shutdown` entweder auf, wenn die Verarbeitung beendet wird (`shutdownInput.reason` ist `TERMINATE`) oder wenn der Auftragnehmer nicht mehr reagiert (`shutdownInput.reason` ist `ZOMBIE`).
```
shutdown: function(shutdownInput, completeCallback)
```
Die Verarbeitung endet, wenn der Datensatzverarbeiter keine weiteren Datensätze aus der Shard erhält, entweder weil die Shard geteilt oder zusammengeführt wurde oder weil der Stream gelöscht wurde.
Die KCL übergibt auch ein `shutdownInput.checkpointer`-Objekt an `shutdown`. Wenn der Grund für das Herunterfahren `TERMINATE` ist, sollten Sie sicherstellen, dass der Datensatzverarbeiter die Verarbeitung aller Datensätze fertiggestellt hat, und dann die Funktion `checkpoint` in seiner Schnittstelle aufrufen.
## Ändern Sie die Konfigurationseigenschaften
Das Beispiel zeigt Standardwerte für die Konfigurationseigenschaften. Sie können diese Eigenschaften mit eigenen Werten überschreiben (siehe `sample.properties` im einfachen Beispiel).
### Anwendungsname
Die KCL erfordert eine Anwendung, die unter Ihren Anwendungen sowie den Amazon-DynamoDB-Tabellen in derselben Region eindeutig ist. Sie verwendet den Wert der Anwendungsnamenkonfiguration auf folgende Arten:
+ Für mit diesem Anwendungsnamen verknüpfte Auftragnehmer wird angenommen, dass sie gemeinsam im gleichen Stream arbeiten. Diese Auftragnehmer können auf mehrere Instances verteilt sein. Wenn Sie eine zusätzliche Instance desselben Anwendungscodes ausführen, jedoch mit einem anderen Anwendungsnamen, behandelt die KCL die zweite Instance als eine völlig getrennte Anwendung, die ebenfalls im selben Stream arbeitet.
+ Die KCL erstellt eine DynamoDB-Tabelle mit dem Namen der Anwendung und verwendet die Tabelle für die Verwaltung von Statusinformationen für die Anwendung (wie Checkpoints und Auftragnehmer-Shard-Zuweisungen). Jede Anwendung verfügt über eine eigene DynamoDB-Tabelle. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
### Richten Sie Anmeldeinformationen ein
Sie müssen Ihre AWS Anmeldeinformationen einem der Anmeldeinformationsanbieter in der Kette der Standardanmeldedienstanbieter zur Verfügung stellen. Sie können die Eigenschaft `AWSCredentialsProvider` verwenden, um einen Anmeldeinformationsanbieter einzurichten. Die `sample.properties`-Datei muss Anmeldeinformationen einem der Anmeldeinformationsanbieter in der [Anmeldeinformationsanbieter-Standardkette](https://docs.aws.amazon.com/sdk-for-java/latest/reference/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html) bereitstellen. Wenn Sie Ihren Consumer auf einer Amazon EC2 EC2-Instance ausführen, empfehlen wir Ihnen, die Instance mit einer IAM-Rolle zu konfigurieren. AWS Anmeldeinformationen, die die mit dieser IAM-Rolle verknüpften Berechtigungen widerspiegeln, werden Anwendungen auf der Instance über deren Instance-Metadaten zur Verfügung gestellt. Dies ist die sicherste Art, Anmeldeinformationen für eine Konsumentenanwendung zu verwalten, die auf einer EC2-Instance ausgeführt wird.
Im folgenden Beispiel wird eine KCL konfiguriert, um einen Kinesis-Datenstrom namens `kclnodejssample` mittels des Datensatzverarbeiters zu verarbeiten, der in `sample_kcl_app.js` bereitgestellt wird:
```
# The Node.js executable script
executableName = node sample_kcl_app.js
# The name of an Amazon Kinesis stream to process
streamName = kclnodejssample
# Unique KCL application name
applicationName = kclnodejssample
# Use default AWS credentials provider chain
AWSCredentialsProvider = DefaultAWSCredentialsProviderChain
# Read from the beginning of the stream
initialPositionInStream = TRIM_HORIZON
```
# Entwickeln Sie einen Kinesis Client Library-Consumer in .NET
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Kinesis Client Library (KCL) verwenden, um Anwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten. Die Kinesis Client Library ist in mehreren Sprachen verfügbar. In diesem Thema wird .NET behandelt.
Die KCL ist eine Java-Bibliothek. Unterstützung für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle bereitgestellt, die als. *MultiLangDaemon* Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine andere KCL-Sprache als Java verwenden. Wenn Sie also die KCL für .NET installieren und Ihre Consumer-App vollständig in .NET schreiben, müssen Sie trotzdem Java auf Ihrem System installieren, da MultiLangDaemon Darüber hinaus MultiLangDaemon verfügt es über einige Standardeinstellungen, die Sie möglicherweise an Ihren Anwendungsfall anpassen müssen, z. B. die AWS Region, mit der eine Verbindung hergestellt wird. Weitere Informationen dazu finden Sie MultiLangDaemon auf GitHub der [ MultiLangDaemon KCL-Projektseite](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang).
Gehen Sie zur [Kinesis Client Library (.NET) GitHub, um die.NET-KCL](https://github.com/awslabs/amazon-kinesis-client-net) von herunterzuladen. Um Beispielcode für eine.NET-KCL-Consumer-Anwendung herunterzuladen, rufen Sie die Projektseite [KCL for .NET-Beispielanwendung für Privatanwender](https://github.com/awslabs/amazon-kinesis-client-net/tree/master/SampleConsumer) auf. GitHub
Sie müssen die folgenden Aufgaben durchführen, wenn Sie eine KCL-Konsumentenanwendung in .NET implementieren:
**Topics**
+ [
## Implementieren Sie die Methoden der IRecord Prozessorklasse
](#kinesis-record-processor-implementation-interface-dotnet)
+ [
## Ändern Sie die Konfigurationseigenschaften
](#kinesis-record-processor-initialization-dotnet)
## Implementieren Sie die Methoden der IRecord Prozessorklasse
Der Konsument muss die folgenden Methoden für `IRecordProcessor` implementieren. Der Konsument im Beispiel stellt Implementierungen bereit, die Sie als Ausgangspunkt verwenden können (siehe die `SampleRecordProcessor`-Klasse in `SampleConsumer/AmazonKinesisSampleConsumer.cs`).
```
public void Initialize(InitializationInput input)
public void ProcessRecords(ProcessRecordsInput input)
public void Shutdown(ShutdownInput input)
```
**Initialisieren**
Die KCL ruft diese Methode auf, wenn der Datensatzverarbeiter instanziiert wird, und übergibt eine spezifische Shard-ID an den `input`-Parameter (`input.ShardId`). Dieser Datensatzverarbeiter verarbeitet nur diese Shard und in der Regel ist dies auch umgekehrt der Fall (diese Shard wird nur durch diesen Datensatverarbeiter verarbeitet). Ihr Konsument sollte jedoch die Möglichkeit berücksichtigen, dass ein Datensatz mehr als einmal verarbeitet werden könnte. Das liegt daran, dass Kinesis Data Streams eine Semantik nach dem Grundsatz *mindestens einmal* hat. Das bedeutet, dass jeder Datensatz aus einer Shard mindestens einmal von einem Worker in Ihrem Konsumenten verarbeitet wird. Weitere Informationen zu Fällen, in denen eine bestimmte Shard möglicherweise durch mehr als einen Auftragnehmer verarbeitet wird, finden Sie unter [Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern](kinesis-record-processor-scaling.md).
```
public void Initialize(InitializationInput input)
```
**ProcessRecords**
Die KCL ruft diese Methode auf und übergibt eine Liste der Datensätze an den `input`-Parameter (`input.Records`) aus der Shard, die von der Methode `Initialize` angegeben wird. Der von Ihnen implementierte Datensatzverarbeiter verarbeitet die Daten in diesen Datensätzen entsprechend der Semantik Ihres Konsumenten. Beispielsweise kann der Auftragnehmer eine Transformation für die Daten ausführen und das Ergebnis dann in einem Amazon Simple Storage Service (Amazon S3)-Bucket speichern.
```
public void ProcessRecords(ProcessRecordsInput input)
```
Zusätzlich zu den Daten selbst enthält der Datensatz auch eine Sequenznummer und einen Partitionsschlüssel. Der Auftragnehmer kann diese Werte beim Verarbeiten der Daten verwenden. Beispielsweise könnte der Auftragnehmer basierend auf dem Wert des Partitionsschlüssels den S3-Bucket wählen, in dem die Daten gespeichert werden sollen. Die Klasse `Record` stellt die folgenden Methoden bereit, die Zugriff auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel bieten:
```
byte[] Record.Data
string Record.SequenceNumber
string Record.PartitionKey
```
Im Beispiel weist die Methode `ProcessRecordsWithRetries` Code auf, der zeigt, wie ein Auftragnehmer auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel zugreifen kann.
Kinesis Data Streams erfordert, dass der Datensatzverarbeiter die Datensätze nachverfolgt, die bereits in einer Shard verarbeitet wurden. Die KCL übernimmt diese Nachverfolgung für Sie, indem ein `Checkpointer`-Objekt an `ProcessRecords` (`input.Checkpointer`) übergeben wird. Der Datensatzverarbeiter ruft die Methode `Checkpointer.Checkpoint` auf, um die KCL über die Fortschritte zu informieren, die sie beim Verarbeiten der Datensätze in der Shard gemacht hat. Wenn der Auftragnehmer fehlschlägt, verwendet die KCL diese Informationen, um die Verarbeitung der Shard mit dem letzten bekannten Datensatz neu zu starten.
Im Fall einer Teilungs- oder Zusammenführungsoperation beginnt die KCL erst dann mit der Verarbeitung der neuen Shards, wenn die Verarbeiter für die ursprünglichen Shards `Checkpointer.Checkpoint` aufgerufen haben, um zu signalisieren, dass die Verarbeitung der ursprünglichen Shards vollständig abgeschlossen ist.
Wenn Sie keinen Parameter übergeben, nimmt die KCL an, dass der Aufruf von `Checkpointer.Checkpoint` bedeutet, dass alle Datensätze bis zum letzten Datensatz, der an den Datensatzverarbeiter übergeben wurde, verarbeitet wurden. Daher sollte der Datensatzverarbeiter die Methode `Checkpointer.Checkpoint` erst aufrufen, wenn er alle Datensätze in der Liste, die ihm übergeben wurden, verarbeitet hat. Datensatzverarbeiter müssen `Checkpointer.Checkpoint` nicht bei jedem Aufruf von `ProcessRecords` aufrufen. Ein Prozessor könnte beispielsweise `Checkpointer.Checkpoint` bei jedem dritten oder vierten Aufruf aufrufen. Sie können optional die exakte Sequenznummer eines Datensatzes als Parameter für `Checkpointer.Checkpoint` angeben. In diesem Fall nimmt die KCL an, dass die Datensätze nur bis zu diesem Datensatz verarbeitet wurden.
Im Beispiel zeigt die private Methode `Checkpoint(Checkpointer checkpointer)`, wie die `Checkpointer.Checkpoint`-Methode mithilfe der entsprechenden Ausnahmebehandlung und Wiederholungslogik aufgerufen wird.
Die KCL für .NET verarbeitet Ausnahmen anders als andere KCL-Sprachbibliotheken, da sie keine Ausnahmen verarbeitet, die aus der Verarbeitung der Datensätze entstanden sind. Alle nicht abgefangenen Ausnahmen vom Benutzer-Code bringen das Programm zum Absturz.
**Herunterfahren**
Die KPL ruft die Methode `Shutdown` entweder auf, wenn die Verarbeitung beendet wird (Grund für das Herunterfahren ist `TERMINATE`) oder wenn der Auftragnehmer nicht mehr reagiert (der `input.Reason`-Wert für das Herunterfahren ist `ZOMBIE`).
```
public void Shutdown(ShutdownInput input)
```
Die Verarbeitung endet, wenn der Datensatzverarbeiter keine weiteren Datensätze aus der Shard erhält, weil die Shard geteilt oder zusammengeführt wurde oder der Stream gelöscht wurde.
Die KCL übergibt auch ein `Checkpointer`-Objekt an `shutdown`. Wenn der Grund für das Herunterfahren `TERMINATE` ist, sollte der Datensatzverarbeiter alle Datensätze fertigstellen und dann die Methode `checkpoint` in seiner Schnittstelle aufrufen.
## Ändern Sie die Konfigurationseigenschaften
Der Beispielkonsument zeigt Standardwerte für die Konfigurationseigenschaften. Sie können diese Eigenschaften mit eigenen Werten überschreiben (siehe `SampleConsumer/kcl.properties`).
### Anwendungsname
Die KCL erfordert eine Anwendung, die unter Ihren Anwendungen sowie den Amazon-DynamoDB-Tabellen in derselben Region eindeutig ist. Sie verwendet den Wert der Anwendungsnamenkonfiguration auf folgende Arten:
+ Für mit diesem Anwendungsnamen verknüpfte Auftragnehmer wird angenommen, dass sie gemeinsam im gleichen Stream arbeiten. Diese Auftragnehmer können auf mehrere Instances verteilt sein. Wenn Sie eine zusätzliche Instance desselben Anwendungscodes ausführen, jedoch mit einem anderen Anwendungsnamen, behandelt die KCL die zweite Instance als eine völlig getrennte Anwendung, die ebenfalls im selben Stream arbeitet.
+ Die KCL erstellt eine DynamoDB-Tabelle mit dem Namen der Anwendung und verwendet die Tabelle für die Verwaltung von Statusinformationen für die Anwendung (wie Checkpoints und Auftragnehmer-Shard-Zuweisungen). Jede Anwendung verfügt über eine eigene DynamoDB-Tabelle. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
### Richten Sie Anmeldeinformationen ein
Sie müssen Ihre AWS Anmeldeinformationen einem der Anmeldeinformationsanbieter in der Kette der Standardanmeldedienstanbieter zur Verfügung stellen. Sie können die Eigenschaft `AWSCredentialsProvider` verwenden, um einen Anmeldeinformationsanbieter einzurichten. Die [sample.properties](https://github.com/awslabs/amazon-kinesis-client-python/blob/master/samples/sample.properties) muss Ihre Anmeldeinformationen einem der Anmeldeinformationsanbieter in der [Anmeldeinformationsanbieter-Standardkette](https://docs.aws.amazon.com/sdk-for-java/latest/reference/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html) bereitstellen. Wenn Sie Ihre Konsumentenanwendung auf einer EC2-Instance ausführen, empfehlen wir, die Instance mit einer IAM-Rolle zu konfigurieren. AWS -Anmeldeinformationen, die die mit dieser IAM-Rolle verknüpften Berechtigungen widerspiegeln, werden den Anwendungen auf der Instance über deren Instance-Metadaten zur Verfügung gestellt. Dies ist die sicherste Art, Anmeldeinformationen für einen Konsumenten zu verwalten, der auf einer EC2-Instance ausgeführt wird.
Die Eigenschaftendatei des Beispiels konfiguriert KCL, um einen Kinesis-Datenstrom namens „words“ mittels des Datensatzverarbeiters zu verarbeiten, der in `AmazonKinesisSampleConsumer.cs` bereitgestellt wird.
# Entwickeln Sie einen Kinesis Client Library-Consumer in Python
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Kinesis Client Library (KCL) verwenden, um Anwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten. Die Kinesis Client Library ist in mehreren Sprachen verfügbar. In diesem Thema wird Python behandelt.
Die KCL ist eine Java-Bibliothek. Unterstützung für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle bereitgestellt, die als. *MultiLangDaemon* Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine andere KCL-Sprache als Java verwenden. Wenn Sie also die KCL für Python installieren und Ihre Consumer-App vollständig in Python schreiben, muss Java aufgrund der MultiLangDaemon trotzdem auf Ihrem System installiert sein. Darüber hinaus MultiLangDaemon verfügt es über einige Standardeinstellungen, die Sie möglicherweise an Ihren Anwendungsfall anpassen müssen, z. B. die AWS Region, mit der eine Verbindung hergestellt wird. Weitere Informationen dazu finden Sie MultiLangDaemon auf GitHub der [ MultiLangDaemon KCL-Projektseite](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang).
Um die Python-KCL von herunterzuladen GitHub, gehen Sie zur [Kinesis Client Library (Python)](https://github.com/awslabs/amazon-kinesis-client-python). Um Beispielcode für eine Python-KCL-Consumer-Anwendung herunterzuladen, gehen Sie zur [KCL for Python-Beispielprojektseite unter](https://github.com/awslabs/amazon-kinesis-client-python/tree/master/samples). GitHub
Sie müssen die folgenden Aufgaben durchführen, wenn Sie eine KCL-Konsumentenanwendung in Python implementieren:
**Topics**
+ [
## Implementieren Sie die Klassenmethoden RecordProcessor
](#kinesis-record-processor-implementation-interface-py)
+ [
## Ändern Sie die Konfigurationseigenschaften
](#kinesis-record-processor-initialization-py)
## Implementieren Sie die Klassenmethoden RecordProcessor
Die `RecordProcess`-Klasse muss die `RecordProcessorBase` erweitern, um die folgenden Methoden zu implementieren. Das Beispiel stellt Implementierungen bereit, die Sie als Ausgangspunkt verwenden können (siehe `sample_kclpy_app.py`).
```
def initialize(self, shard_id)
def process_records(self, records, checkpointer)
def shutdown(self, checkpointer, reason)
```
**initialize**
Die KCL ruft die Methode `initialize` auf, wenn der Datensatzverarbeiter instanziiert wird, und übergibt eine spezifische Shard-ID als Parameter. Dieser Datensatzverarbeiter verarbeitet nur diese Shard und in der Regel ist dies auch umgekehrt der Fall (diese Shard wird nur durch diesen Datensatverarbeiter verarbeitet). Ihr Konsument sollte jedoch die Möglichkeit berücksichtigen, dass ein Datensatz mehr als einmal verarbeitet werden könnte. Das liegt daran, dass Kinesis Data Streams eine Semantik nach dem Grundsatz *mindestens einmal* hat. Das bedeutet, dass jeder Datensatz aus einer Shard mindestens einmal von einem Worker in Ihrem Konsumenten verarbeitet wird. Weitere Informationen zu Fällen, in denen eine bestimmte Shard möglicherweise durch mehr als einen Auftragnehmer verarbeitet wird, finden Sie unter [Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern](kinesis-record-processor-scaling.md).
```
def initialize(self, shard_id)
```
**process\$1records**
Die KCL ruft diese Methode auf und übergibt eine Liste der Datensätze aus der Shard, die von der Methode `initialize` angegeben wird. Der von Ihnen implementierte Datensatzverarbeiter verarbeitet die Daten in diesen Datensätzen entsprechend der Semantik Ihres Konsumenten. Beispielsweise kann der Auftragnehmer eine Transformation für die Daten ausführen und das Ergebnis dann in einem Amazon Simple Storage Service (Amazon S3)-Bucket speichern.
```
def process_records(self, records, checkpointer)
```
Zusätzlich zu den Daten selbst enthält der Datensatz auch eine Sequenznummer und einen Partitionsschlüssel. Der Auftragnehmer kann diese Werte beim Verarbeiten der Daten verwenden. Beispielsweise könnte der Auftragnehmer basierend auf dem Wert des Partitionsschlüssels den S3-Bucket wählen, in dem die Daten gespeichert werden sollen. Das `record`-Anmeldeverzeichnis stellt die folgenden Schlüssel-Wert-Paare für den Zugriff auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel bereit:
```
record.get('data')
record.get('sequenceNumber')
record.get('partitionKey')
```
Beachten Sie, dass die Daten Base64-kodiert sind.
Im Beispiel weist die Methode `process_records` Code auf, der zeigt, wie ein Auftragnehmer auf die Daten des Datensatzes, die Sequenznummer und den Partitionsschlüssel zugreifen kann.
Kinesis Data Streams erfordert, dass der Datensatzverarbeiter die Datensätze nachverfolgt, die bereits in einer Shard verarbeitet wurden. Die KCL übernimmt diese Nachverfolgung für Sie, indem ein `Checkpointer`-Objekt an `process_records` übergeben wird. Der Datensatzverarbeiter ruft die Methode `checkpoint` auf diesem Objekt auf, um die KCL über die Fortschritte zu informieren, die er beim Verarbeiten der Datensätze in der Shard gemacht hat. Wenn der Auftragnehmer fehlschlägt, verwendet die KCL diese Informationen, um die Verarbeitung der Shard mit dem letzten bekannten Datensatz neu zu starten.
Im Fall einer Teilungs- oder Zusammenführungsoperation beginnt die KCL erst dann mit der Verarbeitung der neuen Shards, wenn die Verarbeiter für die ursprünglichen Shards `checkpoint` aufgerufen haben, um zu signalisieren, dass die Verarbeitung der ursprünglichen Shards vollständig abgeschlossen ist.
Wenn Sie keinen Parameter übergeben, nimmt die KCL an, dass der Aufruf von `checkpoint` bedeutet, dass alle Datensätze bis zum letzten Datensatz, der an den Datensatzverarbeiter übergeben wurde, verarbeitet wurden. Daher sollte der Datensatzverarbeiter die Methode `checkpoint` erst aufrufen, wenn er alle Datensätze in der Liste, die ihm übergeben wurden, verarbeitet hat. Datensatzverarbeiter müssen `checkpoint` nicht bei jedem Aufruf von `process_records` aufrufen. Ein Prozessor könnte beispielsweise `checkpoint` bei jedem dritten Aufruf aufrufen. Sie können optional die exakte Sequenznummer eines Datensatzes als Parameter für `checkpoint` angeben. In diesem Fall nimmt die KCL an, dass alle Datensätze nur bis zu diesem Datensatz verarbeitet wurden.
Im Beispiel zeigt die private Methode `checkpoint`, wie die `Checkpointer.checkpoint`-Methode mithilfe der entsprechenden Ausnahmebehandlung und Wiederholungslogik aufgerufen wird.
Die KCL ist bei der Behandlung von Ausnahmen, die während der Verarbeitung der Datensätze auftreten, von `process_records` abhängig. Wenn `process_records` eine Ausnahme auslöst, überspringt die KCL die Datensätze, die vor der Ausnahme an `process_records` übergeben wurden. Das heißt, diese Datensätze werden nicht erneut an den Datensatzprozessor gesendet, der die Ausnahme ausgelöst hat, oder an einen anderen Datensatzprozessor im Verbraucher.
**shutdown**
Die KCL ruft die Methode `shutdown` entweder auf, wenn die Verarbeitung beendet wird (Grund für das Herunterfahren ist `TERMINATE`) oder wenn der Auftragnehmer nicht mehr reagiert (das Herunterfahren `reason` ist `ZOMBIE`).
```
def shutdown(self, checkpointer, reason)
```
Die Verarbeitung endet, wenn der Datensatzverarbeiter keine weiteren Datensätze aus der Shard erhält, entweder weil die Shard geteilt oder zusammengeführt wurde oder weil der Stream gelöscht wurde.
Die KCL übergibt auch ein `Checkpointer`-Objekt an `shutdown`. Wenn der `reason` für das Herunterfahren `TERMINATE` ist, sollte der Datensatzverarbeiter alle Datensätze fertigstellen und dann die Methode `checkpoint` in seiner Schnittstelle aufrufen.
## Ändern Sie die Konfigurationseigenschaften
Das Beispiel zeigt Standardwerte für die Konfigurationseigenschaften. Sie können diese Eigenschaften mit eigenen Werten überschreiben (siehe `sample.properties`).
### Anwendungsname
Die KCL erfordert einen Anwendungsnamen, der unter Ihren Anwendungen sowie den Amazon-DynamoDB-Tabellen in derselben Region eindeutig ist. Sie verwendet den Wert der Anwendungsnamenkonfiguration auf folgende Arten:
+ Für mit diesem Anwendungsnamen verknüpfte Auftragnehmer wird angenommen, dass sie gemeinsam im gleichen Stream arbeiten. Diese Auftragnehmer können auf mehrere Instances verteilt sein. Wenn Sie eine zusätzliche Instance desselben Anwendungscodes ausführen, jedoch mit einem anderen Anwendungsnamen, behandelt die KCL die zweite Instance als eine völlig getrennte Anwendung, die ebenfalls im selben Stream arbeitet.
+ Die KCL erstellt eine DynamoDB-Tabelle mit dem Namen der Anwendung und verwendet die Tabelle für die Verwaltung von Statusinformationen für die Anwendung (wie Checkpoints und Auftragnehmer-Shard-Zuweisungen). Jede Anwendung verfügt über eine eigene DynamoDB-Tabelle. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
### Richten Sie Anmeldeinformationen ein
Sie müssen Ihre AWS Anmeldeinformationen einem der Anmeldeinformationsanbieter in der Kette der Standardanmeldedienstanbieter zur Verfügung stellen. Sie können die Eigenschaft `AWSCredentialsProvider` verwenden, um einen Anmeldeinformationsanbieter einzurichten. Die [sample.properties](https://github.com/awslabs/amazon-kinesis-client-python/blob/master/samples/sample.properties) muss Ihre Anmeldeinformationen einem der Anmeldeinformationsanbieter in der [Anmeldeinformationsanbieter-Standardkette](https://docs.aws.amazon.com/sdk-for-java/latest/reference/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html) bereitstellen. Wenn Sie Ihre Konsumentenanwendung auf einer Amazon-EC2-Instance ausführen, empfehlen wir, die Instance mit einer IAM-Rolle zu konfigurieren. AWS -Anmeldeinformationen, die die mit dieser IAM-Rolle verknüpften Berechtigungen widerspiegeln, werden den Anwendungen auf der Instance über deren Instance-Metadaten zur Verfügung gestellt. Dies ist die sicherste Art, Anmeldeinformationen für eine Konsumentenanwendung zu verwalten, die auf einer EC2-Instance ausgeführt wird.
Die Eigenschaftendatei des Beispiels konfiguriert KCL, um einen Kinesis-Datenstrom namens „words“ mittels des Datensatzverarbeiters zu verarbeiten, der in `sample_kclpy_app.py` bereitgestellt wird.
# Entwickeln Sie einen Kinesis Client Library-Consumer in Ruby
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Kinesis Client Library (KCL) verwenden, um Anwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten. Die Kinesis Client Library ist in mehreren Sprachen verfügbar. In diesem Thema wird Ruby behandelt.
Die KCL ist eine Java-Bibliothek. Unterstützung für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle bereitgestellt, die als. *MultiLangDaemon* Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine andere KCL-Sprache als Java verwenden. Wenn Sie also die KCL für Ruby installieren und Ihre Consumer-App vollständig in Ruby schreiben, müssen Sie trotzdem Java auf Ihrem System installieren, da MultiLangDaemon Darüber hinaus MultiLangDaemon verfügt es über einige Standardeinstellungen, die Sie möglicherweise an Ihren Anwendungsfall anpassen müssen, z. B. die AWS Region, mit der eine Verbindung hergestellt wird. Weitere Informationen dazu finden Sie MultiLangDaemon auf GitHub der [ MultiLangDaemon KCL-Projektseite](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang).
Um die Ruby KCL von herunterzuladen GitHub, gehen Sie zur [Kinesis Client Library (Ruby)](https://github.com/awslabs/amazon-kinesis-client-ruby). Den Beispielcode für eine Ruby-KCL-Anwendung für Privatanwender können Sie auf der Projektseite [KCL for Ruby unter](https://github.com/awslabs/amazon-kinesis-client-ruby/tree/master/samples) herunterladen. GitHub
Weitere Informationen über die KCL-Bibliothek für die Unterstützung von Ruby finden Sie unter [Dokumentation zu KCL Ruby Gems](http://www.rubydoc.info/gems/aws-kclrb).
# Entwickeln Sie KCL 2.x-Verbraucher
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird am 30. Januar 2026 end-of-support verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
In diesem Thema erhalten Sie Informationen zur Nutzung der Version 2.0 der Kinesis Client Library (KCL).
Weitere Informationen über die KCL finden Sie in der Übersicht in [Entwickeln von Verbrauchern mit der Kinesis Client Library 1.x](https://docs.aws.amazon.com/streams/latest/dev/developing-consumers-with-kcl.html).
Wählen Sie je nach der Option, die Sie verwenden möchten, aus den folgenden Themen.
**Topics**
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in Java
](kcl2-standard-consumer-java-example.md)
+ [
# Entwickeln Sie einen Kinesis Client Library-Consumer in Python
](kcl2-standard-consumer-python-example.md)
+ [
# Entwickeln Sie mit KCL 2.x erweiterte Fan-Out-Nutzer
](building-enhanced-consumers-kcl-retired.md)
# Entwickeln Sie einen Kinesis Client Library-Consumer in Java
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Der folgende Code zeigt eine Beispielimplementierung in Java für `ProcessorFactory` und `RecordProcessor`. Weitere Informationen zur Nutzung der Vorteile der erweiterten Rundsendefunktion finden Sie unter [Verwenden von Verbrauchern mit erweitertem Rundsenden ](https://docs.aws.amazon.com/streams/latest/dev/building-enhanced-consumers-kcl-java.html).
```
/*
* Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
*
* Licensed under the Amazon Software License (the "License").
* You may not use this file except in compliance with the License.
* A copy of the License is located at
*
* http://aws.amazon.com/asl/
*
* or in the "license" file accompanying this file. This file is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
* express or implied. See the License for the specific language governing
* permissions and limitations under the License.
*/
/*
* Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
*
* Licensed under the Apache License, Version 2.0 (the "License").
* You may not use this file except in compliance with the License.
* A copy of the License is located at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* or in the "license" file accompanying this file. This file is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
* express or implied. See the License for the specific language governing
* permissions and limitations under the License.
*/
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.UUID;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
import org.apache.commons.lang3.ObjectUtils;
import org.apache.commons.lang3.RandomStringUtils;
import org.apache.commons.lang3.RandomUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;
import software.amazon.awssdk.core.SdkBytes;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.cloudwatch.CloudWatchAsyncClient;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClient;
import software.amazon.awssdk.services.kinesis.KinesisAsyncClient;
import software.amazon.awssdk.services.kinesis.model.PutRecordRequest;
import software.amazon.kinesis.common.ConfigsBuilder;
import software.amazon.kinesis.common.KinesisClientUtil;
import software.amazon.kinesis.coordinator.Scheduler;
import software.amazon.kinesis.exceptions.InvalidStateException;
import software.amazon.kinesis.exceptions.ShutdownException;
import software.amazon.kinesis.lifecycle.events.InitializationInput;
import software.amazon.kinesis.lifecycle.events.LeaseLostInput;
import software.amazon.kinesis.lifecycle.events.ProcessRecordsInput;
import software.amazon.kinesis.lifecycle.events.ShardEndedInput;
import software.amazon.kinesis.lifecycle.events.ShutdownRequestedInput;
import software.amazon.kinesis.processor.ShardRecordProcessor;
import software.amazon.kinesis.processor.ShardRecordProcessorFactory;
import software.amazon.kinesis.retrieval.polling.PollingConfig;
/**
* This class will run a simple app that uses the KCL to read data and uses the AWS SDK to publish data.
* Before running this program you must first create a Kinesis stream through the AWS console or AWS SDK.
*/
public class SampleSingle {
private static final Logger log = LoggerFactory.getLogger(SampleSingle.class);
/**
* Invoke the main method with 2 args: the stream name and (optionally) the region.
* Verifies valid inputs and then starts running the app.
*/
public static void main(String... args) {
if (args.length < 1) {
log.error("At a minimum, the stream name is required as the first argument. The Region may be specified as the second argument.");
System.exit(1);
}
String streamName = args[0];
String region = null;
if (args.length > 1) {
region = args[1];
}
new SampleSingle(streamName, region).run();
}
private final String streamName;
private final Region region;
private final KinesisAsyncClient kinesisClient;
/**
* Constructor sets streamName and region. It also creates a KinesisClient object to send data to Kinesis.
* This KinesisClient is used to send dummy data so that the consumer has something to read; it is also used
* indirectly by the KCL to handle the consumption of the data.
*/
private SampleSingle(String streamName, String region) {
this.streamName = streamName;
this.region = Region.of(ObjectUtils.firstNonNull(region, "us-east-2"));
this.kinesisClient = KinesisClientUtil.createKinesisAsyncClient(KinesisAsyncClient.builder().region(this.region));
}
private void run() {
/**
* Sends dummy data to Kinesis. Not relevant to consuming the data with the KCL
*/
ScheduledExecutorService producerExecutor = Executors.newSingleThreadScheduledExecutor();
ScheduledFuture producerFuture = producerExecutor.scheduleAtFixedRate(this::publishRecord, 10, 1, TimeUnit.SECONDS);
/**
* Sets up configuration for the KCL, including DynamoDB and CloudWatch dependencies. The final argument, a
* ShardRecordProcessorFactory, is where the logic for record processing lives, and is located in a private
* class below.
*/
DynamoDbAsyncClient dynamoClient = DynamoDbAsyncClient.builder().region(region).build();
CloudWatchAsyncClient cloudWatchClient = CloudWatchAsyncClient.builder().region(region).build();
ConfigsBuilder configsBuilder = new ConfigsBuilder(streamName, streamName, kinesisClient, dynamoClient, cloudWatchClient, UUID.randomUUID().toString(), new SampleRecordProcessorFactory());
/**
* The Scheduler (also called Worker in earlier versions of the KCL) is the entry point to the KCL. This
* instance is configured with defaults provided by the ConfigsBuilder.
*/
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig(),
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig().retrievalSpecificConfig(new PollingConfig(streamName, kinesisClient))
);
/**
* Kickoff the Scheduler. Record processing of the stream of dummy data will continue indefinitely
* until an exit is triggered.
*/
Thread schedulerThread = new Thread(scheduler);
schedulerThread.setDaemon(true);
schedulerThread.start();
/**
* Allows termination of app by pressing Enter.
*/
System.out.println("Press enter to shutdown");
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
try {
reader.readLine();
} catch (IOException ioex) {
log.error("Caught exception while waiting for confirm. Shutting down.", ioex);
}
/**
* Stops sending dummy data.
*/
log.info("Cancelling producer and shutting down executor.");
producerFuture.cancel(true);
producerExecutor.shutdownNow();
/**
* Stops consuming data. Finishes processing the current batch of data already received from Kinesis
* before shutting down.
*/
Future gracefulShutdownFuture = scheduler.startGracefulShutdown();
log.info("Waiting up to 20 seconds for shutdown to complete.");
try {
gracefulShutdownFuture.get(20, TimeUnit.SECONDS);
} catch (InterruptedException e) {
log.info("Interrupted while waiting for graceful shutdown. Continuing.");
} catch (ExecutionException e) {
log.error("Exception while executing graceful shutdown.", e);
} catch (TimeoutException e) {
log.error("Timeout while waiting for shutdown. Scheduler may not have exited.");
}
log.info("Completed, shutting down now.");
}
/**
* Sends a single record of dummy data to Kinesis.
*/
private void publishRecord() {
PutRecordRequest request = PutRecordRequest.builder()
.partitionKey(RandomStringUtils.randomAlphabetic(5, 20))
.streamName(streamName)
.data(SdkBytes.fromByteArray(RandomUtils.nextBytes(10)))
.build();
try {
kinesisClient.putRecord(request).get();
} catch (InterruptedException e) {
log.info("Interrupted, assuming shutdown.");
} catch (ExecutionException e) {
log.error("Exception while sending data to Kinesis. Will try again next cycle.", e);
}
}
private static class SampleRecordProcessorFactory implements ShardRecordProcessorFactory {
public ShardRecordProcessor shardRecordProcessor() {
return new SampleRecordProcessor();
}
}
/**
* The implementation of the ShardRecordProcessor interface is where the heart of the record processing logic lives.
* In this example all we do to 'process' is log info about the records.
*/
private static class SampleRecordProcessor implements ShardRecordProcessor {
private static final String SHARD_ID_MDC_KEY = "ShardId";
private static final Logger log = LoggerFactory.getLogger(SampleRecordProcessor.class);
private String shardId;
/**
* Invoked by the KCL before data records are delivered to the ShardRecordProcessor instance (via
* processRecords). In this example we do nothing except some logging.
*
* @param initializationInput Provides information related to initialization.
*/
public void initialize(InitializationInput initializationInput) {
shardId = initializationInput.shardId();
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Initializing @ Sequence: {}", initializationInput.extendedSequenceNumber());
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
/**
* Handles record processing logic. The Amazon Kinesis Client Library will invoke this method to deliver
* data records to the application. In this example we simply log our records.
*
* @param processRecordsInput Provides the records to be processed as well as information and capabilities
* related to them (e.g. checkpointing).
*/
public void processRecords(ProcessRecordsInput processRecordsInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Processing {} record(s)", processRecordsInput.records().size());
processRecordsInput.records().forEach(r -> log.info("Processing record pk: {} -- Seq: {}", r.partitionKey(), r.sequenceNumber()));
} catch (Throwable t) {
log.error("Caught throwable while processing records. Aborting.");
Runtime.getRuntime().halt(1);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
/** Called when the lease tied to this record processor has been lost. Once the lease has been lost,
* the record processor can no longer checkpoint.
*
* @param leaseLostInput Provides access to functions and data related to the loss of the lease.
*/
public void leaseLost(LeaseLostInput leaseLostInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Lost lease, so terminating.");
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
/**
* Called when all data on this shard has been processed. Checkpointing must occur in the method for record
* processing to be considered complete; an exception will be thrown otherwise.
*
* @param shardEndedInput Provides access to a checkpointer method for completing processing of the shard.
*/
public void shardEnded(ShardEndedInput shardEndedInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Reached shard end checkpointing.");
shardEndedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at shard end. Giving up.", e);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
/**
* Invoked when Scheduler has been requested to shut down (i.e. we decide to stop running the app by pressing
* Enter). Checkpoints and logs the data a final time.
*
* @param shutdownRequestedInput Provides access to a checkpointer, allowing a record processor to checkpoint
* before the shutdown is completed.
*/
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Scheduler is shutting down, checkpointing.");
shutdownRequestedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at requested shutdown. Giving up.", e);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
}
}
```
# Entwickeln Sie einen Kinesis Client Library-Consumer in Python
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird end-of-support am 30. Januar 2026 verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Kinesis Client Library (KCL) verwenden, um Anwendungen zu erstellen, die Daten aus Ihren Kinesis-Datenströmen verarbeiten. Die Kinesis Client Library ist in mehreren Sprachen verfügbar. In diesem Thema wird Python behandelt.
Die KCL ist eine Java-Bibliothek. Unterstützung für andere Sprachen als Java wird über eine mehrsprachige Schnittstelle bereitgestellt, die als. *MultiLangDaemon* Dieser Daemon basiert auf Java und wird im Hintergrund ausgeführt, wenn Sie eine andere KCL-Sprache als Java verwenden. Wenn Sie also die KCL für Python installieren und Ihre Consumer-App vollständig in Python schreiben, muss Java aufgrund der MultiLangDaemon trotzdem auf Ihrem System installiert sein. Darüber hinaus MultiLangDaemon verfügt es über einige Standardeinstellungen, die Sie möglicherweise an Ihren Anwendungsfall anpassen müssen, z. B. die AWS Region, mit der eine Verbindung hergestellt wird. Weitere Informationen dazu finden Sie MultiLangDaemon auf GitHub der [ MultiLangDaemon KCL-Projektseite](https://github.com/awslabs/amazon-kinesis-client/tree/v1.x/src/main/java/com/amazonaws/services/kinesis/multilang).
Um die Python-KCL von herunterzuladen GitHub, gehen Sie zur [Kinesis Client Library (Python)](https://github.com/awslabs/amazon-kinesis-client-python). Um Beispielcode für eine Python-KCL-Consumer-Anwendung herunterzuladen, gehen Sie zur [KCL for Python-Beispielprojektseite unter](https://github.com/awslabs/amazon-kinesis-client-python/tree/master/samples). GitHub
Sie müssen die folgenden Aufgaben durchführen, wenn Sie eine KCL-Konsumentenanwendung in Python implementieren:
**Topics**
+ [
## Implementieren Sie die Klassenmethoden RecordProcessor
](#kinesis-record-processor-implementation-interface-py)
+ [
## Ändern Sie die Konfigurationseigenschaften
](#kinesis-record-processor-initialization-py)
## Implementieren Sie die Klassenmethoden RecordProcessor
Die `RecordProcess`-Klasse muss die `RecordProcessorBase`-Klasse erweitern, um die folgenden Methoden zu implementieren:
```
initialize
process_records
shutdown_requested
```
Dieses Beispiel stellt Implementierungen bereit, die Sie als Ausgangspunkt verwenden können.
```
#!/usr/bin/env python
# Copyright 2014-2015 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Amazon Software License (the "License").
# You may not use this file except in compliance with the License.
# A copy of the License is located at
#
# http://aws.amazon.com/asl/
#
# or in the "license" file accompanying this file. This file is distributed
# on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
# express or implied. See the License for the specific language governing
# permissions and limitations under the License.
from __future__ import print_function
import sys
import time
from amazon_kclpy import kcl
from amazon_kclpy.v3 import processor
class RecordProcessor(processor.RecordProcessorBase):
"""
A RecordProcessor processes data from a shard in a stream. Its methods will be called with this pattern:
* initialize will be called once
* process_records will be called zero or more times
* shutdown will be called if this MultiLangDaemon instance loses the lease to this shard, or the shard ends due
a scaling change.
"""
def __init__(self):
self._SLEEP_SECONDS = 5
self._CHECKPOINT_RETRIES = 5
self._CHECKPOINT_FREQ_SECONDS = 60
self._largest_seq = (None, None)
self._largest_sub_seq = None
self._last_checkpoint_time = None
def log(self, message):
sys.stderr.write(message)
def initialize(self, initialize_input):
"""
Called once by a KCLProcess before any calls to process_records
:param amazon_kclpy.messages.InitializeInput initialize_input: Information about the lease that this record
processor has been assigned.
"""
self._largest_seq = (None, None)
self._last_checkpoint_time = time.time()
def checkpoint(self, checkpointer, sequence_number=None, sub_sequence_number=None):
"""
Checkpoints with retries on retryable exceptions.
:param amazon_kclpy.kcl.Checkpointer checkpointer: the checkpointer provided to either process_records
or shutdown
:param str or None sequence_number: the sequence number to checkpoint at.
:param int or None sub_sequence_number: the sub sequence number to checkpoint at.
"""
for n in range(0, self._CHECKPOINT_RETRIES):
try:
checkpointer.checkpoint(sequence_number, sub_sequence_number)
return
except kcl.CheckpointError as e:
if 'ShutdownException' == e.value:
#
# A ShutdownException indicates that this record processor should be shutdown. This is due to
# some failover event, e.g. another MultiLangDaemon has taken the lease for this shard.
#
print('Encountered shutdown exception, skipping checkpoint')
return
elif 'ThrottlingException' == e.value:
#
# A ThrottlingException indicates that one of our dependencies is is over burdened, e.g. too many
# dynamo writes. We will sleep temporarily to let it recover.
#
if self._CHECKPOINT_RETRIES - 1 == n:
sys.stderr.write('Failed to checkpoint after {n} attempts, giving up.\n'.format(n=n))
return
else:
print('Was throttled while checkpointing, will attempt again in {s} seconds'
.format(s=self._SLEEP_SECONDS))
elif 'InvalidStateException' == e.value:
sys.stderr.write('MultiLangDaemon reported an invalid state while checkpointing.\n')
else: # Some other error
sys.stderr.write('Encountered an error while checkpointing, error was {e}.\n'.format(e=e))
time.sleep(self._SLEEP_SECONDS)
def process_record(self, data, partition_key, sequence_number, sub_sequence_number):
"""
Called for each record that is passed to process_records.
:param str data: The blob of data that was contained in the record.
:param str partition_key: The key associated with this recod.
:param int sequence_number: The sequence number associated with this record.
:param int sub_sequence_number: the sub sequence number associated with this record.
"""
####################################
# Insert your processing logic here
####################################
self.log("Record (Partition Key: {pk}, Sequence Number: {seq}, Subsequence Number: {sseq}, Data Size: {ds}"
.format(pk=partition_key, seq=sequence_number, sseq=sub_sequence_number, ds=len(data)))
def should_update_sequence(self, sequence_number, sub_sequence_number):
"""
Determines whether a new larger sequence number is available
:param int sequence_number: the sequence number from the current record
:param int sub_sequence_number: the sub sequence number from the current record
:return boolean: true if the largest sequence should be updated, false otherwise
"""
return self._largest_seq == (None, None) or sequence_number > self._largest_seq[0] or \
(sequence_number == self._largest_seq[0] and sub_sequence_number > self._largest_seq[1])
def process_records(self, process_records_input):
"""
Called by a KCLProcess with a list of records to be processed and a checkpointer which accepts sequence numbers
from the records to indicate where in the stream to checkpoint.
:param amazon_kclpy.messages.ProcessRecordsInput process_records_input: the records, and metadata about the
records.
"""
try:
for record in process_records_input.records:
data = record.binary_data
seq = int(record.sequence_number)
sub_seq = record.sub_sequence_number
key = record.partition_key
self.process_record(data, key, seq, sub_seq)
if self.should_update_sequence(seq, sub_seq):
self._largest_seq = (seq, sub_seq)
#
# Checkpoints every self._CHECKPOINT_FREQ_SECONDS seconds
#
if time.time() - self._last_checkpoint_time > self._CHECKPOINT_FREQ_SECONDS:
self.checkpoint(process_records_input.checkpointer, str(self._largest_seq[0]), self._largest_seq[1])
self._last_checkpoint_time = time.time()
except Exception as e:
self.log("Encountered an exception while processing records. Exception was {e}\n".format(e=e))
def lease_lost(self, lease_lost_input):
self.log("Lease has been lost")
def shard_ended(self, shard_ended_input):
self.log("Shard has ended checkpointing")
shard_ended_input.checkpointer.checkpoint()
def shutdown_requested(self, shutdown_requested_input):
self.log("Shutdown has been requested, checkpointing.")
shutdown_requested_input.checkpointer.checkpoint()
if __name__ == "__main__":
kcl_process = kcl.KCLProcess(RecordProcessor())
kcl_process.run()
```
## Ändern Sie die Konfigurationseigenschaften
Das Beispiel zeigt Standardwerte für die Konfigurationseigenschaften, wie in dem folgenden Skript gezeigt. Sie können diese Eigenschaften mit eigenen Werten überschreiben.
```
# The script that abides by the multi-language protocol. This script will
# be executed by the MultiLangDaemon, which will communicate with this script
# over STDIN and STDOUT according to the multi-language protocol.
executableName = sample_kclpy_app.py
# The name of an Amazon Kinesis stream to process.
streamName = words
# Used by the KCL as the name of this application. Will be used as the name
# of an Amazon DynamoDB table which will store the lease and checkpoint
# information for workers with this application name
applicationName = PythonKCLSample
# Users can change the credentials provider the KCL will use to retrieve credentials.
# The DefaultAWSCredentialsProviderChain checks several other providers, which is
# described here:
# http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html
AWSCredentialsProvider = DefaultAWSCredentialsProviderChain
# Appended to the user agent of the KCL. Does not impact the functionality of the
# KCL in any other way.
processingLanguage = python/2.7
# Valid options at TRIM_HORIZON or LATEST.
# See http://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetShardIterator.html#API_GetShardIterator_RequestSyntax
initialPositionInStream = TRIM_HORIZON
# The following properties are also available for configuring the KCL Worker that is created
# by the MultiLangDaemon.
# The KCL defaults to us-east-1
#regionName = us-east-1
# Fail over time in milliseconds. A worker which does not renew it's lease within this time interval
# will be regarded as having problems and it's shards will be assigned to other workers.
# For applications that have a large number of shards, this msy be set to a higher number to reduce
# the number of DynamoDB IOPS required for tracking leases
#failoverTimeMillis = 10000
# A worker id that uniquely identifies this worker among all workers using the same applicationName
# If this isn't provided a MultiLangDaemon instance will assign a unique workerId to itself.
#workerId =
# Shard sync interval in milliseconds - e.g. wait for this long between shard sync tasks.
#shardSyncIntervalMillis = 60000
# Max records to fetch from Kinesis in a single GetRecords call.
#maxRecords = 10000
# Idle time between record reads in milliseconds.
#idleTimeBetweenReadsInMillis = 1000
# Enables applications flush/checkpoint (if they have some data "in progress", but don't get new data for while)
#callProcessRecordsEvenForEmptyRecordList = false
# Interval in milliseconds between polling to check for parent shard completion.
# Polling frequently will take up more DynamoDB IOPS (when there are leases for shards waiting on
# completion of parent shards).
#parentShardPollIntervalMillis = 10000
# Cleanup leases upon shards completion (don't wait until they expire in Kinesis).
# Keeping leases takes some tracking/resources (e.g. they need to be renewed, assigned), so by default we try
# to delete the ones we don't need any longer.
#cleanupLeasesUponShardCompletion = true
# Backoff time in milliseconds for Amazon Kinesis Client Library tasks (in the event of failures).
#taskBackoffTimeMillis = 500
# Buffer metrics for at most this long before publishing to CloudWatch.
#metricsBufferTimeMillis = 10000
# Buffer at most this many metrics before publishing to CloudWatch.
#metricsMaxQueueSize = 10000
# KCL will validate client provided sequence numbers with a call to Amazon Kinesis before checkpointing for calls
# to RecordProcessorCheckpointer#checkpoint(String) by default.
#validateSequenceNumberBeforeCheckpointing = true
# The maximum number of active threads for the MultiLangDaemon to permit.
# If a value is provided then a FixedThreadPool is used with the maximum
# active threads set to the provided value. If a non-positive integer or no
# value is provided a CachedThreadPool is used.
#maxActiveThreads = 0
```
### Anwendungsname
Die KCL erfordert einen Anwendungsnamen, der unter Ihren Anwendungen sowie den Amazon-DynamoDB-Tabellen in derselben Region eindeutig ist. Sie verwendet den Wert der Anwendungsnamenkonfiguration auf folgende Arten:
+ Für mit diesem Anwendungsnamen verknüpfte Auftragnehmer wird angenommen, dass sie gemeinsam im gleichen Stream arbeiten. Diese Worker können auf mehrere Instances verteilt sein. Wenn Sie eine zusätzliche Instance desselben Anwendungscodes ausführen, jedoch mit einem anderen Anwendungsnamen, behandelt die KCL die zweite Instance als eine völlig getrennte Anwendung, die ebenfalls im selben Stream arbeitet.
+ Die KCL erstellt eine DynamoDB-Tabelle mit dem Namen der Anwendung und verwendet die Tabelle für die Verwaltung von Statusinformationen für die Anwendung (wie Checkpoints und Auftragnehmer-Shard-Zuweisungen). Jede Anwendung verfügt über eine eigene DynamoDB-Tabelle. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
### Anmeldeinformationen
Sie müssen Ihre AWS Anmeldeinformationen einem der Anmeldeinformationsanbieter in der Kette der [Standardanmeldedienstanbieter](https://docs.aws.amazon.com/sdk-for-java/latest/reference/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html) zur Verfügung stellen. Sie können die Eigenschaft `AWSCredentialsProvider` verwenden, um einen Anmeldeinformationsanbieter einzurichten. Wenn Sie Ihre Consumer-Anwendung auf einer Amazon EC2 EC2-Instance ausführen, empfehlen wir Ihnen, die Instance mit einer IAM-Rolle zu konfigurieren. AWS Anmeldeinformationen, die die mit dieser IAM-Rolle verknüpften Berechtigungen widerspiegeln, werden den Anwendungen auf der Instance über deren Instance-Metadaten zur Verfügung gestellt. Dies ist die sicherste Art, Anmeldeinformationen für eine Konsumentenanwendung zu verwalten, die auf einer EC2-Instance ausgeführt wird.
# Entwickeln Sie mit KCL 2.x erweiterte Fan-Out-Nutzer
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird am 30. Januar 2026 end-of-support verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Verbraucher, die ein *erweitertes Rundsenden* in Amazon Kinesis Data Streams verwenden, können Datensätze aus einem Datenstrom mit einem dedizierten Durchsatz von bis zu 2 MB Daten pro Sekunde pro Shard empfangen. Diese Art Verbraucher muss nicht mit anderen Verbrauchern konkurrieren, die Daten aus dem Stream empfangen. Weitere Informationen finden Sie unter [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md).
Sie können die Version 2.0 oder höher der Kinesis Client Library (KCL) verwenden, um Anwendungen zu entwickeln, die erweitertes Rundsenden verwenden, um Daten aus Streams zu empfangen. Die KCL abonniert Ihre Anwendung automatisch für alle Shards eines Streams und stellt sicher, dass Ihre Privatanwenderanwendung mit einem Durchsatzwert von 2 pro Shard lesen kann. MB/sec Weitere Informationen zur Verwendung der KCL ohne Aktivierung von erweitertem Rundsenden finden Sie unter [Entwickeln von Verbrauchern mit der Kinesis Client Library 2.0](https://docs.aws.amazon.com/streams/latest/dev/developing-consumers-with-kcl-v2.html).
**Topics**
+ [
# Entwickeln Sie erweiterte Fan-Out-Consumer mithilfe von KCL 2.x in Java
](building-enhanced-consumers-kcl-java.md)
# Entwickeln Sie erweiterte Fan-Out-Consumer mithilfe von KCL 2.x in Java
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird am 30. Januar 2026 end-of-support verfügbar sein. Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
Sie können die Version 2.0 oder höher der Kinesis Client Library (KCL) verwenden, um Anwendungen in Amazon Kinesis Data Streams zu entwickeln, die Daten aus Streams mit erweitertem Rundsenden empfangen. Der folgende Code zeigt eine Beispielimplementierung in Java für `ProcessorFactory` und `RecordProcessor`.
Es wird empfohlen, dass Sie `KinesisClientUtil` zum Erstellen von `KinesisAsyncClient` und zum Konfigurieren von `maxConcurrency` in `KinesisAsyncClient` verwenden.
**Wichtig**
Für den Amazon Kinesis Client kann sich die Latenz möglicherweise signifikant erhöhen, sofern Sie `KinesisAsyncClient` nicht für einen `maxConcurrency`-Wert konfigurieren, der hoch genug ist, um alle Leases plus zusätzliche Verwendungen von `KinesisAsyncClient` zu ermöglichen.
```
/*
* Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
*
* Licensed under the Amazon Software License (the "License").
* You may not use this file except in compliance with the License.
* A copy of the License is located at
*
* http://aws.amazon.com/asl/
*
* or in the "license" file accompanying this file. This file is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
* express or implied. See the License for the specific language governing
* permissions and limitations under the License.
*/
/*
* Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
*
* Licensed under the Apache License, Version 2.0 (the "License").
* You may not use this file except in compliance with the License.
* A copy of the License is located at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* or in the "license" file accompanying this file. This file is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
* express or implied. See the License for the specific language governing
* permissions and limitations under the License.
*/
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.UUID;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
import org.apache.commons.lang3.ObjectUtils;
import org.apache.commons.lang3.RandomStringUtils;
import org.apache.commons.lang3.RandomUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;
import software.amazon.awssdk.core.SdkBytes;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.cloudwatch.CloudWatchAsyncClient;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClient;
import software.amazon.awssdk.services.kinesis.KinesisAsyncClient;
import software.amazon.awssdk.services.kinesis.model.PutRecordRequest;
import software.amazon.kinesis.common.ConfigsBuilder;
import software.amazon.kinesis.common.KinesisClientUtil;
import software.amazon.kinesis.coordinator.Scheduler;
import software.amazon.kinesis.exceptions.InvalidStateException;
import software.amazon.kinesis.exceptions.ShutdownException;
import software.amazon.kinesis.lifecycle.events.InitializationInput;
import software.amazon.kinesis.lifecycle.events.LeaseLostInput;
import software.amazon.kinesis.lifecycle.events.ProcessRecordsInput;
import software.amazon.kinesis.lifecycle.events.ShardEndedInput;
import software.amazon.kinesis.lifecycle.events.ShutdownRequestedInput;
import software.amazon.kinesis.processor.ShardRecordProcessor;
import software.amazon.kinesis.processor.ShardRecordProcessorFactory;
public class SampleSingle {
private static final Logger log = LoggerFactory.getLogger(SampleSingle.class);
public static void main(String... args) {
if (args.length < 1) {
log.error("At a minimum, the stream name is required as the first argument. The Region may be specified as the second argument.");
System.exit(1);
}
String streamName = args[0];
String region = null;
if (args.length > 1) {
region = args[1];
}
new SampleSingle(streamName, region).run();
}
private final String streamName;
private final Region region;
private final KinesisAsyncClient kinesisClient;
private SampleSingle(String streamName, String region) {
this.streamName = streamName;
this.region = Region.of(ObjectUtils.firstNonNull(region, "us-east-2"));
this.kinesisClient = KinesisClientUtil.createKinesisAsyncClient(KinesisAsyncClient.builder().region(this.region));
}
private void run() {
ScheduledExecutorService producerExecutor = Executors.newSingleThreadScheduledExecutor();
ScheduledFuture producerFuture = producerExecutor.scheduleAtFixedRate(this::publishRecord, 10, 1, TimeUnit.SECONDS);
DynamoDbAsyncClient dynamoClient = DynamoDbAsyncClient.builder().region(region).build();
CloudWatchAsyncClient cloudWatchClient = CloudWatchAsyncClient.builder().region(region).build();
ConfigsBuilder configsBuilder = new ConfigsBuilder(streamName, streamName, kinesisClient, dynamoClient, cloudWatchClient, UUID.randomUUID().toString(), new SampleRecordProcessorFactory());
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig(),
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig()
);
Thread schedulerThread = new Thread(scheduler);
schedulerThread.setDaemon(true);
schedulerThread.start();
System.out.println("Press enter to shutdown");
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
try {
reader.readLine();
} catch (IOException ioex) {
log.error("Caught exception while waiting for confirm. Shutting down.", ioex);
}
log.info("Cancelling producer, and shutting down executor.");
producerFuture.cancel(true);
producerExecutor.shutdownNow();
Future gracefulShutdownFuture = scheduler.startGracefulShutdown();
log.info("Waiting up to 20 seconds for shutdown to complete.");
try {
gracefulShutdownFuture.get(20, TimeUnit.SECONDS);
} catch (InterruptedException e) {
log.info("Interrupted while waiting for graceful shutdown. Continuing.");
} catch (ExecutionException e) {
log.error("Exception while executing graceful shutdown.", e);
} catch (TimeoutException e) {
log.error("Timeout while waiting for shutdown. Scheduler may not have exited.");
}
log.info("Completed, shutting down now.");
}
private void publishRecord() {
PutRecordRequest request = PutRecordRequest.builder()
.partitionKey(RandomStringUtils.randomAlphabetic(5, 20))
.streamName(streamName)
.data(SdkBytes.fromByteArray(RandomUtils.nextBytes(10)))
.build();
try {
kinesisClient.putRecord(request).get();
} catch (InterruptedException e) {
log.info("Interrupted, assuming shutdown.");
} catch (ExecutionException e) {
log.error("Exception while sending data to Kinesis. Will try again next cycle.", e);
}
}
private static class SampleRecordProcessorFactory implements ShardRecordProcessorFactory {
public ShardRecordProcessor shardRecordProcessor() {
return new SampleRecordProcessor();
}
}
private static class SampleRecordProcessor implements ShardRecordProcessor {
private static final String SHARD_ID_MDC_KEY = "ShardId";
private static final Logger log = LoggerFactory.getLogger(SampleRecordProcessor.class);
private String shardId;
public void initialize(InitializationInput initializationInput) {
shardId = initializationInput.shardId();
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Initializing @ Sequence: {}", initializationInput.extendedSequenceNumber());
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
public void processRecords(ProcessRecordsInput processRecordsInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Processing {} record(s)", processRecordsInput.records().size());
processRecordsInput.records().forEach(r -> log.info("Processing record pk: {} -- Seq: {}", r.partitionKey(), r.sequenceNumber()));
} catch (Throwable t) {
log.error("Caught throwable while processing records. Aborting.");
Runtime.getRuntime().halt(1);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
public void leaseLost(LeaseLostInput leaseLostInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Lost lease, so terminating.");
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
public void shardEnded(ShardEndedInput shardEndedInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Reached shard end checkpointing.");
shardEndedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at shard end. Giving up.", e);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
MDC.put(SHARD_ID_MDC_KEY, shardId);
try {
log.info("Scheduler is shutting down, checkpointing.");
shutdownRequestedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
log.error("Exception while checkpointing at requested shutdown. Giving up.", e);
} finally {
MDC.remove(SHARD_ID_MDC_KEY);
}
}
}
}
```
# Migrieren Sie Verbraucher von KCL 1.x zu KCL 2.x
**Wichtig**
Die Versionen 1.x und 2.x der Amazon Kinesis Client Library (KCL) sind veraltet. KCL 1.x wird am 30. Januar 2026 verfügbar sein. end-of-support Wir **empfehlen dringend**, dass Sie Ihre KCL-Anwendungen, die Version 1.x verwenden, vor dem 30. Januar 2026 auf die neueste KCL-Version migrieren. Die neueste KCL-Version finden Sie auf der [Seite Amazon Kinesis Client Library](https://github.com/awslabs/amazon-kinesis-client) unter. GitHub Informationen zu den neuesten KCL-Versionen finden Sie unter. [Verwenden Sie die Kinesis-Clientbibliothek](kcl.md) Informationen zur Migration von KCL 1.x zu KCL 3.x finden Sie unter. [Migrieren von KCL 1.x zu KCL 3.x](kcl-migration-1-3.md)
In diesem Thema werden die Unterschiede zwischen den Versionen 1.x und 2.x der Kinesis Client Library (KCL) erläutert. Außerdem erfahren Sie, wie Sie Ihren Konsumenten von Version 1.x nach Version 2.x der KCL migrieren. Nach der Migration des Clients werden Datensätze vom letzten Checkpoint-Speicherort verarbeitet.
Version 2.0 der KCL enthält die folgenden Schnittstellenänderungen:
**KCL-Schnittstellenänderungen**
| KCL 1.x-Schnittstelle | KCL 2.0-Schnittstelle |
| --- | --- |
| com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor | software.amazon.kinesis.processor.ShardRecordProcessor |
| com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessorFactory | software.amazon.kinesis.processor.ShardRecordProcessorFactory |
| com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IShutdownNotificationAware | Umgewandelt in software.amazon.kinesis.processor.ShardRecordProcessor |
**Topics**
+ [
## Migrieren Sie den Aufzeichnungsprozessor
](#recrod-processor-migration)
+ [
## Migrieren Sie den Plattenprozessor ab Werk
](#recrod-processor-factory-migration)
+ [
## Migrieren Sie den Worker
](#worker-migration)
+ [
## Den Amazon Kinesis-Client konfigurieren
](#client-configuration)
+ [
## Entfernung von Leerlaufzeiten
](#idle-time-removal)
+ [
## Entfernung der Client-Konfiguration
](#client-configuration-removals)
## Migrieren Sie den Aufzeichnungsprozessor
Das folgende Beispiel zeigt einen Datensatzprozessor, der für KCL 1.x implementiert wurde:
```
package com.amazonaws.kcl;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.InvalidStateException;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.ShutdownException;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorCheckpointer;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IShutdownNotificationAware;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.ShutdownReason;
import com.amazonaws.services.kinesis.clientlibrary.types.InitializationInput;
import com.amazonaws.services.kinesis.clientlibrary.types.ProcessRecordsInput;
import com.amazonaws.services.kinesis.clientlibrary.types.ShutdownInput;
public class TestRecordProcessor implements IRecordProcessor, IShutdownNotificationAware {
@Override
public void initialize(InitializationInput initializationInput) {
//
// Setup record processor
//
}
@Override
public void processRecords(ProcessRecordsInput processRecordsInput) {
//
// Process records, and possibly checkpoint
//
}
@Override
public void shutdown(ShutdownInput shutdownInput) {
if (shutdownInput.getShutdownReason() == ShutdownReason.TERMINATE) {
try {
shutdownInput.getCheckpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
throw new RuntimeException(e);
}
}
}
@Override
public void shutdownRequested(IRecordProcessorCheckpointer checkpointer) {
try {
checkpointer.checkpoint();
} catch (ShutdownException | InvalidStateException e) {
//
// Swallow exception
//
e.printStackTrace();
}
}
}
```
**So migrieren Sie die Datensatzprozessorklasse**
1. Ändern Sie die Schnittstellen von `com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor` und `com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IShutdownNotificationAware` folgendermaßen nach `software.amazon.kinesis.processor.ShardRecordProcessor`:
```
// import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor;
// import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IShutdownNotificationAware;
import software.amazon.kinesis.processor.ShardRecordProcessor;
// public class TestRecordProcessor implements IRecordProcessor, IShutdownNotificationAware {
public class TestRecordProcessor implements ShardRecordProcessor {
```
1. Aktualisieren Sie die `import`-Anweisungen für die Methoden `initialize` und `processRecords`.
```
// import com.amazonaws.services.kinesis.clientlibrary.types.InitializationInput;
import software.amazon.kinesis.lifecycle.events.InitializationInput;
//import com.amazonaws.services.kinesis.clientlibrary.types.ProcessRecordsInput;
import software.amazon.kinesis.lifecycle.events.ProcessRecordsInput;
```
1. Ersetzen Sie die Methode `shutdown` durch die folgenden neuen Methoden: `leaseLost`, `shardEnded` und `shutdownRequested`.
```
// @Override
// public void shutdownRequested(IRecordProcessorCheckpointer checkpointer) {
// //
// // This is moved to shardEnded(...)
// //
// try {
// checkpointer.checkpoint();
// } catch (ShutdownException | InvalidStateException e) {
// //
// // Swallow exception
// //
// e.printStackTrace();
// }
// }
@Override
public void leaseLost(LeaseLostInput leaseLostInput) {
}
@Override
public void shardEnded(ShardEndedInput shardEndedInput) {
try {
shardEndedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
//
// Swallow the exception
//
e.printStackTrace();
}
}
// @Override
// public void shutdownRequested(IRecordProcessorCheckpointer checkpointer) {
// //
// // This is moved to shutdownRequested(ShutdownReauestedInput)
// //
// try {
// checkpointer.checkpoint();
// } catch (ShutdownException | InvalidStateException e) {
// //
// // Swallow exception
// //
// e.printStackTrace();
// }
// }
@Override
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
try {
shutdownRequestedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
//
// Swallow the exception
//
e.printStackTrace();
}
}
```
Nachstehend finden Sie die aktualisierte Version der Datensatzprozessorklasse.
```
package com.amazonaws.kcl;
import software.amazon.kinesis.exceptions.InvalidStateException;
import software.amazon.kinesis.exceptions.ShutdownException;
import software.amazon.kinesis.lifecycle.events.InitializationInput;
import software.amazon.kinesis.lifecycle.events.LeaseLostInput;
import software.amazon.kinesis.lifecycle.events.ProcessRecordsInput;
import software.amazon.kinesis.lifecycle.events.ShardEndedInput;
import software.amazon.kinesis.lifecycle.events.ShutdownRequestedInput;
import software.amazon.kinesis.processor.ShardRecordProcessor;
public class TestRecordProcessor implements ShardRecordProcessor {
@Override
public void initialize(InitializationInput initializationInput) {
}
@Override
public void processRecords(ProcessRecordsInput processRecordsInput) {
}
@Override
public void leaseLost(LeaseLostInput leaseLostInput) {
}
@Override
public void shardEnded(ShardEndedInput shardEndedInput) {
try {
shardEndedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
//
// Swallow the exception
//
e.printStackTrace();
}
}
@Override
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
try {
shutdownRequestedInput.checkpointer().checkpoint();
} catch (ShutdownException | InvalidStateException e) {
//
// Swallow the exception
//
e.printStackTrace();
}
}
}
```
## Migrieren Sie den Plattenprozessor ab Werk
Die Datensatzprozessor-Factory ist für das Erstellen von Prozessoren verantwortlich, wenn eine Lease erworben wird. Nachfolgend sehen Sie ein Beispiel für eine KCL-1.x-Factory.
```
package com.amazonaws.kcl;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessorFactory;
public class TestRecordProcessorFactory implements IRecordProcessorFactory {
@Override
public IRecordProcessor createProcessor() {
return new TestRecordProcessor();
}
}
```
**So migrieren Sie die Datensatzprozessor-Factory**
1. Ändern Sie die implementierte Schnittstelle von `com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessorFactory` folgendermaßen nach `software.amazon.kinesis.processor.ShardRecordProcessorFactory`:
```
// import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessor;
import software.amazon.kinesis.processor.ShardRecordProcessor;
// import com.amazonaws.services.kinesis.clientlibrary.interfaces.v2.IRecordProcessorFactory;
import software.amazon.kinesis.processor.ShardRecordProcessorFactory;
// public class TestRecordProcessorFactory implements IRecordProcessorFactory {
public class TestRecordProcessorFactory implements ShardRecordProcessorFactory {
```
1. Ändern Sie die Rückgabesignatur für `createProcessor`.
```
// public IRecordProcessor createProcessor() {
public ShardRecordProcessor shardRecordProcessor() {
```
Es folgt ein Beispiel für die Verwendung der Datensatzprozessor-Factory in 2.0:
```
package com.amazonaws.kcl;
import software.amazon.kinesis.processor.ShardRecordProcessor;
import software.amazon.kinesis.processor.ShardRecordProcessorFactory;
public class TestRecordProcessorFactory implements ShardRecordProcessorFactory {
@Override
public ShardRecordProcessor shardRecordProcessor() {
return new TestRecordProcessor();
}
}
```
## Migrieren Sie den Worker
In Version 2.0 des KCL, einer neuen Klasse mit der Bezeichnung `Scheduler`, wird die `Worker`-Klasse ersetzt. Nachfolgend sehen Sie ein Beispiel für einen KCL-1.x-Auftragnehmer.
```
final KinesisClientLibConfiguration config = new KinesisClientLibConfiguration(...)
final IRecordProcessorFactory recordProcessorFactory = new RecordProcessorFactory();
final Worker worker = new Worker.Builder()
.recordProcessorFactory(recordProcessorFactory)
.config(config)
.build();
```
**So migrieren Sie den Worker**
1. Ändern Sie die `import`-Anweisung für die `Worker`-Klasse in die Import-Anweisungen für die Klassen `Scheduler` und `ConfigsBuilder`.
```
// import com.amazonaws.services.kinesis.clientlibrary.lib.worker.Worker;
import software.amazon.kinesis.coordinator.Scheduler;
import software.amazon.kinesis.common.ConfigsBuilder;
```
1. Erstellen Sie `ConfigsBuilder` und `Scheduler` wie im folgenden Beispiel gezeigt.
Es wird empfohlen, dass Sie `KinesisClientUtil` zum Erstellen von `KinesisAsyncClient` und zum Konfigurieren von `maxConcurrency` in `KinesisAsyncClient` verwenden.
**Wichtig**
Für den Amazon Kinesis Client kann sich die Latenz möglicherweise signifikant erhöhen, sofern Sie `KinesisAsyncClient` nicht für einen `maxConcurrency`-Wert konfigurieren, der hoch genug ist, um alle Leases plus zusätzliche Verwendungen von `KinesisAsyncClient` zu ermöglichen.
```
import java.util.UUID;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClient;
import software.amazon.awssdk.services.cloudwatch.CloudWatchAsyncClient;
import software.amazon.awssdk.services.kinesis.KinesisAsyncClient;
import software.amazon.kinesis.common.ConfigsBuilder;
import software.amazon.kinesis.common.KinesisClientUtil;
import software.amazon.kinesis.coordinator.Scheduler;
...
Region region = Region.AP_NORTHEAST_2;
KinesisAsyncClient kinesisClient = KinesisClientUtil.createKinesisAsyncClient(KinesisAsyncClient.builder().region(region));
DynamoDbAsyncClient dynamoClient = DynamoDbAsyncClient.builder().region(region).build();
CloudWatchAsyncClient cloudWatchClient = CloudWatchAsyncClient.builder().region(region).build();
ConfigsBuilder configsBuilder = new ConfigsBuilder(streamName, applicationName, kinesisClient, dynamoClient, cloudWatchClient, UUID.randomUUID().toString(), new SampleRecordProcessorFactory());
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig(),
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig()
);
```
## Den Amazon Kinesis-Client konfigurieren
Mit Version 2.0 der Kinesis Client Library wurde die Konfiguration des Clients aus einer einzelnen Konfigurationsklasse (`KinesisClientLibConfiguration`) in sechs Konfigurationsklassen verlagert. Die folgende Tabelle beschreibt die Migration.
**Konfigurationsfelder und ihre neue Klassen**
| Originalfeld | Neue Konfigurationsklasse | Description |
| --- | --- | --- |
| applicationName | ConfigsBuilder | Der Name für die KCL-Anwendung. Wird als Standard für tableName und consumerName verwendet. |
| tableName | ConfigsBuilder | Ermöglicht das Überschreiben des für die Lease-Tabelle von Amazon DynamoDB verwendeten Tabellennamens. |
| streamName | ConfigsBuilder | Der Name des Streams, dessen Datensätze diese Anwendung verarbeitet. |
| kinesisEndpoint | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| dynamoDBEndpoint | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| initialPositionInStreamExtended | RetrievalConfig | Der Speicherort im Shard, an dem die KCL mit der Ausführung der Anwendung durch Abrufen von Datensätzen beginnt. |
| kinesisCredentialsProvider | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| dynamoDBCredentialsProvider | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| cloudWatchCredentialsProvider | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| failoverTimeMillis | LeaseManagementConfig | Anzahl Millisekunden, nach deren Ablauf unterstellt werden kann, dass ein Lease-Eigentümer fehlgeschlagen ist. |
| workerIdentifier | ConfigsBuilder | Eine eindeutige Kennung, die die Instanziierung des Anwendungsprozessors repräsentiert. Dieser Wert muss eindeutig sein. |
| shardSyncIntervalMillis | LeaseManagementConfig | Die Zeit zwischen Shard-Synchronisierungsaufrufen. |
| maxRecords | PollingConfig | Ermöglicht das Einstellen der maximalen Anzahl an Datensätzen, die Kinesis zurückgibt. |
| idleTimeBetweenReadsInMillis | CoordinatorConfig | Diese Option wurde entfernt. Siehe "Entfernen der Leerlaufzeit". |
| callProcessRecordsEvenForEmptyRecordList | ProcessorConfig | Wenn diese Option aktiviert ist, wird der Datensatzprozessor aufgerufen, auch wenn Kinesis keine Datensätze bereitgestellt hat. |
| parentShardPollIntervalMillis | CoordinatorConfig | Gibt an, wie oft ein Datensatzprozessor abfragen soll, ob der übergeordnete Shard abgeschlossen wurde. |
| cleanupLeasesUponShardCompletion | LeaseManagementConfig | Wenn diese Option aktiviert ist, werden Leases entfernt, sobald die untergeordneten Leases die Verarbeitung gestartet haben. |
| ignoreUnexpectedChildShards | LeaseManagementConfig | Wenn diese Option aktiviert ist, werden untergeordnete Shards, die einen offenen Shard aufweisen, ignoriert. Dies gilt hauptsächlich für DynamoDB Streams. |
| kinesisClientConfig | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| dynamoDBClientConfig | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| cloudWatchClientConfig | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| taskBackoffTimeMillis | LifecycleConfig | Die Wartezeit beim erneuten Versuchen von fehlgeschlagenen Aufgaben. |
| metricsBufferTimeMillis | MetricsConfig | Steuert die Veröffentlichung von CloudWatch Metriken. |
| metricsMaxQueueSize | MetricsConfig | Steuert die Veröffentlichung von CloudWatch Metriken. |
| metricsLevel | MetricsConfig | Steuert die Veröffentlichung von CloudWatch Metriken. |
| metricsEnabledDimensions | MetricsConfig | Steuert die Veröffentlichung von CloudWatch Metriken. |
| validateSequenceNumberBeforeCheckpointing | CheckpointConfig | Diese Option wurde entfernt. Siehe "Checkpoint Sequence Number Validation". |
| regionName | ConfigsBuilder | Diese Option wurde entfernt. Siehe "Entfernen von Client-Konfigurationen". |
| maxLeasesForWorker | LeaseManagementConfig | Die maximale Anzahl der Leases, die eine einzelne Instance der Anwendung akzeptieren sollte. |
| maxLeasesToStealAtOneTime | LeaseManagementConfig | Die maximale Anzahl der Leases, die eine Anwendung zu einem gegebenen Zeitpunkt zu stehlen versuchen sollte. |
| initialLeaseTableReadCapacity | LeaseManagementConfig | Der DynamoDB-Lesevorgang IOPs , der verwendet wird, wenn die Kinesis-Clientbibliothek eine neue DynamoDB-Leasetabelle erstellen muss. |
| initialLeaseTableWriteCapacity | LeaseManagementConfig | Der DynamoDB-Lesevorgang IOPs , der verwendet wird, wenn die Kinesis-Clientbibliothek eine neue DynamoDB-Leasetabelle erstellen muss. |
| initialPositionInStreamExtended | LeaseManagementConfig | Die ursprüngliche Position im Stream, an der die Anwendung starten soll. Dieser Wert wird nur im Rahmen der Lease-Erstellung verwendet. |
| skipShardSyncAtWorkerInitializationIfLeasesExist | CoordinatorConfig | Synchronisieren der Shard-Daten deaktivieren, wenn die Lease-Tabelle Leases enthält. KinesisEcoTODO: -438 |
| shardPrioritization | CoordinatorConfig | Welche Shard-Priorisierung verwendet werden soll. |
| shutdownGraceMillis | – | Diese Option wurde entfernt. Siehe Umzüge. MultiLang |
| timeoutInSeconds | – | Diese Option wurde entfernt. Siehe MultiLang Umzüge. |
| retryGetRecordsInSeconds | PollingConfig | Konfiguriert die Verzögerung zwischen GetRecords Fehlversuchen. |
| maxGetRecordsThreadPool | PollingConfig | Die Thread-Pool-Größe, die für GetRecords verwendet wird. |
| maxLeaseRenewalThreads | LeaseManagementConfig | Steuert die Größe des Lease-Renewer-Thread-Pools. Dieser Pool muss größer sein, wenn die Anwendung mehr Leases annehmen kann. |
| recordsFetcherFactory | PollingConfig | Ermöglicht es, die Voreinstellung zu ersetzen, die zum Erstellen von Fetchers verwendet wird, die von Streams abrufen. |
| logWarningForTaskAfterMillis | LifecycleConfig | Wartezeit, bevor eine Warnung protokolliert wird, wenn eine Aufgabe nicht abgeschlossen wurde. |
| listShardsBackoffTimeInMillis | RetrievalConfig | Die Anzahl der zwischen Aufrufen von ListShards abzuwartenden Millisekunden, wenn es zu Fehlern kommt. |
| maxListShardsRetryAttempts | RetrievalConfig | Die maximale Anzahl Wiederholungsversuche durch ListShards, bevor abgebrochen wird. |
## Entfernung von Leerlaufzeiten
In Version 1.x von KCL wurde `idleTimeBetweenReadsInMillis` für zwei Werte verwendet:
+ Zeitraum zwischen Task-Versandprüfungen. Sie können diesen Zeitraum zwischen Tasks jetzt mit `CoordinatorConfig#shardConsumerDispatchPollIntervalMillis` konfigurieren.
+ Zeit im Ruhemodus, wenn keine Datensätze von Kinesis Data Streams zurückgegeben wurden. In Version 2.0 werden Datensätze im Rahmen der verbesserten Rundsendung von den jeweiligen Abrufern im Push-Verfahren übermittelt. Aktivitäten auf dem Shard-Konsumenten treten nur auf, wenn eine Anforderung per Push ankommt.
## Entfernung der Client-Konfiguration
In Version 2.0 erstellt KCL keine Clients mehr. Der Benutzer muss einen gültigen Client bereitstellen. Mit dieser Änderung wurden alle Konfigurationsparameter für die Client-Erstellung entfernt. Wenn Sie diese Parameter benötigen, können Sie sie in den Clients einstellen, bevor die Clients für `ConfigsBuilder` bereitgestellt werden.
****
| Entferntes Field | Äquivalente Konfiguration |
| --- | --- |
| kinesisEndpoint | Konfigurieren Sie das SDK KinesisAsyncClient mit dem bevorzugten Endpunkt: KinesisAsyncClient.builder().endpointOverride(URI.create("https://")).build(). |
| dynamoDBEndpoint | Konfigurieren Sie das SDK DynamoDbAsyncClient mit dem bevorzugten Endpunkt: DynamoDbAsyncClient.builder().endpointOverride(URI.create("https://")).build(). |
| kinesisClientConfig | Konfigurieren Sie das SDK KinesisAsyncClient mit der benötigten Konfiguration: KinesisAsyncClient.builder().overrideConfiguration().build(). |
| dynamoDBClientConfig | Konfigurieren Sie das SDK DynamoDbAsyncClient mit der benötigten Konfiguration: DynamoDbAsyncClient.builder().overrideConfiguration().build(). |
| cloudWatchClientConfig | Konfigurieren Sie das SDK CloudWatchAsyncClient mit der benötigten Konfiguration: CloudWatchAsyncClient.builder().overrideConfiguration().build(). |
| regionName | Konfigurieren Sie das SDK mit der bevorzugten Region. Dies ist für alle SDK-Clients gleich. Beispiel, KinesisAsyncClient.builder().region(Region.US\$1WEST\$12).build(). |
# Entwickeln Sie Verbraucher mit dem AWS SDK für Java
Mithilfe der Amazon Kinesis Data Streams APIs können Sie benutzerdefinierte Verbraucher entwickeln. In diesem Abschnitt wird die Verwendung der Kinesis Data Streams APIs mit dem AWS SDK für Java beschrieben.
**Wichtig**
Die empfohlene Methode zur Entwicklung benutzerdefinierter Verbraucher von Kinesis Data Streams mit durchgängiger gemeinsamer Nutzung ist die Verwendung der Kinesis Client Library (KCL). KCL unterstützt Sie bei der Nutzung und Verarbeitung von Daten aus einem Kinesis-Datenstrom, indem sie sich um viele der komplexen Aufgaben kümmert, die mit verteilter Datenverarbeitung verbunden sind. Weitere Informationen finden Sie unter [Entwickeln Sie Verbraucher mit KCL in Java](develop-kcl-consumers-java.md).
**Topics**
+ [
# Entwickeln Sie Verbraucher mit gemeinsamem Durchsatz mit dem AWS SDK für Java
](developing-consumers-with-sdk.md)
+ [
# Entwickeln Sie mehr Fan-Out-Nutzer mit dem AWS SDK für Java
](building-enhanced-consumers-api.md)
+ [
# Interagieren Sie mit Daten mithilfe der Schema Registry AWS Glue
](building-enhanced-consumers-glue-schema-registry.md)
# Entwickeln Sie Verbraucher mit gemeinsamem Durchsatz mit dem AWS SDK für Java
Eine der Methoden zur Entwicklung benutzerdefinierter Kinesis Data Streams-Verbraucher, die durchgehend gemeinsam genutzt werden, ist die Verwendung von Amazon Kinesis Data Streams APIs mit dem. AWS SDK für Java In diesem Abschnitt wird die Verwendung der Kinesis Data Streams APIs mit dem AWS SDK für Java beschrieben. Sie können die Kinesis Data Streams APIs mit anderen Programmiersprachen aufrufen. Weitere Informationen zu allen verfügbaren AWS SDKs Produkten finden Sie unter [Start Developing with Amazon Web Services](https://aws.amazon.com/developers/getting-started/).
Der Java-Beispielcode in diesem Abschnitt zeigt, wie grundlegende Kinesis Data Streams Streams-API-Operationen ausgeführt werden. Er ist logisch nach Operationstypen unterteilt. Diese Beispiele stellen keinen produktionsbereiten Code dar. Sie überprüfen nicht alle möglichen Ausnahmen und es werden nicht alle möglichen Sicherheits- oder Leistungsüberlegungen berücksichtigt.
**Topics**
+ [
## Daten aus einem Stream abrufen
](#kinesis-using-sdk-java-get-data)
+ [
## Verwenden Sie Shard-Iteratoren
](#kinesis-using-sdk-java-get-data-shard-iterators)
+ [
## Benutze GetRecords
](#kinesis-using-sdk-java-get-data-getrecords)
+ [
## Passt euch an einen Reshard an
](#kinesis-using-sdk-java-get-data-reshard)
## Daten aus einem Stream abrufen
Die Kinesis Data Streams APIs umfassen die `getRecords` Methoden `getShardIterator` und, die Sie aufrufen können, um Datensätze aus einem Datenstream abzurufen. Dies ist das PULL-Modell, bei dem der Code Datensätze direkt aus den Shards des Datenstroms abruft.
**Wichtig**
Wir empfehlen Ihnen, die von KCL bereitgestellte Unterstützung für Datensatzprozessoren zu verwenden, um Datensätze aus Ihren Datenströmen abzurufen. Dies ist das PUSH-Modell, bei dem Sie den Code implementieren, der die Daten verarbeitet. Die KCL ruft Datensätze aus dem Datenstrom ab und übermittelt diese an Ihren Anwendungscode. Darüber hinaus bietet die KCL Funktionen für einen Failover, eine Wiederherstellung und eine Lastverteilung. Weitere Informationen finden Sie unter [Entwickeln benutzerdefinierter Verbraucher mit gemeinsamem Durchsatz mithilfe von KCL](https://docs.aws.amazon.com/streams/latest/dev/shared-throughput-kcl-consumers.html).
In einigen Fällen ziehen Sie es jedoch möglicherweise vor, die Kinesis Data Streams APIs zu verwenden. Dies ist beispielsweise der Fall, wenn Sie benutzerdefinierte Tools für das Überwachen und Debuggen Ihrer Datenströme implementieren.
**Wichtig**
Kinesis Data Streams unterstützt Änderungen des Zeitraums der Datensatzaufbewahrung für einen Datenstrom. Weitere Informationen finden Sie unter [Ändern Sie den Aufbewahrungszeitraum für Daten](kinesis-extended-retention.md).
## Verwenden Sie Shard-Iteratoren
Sie rufen Datensätze aus dem Stream pro Shard ab. Für jeden Shard und jeden Datensatzstapel, den Sie aus dem Shard abrufen, benötigen Sie einen *Shard-Iterator*. Der Shard-Iterator wird im `getRecordsRequest`-Objekt verwendet, um den Shard anzugeben, aus dem die Datensätze abgerufen werden. Der Typ, der dem Shard-Iterator zugeordnet ist, gibt die Stelle im Shard an, von der die Datensätze abgerufen werden sollen (weitere Informationen dazu finden Sie später in diesem Abschnitt). Bevor Sie mit dem Shard-Iterator arbeiten können, müssen Sie den Shard abrufen. Weitere Informationen finden Sie unter [Shards auflisten](kinesis-using-sdk-java-list-shards.md).
Rufen Sie diesen ersten Shard-Iterator mit der `getShardIterator`-Methode ab. Rufen Sie Shard-Iteratoren für weitere Datensatzstapel mit der `getNextShardIterator` -Methode des `getRecordsResult`-Objekts ab, das von der `getRecords`-Methode zurückgegeben wird. Ein Shard-Iterator verliert seine Gültigkeit nach 5 Minuten. Wenn Sie einen Shard-Iterator verwenden, solange er gültig ist, erhalten Sie einen neuen. Jeder Shard-Iterator ist 5 Minuten lang gültig, selbst wenn er bereits verwendet wurde.
Instanziieren Sie `GetShardIteratorRequest`, um den ersten Shard-Iterator abzurufen. Übergeben Sie ihn an die `getShardIterator`-Methode. Geben Sie zum Konfigurieren der Anforderung den Stream und die Shard-ID an. Informationen darüber, wie Sie die Streams in Ihrem AWS Konto abrufen können, finden Sie unter. [Auflisten von Streams](kinesis-using-sdk-java-list-streams.md) Informationen zum Abrufen der Shards in einem Stream finden Sie unter [Shards auflisten](kinesis-using-sdk-java-list-shards.md).
```
String shardIterator;
GetShardIteratorRequest getShardIteratorRequest = new GetShardIteratorRequest();
getShardIteratorRequest.setStreamName(myStreamName);
getShardIteratorRequest.setShardId(shard.getShardId());
getShardIteratorRequest.setShardIteratorType("TRIM_HORIZON");
GetShardIteratorResult getShardIteratorResult = client.getShardIterator(getShardIteratorRequest);
shardIterator = getShardIteratorResult.getShardIterator();
```
Der Beispiel-Code gibt beim Abrufen des ersten Shard-Iterators `TRIM_HORIZON` als Iterator-Typ an. Dieser Iterator-Typ bedeutet, dass Datensätze zurückgegeben werden sollen. Und zwar beginnend mit dem ersten zum Shard hinzugefügten Datensatz und nicht mit dem letzten hinzugefügten Datensatz, auch als *Spitze* bezeichnet. Folgende Iterator-Typen werden unterstützt:
+ `AT_SEQUENCE_NUMBER`
+ `AFTER_SEQUENCE_NUMBER`
+ `AT_TIMESTAMP`
+ `TRIM_HORIZON`
+ `LATEST`
Weitere Informationen finden Sie unter [ShardIteratorType](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetShardIterator.html#Kinesis-GetShardIterator-request-ShardIteratorType).
Bei einigen Iterator-Typen müssen Sie zusätzlich eine Sequenznummer angeben, z. B.:
```
getShardIteratorRequest.setShardIteratorType("AT_SEQUENCE_NUMBER");
getShardIteratorRequest.setStartingSequenceNumber(specialSequenceNumber);
```
Nachdem Sie einen Datensatz mit `getRecords` abgerufen haben, erhalten Sie die Sequenznummer für den Datensatz, indem Sie die `getSequenceNumber`-Methode des Datensatzes aufrufen.
```
record.getSequenceNumber()
```
Darüber hinaus erhält der Code, durch den Datensätze zum Stream hinzufügt werden, die Sequenznummer für einen hinzugefügten Datensatz, indem `getSequenceNumber` auf dem Ergebnis von `putRecord` aufgerufen wird.
```
lastSequenceNumber = putRecordResult.getSequenceNumber();
```
Sie können mit diesen Sequenznummern eine strenge aufsteigende Anordnung der Datensätze gewährleisten. Weitere Informationen finden Sie im Code-Beispiel unter [PutRecord Beispiel](developing-producers-with-sdk.md#kinesis-using-sdk-java-putrecord-example).
## Benutze GetRecords
Instanziieren Sie nach Abruf des Shard-Iterators ein `GetRecordsRequest`-Objekt. Geben Sie den Iterator für die Anforderung mit der `setShardIterator`-Methode an.
Optional können Sie auch die Anzahl der abzurufenden Datensätze mithilfe der `setLimit`-Methode angeben. Die Anzahl der Datensätze, die `getRecords` zurückgibt, ist stets gleich oder kleiner als dieses Limit. Wenn Sie kein Limit angeben, gibt `getRecords` 10 MB abgerufener Datensätze zurück. Beim unten stehenden Beispiel-Code wird das Limit auf 25 Datensätze festgelegt.
Wenn keine Datensätze zurückgegeben werden, bedeutet dies, dass derzeit keine Datensätze von diesem Shard für die vom Shard-Iterator angegebene Sequenznummer verfügbar sind. Wenn dies der Fall ist, sollte Ihre Anwendung so lange warten, wie dies für die Datenquellen des Streams angemessen ist. Versuchen Sie dann erneut mit dem Shard-Iterator, der vom vorherigen Aufruf von `getRecords` zurückgegeben wurde, Daten aus dem Shard abzurufen.
Übergeben Sie `getRecordsRequest` an die `getRecords`-Methode und erfassen Sie die zurückgegebenen Werte als `getRecordsResult`-Objekt. Rufen Sie die `getRecords`-Methode auf dem `getRecordsResult`-Objekt auf, um die Datensätze abzurufen.
```
GetRecordsRequest getRecordsRequest = new GetRecordsRequest();
getRecordsRequest.setShardIterator(shardIterator);
getRecordsRequest.setLimit(25);
GetRecordsResult getRecordsResult = client.getRecords(getRecordsRequest);
List records = getRecordsResult.getRecords();
```
Zur Vorbereitung auf einen weiteren Aufruf von `getRecords` rufen Sie den nächsten Shard-Iterator von `getRecordsResult` ab.
```
shardIterator = getRecordsResult.getNextShardIterator();
```
Die besten Ergebnisse erzielen Sie, wenn Sie mindestens 1 Sekunde (1.000 Millisekunden) zwischen den Aufrufen von `getRecords` warten, um ein Überschreiten des Limits für die Aufrufe von `getRecords` zu vermeiden.
```
try {
Thread.sleep(1000);
}
catch (InterruptedException e) {}
```
In der Regel sollten Sie `getRecords` in einer Schleife aufrufen, auch wenn Sie einen einzelnen Datensatz in einem Testszenario abrufen. Ein einzelner Aufruf von `getRecords` gibt möglicherweise eine leere Datensatzliste zurück, auch wenn der Shard mehrere Datensätze mit höheren Sequenznummern enthält. In diesem Fall verweist der zurückgegebene `NextShardIterator` zusammen mit der leeren Datensatzliste auf eine höhere Sequenznummer im Shard. Nachfolgende Aufrufe von `getRecords` führen dann zu einem erfolgreichen Abruf. Das folgende Beispiel zeigt die Verwendung einer Schleife.
**Beispiel: getRecords**
Das folgende Codebeispiel spiegelt die `getRecords`-Tipps in diesem Abschnitt wieder, einschließlich der Aufrufe in Schleifen.
```
// Continuously read data records from a shard
List records;
while (true) {
// Create a new getRecordsRequest with an existing shardIterator
// Set the maximum records to return to 25
GetRecordsRequest getRecordsRequest = new GetRecordsRequest();
getRecordsRequest.setShardIterator(shardIterator);
getRecordsRequest.setLimit(25);
GetRecordsResult result = client.getRecords(getRecordsRequest);
// Put the result into record list. The result can be empty.
records = result.getRecords();
try {
Thread.sleep(1000);
}
catch (InterruptedException exception) {
throw new RuntimeException(exception);
}
shardIterator = result.getNextShardIterator();
}
```
Bei der Nutzung der Kinesis Client Library müssen möglicherweise mehrere Aufrufe durchgeführt werden, ehe Daten zurückgegeben werden. Dieses Verhalten ist Design-bedingt und kein Fehler der KCL oder Ihrer Daten.
## Passt euch an einen Reshard an
Wenn `getRecordsResult.getNextShardIterator` `null` zurückgibt, bedeutet dies, dass eine Aufteilung oder Zusammenführung des Shards stattgefunden hat, die diesen Shard betrifft. Dieser Shard befindet sich jetzt in einem `CLOSED`-Status und Sie haben alle verfügbaren Datensätze von diesem Shard gelesen.
In diesem Szenario können Sie `getRecordsResult.childShards` verwenden, um etwas über die neuen untergeordneten Shards des zu verarbeitenden Shards zu erfahren, die durch die Aufteilung oder Zusammenführung entstanden sind. Weitere Informationen finden Sie unter [ChildShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ChildShard.html).
Bei einer Teilung ist die `parentShardId` der beiden neuen Shards gleich der Shard-ID des zuvor verarbeiteten Shards. Der Wert von `adjacentParentShardId` für beide Shards ist `null`.
Bei einer Zusammenführung ist bei dem entstandenen einzelnen Datensatz die `parentShardId` identisch mit der Shard-ID eines übergeordneten Shards und die `adjacentParentShardId` ist gleich der Shard-ID des anderen übergeordneten Shards. Ihre Anwendung hat bereits alle Daten aus einem dieser Shards ausgelesen. Dies ist der Shard, für den `getRecordsResult.getNextShardIterator` `null` zurückgegeben hat. Wenn die Reihenfolge der Daten für Ihre Anwendung von Bedeutung ist, stellen Sie sicher, dass die Anwendung auch alle Daten des anderen übergeordneten Shards ausliest, ehe neue Daten aus dem durch die Zusammenführung entstandenen untergeordneten Shards ausgelesen werden.
Wenn Sie mehrere Prozessoren zum Abrufen von Daten aus dem Stream verwenden (beispielsweise einen Prozessor pro Shard), und es kommt zu einer Teilung oder Zusammenführung von Shards, sollten Sie die Anzahl der Prozessoren entsprechend anpassen.
Weitere Informationen zum Resharding, einschließlich einer Diskussion über Shard-Status, beispielsweise `CLOSED` finden Sie unter [Einen Stream erneut teilen](kinesis-using-sdk-java-resharding.md).
# Entwickeln Sie mehr Fan-Out-Nutzer mit dem AWS SDK für Java
*Erweitertes Rundsenden* ist ein Feature in Amazon Kinesis Data Streams, die es Verbrauchern ermöglicht, Datensätze aus einem Datenstrom mit einem dedizierten Durchsatz von bis zu 2 MB Daten pro Sekunde pro Shard zu empfangen. Ein Verbraucher, der ein erweitertes Rundsenden verwendet, muss nicht mit anderen Verbrauchern konkurrieren, die Daten aus dem Stream empfangen. Weitere Informationen finden Sie unter [Entwickeln Sie verbesserte Fan-Out-Verbraucher mit dediziertem Durchsatz](enhanced-consumers.md).
Sie können API-Operationen zum Erstellen eines Verbrauchers in Kinesis Data Streams verwenden der erweitertes Rundsenden verwendet.
**Einen Verbraucher mit erweitertem Rundsenden unter Verwendung der API für Kinesis Data Streams registrieren**
1. Rufen Sie an [RegisterStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_RegisterStreamConsumer.html), um Ihre Anwendung als Endverbraucher zu registrieren, der den erweiterten Fan-Out verwendet. Kinesis Data Streams generiert einen Amazon-Ressourcennamen (ARN) für den Verbraucher und gibt ihn in der Antwort zurück.
1. Um mit dem Abhören eines bestimmten Shards zu beginnen, geben Sie den Kunden-ARN in einem Anruf an [SubscribeToShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_SubscribeToShard.html)weiter. Kinesis Data Streams beginnt dann, die Datensätze von diesem Shard in Form von Ereignissen des Typs [SubscribeToShardEvent](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_SubscribeToShardEvent.html)über eine HTTP/2-Verbindung an Sie weiterzuleiten. Die Verbindung bleibt für bis zu 5 Minuten offen. Rufen Sie [SubscribeToShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_SubscribeToShard.html)erneut an, wenn Sie weiterhin Datensätze von dem Shard empfangen möchten`future`, nachdem der vom Anruf zurückgegebene Shard normal oder ausnahmsweise [SubscribeToShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_SubscribeToShard.html)abgeschlossen wurde.
**Anmerkung**
Die `SubscribeToShard`-API gibt auch die Liste der untergeordneten Shards des aktuellen Shards zurück, wenn das Ende des aktuellen Shards erreicht ist.
1. Rufen Sie an, um einen Verbraucher abzumelden, der den erweiterten Fan-Out verwendet. [DeregisterStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_DeregisterStreamConsumer.html)
Der folgende Code ist ein Beispiel dafür, wie Sie für Ihren Verbraucher ein Abonnement für einen Shard einrichten, das Abonnement regelmäßig erneuern und die Ereignisse verarbeiten können.
```
import software.amazon.awssdk.services.kinesis.KinesisAsyncClient;
import software.amazon.awssdk.services.kinesis.model.ShardIteratorType;
import software.amazon.awssdk.services.kinesis.model.SubscribeToShardEvent;
import software.amazon.awssdk.services.kinesis.model.SubscribeToShardRequest;
import software.amazon.awssdk.services.kinesis.model.SubscribeToShardResponseHandler;
import java.util.concurrent.CompletableFuture;
/**
* See https://github.com/awsdocs/aws-doc-sdk-examples/blob/master/javav2/example_code/kinesis/src/main/java/com/example/kinesis/KinesisStreamEx.java
* for complete code and more examples.
*/
public class SubscribeToShardSimpleImpl {
private static final String CONSUMER_ARN = "arn:aws:kinesis:us-east-1:123456789123:stream/foobar/consumer/test-consumer:1525898737";
private static final String SHARD_ID = "shardId-000000000000";
public static void main(String[] args) {
KinesisAsyncClient client = KinesisAsyncClient.create();
SubscribeToShardRequest request = SubscribeToShardRequest.builder()
.consumerARN(CONSUMER_ARN)
.shardId(SHARD_ID)
.startingPosition(s -> s.type(ShardIteratorType.LATEST)).build();
// Call SubscribeToShard iteratively to renew the subscription periodically.
while(true) {
// Wait for the CompletableFuture to complete normally or exceptionally.
callSubscribeToShardWithVisitor(client, request).join();
}
// Close the connection before exiting.
// client.close();
}
/**
* Subscribes to the stream of events by implementing the SubscribeToShardResponseHandler.Visitor interface.
*/
private static CompletableFuture callSubscribeToShardWithVisitor(KinesisAsyncClient client, SubscribeToShardRequest request) {
SubscribeToShardResponseHandler.Visitor visitor = new SubscribeToShardResponseHandler.Visitor() {
@Override
public void visit(SubscribeToShardEvent event) {
System.out.println("Received subscribe to shard event " + event);
}
};
SubscribeToShardResponseHandler responseHandler = SubscribeToShardResponseHandler
.builder()
.onError(t -> System.err.println("Error during stream - " + t.getMessage()))
.subscriber(visitor)
.build();
return client.subscribeToShard(request, responseHandler);
}
}
```
Wenn `event.ContinuationSequenceNumber` `null` zurückgibt, bedeutet dies, dass eine Aufteilung oder Zusammenführung des Shards stattgefunden hat, die diesen Shard betrifft. Dieser Shard befindet sich jetzt in einem `CLOSED`-Status und Sie haben alle verfügbaren Datensätze von diesem Shard gelesen. In diesem Szenario können Sie, wie im obigen Beispiel, `event.childShards` verwenden, um etwas über die neuen untergeordneten Shards des zu verarbeitenden Shards zu erfahren, die durch die Aufteilung oder Zusammenführung entstanden sind. Weitere Informationen finden Sie unter [ChildShard](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_ChildShard.html).
# Interagieren Sie mit Daten mithilfe der Schema Registry AWS Glue
Sie können Ihre Kinesis-Datenströme in die AWS Glue Schema Registry integrieren. Mit der AWS Glue Schema Registry können Sie Schemas zentral erkennen, steuern und weiterentwickeln und gleichzeitig sicherstellen, dass die erstellten Daten kontinuierlich anhand eines registrierten Schemas validiert werden. Ein Schema definiert die Struktur und das Format eines Datensatzes. Ein Schema ist eine versionierte Spezifikation für zuverlässige Datenveröffentlichung, -nutzung oder -speicherung. Mit der AWS Glue Schema Registry können Sie die end-to-end Datenqualität und Datenverwaltung in Ihren Streaming-Anwendungen verbessern. Weitere Informationen finden Sie unter [AWS Glue Schema Registry](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html). Eine Möglichkeit, diese Integration einzurichten, ist die `GetRecords` Kinesis Data Streams Streams-API, die im AWS Java SDK verfügbar ist.
Detaillierte Anweisungen zur Einrichtung der Integration von Kinesis Data Streams mit Schema Registry mithilfe der `GetRecords` Kinesis Data Streams APIs finden Sie im Abschnitt „Interaktion mit Daten mithilfe der Kinesis Data Streams APIs“ unter [Anwendungsfall: Integration von Amazon Kinesis Data Streams mit der AWS](https://docs.aws.amazon.com/glue/latest/dg/schema-registry-integrations.html#schema-registry-integrations-kds) Glue Schema Registry.
# Entwickeln Sie Verbraucher mit AWS Lambda
Sie können eine AWS Lambda Funktion verwenden, um Datensätze in einem Datenstrom zu verarbeiten. AWS Lambda ist ein Rechendienst, mit dem Sie Code ausführen können, ohne Server bereitzustellen oder zu verwalten. Es führt Ihren Code nur bei Bedarf aus und skaliert automatisch – von einigen Anfragen pro Tag bis zu Tausenden pro Sekunde. Sie zahlen nur für die tatsächlich aufgewendete Zeit. Es werden keine Gebühren berechnet, solange Ihr Code nicht ausgeführt wird. Mit AWS Lambda können Sie Code für praktisch jede Art von Anwendung oder Back-End-Dienst ausführen, und das alles ohne Verwaltungsaufwand. Der Service führt Ihren Code auf einer hoch verfügbaren Datenverarbeitungsinfrastruktur aus and erledigt die gesamte Administration der Datenverarbeitungsressourcen, einschließlich der Server- und Betriebssystemwartung, Kapazitätsbereitstellung und automatischen Skalierung sowie Code-Überwachung und -Protokollierung. Weitere Informationen finden Sie unter [Verwenden AWS Lambda mit Amazon Kinesis](/lambda/latest/dg/with-kinesis.html).
Informationen zur Fehlerbehebung finden Sie unter [Warum kann der Kinesis-Data-Streams-Trigger meine Lambda-Funktion nicht aufrufen?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-lambda-invocation/)
# Entwickeln Sie Kunden mithilfe von Amazon Managed Service für Apache Flink
Sie können eine Anwendung von Amazon Managed Service für Apache Flink verwenden, um Daten in einem Kinesis-Stream mit SQL, Java oder Scala zu verarbeiten und zu analysieren. Anwendungen des Managed Service für Apache Flink kann Daten mithilfe von Referenzquellen anreichern, Daten im Laufe der Zeit aggregieren oder Machine Learning verwenden, um Datenanomalien zu finden. Anschließend können Sie die Analyseergebnisse in einen anderen Kinesis-Stream, einen Firehose-Lieferstream oder eine Lambda-Funktion schreiben. Weitere Informationen finden Sie im [Entwicklerhandbuch für Managed Service für Apache Flink für SQL-Anwendungen](/kinesisanalytics/latest/dev/what-is.html) oder im [Entwicklerhandbuch für Managed Service für Apache Flink für Flink-Anwendungen](/kinesisanalytics/latest/java/what-is.html).
# Entwickeln Sie Verbraucher mithilfe von Amazon Data Firehose
Sie können einen Firehose verwenden, um Datensätze aus einem Kinesis-Stream zu lesen und zu verarbeiten. Firehose ist ein vollständig verwalteter Service für die Bereitstellung von Echtzeit-Streaming-Daten an Ziele wie Amazon S3, Amazon Redshift, Amazon OpenSearch Service und Splunk. Firehose unterstützt auch alle benutzerdefinierten HTTP-Endpunkte oder HTTP-Endpunkte, die unterstützten Drittanbietern gehören, darunter Datadog, MongoDB und New Relic. Sie können Firehose auch so konfigurieren, dass Ihre Datensätze transformiert und das Datensatzformat konvertiert wird, bevor Ihre Daten an das Ziel gesendet werden. Weitere Informationen finden Sie unter [Writing to Firehose Using Kinesis Data Streams](/firehose/latest/dev/writing-with-kinesis-streams.html).
# Daten aus Kinesis Data Streams mithilfe anderer AWS Dienste lesen
Die folgenden AWS Services können direkt in Amazon Kinesis Data Streams integriert werden, um Daten aus Kinesis-Datenströmen zu lesen. Überprüfen Sie die Informationen für jeden Service, an dem Sie interessiert sind, und verweisen Sie auf die bereitgestellten Referenzen.
**Topics**
+ [
# Daten aus Kinesis Data Streams mit Amazon EMR lesen
](using-other-services-emr.md)
+ [
# Daten aus Kinesis Data Streams mit Amazon EventBridge Pipes lesen
](using-other-services-ev-pipes.md)
+ [
# Daten aus Kinesis Data Streams lesen mit AWS Glue
](using-other-services-glue.md)
+ [
# Daten aus Kinesis Data Streams mit Amazon Redshift lesen
](using-other-services-redshift.md)
# Daten aus Kinesis Data Streams mit Amazon EMR lesen
Amazon EMR-Cluster können Kinesis-Streams direkt lesen und verarbeiten, indem sie vertraute Tools aus dem Hadoop-Ökosystem wie Hive, Pig MapReduce, die Hadoop Streaming API und Cascading verwenden. Sie können auch Echtzeitdaten aus Kinesis Data Streams mit vorhandenen Daten auf Amazon S3, Amazon DynamoDB und HDFS in einem laufenden Cluster verbinden. Zur Nachbearbeitung können Sie die Daten aus Amazon EMR direkt in Amazon S3 oder DynamoDB laden.
Weitere Informationen finden Sie unter [Amazon Kinesis](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-kinesis.html) im *Handbuch zu Amazon-EMR-Releases*.
# Daten aus Kinesis Data Streams mit Amazon EventBridge Pipes lesen
Amazon EventBridge Pipes unterstützt Kinesis-Datenstreams als Quelle. Amazon EventBridge Pipes unterstützt Sie bei der Erstellung von point-to-point Integrationen zwischen Veranstaltern und Verbrauchern mit optionalen Transformations-, Filter- und Anreicherungsschritten. Sie können EventBridge Pipes verwenden, um Datensätze in einem Kinesis-Datenstream zu empfangen und diese Datensätze optional zu filtern oder zu verbessern, bevor Sie sie zur Verarbeitung an eines der verfügbaren Ziele senden, einschließlich Kinesis Data Streams.
Weitere Informationen finden Sie unter [Amazon Kinesis Stream as a source](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes-kinesis.html) im *Amazon EventBridge Release Guide*.
# Daten aus Kinesis Data Streams lesen mit AWS Glue
Mit AWS Glue Streaming-ETL können Sie Streaming-Jobs zum Extrahieren, Transformieren und Laden (ETL) erstellen, die kontinuierlich ausgeführt werden und Daten aus Amazon Kinesis Data Streams verbrauchen. Die Aufträge bereinigen und transformieren die Daten und laden die Ergebnisse dann in Amazon-S3-Data-Lakes oder JDBC-Datenspeicher.
Weitere Informationen finden Sie unter [Streaming-ETL-Aufträge in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/add-job-streaming.html) im *AWS Glue -Release-Handbuch*.
# Daten aus Kinesis Data Streams mit Amazon Redshift lesen
Amazon Redshift unterstützt die Streaming-Erfassung von Amazon Kinesis Data Streams. Das Streaming-Erfassungs-Feature Amazon Redshift ermöglicht das Erfassen von Streaming-Daten mit geringer Latenz und hoher Geschwindigkeit aus Amazon Kinesis Data Streams in einer materialisierten Ansicht von Amazon Redshift. Durch die Amazon Redshift-Streaming-Aufnahme müssen Daten nicht mehr in Amazon S3 gespeichert werden, bevor sie in Amazon Redshift aufgenommen werden.
Weitere Informationen finden Sie unter [Streaming-Erfassung](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion.html) im *Handbuch zum Release von Amazon Redshift*.
# Lesen Sie mithilfe von Integrationen von Drittanbietern aus Kinesis Data Streams
Sie können Daten aus Amazon Kinesis Data Streams mit einer der folgenden Drittanbieteroptionen lesen, die in Kinesis Data Streams integriert sind. Wählen Sie die Option aus, über die Sie mehr erfahren möchten, und finden Sie Ressourcen und Links zu relevanter Dokumentation.
**Topics**
+ [
# Apache Flink
](using-other-services-read-flink.md)
+ [
# Adobe Experience Platform
](using-other-services-read-adobe.md)
+ [
# Apache Druid
](using-other-services-read-druid.md)
+ [
# Apache Spark
](using-other-services-read-spark.md)
+ [
# Databricks
](using-other-services-read-databricks.md)
+ [
# Kafka Confluent Plattform
](using-other-services-read-kafka.md)
+ [
# Kinesumer
](using-other-services-read-kinesumer.md)
+ [
# Talend
](using-other-services-read-talend.md)
# Apache Flink
Apache Flink ist ein Framework und eine verteilte Verarbeitungs-Engine für statusbehaftete Berechnungen über unbegrenzte und begrenzte Datenströme. Weitere Informationen zur Nutzung von Kinesis Data Streams mit Apache Flink finden Sie unter [Amazon Kinesis Data Streams Connector](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/connectors/datastream/kinesis/).
# Adobe Experience Platform
Die Adobe Experience Platform ermöglicht es Unternehmen, Kundendaten aus jedem System zu zentralisieren und zu standardisieren. Anschließend werden Datenwissenschaft und Machine Learning angewendet, um das Design und die Bereitstellung umfassender, personalisierter Erlebnisse erheblich zu verbessern. Weitere Informationen zur Nutzung von Kinesis-Datenströmen mit der Adobe Experience Platform finden Sie unter [Amazon Kinesis](https://experienceleague.adobe.com/docs/experience-platform/sources/connectors/cloud-storage/kinesis.html) Connector.
# Apache Druid
Druid ist eine hochleistungsfähige Echtzeit-Analysedatenbank, die Abfragen auf Streaming- und Batch-Daten in Sekundenschnelle und bei hoher Auslastung ermöglicht. Weitere Informationen zur Aufnahme von Kinesis-Datenströmen mit Apache Druid finden Sie unter [Amazon](https://druid.apache.org/docs/latest/development/extensions-core/kinesis-ingestion.html) Kinesis-Aufnahme.
# Apache Spark
Apache Spark ist eine einheitliche Analytics-Engine für die großflächige Datenverarbeitung. Es bietet hochwertige APIs Funktionen in Java, Scala, Python und R sowie eine optimierte Engine, die allgemeine Ausführungsdiagramme unterstützt. Sie können Apache Spark verwenden, um Anwendungen zur Stream-Verarbeitung zu erstellen, die die Daten in Ihren Kinesis-Datenströmen nutzen.
[Verwenden Sie den Amazon Kinesis Data Streams-Connector, um Kinesis-Datenstreams mit Apache Spark Structured Streaming zu nutzen.](https://github.com/awslabs/spark-sql-kinesis-connector) Dieser Connector unterstützt die Nutzung mit Enhanced Fan-Out, wodurch Ihre Anwendung einen dedizierten Lesedurchsatz von bis zu 2 MB Daten pro Sekunde und Shard erhält. Weitere Informationen finden Sie unter [Entwicklung benutzerdefinierter Verbraucher mit dediziertem Durchsatz (erweiterter Fan-Out)](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html).
Informationen zur Nutzung von Kinesis-Datenströmen mit Spark Streaming finden Sie unter [Spark Streaming \$1 Kinesis Integration](https://spark.apache.org/docs/latest/streaming-kinesis-integration.html).
# Databricks
Databricks ist eine Cloud-basierte Plattform, die eine kollaborative Umgebung für Datentechnik, Datenwissenschaft und Machine Learning bietet. Weitere Informationen zur Nutzung von Kinesis-Datenströmen mithilfe von Databricks finden Sie unter [Connect zu](https://docs.databricks.com/structured-streaming/kinesis.html) Amazon Kinesis herstellen.
# Kafka Confluent Plattform
Confluent Platform basiert auf Kafka und bietet zusätzliche Features und Funktionen, mit denen Unternehmen Daten-Pipelines und Streaming-Anwendungen in Echtzeit aufbauen und verwalten können. Weitere Informationen zur Nutzung von Kinesis-Datenströmen mithilfe der Confluent Platform finden Sie unter [Amazon Kinesis Source Connector](https://docs.confluent.io/kafka-connectors/kinesis/current/overview.html#features) for Confluent Platform.
# Kinesumer
Kinesumer ist ein Go-Client, der einen clientseitigen Client für verteilte Verbrauchergruppen für Kinesis-Datenströme implementiert. Weitere Informationen finden Sie im [Kinesumer-GitHub-Repository](https://github.com/daangn/kinesumer).
# Talend
Talend ist eine Datenintegrations- und Verwaltungssoftware, die es Benutzern ermöglicht, Daten aus verschiedenen Quellen auf skalierbare und effiziente Weise zu sammeln, zu transformieren und miteinander zu verbinden. Weitere Informationen zur Nutzung von Kinesis-Datenströmen mit Talend finden Sie unter Talend mit [einem Amazon Kinesis Kinesis-Stream Connect](https://help.talend.com/r/en-US/Cloud/connectors-guide/connector-kinesis).
# Problembehandlung bei Kinesis Data Streams Streams-Verbrauchern
**Topics**
+ [
## Kompilierungsfehler mit dem Konstruktor LeaseManagementConfig
](#compilation-error-leasemanagementconfig)
+ [
## Einige Kinesis Data Streams Streams-Datensätze werden bei der Verwendung der Kinesis Client Library übersprungen
](#records-skipped)
+ [
## Datensätze, die zu demselben Shard gehören, werden gleichzeitig von verschiedenen Datensatzprozessoren verarbeitet
](#records-belonging-to-the-same-shard)
+ [
## Die Verbraucheranwendung liest langsamer als erwartet
](#consumer-app-reading-slower)
+ [
## GetRecords gibt ein leeres Datensatz-Array zurück, auch wenn der Stream Daten enthält
](#getrecords-returns-empty)
+ [
## Der Shard-Iterator läuft unerwartet ab
](#shard-iterator-expires-unexpectedly)
+ [
## Die Verarbeitung von Verbraucherdaten hinkt hinterher
](#record-processing-falls-behind)
+ [
## Fehler beim Zugriff auf einen nicht autorisierten KMS-Schlüssel
](#unauthorized-kms-consumer)
+ [
## DynamoDbException: Der im Aktualisierungsausdruck angegebene Dokumentpfad ist für die Aktualisierung ungültig
](#dynamo-db-exception)
+ [
## Beheben Sie andere häufig auftretende Probleme von Verbrauchern
](#misc-troubleshooting-consumer)
## Kompilierungsfehler mit dem Konstruktor LeaseManagementConfig
Beim Upgrade auf Kinesis Client Library (KCL) Version 3.x oder höher kann ein Kompilierungsfehler auftreten, der mit dem Konstruktor zusammenhängt. `LeaseManagementConfig` Wenn Sie direkt ein `LeaseManagementConfig` Objekt erstellen, um Konfigurationen festzulegen, anstatt es `ConfigsBuilder` in KCL-Versionen 3.x oder höher zu verwenden, wird Ihnen beim Kompilieren Ihres KCL-Anwendungscodes möglicherweise die folgende Fehlermeldung angezeigt.
```
Cannot resolve constructor 'LeaseManagementConfig(String, DynamoDbAsyncClient, KinesisAsyncClient, String)'
```
Bei KCL mit Versionen 3.x oder höher müssen Sie nach dem TableName-Parameter einen weiteren Parameter, applicationName (Typ: String), hinzufügen.
+ *Vorher*: leaseManagementConfig = neu LeaseManagementConfig (TableName, Dynamo, KinesisClientDBClient, StreamName, WorkerIdentifier)
+ *Danach*: leaseManagementConfig = neu LeaseManagementConfig (tableName, **applicationName, Dynamo, KinesisClient, StreamName**DBClient, WorkerIdentifier)
Anstatt direkt ein LeaseManagementConfig Objekt zu erstellen, empfehlen `ConfigsBuilder` wir, Konfigurationen in KCL 3.x und späteren Versionen festzulegen. `ConfigsBuilder`bietet eine flexiblere und wartungsfreundlichere Methode zur Konfiguration Ihrer KCL-Anwendung.
Im Folgenden finden Sie ein Beispiel für die Verwendung `ConfigsBuilder` zum Festlegen von KCL-Konfigurationen.
```
ConfigsBuilder configsBuilder = new ConfigsBuilder(
streamName,
applicationName,
kinesisClient,
dynamoClient,
cloudWatchClient,
UUID.randomUUID().toString(),
new SampleRecordProcessorFactory()
);
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig()
.failoverTimeMillis(60000), // this is an example
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig()
);
```
## Einige Kinesis Data Streams Streams-Datensätze werden bei der Verwendung der Kinesis Client Library übersprungen
Der häufigste Grund für übersprungene Datensätzen ist ein Ausnahmefehler, der von `processRecords` ausgelöst wird. Die Kinesis Client Library (KCL) verlässt sich bei der Behandlung von Ausnahmen, die während der Verarbeitung von Datensätzen auftreten, auf Ihrem `processRecords`-Code. Alle von `processRecords` ausgelösten Ausnahmen werden von der KCL aufgenommen. Um unbegrenzte Wiederholungen eines Fehlers zu vermeiden, sendet die KCL den Datensatzstapel, der während der Ausnahme verarbeitet wurde, nicht erneut. Die KCL ruft stattdessen `processRecords` für den nächsten Datensatzstapel auf, ohne den Datensatzprozessor neu zu starten. Dies führt dazu, dass Konsumentenanwendungen übersprungene Datensätze erkennen. Zur Vermeidung übersprungener Datensätze müssen Sie alle Ausnahmen innerhalb von `processRecords` entsprechend behandeln.
## Datensätze, die zu demselben Shard gehören, werden gleichzeitig von verschiedenen Datensatzprozessoren verarbeitet
Ein Shard hat für jede ausgeführte Anwendung der Kinesis Client Library (KCL) nur einen Besitzer. Allerdings kann es vorkommen, dass mehrere Datensatzprozessoren vorübergehend denselben Shard verarbeiten. Wenn eine Worker-Instance die Netzwerkkonnektivität verliert, geht die KCL davon aus, dass der nicht erreichbare Worker nach Ablauf der Failover-Zeit keine Datensätze mehr verarbeitet, und weist andere Worker-Instances an, die Kontrolle zu übernehmen. Für eine kurze Zeit werden dann möglicherweise Daten aus demselben Shard von neuen Datensatzprozessoren und Datensatzprozessoren des nicht erreichbaren Workers verarbeitet.
Stellen Sie eine Failover-Zeit ein, die für Ihre Anwendung geeignet ist. Für Anwendungen mit geringer Latenz entspricht der Standardwert von 10 Sekunden möglicherweise dem Zeitraum, den Sie maximal bereit sind zu warten. In den Fällen jedoch, in denen Sie Verbindungsprobleme erwarten, beispielsweise bei Aufrufen über verschiedene geografische Bereiche hinweg, in denen häufiger mit Verbindungsproblemen zu rechnen ist, ist die Zeitspanne möglicherweise zu gering.
Ihre Anwendung sollte diesem Szenario abhelfen können, insbesondere, weil die Netzwerkanbindung in der Regel für den zuvor nicht erreichbaren Worker wiederhergestellt wird. Wenn die Shards eines Datensatzprozessors von einem anderen Datensatzprozessor übernommen werden, müssen folgende Fälle für ein ordnungsgemäßes Herunterfahren korrekt behandelt werden:
1. Nach Abschluss des aktuellen Aufrufs von ruft die KCL die Shutdown-Methode auf dem Recordprozessor mit dem Shutdown-Grund 'ZOMBIE' auf. `processRecords` Von Ihren Datensatzprozessoren wird erwartet, dass alle Ressourcen entsprechend bereinigt werden und die Datensatzprozessoren anschließend beendet werden.
1. Wenn Sie versuchen, ein Checkpointing mit einem „Zombie“-Worker durchzuführen, löst die KCL `ShutdownException` aus. Nach Empfang der Ausnahme ist die aktuelle Methode durch Ihren Code sauber zu beenden.
Weitere Informationen finden Sie unter [Behandeln Sie doppelte Datensätze](kinesis-record-processor-duplicates.md).
## Die Verbraucheranwendung liest langsamer als erwartet
Die häufigsten Gründe für einen langsameren Lesedurchsatz sind:
1. Bei mehreren Konsumentenanwendungen übersteigt die Anzahl der Lesevorgänge die pro Shard festgelegten Limits. Weitere Informationen finden Sie unter [Kontingente und -Einschränkungen](service-sizes-and-limits.md). Erhöhen Sie in diesem Fall die Anzahl der Shards im Kinesis-Datenstrom.
1. Das [Limit](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html#API_GetRecords_RequestSyntax) für die maximale Anzahl von **GetRecords** pro Aufruf ist möglicherweise zu niedrig festgelegt. Wenn Sie die KCL verwenden, haben Sie möglicherweise einen niedrigen Wert bei der `maxRecords`-Eigenschaft des Workers angegeben. Grundsätzlich empfehlen wir die Verwendung der Systemvoreinstellungen für diese Eigenschaft.
1. Die Logik in Ihrem `processRecords` Aufruf kann aus verschiedenen Gründen länger als erwartet dauern. Die Logik ist möglicherweise CPU-intensiv, I/O blockierend oder führt zu Engpässen bei der Synchronisation. Führen Sie leere Datensatzprozessoren aus und vergleichen Sie den Lesedurchsatz, um festzustellen, ob dies der Fall ist. Weitere Informationen dazu, wie Sie eingehende Daten zeitgerecht verarbeiten können, finden Sie unter [Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern](kinesis-record-processor-scaling.md).
Wenn Sie nur eine Konsumentenanwendung haben, ist es immer möglich, mindestens zwei Mal schneller als die PUT-Rate zu lesen. Das liegt daran, dass Sie bis zu 1 000 Datensätze pro Sekunde für Schreibvorgänge bis zu einem maximalen Datenschreibvolumen von 1 MB pro Sekunde (einschließlich Partitionsschlüsseln) schreiben können. Jeder offene Shard kann bis zu 5 Lesetransaktionen pro Sekunde unterstützen, bis zu einer maximalen Gesamtdatenleserate von 2 MB pro Sekunde. Beachten Sie, dass jeder Lesevorgang (**GetRecords**-Aufruf) einen Stapel an Datensätzen erhält. Die Menge der Daten, die von **GetRecords** zurückgegeben werden, hängt von der Shard-Auslastung ab. Die maximale Größe der Daten, die **GetRecords** zurückgeben kann, ist 10 MB. Wenn ein Anruf dieses Limit zurückgibt, lösen nachfolgende Aufrufe innerhalb der nächsten 5 Sekunden einen Fehler aus. `ProvisionedThroughputExceededException`
## GetRecords gibt ein leeres Datensatz-Array zurück, auch wenn der Stream Daten enthält
Beim Verbrauchen oder Empfangen von Datensätzen kommt ein PULL-Modell zum Einsatz. Von Entwicklern wird erwartet, dass sie [GetRecords](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html)in einer Dauerschleife ohne Back-offs aufrufen. Jeder Aufruf von **GetRecords** gibt auch einen `ShardIterator`-Wert zurück, der in der nächsten Iteration der Schleife verwendet wird.
Die **GetRecords**-Operation blockiert nicht. Stattdessen erfolgt sofort eine Rückgabe, entweder mit relevanten Datensätzen oder mit einem leeren `Records`-Element. Ein leeres `Records`-Element wird unter zwei Bedingungen zurückgegeben:
1. Im Shard sind derzeit keine weiteren Daten vorhanden.
1. Es gibt keine Daten in der Nähe des Shard-Inhalts, auf den `ShardIterator` zeigt.
Die letzte Bedingung ist subtil, aber eine notwendige Design-Komponente, durch die unbegrenzte Suchzeiten (Latenzen) beim Abrufen von Datensätzen vermieden werden. Daher sollte die Anwendung, die Daten aus dem Stream verbraucht, eine Schleife durchlaufen, **GetRecords** aufrufen und leere Datensätze verarbeiten.
In einer Produktionsumgebung sollte die Endlosschleife nur verlassen werden, wenn der Wert von `NextShardIterator` `NULL` ist. Wenn `NextShardIterator` `NULL` ist, bedeutet dies, dass der aktuelle Shard geschlossen wurde und der Wert von `ShardIterator` ansonsten auf eine Position hinter dem letzten Datensatz verweisen würde. Wenn die datenverbrauchende Anwendung **SplitShard** oder **MergeShards** nicht aufruft, bleibt der Shard offen und die Aufrufe von **GetRecords** geben niemals einen `NextShardIterator`-Wert von `NULL` zurück.
Wenn Sie die Kinesis Client Library (KCL) verwenden, wird das vorherige Verbrauchsmuster für Sie abstrahiert. Dies umfasst die automatische Handhabung einer Gruppe von Shards, die sich dynamisch ändert. Mit der KCL übermittelt der Entwickler nur die Logik für die Verarbeitung eingehender Datensätze. Dies ist möglich, da die Bibliothek **GetRecords** kontinuierlich für Sie aufruft.
## Der Shard-Iterator läuft unerwartet ab
Bei jeder **GetRecords**-Anforderung (wie `NextShardIterator`) wird ein neuer Shard-Iterator zurückgegeben, den Sie bei der nächsten **GetRecords**-Anforderung (wie `ShardIterator`) verwenden. In der Regel läuft dieser Shard-Iterator nicht vor der Verwendung ab. Es kann jedoch sein, dass Shard-Iteratoren ihre Gültigkeit verlieren, weil Sie **GetRecords** länger als 5 Minuten nicht aufgerufen oder die Konsumentenanwendung neu gestartet haben.
Wenn der Shard-Iterator unmittelbar abläuft, bevor Sie ihn verwenden können, kann dies darauf hindeuten, dass die von Kinesis verwendete DynamoDB-Tabelle nicht über genügend Kapazität zum Speichern der Lease-Daten verfügt. Diese Situation tritt häufiger auf, wenn Sie viele Shards haben. Beheben Sie das Problem, indem Sie die Schreibkapazität der Shard-Tabelle erhöhen. Weitere Informationen finden Sie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
## Die Verarbeitung von Verbraucherdaten hinkt hinterher
Bei den meisten Anwendungsfällen lesen die Konsumentenanwendungen die neuesten Daten aus dem Stream. Unter bestimmten Umständen hängt das Lesen des Konsumenten hinterher. Dieses Verhalten möglicherweise nicht erwünscht. Sehen Sie sich die häufigsten Gründe für ein zu langsames Lesen des Datenkonsumenten an, wenn Sie ermittelt haben, wie weit die Lesevorgänge des Konsumenten hinterherhängen.
Beginnen Sie mit der `GetRecords.IteratorAgeMilliseconds`-Metrik. Diese verfolgt die Leseposition aller Shards und Konsumenten im Stream. Beachten Sie: Wenn das Alter eines Iterators 50 % des Aufbewahrungszeitraums (standardmäßig 24 Stunden, anpassbar auf bis zu 365 Tage) überschreitet, besteht die Gefahr des Datenverlusts durch Datensatzablauf. Als schnelle Übergangslösung eignet sich eine Verlängerung des Aufbewahrungszeitraums. Auf diese Weise wird der Verlust von wichtigen Daten gestoppt, während Sie sich der weiteren Fehlerbehebung widmen. Weitere Informationen finden Sie unter [Überwachen Sie den Amazon Kinesis Data Streams Streams-Service mit Amazon CloudWatch](monitoring-with-cloudwatch.md). Identifizieren Sie als Nächstes anhand einer benutzerdefinierten CloudWatch Metrik, die von der Kinesis Client Library (KCL) ausgegeben wird, wie weit Ihre Verbraucheranwendung von jedem Shard liest. `MillisBehindLatest` Weitere Informationen finden Sie unter [Überwachen Sie die Kinesis-Clientbibliothek mit Amazon CloudWatch](monitoring-with-kcl.md).
Im Folgenden sind die häufigsten Gründe für ein Hinterherhängen von Konsumenten aufgeführt:
+ Plötzliche Anstiege auf `GetRecords.IteratorAgeMilliseconds` oder `MillisBehindLatest` weisen in der Regel auf ein vorübergehendes Problem hin, beispielsweise Fehler bei einer API-Operation in einer nachgelagerten Anwendung. Untersuchen Sie diese plötzlichen Erhöhungen, wenn eine der Metriken dieses Verhalten konsistent zeigt.
+ Eine allmählicher Anstieg dieser Metriken deutet darauf hin, dass ein Konsument Datensätze nicht schnell genug verarbeitet. Die häufigsten Ursachen für ein solches Verhalten sind unzureichende physische Ressourcen oder eine Datensatzverarbeitungslogik, die nicht für einen Anstieg des Stream-Durchsatzes skaliert wurde. Sie können dieses Verhalten überprüfen, indem Sie sich die anderen benutzerdefinierten CloudWatch Messwerte ansehen, die die KCL im Zusammenhang mit dem `processTask` Vorgang ausgibt, einschließlich `RecordProcessor.processRecords.Time``Success`, und. `RecordsProcessed`
+ Wenn Sie eine Erhöhung in der `processRecords.Time`-Metrik feststellen, die mit einem Anstieg des Durchsatzes korreliert, sollten Sie Ihre Datensatzverarbeitungslogik analysieren, um herauszufinden, warum sich diese nicht an den erhöhten Durchsatz anpasst.
+ Wenn Sie eine Erhöhung der `processRecords.Time`-Werte feststellen, die nicht in Zusammenhang mit einem erhöhten Durchsatz steht, prüfen Sie, ob im kritischen Pfad blockierende Aufrufe durchgeführt werden. Diese sind häufig der Grund für eine verlangsamte Datensatzverarbeitung. Alternativ können Sie auch die Parallelität durch eine Erhöhung der Anzahl der Shards erhöhen. Stellen Sie abschließend sicher, dass Sie bei Spitzenauslastung über eine ausreichende Menge an physischen Ressourcen (Arbeitsspeicher, CPU-Auslastung usw.) auf den zugrunde liegenden Verarbeitungsknoten verfügen.
## Fehler beim Zugriff auf einen nicht autorisierten KMS-Schlüssel
Dieser Fehler tritt auf, wenn eine Verbraucheranwendung ohne Berechtigungen für den AWS KMS Schlüssel aus einem verschlüsselten Stream liest. Informationen zum Zuweisen von Berechtigungen zu einer Anwendung für den Zugriff auf einen KMS-Schlüssel finden Sie unter [Verwenden von Schlüsselrichtlinien in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) und [Verwenden von IAM-Richtlinien mit AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html).
## DynamoDbException: Der im Aktualisierungsausdruck angegebene Dokumentpfad ist für die Aktualisierung ungültig
Wenn Sie KCL 3.x mit den AWS SDK für Java Versionen 2.27.19 bis 2.27.23 verwenden, kann die folgende DynamoDB-Ausnahme auftreten:
„software.amazon.awssdk.services.dynamodb.model. DynamoDbException: Der im Aktualisierungsausdruck angegebene Dokumentpfad ist für die Aktualisierung ungültig (Service:, Statuscode: 400, Anforderungs-ID: xxx)“ DynamoDb
Dieser Fehler tritt aufgrund eines bekannten Problems in der auf AWS SDK für Java , das die von KCL 3.x verwaltete DynamoDB-Metadatentabelle betrifft. Das Problem wurde in Version 2.27.19 eingeführt und betrifft alle Versionen bis 2.27.23. Das Problem wurde in Version 2.27.24 behoben. AWS SDK für Java Für optimale Leistung und Stabilität empfehlen wir ein Upgrade auf Version 2.28.0 oder höher.
## Beheben Sie andere häufig auftretende Probleme von Verbrauchern
+ [Warum kann der Kinesis-Data-Streams-Trigger meine Lambda-Funktion nicht aufrufen?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-lambda-invocation/)
+ [Wie erkenne und behebe ich ReadProvisionedThroughputExceeded Ausnahmen in Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-readprovisionedthroughputexceeded/)
+ [Warum habe ich Probleme mit hoher Latenz bei Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-stream-latency-issues/)
+ [Warum gibt mein Kinesis-Datenstrom einen 500 Internal Server Error zurück?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-stream-500-error/)
+ [Wie behebe ich Fehler bei einer blockierten oder hängengebliebenen KCL-Anwendung für Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kcl-kinesis-data-streams/)
+ [Kann ich verschiedene Anwendungen der Amazon Kinesis Client Library mit der gleichen Amazon-DynamoDB-Tabelle verwenden?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-kcl-apps-dynamodb-table/)
# Optimieren Sie die Verbraucher von Amazon Kinesis Data Streams
Sie können Ihren Amazon Kinesis Data Streams Streams-Nutzer auf der Grundlage des spezifischen Verhaltens, das Sie beobachten, weiter optimieren.
Sehen Sie sich die folgenden Themen an, um Lösungen zu finden.
**Topics**
+ [
# Verbessern Sie die Verarbeitung mit niedriger Latenz
](kinesis-low-latency.md)
+ [
# Verarbeiten Sie serialisierte Daten AWS Lambda mithilfe der Amazon Kinesis Producer Library
](kinesis-record-deaggregation.md)
+ [
# Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern
](kinesis-record-processor-scaling.md)
+ [
# Behandeln Sie doppelte Datensätze
](kinesis-record-processor-duplicates.md)
+ [
# Kümmere dich um das Starten, Herunterfahren und Drosseln
](kinesis-record-processor-additional-considerations.md)
# Verbessern Sie die Verarbeitung mit niedriger Latenz
*Die Übertragungsverzögerung* ist definiert als die end-to-end Latenz von dem Moment, in dem ein Datensatz in den Stream geschrieben wird, bis zu seinem Lesen durch eine Verbraucheranwendung. Diese Verzögerung variiert und hängt von vielen Faktoren ab, im Wesentlichen aber vom Abrufintervall der Konsumentenanwendungen.
Für die meisten Anwendungen empfehlen wir, jeden Shard pro Anwendung einmal pro Sekunde abzurufen. So können mehrere Konsumentenanwendungen einen Stream gleichzeitig unabhängig voneinander verarbeiten, ohne an die Limits von 5 `GetRecords`-Aufrufen pro Sekunde von Amazon Kinesis Data Streams zu stoßen. Darüber hinaus ist die Verarbeitung größerer Datenstapel in Bezug auf Netzwerk- und andere nachgelagerte Latenzzeiten effizienter.
Die Standardeinstellungen der KCL entsprechend der bewährten Einstellung von einem Abruf pro Sekunde. Dieser Standard führt zu einer durchschnittlichen Verbreitungsverzögerung von weniger als 1 Sekunde.
Die Datensätze von Kinesis Data Streams können sofort nach dem Schreiben gelesen werden. In Fällen, in denen Daten sofort nach Bereitstellung verarbeitet werden müssen, ist dies eine wichtiger Aspekt. Sie können die Verbreitungsverzögerung erheblich verringern, indem Sie die Standardeinstellungen der KCL überschreiben, um häufiger Datensätze abzurufen. Sehen Sie sich dazu die folgenden Beispiele an.
Java KCL-Konfigurationscode:
```
kinesisClientLibConfiguration = new
KinesisClientLibConfiguration(applicationName,
streamName,
credentialsProvider,
workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);
```
Einstellung der Eigenschaftendatei für Python- und Ruby-KCL:
```
idleTimeBetweenReadsInMillis = 250
```
**Anmerkung**
Da für Kinesis Data Streams ein Limit von 5 `GetRecords`-Aufrufen pro Sekunde pro Shard gilt, kann das Festlegen der `idleTimeBetweenReadsInMillis`-Eigenschaft auf einen Wert von unter 200 ms dazu führen, dass Ihre Anwendung die `ProvisionedThroughputExceededException`-Ausnahme erkennt. Zu viele dieser Ausnahmen können zu exponentiellen Backoffs führen und bedeutsame unerwartete Latenzzeiten bei der Verarbeitung nach sich ziehen. Wenn Sie diese Eigenschaft auf 200 ms oder etwas mehr setzen und mehr als eine Verarbeitungsanwendung haben, kommt es zu einer ähnlichen Drosselung.
# Verarbeiten Sie serialisierte Daten AWS Lambda mithilfe der Amazon Kinesis Producer Library
Die [Amazon Kinesis Producer Library](https://docs.aws.amazon.com/kinesis/latest/dev/developing-producers-with-kpl.html) (KPL) fasst kleine benutzerformatierte Datensätze zu größeren Datensätzen von bis zu 1 MB zusammen, um den Durchsatz von Amazon Kinesis Data Streams besser zu nutzen. Die KCL für Java unterstützt zwar die Deaggregation dieser Datensätze, Sie müssen jedoch ein spezielles Modul verwenden, um Datensätze zu deaggregieren, wenn Sie sie als Verbraucher Ihrer Streams verwenden. AWS Lambda Den erforderlichen Projektcode und Anweisungen finden Sie GitHub unter [Amazon Kinesis Producer Library Deaggregation Modules](https://github.com/awslabs/kinesis-deaggregation) for Lambda. AWS Die Komponenten in diesem Projekt bieten Ihnen die Möglichkeit, KPL-serialisierte Daten in Java AWS Lambda, Node.js und Python zu verarbeiten. Diese Komponenten können auch als Teil einer [mehrsprachigen KCL-Anwendung](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client-multilang/src/main/java/software/amazon/kinesis/multilang/package-info.java) verwendet werden.
# Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern
Das *Resharding* ermöglicht Ihnen das Erhöhen oder Verringern der Anzahl der Shards in einem Stream zur Anpassung an die Datenrate. Das Resharding wird üblicherweise von einer administrativen Anwendung durchgeführt, die Datenverwaltungsmetriken zu Shards überwacht. Obwohl die KCL selbst keine Resharding-Vorgänge auslöst, kann sie sich an die geänderte Anzahl von Shards anpassen, die sich aus dem Resharding ergibt.
Wie unter [Verwenden Sie eine Leasetabelle, um nachzuverfolgen, welche Shards von der KCL-Consumer-Anwendung verarbeitet wurden](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable) erwähnt, verfolgt die KCL die Shards im Stream mit einer Amazon-DynamoDB-Tabelle. Wenn aufgrund einer Resharding-Operation neue Shards erstellt werden, werden diese von der KCL erkannt, die dann neue Zeilen in die Tabelle einfügt. Die Auftragnehmer entdecken die neuen Shards automatisch und erstellen Prozessoren, um die Daten dieser neuen Shards zu verwalten. Die KCL verteilt die Shards zudem auf alle verfügbaren Auftragnehmer und Datensatzprozessoren im Stream.
Die KCL stellt sicher, dass alle Daten, die vor dem Resharding bereits in einem Shard vorhanden waren, als erstes verarbeitet werden. Nachdem diese Daten verarbeitet wurden, werden die Daten der neuen Shards an die Datensatzprozessoren gesendet. So behält die KCL die Reihenfolge bei, in der die Datensätze für einen bestimmten Partitionsschlüssel zum Stream hinzugefügt wurden.
## Beispiel: Resharding, Skalierung und Parallelverarbeitung
Das folgende Beispiel veranschaulicht, wie Sie die KCL bei der Skalierung und beim Resharding unterstützt:
+ Angenommen, Ihre Anwendung wird auf einer EC2 Instance ausgeführt und verarbeitet einen Kinesis-Datenstrom mit vier Shards. Diese eine Instance verfügt über einen KCL-Auftragnehmer und vier Datensatzprozessoren (ein Datensatzprozessor für jeden Shard). Diese vier Datensatzprozessoren werden parallel innerhalb desselben Prozesses ausgeführt.
+ Wenn Sie dann die Anwendung für die Verwendung einer weiteren Instance skalieren, verarbeiten zwei Instances einen Stream mit vier Shards. Wenn der KCL-Auftragnehmer auf der zweiten Instance gestartet wird, führt er einen Lastausgleich mit der ersten Instance durch, sodass nun jede Instance zwei Shards verarbeitet.
+ Dann beschließen Sie, Ihre vier Shards auf fünf Shards aufzuteilen. Die KCL koordiniert erneut die Verarbeitung auf den Instances: Eine Instance verarbeitet drei Shards und die andere zwei. Eine ähnliche Koordinierung erfolgt, wenn Sie Shards zusammenführen.
In der Regel sollten Sie bei Verwendung der KCL sicherstellen, dass die Anzahl der Instances nicht die Anzahl der Shards übersteigt (außer für Standby-Zwecke im Falle eines Ausfalls). Jeder Shard wird exakt von einem KCL-Auftragnehmer verarbeitet und verfügt über genau einen entsprechenden Datensatzprozessor, deshalb benötigen Sie für die Verarbeitung eines Shards niemals mehrere Instances. Ein Auftragnehmer kann allerdings eine beliebige Anzahl von Shards verarbeiten, deshalb ist es kein Problem, wenn Sie mehr Shards als Instances haben.
Testen Sie eine Kombination der folgenden Ansätze, wenn Sie die Verarbeitung in Ihrer Anwendung optimieren möchten:
+ Erhöhung der Instance-Größe (da alle Datensatzprozessoren innerhalb eines Prozesses parallel ausgeführt werden)
+ Erhöhung der Anzahl der Instances bis zur maximalen Anzahl offener Shards (da Shards unabhängig verarbeitet werden können)
+ Erhöhung der Anzahl der Shards (fördert die Parallelität)
Beachten Sie, dass Sie Auto Scaling für die automatische Skalierung Ihrer Instances basierend auf entsprechenden Metriken nutzen können. Weitere Informationen hierzu finden Sie im [Amazon EC2 Auto Scaling-Benutzerhandbuch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
Wenn durch das Resharding die Anzahl der Shards im Stream erhöht wird, führt eine entsprechende Erhöhung der Datensatzprozessoren zu einer höheren Last der EC2 Instances, auf denen sie gehostet werden. Wenn die Instances Teil einer Auto Scaling-Gruppe sind und die Last entsprechend steigt, fügt die Auto Scaling-Gruppe weitere Instances hinzu, damit die höhere Last ausgeglichen wird. Konfigurieren Sie Ihre Instances so, dass Ihre Anwendung Amazon Kinesis Data Streams beim Startup gestartet wird. So werden zusätzliche Auftragnehmer und Datensatzprozessoren in der neuen Instance sofort aktiviert.
Weitere Informationen zum Resharding finden Sie unter [Einen Stream erneut teilen](kinesis-using-sdk-java-resharding.md).
# Behandeln Sie doppelte Datensätze
Es gibt zwei primäre Gründe, warum Datensätze mehr als einmal an Ihre Anwendung von Amazon Kinesis Data Streams übermittelt werden: Wiederholungsversuche des Produzenten und Wiederholungsversuche des Konsumenten. Ihre Anwendung muss in der Lage sein, einzelne Datensätze mehrere Male angemessen zu verarbeiten.
## Der Produzent versucht es erneut
Stellen Sie sich einen Produzenten vor, der nach dem Aufruf von `PutRecord` aber noch vor dem Erhalt einer Bestätigung von Amazon Kinesis Data Streams einen netzwerkbedingten Timeout erfährt. In diesem Fall ist es fraglich, ob der Datensatz auch an Kinesis Data Streams übermittelt wurde. Davon ausgehend, dass jeder Datensatz für die Anwendung wichtig ist, ist der Produzent so aufgebaut, dass er den Aufruf mit denselben Daten wiederholt. Wenn beide `PutRecord`-Aufrufe mit denselben Daten erfolgreich an Kinesis Data Streams übergeben werden, sind anschließend zwei Datensätze von Kinesis Data Streams vorhanden. Obwohl die beiden Datensätze identische Daten enthalten, haben Sie trotzdem eindeutige Sequenznummern. Anwendungen, die Garantien benötigen, sollten einen Primärschlüssel in den Datensatz einbetten, sodass doppelte Datensätze später bei der Verarbeitung entfernt werden. Beachten Sie, dass die Anzahl der Duplikate aufgrund von Wiederholungen durch den Produzenten verglichen mit der Anzahl der Duplikate aufgrund von Wiederholungen durch den Konsumenten in der Regel nicht sehr hoch ist.
**Anmerkung**
Wenn Sie das AWS SDK verwenden`PutRecord`, erfahren Sie mehr über das [SDK-Wiederholungsverhalten](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) im *AWS SDKs und Tools-Benutzerhandbuch*.
## Der Verbraucher versucht es erneut
Wiederholungen durch den Konsumenten (Datenverarbeitungsanwendungen) kommen vor, wenn Datenprozessoren neu gestartet werden. Datensatzprozessoren für denselben Shard werden in den folgenden Fällen neu gestartet:
1. Ein Auftragnehmer wird unerwartet beendet
1. Es werden Auftragnehmer-Instances hinzugefügt oder entfernt
1. Es werden Shards zusammengeführt oder getrennt
1. Die Anwendung wird bereitgestellt
In all diesen Fällen wird die shards-to-worker-to -record-processor-Zuordnung kontinuierlich aktualisiert, um die Lastenausgleichsverarbeitung zu berücksichtigen. Shard-Prozessoren, die in andere Instances migriert wurden, starten das Verarbeiten von Datensätzen am letzten Prüfpunkt neu. Dies führt zu einer doppelten Datensatzverarbeitung, wie in dem folgenden Beispiel dargestellt. Weitere Informationen zur Lastverteilung finden Sie unter [Verwenden Sie Resharding, Skalierung und Parallelverarbeitung, um die Anzahl der Shards zu ändern](kinesis-record-processor-scaling.md).
### Beispiel: Wiederholte Versuche eines Verbrauchers führen zu erneut zugestellten Datensätzen
In diesem Beispiel haben Sie eine Anwendung, die kontinuierlich Datensätze aus einem Stream liest, Datensätze in eine lokale Datei aggregiert und die Datei in Amazon S3 hochlädt. Der Einfachheit halber gehen wir davon aus, dass nur 1 Shard und 1 Auftragnehmer den Shard verarbeiten. Beachten Sie die folgende Beispielabfolge von Ereignissen und gehen Sie davon aus, dass der letzte Prüfpunkt bei Datensatznummer 10.000 gesetzt wurde.
1. Ein Auftragnehmer liest den nächsten Datensatzstapel aus dem Shard (Datensätze 10.001 bis 20.000).
1. Anschließend übermittelt der Auftragnehmer diesen an den zugehörigen Datensatzprozessor.
1. Der Datensatzprozessor aggregiert die Daten, erstellt eine Amazon-S3-Datei und lädt die Datei erfolgreich in Amazon S3 hoch.
1. Der Auftragnehmer wird unerwartet beendet, noch ehe er einen neuen Prüfpunkt setzen kann.
1. Anwendung, Auftragnehmer und Datensatzprozessor starten neu.
1. Der Auftragnehmer beginnt beim letzten erfolgreich gesetzten Prüfpunkt mit dem Lesen, hier Datensatznummer 10.001.
Somit werden die Datensätze 10.001 bis 20.000 mehr als einmal verwendet.
### Widerstandsfähigkeit gegenüber Wiederholungsversuchen durch Verbraucher
Auch wenn Datensätze mehrmals verarbeitet werden, kann die Anwendung vorgeben, dass Datensätze nur einmal verarbeitet wurden (idempotente Verarbeitung). Die Lösungen für dieses Problem variieren in Komplexität und Genauigkeit. Wenn das Ziel der resultierenden Daten doppelte Datensätze ordnungsgemäß handhaben kann, sollten Sie sich auf diese Anwendung verlassen, um eine idempotente Verarbeitung zu erreichen. Mit [Opensearch](https://www.opensearch.org/) können Sie beispielsweise eine Kombination aus Versionierung und Unique verwenden, um doppelte Verarbeitung IDs zu verhindern.
Die Beispielanwendung aus dem vorherigen Abschnitt liest kontinuierlich Datensätze aus dem Stream, aggregiert diese in eine lokale Datei und lädt diese Datei in Amazon S3 hoch. Wie gezeigt, werden die Datensätze 10 001 bis 20 000 mehr als einmal verarbeitet, sodass es mehrere Amazon-S3-Dateien mit identischen Daten gibt. Eine Möglichkeit, Duplikate in diesem Beispiel zu vermeiden, besteht darin, sicherzustellen, dass bei Schritt 3 das folgende Schema verwendet wird:
1. Der Datensatzprozessor verwendet eine feste Anzahl von Datensätzen pro Amazon-S3-Datei, beispielsweise 5 000.
1. Der Dateiname nutzt folgendes Schema: Amazon-S3-Präfix, Shard-ID und `First-Sequence-Num`. In diesem Fall könnte dies `sample-shard000001-10001` sein.
1. Nach dem Hochladen der Amazon-S3-Datei setzen Sie durch Angabe von `Last-Sequence-Num` einen Prüfpunkt. In diesem Fall würden Sie bei Datensatznummer 15.000 einen Prüfpunkt setzen.
Bei diesem Schema hat die resultierende Amazon-S3-Datei auch bei einer mehrfachen Verarbeitung der Datensätze denselben Namen und Dateninhalt. Die Wiederholungen führen nur dazu, dass dieselben Daten mehrmals in dieselbe Datei geschrieben werden.
Bei einer Reshard-Operation ist die Anzahl der im Shard verbliebenen Datensätze möglicherweise kleiner als benötigte Anzahl Ihrer gewünschten, festen Anzahl. In diesem Fall muss die `shutdown()`-Methode die Datei an Amazon S3 übertragen und bei der letzten Sequenznummer einen Prüfpunkt setzen. Die obige Schema ist auch mit Reshard-Operationen kompatibel.
# Kümmere dich um das Starten, Herunterfahren und Drosseln
Nachfolgend einige Überlegungen, die Sie in das Design Ihrer Amazon Kinesis Data Streams einfließen lassen sollten.
**Topics**
+ [
## Starten Sie Datenproduzenten und Datenkonsumenten
](#kinesis-record-processor-producer-consumer-coordination)
+ [
## Fahren Sie eine Amazon Kinesis Data Streams Streams-Anwendung herunter
](#developing-consumers-with-kcl-shutdown)
+ [
## Drosselung von Lesevorgängen
](#kinesis-record-processor-read-throttling)
## Starten Sie Datenproduzenten und Datenkonsumenten
Standardmäßig beginnt die KCL am vorderen Ende des Streams mit dem Lesen von Datensätzen, also mit dem zuletzt hinzugefügten Datensatz. Wenn bei dieser Konfiguration eine datenproduzierende Anwendung Datensätze zum Stream hinzufügt, ehe empfangsbereite Datensatzprozessoren ausgeführt werden, werden diese Datensätze nach dem Start der Datensatzprozessoren nicht gelesen.
Damit Datenprozessoren immer am Anfang des Streams mit dem Lesen beginnen, legen Sie den folgenden Wert in der Eigenschaftendatei Ihrer Amazon Kinesis Data Streams fest:
```
initialPositionInStream = TRIM_HORIZON
```
Standardmäßig speichert Amazon Kinesis Data Streams alle Daten für 24 Stunden. Er unterstützt auch eine erweiterte Aufbewahrung von bis zu 7 Tagen und die langfristige Aufbewahrung von bis zu 365 Tagen. Dieser Zeitrahmen wird als *Aufbewahrungszeitraum* bezeichnet. Wenn Sie die Startposition auf `TRIM_HORIZON` festsetzen, beginnt der Datensatzprozessor entsprechend des definierten Aufbewahrungszeitraums mit den ältesten Daten. Wenn ein Datensatzprozessor nach Ablauf des Aufbewahrungszeitraums gestartet wird, sind trotz `TRIM_HORIZON`-Einstellung einige der Datensätze aus dem Stream nicht mehr verfügbar. Aus diesem Grund sollten Verbraucheranwendungen immer aus dem Stream lesen und anhand der CloudWatch Metrik überwachen, `GetRecords.IteratorAgeMilliseconds` ob die Anwendungen mit den eingehenden Daten Schritt halten.
In einigen Fällen mag es unerheblich sein, wenn Datensatzprozessoren die ersten Datensätze im Stream auslassen. Sie könnten beispielsweise einige erste Datensätze durch den Stream laufen lassen, um zu testen, ob der Stream end-to-end erwartungsgemäß funktioniert. Nach dieser anfänglichen Verifizierung starten Sie dann die Auftragnehmer und beginnen mit der Einleitung von Produktionsdaten in den Stream.
Weitere Informationen zur `TRIM_HORIZON`-Einstellung finden Sie unter [Verwenden Sie Shard-Iteratoren](developing-consumers-with-sdk.md#kinesis-using-sdk-java-get-data-shard-iterators).
## Fahren Sie eine Amazon Kinesis Data Streams Streams-Anwendung herunter
Wenn Ihre Anwendung für Amazon Kinesis Data Streams die beabsichtigten Aufgaben abgeschlossen hat, sollten Sie sie herunterfahren, indem Sie die EC2-Instances beenden, auf denen sie ausgeführt wird. Sie können die Instances über die [AWS-Managementkonsole](https://console.aws.amazon.com//ec2/home) oder die [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html) beenden.
Nach dem Herunterfahren der Anwendung für Amazon Kinesis Data Streams sollten Sie die Amazon-DynamoDB-Tabelle löschen, mit der die KCL den Anwendungsstatus verfolgt hat.
## Drosselung von Lesevorgängen
Der Durchsatz eines Streams wird auf Shard-Ebene bereitgestellt. Jeder Shard hat einen Lesedurchsatz von bis zu 5 Transaktionen pro Sekunde für Lesevorgänge, bis zu einer maximalen Gesamtdatenleserate von 2 MB pro Sekunde. Wenn eine Anwendung (oder eine Gruppe von Anwendungen im selben Stream) versucht, Daten schneller aus einem Shard abzurufen, drosselt Kinesis Data Streams die entsprechenden GET-Operationen.
Wenn in einer Amazon Kinesis Data Streams ein Datensatzprozessor Daten schneller als das Limit verarbeitet, beispielsweise bei einem Ausfall, kommt es zu einem Failover. Da die KCL die Interaktionen zwischen der Anwendung und Kinesis Data Streams verwaltet, treten Ablehnungsausnahmen im Code der KCL und nicht im Anwendungscode auf. Da die KCL diese Ausnahmen jedoch protokolliert, sind sie in den Protokollen zu sehen.
Wenn Sie feststellen, dass Ihre Anwendung permanent gedrosselt wird, sollten Sie eine Erhöhung der Shards für diesen Stream in Betracht ziehen.