schema on read vs schema on write

빅데이터 환경에서는 실시간으로 다양한 형태(정형/비정형 등)의 데이터를 수집함에 따라 Hive의 schema-on-read 특성을 이용하게 되는데, 이에 대해서 더 자세히 알아보도록 하자.

 

데이터를 읽는 방법에 따라 [schema-on-read] 방식과 [schema-on-write] 방식으로 나눠지게 되는데, 이 두가지 방법의 차이점은 무엇일까?

 

schema-on-read 방식이란?

• (사전적 의미) 데이터를 읽는 시점에 스키마를 정의(=확인)하는 방식
• 풀어서 설명하자면 데이터를 저장(Insert)하는 시점에서는 스키마(=테이블 구조)를 확인하지 않고 데이터를 읽는(Read with query) 시점에 테이블 형상대로 읽어준다. 이런 특성 덕분에 우선적으로 데이터를 HDFS에 저장해두고 이후에 스키마를 정의할 수 있다.
• 스키마와 상관없이 모든 데이터 형태를 저장할 수 있어서 빅데이터 환경(Hive)에서 사용되고 있다.

case1) 스키마가 정의되지 않은 경우
HDFS에 데이터 저장(컬럼10개) → 데이터 형태에 맞는 TABLE CREATE → 테이블에서 데이터 조회 가능

case2) 스키마가 이미 정의되어 있는 경우
TABLE CREATE(컬럼5개) → HDFS에 데이터 저장(컬럼10개) → 테이블에 있는 컬럼5개의 데이터만 조회 가능

 

 

schema-on-write 방식이란?

• (사전적 의미) 데이터를 저장하는 시점에 스키마를 정의(=확인)하는 방식
• 풀어서 설명하자면 데이터를 저장(Insert)하는 시점에 스키마를 확인하여 올바른 데이터 형태일 때만 저장된다. 예를 들어 정의된 스키마 보다 컬럼 수가 더 많은 데이터를 저장하려고 시도하면 에러가 발생하게 되고, 이를 해결하기 위해서는 ETL 과정을 통해 올바른 데이터 형상으로 정제 후에 저장을 해야 한다.
• 일반적으로 스키마에 따른 데이터 형상이 정해져 있기 때문에 RDBMS(관계형DB) 환경에서 사용되고 있다.

case1) 스키마 형상과 동일한 데이터가 들어온 경우
TABLE CREATE(컬럼5개) → 데이터 저장(컬럼5개) → 테이블에서 데이터 조회 가능

case2) 스키마 형상에 맞지 않은 데이터가 들어온 경우
TABLE CREATE(컬럼5개) → 데이터 저장(컬럼10개) → 에러 발생(Error)

case2에 대한 해결방법)
TABLE CREATE(컬럼5개) → 데이터를 정제(ETL)하여 컬럼5개로 변환 후 저장 → 데이터 조회 가능

 

 

 

이것에 대해 공부하게 된 이유?

업무 과정에서 put / get 등을 통해 외부 소스 데이터를 수집하는 경우가 있었는데, 동일한 데이터 파일에 대해서 Hive 테이블에서는 데이터 조회가 가능하고 Iceberg 테이블에서는 에러가 발생한 상황이 있었다. 이 상황을 확인하는 과정에서 ‘스키마 형상과 다른 데이터가 저장’된 것이 문제인 것을 인지했고 Iceberg 테이블에 컬럼을 추가하면서 상황을 해결할 수 있었다. (Iceberg에 대해서는 다음번에 추가로 설명할 예정)

여기서 Hive 테이블의 schema-on-read 특성으로 오류 없이 데이터가 잘 조회될 수 있다는 것을 알게 되었고 이 부분에 대해서 더 찾아보게 되었다. schema-on-read 방식과 schema-on-write 방식은 저마다의 차이점과 장단점이 있기 때문에 어떤게 더 우월하다고 말하진 않고 상황에 맞게 사용하는 것이 좋다.