### 1. 문제 상황 (Problem)
ASAC 2기 데이터 엔지니어링 실습으로 S3를 Data Lake로 삼고 AWS Athena를 연동하는 기본 파이프라인을 구축하던 중 오류가 발생했습니다.
- 데이터 원본: S3 S3
data/basic경로에 다중 JSON(dict 형태)이 나열된a.txt파일 업로드. - 테이블 설정: Athena 쿼리 편집기에서 S3 데이터를 기반으로 외부 테이블(
dummy_test_tbl)을 생성. - 발생 에러: 테이블 생성 후 쿼리 실행 시 아래와 같은 치명적 오류(Fatal Error) 발생.
HIVE_BAD_DATA: Error reading field 'event_id' at position X. invalid magic number
### 2. 팩트 기반 원인 분석 (Root Cause)
이 에러는 S3에 적재된 실제 데이터의 포맷과 Athena(Glue Data Catalog)에 정의된 테이블 포맷 설정이 불일치할 때 발생합니다.
- 잘못된 가정: 테이블을 생성할 때, '분석 효율을 위해 Parquet 포맷을 선택하면 Athena가 알아서 데이터를 Parquet 포맷으로 읽거나 변환해 줄 것'이라는 착각.
- 기술적 팩트 (Magic Number란?): 실제 S3에 있는 파일은 평문 텍스트 형식의
JSON입니다. 그러나 테이블 속성을PARQUET로 지정하면, Athena의 쿼리 엔진은 파일을 읽을 때 파일의 맨 앞 4바이트에서 Parquet 포맷의 고유 식별자인 매직 넘버(PAR1)를 찾습니다.
텍스트 파일인 JSON에는 이 바이너리 시그니처가 존재하지 않으므로 엔진이 데이터를 해석하지 못하고 즉시invalid magic number파싱 에러를 뱉어내는 것입니다. Athena는 쿼리 엔진일 뿐, 테이블 포맷을 바꾼다고 S3 S3 원본 데이터를 변환해주지 않습니다.
### 3. 논리적 해결 방법 (Solution)
데이터의 수집(Raw)과 가공(Refined) 단계를 철저히 분리하여 접근해야 합니다.
Step 1: Raw 데이터 테이블은 원본 포맷과 100% 일치하게 재생성
- 테이블의 파일 포맷을
Parquet가 아닌 원본 데이터와 동일한JSON으로 정확히 지정하여 테이블을 다시 생성합니다. (내부적으로 OpenX JSON SerDe가 사용됩니다.) - 이 테이블(
dummy_test_tbl_json)을 쿼리하면 정상적으로 S3의 JSON 텍스트를 읽어옵니다.
Step 2: 분석을 위한 Parquet 테이블은 CTAS로 별도 생성 (ETL 처리)
- JSON 포맷은 스캔 비용이 비싸고 성능이 떨어지므로, Parquet 포맷의 데이터 마트가 필요하다면 CTAS (Create Table As Select) 구문을 이용해 물리적 포맷 변환 작업을 수행해야 합니다.
-- JSON 테이블의 데이터를 읽어 Parquet 포맷으로 S3 새 경로에 저장하는 ETL 로직
CREATE TABLE dummy_test_tbl_parquet
WITH (
format = 'PARQUET',
external_location = 's3://your-bucket/data/refined/'
) AS
SELECT *
FROM dummy_test_tbl_json;
### 4. 마치며
- 스키마 온 리드(Schema-on-Read): Athena는 데이터를 읽어들이는 시점에 스키마와 포맷을 적용합니다. 물리적인 Storage Format과 논리적인 DDL 포맷 정의가 어긋나면 즉각적인
HIVE_BAD_DATA장애로 이어집니다. - 설정 창 클릭 한 번으로 포맷이 바뀌는 것이 아닙니다. 파일의 구조와 엔진의 직렬화/역직렬화(SerDe) 과정에 대한 팩트를 정확히 이해하고 데이터 파이프라인을 설계해야 합니다.
develop myself