hive SerDe

케이스

HDFS 경로의 파일을 대상으로 만든 Hive external table을 조회했을 때, 컬럼 값이 다음과 같이 비정상적으로 보였다.

�����A����..

처음에는 데이터 손상이나 스키마 문제인지 파악하기 위해 아래 항목들을 순서대로 확인했다.

• Hive 테이블 스키마가 실제 데이터 구조와 일치하는지
• 테이블 컬럼 순서와 데이터프레임 컬럼 순서가 서로 다른지
• 원본 Parquet 파일 자체에 이미 값이 깨져 있는지

하지만 위 항목들에서는 특별한 이상이 없었다.
즉, 원본 파일과 스키마 자체의 문제라기보다, Hive가 파일을 해석하는 방식에 문제가 있을 가능성이 더 커 보였다.

원인

SHOW CREATE TABLE, DESCRIBE FORMATTED로 테이블의 상세 설정을 확인해보니, 실제 데이터는 Parquet 파일이었는데, 테이블 메타데이터에는 이에 맞지 않는 설정이 들어가 있었다. 그 결과 Hive가 파일을 올바른 방식으로 역직렬화하지 못했고, 조회 시 문자열이 깨져 보였다.

• ROW FORMAT SERDE
• STORED AS INPUTFORMAT
• OUTPUTFORMAT

즉, 이번 케이스에서는 실제 파일은 Parquet인데, 테이블 메타데이터가 Text 기반 처리방식으로 설정되어 Parquet와 맞지 않는 SerDe를 가리키고 있어서 다음 영향이 있었다.

• 파일 바이트를 잘못 읽거나
• 컬럼 경계를 잘못 해석하거나
• 문자열 필드를 잘못 역직렬화해서

결과적으로 조회 시 한글이 ���� 같은 형태로 나타났다.

 

대응

해당 테이블 파일에 대한 재적재, 수정은 필요하지 않고 external table 메타만 수정 필요했다. 메타 수정은 alter table로 serde 설정만 변경하는 것만으로는 반영되지 않았다. 

기존 external table을 제거한 뒤, Parquet에 맞는 SerDe / InputFormat / OutputFormat을 명시하여 테이블을 다시 생성 후 정상적으로 조회되었다.

 

분석

SerDe는 Serializer/Deserializer의 약자다.

Hive는 데이터를 읽고 쓰는 I/O 과정에서 SerDe를 사용한다.

읽기) HDFS files -> InputFormat -> [raw record] -> Deserializer -> Row object
쓰기) Row object -> Serializer -> [serialized record] -> OutputFormat -> HDFS files

• InputFormat: 파일을 어떤 방식으로 읽을지 결정
• Deserializer: 파일에서 읽어온 데이터를 Hive가 이해할 수 있는 row 형태로 변환
  
• OutputFormat: 변환된 데이터를 어떤 방식으로 쓸지 결정
• Serializer: Hive의 row 데이터를 저장 가능한 형태로 변환

SerDe는 단순히 “포맷 이름”이 아니라, Hive가 파일 내용을 컬럼 값으로 어떻게 해석할지 결정하는 구성요소이다.
Hive의 읽기 경로는 대체로 InputFormat → SerDe → ObjectInspector → Operator 순서로 이해할 수 있다. InputFormat이 파일을 읽어 레코드를 가져오면, SerDe가 이를 row 객체로 역직렬화하고, ObjectInspector가 각 필드의 해석 방법을 제공한다. 이후 Hive operator가 이 정보를 이용해 SELECT, WHERE, JOIN, GROUP BY 같은 SQL 연산을 수행한다.

흐름도

---

참고

https://hive.apache.org/docs/latest/user/serde/?utm_source=chatgpt.com

https://wikidocs.net/25306