クイズ: Structured Streaming

스트리밍 쿼리가 3번 배치를 처리하던 중 죽었다. 체크포인트에는 offsets/3 은 있고 commits/3 은 없다. 재시작하면 어떻게 되는가?

• 3번 배치를 건너뛰고 4번부터 새 파일을 읽는다
• 처음부터 모든 파일을 다시 처리한다
• 3번 배치를 offsets/3 에 적힌 같은 범위로 다시 돌린다
• commits 가 없으므로 오류를 내고 사람이 고치기를 기다린다

파일 싱크의 출력 폴더에 죽은 배치가 남긴 반쪽 파일이 있다. Spark 로 그 폴더를 읽으면 그 파일은 어떻게 되는가?

• _spark_metadata 에 적힌 파일만 읽으므로 반쪽 파일은 보이지 않는다
• 폴더의 모든 파일을 읽으므로 반쪽 파일이 결과에 섞인다
• 반쪽 파일을 만나면 FAILFAST 처럼 읽기가 실패한다
• Spark 가 읽는 순간 반쪽 파일을 찾아 지운다

협력사가 어제 보낸 묶음을 이름만 바꿔 착륙 폴더에 다시 넣었다. 파일 원본의 기본 동작은?

• 내용의 해시가 같으므로 이미 본 파일로 여기고 건너뛴다
• 수정 시각이 어제보다 늦으므로 앞선 묶음을 덮어쓴다
• 이름이 달라 새 파일로 받아들이므로 같은 내용이 또 들어온다
• maxFileAge 를 넘겼으므로 이 파일은 무시된다

trigger(availableNow=True) 에 대한 설명으로 맞는 것은?

• 새 파일이 올 때까지 기다리며 영원히 멈추지 않는다
• 쌓인 자료 전부를 반드시 배치 하나로 몰아 처리한다
• 커밋되지 못한 배치는 버리고 새 파일만 처리한다
• 지금 있는 자료를 모두 처리하고 멈추되, 여러 배치로 나눌 수 있다

event_time 에 10분 워터마크를 걸었다. 공식 문서가 보장하는 것으로 맞는 것은?

• 10분보다 늦은 자료는 반드시 버려진다
• 지금까지 본 최대 이벤트 시각보다 10분 안쪽으로 늦은 자료는 버리지 않는다
• 벽시계 기준으로 10분 뒤에 도착한 자료는 모두 버려진다
• 10분 안쪽 자료도 상태가 크면 버려질 수 있다

스트리밍 쿼리에서 워터마크 없이 dropDuplicates(["event_id"]) 를 오래 돌렸다. 가장 먼저 드러날 문제는?

• 배치가 끝날 때마다 상태가 비워져 같은 ID 가 다시 들어온다
• 이미 본 ID 를 모두 상태로 들고 있어 상태가 끝없이 자란다
• 스트리밍에서는 dropDuplicates 를 쓸 수 없어 시작할 때 실패한다
• 파일 싱크가 중복 제거를 지원하지 않아 Complete 모드로 바뀐다