Apache Spark — 느린 잡의 답은 실행 계획과 이벤트 로그에 있다 · Structured Streaming · 퀴즈
퀴즈: Structured Streaming
6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
스트리밍 쿼리가 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 모드로 바뀐다