Share via

진공 상태에서 사용되지 않는 데이터 파일 제거

  • 아티클

테이블에서 명령을 실행 VACUUM 하여 보존 임계값보다 오래된 Delta 테이블에서 더 이상 참조하지 않는 데이터 파일을 제거할 수 있습니다. 다음 고려 사항으로 인해 비용 및 규정 준수를 위해 정기적으로 실행하는 VACUUM 것이 중요합니다.

  • 사용되지 않는 데이터 파일을 삭제하면 클라우드 스토리지 비용이 줄어듭니다.
  • 제거된 데이터 파일에는 VACUUM 수정되거나 삭제된 레코드가 포함될 수 있습니다. 클라우드 스토리지에서 이러한 파일을 영구적으로 제거하면 이러한 레코드에 더 이상 액세스할 수 없습니다.

진공에 대한 주의 사항

실행 VACUUM 후 데이터 파일에 대한 기본 보존 임계값은 7일입니다. 이 동작을 변경하려면 시간 이동 쿼리에 대한 데이터 보존 구성을 참조 하세요.

VACUUM 은 파일 내에서 모든 파일을 제거한 후 빈 디렉터리를 남겨 둘 수 있습니다. 이후 VACUUM 작업에서 이러한 빈 디렉터리를 삭제합니다.

Databricks는 예측 최적화를 사용하여 델타 테이블에 대해 자동으로 실행하는 VACUUM 것이 좋습니다. Delta Lake에 대한 예측 최적화를 참조하세요.

일부 Delta Lake 기능은 데이터 파일을 다시 작성하는 대신 메타데이터 파일을 사용하여 데이터를 삭제된 것으로 표시합니다. 이러한 삭제를 커밋하고 데이터 파일을 다시 작성하는 데 사용할 REORG TABLE ... APPLY (PURGE) 수 있습니다. 데이터를 강제로 다시 작성하려면 메타데이터 전용 삭제 제거를 참조 하세요.

Important

  • Databricks Runtime 13.3 LTS 이상 VACUUM 에서는 Unity 카탈로그 관리 테이블이 있는 단순 클론에 대한 의미 체계가 다른 델타 테이블과 다릅니다. 진공 및 Unity 카탈로그 단순 클론을 참조하세요.
  • VACUUM 는 Delta Lake에서 관리되지 않는 디렉터리에서 모든 파일을 제거하여 디렉터리부터 시작 _ 하거나 .무시합니다. Delta 테이블 디렉터리 내에 Structured Streaming 검사점과 같은 추가 메타데이터를 저장하는 경우 디렉터리 이름(예: _checkpoints)을 사용합니다.
  • 보존 기간보다 오래된 테이블 버전을 쿼리하는 기능은 실행 VACUUM후 손실됩니다.
  • 로그 파일은 검사point 작업 후에 자동으로 비동기적으로 삭제되며 VACUUM. 로그 파일의 기본 보존 기간은 30일이지만 테이블에서 실행 VACUUM 하면 시간 이동에 필요한 데이터 파일이 제거됩니다.

참고 항목

디스크 캐싱을 사용하도록 설정한 경우 클러스터에 VACUUM으로 삭제된 Parquet 파일의 데이터가 포함될 수 있습니다. 따라서 파일이 삭제된 이전 테이블 버전의 데이터를 쿼리하는 것이 가능할 수 있습니다. 클러스터를 다시 시작하면 캐시된 데이터가 제거됩니다. 디스크 캐시 구성을 참조하세요.

진공에 대한 예제 구문

VACUUM eventsTable   -- vacuum files not required by versions older than the default retention period

VACUUM '/data/events' -- vacuum files in path-based table

VACUUM delta.`/data/events/`

VACUUM delta.`/data/events/` RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM eventsTable DRY RUN    -- do dry run to get the list of files to be deleted

Spark SQL 구문 세부 정보는 VACUUM을 참조하세요.

Scala, Java, Python의 구문 세부 사항은 Delta Lake API 문서를 참조하세요.

참고 항목

RETAIN 키워드(keyword) 사용하여 데이터 파일을 제거할지 여부를 결정하는 데 사용되는 임계값을 지정합니다. 이 VACUUM 명령은 이 임계값을 사용하여 지정된 시간을 되돌아보고 해당 시점의 최신 테이블 버전을 식별합니다. 델타는 해당 테이블 버전 및 모든 최신 테이블 버전을 쿼리하는 데 필요한 모든 데이터 파일을 유지합니다. 이 설정은 다른 테이블 속성과 상호 작용합니다. 시간 이동 쿼리에 대한 데이터 보존 구성을 참조 하세요.

메타데이터 전용 삭제를 제거하여 데이터 다시 쓰기 강제 적용

이 REORG TABLE 명령은 일시 삭제를 APPLY (PURGE) 적용하기 위해 데이터를 다시 쓰는 구문을 제공합니다. 일시 삭제는 데이터를 다시 작성하거나 데이터 파일을 삭제하지 않고 메타데이터 파일을 사용하여 일부 데이터 값이 변경되었음을 나타냅니다. REORG 테이블을 참조하세요.

Delta Lake에서 일시 삭제를 만드는 작업에는 다음이 포함됩니다.

  • 열 매핑을 사용하도록 설정된 열을 삭제합니다.
  • 삭제 벡터가 사용하도록 설정된 행 삭제
  • 삭제 벡터를 사용하는 경우 Photon 지원 클러스터의 모든 데이터 수정

