데이터 이전 후 설명 없는 NullPointerException

 ERROR TaskSetManager: Task 0 in stage 5.0 failed 4 times; aborting job
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 5.0 failed 4 times, most recent failure: Lost task 0.3 in stage 5.0  : java.lang.NullPointerException
    at org.apache.spark.sql.execution.datasources.orc.OrcColumnVector.getUTF8String(OrcColumnVector.java:167)
    ...

데이터 이전을 잘 하고 나머지 집계도 잘 동작하는지 확인하기 위해 검증하는 도중 원인 설명이 제대로 되지 않은 문제가 발생했다.

원인

이전 이전의 Table에 필요한 columns을 추가하였고, 생성문은 관련된 columns끼리 묶어 관리하기 위해 순서를 변경함

그로 인하여 기존 테이블 스키마 순서와 이전할 테이블의 순서가 다르기 때문에 문제가 발생함.

간단 설명

1. 아래와 같은 테이블이 존재했다 가정하고 시작해보자

   id	passwd	name
   id1	passwd1	nane1
   id2	passwd2	nane2
   id3	passwd3	nane3

2. email칼럼을 추가하기위해 데이터를 추가하였다.

   id	passwd	name	email
   id1	passwd1	nane1	email1
   id2	passwd2	nane2	email2
   id3	passwd3	nane3	email3

3. 이전한 테이블은 id,passwd,email,name 순으로 테이블 스키마를 정의했다.

4. create external table if not exists db명.tb명 ( id string , passwd string , email string , name string ) ;

5. 복제할때 기존 테이블의 스키마 순서인 id,passwd,name,email 가아닌 id,passwd,email,name 로 스키마 순서가 바뀌어 데어터 순서가 뒤섞여 복제가 되었다.

   id	passwd	email	name
   id1	passwd1	nane1	email1
   id2	passwd2	nane2	email2
   id3	passwd3	nane3	email3

해결책

1번 해결책

생성문을 기존 칼럼 순서와 동일하게 만든다.

create external table if not exists db명.tb명 (
      id      string
    , passwd  string
    , name    string
    , email   string
)
;

• 위에 설명한 원인을 예시로 보면 위와 같이 기존 테이블 순서에 맞게 변경한 후 이관시킨다
• 하지만 이 방법은 columns끼리 묶으려고 순서를 변경하였기에 썩 좋지 않은 방법이라고 생각한다.

2번 해결책 ( 실패 )

ALTER TABLE test_change CHANGE [ col_name ] [col_new_name] [type] [location] 을 이용하여 순서변경

alter table db명.tb명 change id     id      string first         ;
alter table db명.tb명 change passwd passwd  string after  id     ;
alter table db명.tb명 change name   name    string after  passwd ;
alter table db명.tb명 change email  email   string after  name   ;

• 실 구동은 해보지 않음 hive cwiki

• 아래 테이블의 차이처럼 metadata 까지 변경 되는것으로 보이기 때문에 기각

  id	passwd	email	name
  id1	passwd1	nane1	email1
  id2	passwd2	nane2	email2
  id3	passwd3	nane3	email3

  id	passwd	name	email
  id1	passwd1	email1	nane1
  id2	passwd2	email2	nane2
  id3	passwd3	email3	nane3

3번 해결책 ( 성공 )

select a.CD_ID, a.COLUMN_NAME, a.INTEGER_IDX
from hive.COLUMNS_V2 a
inner join hive.SDS b
    on  b.CD_ID = a.CD_ID
inner join hive.TBLS c
    on  c.SD_ID = b.SD_ID
    and c.TBL_NAME = 'table_name'
order by INTEGER_IDX
;

• 출력 예시

  CD_ID	COLUMN_NAME	INTEGER_IDX
  504	member_id	0
  504	char_id	1
  504	first_time	2
  504	last_time	3
  504	reg_time	4

• 위와 같이 metastore 정보를 확인해보면 COLUMN_NAME,integer_idx을 확인할 수 있다.

• 해당 COLUMN_NAME과 INTEGER_IDX의 값과 순서를 기존 테이블과 동일하게 만들어주면된다.

• 따로 외래키등이 걸려있지 않아서 해당 CD_ID의 값을 insert overwrite로 해결하였다.

추정되는 원인

