Databricks에서 DROP을 날리면 S3에 즉시 삭제되지 않습니다. 이는 Databricks에서 사용자가 실수로 테이블을 DROP 하였을 때를 대비하여 마련해 둔 장치입니다. 테이블을 삭제하면 30일 동안 AWS의 S3에 있는 실제 물리적 파일은 삭제되지 않고 보관하고 있다가 30일 이후에 자동으로 삭제가 됩니다.
테이블이 매우 큰 경우 이는 굉장히 비용적 부담이라고 할 수 있습니다. 그렇기 때문에 UNDROP으로 테이블을 복구 할 이슈가 전혀 없다면 물리적으로 S3에 저장된 모든 파일을 빠르게 지워야지 비용적인 부담을 덜 할 수 있습니다. 하지만 Databricks를 사용하는 사용자라면 알 수 있듯이 S3에는 Databricks에서 지정한 Table의 ID로 폴더명이 구분되어 저장됩니다.
그렇기 때문에 내가 테이블을 이미 지웠다면 NOT FOUND TABLE이라고 메시지가 나옵니다. 일반적으로 DESCRIBE DETAIL 테이블명으로 테이블의 물리적 S3 위치 및 Table의 ID를 확인 할 수 있습니다.
DESCRIBE DETAIL MY_TABLE
다음과 같이 실제로 정보가 자세하게 나옵니다. 하지만 테이블이 존재 하지 않을 경우가 문제입니다.
테이블이 존재하지 않을 경우 DESCRIBE DETAIL을 사용 할 수 없습니다. 논리적으로 테이블이 존재하지 않기 때문에 찾을 수 없기 때문입니다.
그렇다면 우리는 S3에서 Table의 ID를 모르기 때문에 30일이 지나기 전까지 S3의 불필요한 저장 공간에 대한 비용을 내야 합니다. 작은 크기의 테이블이라면 큰 이슈가 없겠으나 수십수백 TB의 데이터라면 큰 문제가 됩니다. 그렇기 때문에 이를 찾아서 지워야 합니다.
🧐찾는 방법)
1. DROP TABLE 실행 7일 이내인 경우
SHOW TABLES DROPPED IN MY_CATALOG.MY_SCHEMA
SHOW TABLES DROPPED 명령어를 통해서 찾을 수 있습니다. DROP TABLE을 수행하고 7일이 지나지 않았다면 위의 명령어를 통해서 내가 삭제한 테이블의 정보를 DESCRIBE DETAIL 처럼 볼 수 있습니다.
이는 7일 이내의 삭제된 해당하는 카탈로그 및 스키마에 해당하는 테이블의 모든 정보를 불러옵니다. 여기서 tableid라는 컬럼으로 S3의 폴더에서 조회를 하시면 실제로 폴더가 존재합니다.
하지만 이 방법은 SHOW TABLES DROPPED가 7일만 보관하기 때문에 (기본적으로) 7일이 지나면 보이지 않습니다. 그렇기 때문에 내가 삭제를 한 테이블이 7일 이후라면 다음의 방법으로 찾아야 합니다.
2. DROP TABLE 실행 7일 이후인 경우
system 테이블을 사용하여 history를 찾는 방법입니다. Databricks에는 aceess.audit 테이블이라는 로그 테이블을 제공합니다. 이 테이블에는 삭제(DROP)을 했던 내역이 남아 있기 때문에 이를 찾을 수 있습니다.
select *
from system.access.audit
where action_name = 'deleteTable'
and request_params.full_name_arg like '%MY_TABLE%'
order by event_time desc
여기서 테이블명을 검색하면 내가 삭제한 내역이 오름차순으로 정렬되어서 나옵니다. 여기에서 table_id가 S3의 폴더명과 동일합니다. full_name_arg에는 내가 삭제한 테이블의 카탈로그, 스키마, 테이블명 모든 것이 있습니다.