데이터가 사라진 원인을 찾을 때 Impala 쪽에서 볼 수 있는 경로는 세 가지이며, 남는 기간과 정확도가 다르다.
| 경로 | 보존 | 쓰임 |
|---|---|---|
| Cloudera Manager 의 Impala Queries | 짧다. Service Monitor 보존 정책에 따른다 | 방금 일어난 일을 빠르게 확인 |
| impalad 로그 | 로그 롤링 정책에 따른다 | UI 보존 기간이 지난 뒤의 추적 |
| Impala 감사 로그 | 별도 보관 정책을 둘 수 있다 | 실행 주체까지 확정해야 하는 감사 |
Impala 의 DELETE 와 UPDATE 는 아무 테이블에나 되지 않는다. Kudu 테이블과 Iceberg 버전 2 테이블에서 동작하며, 일반 HDFS 기반 Hive 테이블에는 쓸 수 없다. 따라서 DELETE 가 실행된 흔적이 있다면 대상 테이블은 Kudu 이거나 Iceberg 다. 지원 범위는 런타임 버전마다 다르므로 대조가 필요하다 — 확인 필요.
Cloudera Manager → Impala → Queries 화면에서 기간을 좁히고 필터를 건다. 문장 내용으로 거르려면 delete 처럼 짧게 시작해 오탐을 보며 delete from 으로 좁힌다. Query Type 을 함께 걸면 COMPUTE STATS · INVALIDATE METADATA 같은 내부 질의가 섞이는 것을 줄일 수 있다.
개별 쿼리를 열면 실행 사용자, 시작·종료 시각, 전체 SQL, 프로파일을 볼 수 있다. 원본 대화에는 이 화면의 검색이 단순 부분 문자열 대조이고 정규식을 지원하지 않는다는 설명이 있었으나 확인하지 못했다 — 확인 필요. 필터 문법은 화면의 도움말에서 지원되는 속성과 연산자를 직접 대조하는 편이 빠르다.
주의할 점은 이 화면의 보존 기간이 짧다는 것이다. Service Monitor 가 보관하는 범위를 넘어가면 조회되지 않는다.
grep -i "delete from" /var/log/impala/impalad.INFO
로그가 롤링되면 지워지므로 오래된 사건에는 한계가 있다. 코디네이터 역할을 하는 노드의 로그를 봐야 한다.
감사 로그를 켜 두면 실행 주체까지 확정할 수 있다. Cloudera Manager 의 Impala 설정에서 감사 이벤트 로그를 활성화하면 JSON 으로 기록된다.
grep -i '"stmt":"delete' /var/log/impala/audit_event_log.json
규제 대응이 필요한 환경이라면 이 경로를 기본으로 켜 두고 보존 정책을 별도로 잡는다. Ranger 감사와 연동하면 중앙에서 조회할 수 있다.
서비스 계정이 Active Directory 에서 사라진 경우는 Impala 쪽 기록으로 알 수 없다. 도메인 컨트롤러의 보안 이벤트 로그에서 사용자 계정 삭제 이벤트(이벤트 ID 4726) 를 찾는다. 이 이벤트가 기록되려면 그룹 정책의 고급 감사 정책에서 계정 관리 감사가 켜져 있어야 하며, 켜져 있지 않았다면 사후에 조회할 방법이 없다.
타임아웃 설정이나 어드미션 컨트롤 동작을 시험할 때 쓴다. Impala 의 sleep() 은 밀리초를 받는다. 300 을 넘기면 0.3초 뒤 true 를 돌려주고 끝나므로, 300초를 기다리게 하려면 300000 을 넣는다.
SELECT sleep(300000);