문서 메뉴
문서 홈
/
MongoDB 아틀라스
/

스트림 프로세서 Windows

이 페이지의 내용

  • 텀블링 Windows
  • 호핑 Windows
  • Atlas Stream 처리 타이밍
  • 워터마크
  • 허용된 지연 시간
  • 유휴 시간 초과

Atlas Stream Processing window는 데이터 스트림의 시간 제한이 있는 하위 집합을 캡처하는 집계 파이프라인 단계 로, 스트리밍 데이터에 한정된 입력이 필요한 작업을 수행할 수 있습니다.

여기에 설명된 에 설명된 예제 스트림 프로세서를 고려하세요. $match 단계는 $source 에서 가져온 데이터 스트림에서 직접 작동할 수 있으며, 스트림 프로세서가 각 문서를 수집할 때 일치 기준과 비교하여 각 문서를 확인합니다.

반대로 $group 단계와 그 안에 포함된 다양한 통계 계산은 고려해야 할 값 집합을 먼저 제한하지 않고는 최소, 최대, 평균 또는 중앙값을 결정하는 것이 불가능하므로 제한이 없는 데이터에는 적용할 수 없습니다. $push$top 과 같은 많은 비수학적 연산자에도 제한된 데이터가 필요합니다.

스트림 프로세서는 이러한 경계에 창을 제공합니다. 창이 열리고 스트림 프로세서가 수집하는 모든 문서는 미리 정의된 시간 간격이 경과하고 창이 닫힐 때까지 해당 창 상태로 누적됩니다. 창은 해당 간격 동안 캡처한 모든 문서를 일괄 처리하고 이 세트를 내부 파이프라인을 통해 전달합니다. 이 파이프라인 내에서 배치된 문서는 미사용 데이터와 구별할 수 없습니다.

Atlas Stream Processing 은 텀블링 Windows호핑 Windows 을 지원합니다.

텀블링 Windows 은 캡처하는 시간 간격으로 완전히 정의되는 Windows 입니다. 이러한 시간 간격은 겹치지 않습니다.

예제

3초 간격으로 회전 기간을 정의합니다. 스트림 프로세서를 시작하는 경우:

  • 창이 3초 동안 열립니다.

  • 첫 번째 창은 스트림이 3초 이내에 생성하는 모든 문서를 캡처합니다.

  • 3초가 지나면 창이 닫히고 해당 창의 모든 문서에 애그리게이션 로직이 적용됩니다.

    allowedLateness 을(를) 구성하는 경우 Atlas Stream Processing은 창을 닫은 후 늦게 도착하는 메시지를 데드 레터 대기열 에 씁니다.

  • 첫 번째 창이 닫히면 새 창이 열리고 다음 3초 동안 스트림에서 문서를 캡처합니다.

텀블링 Windows는 개별 문서를 반복적으로 처리하지 않고도 데이터 스트림을 포괄적으로 캡처할 수 있도록 보장합니다.

호핑 Windows Windows 캡처하는 시간 간격과 각 창을 여는 간격( )으로 정의되는 창입니다. 지속 시간은 빈도와 분리되어 있으므로 호핑 Windows 가 겹치거나 서로 떨어져 있도록 구성할 수 있습니다.

겹치는 호핑 기간을 정의하려면 간격보다 작은 홉을 설정합니다.

예제

20초 간격과 5초의 홉으로 호핑 기간을 정의합니다. 스트림 프로세서를 시작하는 경우:

  • 창이 20초 동안 열립니다.

  • 첫 번째 창은 스트림이 20초 이내에 생성하는 모든 문서를 캡처합니다.

  • 5초 후 다른 창이 열리고 다음 20초 이내에 모든 문서를 캡처합니다. 첫 번째 Windows가 여전히 열려 있으므로 스트림이 다음 15초 동안 생성하는 모든 문서가 두 Windows에서 모두 캡처됩니다.

  • 첫 번째 창이 열린 지 20초가 지나면 닫히고 해당 창의 모든 문서에 애그리게이션 로직을 적용합니다.

  • 5초 후 두 번째 창이 닫히고 첫 번째 창에서 이미 애그리게이션 로직이 적용된 문서를 포함하여 해당 창의 모든 문서에 애그리게이션 로직을 적용합니다.

allowedLateness 을(를) 구성하는 경우 Atlas Stream Processing은 창을 닫은 후 늦게 도착하는 메시지를 데드 레터 대기열 에 씁니다.

