行タイムスタンプを使用してパイプラインのレイテンシを測定する

行タイムスタンプは、テーブル内の各行が最後にいつ更新されたかについて正確な時系列の記録を提供します。同一のトランザクションで変更された行はまったく同じタイムスタンプを共有し、異なるトランザクションで変更された行はコミットされた時間の順に並べられます。

主なユースケースには、次が含まれます。

  • **パイプラインの観測可能性：**ストリーミングインジェスト、CDC、およびETLのワークロードにおいて、エンドツーエンドのレイテンシやデータの鮮度をクライアント側のタイムスタンプよりも高い精度で測定します。

  • **信頼性の高い増分処理：**確定的なコミット時間を使用することで、イベントタイムスタンプでは見落とされてしまう可能性のある遅延レコードやバックフィルされた記録をキャプチャします。

  • **確定的な監査証跡：**規制コンプライアンスやSCD2スタイルのマイルストーンのために、イベントの時系列順序を確立します。

テーブルに行タイムスタンプを設定するには、次のいずれかを使用します。

  • **テーブルに行タイムスタンプを設定する：**テーブルのOWNERSHIP権限を持つロールを使用して、/sql-reference/sql/create-table`または:doc:/sql-reference/sql/alter-table`コマンドの実行時にROW_TIMESTAMPプロパティをTRUEに設定します。

    例: CREATE TABLE … ROW_TIMESTAMP = TRUE または ALTER TABLE … SET ROW_TIMESTAMP = TRUE。

  • **コンテナ内の新規テーブルにデフォルトで行タイムスタンプを設定する：**コンテナでROW_TIMESTAMP_DEFAULTプロパティをTRUEに設定します。

    例：:code:`ALTER SCHEMA … SET ROW_TIMESTAMP_DEFAULT = TRUE`は、このパラメーターの設定後にスキーマで作成されるすべての新しいテーブルが、デフォルトで行タイムスタンプを持つことを意味します。

  • **既存テーブルに一括で行タイムスタンプを有効にする：**システム関数SELECT SYSTEM$SET_ROW_TIMESTAMP_ON_ALL_SUPPORTED_TABLESを使用します。

    例: SELECT SYSTEM$SET_ROW_TIMESTAMP_ON_ALL_SUPPORTED_TABLES('schema', '{my_db}.my_schema')。

    • 最初の引数はレベルで、schema、database、:code:`account`のいずれかです。

    • 2番目の引数は、コンテナの完全修飾名です。

    この関数は、コンテナー内の対象となる既存のテーブルすべてに行タイムスタンプ列を追加し、新しく作成されたテーブルで自動的に行タイムスタンプが有効になるようにします。

    関数を正常に実行するには、関数の呼び出し先のコンテナーに対するMODIFY権限が必要です。

行タイムスタンプが有効になると、テーブルはMETADATA$ROW_LAST_COMMIT_TIME列を公開します。これは、各行が最後に変更されたときのタイムスタンプを返します。これにより、行の変更時間に基づいて変更の追跡、インクリメント処理、およびTime Travelクエリが可能になります。

注釈

データ共有シナリオの場合、プロデューサーテーブルで行タイムスタンプが有効化されていても、コンシューマーはMETADATA$ROW_LAST_COMMIT_TIMEを選択できません。コンシューマーとの行タイムスタンプ共有が必要な場合、プロデューサーは、METADATA$ROW_LAST_COMMIT_TIMEを選択するビューを作成して共有する必要があります

次のステートメントは、行タイムスタンプをサポートするテーブルの作成方法を示しています。このステートメントは、テーブルにデータを挿入し、各行のタイムスタンプを取得します。

CREATE OR REPLACE TABLE table1(value1 STRING)
  ROW_TIMESTAMP = TRUE;

INSERT INTO table1 VALUES('some-value-a');

INSERT INTO table1 VALUES('some-value-b');

SELECT METADATA$ROW_LAST_COMMIT_TIME AS row_timestamp, *
  FROM table1
  ORDER BY 1;
Copy

プライマリユースケース

METADATA$ROW_LAST_COMMIT_TIMEメタデータ列はレイテンシの追跡に役立ちます。たとえば、レイテンシの合計5秒以下を目標とする場合、この列はレイテンシにSnowflakeがどれほど関与しているかを判断するのに役立ちます。

ユースケースには次が含まれます。

  • インジェスションのレイテンシの測定：クライアントで行が作成されてから、Snowflakeで表示されるまでの時間を追跡し、ユーザーがデータのインジェスション時間を計算できるようにします。

  • エンドツーエンドのレイテンシの測定：インジェスションレイテンシとパイプラインレイテンシを組み合わせて、データ生成から最終状態までの合計時間を測定します。

  • パイプラインのレイテンシの測定：データがパイプラインを移動するときのタイムスタンプを追跡します。最初のテーブルのタイムスタンプを最後のテーブルのタイムスタンプと比較することで、ユーザーはパイプラインのデータ処理にかかった時間を測定できます。

    • ストリーム、動的テーブル、タスクに基づくパイプラインがサポートされています。

例：インジェスションのレイテンシ測定

