Nach reiflicher Überlegung haben wir uns entschieden, Amazon Kinesis Data Analytics für SQL-Anwendungen einzustellen:
1. Ab dem **1. September 2025** werden wir keine Bugfixes für Amazon Kinesis Data Analytics for SQL-Anwendungen bereitstellen, da wir aufgrund der bevorstehenden Einstellung nur eingeschränkten Support dafür haben werden.
2. Ab dem **15. Oktober 2025** können Sie keine neuen Kinesis Data Analytics for SQL-Anwendungen mehr erstellen.
3. Wir werden Ihre Anwendungen ab dem **27. Januar 2026** löschen. Sie können Ihre Amazon Kinesis Data Analytics for SQL-Anwendungen nicht starten oder betreiben. Ab diesem Zeitpunkt ist kein Support mehr für Amazon Kinesis Data Analytics for SQL verfügbar. Weitere Informationen finden Sie unter [Einstellung von Amazon Kinesis Data Analytics für SQL-Anwendungen](discontinuation.md).
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](windowed-sql.md).
Sie können die Spalte ROWTIME in Ihrer `SELECT`-Anweisung wie jede andere Spalte in Ihrem In-Application-Stream aufrufen. Beispiel:
```
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 `ROWTIME` bereit, 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.) Diese `ROWTIME` ist 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 `ROWTIME` als 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](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/get-started-exercise.html)-Ü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 die Anwendungsausgabe beispielsweise so konfigurieren, dass die Ergebnisse in einem Firehose-Lieferdatenstrom gespeichert werden, der in eine Amazon Redshift 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\$11), obwohl ein Datensatz spät eingetroffen ist.