간격이 있는 홉핑 기간을 정의하려면 간격보다 큰 홉을 설정합니다.

예제

3초 간격과 5초의 홉으로 호핑 기간을 정의합니다. 스트림 프로세서를 시작하는 경우:

  • 창이 3초 동안 열립니다.

  • 첫 번째 창은 향후 3초 동안 모든 문서를 캡처합니다.

  • 3초가 지나면 창이 닫히고 해당 창의 모든 문서에 애그리게이션 로직이 적용됩니다.

  • 2초가 더 경과한 후 다음 창이 열립니다.

  • Atlas Stream Processing은 스트림이 이 2초 동안 생성한 문서를 처리하지 않습니다.

스트리밍 데이터 처리에서 문서에는 두 가지 타이밍 시스템이 적용됩니다.

네트워크 지연 시간, 업스트림 처리 및 기타 요인으로 인해 특정 문서에 대해 이러한 시간 간의 불일치가 발생할 수 있을 뿐만 아니라 문서가 이벤트 시간 순서와 다르게 스트림 프로세서에 도착할 수도 있습니다. 두 경우 모두 Windows에서 캡처하려는 문서를 놓칠 수 있습니다. Atlas Stream Processing은 이러한 문서 가 지연 도착하는 것으로 간주하여 구성한 경우 데드 레터 대기열 로 전송합니다.

Atlas Stream Processing은 이러한 문제를 완화하기 위해 창 동작을 변경하는 다양한 메커니즘을 제공합니다.

워터마크는 처리 시간을 대체하며 프로세서가 이전에 소비한 문서보다 이벤트 시간이 더 늦은 문서를 소비하는 경우에만 업데이트됩니다. 모든 스트림 프로세서는 Atlas Stream Processing에 워터마크를 적용합니다.

5분 Windows 로 스트림 프로세서를 구성합니다. 프로세서를 12:00에서 시작하여 처음 두 Windows 의 지속 시간이 12:00-12:0512:05-12:10이 되도록 합니다. 다음 표는 워터마크 유무에 관계없이 다양한 지연이 있는 경우 어떤 Windows 가 어떤 이벤트를 캡처하는지 보여줍니다.

이벤트 시간
처리 시간
창 시간(워터마크 없음)
창 시간(워터마크)
12:00
12:00
12:00-12:05
12:00-12:05
12:00
12:01
12:00-12:05
12:00-12:05
12:01
12:03
12:00-12:05
12:00-12:05
12:03
12:04
12:00-12:05
12:00-12:05
12:02
12:05
12:05-12:10
12:00-12:05
12:01
12:06
12:05-12:10
12:00-12:05
12:04
12:06
12:05-12:10
12:00-12:05
12:05
12:07
12:05-12:10
12:05-12:10
12:06
12:07
12:05-12:10
12:04-12:10
12:06
12:08
12:05-12:10
12:05-12:10

워터마크가 적용되지 않는 시나리오에서는 Atlas Stream Processing 인스턴스의 시스템 시계에 따라 12:0512:00-12:05 창이 닫히고 12:05-12:10 창이 즉시 열립니다. 결과적으로 소스는 12:00-12:05 간격 동안 7개의 문서를 생성했지만 관련 창은 4개의 문서만 캡처합니다.

워터마크가 적용되는 시나리오에서는 12:00-12:05 창이 해당 지점까지 수집하는 문서 중 최신 이벤트 시간(따라서 워터마크 값)이 12:03 이기 때문에 12:05 에 닫히지 않습니다. 12:00-12:05 창은 스트림 프로세서가 이벤트 시간이 12:05 인 문서를 수집하고 워터마크를 해당 시간으로 진행하고 12:05-12:10 창을 열 때 시스템 시계에서 12:07 가 될 때까지 닫히지 않습니다. 각 창은 해당 문서를 모두 캡처합니다.

이벤트 시간과 처리 시간의 차이가 충분히 차이가 나면 워터마크가 예상 창을 닫을 만큼 진행된 후에 문서가 스트림 프로세서에 도착할 수 있습니다. 이를 완화하기 위해 Atlas Stream Processing은 워터마크를 기준으로 창 닫기를 설정된 간격만큼 지연시키는 설정인 허용 지연 시간을 지원합니다.