기존에 hive.metastore.schema.verification=false로 처리가 되어 있어 schema 검증을 제대로 안 되서 그런 것으로 추정됨

hive --orcfiledump /File_Path 이 명령어를 이용하여 orc 파일의 schema를 확인해보니, 아래와 같다.

1. hive.metastore.schema.verification=true

   Structure for /File_Path
   File Version: 0.12 with HIVE_8732
   Rows: 1151
   Compression: SNAPPY
   Compression size: 262144
   Type: struct<member_id:string,char_id:string,first_time:timestamp,last_time:timestamp,reg_time:timestamp>
   
   Stripe Statistics:
   Stripe 1:
       ...
   
   File Statistics:
   ...
   
   Stripes:
   ...

2. hive.metastore.schema.verification=false

   Structure for /File_Path
   File Version: 0.12 with HIVE_13083
   Rows: 1095
   Compression: SNAPPY
   Compression size: 262144
   Type: struct<_col0:string,_col1:string,_col2:timestamp,_col3:timestamp,_col6:timestamp>
   
   Stripe Statistics:
   Stripe 1:
       ...
   
   File Statistics:
   ...
   
   Stripes:
   ...

위 결과를 보면 hive.metastore.schema.verification=true를 해야 orc의 schema값이 Hive의 스키마로 잘 생성된다.

1. true

   • Type: struct<member_id:string,char_id:string,first_time:timestamp,last_time:timestamp,reg_time:timestamp>

2. false

   • Type: struct<_col0:string,_col1:string,_col2:timestamp,_col3:timestamp,_col6:timestamp>

데이터 이전 전의 테이블이 false로 되어있던 것 이기 때문에 테스트는 하지 못 하였으나, 겪은 문제처럼 칼럼 순서가 뒤바뀐 이유는 이것으로 추정된다.

이전 사유

HDP 라이센스 문제로 Hadoop-EchoSystem 재구축함에 따라 HDFS, Hive의 버전을 변경하게 됬다

• HDFS 2.7.3 -> 3.1.1
• Hive 1.6.3 -> 3.1.2

이전 방법

데이터 복사

# hdfs dfs -cp -f -p src dist
hdfs dfs -cp -f -p hdfs://기존HDFS 주소/기존 테이블 경로/*  hdfs://이전될 HDFS 주소/기존 테이블 경로  

• (hdfs://이전될 HDFS 주소) 은 명령어 실행위치가 loacal이면 생략해도 된다.
• option ( 필요 없다면 생략 가능 )
  • f : 덮어쓰기
  • p : 파일정보 그대로 가져가기 e.g 생성일자, 생성 user, group.. 등

복사(전송) 확인

# hdfs dfs -ls path
hdfs dfs -ls /apps/hive/dbName/tbName
drwxr-xr-x   - hive hadoop          0 2022-09-15 19:38 /apps/hive/dbName/tbName
.....

• 위와 같이 기존과 동일한 hive partition 구조로 디렉토리 및 파일이 잘 전송됬으면 된다.
• (hdfs://이전될 HDFS 주소) 은 명령어 실행위치가 loacal이면 생략해도 된다.

테이블 인식

msck repair table bd명.tb명;

• 위와 같이 테이블 복구(msck repair)를 해주면 끝이다.
  • hdfs에는 옮겨졌지만, metastore은 인식하고 있지 않으니 msck repair을 해줘야한다
  • 궁금하다면 msck를 하기전에 조회를 해보고, msck를 한 후 조회를 해보면 msck를 한 기점으로 조회가 되는 것을 확인할 수 있을 것 이다.

결론

우연치 않은 기회로 Hive Records 이전 작업을 수행했다.

처음에는 cp 명령어로 간단하게 될까 했는데 진짜 되서 당황스러웠다,

그래도 막히는 부분이 있어서 여러 문제에 봉착할 줄 알았지만, 기존 테이블과 동일한 조건으로 생성한 후 진행해서 그런지 첫 시도에 해결을 했고 시간을 많이 안 잡아먹어서 다행이다.

이제 저것을 기반으로 shell script만 만들고 성공하면 운영 서버 데이터 이전할 때 편안하게 사용해야겠다.

작성 후 작업중 추가로 발생한 에러

데이터 이전 후 추가로 발생한 에러