일시 삭제를 사용하도록 설정하면 데이터가 삭제되거나 업데이트된 후에도 이전 데이터가 테이블의 현재 파일에 물리적으로 다시 기본 수 있습니다. 테이블에서 이 데이터를 물리적으로 제거하려면 다음 단계를 완료합니다.

  1. REORG TABLE ... APPLY (PURGE)를 실행합니다. 이렇게 하면 이전 데이터가 테이블의 현재 파일에 더 이상 존재하지 않지만 시간 이동에 사용되는 이전 파일에는 여전히 존재합니다.
  2. 이러한 이전 파일을 삭제하려면 실행 VACUUM 합니다.

REORG TABLE 는 작업이 완료되면 테이블의 새 버전을 만듭니다. 이 트랜잭션 이전 기록의 모든 테이블 버전은 이전 데이터 파일을 참조합니다. 개념적으로 현재 테이블 버전의 데이터가 일관성을 OPTIMIZE 유지하더라도 데이터 파일을 다시 작성하는 명령과 비슷합니다.

Important

데이터 파일은 보존 기간에 따라 VACUUM 파일이 만료된 경우에만 삭제됩니다. 즉 VACUUM , 이전 파일이 만료되도록 지연 REORG 으로 수행해야 합니다. 보존 기간 VACUUM 은 보존되는 최대 기록을 줄이는 비용으로 필요한 대기 시간을 단축하도록 줄일 수 있습니다.

진공에 필요한 크기 클러스터는 무엇인가요?

올바른 클러스터 크기를 VACUUM선택하려면 다음 두 단계로 작업이 수행된다는 것을 이해하는 데 도움이 됩니다.

  1. 작업은 사용 가능한 모든 실행기 노드를 사용하여 소스 디렉터리의 파일을 병렬로 나열하는 것으로 시작합니다. 이 목록은 삭제할 파일을 식별하기 위해 현재 델타 트랜잭션 로그에서 참조되는 모든 파일과 비교됩니다. 이 시간 동안 드라이버는 유휴 상태입니다.
  2. 그런 다음 드라이버는 삭제할 각 파일에 대한 삭제 명령을 실행합니다. 파일 삭제는 드라이버 전용 작업입니다. 즉, 작업자 노드가 유휴 상태인 동안 모든 작업이 단일 노드에서 발생합니다.

비용 및 성능을 최적화하기 위해 Databricks는 특히 장기 실행 진공 작업에 대해 다음을 권장합니다.

  • 각 작업자의 코어가 8개인 1~4명의 작업자에 대해 자동 크기 조정이 설정된 클러스터에서 진공을 실행합니다.
  • 코어가 8~32개인 드라이버를 선택합니다. OOM(메모리 부족) 오류를 방지하려면 드라이버의 크기를 늘입니다.

작업이 정기적으로 10,000개 이상의 파일을 삭제하거나 처리 시간이 30분 넘게 걸리는 경우 VACUUM 드라이버의 크기 또는 작업자 수를 늘릴 수 있습니다.

제거할 파일을 식별하는 동안 속도가 느려지면 작업자 노드를 더 추가합니다. 삭제 명령이 실행되는 동안 속도가 느려지면 드라이버의 크기를 늘려 보세요.

진공을 얼마나 자주 실행해야 하나요?

Databricks는 과도한 클라우드 데이터 스토리지 비용을 줄이기 위해 모든 테이블에서 VACUUM을 정기적으로 실행하는 것이 좋습니다. 진공의 기본 보존 임계값은 7일입니다. 임계값을 높이면 테이블에 대한 더 큰 기록에 액세스할 수 있지만 저장된 데이터 파일 수가 늘어나고 결과적으로 클라우드 공급자의 스토리지 비용이 증가합니다.

보존 임계값이 낮은 Delta 테이블을 진공 처리할 수 없는 이유는 무엇인가요?

Warning

Databricks에 따르면 테이블에 대한 동시 읽기 권한자 또는 작성기가 오래된 스냅샷과 커밋되지 않은 파일을 계속 사용할 수 있으므로 보존 간격을 7일 이상으로 설정하는 것이 좋습니다. VACUUM이 활성 파일을 정리하는 경우 동시 판독기가 실패하거나, 더 나쁜 경우에는 VACUUM이 아직 커밋되지 않은 파일을 삭제할 때 테이블이 손상될 수 있습니다. 가장 긴 동시 실행 트랜잭션보다 긴 간격과 모든 스트림이 테이블에 대한 최신 업데이트보다 지연될 수 있는 가장 긴 기간을 선택해야 합니다.

Delta Lake에는 위험한 VACUUM 명령을 실행할 수 없도록 해 주는 안전 검사가 있습니다. 지정하려는 보존 간격보다 오래 걸리는 작업이 이 테이블에서 수행되지 않다고 확신하는 경우 Spark 구성 속성 spark.databricks.delta.retentionDurationCheck.enabled를 false로 설정하여 이 안전 검사를 해제할 수 있습니다.

감사 정보

델타 트랜잭션 로그에 대한 VACUUM 커밋은 감사 정보를 포함합니다. DESCRIBE HISTORY를 사용하여 감사 이벤트를 쿼리할 수 있습니다.