타임스탬프와 ROWTIME 열 - SQL애플리케이션용 Amazon Kinesis Data Analytics 개발자 가이드
스트리밍 분석에서 사용되는 다양한 시간의 이해

새 프로젝트의 경우 애플리케이션용 Kinesis Data Analytics보다 Apache Flink Studio용 새로운 관리형 서비스를 사용하는 것이 좋습니다. SQL Managed Service for Apache Flink Studio는 사용 편의성과 고급 분석 기능을 결합하여 정교한 스트림 처리 애플리케이션을 몇 분 만에 구축할 수 있도록 합니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

타임스탬프와 ROWTIME 열

애플리케이션 내 스트림에는 ROWTIME이라고 하는 특수 열이 있습니다. Amazon Kinesis Data Analytics가 첫 번째 애플리케이션 내 스트림에 행을 삽입하면 타임스탬프를 저장합니다. ROWTIME은 Amazon Kinesis Data Analytics이 스트리밍 소스에서 읽은 후 첫 번째 애플리케이션 내 스트림을 레코드에 삽입한 타임스탬프를 나타냅니다. 그런 다음 이 ROWTIME 값은 애플리케이션 전체에 걸쳐 유지됩니다.

참고

한 애플리케이션 내 스트림에서 다른 스트림으로 레코드를 펌핑할 경우, 열을 명시적으로 복사할 필요가 없습니다. Amazon Kinesis Data Analytics가 대신 이 열을 복사합니다.

Amazon Kinesis Data Analytics는 ROWTIME 값의 단조 증가를 보증합니다. 시간 기반 윈도우 모드 쿼리에서 이 타임스탬프를 사용합니다. 자세한 설명은 윈도우 모드 쿼리 섹션을 참조하세요.

애플리케이션 내 스트림에 있는 임의의 다른 열과 같이 SELECT 문에서 ROWTIME 열에 액세스할 수 있습니다. 예:

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은 일반 시계에 비해 정확하지만 이벤트가 실제 발생한 시간이 아닐 수 있습니다.

시간 기반 창 모드 쿼리에서 이들 시간 각각을 사용하는 것은 장점과 단점이 있습니다. 이들 시간 중 하나 이상을 선택하고 사용 시나리오를 바탕으로 관련 전략을 채택하는 것이 좋습니다.

참고

행 기반 윈도우를 사용하는 경우 시간은 문제가 아니며 이 섹션은 무시해도 됩니다.

두 개의 시간 기반 윈도우, 즉 ROWTIME과 다른 시간(수집 또는 이벤트 시간) 중 하나를 사용하는 2개 윈도우 전략을 권장합니다.

  • 다음 예에서와 같이 쿼리가 결과를 방출하는 빈도를 제어하는 첫 번째 윈도우로 ROWTIME을 사용합니다. 논리 시간으로는 사용되지 않습니다.

  • 분석과 연관시키고자 하는 논리 시간인 다른 시간 중 하나를 사용하십시오. 이 시간은 이벤트가 발생한 시간을 나타냅니다. 다음 예에서 분석 목적은 레코드를 그룹화하고 티커별 수를 반환하는 것입니다.

이 전략의 장점은 이벤트가 언제 발생했는지 나타내는 시간을 사용할 수 있다는 것입니다. 애플리케이션이 뒤쳐지거나 이벤트가 부적절하게 도착하면 정상적으로 처리할 수 있습니다. 애플리케이션이 애플리케이션 내 스트림으로 레코드를 가져오는 시점이 뒤쳐지는 경우에도 두 번째 윈도우에서 논리 시간 별로 그룹화할 수 있습니다. 쿼리는 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에서 먼저 ROWTIME을 바탕으로 1분 윈도우 내에서 레코드를 그룹화한 다음 APPROXIMATE_ARRIVAL_TIME을 기준으로 그룹화합니다.

결과에서의 타임스탬프 값은 가장 가까운 60초 간격으로 내림됩니다. 쿼리에 의해 방출되는 첫 번째 그룹 결과는 첫 1분 간의 레코드를 보여 줍니다. 방출된 결과의 두 번째 그룹은 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+1).