Bewährte Methoden

CloudWatch Amazon-Alarme einrichten — Sie können die von Kinesis Data Analytics bereitgestellten CloudWatch Metriken verwenden, um Folgendes zu überwachen:

Wir empfehlen, dass Sie mindestens zwei CloudWatch Alarme für die folgenden Metriken für Ihre in Produktion befindlichen Anwendungen einrichten:

Beschränken Sie die Anzahl der Produktionsanwendungen, die denselben Kinesis-Datenstrom lesen, auf zwei Anwendungen, um zu verhindern, dass die ReadProvisionedThroughputException-Ausnahmebedingung ausgelöst wird.

Amazon-Kinesis-Data-Analytics liest für jede Anwendung eine Streaming-Quelle ca. einmal pro Sekunde aus. Anwendungen, die mit Ihrer Leseleistung zurückfallen, können Daten möglicherweise mit einer schnelleren Rate einlesen, um aufzuholen. Um Anwendungen einen genügend großen Durchsatz bereitzustellen, damit sie aufholen können, beschränken Sie die Anzahl der Anwendungen, die von derselben Datenquelle lesen.

Beschränken Sie die Anzahl der Produktionsanwendungen, die aus demselben Firehose-Lieferstream lesen, auf eine Anwendung.

Ein Firehose-Lieferstream kann in Ziele wie Amazon S3 und Amazon Redshift schreiben. Er kann auch als Streaming-Quelle für Ihre Kinesis Data Analytics-Anwendung dienen. Daher empfehlen wir, nicht mehr als eine Kinesis Data Analytics Analytics-Anwendung pro Firehose-Lieferstream zu konfigurieren. So stellen Sie sicher, dass der Bereitstellungs-Stream auch für andere Ziele bereitstellen kann.

Verwenden Sie mehrere Streams und Kinesis-Data-Analytics-for-SQL-Anwendungen, wenn die Skalierungsanforderungen Ihrer Anwendung 100 MB/Sekunde überschreiten.

Verwenden Sie Managed Service für Apache Flink-Anwendungen, wenn Sie einen einzelnen Stream und eine einzelne Anwendung verwenden möchten.

Der größte Durchsatz, den wir für einen einzelnen In-Application-Stream empfehlen, liegt je nach Komplexität der Abfrage der Anwendung zwischen 2 und 20 MB/s.

Der maximale Streaming-Durchsatz, den eine einzelne Kinesis Data Analytics for SQL-Anwendung verarbeiten kann, beträgt ungefähr 100 MB/s. Dies setzt voraus, dass Sie die Anzahl der In-App-Streams auf den Höchstwert von 64 erhöht haben und dass Sie Ihr KPU-Limit auf über 8 erhöht haben. Weitere Informationen finden Sie unter Limits.

Testen Sie das abgeleitete Schema gründlich. Bei dem Erkennungsprozess werden nur Proben der Datensätze aus der Streaming-Quelle verwendet, um daraus ein Schema abzuleiten. Wenn Ihre Streaming-Quelle über zahlreiche Datensatztypen verfügt, wurden möglicherweise nicht alle Datensatztypen von der Erkennungs-API erfasst. Dadurch kann ein Schema entstehen, dass die Daten in der Streaming-Quelle nicht genau widerspiegelt.

Wenn Ihre Anwendung gestartet wird, können diese nicht berücksichtigten Datensatztypen zu Fehlern bei der Strukturanalyse führen. Amazon-Kinesis-Data-Analytics sendet diese Datensätze an den In-Application-Fehler-Stream. Um Fehler bei der Strukturanalyse zu reduzieren, empfehlen wir, das abgeleitete Schema interaktiv in der Konsole zu testen und den In-Application-Stream auf ausgelassene Datensätze hin zu überwachen.

Die Kinesis Data Analytics API unterstützt für Spalten in der Eingabekonfiguration nicht die Angabe einer NOT NULL-Einschränkung. Wenn Sie in Ihrem In-Application-Stream für bestimmte Spalten NOT NULL-Einschränkungen festlegen möchten, erstellen Sie diese In-Application-Streams in Ihrem Anwendungscode. Anschließend können Sie Daten von einem In-Application-Stream in einen anderen kopieren und dort die Beschränkung durchsetzen.

Bei jedem Versuch, Zeilen mit NULL-Werten einzufügen, wenn ein Wert erforderlich ist, wird ein Fehler ausgegeben. Kinesis Data Analytics sendet diese Fehler an den In-App-Fehler-Stream.

Verallgemeinern Sie Datentypen, die bei dem Erkennungsprozess abgeleitet wurden. Der Erkennungsvorgang empfiehlt Spalten und Datentypen basierend auf einer Zufallsauswahl von Datensätzen aus der Streaming-Quelle. Wir empfehlen, dass Sie die Datensätze sorgfältig überprüfen und sie für alle möglichen Fälle von Datensätzen in der Eingabe generalisieren. Auf diese Weise wird sichergestellt, dass bei der Strukturanalyse während der Ausführung der Anwendung weniger Fehler auftreten. Wenn beispielsweise ein Schema mit einem Spaltentyp SMALLINT abgeleitet wurde, sollten Sie ihn ggf. in einen INTEGER ändern.

