[Databricks] Optimize / VACUUM

 

 

안녕하세요. 데이터엔지니어 주형권입니다.

어느덧 Databricks를 맡고 운영한 지 5개월 정도가 흘렀습니다. 초반에 데이터 아키텍처와 정책을 잡고 서서히 물리적인 데이터를 운영 함에 있어서 꼭 알아야 하는 개념이 무엇일까 하다가 2가지 내용이 있어서 공부 겸 찾아보고 개념을 정리하였습니다. 

 

위의 2개의 작업은 Databricks를 운영 하면서 필수적인 내용이므로 꼭 해줘야 하는 작업으로 보입니다. 정확히는 Optimize에 z-Ordering이 포함(?)인 것으로 옵션입니다. 하지만 할 때 같이 해주는 게 성능에 큰 영향을 미치는 것으로 보입니다. 개념과 함께 실제로 실행했을 때 알아야 하는 내용에 대해서도 공유하고자 합니다. 

---

Databricks의 테이블과 데이터 파일 처리 원리

Databricks에 이 2가지 명령어를 알기 위해서는 Databricks의 테이블에 INSERT / UPDATE / DELETE를 하면 어떠한 작용이 일어나는지 정확히 이해 해야 합니다. 테스트는 Databricks의 SQL 편집기(SQL Editor)에서 수행하였습니다. 

CREATE OR REPLACE TABLE databricks_table_test
(
    user_no INT 
    ,user_name STRING
    ,log_time TIMESTAMP
)
LOCATION 'user_s3_bucket_path'

 

우선 지정한 위치에 테이블을 만듭니다. 

 

테이블을 만들면 다음과 같이 _delta_log 폴더가 생깁니다.

 

폴더에 들어가보면 첫 번째 스냅숏이 보입니다. 현재 아무것도 없는 테이블의 스냅숏입니다.

INSERT INTO databricks_table_test VALUES(1,'주형권',now())

 

데이터 1건을 넣어보겠습니다.

 

새로운 스냅숏이 생겨납니다. 이렇게 한번에 작업을 할때마다 스냅샷이 계속해서 추가 됩니다. 작업이 서로 다르기 때문에 새로운 별도의 스냅샷으로 생겨나며, 하나의 데이터씩 포함되어 있습니다. 만약에 한번 더 데이터를 넣으면 다음과 같이 파일이 또 생깁니다.

 

SELECT를 하면 다음과 같이 2줄의 row가 보입니다.

 

데이터가 잘 들어가 있으며 우리가 SELECT를 하면 마지막 스냅숏 파일을 읽어서 데이터를 보여주게 됩니다. 그렇다면 이제 DELETE를 수행 해보겠습니다. DELETE를 하면 파일이 삭제 될까요? 

DELETE FROM databricks_table_test 
WHERE user_name = '주형권'

 

 

파일은 삭제되지 않고 오히려 파일이 늘어났습니다. 실제로 파일이 삭제되면 delta 테이블(Databricks 기본 테이블)은 파일을 삭제하지 않고 새로운 파일을 만들고 해당 행을 "비활성" 상태로 만듭니다. 이러한 정보는 가장 마지막에 쓰인 스냅샷 파일에 저장되어 SELECT를 하여도 결괏값은 보이지 않습니다. 실제로 SELECT를 하면 결과에 user_name에 "주형권"은 보이지 않고 "주형권 1"만 보입니다.

 

그렇다면 UPDATE는 어떨까요? UPDATE는 과연 파일을 삭제하거나 새로 생기지 않고 해당 파일을 그대로 사용할까요? 실제로 한번 진행해 보겠습니다.

 

 

파일이 또 늘어났습니다. 분명히 3번까지 있었는데 4번까지 생겼습니다. UPDATE도 DELETE와 마찬가지로 파일의 개수가 늘어나고 줄거나 그대로이지 않습니다. 우리는 여기서 중요한 사실을 알 수 있습니다.

 

Databricks는 파일을 지우지 않고 INSERT / DELETE / UPDATE 시에 파일을 계속해서 만들어 냅니다. 지금은 데이터의 수행을 많이 하지 않았고 큰 작업도 하지 않아서 체감이 안되지만 실시간 처리 및 많은 양의 데이터를 반복적으로 처리하면 성능에 영향을 미칠 수 있습니다. 

따라서 작은 파일을 너무 많이 보관하는 것은 좋지 않습니다. 그래서 이 파일을 최적화하는 작업이 Optimize 작업입니다. 그리고 여기서 옵션으로 할 수 있는 작업이 z-Ordering입니다.

---

Optimize 

 

모든 파일 시스템이 그럴 거 같지만 파일 시스템이 파일이 많을수록 읽어야 하는 개수가 늘어나므로 비효율적입니다. 그래서 최대한 파일을 압축해서 보관하는 것이 유리합니다. 이러한 작업을 하는 것이 Optimize  작업입니다. Databricks에서 말하는 최적의 파일 크기는 1GB라고 합니다. (물론 환경에 따라 다르겠지만)

 

Delta Lake Small File Compaction with OPTIMIZE

 

