クイズ: 実行台帳と原子的コミット

결과 파일을 직접 열어 쓰던 작업이 도중에 죽었다. 다음 단계가 그 파일을 읽어 갔다. 가장 정확한 설명은?

• 파일이 잠겨 있어 다음 단계는 읽지 못하고 기다렸을 것이다
• 이름도 크기도 멀쩡한 반쯤 쓰인 파일이 남아 오류 없이 읽힌다
• 파일 시스템이 미완성 파일을 자동으로 지우므로 다음 단계는 빈 결과를 본다
• 운영체제가 쓰기를 되돌리므로 옛 내용이 그대로 남는다

임시 파일을 /tmp 에 만들고 os.replace 로 결과 디렉터리에 옮기는 코드가 있다. 개발 기계에서는 잘 돌았다. 가장 먼저 의심할 것은?

• 임시 파일 이름이 너무 길어 파일 시스템이 거절한다
• /tmp 가 주기적으로 비워져 임시 파일이 사라진다
• /tmp 의 권한이 달라 읽기 전용으로 열린다
• 두 경로가 서로 다른 파일 시스템이라 바꿔 달기가 실패한다

바꿔 달기로 산출물을 만드는데도 합계가 커졌다. 읽는 쪽은 out 디렉터리에서 part-*.json 을 모은다. 원인으로 가장 그럴듯한 것은?

• 죽은 실행이 남긴 임시 파일 이름이 그 목록에 함께 걸린다
• os.replace 가 옛 파일을 지우지 않고 복사본을 남긴다
• JSON 을 정렬해 쓰지 않아 같은 파일이 두 번 읽힌다
• 덧붙이기 모드로 열어 조각 산출물이 계속 길어진다

재개한 실행이 이번에 처리한 조각만 더해 총계를 냈다. 어떤 일이 생기는가?

• 총계가 두 배가 되어 하루치 장부가 부풀어 오른다
• 총계가 변하지 않아 재개가 아무 효과도 내지 못한다
• 건너뛴 조각이 빠져 총계가 한 번에 끝낸 실행보다 작아진다
• 조각 순서가 뒤바뀌어 총계의 자릿수가 어긋난다

재개 판단을 로그 파일의 마지막 줄로 하자는 제안이 나왔다. 가장 정확한 반론은?

• 로그가 너무 커져서 마지막 줄을 읽는 데 시간이 오래 걸린다
• 로그는 사람이 읽는 형식이라 조각이 끝났다는 사실을 프로그램이 확실히 판단할 수 없다
• 로그는 디스크에 곧바로 쓰이지 않으므로 항상 한 줄이 비어 있다
• 로그에는 시각이 없어 순서를 알 수 없다

같은 날 정산을 두 번 돌렸는데 하루치 장부가 두 줄이 되었다. 중복을 막을 기준으로 가장 알맞은 것은?

• 장부 파일의 마지막 수정 시각
• 장부의 줄 수가 하루에 하나인지
• 실행이 시작된 날짜와 시각
• 실행의 이름(run_id)이 장부에 이미 있는지