Für neue Projekte empfehlen wir, den neuen Managed Service für Apache Flink Studio anstelle von Kinesis Data Analytics for SQL Applications zu verwenden. Der Managed Service für Apache Flink Studio kombiniert Benutzerfreundlichkeit mit fortschrittlichen Analysefunktionen, sodass Sie in wenigen Minuten anspruchsvolle Anwendungen zur Stream-Verarbeitung erstellen können.
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.
Zeitstempel und die ROWTIME-Spalte
In-Application-Streams enthalten eine spezielle Spalte namens ROWTIME. In dieser wird ein Zeitstempel gespeichert, wenn Amazon Kinesis Data Analytics eine Zeile in den ersten In-Application-Stream einfügt. ROWTIME spiegelt den Zeitstempel wider, zu dem Amazon Kinesis Data Analytics nach dem Lesen aus der Streaming-Quelle einen Datensatz in den ersten In-Application-Stream eingefügt hat. Dieser ROWTIME-Wert wird anschließend in der gesamten Anwendung beibehalten.
Anmerkung
Wenn Sie Datensätze aus einem In-Application-Stream in einen anderen pumpen, müssen Sie die Spalte ROWTIME nicht explizit kopieren. Amazon Kinesis Data Analytics kopiert diese Spalte für Sie.
Amazon Kinesis Data Analytics stellt sicher, dass die ROWTIME-Werte gleichmäßig erhöht werden. Sie verwenden diesen Zeitstempel in Abfragen mit Fenstern auf Zeitbasis. Weitere Informationen finden Sie unter Abfragen mit Fenstern.
Sie können die Spalte ROWTIME in Ihrer SELECT-Anweisung wie jede andere Spalte in Ihrem In-Application-Stream aufrufen. Beispielsweise:
SELECT STREAM ROWTIME, some_col_1, some_col_2 FROM SOURCE_SQL_STREAM_001
Verstehen der verschiedenen Zeiten in Streaming-Analysen
Zusätzlich zu ROWTIME gibt es weitere Arten von Zeiten in Echtzeit-Streaming-Anwendungen. Dies sind:
-
Ereigniszeit – Der Zeitstempel für den Zeitpunkt, an dem das Ereignis aufgetreten ist. Dies wird manchmal auch die clientseitige Zeit genannt. Häufig ist es wünschenswert, diese Zeit in Analysen zu verwenden, da dies die Zeit ist, zu der ein Ereignis aufgetreten ist. Zahlreiche Ereignisquellen, wie Smartphones und Web-Clients, besitzen jedoch keine zuverlässigen Uhren, was zu ungenauen Zeiten führen kann. Zusätzlich können Konnektivitätsprobleme dazu führen, dass Datensätze in einem Stream nicht in der gleichen Reihenfolge angezeigt werden, in der sie aufgetreten sind.
-
Aufnahmezeit – Der Zeitstempel für den Zeitpunkt, an dem ein Datensatz der Streaming-Quelle hinzugefügt wurde. Amazon Kinesis Data Streams enthalten in jedem Datensatz ein Feld namens
APPROXIMATE_ARRIVAL_TIME, das diesen Zeitstempel bereitstellt. Dies wird manchmal auch als serverseitige Zeit bezeichnet. Diese Aufnahmezeit ist häufig eine nahe Annäherung an die Ereigniszeit. Wenn es eine Verzögerung bei der Aufnahme des Datensatzes in den Stream gibt, kann dies zu Ungenauigkeiten führen, was in der Regel selten ist. Die Aufnahmezeit ist selten nicht in der richtigen Reihenfolge, auch wenn dies aufgrund der verteilten Natur von Streaming-Daten vorkommen kann. Daher reflektiert die Aufnahmezeit die Ereigniszeit meistens genau und in der richtigen Reihenfolge. -
Verarbeitungszeit – Der Zeitstempel für den Zeitpunkt, an dem Amazon Kinesis Data Analytics eine Zeile in den ersten In-Application-Stream einfügt. Amazon Kinesis Data Analytics stellt diesen Zeitstempel in der Spalte
ROWTIMEbereit, die in jedem In-Application-Stream vorhanden ist. Die Verarbeitungszeit wird stets gleichmäßig erhöht. Sie ist jedoch nicht genau, wenn Ihre Anwendung hinter das Schreiben von Daten zurückfällt. (Wenn eine Anwendung zurückfällt, gibt die Verarbeitungszeit die Ereigniszeit nicht genau wieder.) DieseROWTIMEist in Bezug auf die Uhr zwar sehr genau, stellt möglicherweise jedoch nicht die Zeit dar, zu der das Ereignis tatsächlich aufgetreten ist.
Die Verwendung dieser Zeiten in Abfragen mit Fenstern auf Zeitbasis hat Vor- und Nachteile. Wir empfehlen, mindestens eine dieser Zeiten zu wählen und je nach Anwendungsfall eine Strategie für den Umgang mit den relevanten Nachteilen zu entwickeln.
Anmerkung
Wenn Sie Fenster auf Zeilenbasis verwenden, stellt Zeit kein Problem dar und Sie können diesen Abschnitt ignorieren.
Wir empfehlen, eine Zwei-Fenster-Strategie, die zwei Fenster auf Zeitbasis verwendet, sowohl ROWTIME und eine der beiden anderen Zeiten (Aufnahme- oder Ereigniszeit).
-
Sie sollten
ROWTIMEals erstes Fenster verwenden, das die Häufigkeit steuert, mit der die Abfrage die Ergebnisse ausgibt, wie im folgenden Beispiel gezeigt. Sie wird nicht als logische Zeit verwendet. -
Sie sollten eine der beiden anderen Zeiten als logische Zeit verwenden, um sie mit Ihren Analysen zu verknüpfen. Diese Zeit stellt den Zeitpunkt dar, zu dem das Ereignis aufgetreten ist. Im folgenden Beispiel besteht das Ziel der Analyse darin, die Datensätze zu gruppieren und eine Zahl nach Ticker zurückzugeben.
Der Vorteil dieser Strategie besteht darin, dass eine Zeit verwendet werden kann, die den Zeitpunkt angibt, zu dem das Ereignis aufgetreten ist. Auch treten mit dieser Strategie keinerlei Probleme auf, wenn Ihre Anwendung zurückfällt oder Ereignisse nicht in der richtigen Reihenfolge eintreffen. Wenn die Anwendung zurückfällt, wenn Datensätze in den In-Application-Stream eingefügt werden, werden sie dennoch von der logischen Zeit im zweiten Fenster gruppiert. Die Abfrage verwendet ROWTIME, um die Reihenfolge der Verarbeitung zu gewährleisten. Datensätze, die verspätet eintreffen (der Aufnahmezeitstempel zeigt im Vergleich zum ROWTIME-Wert einen früheren Wert an), werden ebenfalls erfolgreich verarbeitet.
Betrachten Sie die folgende Abfrage für den in der Erste Schritte-Übung verwendeten Demo-Stream. Die Abfrage verwendet die GROUP BY-Klausel und gibt die Tickerzahl innerhalb eines rollierenden Zeitfensters von einer Minute an.
CREATE OR REPLACE STREAM "DESTINATION_SQL_STREAM" ("ingest_time" timestamp, "APPROXIMATE_ARRIVAL_TIME" timestamp, "ticker_symbol" VARCHAR(12), "symbol_count" integer); CREATE OR REPLACE PUMP "STREAM_PUMP" AS INSERT INTO "DESTINATION_SQL_STREAM" SELECT STREAM STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND) AS "ingest_time", STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND) AS "APPROXIMATE_ARRIVAL_TIME", "TICKER_SYMBOL", COUNT(*) AS "symbol_count" FROM "SOURCE_SQL_STREAM_001" GROUP BY "TICKER_SYMBOL", STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND), STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND);
In GROUP BY gruppieren Sie die Datensätze zunächst anhand der ROWTIME in einem Zeitfenster von einer Minute und anschließend nach APPROXIMATE_ARRIVAL_TIME.
Die Zeitstempelwerte im Ergebnis werden auf das nächste 60-Sekunden-Intervall gerundet. Die erste von der Abfrage ausgegebene Ergebnisgruppe zeigt Datensätze in der ersten Minute an. Die zweite Gruppe von ausgegebenen Ergebnissen zeigt Datensätze in den nächsten Minuten an, basierend auf ROWTIME. Der letzte Datensatz gibt an, dass die Anwendung den Datensatz verspätet in den In-Application-Stream aufgenommen hat(sie zeigt im Vergleich zum Aufnahmezeitstempel einen verspäteten ROWTIME-Wert an).
ROWTIME INGEST_TIME TICKER_SYMBOL SYMBOL_COUNT --First one minute window. 2016-07-19 17:05:00.0 2016-07-19 17:05:00.0 ABC 10 2016-07-19 17:05:00.0 2016-07-19 17:05:00.0 DEF 15 2016-07-19 17:05:00.0 2016-07-19 17:05:00.0 XYZ 6 –-Second one minute window. 2016-07-19 17:06:00.0 2016-07-19 17:06:00.0 ABC 11 2016-07-19 17:06:00.0 2016-07-19 17:06:00.0 DEF 11 2016-07-19 17:06:00.0 2016-07-19 17:05:00.0 XYZ 1 *** ***late-arriving record, instead of appearing in the result of the first 1-minute windows (based on ingest_time, it is in the result of the second 1-minute window.
Sie können die Ergebnisse kombinieren, um eine endgültige genaue Zahl pro Minute zu erhalten, indem die Ergebnisse zu einer Downstream-Datenbank verschoben werden. Sie können beispielsweise die Anwendungsausgabe so konfigurieren, dass die Ergebnisse in einem Firehose-Bereitstellungs-Stream gespeichert werden, der in eine Amazon-Redshift-Tabelle schreiben kann. Wenn sich die Ergebnisse in einer Amazon Redshift-Tabelle befinden, können Sie eine Tabellenabfrage durchführen, um die gesamte Zahl für die Gruppe nach Ticker_Symbol zu berechnen. Im Fall von XYZ ist die Gesamtzahl genau (6+1), obwohl ein Datensatz spät eingetroffen ist.