그래서 이러한 작은 파일은 압축하여 보관하는 것이 당연히 유리 합니다. 그럼 실제로 Optimize가 어떤 일을 하는지 확인해 보기 위해서 명령어를 실행해 보겠습니다. 명령어를 수행하기 전에 데이터를 몇 개 더 넣었습니다. (3줄)

 

 

위의 내용을 보면 파일 하나를 추가하고 파일 4개를 지웠다고 나옵니다. 하지만 실제로 S3 폴더에 가보면 파일은 줄어들지 않았습니다. 파일을 물리적으로 실제로 지운게 아니고 지워진 내용은 건너뛰라는 의미입니다. 그래서 Optimize 작업을 하여 기존에 필요 없는 파일을 건너뛰어서 성능이 올라갈 수 있습니다. 이러한 작업을 확인하기 위해서는 다음과 같은 명령어로 확인이 가능합니다. 

DESCRIBE HISTORY databricks_table_test

 

 

Optimize는 파일을 압축하지만 기존의 파일을 삭제하지는 않습니다. 위에서 파일이 삭제되었다고 하는 내용은 기존의 파일을 아예 읽지 않고 최신 파일을 참조하여 데이터를 가져온다는 의미입니다. 해당 파일은 여전히 S3에 존재하며 참조만 하지 않을 뿐 계속해서 물리적인 내용이 남아 있습니다. 

---

VACUUM

deleta 테이블은 기본적으로 과거 데이터로의 복구를 위해서 내용을 기록합니다. 그 내용이 담긴 파일을 보관하고 있습니다. 하지만 일정 기간 동안 파일을 정리하지 않으면 많은 양의 데이터가 쌓이게 되므로 S3의 저장 비용이 크게 증가합니다. 그러므로 오래된 파일을 제거하여 이러한 파일을 삭제해야 합니다. 이 명령어가 VACUUM입니다.

 

일반적으로 VACUUM으로 그냥 수행하면 보관 주기가 7일(기본 보관주기)이므로 삭제가 안되는 것으로 알고 있습니다. 옵션을 줘서 파일을 바로 삭제하도록 하겠습니다. 또한 DRY RUN 옵션을 통해서 어떤 파일이 삭제되었는지 확인할 수 있습니다.

 

 

다음과 같이 오류 발생

 

* 테이블을 그냥 VACUUM 하면 기본적으로 7일의 보관 주기가 있으므로 오류가 발생합니다. 제가 위에서 언급했듯이 Databricks에서 저는 SQL 편집기를 사용하여 테스트를 하였습니다.

 

위에 보시면 park.databricks.delta.retentionDurationCheck.enabled이 옵션을 적용해도 같은 오류가 나오면서 VACUUM이 먹지 않습니다. 그래서 내용을 찾아보니 옵션을 적용하고 실행하던지 아니면 클러스터에 옵션을 적용하던지 두 개 중에 한 개를 써야 하는데요. SQL 편집기 컴퓨팅의 경우 옵션을 넣는 곳이 없는 것 같습니다. 

 

그래서 부득이하게 노트북으로 가서 실행하였습니다. (아래는 관련 오류에 링크입니다.)

How to set retention period for a delta table lower than the default period? Is it even possible?

 

노트북에서 VACUUM DRY RUN을 수행하면 다음과 같이 나옵니다.

 

8개의 파일을 삭제하도록 나옵니다. 실제로 vacuum을 수행하고 물리적 위치(S3)에 들어가서 파일을 보면 파일이 삭제된 것을 확인할 수 있습니다. 

 

 

결론적으로 OPTIMIZE 작업은 파일을 실제로 지우진 않고 상태값을 바꿔서 삭제되었다고 표기를 해둡니다. 그렇게 메타 테이블에 저장하고 실제로 데이터를 읽을 때 불필요한 데이터를 읽지 않음으로써 성능을 끌어올리는 작업을 합니다. 

실제 삭제된 값을 지우기 위해서는 vacuum 작업이 필요하며, 이 작업을 통해서 물리적 위치에 파일을 삭제합니다. 실제 물리적 공간(S3)의 용량을 확보하기 위해서는 OPTIMIZE와 vacuum을 묶어서 작업해야 합니다.

 

---

마치며 

이 작업으로 S3 전체 용량의 1/4을 줄였습니다. 계속해서 느끼지만 공부를 하면 할수록 최적의 비용을 쓸 수 있게 해 주고 빠르게 처리하게 해주는 것 같습니다. 다음 시간에는 Z-ordering에 대해서 다뤄볼 예정이며, Z-ordering 또한 알아두면 굉장히 성능 향상에 도움을 주는 내용입니다. Databircks는 하면 할수록 굉장히 운영 능력에 따라서 많은 부분이 좌우되는 설루션인 거 같습니다. 이외에도 여러 가지 옵션에 대해서도 공부해서 다뤄볼 예정입니다.

 

감사합니다.

 

참고 : https://medium.com/@amarkrgupta96/unlocking-performance-optimize-vacuum-and-z-ordering-in-databri cks-delta-tables-6ce20999f6f5