[Databricks] 비효율적인 작업 추적기 만들기

databricks

 

안녕하세요. 주형권입니다.

정말 오랜만에 글을 쓰는 거 같습니다. 요즘 내/외부적으로 바쁘게 살고 있어서 글을 쓸 시간이 없습니다... 그래서 한 달에 1개 업로드하기도 어렵습니다.🥺

 

들어가며 

Databricks를 이용해서 데이터환경을 구축하고 이를 기반으로 수많은 유저들에게 오픈하여 사용하다보면 어쩔 수 없이 비용이 많이 나오게 됩니다. Databricks도 결국 사용하는 만큼 비용을 지불하기 때문에 그만큼 오래 수행이 된다면 비용을 많이 지불하게 됩니다. (AWS EC2 비용은 별도다.😥)

 

어쩔 수 없이 기간을 오래 잡아서 데이터를 집계하거나 어쩔 수 없이 큰 데이터를 조회하는 경우는 어쩔 수 없지만 비전공자나 데이터를 잘 사용해 본 적이 없는 사용자의 경우 파티션이나 리퀴드 클러스터링 등 사용을 하지 않고 그냥 전체적으로 SELECT 하고 집계하는 경우도 많습니다. 이럴 경우 비용도 비용이지만 공용으로 사용하는 클러스터에 무리를 주거나 한 개의 대용량 작업이 점유하고 있어서 다른 작업이 모두 밀리거나 느려지는 경우가 생길 수 있습니다. 

 

그것을 방지하기 위해서 작업을 추적하여 이러한 비효율적인 작업을 추적하도록 하였습니다. 여기에서 나오는 범위는 SQL편집기를 이용한 작업이나 워크스페이스에서 Notebook을 사용한 작업을 추적합니다. 

---

1. SQL편집기 데이터 수집

Query를 추적하는 가장 간단한 방법은 system.query.history 테이블을 사용하는 방법 입니다. 이 테이블에는 수행을 완료한 Query의 전반적인 정보가 나옵니다. 하지만 저는 이 테이블을 사용하지 않고 API를 사용하였습니다. 이 테이블은 수행이 완료된 작업만 나오므로 실제로 점유하고 계속 돌고 있을 경우는 데이터가 나오지 않습니다. 그래서 API를 통해서 SQL 편집기에서 수행하는 Query를 수집하였습니다.

 

Databricks에서 제공하는 API중에 쿼리 기록(Query History)을 가져오는 API가 있습니다. 이를 가져오는 API를 주기적으로 실행해서 데이터를 수집하였습니다. 

 

https://{domain}/api/2.0/sql/history/queries

 

API는 sql/history/queries이며, 다음의 링크에서 자세한 내용을 확인 할 수 있습니다.

Databricks REST API reference

 

API는 엄청나게 자세하게 정보를 JSON 형식으로 제공하는데, 여기서 필요한 정보만 python으로 가져와서 RDB에 저장하도록 하였습니다. RDB에 따로 저장하는 이유는 주후에 Query 관련해서 사용량이나 사용자를 조사하기 위해서 RDB에 저장하고 지표화 하기 위하여 RDB에 저장하였습니다. 

 

이 API의 경우 RUNNING 상태의 현재 실행중인 Query도 모두 나오기 때문에 오랫동안 점유하고 있는 작업도 추적이 가능합니다. 그래서 Databricks에서 제공하는 테이블을 사용하지 않고 API를 사용해서 작업을 추적하였습니다. 

---

2. 워크스페이스 (Notebook) 데이터 수집

워크스페이스의 경우 SQL편집기와 같이 기록을 저장하는 곳이 없는것으로 보였습니다. API를 찾아보려고 하였으나 역시 찾지 못하였습니다. (혹시 있다면 말씀해 주세요.)

 

그래서 선택한 방법이 system.access.audit 테이블을 사용하는 방법입니다. 

Audit log reference | Databricks Documentation

 