Verwenden Sie SQL-Funktionen in Ihrem Anwendungscode, um unstrukturierte Daten oder Spalten zu verarbeiten. Möglicherweise haben Sie unstrukturierte Daten oder Spalten in Ihrer Eingabe, z. B. Protokolldaten. Beispiele finden Sie unter Beispiel: Werte transformieren DateTime . Ein Ansatz zur Verarbeitung dieser Art von Daten ist, das Schema mit nur einem Spaltentyp VARCHAR(N) zu definieren, wobei N die längstmögliche Zeile ist, die Sie in Ihrem Stream erwarten. Anschließend können Sie dann die eingehenden Datensätze mit Ihrer Anwendung einlesen und mit den String- und Date Time-Funktionen analysieren und so ein Schema für die Rohdaten gewinnen.

Stellen Sie sicher, dass Sie bei der Verarbeitung Streaming-Quelldaten, die tiefer als zwei Ebenen verschachtelt sind, vollständig abarbeiten. JSON-Quelldaten können verschachtelt sein. Die Erkennungs-API leitet ein Schema ab, das die Eingabe auf eine Verschachtelungsebene reduziert. Die Erkennungs-API versucht auch bei zwei Schachtelungsebenen, diese auf eine Ebene zu reduzieren. Bei mehr als zwei Schachtelungsebenen kann die Strukturtiefe nur bedingt reduziert werden. Um verschachtelte Strukturen vollständig zu verarbeiten, müssen Sie das abgeleitete Schema manuell an Ihre Anforderungen anpassen. Verwenden Sie dazu eine der beiden folgenden Strategien:

Verwenden Sie das erste Ziel, um die Ergebnisse Ihrer SQL-Abfragen auszugeben.

Verwenden Sie das zweite Ziel, um den gesamten Fehlerstream einzufügen und ihn über einen Firehose-Lieferstream an einen S3-Bucket zu senden.

Geben Sie aus den folgenden Gründen in der SQL-Anweisung keine Zeitfenster an, die größer als eine Stunde sind:

Halten Sie während der Entwicklung die Fenstergröße in Ihren SQL-Anweisungen klein, um schneller Ergebnisse zu erhalten. Wenn Sie die Anwendung in der Produktionsumgebung bereitstellen, können Sie die Fenstergröße geeignet anpassen.

Verwenden Sie anstelle einer einzigen komplexen SQL-Anweisung mehrere Anweisungen, die in jedem Schritt Zwischenergebnisse in In-Application-Streams speichern. Dies vereinfacht auch das Debugging.

Bei der Verwendung von rollierenden Zeitfenstern empfehlen wir, dass Sie zwei Fenster verwenden: eines für die Verarbeitungszeit und eines für die logische Zeit (Zeitpunkt der Erfassung oder des Ereignisses). Weitere Informationen finden Sie unter Zeitstempel und die ROWTIME-Spalte.

Verwenden Sie den Kinesis Data Generator (KDG). Der KDG verwendet eine Datenvorlage, mit der zufällige Daten an einen Kinesis-Stream gesendet werden. Er ist einfach zu verwenden, eignet sich jedoch nicht zum Testen von komplexen Beziehungen zwischen Datenelementen wie beispielsweise in Anwendungen, die Hotspots oder Anomalien erkennen.

Verwenden Sie eine benutzerdefinierte Python-Anwendung, um komplexere Daten an einen Kinesis-Datenstrom zu senden. Mithilfe einer Python-Anwendung können Sie komplexe Beziehungen zwischen Datenelementen wie Hotspots oder Anomalien erzeugen. Eine Python-Beispielanwendung, die Daten in Clusterform an einen Daten-Hotspot sendet, finden Sie unter Beispiel: Erkennen von Hotspots in einem Stream (HOTSPOTS-Funktion).

Die Daten aus Ihrem Stream werden in den richtigen Datentyp umgewandelt. Stellen Sie beispielsweise sicher, dass Datum-/Uhrzeit-Angaben nicht als Zeichenfolge in die Anwendung aufgenommen werden.

Die Daten werden in dem gewünschten Datentyp analysiert und umgewandelt. Wenn bei der Analyse oder Umwandlung Fehler auftreten, können Sie diese in der Konsole ausgeben oder dem Fehler-Stream ein Ziel zuweisen und die Fehler im Zielspeicher betrachten.

Die Datenfelder für Zeichendaten sind ausreichend lang und die Zeichendaten werden in der Anwendung nicht abgeschnitten. Sie können die Datensätze in Ihrem Zielspeicher überprüfen, um sicherzustellen, dass die Anwendungsdaten nicht abgeschnitten werden.