[Databricks] 대용량 테이블 파티션 재구성
Databricks에서 파티션을 재구성해야 할 때가 많이 있을 것입니다. 특히 초기에 데이터 환경을 세팅하는 경우가 그럴 것입니다. 초기에는 데이터의 패턴을 정확히 알지 못하거나 여러 가지 변수로 인하여 파티션을 재구성하는 경우가 종종 있습니다. 그럴 때 어떻게 하면 파티션을 재구성할 수 있는지에 대해서 이번에 경험을 통해서 알게 된 내용을 글로 적어보자 합니다.
Ⅰ. 처음에 어떻게 하였는가?
우선 회사의 데이터이기에 정확한 사이즈는 언급이 불가능 하지만 수십 TB단위의 데이터입니다. 그렇기에 Databricks에서 단순히 SQL을 이용하여 파티션을 재구성 하고자 했습니다.
REPLACE TABLE 테이블명
USING DELTA
PARTITIONED BY (파티션컬럼1,파티션컬럼2)
AS
SELECT * FROM 테이블명
Databricks의 경험이 전무 하기에 단순히 테이블을 그대로 읽어서 파티션을 재구성하는 SQL을 찾아서 적용하였습니다. 이 방법이 제일 깔끔하고 빠르게 될 것으로 보였기에 데이터를 사용하지 않거나 ETL이 작동하지 않는 시간대에 해당 작업을 실행하였습니다.
위의 SQL을 SQL 편집기 (SQL Editor)에서 10TB가 안되는 테이블 기준으로 수행하였습니다. 결과는 정상적으로 동작하였고 이대로 모든 테이블을 적용하면 되겠다고 생각하였습니다.
Ⅱ. 무엇이 문제였는가?
처음에 순조롭게 진행되는 것 같았으나 저는 여러가지 문제에 봉착하였습니다.
➀ 비용적 문제
SQL 편집기를 이용하면 자연스럽게 SQL Warehouse의 컴퓨팅을 사용합니다. SQL Warehouse의 경우 물론 이점이 상당히 많지만 지금 제가 하고자 하는 SQL의 경우 일회성으로 하고 있고 반본적 작업도 아닌 것을 감안하면 굳이 사용할 필요가 없습니다.
실제로 Databricks에서 제공하는 비용 계산기를 이용해서 가격을 비교하면 다음과 한 번에 와닿습니다. SQL warehouse에서 사용하는 SQL Serverless Compute와 Jobs compute(이걸로 작업하였습니다.)과의 가격 차이가 제법 있는 것을 확인할 수 있습니다.
다른 여타 성능을 본다면 물론 SQL Serverless Compute가 유리할 수 있지만 단순히 파티션 재구성이므로 Jobs Compute를 사용하여도 크게 상관이 없다고 결론을 내렸습니다. (SQL Serverless Compute가 3배 정도 비싸다고 합니다.)
➁ 실행이 불가능
위의 문제는 큰 문제도 아니었습니다. 돈이야 내면 그만이지만 실행이 되지 않는다면 어떻게 해서든 방법이 없었습니다. 여러 가지 다양한 문제가 있었는데 결국은 데이터의 양이 너무 크기 때문에 읽다가 실패하는 경우가 대부분이었습니다. 데이터의 양이 작지 않기 때문에 Compute를 많이 사용해야겠으나 비용은 무제한이 아니기 때문에 제한된 자원으로 하려고 해서 이 문제가 봉착한 것도 있습니다.
하지만 다른 여러 회사에서도 비용은 무제한이 아니기 때문에 저와 같은 문제를 만날 것이라고 생각됩니다. 그래서 다른 방법을 생각하였습니다. 물론 제가 Databricks 잘 모르기 때문에 해결을 못해서 그런 것도 있겠지만 한번 수행에 너무 많은 시간이 들고, 계속해서 이러한 문제들로 실패를 하기에 방법을 바꿔야겠다고 생각했습니다.
Ⅲ. 해결 방법
➀ Copute 변경
아까 앞서 언급했듯이 SQL Warehouse의 비용보다 Job Compute의 비용이 저렴하다고 이야기하였습니다. 그래서 SQL 편집기에서 작업을 하지 않고, 워크플로우에서 Job 형태로 만들어서 수행을 하였습니다. 이 경우 또한 여러 가지 장점이 있는데, 다음과 같습니다.
첫 번째) 컴퓨팅 구성을 자유롭게 가능
두 번째) 작업 모니터링을 통해서 각각의 상황 및 자원 사용량 한눈에 파악 가능
세 번째) 가장 중요한 비용 절감 가능
물론 SQL Warehouse도 제공을 하지만 Job Compute에서는 더욱 유연하게 독립적으로 작업마다 수행이 가능합니다. 예를 들어서 Job을 여러개 만들면 각각의 Job마다 컴퓨팅 구성을 따로 할 수 있기에 더욱 유연하게 대처가 가능 합니다.
물론 가장 중요한 것은 비용의 절감입니다. Job은 Notebook형태로 SQL을 실행 가능하므로 INSERT INTO SQL을 Notebook에 저장하여 사용하면 Job으로 실행 가능 합니다.
➁ 적재 방식을 변환
적재 방식을 아래와 같이 변경하였습니다. 기존에는 원본 테이블에서 REPLACE TABLE을 하여, 그대로 작업하는 방식이였다면 변경 후 방식은 미리 파티션을 재구성하여 임시 테이블 형태로 만들어 놓고 원본 테이블을 INSERT INTO 하는 방식으로 변경 하였습니다.
위와 같이 할 경우에 2가지 장점이 있습니다. 두 가지 장점만 해도 큰 이점으로 작용하였습니다.
첫 번째) 원본 테이블의 파티션이 있을 경우 최대한 쪼개서 병렬로 작업이 가능
두 번째) ETL 및 데이터의 변경이 없는 경우 사용자가 SELECT 하는 동안 (업무시간)에도 작업 가능
두 개의 장점으로 인하여 주말이나 저녁, 새벽에 작업하는 방식이 업무 시간에 가능해졌고 더 이상 여러 가지 오류가 발생하지 않았습니다.
Ⅳ. 마치며
Databricks를 처음으로 사용해 보니 여러 가지 우여곡절이 많았습니다. 안 되는 부분도 있고 잘되는 부분도 있다 보니 당황하는 순간이 많았습니다. 그리고... 이번 일을 하면서 테스트 아닌 테스트가 되다 보니 비용 폭탄을 맞기도 하였습니다. 물론 이것을 함으로써 발생하는 비용절감과 성능 향상의 효과가 더욱 크겠지만 비용 폭탄은 저에게 큰 교훈을 주었습니다.
아무리 강조해도 모자라겠지만 늘 데이터는 이미 만들어놓고 다시 바꾸는 게 굉장히 힘든 작업입니다. 기존의 데이터를 마이그레이션 하거나 어떻게든 해줘야 하는 것이 가장 큰 문제이죠. 그렇기 때문에 처음에 데이터 환경을 구축할 때 굉장히 큰 고민이 필요합니다. 하지만 구축을 해놓은 뒤에 변경을 하는 경우도 빈번하게 있습니다. 그렇기에 각자의 상황에 맞게 잘 수행하였으면 합니다.
감사합니다.