신중한 고려 후 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 열
애플리케이션 내 스트림에는 `ROWTIME`이라고 하는 특수 열이 있습니다. Amazon Kinesis Data Analytics가 첫 번째 애플리케이션 내 스트림에 행을 삽입하면 타임스탬프를 저장합니다. `ROWTIME`은 Amazon Kinesis Data Analytics이 스트리밍 소스에서 읽은 후 첫 번째 애플리케이션 내 스트림을 레코드에 삽입한 타임스탬프를 나타냅니다. 그런 다음 이 `ROWTIME` 값은 애플리케이션 전체에 걸쳐 유지됩니다.
**참고**
한 애플리케이션 내 스트림에서 다른 스트림으로 레코드를 펌핑할 경우, 열을 명시적으로 복사할 필요가 없습니다. Amazon Kinesis Data Analytics가 대신 이 열을 복사합니다.
Amazon Kinesis Data Analytics는 `ROWTIME` 값의 단조 증가를 보증합니다. 시간 기반 윈도우 모드 쿼리에서 이 타임스탬프를 사용합니다. 자세한 설명은 [윈도우 모드 쿼리](windowed-sql.md) 섹션을 참조하십시오.
애플리케이션 내 스트림에 있는 임의의 다른 열과 같이 `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` 값에 비해 앞서는 경우) 성공적으로 처리됩니다.
다음 쿼리를 [시작하기 실습](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`에서 먼저 `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.
```
결과를 다운스트림 데이터베이스로 푸시함으로써 최종적으로 정확한 분당 수에 대해 결과를 결합할 수 있습니다. 예를 들어, 결과를 Firehose 전송 스트림에 유지하여 Amazon Redshift 테이블에 작성할 수 있도록 애플리케이션 출력을 구성할 수 있습니다. 결과가 Amazon Redshift 표에 기록되고 나면 이 표를 쿼리하여 `Ticker_Symbol`별로 총 수 그룹을 계산할 수 있습니다. `XYZ`의 경우 레코드가 늦게 도착하더라도 총계는 정확합니다(6\+1).