慎重に検討した結果、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 列
<a name="timestamps-rowtime-concepts"></a>

アプリケーション内ストリームには、`ROWTIME` という特別な行が含まれています。Amazon Kinesis Data Analytics によって最初のアプリケーション内ストリームに行が挿入されると、タイムスタンプが保存されます。`ROWTIME` は、Amazon Kinesis Data Analytics がストリーミングソースからレコードを読み取った後、最初のアプリケーション内ストリームにレコードを挿入した時点のタイムスタンプを反映します。この `ROWTIME` 値はその後、アプリケーション全体で維持されます。

**注記**  
1 つのアプリケーション内ストリームから別のアプリケーション内ストリームにレコードをポンプする際に、`ROWTIME` 列を明示的にコピーする必要はありません。この列は Amazon Kinesis Data Analytics でコピーされます。

Amazon Kinesis Data Analytics は、`ROWTIME` の値が一定間隔で増加することを保証します。このタイムスタンプは、時間ベースウィンドウのクエリで使用されます。詳細については、「[ウィンドウクエリ](windowed-sql.md)」を参照してください。

ROWTIME 列には、アプリケーション内ストリームの他の列と同様に、`SELECT` ステートメント内でアクセスできます。例えば、次のようになります。

```
SELECT STREAM ROWTIME, 
              some_col_1, 
              some_col_2
FROM  SOURCE_SQL_STREAM_001
```

## ストリーミング分析でのさまざまな時間を理解する
<a name="out-of-order-rows"></a>

`ROWTIME` の他に、リアルタイムストリーミングアプリケーションには別のタイプの時間があります。次のようなものがあります。
+ **イベント時間** – イベントが発生したときのタイムスタンプ。*クライアント側の時間*と呼ばれることもあります。イベントが発生した時間であるため、分析でこの時間を使用するのが望ましい場合がよくあります。しかし、携帯電話やウェブクライアントなど多くのイベントソースは信頼性の高い時計を持たないため、時間が不正確になる場合があります。さらに、接続性の問題で、レコードがイベントの発生と同じ順序でストリームに現れない場合があります。

   
+ **取り込み時間** — レコードがストリーミングソースに追加されたときのタイムスタンプ。Amazon Kinesis Data Streams は、このタイムスタンプを提供する `APPROXIMATE_ARRIVAL_TIME` というフィールドをすべてのレコードに含んでいます。*サーバー側の時間*と呼ばれることもあります。取り込み時間は、多くの場合、イベント時間にかなり近い近似値です。ストリームへのレコード取り込みに何らかの遅延が発生した場合は不正確になることがありますが、通常は稀なケースです。また、取り込み時間の順序が入れ替わることはめったにありません。ただし、ストリーミングデータの分散特性のために発生する可能性はあります。そのため、取り込み時間はエベント時間をもっとも正確に順序正しく反映しています。

   
+ **処理時間** — Amazon Kinesis Data Analytics が最初のアプリケーション内ストリームに行を挿入したときのタイムスタンプ。Amazon Kinesis Data Analytics は、このタイムスタンプを各アプリケーション内ストリームに存在する `ROWTIME` 列に提供します。処理時間は常に一定間隔で増加しています。ただし、アプリケーションが遅れている場合は正確ではありません。(アプリケーションが遅れた場合、処理時間がイベント時間を正確に反映しなくなります)。この `ROWTIME` は経過時間に関しては正確ですが、実際にイベントが発生した時間ではない場合があります。

時間ベースのウィンドウクエリでこれらの時間を使用するには、それぞれ利点と欠点があります。これらの時間を 1 つ以上選択し、またそれに伴う欠点に対処する戦略をお客様のユースケースシナリオに基づいて選択することをお勧めします。

**注記**  
行ベースのウィンドウを使用する場合は、時刻は問題ではないため、このセクションは無視してかまいません。

`ROWTIME` と他の時間 (取り込み時間またはイベント時間) の 2 つの時間ベースを両方使用した 2 ウィンドウ戦略をお勧めします。
+ 次の例に示すように、クエリで結果を発行する頻度を制御する `ROWTIME` を最初のウィンドウとして使用します。論理時間としては使用されません。
+ 分析に関連付ける論理時間であるその他の時間のうち 1 つを使用します。この時間は、いつイベントが発生したかを示します。次の例では、分析の目的はレコードをグループ化し、ティッカーでカウントを返すことです。

この戦略の利点は、イベントが発生したときを示す時間を使用できることです。アプリケーションが遅れたときやイベントの到達順序が入れ替わったときに適切に処理できます。アプリケーション内ストリームにレコードを持ってくるときにアプリケーションが遅れた場合でも、2 番目のウィンドウの論理時間でグループ化されます。クエリは `ROWTIME` を使用して処理順序を保証します。遅延したレコード (取り込みタイムスタンプの値が `ROWTIME` 値よりも早い) も正常に処理されます。

[「使用開始」実習](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/get-started-exercise.html)で使用されているデモストリームに対して次のクエリを検討します。クエリは `GROUP BY` 句を使用し、1 分ごとのタンブリングウィンドウでティッカーカウントを発行します。

```
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` で、まず 1 分ごとのウィンドウの `ROWTIME` に基づいて、次に `APPROXIMATE_ARRIVAL_TIME` に基づいてレコードをグループ化します。

結果のタイムスタンプ値は、最も近い 60 秒間隔で切り捨てられます。クエリによって発行された最初のグループ結果が、最初の 1 分間のレコードを示しています。発行された 2 つめの結果グループは、`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.
```

ダウンストリームデータベースに結果をプッシュすることで、最終的な 1 分あたりの正確なカウントを得るために結果を 1 つにできます。例えば、Amazon Redshift テーブルに書き込む Firehose 配信ストリームに結果を永続化するように、アプリケーション出力を設定できます。結果が Amazon Redshift テーブルに書き込まれた後は、テーブルにクエリして `Ticker_Symbol` によってカウントグループの総数をコンピューティングできます。`XYZ` の場合、レコードが遅延したとしても総数は正確 (6\$11) です。