Docs Menu
Docs Home
/
MongoDB Atlas
/

스트림 프로세서 Windows

이 페이지의 내용

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

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

예시 스트림 프로세서는 여기를 참고하세요. $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초 동안 생성한 문서를 처리하지 않습니다.

스트리밍 데이터 처리에서는 문서가 두 가지 타이밍 시스템의 영향을 받습니다.

네트워크 지연 시간, 업스트림 처리 및 기타 요인으로 인해 특정 문서에 대한 이러한 시간 사이에 불일치가 발생할 뿐만 아니라 문서가 이벤트 시간 순서와 다르게 스트림 프로세서에 도착할 수도 있습니다. 두 경우 모두 창에서 캡처하려는 문서를 놓칠 수 있습니다. 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:05에 닫히지 않습니다. 그 이유는 해당 시점까지 수집한 문서 중에서 가장 최근 이벤트 시간, 즉 워터마크 값이 12:03이기 때문입니다. 12:00-12:05 창은 시스템 시계의 12:07 이후에야 닫힙니다. 이때 스트림 프로세서는 이벤트 시간이 12:05인 문서를 수집하고 워터마크를 해당 시간으로 이동시킨 후 12:05-12:10 창을 엽니다. 각 창은 해당 문서를 모두 캡처합니다.

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

워터마크는 스트림 프로세서의 속성이지만, Allowed Lateness(허용 유휴 시간)은 창의 속성이며 창이 닫힐 때만 영향을 줍니다. 스트림 프로세서의 워터마크가 새 창이 열리도록 트리거하는 지점까지 적용되는 경우, Allowed Lateness(허용 유휴 시간)은 이를 막지 않고 이전 창을 열린 상태로 유지합니다.

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 로 진행됩니다.

돌아가기

시작하기