이 테이블은 원래의 목적은 감사로그이지만 이곳에도 Notebook의 실행에 관련한 내용이 나옵니다. 다음과 같이 Query를 작성하여 테이블을 SELECT 하면 Notebook에서 실행한 내역이 나옵니다.

SELECT *
FROM system.access.audit 
WHERE action_name = 'runCommand'
AND service_name = 'notebook'

 

이 테이블에서도 마찬가지로 엄청나게 자세한 정보가 나오는데요. request_params에는 notebookid 및 어떠한 클러스터 컴퓨팅을 사용하였는지 현재 상태값과 실행 시간 및 어떠한 작업을 수행하였는지까지 모두 나옵니다. 이를 기반으로 바로가기 링크를 만들어서 Notebook으로 바로가기 버튼을 만들 수도 있습니다.

 

이 Query의 경우 Databricks에서 제공하는 API를 사용하여 python으로 지속적으로 데이터를 가져오도록 만들고 Airflow를 통해서 지속적으로 수행하도록 하였습니다. API의 경우 다음의 API를 사용하였습니다.

https://{domain}/api/2.0/sql/statements

 

 

Statement Execution API: Run SQL on warehouses | Databricks Documentation

 

 

해당 API를 통해서 지속적으로 Notebook에서 수행한 작업에 대해서 수집하여 이 역시 RDB에 저장하였습니다. 

---

3. 메시지 알람 만들기 

현재 저희의 경우 메신저를 Teams를 사용하고 있기에 Teams를 통해서 메시지를 받도록 만들었습니다. 제가 아까 RDB에 계속해서 저장한다고 하였는데요. RDB에서 Query를 통해서 우리가 정한 기준에 따라서 데이터를 가져와서 이를 Teams 메시지로 보냈습니다. 

 

Teams Webhook을 통해서 다음과 같이 채널에 메시지를 보낼 수 있습니다.

Teams 알람 예시

 

Email로 당사자에게 발송도 가능합니다. 하지만 실제로 비효율적으로 사용하였는지 아니면 데이터가 너무 많아서 그런 것인지 알 수 없기에 팀에서 한번 보고 판단하도록 일부러 Teams 메시지로 우선 받도록 개발하였습니다. 

---

4. 대시보드 만들기

아까 제가 모든 작업 내역을 RDB에 저장한다고 하였습니다. 이 데이터를 저장하여 집계를 통해서 다음과 같이 실제 대시보드를 만들어서 작업의 여러 가지 사용량과 횟수등 많은 것을 한눈에 볼 수 있습니다.

 

이렇게 하면 누가 얼마나 어떻게 사용하였는지 볼 수 있고, 관련 부서와 협의 및 컴퓨팅을 따로 만들어주거나 여러 가지로 볼 수 있는 것이 많습니다. 그렇기 때문에 RDB에 저장해서 보는것은 굉장히 편리하고 이점이 많습니다. 저 같은 경우 대시보드는 superset을 이용하여 만들었는데, 오픈소스이기에 큰 부담 없이 만들 수 있습니다. 

 

이밖에 Query 내역을 볼수 있는 History 대시보드를 만들어서 누가 언제 어떻게 작업을 하였는지 등도 볼 수 있습니다. 그렇기 때문에 RDB에 모든 데이터를 저장하는 것은 생각보다 굉장히 이점이 많습니다. 

---

마치며

Databricks를 운영한 지 2025년 07월 기준으로 어느덧 1년이 되었습니다. 구축과 운영을 동시에 하다 보니 많은 삽질(?)을 하였고, 비효율적으로 작업도 많이 하였습니다. Spark를 알지 못하여 Databricks를 접하기에 엄청나게 많은 어려움이 있었고 Databricks 또한 처음이기에 우여곡절이 많았습니다.

 

하지만 1년 정도 운영을 해봤더니 많은 이점이 있었고 위와 같은 비효율 작업을 추적하는 모니터링 이외에 다른 여러 가지 모니터링을 만들기도 하였습니다. 앞으로도 더 많은 필요한 모니터링을 더 많이 공유하겠습니다.

 

감사합니다.