METADATA$ROW_LAST_COMMIT_TIMEメタデータ列を使用してインジェスションのレイテンシを測定するには、次を実行します。

  1. 次のいずれかのメソッドを使用して、Snowflakeにデータを送信するインジェスションパイプラインを作成します。

  2. 次を実行します。

    ALTER SESSION SET TIMESTAMP_TZ_OUTPUT_FORMAT = 'YYYY-MM-DDTHH:MI:SS.FF3 TZH';

ALTER SESSION SET TIMEZONE = 'UTC';

CREATE OR REPLACE DATABASE mydb;

CREATE OR ALTER SCHEMA myschema;

CREATE OR REPLACE TABLE table1(record_id STRING, client_timestamp TIMESTAMP_LTZ);

-- The rows inserted from server-side-insert-1 up to this point will not have a valid METADATA$ROW_LAST_COMMIT_TIME timestamp.
INSERT INTO table1 VALUES('server-side-insert-1', current_timestamp());
    Copy

  3. テーブルを変更してMETADATA$ROW_LAST_COMMIT_TIME機能を有効にします。

    ALTER TABLE table1 SET ROW_TIMESTAMP = TRUE;
    Copy

  4. ステップ1で定義したインジェスションパイプラインを使用して、``record_id``列と``client_timestamp``列を含むデータをSnowflakeテーブルに取り込みます。

  5. インジェスションパイプラインを使用しない場合は、サンプルとして新しい行を挿入します。テーブルプロパティが有効になっているため、ステップ2の挿入とは異なり、この挿入には有効なMETADATA$ROW_LAST_COMMIT_TIMEタイムスタンプが設定されます。

    INSERT INTO table1 VALUES('server-side-insert-2', current_timestamp());
    Copy

  6. クライアント側のプログラムを再度実行してから、次を実行します。

    SELECT *, METADATA$ROW_LAST_COMMIT_TIME AS ROW_TIMESTAMP, TIMESTAMPDIFF(ms, CLIENT_TIMESTAMP, ROW_TIMESTAMP)
  AS INGEST_LATENCY FROM table1 ORDER BY 2;
    Copy

セカンダリユースケース

行タイムスタンプは、次の場合にも使用できます。

  • データ保持:行タイムスタンプは、古い記録を削除してストレージコストを節約するのに役立ちます。

  • イベントの順序付けと変更の追跡：行タイムスタンプを使って変更を追跡できます。タイムスタンプが最大の行は、最新の変更を表します。

  • 追加のみのデータ：行の追加のみが許容される場合、行タイムスタンプは特定の時点からテーブルの状態をフィルターするのに役立ち、データ保持ポリシーに関係なく:doc:`Time Travel</user-guide/data-time-travel>`の使用が可能になります。

制限と考慮事項

  • 行タイムスタンプでは、同一テーブル内でのみ時系列順序の維持が保証されます。ただし、フェイルオーバー発生時は例外であり、順序が保証されません。テーブル間、異なるリージョン、異なる時間ソース間における順序は保証されません。テーブル間で、または他のソースとの間で行タイムスタンプを比較しないでください。不整合が生じるおそれがあります。

  • 行タイムスタンプは、作成時刻ではなく、最終更新時刻を反映します。たとえば、データ行がコミットされた後に更新された場合、行のタイムスタンプには、データの作成時刻ではなく、最終更新時刻が反映されます。

  • テーブルで行タイムスタンプが有効になる前に作成された行のタイムスタンプは、NULLに設定されます。

  • 行タイムスタンプは、行が保存されている限り保存されます。

  • ROW_TIMESTAMPプロパティをFALSEに設定すると、保存されているMETADATA$ROW_LAST_COMMIT_TIMEの値すべてが完全に削除されます。再度有効にしても復元されず、Time Travelクエリは何も返しません。

  • |iceberg-tm|テーブル、外部テーブル、ハイブリッドテーブル、ストリーム、ビューでは、行タイムスタンプがサポートされていません。

  • 以下のものの中でメタデータ列METADATA$ROW_LAST_COMMIT_TIMEを参照することはできません。

    • CHANGES 句

    • 行や列のアクセスポリシー、および:doc:`ストレージライフサイクルポリシー</user-guide/storage-management/storage-lifecycle-policies>`などの各種ポリシー

    • 制約

    • CLUSTER BY式

  • 行タイムスタンプは、アーカイブテーブルの復元では復元できません。回避策として、METADATA$ROW_LAST_COMMIT_TIMEをアーカイブ復元で使用する別のテーブルの永続列として実体化することができます。

行タイムスタンプのクローニングに関する考慮事項

テーブルのクローンを作成すると、行タイムスタンプは正確に保持されます。CREATE TABLE AS SELECT（CTAS）やINSERT INTO ... SELECTのようにデータの物理コピーを作成する操作では、コピーが実行された時間を反映した行タイムスタンプが割り当てられます。ソーステーブルの元の行タイムスタンプは保持されません。それらの記録を保持する場合は、次の例に示すように、永続化された列として明示的に選択してください。

CREATE TABLE my_archive AS
 SELECT *, METADATA$ROW_LAST_COMMIT_TIME AS original_commit_time
 FROM my_source_table;
Copy