在仔細考慮之後，我們決定停止 Amazon Kinesis Data Analytics for SQL 應用程式：
1. 從 **2025 年 9 月 1 日起，**我們不會為 Amazon Kinesis Data Analytics for SQL 應用程式提供任何錯誤修正，因為考慮到即將終止，我們將對其提供有限的支援。
2. 從 **2025 年 10 月 15 日起，**您將無法建立新的 Kinesis Data Analytics for SQL 應用程式。
3. 我們將自 **2026 年 1 月 27** 日起刪除您的應用程式。您將無法啟動或操作 Amazon Kinesis Data Analytics for SQL 應用程式。從那時起，Amazon Kinesis Data Analytics for SQL 將不再提供支援。如需詳細資訊，請參閱[Amazon Kinesis Data Analytics for SQL 應用程式終止](discontinuation.md)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 時間戳記和 ROWTIME 欄
應用程式內串流包含一個名為 `ROWTIME` 的特殊欄。當 Amazon Kinesis Data Analytics 在第一個應用程式內串流中插入資料列時，它會儲存時間戳記。`ROWTIME` 反映 Amazon Kinesis Data Analytics 從串流來源讀取後，將記錄插入第一個應用程式內串流的時間戳記。然後此 `ROWTIME` 值會在整個應用程式中保留。
**注意**
當您將記錄從一個應用程式內串流抽取到另一個應用程式內串流時，不需要明確複製該 `ROWTIME` 欄，Amazon Kinesis Data Analytics 會為您複製此資料欄。
Amazon Kinesis Data Analytics 保證這些 `ROWTIME` 值會單調增加。您可以在基於時間的窗口式查詢中使用此時間戳記。如需詳細資訊，請參閱[窗口化查詢](windowed-sql.md)。
您可以像在應用程式內串流中存取任何其他資料欄一樣，存取 `SELECT` 陳述式中的 ROWTIME 資料欄。例如：
```
SELECT STREAM ROWTIME,
some_col_1,
some_col_2
FROM SOURCE_SQL_STREAM_001
```
## 了解串流分析中的不同時間
除了 `ROWTIME` 之外，實時串流應用程式中還有其他類型的時間。這些時間為：
+ **事件時間**：事件發生的時間戳記。這有時也稱為*用戶端時間*。在分析中通常偏好使用此時間，因其為事件發生的時間。不過，許多事件來源 (例如行動電話和 Web 用戶端) 沒有可靠的時鐘，這可能會導致不正確的時間。此外，連線問題可能會導致串流上的記錄顯示順序與事件發生的順序不相同。
+ **擷取時間**：記錄新增至串流來源的時間戳記。Amazon Kinesis Data Streams 在提供此時間戳記的每個記錄中，都包含一個名為 `APPROXIMATE_ARRIVAL_TIME` 的欄位。這有時也稱為*伺服器端時間*。這個擷取時間通常是接近事件時間的近似值。如果記錄擷取到串流時有任何延遲，則可能會導致錯誤，但通常很少見。此外，擷取時間很少出現故障，但由於串流資料的分散式性質，故障可能會發生。因此，擷取時間大多準確且符合順序地反映事件時間。
+ **處理時間**：Amazon Kinesis Data Analytics 在第一個應用程式內串流中插入資料列的時間戳記。在每個應用程式內串流中，Amazon Kinesis Data Analytics 會在 `ROWTIME` 欄提供時間戳記。處理時間總是會單調增加。但是，如果您的應用程式落後，此時間就不准確。(如果應用程式落後，處理時間就不能準確反映事件時間。) 此 `ROWTIME` 與掛鐘比對是準確的，但它可能不是事件實際發生的時間。
在基於時間的窗口查詢中，使用這些時間中的每一個時間都有優點和缺點。我們建議您選擇其中一個或多個時間，並擬好根據使用案例情境處理相關缺點的策略。
**注意**
如果您使用以列為基礎的窗口，則時間不是問題，您可以忽略此節。
我們建議採用雙窗口策略，該策略使用兩個時間基礎，即 `ROWTIME` 與另一個其他時間 (擷取或事件時間) 兩者。
+ 使用 `ROWTIME` 作為第一個窗口，此時段可控制查詢發出結果的頻率，如下列範例所示。這並非邏輯時間。
+ 把其中一個其他時間當作邏輯時間，即您想要連結到分析的時間 此時間表示事件發生的時間。在下面的例子中，分析目標是按股票代號對記錄進行分組和返回計數。
此策略的優點，是可以使用代表事件發生的時間。當您的應用程式落後或事件出現故障時，它可以適當地處理。如果應用程式在將記錄引入應用程式內串流時落後，它們仍會依照第二個窗口中的邏輯時間進行分組。該查詢用 `ROWTIME` 來保證處理的順序。任何延遲的記錄 (與 `ROWTIME` 值相比，擷取時間戳記顯示較早的值) 也會成功處理。
請考慮下列針對[入門練習](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/get-started-exercise.html)中使用的示範串流的查詢。該查詢使用 `GROUP BY` 子句，並在一分鐘的輪轉窗口中發出股票代號計數。
```
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);
```
在 `GROUP BY`，您先依據 `ROWTIME` 將記錄分組在一分鐘的窗口中，然後再依據 `APPROXIMATE_ARRIVAL_TIME`。
結果中的時間戳記值會無條件捨去至最接近的 60 秒間隔。查詢發出的第一個群組結果，會顯示第一分鐘的記錄。發出的第二組結果，會根據 `ROWTIME` 顯示接下來幾分鐘內的記錄。最後一筆記錄指出應用程式擷取紀錄至應用程式內串流的時間延遲 (與擷取時間戳記相比，顯示了延遲 `ROWTIME` 值)。
```
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.
```
透過將結果推送至下游資料庫，您可以合併結果，以獲得最終精確的每分鐘計數。例如，您可以設定應用程式輸出，將結果保留到可寫入 Amazon Redshift 資料表的 Firehose 交付串流。在 Amazon Redshift 資料表中顯示結果之後，您可以查詢資料表來計算依據 `Ticker_Symbol` 分組的總計數。在 `XYZ` 的情況，即使記錄遲到，總數也是準確的（6\$11）。