| 명령 | 하는 일 | 비용 |
|---|---|---|
REFRESH db.tbl |
이미 알고 있는 테이블의 파일 목록과 블록 위치를 다시 읽는다 | 낮음. 해당 테이블만 |
REFRESH db.tbl PARTITION (bse_dt='20241014') |
지정한 파티션만 다시 읽는다 | 가장 낮음 |
INVALIDATE METADATA db.tbl |
그 테이블의 캐시를 버린다. 다음 조회 때 메타스토어에서 다시 읽는다 | 중간 |
INVALIDATE METADATA |
모든 데이터베이스·테이블의 캐시를 버린다 | 매우 높음 |
인자 없는 INVALIDATE METADATA 는 카탈로그 전체를 다시 만들게 하므로 운영 중 클러스터에서는 피한다. 테이블 수가 많으면 이후 첫 조회들이 줄줄이 느려진다.
기준은 단순하다. Impala 밖에서 파일만 바뀌었으면 REFRESH, Impala 밖에서 테이블·파티션 구조가 바뀌었거나 테이블이 새로 생겼으면 INVALIDATE METADATA <테이블> 이다.
REFRESH db.tbl;
INVALIDATE METADATA db.new_tbl;
Hive 에서 새 테이블을 만들고 Impala 에서 안 보인다면 후자다. 반대로 Hive 가 파티션에 데이터를 추가한 정도면 REFRESH 로 충분하다.
CDP 계열은 Hive Metastore 이벤트를 폴링해 자동으로 반영하는 기능이 있다. catalogd 의 hms_event_polling_interval_s 를 0 보다 크게 두면 켜진다. 켜 두면 수동 INVALIDATE 빈도를 크게 줄일 수 있지만, 이벤트 처리 지연이 있으므로 즉시성이 필요한 배치에서는 여전히 명시적으로 건다.
원인은 대개 둘 중 하나다.
코디네이터가 여러 대인데 로드밸런서를 통해 붙는 경우 — 갱신은 catalogd 를 통해 전파되지만, 전파가 끝나기 전에 다른 코디네이터로 붙으면 옛 메타데이터를 본다. 후속 작업이 갱신 완료를 전제한다면 SYNC_DDL 을 켠다.
SET SYNC_DDL=1;
REFRESH db.tbl;
SYNC_DDL 은 변경이 모든 코디네이터에 전파될 때까지 문장이 반환되지 않게 한다. 정확성은 올라가지만 DDL 이 직렬화되므로, DDL 이 잦은 워크로드에서 켜 두면 전체가 느려진다. 배치 마지막의 한 문장에만 거는 식으로 쓴다. DDL 이 대상이며, 메타데이터를 바꾸는 INSERT 계열까지 포함하는지는 사용하는 버전의 문서로 확인한다.
권한 부족 — Ranger 환경에서 REFRESH 는 별도 권한을 요구한다. 오류 없이 조용히 넘어가지 않고 권한 오류가 나므로 메시지를 확인한다.
Impala 에는 "이 테이블의 메타데이터가 언제 갱신됐는지" 알려 주는 명령이 없다. 실무에서는 세 가지로 추적한다.
Impala 웹 UI(http://<coordinator>:25000/queries)의 질의 이력에서 invalidate metadata · refresh 문장을 찾는다. Cloudera Manager 의 Impala Queries 화면에서도 같은 것을 볼 수 있다.
메타스토어 쪽 변경 시점은 테이블 프로퍼티로 남는다.
DESCRIBE FORMATTED db.tbl;
transient_lastDdlTime 이 마지막 DDL 시각(epoch 초)이다. 파일이 지워졌는데 Impala 가 계속 옛 파일을 보려 한다면, 이 값과 조회 실패 시각을 비교해 갱신 누락 구간을 좁힌다.
정기 작업으로 INVALIDATE METADATA 를 돌릴 때 Hue API 를 쓰는 경우가 있는데, Hue 의 편집기 API 는 버전마다 경로와 인증 방식이 달라 깨지기 쉽다. impala-shell 을 크론으로 도는 쪽이 안정적이다.
impala-shell -i coordinator.example.com:21050 --ssl -k -q "INVALIDATE METADATA db.tbl"