Azure Stream Analytics의 시간 처리는 스트리밍 이벤트가 발생한 시기와 도착한 시기에 따라 타임스탬프, 순서 지정 및 처리되는 방식을 결정하는 메커니즘 집합입니다. 이 문서에서는 Azure Stream Analytics 작업에서 실제 시간 처리 문제를 해결하기 위해 디자인을 선택하는 방법을 설명합니다. 시간 처리 설계 결정은 이벤트 순서 지정 요인과 밀접하게 관련되어 있습니다.
시간에 대한 배경 개념
논의의 틀을 더 효율적으로 구성하기 위해 몇 가지 배경 개념을 정의하겠습니다.
이벤트 시간: 원래 이벤트가 발생하는 시간입니다. 예를 들어, 고속도로에서 움직이는 자동차가 요금소에 접근할 때.
처리 시간: 이벤트가 처리 시스템에 도달하여 관찰되는 시간입니다. 예를 들어 요금소 창구 센서에서 자동차를 확인하고 컴퓨터 시스템에서 데이터를 처리하는 데 몇 분이 걸리는 경우가 있습니다.
워터마크: 스트리밍 프로세서에 수집된 이벤트가 있는 지점까지를 나타내는 이벤트 시간 표식입니다. 워터마크를 사용하면 시스템에서 이벤트 수집에 대한 명확한 진행률을 표시할 수 있습니다. 스트림의 특성에 따라 들어오는 이벤트 데이터가 중지되지 않으므로 워터마크는 스트림의 특정 시점까지의 진행률을 나타냅니다.
워터마크는 중요한 개념입니다. 워터마크를 사용하면 Azure Stream Analytics가 시스템에서 철회할 필요가 없는 완전하고 정확하며 반복 가능한 결과를 생성할 수 있는 시기를 결정할 수 있습니다. 처리는 예측 가능하고 반복 가능한 방식으로 수행할 수 있습니다. 예를 들어 일부 오류 처리 조건에 대해 다시 계산해야 하는 경우 워터마크는 안전한 시작 지점과 종료 지점입니다.
이 주제에 대한 추가 리소스는 Tyler Akidau의 스트리밍 101 및 스트리밍 102 블로그 게시물을 참조하세요.
최적 시작 시간 선택
Azure Stream Analytics는 이벤트 시간을 선택하는 데 두 가지 선택 사항인 도착 시간 및 애플리케이션 시간을 제공합니다.
도착 시간
도착 시간은 이벤트가 소스에 도달하면 입력 소스에서 할당됩니다. Event Hubs 입력의 경우 EventEnqueuedUtcTime 속성을 사용하고, IoT Hub 입력의 경우 IoTHub.EnqueuedTime 속성을 사용하고, Blob 입력의 경우 BlobProperties.LastModified 속성을 사용하여 도착 시간에 액세스할 수 있습니다.
도착 시간은 기본적으로 사용되며, temporal 논리가 필요하지 않은 데이터 보관 시나리오에 가장 적합합니다.
애플리케이션 시간(이벤트 시간이라고도 함)
애플리케이션 시간은 이벤트를 생성할 때 할당되며 이벤트 페이로드의 일부입니다. 애플리케이션 시간을 기준으로 이벤트를 처리하려면 SELECT 쿼리에서 Timestamp by 절을 사용합니다. Timestamp by가 없으면 이벤트는 도착 시간을 기준으로 처리됩니다.
원본 시스템이나 네트워크에서 지연을 고려하기 위해 temporal 논리가 사용되는 경우 페이로드에 타임스탬프를 사용하는 것이 중요합니다. 이벤트에 할당된 시간은 SYSTEM.TIMESTAMP에서 사용할 수 있습니다.
Azure Stream Analytics에서 시간이 진행되는 방법
애플리케이션 시간을 사용하는 경우 시간 진행은 들어오는 이벤트를 기반으로 합니다. 스트림 처리 시스템에서는 이벤트가 없는지 또는 이벤트가 지연되는지 여부를 알기 어렵습니다. 이러한 이유로 Azure Stream Analytics는 각 입력 파티션에 대해 다음과 같은 방식으로 추론 워터마크를 생성합니다.
새로운 이벤트가 들어오면 워터마크는 Azure Stream Analytics가 지금까지 확인한 가장 늦은 이벤트 시간에서 지연 허용 오차를 뺀 값으로 설정됩니다.
들어오는 이벤트가 없는 경우 워터마크는 현재 예상 도착 시간에서 지연 도착 허용 시간을 뺀 값입니다. 예상 도착 시간은 입력 이벤트가 마지막으로 표시된 시간부터 경과한 시간과 입력 이벤트 도착 시간을 더한 시간입니다.
실시간 도착 시간은 이벤트를 처리하는 Azure Stream Analytics VM이 아니라 입력 이벤트 브로커(예: Event Hubs 또는 IoT Hub)에서 생성되기 때문에 도착 시간을 예측할 수 있습니다.
디자인은 워터마크를 생성하는 것 외에도 다음 두 가지 목적을 추가로 제공합니다.
시스템에서 들어오는 이벤트의 유무에 관계없이 적시에 결과를 생성합니다.
출력 결과가 사용자에게 적시에 확인되도록 하려는 방법을 제어할 수 있습니다. Stream Analytics 작업에 대한 Azure Portal의 이벤트 순서 지정 페이지에서 잘못된 순서 이벤트 설정을 구성할 수 있습니다. 해당 설정을 구성하는 경우 이벤트 스트림에서 잘못된 순서 이벤트의 허용 시간과 적시성의 절충점을 고려합니다.
들어오는 이벤트가 없는 경우에도 지연 도착 허용 시간은 워터마크를 계속 생성하는 데 있어 필요합니다. 때때로 이벤트 입력 스트림이 스파스인 경우와 같이 들어오는 이벤트가 들어오지 않는 기간이 있을 수 있습니다. 이 문제는 입력 이벤트 브로커에서 여러 개의 파티션을 사용함으로써 악화된 것입니다.
지연 도착 허용 창이 없는 스트리밍 데이터 처리 시스템의 경우 입력이 드문드문 이루어지고 여러 파티션을 사용할 때 출력이 지연될 수 있습니다.
시스템 동작이 반복 가능해야 합니다. 반복성은 스트리밍 데이터 처리 시스템의 중요한 속성입니다.
워터마크는 도착 시간 및 애플리케이션 시간에서 파생됩니다. 둘 모두는 이벤트 브로커에서 유지되므로 반복할 수 있습니다. 이벤트가 없을 때 도착 시간을 예상해야 하는 경우 Azure Stream Analytics는 오류 복구를 위해 재생하는 중에 반복성에 대한 예상 도착 시간을 저널링합니다.
도착 시간을 이벤트 시간으로 사용하도록 선택하는 경우 잘못된 순서 허용 시간 및 지연 도착 허용 시간을 구성할 필요가 없습니다. 입력 이벤트 브로커에서 도착 시간이 증가하도록 보장되므로 Azure Stream Analytics는 구성을 무시합니다.
지연 도착 이벤트
들어오는 각 이벤트에 대해 지연 도착 허용 시간을 정의하여 Azure Stream Analytics에서 이벤트 시간을 도착 시간과 비교합니다. 이벤트 시간이 허용 시간 범위를 벗어나는 경우 이벤트를 삭제하거나 이벤트의 시간을 허용 범위 내에 있도록 조정하도록 시스템을 구성할 수 있습니다.
워터마크가 생성되면 서비스에서 잠재적으로 워터마크보다 낮은 이벤트 시간의 이벤트를 받을 수 있습니다. 이러한 이벤트를 삭제하거나 이벤트 시간을 워터마크 값으로 조정하도록 서비스를 구성할 수 있습니다.
조정의 일환으로 이벤트의 System.Timestamp 가 새 값으로 설정되지만 이벤트 시간 필드 자체는 변경되지 않습니다. 이 조정은 이벤트의 System.Timestamp가 이벤트 시간 필드의 값과 다를 수 있으며 예기치 않은 결과가 생성될 수 있는 유일한 상황입니다.
하위 스트림에 따른 시간 변동 처리
Azure Stream Analytics가 가장 큰 관찰된 타임스탬프를 사용하여 이벤트 시간 진행률을 추적하여 허용 오차 기간을 뺀 추론 워터마크 생성 메커니즘은 대부분의 경우 다양한 이벤트 보낸 사람 간에 시간이 동기화되는 경우 잘 작동합니다. 그러나 실제로, 특히 많은 IoT 시나리오에서 시스템은 이벤트 전송자의 클록을 거의 제어할 수 없습니다. 이벤트 발신자는 현장에 있는 다양한 IoT 디바이스를 대상으로 하며, 기기 하드웨어와 펌웨어 버전에 따라 형태가 달라질 수 있습니다.
Azure Stream Analytics에는 입력 파티션의 모든 이벤트에 전역적인 워터마크를 사용하는 대신 하위 스트림이라는 또 다른 메커니즘 이 있습니다.
TIMESTAMP BY 절 및 키워드 OVER를 사용하는 작업 쿼리를 작성하여 작업에서 하위 스트림을 사용할 수 있습니다. 하위 스트림을 지정하려면 와 같은 deviceid 키워드 뒤에 키 열 이름을 제공하여 시스템에서 해당 열에 따라 시간 정책을 적용하도록 합니다. 각 하위 스트림에는 자체의 독립적인 워터마크가 있습니다. 이 메커니즘은 이벤트 전송자 간의 큰 클록 스큐 또는 네트워크 지연을 처리할 때 출력을 적시에 생성할 수 있도록 하는 데 유용합니다.
하위 스트림을 사용하는 경우 Azure Stream Analytics는 들어오는 이벤트에 지연 도착 허용 시간 기간을 적용합니다. 지연 도착 허용 시간은 서로 다른 하위 스트림에서 서로 떨어져 있을 수 있는 최대 시간을 결정합니다. 예를 들어 디바이스 1이 타임스탬프 1에 있고 디바이스 2가 타임스탬프 2에 있는 경우 최대 지연 도착 허용 시간은 타임스탬프 2에서 타임스탬프 1을 뺀 값입니다. 기본 지연 도착 허용 시간 설정은 5초이며, 타임스탬프가 서로 다른 IoT 디바이스에는 너무 작을 수 있습니다. 5분으로 시작하고 디바이스 클록 기울이기 패턴에 따라 조정합니다.
조기 도착 이벤트
조기 도착 기간은 Azure Stream Analytics가 이벤트를 삭제하기 전에 이벤트 시간을 기준으로 이벤트가 얼마나 일찍 도착할 수 있는지를 결정하는 고정된 5분 허용 시간입니다. 이 창은 지연 도착 허용 시간 창과 다른 용도로 사용됩니다.
Azure Stream Analytics는 전체 결과를 보장하므로 작업 시작 시간만 입력 시간이 아닌 작업의 첫 번째 출력 시간으로 지정할 수 있습니다. 작업 시작 시간은 시스템이 창의 중간뿐만 아니라 전체 창을 처리할 수 있도록 하는 데 필요합니다.
Azure Stream Analytics는 쿼리 사양에서 시작 시간을 파생합니다. 그러나 입력 이벤트 브로커는 도착 시간만으로 인덱싱되므로 시스템에서 시작 이벤트 시간을 도착 시간으로 변환해야 합니다. 시스템은 입력 이벤트 브로커의 해당 지점에서 이벤트 처리를 시작할 수 있습니다. 조기 도착 시간 제한을 사용하면 변환은 간단합니다(시작 이벤트 시간 - 5분 조기 도착 시간). 또한 이 계산은 시스템에서 이벤트 시간이 도착 시간보다 5분 더 큰 것으로 표시되는 모든 이벤트를 삭제한다는 것을 의미합니다. 조기 입력 이벤트 메트릭은 이벤트가 삭제될 때 증가합니다.
이 개념은 출력을 시작하는 위치에 관계없이 처리를 반복할 수 있도록 합니다. 이러한 메커니즘이 없으면 다른 많은 스트리밍 시스템이 주장하는 것처럼 반복성을 보장할 수 없습니다.
이벤트 순서 지정 허용 시간으로 인한 부작용
Azure Stream Analytics 작업에는 여러 이벤트 순서 지정 옵션이 있습니다 . Azure Portal에서는 잘못된 순서 이벤트 설정(잘못된 순서 허용 시간)과 지연 도착 이벤트 설정(지연 도착 허용 시간)의 두 가지 옵션을 구성할 수 있습니다. 조기 도착 허용 오차는 고정되어 있으며 조정할 수 없습니다. Azure Stream Analytics는 이러한 시간 정책을 사용하여 강력한 보증을 제공합니다. 그러나 이러한 설정으로 인해 다음과 같이 예기치 않은 영향을 주는 경우가 있습니다.
실수로 이벤트를 너무 일찍 보내는 경우.
초기 이벤트는 일반적으로 출력되어서는 안 됩니다. 보낸 사람의 시계가 너무 빨리 실행되는 경우 초기 이벤트가 출력으로 전송되는 것일 수 있습니다. 모든 조기 도착 이벤트가 삭제되므로 출력에서 이벤트가 표시되지 않습니다.
오래된 이벤트를 Azure Stream Analytics에서 처리할 Event Hubs로 보냅니다.
처음에는 오래된 이벤트가 무해해 보일 수 있지만 지연 도착 허용 시간 적용으로 인해 이전 이벤트가 삭제될 수 있습니다. 이벤트가 너무 오래되면 이벤트 수집 중에 System.Timstamp 값이 변경됩니다. 이 동작으로 인해 Azure Stream Analytics는 기록 이벤트 처리 시나리오보다 거의 실시간으로 이벤트 처리 시나리오에 더 적합합니다. 경우에 따라 지연 도착 이벤트 시간을 가능한 최댓값(20일)으로 설정하여 이 문제를 해결할 수 있습니다.
출력이 지연되는 것 같습니다.
첫 번째 워터마크는 계산된 시간, 즉 시스템에서 지금까지 관찰한 최대 이벤트 시간에서 잘못된 순서 허용 시간 크기를 뺀 시간에 생성됩니다. 기본적으로 잘못된 순서 허용 시간은 0(00분 00초)으로 구성됩니다. 0이 아닌 더 높은 시간 값으로 설정하면 계산된 첫 번째 워터마크 시간으로 인해 스트리밍 작업의 첫 번째 출력이 해당 시간 값(또는 그 이상)만큼 지연됩니다.
입력이 희박합니다.
지정된 파티션에 입력이 없는 경우 워터마크 시간은 도착 시간에서 지연 도착 허용 시간을 뺀 값으로 계산됩니다. 결과적으로 입력 이벤트가 간헐적으로 드문 경우 출력이 해당 시간만큼 지연될 수 있습니다. 기본 지연 도착 이벤트 값은 5초입니다. 예를 들어 입력 이벤트를 한 번에 하나씩 보내면 약간의 지연이 발생할 수 있습니다. 지연 도착 이벤트 시간을 큰 값으로 설정하면 지연이 더 심해질 수 있습니다.
System.Timstamp 값이 이벤트 시간 필드의 시간과 다릅니다.
앞에서 설명한 대로 시스템에서는 이벤트 시간을 잘못된 순서 허용 시간 또는 지연 도착 허용 시간으로 조정합니다. 이벤트의 System.Timestamp 값이 조정되었지만 이벤트 시간 필드는 조정되지 않습니다. 이를 사용하여 타임스탬프가 조정된 이벤트를 식별할 수 있습니다. 시스템이 허용 오차 중 하나로 인해 타임스탬프를 변경하는 경우 일반적으로 동일합니다.
관찰할 메트릭
다양한 이벤트 순서 지정 허용 시간의 효과는 Azure Stream Analytics 작업 메트릭을 통해 관찰할 수 있습니다. 관련된 메트릭은 다음과 같습니다.
| 메트릭 | 설명 |
|---|---|
| 순서가 맞지 않는 이벤트 | 순서가 뒤바뀌어 수신된 이벤트 중 삭제되었거나 타임스탬프가 조정된 이벤트의 수를 나타냅니다. 이 메트릭은 Azure Portal에 있는 작업의 이벤트 순서 지정 페이지의 잘못된 순서 이벤트 설정 구성에 따라 직접적인 영향을 받습니다. |
| 지연 입력 이벤트 | 원본에서 늦게 도착하는 이벤트의 수를 나타냅니다. 이 메트릭에는 삭제되었거나 타임스탬프가 조정된 이벤트가 포함됩니다. 이 메트릭은 Azure Portal에 있는 작업의 늦게 도착한 이벤트 설정 구성에서 이벤트 순서 지정 페이지에 따라 직접적인 영향을 받습니다. |
| 조기 입력 이벤트 | 5분을 넘기면, 삭제되었거나 타임스탬프가 조정된 원본으로 인해 예정보다 일찍 도착한 이벤트의 수를 의미합니다. |
| 워터마크 지연 | 스트리밍 데이터 처리 작업의 지연을 나타냅니다. 자세한 내용은 다음 섹션을 참조하세요. |
워터마크 지연 세부 정보
Azure Stream Analytics는 워터마크 지연 메트릭을 처리 노드의 벽 클록 시간에서 지금까지 본 가장 큰 워터마크를 뺀 값으로 계산합니다. 자세한 내용은 워터마크 지연을 참조하세요.
다음과 같이 일반적인 작업에서 이 메트릭 값이 0보다 큰 몇 가지 이유가 있을 수 있습니다.
스트리밍 파이프라인 고유의 처리 지연입니다. 일반적으로 이 지연은 명목적입니다.
잘못된 순서 허용 범위가 도입되면서, 이 허용 범위의 크기만큼 워터마크가 줄어들어 지연이 발생했습니다.
워터마크가 허용 시간 창의 크기만큼 감소하므로, 도착이 늦어질 가능성을 반영해 지연이 발생했습니다.
해당 메트릭을 생성하는 처리 노드에서 발생하는 클록 스큐를 나타냅니다.
스트리밍 파이프라인의 속도가 느려질 수 있는 몇 가지 다른 리소스 제약 조건이 있습니다. 워터마크 지연 메트릭이 높아질 수 있는 이유는 다음과 같습니다.
Azure Stream Analytics의 처리 리소스가 부족하여 입력 이벤트의 볼륨을 처리할 수 없습니다. 리소스를 강화하려면 스트리밍 단위 이해 및 조정을 참조하세요.
입력 이벤트 브로커 내에서 처리량이 충분하지 않으므로 제한됩니다. 가능한 해결 방법은 Azure Event Hubs 처리량 단위 자동 확장을 참조 하세요.
출력 싱크(예: Azure SQL Database, Blob Storage 또는 Power BI)는 충분한 용량으로 프로비전되지 않으므로 제한됩니다. 가능한 솔루션은 사용 중인 출력 서비스에 따라 크게 달라집니다.
출력 이벤트 빈도
Azure Stream Analytics는 워터마크 진행률을 출력 이벤트가 생성되는 유일한 트리거로 사용합니다. 워터마크는 입력 데이터에서 파생되므로 오류 복구 중 및 사용자가 시작한 재처리에서도 반복할 수 있습니다. 윈도우형 집계를 사용하는 경우, 서비스는 창의 끝에서만 출력을 생성합니다. 경우에 따라 창에서 생성된 부분 집계 결과를 보고 싶을 수 있습니다. 부분 집계는 현재 Azure Stream Analytics에서 지원되지 않습니다.
다른 스트리밍 솔루션에서는 외부 상황에 따라 다양한 트리거 지점에서 출력 이벤트를 구체화할 수 있습니다. 일부 솔루션에서는 지정된 기간의 출력 이벤트를 여러 번 생성할 수 있습니다. 입력 값이 구체화됨에 따라 집계 결과는 더욱 정확하게 됩니다. 이벤트는 처음에 추측될 수 있으며 시간이 지남에 따라 수정될 수 있습니다. 예를 들어 특정 디바이스가 네트워크에서 오프라인 상태인 경우 시스템에서 예상 값을 사용할 수 있습니다. 나중에 동일한 디바이스가 네트워크에서 온라인 상태가 됩니다. 그러면 실제 이벤트 데이터가 입력 스트림에 포함될 수 있습니다. 출력에서는 해당 시간 범위를 처리하여 더 정확한 출력을 생성합니다.
워터마크의 예시 그림
다음 이미지에서는 다양한 상황에서 워터마크가 진행되는 방식을 보여 줍니다.
다음 표에는 아래 차트에 있는 예제 데이터가 나와 있습니다. 이벤트 시간과 도착 시간은 경우에 따라 일치하거나 다를 수 있습니다.
| 이벤트 시간 | 도착 시간 | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | 디바이스3 |
| 12:19 | 12:16 | 기기1 |
| 12:12 | 12:17 | device3 |
| 12:17 | 12:18 | 장치2 |
| 12:20 | 12:19 | 디바이스2 |
| 12:16 | 12:21 | 장치3 |
| 12:23 | 12:22 | 장치2 |
| 12:22 | 12:24 | 장치2 |
| 12:21 | 12:27 | device3 |
다음 그림에 사용된 허용 시간은 다음과 같습니다.
- 이른 도착 기간은 5분입니다.
- 지연 도착 시간이 5분입니다.
- 순서 재지정 시간이 2분입니다.
이러한 이벤트를 통해 진행되는 워터마크의 예:
앞의 그래픽에 표시된 주목할 만한 프로세스:
첫 번째 이벤트(device1)와 두 번째 이벤트(device2)는 시간을 정렬했고 조정 없이 처리됩니다. 각 이벤트마다 워터마크가 갱신됩니다.
세 번째 이벤트(device1)가 처리되면 도착 시간(12:11)이 이벤트 시간(12:17)보다 앞섭니다. 이 이벤트는 6분 일찍 도착했으므로 5분 조기 도착 허용 시간으로 인해 삭제됩니다.
이러한 조기 이벤트에서는 워터마크가 진행되지 않습니다.
네 번째 이벤트(device3)와 다섯 번째 이벤트(device1)는 시간을 정렬했고 조정 없이 처리됩니다. 각 이벤트에서 워터마크가 점진적으로 발전합니다.
여섯 번째 이벤트(device3)가 처리되면 도착 시간(12:17) 및 이벤트 시간(12:12)이 워터마크 수준보다 낮습니다. 이벤트 시간은 워터마크 수준(12:17)으로 조정됩니다.
12번째 이벤트(device3)가 처리되면 도착 시간(12:27)이 이벤트 시간(12:21)보다 6분 정도 앞섭니다. 지연 도착 정책이 적용됩니다. 이벤트 시간이 워터마크(12:21)보다 높은 12:22로 조정되어 조정이 더 이상 적용되지 않습니다.
조기 도착 정책 없이 진행되는 워터마크의 발전 두 번째 사례:
이 예에서는 조기 도착 정책이 적용되지 않습니다. 워터마크는 예상보다 일찍 도착하는 비정상 이벤트로 인해 크게 상승할 수 있습니다. 이 시나리오에서는 세 번째 이벤트(deviceId1 시간 12:11)가 삭제되지 않고 워터마크가 12:15로 조정됩니다. 결과적으로 네 번째 이벤트 시간이 7분 앞으로(12:08에서 12:15로) 조정됩니다.
마지막 그림에서는 하위 스트림이 사용됩니다(DeviceId를 통해). 여러 개의 워터마크가 스트림별로 하나씩 추적됩니다. 결과적으로 시간이 조정되는 이벤트가 줄어듭니다.