워터마크는 스트림 프로세서의 속성이지만 허용 지연 시간은 창의 속성이며 해당 창이 닫히는 경우에만 영향을 미칩니다. 스트림 프로세서의 워터마크가 새 창이 열리도록 하는 지점으로 진행되는 경우 허용 지연 시간은 이를 방지하지 않고 이전 창을 계속 열어 둡니다.

5분 텀블링 Windows 를 사용하여 스트림 프로세서를 구성합니다. 프로세서를 12:00에서 시작하여 처음 두 Windows 의 지속 시간이 12:00-12:0512:05-12:10이 되도록 합니다. 허용 지연 시간을 2 분으로 설정했습니다.

아래 표는 스트림 프로세서가 설명된 문서를 수집하는 순서를 반영합니다.

이벤트 시간
워터 마크
허용된 지연 시간
창 시간
12:00
12:00
11:58
12:00-12:05
12:01
12:01
11:59
12:00-12:05
12:03
12:03
12:01
12:00-12:05
12:02
12:03
12:01
12:00-12:05
12:04
12:04
12:02
12:00-12:05
12:01
12:04
12:02
12:00-12:05
12:05
12:05
12:03
12:00-12:15, 12:05-12:10
12:06
12:06
12:04
12:00-12:05, 12:05-12:10
12:04
12:06
12:04
12:00-12:05, 12:05-12:10
12:07
12:07
12:05
12:05-12:10

워터마크가 12:05 진행되면 12:05-12:10 창이 열립니다. 그러나 허용된 지연 시간 간격은 2 분이므로 12:00-12:05 창 내에서 사실상 12:03 만 허용되므로 열린 상태로 유지됩니다. 워터마크가 12:07 로 진행된 경우에만 조정된 시간이 12:05 에 도달합니다. 이 시점에서 12:00-12:05 창이 닫힙니다.

기본적으로 윈도우 동작을 처리 시간과 분리하면 대부분의 경우 스트림 처리 정확성이 향상됩니다. 그러나 스트리밍 데이터 소스는 유휴 기간이 길어질 수 있습니다. 이 시나리오에서는 창이 유휴 기간 이전의 이벤트를 캡처하고 워터마크가 닫힐 만큼 진행되기를 기다리는 동안 처리된 결과를 반환하지 못할 수 있습니다.

Atlas Stream Processing 을 사용하면 Windows 에 대한 유휴 시간 제한을 구성하여 처리 시간을 사용하여 이러한 시나리오를 완화할 수 있습니다. 유휴 시간 제한은 처리 시간이 열린 창 간격의 끝을 지나고 스트림 프로세서의 소스가 유휴 상태일 때 시작되는 시간 간격입니다. 소스가 유휴 시간 제한과 동일한 간격 동안 유휴 상태로 유지되면 문서 수집과 관계없이 창이 닫히고 워터마크가 진행됩니다.

3분 간격 및 1분의 유휴 시간 제한을 사용하여 텀블링 창을 구성합니다. 다음 표는 창 간격 중과 후에 유휴 시간 제한이 미치는 영향을 보여줍니다.

처리 시간
이벤트 시간 또는 상태
워터 마크
창 시간
12:00
12:00
12:00
12:00-12:03
12:01
소스 유휴 상태
12:00
12:00-12:03
12:02
소스 유휴 상태
12:00
12:00-12:03
12:03
소스 유휴 상태
12:00
12:00-12:03
12:04
12:02
12:02
12:00-12:03
12:05
12:05
12:05
12:03-12:06
12:06
소스 유휴 상태
12:05
12:03-12:06
12:07
소스 유휴 상태
12:00
12:06-12:09
12:08
소스 유휴 상태
12:00
12:06-12:09
12:09
12:09
12:09
12:09-12:12

12:00-12:03 간격 동안 소스는 3분 동안 유휴 상태이지만, 처리 시간이 창 간격의 끝을 넘지 않았으므로 스트림 프로세서는 창을 닫지 않으며, 소스는 창 간격이 끝난 후에도 유휴 상태를 유지하지 않습니다. 워터마크가 12:05 로 진행되면 창이 정상적으로 닫히고 12:03-12:06 창이 열립니다.

소스가 12:06 에 유휴 상태가 되면 12:07 까지 유휴 상태로 유지되어 유휴 시간 제한이 트리거되고 워터마크가 12:06 로 진행됩니다.

← 시작하기
보안 →