행 타임스탬프를 사용하여 파이프라인의 대기 시간 측정

행 타임스탬프는 테이블의 각 행이 마지막으로 업데이트된 시간에 대한 정확한 시간순 레코드를 제공합니다. 동일한 트랜잭션에서 수정된 행은 정확히 똑같은 타임스탬프를 공유하며, 다른 트랜잭션에서 수정된 행은 커밋된 시점을 기준으로 정렬됩니다.

주요 사용 사례는 다음과 같습니다.

  • 파이프라인 가시성: 클라이언트 측 타임스탬프보다 정확도가 높은 스트리밍 수집, CDC 및 ETL 워크로드의 엔드투엔드 대기 시간과 데이터 최신성을 측정합니다.

  • 신뢰할 수 있는 증분 처리: 최종 커밋 시간을 사용하여 이벤트 타임스탬프가 건너뛸 수 있는 지연되거나 백필된 레코드를 캡처합니다.

  • 최종 감사 추적: 규정 준수 또는 SCD2 스타일의 마일스톤을 위해 이벤트의 시간 순서를 설정합니다.

테이블에 행 타임스탬프를 설정하려면 다음 옵션 중 하나를 선택합니다.

  • 테이블에 행 타임스탬프 설정: 테이블에 대한 OWNERSHIP 권한이 있는 역할을 사용하여 CREATE TABLE 또는 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 또는 account 중 하나입니다.

    • 두 번째 인자는 컨테이너의 정규화된 이름입니다.

    이 함수는 컨테이너 내의 모든 기존 적격 테이블에 행 타임스탬프 열을 추가하고 새로 생성된 테이블에 행 타임스탬프가 자동으로 활성화되도록 합니다.

    함수를 성공적으로 실행하려면 함수를 호출하는 컨테이너에 대한 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. Execute the following:

    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

보조 사용 사례

행 타임스탬프는 다음과 같은 경우에도 사용할 수 있습니다.

  • 데이터 보존: 행 타임스탬프는 오래된 레코드를 삭제하여 저장소 비용을 절약하는 데 도움이 될 수 있습니다.

  • 이벤트 순서 지정 및 변경 내용 추적: 행 타임스탬프를 사용하여 변경 사항을 추적할 수 있습니다. 가장 큰 타임스탬프가 있는 행은 최신 변경 사항을 나타냅니다.

  • Append-only 데이터: 행이 추가만 되는 경우 행 타임스탬프는 특정 시점의 테이블 상태를 필터링하는 데 도움이 되므로 데이터 보존 정책과 관계없이 :doc:`Time Travel </user-guide/data-time-travel>`을 사용할 수 있습니다.

제한 사항 및 고려 사항

  • 행 타임스탬프는 순서가 보장되지 않는 장애 조치의 경우를 제외하고 동일한 테이블 내에서만 시간순으로 유지되도록 보장됩니다. 테이블, 다른 리전 또는 기타 시간 소스에서 순서를 지정하는 작업은 보장되지 않습니다. 테이블 또는 다른 소스 간에 행 타임스탬프를 비교하면 불일치가 발생할 수 있으므로 비교해서는 안 됩니다.

  • 행 타임스탬프는 생성 시간이 아니라 마지막으로 업데이트된 시간을 반영합니다. 예를 들어, 데이터 행이 커밋된 후 업데이트되는 경우 행 타임스탬프는 데이터 생성 시간이 아니라 마지막으로 업데이트된 시간을 반영합니다.

  • 테이블에 대해 행 타임스탬프가 활성화되기 전에 생성된 행의 타임스탬프는 NULL로 설정됩니다.

  • 행이 저장되어 있는 한 행 타임스탬프도 저장됩니다.

  • ROW_TIMESTAMP 속성을 FALSE로 설정하면 저장된 모든 METADATA$ROW_LAST_COMMIT_TIME 값을 영구적으로 삭제합니다. 다시 활성화해도 복원되지 않으며 Time Travel 쿼리는 아무것도 반환하지 않습니다.

  • 행 타임스탬프는 Apache Iceberg™ 테이블, 외부 테이블, 하이브리드 테이블, 스트림 또는 뷰에 지원되지 않습니다.

  • 메타데이터 열 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