タイムスタンプと ROWTIME 列 - Amazon Kinesis Data Analytics for SQL Applications デベロッパーガイド
ストリーミング分析でのさまざまな時間を理解する

慎重に検討した結果、アプリケーションの Amazon Kinesis Data Analytics は 2 つのステップSQLで中止することにしました。

1. 2025 年 10 月 15 日以降、SQLアプリケーションの新しい Kinesis Data Analytics を作成することはできません。

2. 2026 年 1 月 27 日以降、アプリケーションを削除します。SQL アプリケーションの Amazon Kinesis Data Analytics を開始または操作することはできません。SQL それ以降、Amazon Kinesis Data Analytics のサポートは終了します。詳細については、「Amazon Kinesis Data Analytics for SQL Applications の中止」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

タイムスタンプと ROWTIME 列

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

注記

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

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

ROWTIME 列には、アプリケーション内ストリームの他の列と同様に、SELECT ステートメント内でアクセスできます。例:

SELECT STREAM ROWTIME, 
              some_col_1, 
              some_col_2
FROM  SOURCE_SQL_STREAM_001

ストリーミング分析でのさまざまな時間を理解する

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 値よりも早い) も正常に処理されます。

「使用開始」実習で使用されているデモストリームに対して次のクエリを検討します。クエリは 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+1) です。