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. # 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.