クイズ: 3種類のストリーム結合

주문 흐름에 상품 표를 시간 조건 없는 JOIN 으로 붙였다. 몇 달 뒤 상태가 계속 자라는 이유로 가장 정확한 것은?

• 상품 표가 갱신될 때마다 새 버전을 따로 쌓기 때문이다
• 워터마크가 멈춰 창이 닫히지 않기 때문이다
• 일반 조인은 양쪽 입력을 모두 상태에 두고 기본으로는 지우지 않기 때문이다
• 싱크가 느려 결과가 상태에 밀려 쌓이기 때문이다

s.ship_time BETWEEN o.order_time AND o.order_time + INTERVAL '2' HOUR 로 구간 조인했다. 주문 7200초 뒤에 나간 배송과 7201초 뒤에 나간 배송은?

• 7200초는 붙고 7201초는 붙지 않는다
• 둘 다 붙지 않는다 — 끝 경계는 제외된다
• 둘 다 붙는다 — 워터마크가 1초를 봐준다
• 7201초만 붙는다 — 시작 경계가 제외된다

append-only 환율 원천을 temporal join 의 오른쪽에 쓰려고 한다. 무엇이 필요한가?

• 환율 표에 PRIMARY KEY ... NOT ENFORCED 를 선언하면 충분하다
• 처리 시간 속성 PROCTIME() 열을 더하면 된다
• 환율 표를 배치 모드로 읽어 한 번에 적재해야 한다
• 통화별 최신 행만 남기는 ROW_NUMBER 중복 제거 뷰로 기본 키와 이벤트 시간을 갖게 한다

이벤트 시간 temporal join 을 돌린 뒤 오른쪽(환율)에 새 버전이 왔다. 이미 낸 주문 결과는?

• -U 와 +U 로 새 환율 값이 다시 나온다
• 바뀌지 않는다 — 주문은 자기 시각에 유효했던 버전과 한 번 붙는다
• TTL 이 지난 뒤에만 다시 계산된다
• 워터마크가 뒤로 돌아가 해당 주문부터 다시 처리된다

세 조인의 COMPILE PLAN JSON 을 비교했다. TTL 이 적힌 leftState·rightState 항목이 있는 것은?

• 일반 조인(stream-exec-join)뿐이다
• 구간 조인(stream-exec-interval-join)뿐이다
• 세 조인 모두 같은 두 항목을 가진다
• temporal join(stream-exec-temporal-join)뿐이다

통화 USD 의 매출을 두 방식으로 환산했다. temporal join 결과와 일반 조인(같은 버전 뷰) 결과의 최종 합계가 다른 이유는?

• 일반 조인은 첫 환율보다 이른 주문을 빼기 때문이다
• temporal join 이 소수점 넷째 자리에서 반올림하기 때문이다
• 일반 조인은 환율이 바뀔 때마다 지난 주문까지 새 환율로 다시 계산해 마지막 환율로 끝나기 때문이다
• 두 쿼리가 서로 다른 워터마크 지연을 쓰기 때문이다