クイズ: スキーマと壊れた行

협력사 CSV 를 inferSchema=True 로 읽었더니 어제까지 int 이던 qty 가 오늘 string 으로 나왔다. 가장 그럴듯한 원인은?

• 오늘 파일이 커서 samplingRatio 가 자동으로 줄었다
• qty 칸에 정수로 볼 수 없는 값이 한 줄 섞였다
• inferSchema 는 원래 모든 칼럼을 string 으로 읽는다
• 머리줄이 빠져서 칼럼 이름을 찾지 못했다

PERMISSIVE 모드에서 깨진 줄의 원문을 결과에 남기려면 무엇이 필요한가?

• mode 를 FAILFAST 로 바꿔 원문을 예외 메시지로 받는다
• inferSchema 를 켜서 손상 칼럼이 자동으로 생기게 한다
• 사용자 스키마에 손상 칼럼 이름의 STRING 칼럼을 넣는다
• samplingRatio 를 1.0 으로 올려 모든 줄을 검사한다

깨진 줄이 섞인 파일을 FAILFAST 로 읽고 count() 만 했더니 오류 없이 전체 줄 수가 나왔다. 이유는?

• count 에는 칼럼이 필요 없어 칼럼 가지치기로 파싱을 건너뛰었다
• FAILFAST 는 첫 1,000 줄만 검사하고 나머지는 통과시킨다
• count 는 드라이버에서 파일 크기로 줄 수를 추정한다
• 스키마를 주면 FAILFAST 가 PERMISSIVE 로 바뀐다

PERMISSIVE 와 DROPMALFORMED 중 운영 파이프라인에서 PERMISSIVE 를 고르는 가장 큰 이유는?

• PERMISSIVE 가 파싱 속도가 훨씬 빠르기 때문
• DROPMALFORMED 는 스키마를 줄 수 없기 때문
• PERMISSIVE 는 업무 규칙 위반까지 걸러 주기 때문
• 깨진 줄을 격리하고 개수를 지표로 남길 수 있기 때문

FAILFAST 로 읽은 뒤 전체 칼럼을 쓰다가 깨진 줄에서 실패했다. 원인 쪽에 붙는 오류 조건 이름은?

• PATH_NOT_FOUND
• MALFORMED_RECORD_IN_PARSING
• PATH_ALREADY_EXISTS
• CANNOT_PARSE_JSON_ARRAYS_AS_STRUCTS

스키마를 주고 header=True 로 읽었는데 협력사가 칼럼 순서를 바꿔 보냈다. 기본 설정에서 일어나는 일은?

• enforceSchema 기본값 true 로 머리줄을 무시해 위치대로 틀린 값이 들어간다
• 머리줄 이름을 보고 스키마 칼럼과 자동으로 맞춰 읽는다
• 칼럼 순서가 다르면 FAILFAST 가 아니어도 읽기가 실패한다
• 순서가 바뀐 칼럼은 모두 손상 칼럼으로 들어간다