데이터엔지니어 주형권

Monitoring에서 Observability로: Databricks 워크플로우 알림 체계화 (Teams 연동)

주형권 — Sun, 12 Apr 2026 21:35:44 +0900

MoEye 프로젝트

이 글은 AI를 기반으로 작성하였으며 실제 제가 만든 Monitoring의 내용을 Gemini와 함께 작성하였습니다.

안녕하세요. 데이터 엔지니어로 일하며, 최근 DRE(Data Reliability Engineer)로의 도전을 시작한 주형권입니다. 그 첫 번째 발걸음으로, 제가 소속된 본부 전체가 함께 사용할 수 있는 'Databricks Job 자동 감지 및 알림 시스템'을 구축한 이야기를 공유해보려 합니다.

왜 이 시스템을 만들었나?

사실 기존에도 팀 내부적으로 쓰던 모니터링 방식은 있었습니다. 하지만 체계화보다는 '일단 돌아가게' 만드는 데 급급했죠. 이번에는 차원이 다릅니다. 본부 전체 인원이 스케일에 상관없이 안정적으로 사용할 수 있는 시스템을 목표로 했습니다. 제가 생각하는 데이터 신뢰성(Reliability)의 로드맵은 다음과 같습니다.

Monitoring -> Observability -> Reliability

결국 신뢰성 있는 데이터 파이프라인을 구축하려면, 가장 기초 단계인 **Monitoring(모니터링)**이 체계화되어야 하고, 이를 넘어 **Observability(관측 가능성)**가 확보되어야 합니다.

그래서 이번 프로젝트에서는 Databricks에서 발생하는 모든 워크플로우의 성공/실패/지연 상황을 체계적으로 감지하고, 조건에 따라 적절한 담당자에게 즉시 알림을 보내는 시스템을 한 땀 한 땀 만들어 보았습니다.

4가지 핵심 구축 조건

시스템 개발에 앞서 본부 전체 사용자를 고려한 4가지 필수 조건을 정립했습니다.

불특정 다수 커버: 본부 누구나 Workflow를 만들어도 Teams 채널을 통해 알림을 받을 수 있어야 함.
비공개 Teams 채널 대응: 회사 Teams 채널은 비공개이므로, 알림을 받으려면 반드시 '초대' 프로세스가 선행되어야 함.
바이브코딩(비개발자) 배려: Databricks에 익숙하지 않은 사용자가 워크플로우를 만들어도 무조건 알림 대상에 포함되어야 함.
직관적인 알림: 누구나 메시지만 보고도 상황을 즉시 파악할 수 있어야 함.

이 조건들을 충족하기 위해 정책과 개발 방향을 꼼꼼히 설계했습니다.

⚙️ 개발 및 정책 핵심

복잡하지는 않지만, 안정성을 위해 여러 가지 고민을 담았습니다.

1. 알림 발송 개발 방식 (백엔드)

API 기반 주기적 탐지: Databricks의 Workflow 리스트 API와 Task API를 주기적으로 호출하여 상태 변경(특히 실패)을 지속적으로 감지합니다.
상태 저장 및 중복 방지 (RDS): 추후 Observability 확장을 고려하여 데이터를 RDS(MySQL)에 저장합니다. ON DUPLICATE KEY UPDATE 구문을 활용해 리스트와 Task 테이블을 효율적으로 업데이트합니다.
알림 히스토리 관리: job_result_state 칼럼으로 실제 발송된 메시지 종류를 표시하고, updated_at으로 최종 발송 시점을 체크하여 중복 알림을 방지합니다.

2. 운영 정책 및 자동화 (Tagging)

Teams 채널 자동 초대 (SMTP): Databricks 권한이 있는 사용자가 Workflow를 생성하는 순간을 API로 캐치합니다. 해당 사용자에게 자동으로 이메일(SMTP)을 발송하여 Teams 채널 가입을 유도합니다.
Tag 정책 기반 자동 할당: Databricks는 태그에 콤마(,)를 지원하지 않아 슬래시(/)를 구분자로 사용했습니다.
- alert_type: S(공), F(실패), L(지연) 플래그 조합. (예: S/F/L)
- alert_user: 알림을 받을 사용자 ID(여러 명 가능).
자동 Tagging: 시스템이 주기적(10분마다)으로 탐지하여 Tag가 없는 워크플로우에는 정책에 따라 자동으로 Tag를 달아줍니다.

✨ Gemini와의 티키타카, 그리고 깨달음

이번 개발 과정에서 특별했던 점은 인공지능(Gemini)을 적극적으로 활용했다는 것입니다. 단순히 코드를 짜달라고 하는 것을 넘어, "내가 설계한 이론에 논리적 모순이 없는지", "코드의 리팩토링 방향은 맞는지", "비효율적인 쿼리나 프로세스는 없는지"를 Gemini와 계속 주고받으며 검증했습니다. 그 결과, 혼자 고민했을 때보다 개발 생산성이 비약적으로 향상되었고, 더 견고한 시스템을 만들 수 있었습니다.

SUCCESS 알림

FAILED 알림

마치며

단순한 알림 발송처럼 보일 수 있지만, '본부 전체'라는 스케일과 '비개발자'라는 사용자 경험을 고려하니 많은 고민이 필요했던 프로젝트였습니다. 이 시스템이 본부 데이터 파이프라인의 신뢰성을 높이는 든든한 주춧돌이 되기를 기대합니다. 그리고 아직 데이터 환경을 갖추지 못한 여러 회사에게 도움이 되기를 기원합니다.

What is Data Reliability Engineer(DRE)?

주형권 — Mon, 8 Dec 2025 17:26:26 +0900

해당 내용은 제가 생각한 부분과 외국 블로그, 사이트에서 있는 내용을 정리 한 개념이므로 정답은 아닙니다.

들어가며

최근에 링크드인을 통해서 Data Reliability Engineer(이하 : DRE)에 대해서 관심을 갖고 이쪽으로 로드맵을 만들어 가겠다고 다짐하였습니다. 이후에 DRE에 대해서 정확히 알고자 검색을 통해서 여러 정보를 얻었습니다. 우선 이 개념은 국내에 T사 한 곳에만 있는 것 같습니다. 실제로 운영을 하고 있으며 잘 운영 중인 것 같습니다. 실제로 검색해도 T사 이외에 어떠한 한글 문서가 나오지 않고 외국 블로그나 업체에서 제공하는 정보만 있습니다.

우선 DRE라는 개념 자체가 전세계적으로 생긴 지 얼마 안 되는 직군인 것 같습니다. 그리고 국내에는 굉장히 생소한 개념으로 보입니다. 생각해 보면 Data Engineer(이하 : DE)라는 직군도 엄청 오래된 직군은 아닙니다. 제가 초창기에 DE 직군이 생겼을 때 시작해서 벌써 7년을 하고 있으니 제가 보기엔 10년이 안된 거 같습니다. 처음에 DE를 한다고 잘 다니는 대기업을 박차고 나갔을 때 다들 X 쳤다고 했습니다. 근데 저는 이 직군이 굉장히 뜰 거라고 생각했습니다. 왜냐면 데이터의 종류가 많아지고 다양해지면서 기존의 방식은 점차 살 곳을 잃을 거 같았습니다.

그 말은 사실이 되었고 전통적인 DataWarehouse Engineer(이하 : DW)들의 이직은 더욱 어려워졌습니다. (지금은 아닌거 같지만...) 그때 당시에는 이런저런 형태의 데이터를 가리지 않고 커스텀해서 하나의 데이터 플랫폼 또는 데이터 레이크에 적재하고 이를 분석할 수 있는 사람을 선호하였습니다. 그러면서 자연스럽게 전통적인 DW만 하는 사람들은 갈수록 구직이 어려워졌습니다.

그리고 오늘날 이제는 DE 조차도 이직이 어려워지고 있습니다. 본인의 특별한 색이 있는 DE들이나 출중한 실력을 가진 DE들만이 이직을 하고 있으며 그 조차도 이직의 허들은 굉장히 높아졌습니다. DE가 그만큼 직업적으로 성숙해졌고 이로 인해서 더욱 세부적인 기술을 요구하는 기업이 많아지고 있습니다. 또한 하나의 회사에서 데이터 플랫폼/레이크를 여러 개를 사용하는 경우도 많다 보니 DE조차도 개발에 중점이 아닌 운영에 중점을 두기 시작하는 곳이 많아지고 있습니다.

Data Reliability Engineering은 무엇인가?

정의

우리가 이미 많이 알고 있는 SRE(Site Reliability Engineering)에서 Site 대신 Data를 접목시킨 역할입니다. SRE이가 인프라의 신뢰성을 보장하는 역할을 하였다면 DRE는 데이터의 신뢰성을 보장하는데 중점을 둡니다. 기업에서는 데이터의 중요성이 지소적으로 커지고 데이터 파이프라인의 복잡성이 증가하면서 관리의 어려움을 겪고 있습니다. 그렇기에 DRE는 데이터가 정확하고 신뢰 할 수 있는 고품질의 데이터로써 제공되게 하고 데이터가 필요한 사람들에게 제공되며 이에 관련하여 보안에도 신경 쓰는 엔지니어링입니다.

(출처 : Data Reliability Engineering: A Guide to Ensuring Data Quality in the Modern Data Stack)

내 생각

외국 블로그/사이트에서 설명하는 내용을 보면 약간은 다르지만 모두 같은 말을 하고 있습니다. DER는 데이터의 신뢰성을 위한 엔지니어링 입니다. 데이터의 신뢰성을 보장하기 위해선 단순하게 생각하면 데이터의 품질이 있을 것입니다. 우리가 사용하는 데이터가 실제로 정상적으로 적재되었는지 정상적으로 전처리가 이루어졌는지 등의 데이터 품질이 있으며 데이터 파이프라인이 정상적으로 작동했는지도 보증해야 합니다. 왜냐하면 다음과 같은 A, B, C의 소스 데이터를 이용해서 Mart를 만들 때 실제로 A, B, C의 데이터 파이프라인이 모두 정상 작동 했는지 보증이 되어야지 Mart의 데이터가 정확한지 신뢰할 수 있기 때문입니다.

예를 들어서 login , purchase , user_info 테이블 3개를 종합하여 user mart 테이블을 만든다고 가정할 경우 3개의 소스 테이블에서 한 개의 테이블이라도 파이프라인이 동작을 안 하면 정상적인 데이터가 나올 수 없습니다. 또는 3개의 테이블 중에 한 개라도 정합성이나 데이터에 이상이 있으면 잘못된 값이 나올 수 있습니다.

이러한 단순한 파이프라인 구조에서도 데이터 파이프라인이 하나 잘못되면 문제가 생기는데, 엄청나게 복잡하고 규모가 큰 데이터 플랫폼에서는 작은 부분이 하나 틀어지면 얼마나 많은 부분의 데이터가 잘못될까요? 또한 여기에 소스 테이블을 추가하여 마트 테이블에 더욱 많은 정보를 넣기 위해서 영향도가 어떨지 등등 많은 부분을 신경 써야 할 것입니다. 그렇기에 DRE의 범위는 데이터에 관련된 대부분의 영역에서 신뢰성 있는 데이터를 제공하기 위해서 일하는 것을 의미한다고 생각합니다.

데이터에 관련된 대부분의 영역에서 데이터의 신뢰성을 위한 엔지니어링

Data Reliability Engineer은 무엇을 하는가?

소방관

정의

DRE의 역할에 대해서는 너무 다양하고 너무 설명하는 게 달라서 뭐라고 정의하기가 어려웠습니다. 하지만 결론적으로는 데이터 신뢰성을 높이기 위해서 데이터 관련된 대부분의 영역에서 활동하는 것으로 보입니다. 또한 어느 블로그에서는 DRE를 데이터 관한 소방수라고 표현하기도 하였습니다. 아래는 몇 가지 공통적으로 등장하는 역할에 대해서 몇 개 써봤습니다.

1) 모니터링 시스템 구축 데이터 신뢰성을 보증하기 위해서 데이터 파이프라인 데이터 정합성등에 대해서 모니터링 시스템을 만들어서 관리합니다.

2) 데이터 품질 관리 데이터를 사용하는 사람들에게 데이터 품질에 대해서 자동으로 검증하고 이를 기반으로 한 데이터 신뢰성 지표 제공 합니다.

3) 데이터 운영 데이터 운영이라고 하면 범위가 굉장히 큽니다. 데이터에 수명주기 데이터의 메타정보 등 여러 가지 데이터 관련 된 운영을 모두 맡는다고 할 수 있습니다. 이밖에 데이터 사용이 쉽게 하도록 교육을 하기도 합니다.

4) 데이터 사용자와 협업 데이터를 사용하는 데이터 엔지니어 / 데이터 과학자 / 데이터 분석가등과 협업하여 모두가 신뢰할 수 있는 데이터를 만듭니다.

출처 : How to become a Data Reliability Engineer

Data Reliability Engineer: 9 Skills to Help You Become One!

What is a Data Reliability Engineer – And Do You Need One?

내 생각

이 부분에서는 제 생각이 많이 반영되었습니다. 사실 어디 회사를 입사하냐에 따라서 같은 직무라도 조금씩 다른 역할을 맡습니다. 같은 DE를 하더라도 조금씩 본인의 색채가 다르듯이 DRE도 비슷한 것 같습니다. 저는 DE를 하면서 운영을 시키지 않았지만 스스로 하였습니다. DBA를 하던 시절에 버릇이 남아서 그런지 운영에 굉장히 민감하고 보수적으로 접근하다 보니 내가 편하자고 만들어서 쓰는 모니터링 시스템이 기본이 되었습니다.

제 생각에는 DRE는 DE에서 Administrator의 역할을 수행하는 직군이라고 생각됩니다. Management보다는 Administrator의 역할을 수행함으로써 운영에 제어를 더해서 관리를 하는 역할이라고 생각됩니다. 제가 회사를 처음 입사하면 항상 하는 게 모니터링 시스템 구축입니다. ( 데이터 엔지니어인 내가 새롭게 입사하는 회사에서 하는 것)

모니터링을 해야지 어느 부분에서 누수가 발생하는지 쉽게 알 수 있고 어느 부분에서 비용이 낭비되는지 알 수 있으며 빠르게 장애를 해결할 수 있습니다. 누군가에게는 별거 아닐 수 있지만 이러한 시스템 자체를 만드는 사람을 저는 회사를 다니면서 본 적이 없습니다. 물론 Datadog / Datahub와 같은 좋은 도구들이 있지만 저 같은 경우 제 입맛에 맞는 대시보드와 제 입맛에 맞는 또는 팀의 입맛에 맞는 대시보드와 알람을 만들기 위해서 그리고 내가 또는 다른 팀원이 원하는 모니터링을 만들기 위해서 직접 만드는 것을 선택하였습니다.

이러한 모니터링을 만들기 위해서는 네이밍룰이나 여러 가지 Tag에 관련해서 정책이 필요하며 카탈로그를 지표를 만들기 위해서는 카탈로그에 대한 정책도 필요합니다. 왜냐하면 나중에 알람을 만들거나 지표에 무언가를 표시할 때 Tag나 네이밍이 이상하면 한눈에 알아보기 어렵기 때문에 당연하게도 정책 수립은 필수적으로 따라옵니다.

이러한 일련의 모든 과정을 수행해야 하는 직무라고 생각이 들며 데이터에 관련된 Administrator이라고 하는 게 제가 생각하기에 가장 맞는 거 같습니다. 그래서 직무를 특정적으로 제한하기보다는 데이터 관련된 대부분의 역할을 수행하되 그 역할이 데이터의 신뢰성에 초점을 맞춰서 해야 하는 역할로 보입니다.

데이터 관련 된 대부분의 역할을 수행하되 그 역할이 데이터 신뢰성에 포커싱 된 역할

내가 생각하는 Data Reliability Engineer

사실 이 내용을 쓰기 위해서 앞부분의 내용을 여러 가지 해외 자료를 통해서 공부했습니다. Data Reliability Engineer가 무엇인지 무엇을 하는지 알아야지 어떻게 할지 고민할 수 있다고 생각이 들어서였습니다. 사실 DRE에 대해서 찾아보면 찾아볼수록 아직은 완성되지 직군인 것 같습니다. Job Description을 봐도 각기 모두 다르고 직무에 대한 이야기를 하는 것도 모두 다르기에 무언가를 한다고 딱 정해져 있기보다는 말 그대로 데이터 신뢰성을 위해서 일하는 직군으로 보였습니다.

그래서 제가 생각하기에 지금 당장 할 수 있는 DRE의 방향은 무엇일까 고민하다가 제가 기존에 해왔던 일을 접목시킨다면 이렇게 할 것 같다는 생각이 있어서 그것을 공유하려고 합니다.

제가 생각하기에 DRE의 역할 중에 3개의 영역으로 나누고 수행하면 좋을 거 같습니다. 물론 제가 이 분야의 전문가들과는 다르게 세부적으로 더 자세하게는 이야기하기 어렵겠지만 3개의 직무 자체를 통합하여 관리하고 적용하다 보니 조금씩 해야 하지 않을까 싶습니다.

1) Data Monitoring

Data에 관련된 모니터링 시스템을 구축하는 것은 어쩌면 DRE의 가장 기본이자 핵심적인 업무가 될 것이라고 생각합니다. 앞서 이야기하였듯이 데이터 파이프라인의 동작이 끊기는 경우 마트 데이터 또는 팩트 데이터의 잘못된 값이 입력될 수 있기에 이를 즉시 알리는 모니터링 시스템을 만드는 부분에 대해서 생각할 수 있을 거 같습니다.

데이터 파이프라인의 경우 각종 시스템에서 각기 다른 소스로부터 오기 때문에 파이프라인의 모니터링을 한눈에 볼 수 있도록 만드는 것이 핵심 일 것 같습니다. 또한 누구나 알기 쉽고 빠르게 대처가 가능하도록 하는 것이 중요할 거 같습니다.

데이터 파이프라인 알람

추가적으로 파이프라인의 성공 실패뿐 아니라 이를 실행시키는 플랫폼의 리소스나 사용량에 대해서도 모니터링이 필요할 것 같습니다. 예를 들면 S3의 사용량이나 Spark의 모니터링등을 하나의 지표에서 함께 볼 수 있다면 굉장히 도움이 될 것 같습니다.

작업별 비용 지표

여기에 더불어 각종 리소스에 관련된 비용을 볼수 있도록 한다면 비용적으로도 도움이 많이 될 것으로 보입니다. 이는 과도하게 사용되는 리소스를 찾아서 비용을 최적화할 수 있으며 성능과도 연관되게 볼 수 있습니다. 다양한 데이터 플랫폼이 과금 구조가 사용한 만큼 비용을 지불하기에 비용이 많이 소모되는 작업을 찾아서 성능을 튜닝하여 비용을 낮추고 성능을 좋게 만드는 효과도 불러올 수 있다고 생각됩니다.

2) Data Quality

데이터의 품질 또한 DRE의 주요 업무라고 생각됩니다. 소스로부터 타깃까지 데이터가 정상적으로 적재되었는지 가장 기본이 되는 ODS부터 시작해서 마트와 팩트 테이블에 이르기까지의 여러 가지 정합성 모니터링을 통해서 데이터의 품질을 올릴 수 있을 것 같습니다.

아주 간단하게는 건수 체크를 통해서 소스로부터 타깃으로 데이터가 그대로 적재되었는지를 볼 수 있을 것이며, 필요에 따라서 Primary Key를 통해서 중복 체크를 해서 데이터의 중복이 있는지 볼 수도 있습니다. Primary Key가 없는 로그성 데이터 또는 RDBMS로부터 오는 데이터가 아닌 경우 일자별로 로그의 건수의 추이를 보고 가중치를 부과해서 가중치 이상 또는 이하로 데이터가 들어오거나 또는 너무 많이 들어올 경우 알람을 보낼 수도 있습니다.

또한 NULL의 비율이나 NULL 값이 있는지 체크를 통해서 NULL로 들어오면 안 되거나 너무 많이 들어오면 이상이 있는 경우를 모니터링할 수도 있습니다. 실제로 ETL 하는 과정에서 변환하는 과정에서 데이터의 타입 변경이 자동으로 이루어지거나 인식하지 못하는 경우에 NULL로 잘못 들어오는 경우가 실제로 많이 발생합니다. 또는 실수로 인한 잘못된 패치로 인해서 아예 NULL로 들어오는 경우도 실제로 많이 있습니다.

3) Data Governance

제가 자세히 알지 못하는 영역이지만 작게나마 수행하고 있던 영역입니다. 실제로 Data Governance 영역의 경우 견고하게 설계된 회사가 많지 않고 실제로 이 부분은 엄청나게 많은 지식을 요구하기에 몇몇 필요한 부분만 적용했었습니다. (저는 그랬습니다.)

수많은 Data Governance 영역에서 저의 경우 데이터 수명주기에 대한 정책을 세우고 관리하였습니다. 왜냐하면 이 부분은 데이터의 저장소 비용과 처리 비용과 직접적으로 연관되기에 신경을 많이 쓸 수밖에 없는 부분입니다. 가장 많이 신경 썼던 부분은 S3 저장소로써 중간 저장소 역할을 하기도 하고 최종 저장소 역할을 하기도 합니다. 예를 들어 RDBMS에서 데이터를 S3에 저장하고 이를 여러 곳에서 사용한다고 하면 S3의 비용이 아무리 싸더라도 중간 산출물인 경우 또는 집계를 위해서 데이터를 S3에 저장하고 있다면 S3 수명주기를 통해서 데이터를 관리할 필요가 있습니다.

실제로 AWS S3에서는 이와 같은 기능을 제공하고 있지만 각 S3 Bucket마다 일일이 들어가서 봐야 하는 번거로움이 있습니다. 그래서 DRE의 경우 이러한 정보를 한눈에 볼 수 있는 지표나 알림을 보여주는 역할을 해야 한다고 생각합니다.

또한 보안과 관련된 일에도 여러 가지 모니터링을 통해서 알림을 받거나 관리 하는 지표를 만들수 있습니다.

이를 통해서 주기적으로 Access Key 또는 여러가지 Key 파일을 관리하고 주기적인 교체를 할 수도 있습니다. 또는 담당자에게 만료 기간이 도래 하였음을 알림으로써 각 담당자가 직접 변경을 할수 있도록 도울 수도 있습니다.

이밖에도 데이터 카탈로그 정보를 관리함으로써 데이터 스키마 변경 내역을 기록하고 이를 문서화할 수 있으며 언제든지 변경 부분에 대해서 누구나 쉽게 보도록 만들 수 있으며 현재 최신 상태의 카탈로그도 제공해야 한다고 생각합니다. 여기에 더불어 데이터에 관련된 여러 가지 Meta 정보를 수집하여 제공도 가능합니다. 예를 들면 현재 테이블의 건수와 테이블의 마지막 업데이트 시간등을 표기하여 데이터를 사용하는 사람으로 하여금 해당 데이터의 신뢰성을 더욱 높일 수 있습니다.

마치며

사실 DRE는 저에게 엄청나게 도전적이고 모험적인 직무인 거 같습니다. 아직 국내에서는 굉장히 생소한 개념이며, 해외에서도 찾아보면 각기 다르게 이야기하고 있습니다. 무엇이 맞다 틀 리다를 이야기하기보다는 어느 방향성으로 데이터의 신뢰성을 올리느냐가 중요해 보입니다. 데이터의 신뢰성을 올린다고 하는 의미가 저에겐 너무 추상적으로 다가오긴 합니다. 어떻게 하면 신뢰성을 올릴 수 있는지는 사람마다 또는 기업마다 모두 다르다고 생각하기 때문입니다.

결론적으로 DRE를 말하자면... 솔직히 말해서 데이터 운영에 관련된 모든 일 하는 사람으로 보입니다. 이게 진짜 범위 자체의 경계가 없고 모든 데이터 관련 운영 업무에 투입이 될 수 있으며 데이터베이스, 데이터웨어하우스, 데이터레이크 등 데이터가 들어가면 모두 왠지 운영적으로 봐야 할거 같습니다.

그래서 당장에는 우선 데이터 운영의 부담을 덜어주면서 데이터 품질을 올리는 부분에 집중하는 게 맞다고 생각됩니다. 이 부분도 굉장히 추상적이지만 생각해 보면 제가 데이터엔지니어를 하면서 팀에서 필요하다고 생각하거나 내가 보고 싶어서 만드는 여러 가지 업무들이 데이터 운영의 부담을 덜어주고 데이터 분석가나 데이터 과학자 나아가 데이터를 사용하는 데이터와 관련이 없는 직군이지만 데이터를 사용하는 모든 사용자들에게 데이터 신뢰도를 올렸습니다.

예를 들면 데이터 파이프라인의 종료되는 시간을 계산해서 테이블의 최신 업데이트 주기를 보는 지표를 만들어서 사용자들이 언제쯤 데이터를 보면 될지 알 수 있도록 하였으며, 데이터가 중복되지 않도록 추세 또는 PK를 통해서 이 데이터가 실제로 잘 쌓이고 있다는 지표등을 제공하여 데이터를 사용하는 사람들이 안심하고 쓰도록 하였습니다.

아마도 제가 DRE 직무를 맡게 된다면 시키는 일 + 내가 했던 일 2개를 병행 할거 같습니다. 위에서 제가 해왔던 일이면서 필요해 보이는 일을 정리하였지만 이밖에도 DRE의 잠재성(?)은 무궁무진하다고 생각됩니다. 하여 회사에서 추구하는 DRE로써의 역할은 언제나 열어놔야 한다고 생각합니다.

[Databricks] API를 이용한 Token정보 가져오기 (Python)

주형권 — Tue, 18 Nov 2025 10:29:49 +0900

안녕하세요. 오랜만에 Databricks 관련 글을 올립니다. 오랜만에 쓰는 글인데 심화적인 글은 아니고 간단한 API를 이용한 내용입니다. Databricks에서는 AWS나 GCP 같은 플랫폼에서와 같이 Key 형태의 Token을 제공합니다. Token을 이용해서 여러 가지 Databricks의 모니터링을 할 때 Token을 이용해서 코드에 삽입하여 사용합니다.

제가 만든 수많은 모니터링 시스템에서 필요한 것이 Databricks의 Token입니다. 모니터링을 하려면 AWS에서는 Access key 가 필요하고 GCP에서는 key file이 필요하듯이 여기서도 Token이라는 것이 존재 합니다.

Authenticate with Databricks personal access tokens (legacy) | Databricks on AWS

Learn how to set up Databricks authentication by using Databricks personal access tokens (PATs).

docs.databricks.com

하지만 이 Token에도 관리가 필요합니다. 특히 최근에 많은 이슈가 되고 있는 보안을 위해서 Token을 주기적으로 교체하거나 수명주기를 관리하여 Token을 관리해야 합니다.

Token 확인 방법

Databricks Token의 경우 위의 스크린숏과 같이 우측 상단의 워크스페이스명을 누르면 나오는 곳의 가장 아래에 "계정 관리"부분을 클릭하면 나오는 페이지로 접속 후 아래와 같이 확인 가능 합니다.

여기서 Token을 생성하는 방법이나 각각의 워크스페이스별로 보는 방법은 다루지 않겠습니다. (글 목적과 맞지 않으므로)

Token 정보 가져오기

Databricks의 Token 정보의 경우 다음의 API를 통해서 가져올 수 있습니다.

List all tokens | Token management API | REST API reference | Databricks on AWS

Databricks REST API reference

docs.databricks.com

Token의 정보를 가져올 수 있으며 결과값 예시는 다음과 같습니다.

{
  "token_infos": [
    {
      "comment": "This is for the ABC department automation scripts.",
      "created_by_id": 202480738464078,
      "created_by_username": "jsmith@example.com",
      "creation_time": 1580265020299,
      "expiry_time": 1580265020299,
      "last_used_day": 1710374400000,
      "owner_id": 202480738464078,
      "token_id": "5684c955822ac792a51ae2aeb80190f13457bab3e2e2934c133a08b38454816c",
      "workspace_id": 5750939285643220
    }
  ]
}

다음의 코드로 Token의 정보를 가져올수 있습니다. info_list에 보시면 list형태로 넣은 이유는 list에 여러 개의 워크스페이스를 넣어서 한 번에 정보를 전부 가져오기 위함입니다. (각 워크스페이스마다 Token을 생성하여 각 워크스페이스마다 API를 실행해야지 모든 Token정보를 획득 가능함)

import requests
from datetime import datetime,timedelta

info_list = [
             {'account':'Please enter your account.','domain':'Please enter your domain.','token':'Please enter your token.'}
             ]

for info_row in info_list:
    account = info_row.get('account')
    domain = info_row.get('domain')
    token = info_row.get('token')

    print(f'Collect the corresponding {account}')

    url = f"https://{domain}/api/2.0/token-management/tokens"
    headers = {"Authorization": f"Bearer {token}" }
    response = requests.get(url=url, headers=headers)
    result = response.json()
    token_list = result.get('token_infos')

    if token_list == []:
        pass

    else:
        for token in token_list:
            print(token)

위의 코드를 이용해서 Token 정보를 가져오고 저희 같은 경우 다음과 같이 Teams 메신저를 통해서 알림을 받고 있습니다. 이렇게 Token의 만료기간을 알려서 사용자가 갑자기 Token이 안 되는 상황을 막고 사전에 이를 방지하기 위함입니다.

[공통] 데이터엔지니어링팀의 계획 - 중기편 (3~N년)

주형권 — Thu, 13 Nov 2025 10:05:07 +0900

빌딩숲

[공통] 데이터엔지니어링팀의 계획 - 단기 편 (0~2년)

[공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)

어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고

burning-dba.tistory.com

지난 단기편에 이어서 중기 편을 이어가려고 합니다. 만약 여러분이 단기 과정을 어느 정도 끝냈다면 이제부터는 중반에 접어들었을 것이라고 봅니다. 기존의 데이터가 없는 환경에서 이제 플랫폼을 이용하여 무엇을 할 수 있는 단계에 이르렀다고 생각됩니다. 이것은 엄청난 도약입니다.

데이터 없이 경험과 감으로 일하던 환경에서 이제는 사실 기반으로 데이터와 수치를 기반으로 업무를 하는 환경을 조금씩 만들어 가고 있는 과정에 서 있다고 봅니다. 제 생각에는 아마도 중반기의 과정이 가장 고달프고 가장 많은 스트레스를 받는 단계가 아닐까 싶습니다.

들어가며

앞에서 이야기 했듯이 제 생각에는 이 시기가 가장 고달프고 스트레스받는 시기인 것 같습니다. 왜냐하면 1~2년 많게는 3~5년까지 데이터 플랫폼을 구축하였다면 이제는 이것을 쓰게 해야 하는 단계이며, 사용자의 편의성을 증대시켜야 하는 시기이기 때문입니다. 제가 여러 회사에서 데이터 플랫폼을 구축하고 데이터 환경을 만들면서 느끼는 점은 잘 만들어도 쓰지 않으면 인정을 받지 못한다는 것입니다.

많은 사람들이 저에게 "잘 만든 데이터 플랫폼은 무엇인가요?"라고 묻습니다. 예전에는 저는 최신 기술을 접목하여 만든 고도화된 데이터 플랫폼 아니면 엄청나게 잘 잡혀있는 데이터 거버넌스를 기반으로 만들어진 단단하고 견고한 데이터 플랫폼등 여러가지 기술이나 정책 기반의 데이터 플랫폼을 많이 이야기하였습니다. 하지만 데이터 엔지니어로써 많은 시간을 보내다 보니 제 생각에 가장 잘 만들어진 데이터 플랫폼은 사용자가 잘 쓰는 데이터 플랫폼인 것 같습니다.

사용자가 많은 데이터 플랫폼이 가장 잘 만든 데이터 플랫폼이라고 감히 말하고 싶다.

이렇게 하기 위해선 수많은 노력이 필요하며 엔지니어로써 "내가 왜 이걸 하지?"라는 생각이 드는 여러가지 일도 많이 해야 하기 때문인 것 같습니다. 이밖에도 여러 가지 고도화를 통해서 비용을 감축시키고 데이터 플랫폼이 구축되었기에 내가 예상하지 못하였던 다양한 종류와 방대한 양의 데이터를 데이터 플랫폼에 넣어줘야 하는 여러 가지 스트레스도 받습니다.

계획	계획 내용	비고
데이터 플랫폼 홍보/교육	데이터를 사용할 수 있는 환경을 만들었다면 이제는 데이터를 잘 쓰도록 해야함
다양한 데이터 적재	이미 있는 데이터 또는 기본적인 데이터를 적재 하였다면 이제는 다양한 데이터를 적재 해야함	예시) CRM / GA4 / 타 플랫폼 데이터등
사용자 편의성 증대	데이터 플랫폼을 계속해서 사용자가 사용하기 편한 환경으로 만들어줘야함 (요구사항 수집 및 반영)	예시) 데이터 카탈로그 강화 / Text To SQL등
데이터 관련 고도화	다양한 사용자와 데이터가 계속해서 유입됨으로 인하여 정책 또한 생성하고 고도화 되어야하며, 기존의 정책도 끊임없이 업데이트 되어야함

1. 데이터 플랫폼 홍보/교육

솔직히 말해서 많이 하기 싫은 일중에 하나입니다. 이 일을 왜 해야하는지 이해하는데 많은 시간이 걸린 거 같습니다. 왜냐면... 저는 엔지니어니까요. 엔지니어가 왜 어째서? 교육하고 홍보하고를 해야 하지?라는 생각을 정말 많이 했습니다. 그런데, 어느 회사를 가든 이건 엔지니어의 숙명 같습니다. 제가 다녔던 많은 회사에서 SQL 교육이나 데이터의 기초 교육을 진행했을 때 항상 반응이 좋았고, 언제나 환영받았습니다. 그만큼 피드백도 좋았습니다.

제가 앞서 말했듯이 데이터 플랫폼을 아무리 잘 구축해도 사용자가 나 뿐이라면 인정받지 못합니다. 다양한 사용자가 잘 쓸 수 있는 환경을 만들어놨다면 이제 다양한 사용자가 쓸 수 있도록 만들어야 합니다. 요즘에는 AI나 LLM을 통해서 Text To SQL을 쓰는 곳도 굉장히 많지만 기본적으로 이런 것을 쓰기 위해서는 데이터 플랫폼 환경에 접속하는 방법부터 시작해서 정말 수많은 것들을 기본적으로 알아야 합니다.

[공통] 데이터를 적재하고 보기까지

글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된

burning-dba.tistory.com

제가 예전에 써둔 데이터를 적재하고 보기까지라는 글에서 나오는 내용을 주로 교육 콘텐츠로 사용하였습니다. 사람들은 설명하지 않으면 데이터를 어떻게 볼 수 있고 데이터를 보기까지의 수많은 과정이 있다는 것을 알지 못합니다. 뭐... 당연한 이야기겠지만 우리의 사용자들은 각자의 본업이 있고 데이터를 그분들에게 어디까지나 보조 도구입니다. 그렇기 때문에 이 분야에 대해서 우리만큼 알지 못합니다. 이 부분을 받아들이고 우리의 사용자들에게 설명(교육)하는 시간이 필수적이라고 봅니다.

저 같은 경우 전단지 돌린다는 말을 자주 사용 하였는데, 실제로 전단지를 나눠주면서 홍보를 하는것과 똑같다고 봅니다. 이 일을 전담하는 부서가 있어야 하는 거 아니야?라고 할 수 있는데, 전담해줘도 어차피 우리의 사용자들의 궁금증을 시원하게 해소해주려면 본인이 나서야 합니다. 왜냐면 교육만 전담하는 부서가 전달하는 것과 실제 현업의 사람이 전달하는 건 차이가 꽤 큽니다.

2. 다양한 데이터 적재

아마 데이터 플랫폼을 구축 하겠다는 요구가 있다면 기본적으로 보고 싶은 데이터는 있다는 뜻이고 아마 그 기본적인 데이터는 적재가 되어서 데이터 플랫폼을 구축하고 사용자들에게 오픈하였다고 볼 수 있습니다. 이제 그럼 사용자가 유입되고 데이터 플랫폼이 생겼으니 다양한 데이터를 적재해달라고 요구가 올 것입니다.

즉, 담을 그릇이 생겼으니 다양한 음식을 준비 해달라는 것과 비슷하다고 봅니다. 제가 주로 받았던 요청은 CRM 데이터, GA4 데이터 그리고 서버로그등이었습니다. 그리고 추가적으로 개발팀에서 로그나 데이터를 추가적으로 만들기도 하며 또는 다른 플랫폼에서 나오는 결괏값 데이터를 적재해달라는 요구도 많이 있습니다.

다양한 데이터들

저는 주로 CRM 데이터를 마케팅 부서로부터 가장 먼저 요청 받았던 기억이 있습니다. 그 이후에 서버개발팀에서 요청이 오거나 또는 사업팀으로부터 요청이 오는 경우가 대부분이었습니다. CRM 데이터나 GA4 같은 데이터들은 사실 적재가 그렇게 어렵진 않습니다. 이미 export 기능이 잘 만들어져 있고 연동을 원한다고 하면 방법도 이미 다 있습니다. 여기서 조금 까다로운 게 다른 플랫폼이나 자체구축 플랫폼에서 데이터를 가져오는 일입니다.

자체 구축하거나 다른 플랫폼의 경우 데이터를 가져오기 위해서는 ODBC / JDBC등과 같은 커텍터로 직접 연결하거나 이것도 안 될 경우 직접 데이터를 내려받아서 가져오는 부분도 필요합니다. 우리 쪽 시스템이 아니라서 굉장히 까다로운 경우가 많습니다. 그리고 웹 크롤링 데이터나 공공기관 데이터도 주로 요청받는 데이터중 하나입니다.

3. 사용자 편의성 증대

앞서 1번에서 이미 홍보와 교육까지 했는데 또 뭘 해야 하지?라고 생각 할 수 있습니다. 이 부분은 약간 다른 내용입니다. 앞의 내용이 사용자가 진입하게 만들었다면 이제는 진입 후 잘 사용하도록 만드는 방법입니다. 약간 같으면서도 다른데요. 예를 들면 이런 것들입니다.

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

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

burning-dba.tistory.com

[Athena] Query 사용량 및 사용자 추적 대시보드 만들기

안녕하세요. 주형권입니다. 지난번에 개발한 GS리테일의 데이터레이크 모니터링 시스템 도베르만에 추가적인 기능을 만들어서 만드는 과정에 대해서 공유하려고 글을 작성하였습니다. 기존에

burning-dba.tistory.com

이게 무슨 연관이 있을까 싶겠지만 굉장히 연관이 많습니다. 제가 현재 사용하고 있는 Databricks 환경을 예로 들어보겠습니다. 비효율적으로 판단되는 쿼리의 기준으로 잡습니다. 저 같은 경우 30분 이상 동작하는 Query를 추적하도록 했습니다. 그럼 이걸 하는 이유가 단순히 튜닝을 위한 목적이라고 생각할 수 있지만 다르게 생각하면 사용자들이 그만큼 오래 기다려야 한다는 의미입니다.

이 말인즉 사용자들이 Query를 실행하고 결과를 받기까지 오래 걸린다는 의미입니다. 내가 사용자라면 매번 Query를 할 때마다 30~60분씩 걸린다고 생각하면 얼마나 고달플까요. 물론 수억 수천억 건의 데이터를 1~N년치 이런 식으로 조회하면 사용자도 느리다 생각하겠지만 하루 또는 이틀 치만 데이터를 질의하는데 오래 걸린다? 그럼 저 같아도 쓰기 힘들 거 같습니다. 그렇기 때문에 이와 같은 Query를 추적하여, 테이블에 파티션을 재조정하거나 파티션이 없으면 만들어 준다거나 조금 더 효율적으로 조금 더 빠르게 결과를 받을 수 있도록 할 수 있습니다.

또한 사용자들이 데이터를 쉽게 볼 수 있도록 카탈로그를 고도화할 수 있으며 데이터 관련 마트/팩트를 설계하여 제공도 가능합니다. 단순히 데이터를 적재하고 끝이 아닌 사용자가 잘 사용할 수 있도록 계속해서 만들어야 합니다. 카탈로그의 경우 사용자가 플랫폼에 접속해서 속성을 찾아서 보기보다는 하나의 페이지에서 검색이 가능하도록 웹 사이트를 만들어서 제공하면 굉장히 큰 호응을 얻을 수 있습니다. (실제로 그랬습니다.)

4. 데이터 정책 고도화

데이터 플랫폼을 구축하고 어느 정도 시간이 지남에 따라서 정책은 끊임없이 업데이트되어야 합니다. 예를 들어서 데이터 플랫폼에서 권한 체계만 해도 다양한 부서와 다양한 데이터를 보는 사람들이 다양하게 생기므로 정책을 다르게 수립해야 하는 경우가 많습니다.

또한 다른 플랫폼에서 데이터가 들어오거나 굉장히 민감한 데이터가 들어오는 경우 데이터를 어떻게 어디까지 보여줘야 할지에 대해서도 고민해야 합니다. 예를 들면 민감 정보의 경우 암호화의 방법부터 시작해서 암호화를 하더라도 볼 수 있는 부서 또는 사용자가 있고 어디까지 볼 수 있는지 모두 고민해야 합니다. 물론 거버넌스 또는 보안부서에서 어느 정도 도움을 주긴 하겠지만 어디까지나 이것을 만들어서 적용은 데이터 엔지니어들이 합니다. (데이터 플랫폼이 우리 거니깐...) 그렇기에 이러한 정책을 계속해서 업데이트해야 합니다.

추가적으로 데이터 수명주기나 데이터의 관리에 관한 여러 가지 정책도 이제 중기에 접어들면 관리가 필요합니다. 데이터의 양이 매우 작으면 큰 의미가 없지만 데이터의 사이즈가 큰 경우 한 달을 보관하는 것도 그만큼 많은 비용이 들어갑니다. 그렇기 때문에 데이터의 수명주기를 설정해서 데이터가 몇 년 또는 몇 달 치 보관을 할지 정해야 합니다. 데이터의 종류가 다양하고 각기 데이터의 성질과 크기가 다르므로 이 모든 것을 관여하여 정책을 잡아야 합니다.

[공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)

주형권 — Tue, 14 Oct 2025 09:29:15 +0900

어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고 비전에 파생되는 계획을 단/중/장기적으로 실천하는 일이 필요합니다. 비전과 계획이 별거 아닌 것 같지만 이것이 없으면 팀원들은 팀 비전에 대해서 의구심을 느낄 수 있으며 불안감이나 또는 보람을 느끼지 못할 수 있습니다.

그렇기 때문에 비전과 계획은 굉장히 중요한것 같습니다. 이번 글에서는 비전 이야기보다는 실질적인 계획에 대해서 이야기해보고자 합니다. 목표라고 할 수도 있겠네요. 사실 비전은 팀마다 정하기 나름이고 회사의 기조에 따라서 많이 달라질 것 같기에 비전에 대해서 다루지 않고 데이터엔지니어링 팀의 계획에 대해서만 다루고자 합니다.

제가 생각 하기에 비전은 조금 더 추상적인 느낌의 긍극적인 목표라면 계획은 구체적인 실행 방안이기 때문에 계획은 큰 틀에서는 비슷할 것 겉으로 보입니다. 제가 팀장을 역임했던 경험과 제로 베이스에서 시작하는 데이터 플랫폼 구축에 관련하여 계획을 세우는 부분에 대해서 실제 행했던 경험을 이야기하고자 합니다.

들어가며

계획은 단기 계획 ➡️ 중기 계획 ➡️ 장기 계획으로 조금씩 나아갑니다. 조금씩 단계를 거쳐가면서 필요한 일과 해왔던 일에 대해서 정리를 하고자 합니다. 현재 2025년 9월 기준으로 속해 있는 LG전자에서는 단기 계획을 넘어서 중/장기 계획을 수립하여 나아가는 단계에 놓여있고 중/장기 계획을 수립하는 과정에 있습니다.

이를 기반으로 현재의 실제 계획을 수행하고 있는 경험과 기존의 회사에서 경험 하였던 계획 수립과 계획 실행을 기반으로 글을 작성하려고 합니다. 생각보다 거창한 이야기는 아닐 수도 있고 엄청나게 혁신적인 이야기는 아닐 수 있지만 아마도 누구나 해야 하고 누구나 필요한 이야기 일 것입니다.

항상 이야기 하지만 저의 이야기가 전부 정답은 아니며, 각자의 상황과 여건에 맞게 받아들이면 좋겠습니다. 이글로 인해서 경험을 해보지 못하여 방황하거나 다른 회사의 사례를 듣고자 하는 분들에게 귀감이 되었으면 좋겠습니다.

단기 계획은 0~2년 정도의 계획이라고 생각 됩니다. 조금 빠르면 0~1년이라고 할 수 있습니다. 이 역시 회사의 여건과 현재 자신의 상황에 따라서 많은 부분이 다를 거라고 생각됩니다. 어느 회사의 경우 조금 여유가 있기에 3년이라고 생각할 수도 있을 것 같습니다.

처음 아무것도 없는 환경에서는 우선 데이터 플랫폼의 선정이 주요하다고 봅니다. 레이크 하우스의 구축을 하거나 데이터 웨어하우스 시스템을 구축하거나 하는 등의 여러가지 플랫폼 구축을 하고 이를 기반으로 모니터링 및 데이터 파이프라인 개발이 필요한 시기입니다. 추가적으로 로그 자체가 없는 경우도 있을 텐데 이 경우 로그를 만드는 작업부터 해야 하는 경우가 있습니다. 다행히 저의 경우 개발자분들이 로그를 미리 만들어주셨기에 로그를 심는 과정부터 진행하진 않았습니다. 만약에 로그가 없지만 빠르게 분석이 필요한 경우 관계형 데이터베이스에서 일단 데이터를 가져와서 인사이트를 얻을 수도 있습니다.

다음은 단기 계획에 대해서 표로 정리한 것 입니다. 순서대로 정리하였으며 필요에 따라서 해도 되고 안 해도 됩니다.

계획	계획 내용	비고
로그 설계/개발	로그가 없다면 설계가 필요함 (이미 있는 경우가 많음)	관계형 데이터베이스의 데이터를 임시로 사용하는 경우도 있음 또는 로그 플랫폼(?)을 사용하기도 함 (Google Analyics / Amplitude 등)
데이터 플랫폼 선정 및 구축	데이터를 담을 데이터 플랫폼 구축 필요함 (예시 : BigQuery / Snowflake / Databricks등)	레이크하우스를 구축할것인지 정보계 데이터 웨어하우스를 만들것인지 구축 범위 협의도 필요
데이터 아키텍처 설계 및 정책 수립	데이터가 어디에 어떻게 적재되고 어떠한 형태로 적재될지부터 정책등을 만들어야함 또한 데이터 관련 정책을 수립하여 데이터가 잘 쌓이고 잘 활용되도록 해야함	참고 : 데이터아키텍처란 무엇인가?
데이터 파이프라인 개발	데이터를 담을 데이터 플랫폼을 구축 하였다면 데이터 플랫폼에 담을 데이터를 가져와야 함
데이터 모니터링 개발	데이터 파이프라인 / 정합성등의 체크를 하는 모니터링 개발	필요에 따라서 파이프라인 구축과 동시에 진행 필요
데이터 플랫폼 운영	데이터 플랫폼을 운영하여 사용자가 잘 사용 하도록 함

1. 로그 설계/개발

일단 아무것도 없는 경우 로그 설계부터 시작해야 합니다. 로그를 만들어야지 그것을 담을 그릇을 만들어도 담을 내용물이 있기 때문에 이 작업은 굉장히 중요합니다. 로그를 당연하게도 기획/사업/마케팅등 데이터를 실제 사용할 사람들의 의견을 반영하여 설계를 하는 게 좋습니다. (나중에 만들었는데 실제 사용자가 못쓰면 무슨 소용이겠습니까...?)

아마 이 로그 설계와 개발은 회사의 여건에 따라서 가능 하기도 하고 불가능하기도 하고 오래 걸리기도 하고 빠르게 진행되기도 할 것 같습니다. 관련해서 조금 더 자세한 내용은 아래의 글을 참고하면 좋을 거 같습니다.

[공통] 데이터를 적재하고 보기까지

[공통] 데이터를 적재하고 보기까지

burning-dba.tistory.com

앞서 말한것과 같이 로그가 없으면 만들어야 하지만 아닐 경우 관계형 데이터베이스에서 가져와서 인사이트를 얻을 수도 있습니다. 관계형 데이터베이스에서 데이터를 가져오기 위해선 아무 준비가 없어 가능은 하지만 제가 예전에 썼던 글을 참고하면 조금 더 안전하고(?) 좋은 성능으로 관계형 데이터베이스에서 데이터를 가져올 수 있습니다.

[ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계

[ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계

안녕하세요. 데이터엔지니어 주형권입니다. 오랜만에 꽤나 길고 범용적인 주제에 관해서 글을 쓰려고 합니다. 많은 회사에서 데이터를 활용하여 많은 업무를 하고 데이터를 이용해서 많은 의사

burning-dba.tistory.com

2. 데이터 플랫폼 선정 및 구축

로그가 어느정도 준비되었거나 관계형 데이터베이스에서 가져오기로 하였다면 데이터를 담을 공간이 필요합니다. 그렇기 때문에 여러 가지 데이터 플랫폼 중에서 하나를 선택하기도 하고 필요에 따라서 여러 개를 선택하기도 합니다. 다만 저는 한 개로 통일하여 사용하시길 권장드립니다. (나중에 관리 포인트가 너무 많아지고 각 데이터플랫폼마다 특색이 달라서 공부할게 많아집니다.)

다양한 데이터플랫폼

데이터 플랫폼의 경우 제가 아는 것만 나열해도 10개가 넘을 것 같고 위의 사진에 나오지 않은 여러가지 수많은 오픈소스 플랫폼 /상용 플랫폼 등 여러 가지 플랫폼이 있습니다. 제가 알지 못하는 플랫폼도 엄청나게 많을 거라고 봅니다. 사실 데이터 플랫폼을 무엇을 선택하는지는 본인의 상황과 회사의 상황에 따라서 모두 다른 것 같습니다. 꼭 위의 사진에 데이터 플랫폼을 사용하지 않아도 되고 관계형 데이터베이스를 데이터 플랫폼으로 사용하는 곳도 많이 있습니다.

관련해서는 아래의 글을 참고하면 도움이 많이 될거 같습니다. LG전자에서 1년 동안의 Databricks 구축에 관련된 회고 글입니다. 전반적인 데이터플랫폼 구축 과정을 담고 있으면 이 글의 기술적 압축본이라고 보면 좋을 거 같습니다.

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

안녕하세요. 주형권입니다.태어나서 처음으로 회고라는 것을 해보네요. 회고라는 것이 무엇인지 몰라서 인터넷을 검색하다가 다양한 회고 기법에 대해서 보았고 잘 모르겠어서 AI에게도 질문을

burning-dba.tistory.com

3. 데이터 아키켁처 설계 및 정책 수립

데이터를 어디서 받아서 어떻게 저장하고 어떠한 단계를 거쳐서 어떻게 제공할지 등의 전체적인 그림을 보여주는 것이라고 알고 있습니다. 대표적으로 Databircks에 메달리온 아키텍처가 있으며, 이러한 데이터 아키텍처를 설계하여 데이터가 어디에 적재되어야 할지 등과 데이터를 어떻게 보여줄지 등을 보여줘야 합니다.

Databricks 메달리온 아키텍처

데이터 아키텍처를 설계하고 이를 기반으로 데이터플랫폼을 만들었다면 정책을 세워야 합니다. 데이터 정책에 여러가지 예시가 있는데, 예를 들면 데이터권한 관리 또는 데이터 배치 주기 또는 사용자들에게 제공할 데이터와 제공하지 않을 데이터등의 정책이 필요합니다.

사실 이 부분은 조금 더 큰 범위로 말하면 데이터 거버넌스라고 할 수 있습니다. 그런데 굳이 거버넌스라고 하지 않은 이유는 초기에 거버넌스 부서가 있지 않은 경우가 대부분이고 있다 하더라도 엄청 세세한 부분까지 빠르게 만들어지는 어려울 거라고 봐서 정책이라고 약간(?) 축소하여 말하였습니다. 물론 거버넌스를 처음부터 확실하게 정하고 가면 제일 좋겠지만 초반에 이런저런 인력 및 시간적 이슈로 그렇지 못한 경우가 많아서 정책이라고 표현하였습니다.

4. 데이터 파이프라인 개발

로그도 준비가 되었고 담을 그릇(데이터 플랫폼)도 준비가 되었다면 이제는 데이터를 넣어야 합니다. 데이터를 넣을 파이프라인을 만들어서 데이터 플랫폼에서 데이터를 볼 수 있도록 만들어야 합니다. 데이터의 형태는 크게 3가지로 나뉘는데 초반에는 거의 대부분이 정형/반정형 데이터를 취급합니다. (아닐 수도 있지만 저의 경험상으론 그랬습니다.) 정형의 경우 주로 관계형 데이터베이스의 데이터를 의미하고 반정형의 경우 parquet 또는 Json이나 avro 같은 데이터를 의미합니다. 이러한 데이터의 경우 형태가 어느 정도 있기에 가져오는데 무리가 크게 없습니다.

우선 정형 데이터의 경우 신경 써야 하는 게 관계형 데이터베이스에서 데이터를 가져올 때 성능을 고려해서 가져와야 합니다. 위에서 언급한 [ETL] RDB에서 데이터를 ETL을 위한 최소한의 테이블 설계를 참고하시면 많은 도움이 될 것으로 보입니다. 아무리 강조해도 관계형 데이터베이스의 성능을 절대적으로 고려해야지 추후에 문제가 없습니다. 나중에 가서 파이프라인을 고치는 행위는 정말 많은 시간과 노력이 필요하고 데이터 파이프라인을 고치지 않고 관계형 데이터베이스를 고치려고 하면 정말 나중에 수십 수백 배의 시간과 노력이 필요합니다. (못 믿겠으면 한번 해보시길 권장...^^)

반정형의 경우는 성능도 성능이고 비용을 주로 많이 고민하는 것 같습니다. 아무래도 사용하는 만큼 부과되는 ETL 도구나 AWS / GCP 같은 곳에서 제공하는 도구등을 사용하거나 아니면 Spark 같은 도구등 여러 가지 도구를 사용해서 데이터를 ETL 하실 텐데 성능적으로는 파일 시스템에 분산처리를 하시기에 성능은 아주 잘 나올 것으로 예상됩니다. (아닌 경우도 있습니다.) 그래서 아마도 성능보다는 비용적으로 처리 비용을 아껴서 하시는 것에 중점을 둘 것으로 보입니다. 주로 네트워크 비용 (데이터 전송비용)과 저장비용 그리고 컴퓨팅 비용을 많이 중점적으로 봐야 할 것입니다.

5. 데이터 모니터링 개발

모니터링의 경우 자칫 쉽게 생각하여 나중에 만들지라고 생각할 수 있는데요. 그렇지 않습니다. 생각보다 모니터링만으로도 장애율을 많이 줄일 수 있고 비용적인 부분에서도 많은 부분을 잡아낼 수 있습니다. 자세한 이야기는 제가 이전에 썼던 모니터링 관련 글을 참고하면 좋을 거 같습니다.

[Databricks] Job Monitoring 방법론 : 수집 알람 보기

[Databricks] Job Monitoring 방법론 : 수집 알람 보기

안녕하세요. Databricks 관련해서 글을 쓰다 보니 굉장히 기본적인 모니터링 관련해서 글을 쓰지 않았네요. 제가 오늘 말씀드릴 내용은 아마도 모니터링에 가장 기본적인 Job에 대한 모니터링 방법

burning-dba.tistory.com

Databricks용으로 쓰긴 했지만 사실상 다른 데이터 플랫폼에도 적용 가능하며 읽어보면 많은 도움이 될 것 같습니다. 제 경험상으로 모니터링만으로도 실시간으로 데이터파이프라인 실패를 감지하고 불필요하게 발생하는 비효율 Query 등을 잡아내서 튜닝을 해주고 많은 것들을 할 수 있습니다.

6. 데이터 플랫폼 운영

데이터 플랫폼 운영을 굳이 따로 뺀 이유는 생각보다 할 일이 많아서입니다. 단순하게 데이터 추출이나 단순히 모니터링에 그치지 않고 데이터 플랫폼의 성능 튜닝이나 모니터링 고도화 파이프라인 고도화등 여러 가지 해야할 일이 많습니다. 실제로 제가 사용하는 Databricks에서도 Optimize / VACCUM등 여러가지 주기적으로 해줘야 하는 일이 있고 관계형 데이터베이스를 기반으로 데이터 플랫폼을 구축하신 분들이라면 백업과 인덱스 리빌딩등 해야 할게 참 많을 것 같습니다.

여기에 당연하게도 데이터 추출 및 데이터 사용자 관리등도 운영에 포함될 것입니다. 데이터 추출이 엔지니어로써 굉장히 하기 싫은 일이지만 어쩔수 없이 해야할수 밖에 없는 일이고 사용자가 늘어남에 따라서 여러가지 권한 문제나 어디까지 데이터를 제공할지의 문제도 봉착하게 될 것 입니다.

여기에 조금 더 나아가 비용의 압박을 조금씩 받기 시작할 것입니다. 보통 2년 차부터 받았던 거 같고 이 부분은 중기 단계에서 조금 더 자세히 다뤄볼까 합니다.

[Databricks] Job Monitoring 방법론 : 수집 알람 보기

주형권 — Tue, 2 Sep 2025 08:04:28 +0900

안녕하세요. Databricks 관련해서 글을 쓰다 보니 굉장히 기본적인 모니터링 관련해서 글을 쓰지 않았네요. 제가 오늘 말씀드릴 내용은 아마도 모니터링에 가장 기본적인 Job에 대한 모니터링 방법에 관련된 내용입니다. Databricks를 운영하면서 수도 없이 많은 모니터링을 만들었지만 아마도 이 모니터링을 가장 처음 만들었던 거 같습니다.

Databricks 운영에 관련해서 다른 글을 보시고 싶으시면 아래의 글을 참고해주세요.

[Databricks] Databricks 운영 정리 - 1편 :: 데이터엔지니어 군고구마

[Databricks] Databricks 운영 정리 - 1편

안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제

burning-dba.tistory.com

들어가며

위에서도 언급하였지만 Databricks의 모니터링의 필수요소라고 할 수 있는 Job에 대해서 오늘 글을 쓰고자 합니다. Job의 경우 아래의 그림에서 나오는 메뉴에 대한 부분입니다.

해당 내용에 관련해서 제일 먼저 만든 게 알림이였습니다. 우선 알람이 오고 빠르게 실패 유무를 확인해야지 실시간으로 대응이 가능했기에 Job의 실패 여부에 대한 알람 발송부터 만들었던 거 같습니다. 이후부터는 Job의 비용에 관한 대시보드를 만들어서 보여주기 시작했고, 이를 기반으로 Job마다 얼마의 비용이 나오는지 확인하고 이 비용을 줄여나가는 작업을 하였습니다.

이번 글에서는 작업의 실패여부를 감지하여 Teams로 발송하여 알람을 보내고 작업당 비용을 수집하여 일 배 치로 지표화 하는 과정에 대해서 설명하고 있습니다. 아마도 이 정도만 해도 Databricks의 Job에 대부분의 모니터링이 될 것으로 보입니다.

1. 데이터 가져오기

우선 무엇을 하든지 데이터가 있어야 합니다. 데이터를 가져와야지 그다음에 지표화를 하거나 알람을 발송할 수 있습니다. 저 같은 경우 Databricks에서 제공하는 api를 사용하였고, 이를 AWS에 RDS에 저장하고 알람/지표를 생성하였습니다. 간략하게 아키텍처를 그리면 다음과 같습니다.

위와 같이 API와 system table에서 데이터터를 가져왔습니다. 그리고 이것을 AWS의 RDS(Aroura)에 저장하고 이를 Superset으로 시각화하고 Teams 메시지로 발송하여 알림을 만들었습니다. 이 모든 과정을 Airflow를 통해서 스케줄 처리하고 Python기반으로 코드를 만들었습니다.

1.1. Job 실패 유무 데이터 가져오기

우선 Job 실패 유무의 경우 system.lakeflow.job_run_timeline 테이블에서 정보를 가져올 수 있습니다. 그래서 아래에 이야기 할 Job의 비용 관련 테이블을 가져올때 함께 가져올수 있지만 저는 해당 테이블을 사용하지 않았습니다. 그 이유는 해당 테이블이 실시간 동기화가 아니고 랜덤 하게 동기화되기 때문입니다. 실시간으로 데이터가 동기화되지 않아서 자칫 제가 해당 정보를 수집할 때 데이터가 없거나 테이블에 업데이트가 되어 있지 않아 잘못된 알람이나 정보를 알려 줄 수 있기 때문에 저는 Databricks의 API를 사용하였습니다.

제가 사용한 API의 경우 jobs/runs/list입니다.

Databricks REST API reference

docs.databricks.com

해당 API의 경우 실시간으로 실행되는 정보를 그대로 가져오기 때문에 누락의 위험이 없고 실시간으로 작업의 실패 여부를 판단 가능 합니다. 또한 Databricks의 Rest API의 경우 현재로서는 큰 제약이 없어서 여러 번 호출해도 큰 이슈가 없습니다. (추후에 유료화 or 제한이 있을 수 있습니다.)

저의 경우 다음과 같이 변수화 하여 받았습니다. job/runs/list의 경우 굉장히 많은 항목을 자세하게 볼 수 있습니다.

job_id = job_run_row.get('job_id')
run_id = job_run_row.get('run_id')
run_name = job_run_row.get('run_name')
run_page_url = job_run_row.get('run_page_url')
creator_user_name = job_run_row.get('creator_user_name')
job_state = job_run_row.get('state').get('life_cycle_state')
job_result_state = job_run_row.get('state').get('result_state')
job_start_time = datetime.fromtimestamp(job_run_row.get('start_time')/1000)
job_end_time = datetime.fromtimestamp(job_run_row.get('end_time')/1000)
run_duration = job_run_row.get('run_duration')/1000

저는 위의 내용을 기반으로 Job의 내용을 가져와서 실패 여부를 체크하였습니다. 물론 더욱 자세하게 볼 수 있으며 여러 가지 항목을 더 필요로 할 경우 위의 링크를 통해서 필요한 정보를 가져와 주시면 좋을 듯합니다.

1.2. Job 비용 관련 데이터 가져오기

Job의 비용에 관련해서는 system.billing.usage를 참고하였습니다.

SELECT
    usage_date,
    workspace_id,
    sku_name,
    usage_metadata.job_id AS job_id,
    SUM(usage_quantity) AS total_dbus_consumed
FROM system.billing.usage
WHERE usage_metadata.job_id IS NOT NULL 
    AND usage_date >= '{tddate}'
GROUP BY usage_date,workspace_id,sku_name,usage_metadata.job_id

위의 SQL을 보면 job_id가 IS NOT NULL을 가져옴으로써 job을 필터 할 수 있습니다. 저 같은 일 배 치로써 하루 한 번씩 RDS에 집계하면서 가져오도록 만들었습니다.

아래의 스키마 정의서에서 씐 부분을 붉은색으로 표기하였으며, 자세한 내용의 위의 테이블 링크를 참고해주세요. (이곳에 모든 칼럼이 있진 않습니다. 너무 컬럼이 많아서 잘렸습니다.)

1.3. Job 리스트 가져오기

Job의 실행 관련 데이터 이외에 가져와야 하는 게 Job의 리스트입니다. 여기에는 실행자 / 생성자가 있으므로 담당자를 알아야지 해당 담당자에게 알람을 발송할 수 있으므로 꼭 필요합니다. 또한 추가적으로 몇 가지 좋은 정보들이 있어서 저는 Job의 성공/실패를 알려주는 API와 별개로 해당 API도 호출하여 계속해서 Job 리스트를 가져옵니다.

제가 사용하는 Job리스트를 가져오는 API는 api/2.2/jobs/list이며, 아래에서 자세하게 볼 수 있습니다.

List jobs | Jobs API | REST API reference | Databricks on AWS

Databricks REST API reference

docs.databricks.com

아래와 같이 몇몇의 값을 가져와서 RDB에 저장하고 있습니다.

creator_user_email = result_job.get('creator_user_name')
run_as_user_email = result_job.get('run_as_user_name')
run_as_owner = result_job.get('run_as_owner')
job_name = result_job.get('settings').get('name')
schedule_time = json.dumps(result_job.get('settings').get('schedule'))
task = json.dumps(result_job.get('settings').get('tasks'))
create_time = datetime.fromtimestamp(result_job.get('created_time')/1000)
tags = json.dumps(result_job.get('settings').get('tags'))

1.4. 가격표 가져오기

가격표 가져오기(?)라고 하여 이게 뭐지? 싶은 분들이 많으실 겁니다. Databricks의 경우 모든 가격의 표기를 USD가 아닌 DBU (Databricks Unit)으로 하기 때문에 이것을 우리가 볼 수 있도록 하려면 USD로 바꿔줘야 합니다. 그런데 가격이라는 게 환율처럼 항상 변경이 됩니다. 그래서 Databricks 내에서 제공하는 테이블을 통해서 가격표를 매일 가져와야 합니다.

가장 최신의 데이터를 가져오기 위해서 PARTITION BY를 사용하였습니다. PARTITION BY를 이용해서 가장 마지막에 업데이트된 가격에 대해서 모두 가져옵니다.

SELECT 
   price_start_time
  ,sku_name
  ,pricing
FROM 
(
  SELECT ROW_NUMBER() OVER (PARTITION BY sku_name ORDER BY price_start_time DESC) AS rank
          ,price_start_time,sku_name,pricing.default as pricing
  FROM system.billing.list_prices
)AS T
WHERE rank = 1

가격이 업데이트될 때마다 APPEND 형태로 추가되는 것으로 보이며, 그렇기 때문에 최신 데이터만 필터 해서 가져오면 다음과 같이 가져올 수 있습니다.

위의 내용을 가지고 sku_name과 조인하여 보여주면 DBU를 USD로 보여줄 수 있습니다.

2. 알람 보내기

알람은 Teams 기준으로 만들었습니다. 왜냐면 저희 회사에서는 공식적으로 Teams를 사용하고 있어서 Teams를 활용하였습니다. Teams를 통해서 보내는 참고할 자료는 아래의 링크를 확인해 주세요.

[Teams] Python에서 Power Automate Workflow을 이용한 Teams 메시지 전송 :: 데이터엔지니어 군고구마

[Teams] Python에서 Power Automate Workflow을 이용한 Teams 메시지 전송

안녕하세요. 주형권입니다. 최근에 Python을 통해서 특정 상황에서 Teams 채널에 메시지를 전송 할때 다음과 같이 알림이 발생하여 다른 방법으로 보내는 방법을 찾는 과정을 정리하였습니다. 이

burning-dba.tistory.com

[Python/Teams] Teams Webhook 메시지 보내기 — 데브옵스 놀이터

[Python/Teams] Teams Webhook 메시지 보내기

[Python/Teams] Teams Webhook 메시지 보내기 팀즈 채널의 커넥터에서 Incoming Webhook을 구성하면, Webhook URL을 얻을 수 있다. 파이썬의 requests와 json 라이브러리를 통해 webhook 메시지를 json형태로 전달할 수

heywantodo.tistory.com

작년부터 Teams에서 webhook을 없앤다고 하였는데 잘 서비스되고 있고 Power Automate Workflow는 아직 안정화가 안된 거 같아서 저는 webhook을 조금 더 추천드립니다. 물론 다양한 기능은 Power Automate Workflow가 조금 더 좋지만 안정성은 제 개인적 생각으로 webhook이 좋은 거 같습니다.

일단 위에서 저장한 2개의 테이블 1.1.Job 실패유무 테이블 / 1.3.Job 리스트 테이블 2개를 이용해서 아래와 같이 데이터를 만들어서 for문을 돌리면서 더 아래에 JSON을 이용해서 Teams 메시지를 발송하였습니다.

SELECT CONVERT_TZ(job_start_time, 'UTC', 'Asia/Seoul') AS job_start_time
            ,CONVERT_TZ(job_end_time, 'UTC', 'Asia/Seoul') AS job_end_time
            ,a.job_id
            ,a.job_name
            ,a.job_state
            ,job_result_state
            ,creator_user_email
            ,a.workspace_name
            ,a.run_page_url
FROM monitoring.databricks_job_task AS a -- 1.1. 테이블
LEFT JOIN monitoring.databricks_job_list AS b -- 1.3. 테이블
ON a.job_id = b.job_id 
WHERE a.job_end_time >= DATE_ADD(DATE_FORMAT(NOW(),'%Y-%m-%d %H:00'), INTERVAL -1 HOUR)
AND a.job_result_state NOT IN ( 'SUCCESS','CANCELED') 
AND a.job_name NOT LIKE 'TEST_%' -- TEST라고 앞부분에 넣으면 알람 안받음(테스트용은 X)

아래는 webhook 기준으로 보내는 JSON입니다. 참고해서 사용해주시면 좋을 거 같습니다. 그리고 여기에 JSON에 보시면 몇 가지 이모티콘이 있는데요. 아래에 사이트를 들어가서 키워드에 맞춰서 검색하면 알맞은 이모티콘이 나옵니다.

Storage Emojis | ️ ️ | Copy & Paste

We've searched our database for all the emojis that are somehow related to Storage. Here they are! There are more than 20 of them, but the most relevant ones appear first.

emojidb.org

{
    "type": "message",
    "attachments": [
        {
        "contentType": "application/vnd.microsoft.card.adaptive",
        "content": {
            "type": "AdaptiveCard",
            "size": "Large",
            "body": [
                {
                    "type": "TextBlock",
                    "size": "Large",
                    "weight": "Bolder",
                    "text": "**  Databricks 작업 실패 알람**"
                },
                {
                    "type": "TextBlock",
                    "text": "<at>user_mention</at>",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  Workspace : {workspace_name}",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  작업 이름 : {job_name} / ({job_id})",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  작업 수행 시간 : {start_date} ~ {end_date}",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  작업 상태 : {job_state}[{job_state_result}]",
                    "wrap": "true"
                },
                {
                "type": "ActionSet",
                "actions": 
                    [
                        {
                        "type": "Action.OpenUrl",
                        "title": "  작업 바로가기",
                        "url": f'{run_page_url}'
                        }
                    ]
                }
            ],
            "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
            "version": "1.0",
            "msteams": {
                "width": "Full",
                "entities": [
                    {
                        "type": "mention",
                        "text": "<at>user_mention</at>",
                        "mentioned": {
                            "id": f"{job_creator}",
                            "name": f"{job_creator}"
                        }
                    }
                ]
            }
        }
    }]
}

위의 내용에 대해서 결과물은 다음과 같이 나옵니다. 아주 심플하게 만들었고 링크를 통해서 담당자가 바로 해당 Job으로 접근이 가능합니다.

3. 대시보드

대시보드의 경우 엄청 많지는 않고, 몇몇의 필요한 대시보드만 만들어서 봤습니다. Superset을 이용해서 만들었으며 요청하시면 해당 대시보드를 만든 SQL이나 여러 가지 기법은 개별적으로 메일로 보내드리겠습니다.

3.1.Job 실행 내역 대시보드

특정 Job이 갑자기 오래 걸리거나 평소에 얼마나 걸리는지 확인을 위해서 만들었습니다. 위의 내용은 모든 Job을 클릭해서 그렇지만 특정 Job을 검색하면 아래와 같이 상세하게 분석이 가능합니다. 물론 더 아래쪽에 표 형태로 존재합니다. (지울 게 너무 많아서 귀찮아서 안 붙였습니다...)

실행 내역의 경우 특정 작업이 오래 걸리거나 하는 것을 볼 수도 있고 갑자기 전체적으로 시간이 늘어난 것도 볼 수 있습니다. 이럴 경우 작업을 조정하거나 컴퓨팅 성능을 늘리거나 하는 여러 가지 조치를 취할 수 있습니다. 관련해서 작업 시간이 오래 걸리는 SQL을 추적하는 방법은 아래의 링크를 통해서 볼 수 있습니다.

[Databricks] 비효율적인 작업 추적기 만들기 :: 데이터엔지니어 군고구마

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

burning-dba.tistory.com

3.2. Job 실행 리스트 대시보드

어딜 가나 전체적인 현황을 보여주는 대시보드는 있어야 합니다. Databricks 자체에서 제공하긴 하지만 region을 여러 개 사용하는 사람들의 경우 하나씩 들어가서 봐야 하는 번거로움이 있습니다. 그렇기 때문에 이를 합쳐서 볼 수 있도록 1.3.Job리스트 테이블을 이용하여 다음과 같이 한 번에 볼 수 있는 대시보드를 만들었습니다.

그리고 추가적으로 실행시간을 보여줌으로써 사용자가 언제 내가 요청한 데이터가 동기화되는지 알 수 있습니다. 그렇기에 조금이나마 문의사항을 덜어줄 수 있습니다.

3.3. Job 비용 대시보드

아마도 이 대시보드가 반응이 제일 좋았던 거 같습니다. 비용에 관련해서 민감하기 때문에 대시보드를 통해서 어떠한 Job이 비용이 많이 들어가는지 한눈에 본다면 그만큼 대처가 빠르고 정확해집니다. 이 대시보드를 통해서 몇몇의 불필요하거나 비용이 많이 들어가는 Job에 대해서 튜닝을 통해서 비용을 절감하였습니다.

해당 대시보드의 경우 1.2.Job 비용 관련 테이블을 이용해서 만들어졌으며, Superset에 Pivot Table을 이용해서 만들었습니다. 아마 1.2.Job비용 관련 테이블을 잘 적재하셨다면 지표를 만드는 데는 큰 문제는 없을 것 같습니다.

관련해서 비용이 많이 나오는 경우 알람을 보내는 기능도 추가할 수 있습니다. 이건 취향(?)에 따라서 운영자가 하면 좋을 것 같습니다.

마치며

운영은 정말 끝이 없는 거 같습니다. 이렇게 길고 여러 개의 글을 썼는데 아직도 써야 하는 글이 산더미인 것을 보면 정말 끝이 없습니다. 운영은 계속해서 나오고 계속해서 진화하는 거 같습니다. 최근 AI로 인해서 많은 사람들이 직업에 위기를 느끼지만 저는 딱히 느끼지 못합니다. 왜냐면 그 AI 조차도 운영을 해야 하거든요...

그렇기 때문에 저는 오히려 운영을 고도화하고 운영에 대해서 경험이 많은 엔지니어로써 계속해서 성장하고 싶습니다. 그에 대한 몇 가지 팁 중에 오늘은 Databricks Job에 모니터링에 대해서 알아봤습니다. 어찌 보면 가장 먼저 다뤘어야 하지 않았나 싶었지만 하다 보니 Databricks Job의 모니터링을 빼먹고 있는 걸 얼마 전에 알았습니다. 그래서 부랴부랴 글을 작성하였습니다.

이글이 많은 데이터 엔지니어 나아가 데이터를 다루는 모든 분들에게 영감이 되었으면 좋습니다. 감사합니다.

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

주형권 — Thu, 24 Jul 2025 13:54:57 +0900

두오모 성당

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

태어나서 처음으로 회고라는 것을 해보네요. 회고라는 것이 무엇인지 몰라서 인터넷을 검색하다가 다양한 회고 기법에 대해서 보았고 잘 모르겠어서 AI에게도 질문을 하였습니다. 그래서 제가 내린 결론은 결국 형식과 틀은 없다입니다. 딱히 무언가 정해진 틀은 없는 거 같고 다양한 기법이 존재하는 거 같습니다.

저는 이러한 기법을 사용하지 않고 제가 느꼈던 점과 어려웠던 점을 이야기 해보고 다른 사람들에게 영감을 주었으면 좋겠습니다. 항상 이야기하듯이 저의 경험과 기술은 정답이 아니며 참고를 하고 앞서 말했듯이 영감을 받기를 바랍니다. 딱 참고 정도 하면 좋겠습니다.

이 회고는 제가 현재의 회사에 입사하고 처음으로 Databricks라는 데이터 플랫폼을 접하고 이를 기반으로 데이터 환경을 구축한 경험을 기반으로 작성하였습니다. 현재 입사 후 어느덧 1년이 지났고 지금까지 경험하였던 어려움과 새로운 경험 그리고 새로운 배움 그리고 이를 통해서 느끼는 생각과 앞으로 남은 과제까지 여러 가지 부분에 대해서 작성하였습니다.

시작 : 입사 후 1~3개월의 상황 파악과 급한 불 끄기

이 회사에 입사는 2024년 06월에 하였습니다. 슬슬 더워지기 시작 할때즈음에 입사를 하였고 입사 첫날 인사팀에 입사 관련하여 서류 작성과 회사 내부 복지나 여러 가지 제도등을 간략하게 들었습니다. 그리고 끝나자마자 일을 시작했습니다. 당장 다음 주에 오픈해야 하는 서비스가 있는데, 이걸 오픈해야 했거든요... 입사하고 아직 계정도 못 받았지만 일단 시작해야 하니 일단 상황 파악을 하고 이것을 잘 오픈하는 것이 급선무였습니다.

어찌어찌 급한불은 끄고 상황을 하나씩 파악했습니다. 우선 현재 데이터 플랫폼이 Databricks라는 점을 듣고 Databricks에 대해서 공부를 시작하였습니다. 저는 태어나서 한 번도 Databricks를 해본 적이 없거든요....

인생 처음 접하는 Databricks

제가 공부만 하고 있을 순 없었습니다. 왜냐면 그럴 시간이 없었습니다. 이미 Databricks를 이용한 데이터 환경이 오픈을 하고 실제로 사용하는 사람도 있었습니다. 사용자는 많지 않지만 그래도 있으니 어떻게든 운영을 해야 했습니다. 우선 데이터는 잘 들어오는지 이 데이터들은 문제가 없는지 수명주기나 파티션등 여러 가지 등을 봐야 했습니다.

0. 데이터 아키텍처 설계 : 어떤 곳이든 어떤 일이든 설계는 중요하다.✍

어떤 분야를 떠나서 무슨 일을 하기 전에 계획을 수립 하는 것은 매우 중요합니다. 처음에 입사했을 때 데이터를 적재하고 는 있지만 ODS / MART / FACT와 같이 잘 나뉘진 아키텍처가 아니었고 데이터를 어떠한 네이밍에 맡게 적재하고 어떻게 어디에 얼마나 적재를 해야 하는지에 대해서도 정책이 없었습니다.

설계는 언제나 중요하며, 기반을 잘 다져야지 건물도 튼튼하다.

그래서 우선 만들어야 했던게 데이터 아키텍처였습니다. 우선이라고 했지만 사실상 1번의 모니터링 시스템과 거의 동시에 만들었습니다. 저의 모든 지식과 경험과 각종 글을 참고해서 꾸역꾸역 데이터 아키텍처를 설계하였습니다. 내부적인 아키텍처이기에 공개는 못하겠으나 Databricks의 Medallion 아키텍처와 같은 형식으로 데이터 아키텍처를 설계 하였습니다. 기존에 데이터를 어디에 어떻게 적재할지 몰랐으나 이런 식으로 데이터의 형태와 가공정도에 따라서 데이터를 분류하고 이를 기반으로 Naming Rules을 만들어서 적재적소에 데이터를 나누어서 적재하였습니다.

대략적으로 위와 같이 설계하였고 운영을 하였습니다. 아마도 데이터를 하신 분들이라면 위의 아키텍처가 엄청나게 특별하거나 부족하거나 하기 보다는 그냥 보편적인 느낌일 수 있습니다. ODS -> Mart -> Fact로 이어지는 데이터와 개인이 쓸 수 있는 Personal 데이터를 만들어서 개인이 조작할 수 있도록 하고 인사이트를 도출하도록 하는 여러 가지는 아마 많은 회사에서 도입해서 사용하는 방식일 것입니다.

1. 일단 보고 이야기하자 : 모니터링 시스템 구축

일단 뭐가 어떻게 되어 있는지 현황을 파악하고 당장 모니터링을 통해서 현재의 현황을 보여주는 모니터링 시스템을 구축하여 대시보드를 구축하고 데이터 파이프라인이나 시스템 등이 문제가 있을 때 이를 실시간으로 알려주는 여러 가지 시스템이 필요했습니다.

보고 이야기 하는 게 생각보다 중요하다.

뭐가 어떻게 돌아가는지 알아야지 어디서 문제가 있는지 알 수 있으니까요... 그러면서 자연스럽게 Databricks의 여러 가지 봐야 하는 부분에 대해서 공부를 하였습니다. Databricks에 어떠한 게 필요하고 무엇을 중점적으로 봐야 하고 성능을 끌어올리기 위해서는 무엇이 필요하고 무엇은 필요하지 않고 이것을 판단하려면 현황 파악을 해야 했습니다.

만들었던 것 중에 크게 몇 가지만 나열하면 다음과 같은 것들을 만들었습니다. 이것은 Databricks뿐 아니라 AWS와 데이터 관련 모니터링도 포함 합니다. 저는 이것은 Superset을 이용해서 구축 하였으며 현재 이 모니터링 시스템은 모아이로 불리고 있습니다. 몇가지 중점적인 모니터링 관련해서 적어보면 다음과 같으며, 회사의 내부적인 부분도 있기에 전부 공개하지는 않았습니다.

️ Databricks
- Databricks 비용 관련 DBU 지표
- Workflow 작업 실패 실시간 감지 알림 (메신저 연동)
- 오래 걸리는 작업 감지 알림 ( SQL / Notebook )
☁️ AWS
- S3 Bucket 사이즈 지표
- AWS 전체적인 비용 지표
Airflow
- Airflow Dag 실패 실시간 감지 알림
️ 데이터
- 주요 테이블 건수 체크

여러 가지 모니터링을 만들어서 상황 파악을 어느 정도 하였고 급한 부분을 수습하기에 이르렀습니다. 그중에 몇 가지 사례를 소개하려고 합니다.

2. vacuum : 청소기요? ️

AWS S3의 사이즈를 보고 이상한 생각이 들었습니다. Databricks의 기본 저장소가 S3를 사용해서 Delta가 전부 S3에 있는데 Databricks에서 표기하는 테이블 사이즈와 S3의 사이즈가 너무 많이 차이가 났습니다. 수십~수백 TB가 차이가 나니 이건 왜 이럴까?라는 생각이 들었습니다. 그러다 알아낸 게 Databricks는 vacuum이라는 명령어가 있고 이를 수행 하는것이 굉장히 중요한 것이라는 것이였습니다.

VACCUM 굉장히 중요하더라

일단 이놈이 뭔지부터 공부해서 왜 이게 필요한지를 알아봤습니다. 일단 말 그대로 청소하는 명령어였습니다. 여기서 줄줄이 이야기하면 이야기가 길어지니 관련된 내용은 제가 기존에 써둔 글을 참고하면 좋을 것 같습니다.

[Databricks] Optimize / VACUUM

안녕하세요. 데이터엔지니어 주형권입니다.어느덧 Databricks를 맡고 운영한 지 5개월 정도가 흘렀습니다. 초반에 데이터 아키텍처와 정책을 잡고 서서히 물리적인 데이터를 운영 함에 있어서 꼭

burning-dba.tistory.com

결론적으로 총 합쳐서 수백 TB의 불필요한 AWS S3의 용량을 줄였습니다. 엄청나게 감소하였고 이로 인해서 저장 비용과 처리 비용이 굉장히 많이 감소하였습니다.

3. 왜 느리지? : 파티션을 다시 구축하였다.

파티션은 어느 빅데이터 또는 RDB 모든 데이터 관련 시스템에서 가장 중요하다고 볼 수 있습니다. 파티션이 없으면 엄청나게 느리게 데이터를 처리하고 불필요한 데이터까지 모두 읽어서 처리해야 하기 때문에 당연히 느릴 수밖에 없습니다. 그래서 가장 주요하게 사용되는 핵심 테이블부터 파티션을 재구성하기 시작하였습니다.

현재 다니고 있는 회사가 약간 특이하게도 대규모 삭제를 하고 있다는 것입니다. 그래서 기존에 흔한(?) 데이터 플램폼과 같이 APPEND만 하는 방식과 달리 APPEND와 DELETE가 일어나야 합니다. 그래서 일자별로 파티션을 생성하면 전체 테이블을 모두 조회해서 지워야 하기에 파티션이 너무 많이 파편화됩니다. 그렇다고 다른 것으로 파티션을 걸자니 파티션의 단위가 너무 커져서 처리할 때 이점을 얻지 못합니다.

결론적으로 가장 많이 그리고 가장 자주 사용 하는 패턴을 기반으로 만들었다.

뭐 당연하겠지만 WHERE에 가장 많이 사용하는 칼럼 그리고 가장 자주 사용하는 SELECT 패턴을 기반으로 하나씩 파티션을 재구축하기 시작하였습니다. 여기서 문제는 기존의 테이블이 너무나도 대규모라서 (크게는 1개에 50TB가 넘는) 일반적인 방법으로는 처리가 굉장히 어려웠습니다. 단순히 새로 만들고 부어 넣고 하려고 해도 계속해서 터져 버리는 Databricks를 보면서 현타가 왔습니다.

그때 공부해서 했던 게 바로 Shuffle partition이었습니다. Databricks는 Spark를 기반으로 만들어졌고 (혹시 아니면 말해주세요.) Spark 옵션에 대해서 공부를 하기 시작했습니다. 왜 터질까? 참고로 저는 Spark도 해본 적이 없습니다. 그래서 Databrick와 Spark를 동시에 공부하면서 많은 것을 배웠습니다.

이후에 처리에 많은 시간이 소요되는 작업이 소요시간이 많이 감소되었습니다. 이로 인해서 자연스럽게 Databricks의 비용이 감소하는 효과까지 얻었습니다. 처리하는 양이 줄어들면 그만큼 자원의 소모가 적기에 효율적으로 작업을 할 수 있게 되었습니다.

중간 : 숨을 고르면서 업무를 분배하였다. ️

어느덧 6개월 정도의 시간이 흐르니 시스템이 많이 안정화되었습니다. 급한 불을 끄고 정책을 세우고 아키텍처를 만들고 어느 정도 데이터 플랫폼이 궤도에 올랐습니다. 혼자서는 이제 무언가를 하기엔 힘이 붙이기도 하였고 시니어 엔지니어로써 팀원들을 챙겨야 했고 팀원들에게 업무를 분배해서 각자의 확실한 색을 입혀주고 싶었습니다.

그래서 이것을 정리하기 시작하였고 다음과 같이 업무를 정리하고 업무를 나누었습니다. 각자의 특색에 맞게 업무를 나눔과 동시에 팀원들의 커리어도 잘 챙겨야 했기에 많은 생각을 하면서 업무 분장과 프로젝트를 정리 나아갔습니다.

1. 나부터 정리를! : 업무를 표로 정리하고 자세하게 기입하였다.

일단 저도 업무가 정리가 안되고 미친 듯이 달려왔기에 뭘 했고 뭘 해야 하고 무엇이 미흡한지 몰랐습니다. 그래서 우선 나부터 살고 보자는 생각으로 업무를 정리하였습니다. 그게 아마 입사 후 4~5개월 즈음이었던 거 같습니다. 제 머릿속에서도 정리가 안되는데 어떻게 남에게 주겠습니까?

일단 내 업무를 정리부터 하자.

작년에 제가 해야 했지만 못했던 일과 하려고 했던 일 했던 일을 크게 나누어서 정리를 하였습니다. 분류를 정하고 이에 관련해서 내가 찾아본 아니면 읽으려고 했던 글이 있으면 링크를 걸어두고 제목과 내용 그리고 어디까지 하였는지 진척도까지 표로 정리하였습니다. 대략 이렇게 정리하였습니다.

이렇게 정리하고 내가 지금 할 수 있는 것과 없는 것을 정확히 분류해서 가장 급한 것부터 우선순위로 쳐내야겠다 싶었습니다. 그렇게 정리를 하고 나니 이제 무엇을 해야 할지 보이기 시작하였습니다.

2. 같이 하자 : 업무를 분배해서 함께 시너지를!

이제 업무를 정리하였고 급한 업무도 어느 정도 하였으니 분배를 해야 했습니다. 그래서 모든 팀원을 불러서 여기서 본인이 하고 싶거나 할 수 있다고 생각하는 업무를 고를 수 있도록 하였고 그렇게 프로젝트를 나누어서 수행하였습니다. 큰 프로젝트와 작은 상시 업무를 나눠서 고루 분배하고 본인들의 강점을 최대한 살릴 수 있도록 하였습니다.

혼자서는 한계가 있고 나는 1명이다. 나누고 함께 가야지 오래간다.

이렇게 업무를 나누고 저는 실무적인 측면과 함께 프로젝트를 리딩하는 역할을 많이 맡아서 하였습니다. 고문 격으로 프로젝트에 참가하여 프로젝트를 봐주고 조언을 해주고 방향을 잡아주는 일이 많아졌습니다. 초반에는 많은 부분을 봐줘야 했지만 나중에 가면 갈수록 모든 팀원들의 눈높이가 향상되면서 제가 관여하지 않아도 잘 끝나는 프로젝트가 점차 늘어났습니다.

그렇게 함으로써 저는 더욱 멀리 보게 되면서 팀의 더욱 많고 큰 프로젝트에 대해서 이야기를 할 수 있게 되었습니다. 여러 가지 프로젝트를 동시에 진행도 가능해지고 저뿐 아니라 팀원들도 현재의 팀에서 무엇을 하는지 명확히 이해하고 같은 방향과 목표를 가지고 일을 할 수 있도록 되었습니다.

후반 : 데이터 플랫폼의 비용절감 그리고 사용성 증가를 위한 노력 ‍

후반부로 가면서 데이터 플랫폼이 거의 안정화되었습니다. 그러면서 이제는 안정화를 넘어서서 비용을 절감하고 사용성을 증가시키기 위한 노력이 필요했습니다. 아무래도 데이터 플랫폼이 많은 돈을 쓰다 보니 어느 회사나 비용의 압박은 언제나 받는 거 같습니다. 그래서 데이터 엔지니어는 해를 거듭할수록 어떻게든 돈을 아끼기 위해서 노력하는 거 같습니다. 예전에는 고민하지 않았던 부분까지도 보고 또 보고 하면서 비용을 아끼기 시작하는 거 같습니다.

그리고 나아가 데이터 플랫폼을 만들고 아무도 사용하지 않으면 안 되기에 사용성을 증가시키기 위해서 노력해야 하는 거 같습니다. 처음 엔지니어를 시작할 때 이런 고민을 해본 적이 없었는데 이제는 데이터가 누구나 사용이 가능하도록 하는 것이 많은 회사의 목표이다 보니 이런 고민에 부딪히는 거 같습니다.

1. 돈의 압박 : 정말 쥐어 짜내서 해야 한다.

제가 데이터 플랫폼을 운영하면 정말 짜기로 유명한 엔지니어입니다. 진짜 회사 돈을 내 돈처럼 아껴서 쓰려고 합니다. 돈에 굉장히 민감합니다. 왜냐면 결국 비용이 많이 들면 그 압박은 고스란히 데이터 플랫폼을 운영하는 팀이 받습니다. 사용자는 최대한 이러한 압박을 받지 않도록 해야 하기에 여기저기서 눈치를 봐야 합니다.

더러워서 내가 가끔 내주고 싶다.

라는 말을 가끔 속으로 하지만 절대 그럴 순 없기 때문에 한 푼 두 푼 아끼고 아껴서 해야 합니다. 처음부터 잘 만들어야지 돈도 그만큼 아낄 수 있습니다. 두 번 세 번 작업하면 그게 다 돈입니다. 내 돈은 아니지만 어차피 제가 할 일이니 최대한 돈 아껴서 하는 게 좋겠지요. (그냥 귀찮아서 크긴 하다...)

그래서 저는 최대한 오픈 소스를 많이 활용하고 모니터링도 타이트하게 하려고 노력합니다.

위와 같이 수많은 (이것도 일부입니다.) 모니터링을 통해서 실시간 또는 주기적으로 알람을 받고 이를 끊임없이 검증하고 돈을 더 아낄 수 없을지 고민합니다. 그래야지 누수가 덜하거든요. 그리고 이런 거 준비를 해두면 나중에 위 (팀장님보다 더 위)에서 뭐라고(?) 할 때도 변명(?) 거리가 생깁니다. 우리는 진짜 타이트하게 하는데 많이 쓰는 걸 어떻게 합니까?라고 할 수 있습니다.

말은 변명이지만 이건 사실입니다. 데이터가 많고 많은 사람이 쓰는데 어떻게 합니까? 못하게 할 수도 없고 아니면 느리다고 쓰지도 않을 테고 정말 답이 안 나옵니다. 그래서 그만큼 정당한(?) 사유를 만들어두고 하는 것은 꽤나 유용합니다.

2. 혹시 우리 거 써볼래..? : 잘해줄게요 한번 해보세요.

아마도 제가 가장 크게 힘들어하고 가장 크게 고민하고 가장 크게 하고 있는 부분이라고 생각합니다. 내가 아무리 좋은 플랫폼을 만들었다고 하여도 누구도 사용하지 않는다면 어쩔 수 없이 그 플랫폼이 얼마나 잘 만들었다고 한들 그것은 외면받지 마련입니다. 그렇기에 이것을 잘 사용할 수 있도록 하는 것도 이제는 데이터 엔지니어의 숙명과도 같은 일이 돼 가는 것 같습니다. 하지만 정말 하기 싫습니다. 엔지니어가 하는 일이 얼마나 많은데 이것까지 해야 한다니요...? 근데 어쩌겠습니까? 세상이 변해가는 거 같습니다. 물론 저도 적응이 안 됩니다. 그리고 정말 하기 싫습니다.

잘 만들었으나 아무도 쓰지 않는다면 무슨 소용이겠는가?

그래서 어쩔 수 없이(?) 교육을 준비하고 교육 자료를 만들고 발표를 합니다.

이러한 교육을 진행하고 사람들이 우리가 만든 데이터 플랫폼을 잘 쓰도록 유도했습니다. 요즘은 그래서 "내가 데이터 엔지니어인지 인터넷 강의 강사인지 모르겠다." 싶을 때도 있습니다. 이밖에도 사람들이 잘 따라 할 수 있도록 따라 하기 글을 계속해서 연재하고 업데이트하고 하다 보면 현타가 많이 오긴 합니다.

그래도 한편으로 뿌듯한 것은 다양한 부서에서 사용하고 어떻게 쓰는지 문의가 하고 여러 가지 다양한 시그널이 있을 때는 보람을 느끼기도 합니다. 우리가 있다는 것을 어쩌면 알아주는 것이니까요. 하지만 현타와 뿌듯 사이의 충돌을 생각보다 자주 일어납니다. 아직도 충돌 중이고 아마 앞으로도 몇 년은 계속 충돌하지 않을까 싶습니다.

마무리 : 이제 뭐 하지? 그리고 뭘 더 해야 하지?⁉️

사실 저도 잘 모르겠습니다. 1년 동안 정말 많이 달려왔습니다. 이제는 무엇을 해야 할지 더 이상 찾기도 버겁습니다. 정말 쉴 새 없이 달리다 보니 이제는 달릴 기운도 없습니다. 그래서 숨 고르기 하면서 천천히 주변을 살피고 무엇이 미흡하고 무엇이 있으면 더 좋을지를 고민하고 있는 시기 같습니다.

전부 했다고 할 수 없기에 이것보다 더 나은 것은 없는지 이것보다 더 쉽게는 안되는지를 고민하는 단계인 거 같습니다. 제가 예전에 면접을 가면 "네가 모든 데이터 환경을 구축하고 그다음 스태프로 무엇을 할 것이냐?"라는 질문에 저는 늘 똑같은 대답을 했습니다.

플랫폼 다 구축하면 비용 절감하고 안정화시켜야죠

이제는 이 대답에서 한발 더 나아가야 하지 않을까? 싶습니다. 아마도 그건 사용성 증가겠죠... (진짜 싫지만...) 저는 항상 이걸 전단지 돌린다고 비유합니다. 내가 어떠한 제품을 생산하다가 다 만들었으니 이제 전단지 돌린다고 말이죠. 이게 진짜 싫긴 한데, 중요하지 않다고 하기엔 또 아니라고 생각합니다.

왜냐면 누군가는 써줘야 하거든요. 예전에는 데이터 플랫폼 소위 말해 정보계나 분석계의 사용자가 굉장히 한정적이라고 생각 합니다. 예를 들면 데이터 분석가 / 데이터 과학자 이외에 SQL이나 Python을 조금 하시는 분들이 대상자였다면 이제는 그 대상자의 한계가 없는 거 같습니다. 아니 정확히는 없애라고 많은 회사에서 요구를 하고 있습니다.

나는 데이터 엔지니어니깐 당연히 데이터 플랫폼 운영을 하고 데이터를 적재하고 데이터의 정합성을 검증하고 이런 전통적인 데이터 엔지니어에서 나아가서 이제는 어찌 보면 사용성을 증가시키는 데이터 엔지니어를 많이 필요로 하는 거 같습니다. 그냥 SQL 배우세요. Python 배우세요. 에서 끝나지 않고 어떻게 무엇을 얼마나 이용할지를 알려주고 누구나 쓸 수 있게 보편적으로 만들고 설명하는 부분도 하나의 과제로 주어진 거 같습니다.

끝으로 어느덧 1년의 기간을 이 회사에서 보내면서 너무나도 많은 일이 있었고 앞으로도 있을 것 같습니다. 무사히 잘 지나갔으면 좋겠고 저의 글을 보고 많은 분들이 Databricks 나아가 데이터 플랫폼을 구축하고 운영하는 부분에 있어서 영감을 얻으시고 공감을 얻으시길 바랍니다.

감사합니다.

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

주형권 — Fri, 11 Jul 2025 09:17:13 +0900

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

docs.databricks.com

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

Learn which services and events are recorded in the audit logs.

docs.databricks.com

이 테이블은 원래의 목적은 감사로그이지만 이곳에도 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

Learn how to use the SQL Statement Execution API in Databricks SQL with this hands-on tutorial.

docs.databricks.com

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

감사합니다.

[Databricks] Databricks 운영 정리 - 1편

주형권 — Wed, 21 May 2025 14:50:55 +0900

안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제일 많이 집중하고 있습니다. 제가 어느덧 Databricks를 접한 지 10개월이 넘어가는 시점에서 회사에 와서 처음 시작해 보는 Databricks 플랫폼 환경에서 무엇을 하였는지에 대해서 회고 겸 정리 겸 글을 작성하였습니다.

이 글은 타 회사와 환경과 비용적 측면에서 다를 수 있으므로 참고 차원에서 보시길 권해 드립니다. 제가 작성한 글이 무조건 정답은 아니며, 회사의 상황에 맞게 적용이 필요합니다. 그렇기에 꼭 본인의 회사에 적용을 하실때 환경과 상황에 맞게 각자의 판단에 맞게 적용을 부탁드립니다. 저의 글이 틀릴 수 있음을 감안해 주시기 바랍니다.

들어가며

앞서 말씀 드렷듯이 이 내용은 제가 적용하고 괜찮다(?) 싶은 생각이 드는 내용을 대략적으로만 정리하였습니다. 자세한 내용은 회사의 중요한 내용이 포함되어 있기도 하고 아직 정리가 끝나지 않아서 자세한 내용은 정리하지 못한 점 양해를 부탁드립니다. 그리고 비용이 생각보다 이것저것 많이 나와서 무엇이 맞다고 말씀을 못 드리겠습니다.

저도 Databricks 초보이고 하나씩 배워가면서 하기 때문에 틀린 내용이 있다면 언제든지 말씀 부탁 드립니다. 또한 이 내용을 꼭 인터넷에 검색하여 충분히 검증하고 적용을 부탁 드립니다. (글 내용을 회사에 적용 후 문제에 대하여 책임지지 않습니다.)

우선 1편이라고 시작은 하였지만 2편이 나오지 않을 수 있습니다. 생각나는 것을 적다보니 순서도 중요도가 아니고 그냥 번호만 붙여두었기에 순서는 중요하지 않습니다. 그러니 해당 내용에서 필요한 부분만 정리하여 보시길 권해 드립니다.

1. 비용 모니터링

비용

엔지니어는 언제나 비용에 관련해서 고민을 안할수 없습니다. 제가 여타 다른 글에서도 항상 강조하지만 돈은 엔지니어에게 떼려야 뗄 수 없는 존재입니다. 항상 모두 가능하다고 하지만 돈 앞에선 장사가 없습니다. 그렇기에 처음에 저는 비용을 모니터링하는 부분에 대해서 만들었습니다.

Databricks에서는 비용에 관해서 보여주는 테이블이 존재 합니다. ( system.billing.usage )

Billable usage system table reference | Databricks Documentation

Learn how the billable usage system table works so you can query and monitor usage in your Databricks account.

docs.databricks.com

위의 테이블에 비용에 관련해서 저장하는 테이블이 존재하며, 여러가지 정보를 담고 있습니다. 해당 테이블에서는 굉장히 자세하게 어떠한 작업이나 사용자가 얼마의 비용을 사용하였는지 보여줍니다. 하지만 이 테이블은 DBU(DataBricks Unit)라는 단위로 row가 저장되어 있어서 실제로 이를 계산하기 위해서는 디멘젼 테이블이 필요합니다.

Databricks에서 사용하는 비용 관련 디멘젼 테이블은 다음과 같이 존재합니다. ( system.billing.list_prices )

Pricing system table reference | Databricks Documentation

Learn how the billable usage system table works so you can query and monitor usage in your Databricks account.

docs.databricks.com

2. 테이블 옵션

Databricks의 옵션이라고 하기 보다는 저희가 지금 사용하는 Delta의 테이블 옵션이라고 하는 게 더 맞을지도 모르겠지만 Databricks 테이블에 적용할 수 있는 옵션은 엄청나게 다양합니다. 아래의 링크를 보면 옵션이 굉장히 다양한 것을 볼 수 있습니다.

Delta 테이블 속성 참조 - Azure Databricks

Azure Databricks의 Delta Lake 테이블 속성에 대한 참조 목록입니다.

learn.microsoft.com

이 옵션 역시 상황에 맞게 적절하게 옵션을 걸어주는게 맞을 거 같습니다. 몇 가지 중요하게 걸었던 옵션을 보면 제가 최근에 작성하였던 targetFileSize 옵션이 있습니다.

[Databricks] targetFileSize 테이블 옵션

안녕하세요. 테이블 옵션에 관해서 처음 글을 쓰는 거 같네요. Databricks에는 여러 가지 자동으로 최적화해주는 옵션이 있지만 해당 옵션을 추가하여 Small 파일을 방지하고 성능을 향상할 수 있을

burning-dba.tistory.com

추가적으로 제가 주요하게 확인하고 걸어본 옵션을 몇가지 공유하면 다음과 같습니다. (옵션 설명은 위의 링크 참고)

delta.autoOptimize.optimizeWrite
delta.autoOptimize.autoCompact
delta.targetFileSize
delta.dataSkippingStatsColumns
delta.enableDeletionVectors

옵션이라는게 테이블마다 특성이 다르기 때문에 모두 다르게 적용해야 하는 경우도 있으니 꼭 테이블의 특성에 맞게 옵션을 적용해야 합니다. 예를 들면 DELETE가 많거나 INSERT가 많거나 SELECT만 주로 일어나거나 여러 가지 상황이 있기 때문에 옵션은 테이블의 사용성에 맞게 다를 것으로 보입니다.

3. OPTIMIZE / VACCUM

어쩌면 정리작업?

이 2개는 진짜 아무리 강조해도 부족할거 같습니다. Delta 테이블의 경우 ACID가 보장되므로 INSERT / UPDATE / DELETE의 작업을 하면서 계속해서 새로운 파일을 만들어 냅니다. 그리고 기존의 파일에 내용을 삭제하면 (DELETE) deletion vectors가 있어서 OPTIMIZE를 통해서 주기적으로 정리가 필요합니다.

What are deletion vectors? | Databricks Documentation

Learn how Databricks leverages deletion vectors to accelerate deletes and updates to data stored in Delta tables.

docs.databricks.com

OPTIMIZE와 VACCUM을 하지 않으면 변경 후의 오래된 파일이 계속해서 남아 있어서 저장소의 낭비를 불러옵니다. 그렇기 때문에 주기적으로 작업을 수행해야지 저장소 공간의 낭비와 성능을 향상할 수 있습니다. 관련하여 제가 예전에 작성 한 글을 참고하면 도움이 될 것 같습니다.

[Databricks] Optimize / VACUUM

burning-dba.tistory.com

추가적으로 OPTIMIZE를 하면서 Z-ORDER를 하는 경우도 있는데, 이 부분에 대해서는 현재 수행하고 있지 않습니다. 저희가 사용하는 데이터 패턴상 큰 이점이 없어서 (실제로 성능 향상 효과 크지 않음) Z-ORDER를 작업하는 공수가 더 큰 것으로 판단되어서 해당 작업을 하지 않고 있습니다.

4. Partition / liquid clustering

이 부분도 3번만큼 중요한 작업으로 알고 있습니다. Partition과 luquid clustering 을 통해서 실제 물리적인 읽는 비용을 감소시키고 성능을 올려서 그만큼 작업의 효율을 증대시키고 작업 시간을 효율화시키고 비용을 감소시키는 효과를 볼 수 있습니다.

Partitions | Databricks Documentation

Learn about table partitions in Databricks SQL and Databricks Runtime.

docs.databricks.com

Use liquid clustering for Delta tables | Databricks Documentation

Learn how Delta Lake liquid clustering works to simplify data layout decisions and accelerate data access.

docs.databricks.com

2가지를 섞어서 사용은 불가능 하지만 (둘중 하나만 선택 가능) 각자의 상황에 맞게 적용하여 사용이 필요합니다. (제가 알고 있기에 2개는 함께 적용이 불가능합니다.) 지금 제가 주로 사용하는 테이블의 경우 Partition을 적용하여 사용하고 있으며 둘 중에 무엇이 낫다고 말하기보다는 데이터를 쌓는 방식과 주로 사용되는 사용성을 확인해서 걸어야 할 것 같습니다. 또한 데이터의 성격 (카디날리티와 같은...)에 따라서 역시 무엇을 주력으로 사용할지 결정이 필요할 것 같습니다.

관련해서는 곧 성능을 비교하는 내용을 작성 해보고자 합니다.

마치며

어느덧 10개월정도 Databricks를 사용하다 보니 무엇을 해야 하는지 감을 잡아가는 것 같습니다. 아직 많이 부족하지만 어느 정도 구색(?)을 갖춘 데이터 환경을 구축하였고 많은 사용자가 해당 환경을 사용함에 있어서 뿌듯함을 느낍니다. 계속해서 사용자를 늘리면서 겪는 문제와 데이터의 크기와 다양성이 증가하면서 겪는 문제에 대해서 글을 추가적으로 작성하도록 하겠습니다.

감사합니다.

[Databricks] targetFileSize 테이블 옵션

주형권 — Wed, 30 Apr 2025 11:10:08 +0900

안녕하세요.

테이블 옵션에 관해서 처음 글을 쓰는 거 같네요. Databricks에는 여러 가지 자동으로 최적화해주는 옵션이 있지만 해당 옵션을 추가하여 Small 파일을 방지하고 성능을 향상할 수 있을 것 같습니다. 실제로 파일의 개수가 1/2 가량 줄어드는 것을 보았고, KB의 파일들이 모여서 MB로 변경되는 것을 눈으로 직접 확인하였습니다.

제가 알고 있기로 Databricks에는(아니면 delta 옵션 일수도?) 다음과 같이 파일에 관련하여 옵션을 제공 합니다. 제가 아는 건 2개 정도였는데요. 이미 테이블에 옵션을 적용해 놨습니다.

delta.autoOptimize.autoCompact
delta.autoOptimize.optimizeWrite

데이터 파일 크기를 제어하도록 Delta Lake 구성 - Azure Databricks

대상 파일 크기를 수동으로 제어하거나 Delta Lake로 파일 크기 자동 튜닝을 구성합니다.

learn.microsoft.com

실제로 위의 2개의 옵션으로 인해서 최적의 파일 크기를 조정해서 저장소에 저장 하는것으로 보입니다. 해당 옵션을 보고 크기가 매우 크고 중요한 테이블이 옵션을 적용하였는데, 생각보다 KB의 파일이 있어서 어쩔 수 없이 (파일을 나누다 보니 남는 데이터들?) 파일을 저렇게 저장하는구나 싶었습니다.

그래서 찾던 와중에 delta.targetFileSize 이라는 옵션을 찾았고, 해당 옵션을 적용하였는데 실제로 큰 효과를 봤습니다. 이 내용을 들어가기 앞서 왜 Small 파일이 성능에 안 좋은 영향을 미치는지 간단하게 그림으로 그려봤습니다.

Small 파일이 좋지 않은 이유?

예를 들어서 우리가 아이스크림을 퍼서 먹는다고 가정 하겠습니다. 아이스크림은 아주 작은 용기에 담겨 있습니다. 이 용기에서 아이스크림을 퍼야 합니다. 그런데 우리에게는 국자 크기의 수저밖에 없습니다.

파일이 작을때

위의 그림을 보면 작은 단위로 나눠져 있기 때문에 옮길 수 있는 크기는 크지만 8번을 옮겨야 합니다. 파일의 크기(아이스크림)가 작기 때문에 한 번에 읽을 수 있는 크기를 여러 번 옮겨야 합니다.

파일이 클때

하지만 파일의 크기(아이스크림의 크기)가 크면 한번에 옮기는 양도 많아지므로 국자 크기에 딱 맞게 옮길 수 있습니다. 그렇기 때문에 작업의 횟수가 줄어듭니다. 이게 파일을 읽는 횟수를 크게 줄여서 그만큼 더 이점이라고 볼 수 있습니다. 여러 가지 더 좋은 부분이 있겠지만 제가 알기로 가장 큰 이점이 이것으로 알고 있습니다.

실제 적용 후 비교

적용 테이블의 크기는 약 4.5TB였으며, 파일의 앞서 말씀드린 옵션이 2가지가 모두 적용 되었습니다. 해당 테이블의 경우 월별로 파티션이 걸려 있습니다. 이외의 몇 가지 옵션이 더 걸려 있지만 다른 옵션은 파일의 크기에 큰 상관이 없는 것으로 알고 있으므로 공유하지 않겠습니다.

일단 가장 중요한 파일의 개수는 다음의 구문으로 확인 하였습니다.

describe detail 테이블명

다음과 같이 검색하면 numFiles라는 칼럼이 나오는데, 해당 칼럼으로 파일의 개수를 확인 가능 합니다. 해당 옵션을 적용하는 구문은 다음과 같습니다.

ALTER TABLE 테이블명
SET TBLPROPERTIES (delta.targetFileSize = '1048576000')

위의 수치는 byte이며, 1GB가 parquet 파일의 최적의 파일 크기로 공식 문서에 언급되어 있어서 1GB로 설정하고자 하였습니다.

targerFileSize 설명

옵션을 적용하고 꼭 OPTIMIZE를 해줘야 합니다. OPTIMIZE를 해주면 파일을 다시 최적으로 쓰기 시작합니다. OPTIMIZE는 시간이 조금 걸리니 꼭 다른 작업을 피해서 수행해주셔야 합니다.

테이블의 파일은 실행 전에 약 13,000개에서 약 7,000개로 거의 1/2 수준으로 줄어들었습니다. 실제로 파일의 크기가 KB 단위가 없어졌습니다. 적용한 시간이 그리 오래되지 않아서, 성능에 대한 체감과 정확한 비교를 하지는 못하였으나 이후에 성능에 대해서 굉장히 기대됩니다.

주의 사항

1. LOCK이 걸립니다.

해당 옵션은 LOCK에 걸립니다. DELETE 나 UPDATE와 OPTIMIZE와 같은 작업을 하는 도중에 해당 옵션을 설정하면 LOCK으로 작업이 실패할 수 있습니다. 아래의 문구와 같이 나오면서 해당 작업이 실패 할 수 있으니 다른 작업이 있을 때는 해당 옵션을 걸지 않는 게 좋습니다. 작업이 끝난 후에 걸도록 해야 합니다.

[DELTA_METADATA_CHANGED] MetadataChangedException: The metadata of the Delta table has been changed by a concurrent update. Please try the operation again.

2. 설정한 파일 크기만큼 필수적으로 파일을 만들지 않습니다.

파일의 크기를 1GB로 설정하였으나 다른 옵션들로 인해서 최적의 파일 크기로 Databricks가 설정하는 것으로 보입니다. 그래서 파일의 크기를 실제로 저장소에서 확인하면 1GB가 아닌 경우가 있습니다.

구글링 해보니 비슷한 질무을 한 사람들이 좀 있는데 당황하지 마시고, 최적화 상에서 이렇게 판단하여한 것으로 보입니다. (댓글 상으로는...) 그러니 내가 설정한 크기로 안된다고 너무 당황하지 않으시길 바랍니다.

감사합니다.

[Databricks] S3에 있는 파일을 테이블 처럼 읽기

주형권 — Fri, 25 Apr 2025 08:15:50 +0900

안녕하세요.

Databricks로 데이터 파이프라인을 만들고 있는데, 좋은 기능이 있어서 글을 씁니다. Databricks에서 주로 파일을 읽을 때 워크스페이스(노트북) 환경에서 데이터프레임을 만들어서 이것을 APPEND 또는 OVERWRITE 하는 방식으로 작업하시는 분들이 많은데요. 이럴 경우 데이터프레임이 용량의 제한이 있어서 OOM이 생길 수 있습니다.

그래서 혹시 바로 읽을 수 있는 방법이 없을까 하였는데, 찾아보면 대부분이 External tables를 추천 합니다. 그런데 External Table을 만들려면 스키마 형태를 알아야 하기 때문에 굉장히 곤욕입니다. 스키마가 너무 많거나 하나씩 열거하기 어려우면 이 방법 또한 굉장히 번거롭습니다.

그래서 찾아보다가 S3에 있는 파일을 그대로 읽어서 보여주는 문법을 찾았습니다. 문법은 SQL이며, Databricks 환경에서 잘 작동합니다.

SELECT * 
FROM parquet.`S3파일 위치`

구문이 굉장히 심플 합니다. 제가 지금 가지고 있는 파일은 parquet라서 parquet로 설정하였고, 찾아보니 CSV도 가능한 것으로 보입니다. 이 구문으로 읽어서 다음과 같이 테이블을 생성할 수도 있습니다.

CREATE TABLE a
SELECT * 
FROM parquet.`S3파일 위치`

추가적으로 여러 파일을 한번에 읽기도 가능하여, * 도 가능 합니다. 예를 들면 2025/04/25/ 아래의 모든 파일을 읽고자 한다면 다음과 같이 할 수 있습니다.

SELECT * 
FROM parquet.`S3명/2025/04/25/*`

정상적으로 잘 작동하며, 읽는데 그리 오래 걸리지도 않습니다. 아래의 스펙으로 테스트를 하였을 때 다음과 같은 결과가 나왔습니다.

Driver / Worker 스팩 같음
- Worker 최대 10개
파일 크기 : 24GB
파일 개수 : 2,311개

위의 테스트 데이터를 읽어서 새로운 테이블을 만드는 시간을 총 22분 46초가 걸렸습니다. 아마도 파일 개수가 더 적고 파일의 크기가 컸다면 더욱 빠른 성능을 기대할 수 있었을 것입니다. 대규모 파이프라인에서는 이 방법이 좋지 않을 수 있겠으나, 소규모의 파이프라인의 경우 이 방법이 굉장히 유용할 것으로 보입니다.

감사합니다.

[Databricks] DELTA_DELETION_VECTOR_SIZE_MISMATCH

주형권 — Fri, 28 Feb 2025 19:34:35 +0900

This time, I wrote this article after experiencing a very big(?) problem. It was my first time experiencing a problem while using Databricks, and above all, I had a very hard time resolving it because there was no related information.

To conclude, it was a bug in Databricks. In the end, I opened a CASE and the backend engineer at the headquarters resolved the problem.

⚠️ Problem found

We have a task that does DELETE. But one day, the following ERROR occurred and the DELETE failed. The message is as follows:

[DELTA_DELETION_VECTOR_SIZE_MISMATCH]
Deletion vector integrity check failed. Encountered a size mismatch.

First, I instinctively googled, tried various measures, and even asked the AI provided by Databricks about the problem. In the end, it was said to do REFRESH TABLE, and after executing it, I executed DELETE again, but it did not work due to the same problem.

️ Symptoms

Here is a list of symptoms. Some were possible, some were not. Some were only partially possible.

⛔ DELETE impossibility
⚠️ SELECT impossibility
⛔ OPTIMIZE impossibility
✅ INSERT possibility
✅ vacuumpossibility

And there was also an ERROR message that said there was a problem reading the file, so I found the file, downloaded it, and read it directly, but there was no problem at all. In conclusion, it did not seem to be a problem with the file.

Conclusion

And as for the ERROR message, it was a problem that could not be solved in conclusion. Databricks admitted it was a bug, and after fixing it, I confirmed that everything was working normally. In the end, after struggling for 3~4 days, I opened the CASE, and it said it was a bug right away, so I was a little... discouraged. So if there is no Google or documentation, don't worry and open the CASE. There was also an article that said there was a problem reading this file, so I looked for the file, downloaded it, and read it directly, but there was no problem at all. In conclusion, it didn't seem to be a file problem.

[Databricks] DELTA_DELETION_VECTOR_SIZE_MISMATCH

주형권 — Thu, 27 Feb 2025 16:14:56 +0900

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

이번에 아주 커다란(?) 장애를 겪고 글을 작성하였습니다. Databricks를 쓰면서 처음 겪는 장애였고, 무엇보다 관련 자료가 전무한 상황이라서 굉장히 해결에 어려움을 겪었습니다. 결론부터 말씀 드리면 Databricks의 버그입니다. 결국 CASE를 열어서 본사의 Back-end 엔지니어가 장애를 해결해줬습니다.

⚠️ 문제 발견

저희는 DELETE를 하는 작업이 있습니다. 그런데 어느 날 다음의 ERROR가 나오면서 DELETE가 실패하는 증상이 나타났습니다. 메시지는 다음과 같습니다.

[DELTA_DELETION_VECTOR_SIZE_MISMATCH]
Deletion vector integrity check failed. Encountered a size mismatch.

일단 본능적으로 구글링을 하였고, 여러 가지 조치가 있었으며, Databricks에서 제공하는 AI에게도 문제에 대해서 물어봤습니다. 결국은 REFRESH TABLE을 하라는 이야기였고, 실행 후 다시 DELETE를 실행하였으나 똑같은 문제로 동작하지 않았습니다.

️ 증상

증상을 나열하면 다음과 같습니다. 가능한 것도 있고 안 되는 것도 있었습니다. 또한 일부만 되는 것도 있었습니다.

⛔ DELETE 불가능
⚠️ SELECT는 가능 하지만 일부만 가능 (Limit 100과 같은...)
⛔ OPTIMIZE 불가능
✅ INSERT 가능
✅ vacuum 가능

그리고 ERROR 메시지에서 다음과 같이 파일을 읽는데 문제가 있다는 내용도 있어서 해당 파일을 찾아서 다운로드 후 직접 읽어 보았으나 문제가 전혀 없었습니다. 결론적으로 파일의 문제는 아닌 것으로 보였습니다.

결론

결론적으로 해결이 불가능한 문제였습니다. Databricks에서 버그라고 인정했고, 수정해준 뒤에 모두 정상적으로 동작하는 것을 확인하였습니다. 결국은 3~4일 정도 삽질 하다가 CASE를 열었는데, 바로 버그라고 해서 조금... 맥이 빠졌습니다. 그래서 구글링이나 문서가 딱히 없는 경우는 고민하지 마시고 CASE를 오픈하는 것도 좋은 방법으로 보입니다.

[공통] 데이터엔지니어 하면서 테스트 하는 방법

주형권 — Mon, 20 Jan 2025 08:55:18 +0900

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

회사에서 파트장을 맡으면서 파트원들에게 이것저것 알려주다 보니 많은 생각이 들었습니다. 내가 처음에 회사를 들어왔을 때 누군가에게 배웠다기보다는 어깨 너머로 스스로 배웠다고 생각했던 것들이 많은데 요즘은 이게 어려운 거 같습니다. 워낙에 각자도생의 시대이고 서로 협업보다는 경쟁을 부 축이는 사회라서 그런지 세세하게 알려주거나 공유하는 문화가 거의 없다 보니 연차가 꽤 있음에도 제 생각엔 기본이라고 생각하는 것들을 모르는 경우가 많습니다.

그래서 오늘은 그중에 하나인 테스트 하는 방법에 대해서 말씀 드리려고 합니다. 이 내용은 데이터엔지니어에 관련해서 제가 하는 방식을 그대로 적은것으므로 각자의 방법이 서로 다를 수 있습니다. 그러므로 본인이 하는 방법이 틀린 것은 아니고 이제 막 시작 하거나 테스트를 어떻게 해야 할지 막막한 분들에게 많은 도움이 되었으면 합니다.

이 글에서는 데이터에 어떠한 조작이나 데이터를 이용한 테스트에 관한 글이며 여러가지 운영적인 테스트보다는 데이터 중점으로 글을 작성하였으므로 이점 참고 부탁 드립니다.

Step 1. 샘플 데이터 만들기

우선 테스트를 하기 위해서는 샘플 데이터를 만들어야 합니다. 샘플 데이터를 만드는 이유는 대부분의 데이터 엔지니어는 관리자 권한을 가지고 있기 때문에도 있고 실제 데이터를 사용할 경우 크기가 크기 때문에 컴퓨팅 자원이나 속도 측면에서 무언가를 하기가 어려울 수 있기 때문입니다.

샘플 데이터는 주로 데이터엔지니어만 쓰는 공간에 만들어서 사용 하는게 좋습니다. 공용 공간에 넣어서 사용할 경우 사람들이 잘못 사용해서 잘못된 결과를 보고 오판을 하거나 할 수 있고 추후에 DROP 테이블이나 파일을 지우다 잘못 지우는 경우 복잡한 문제가 발생합니다. 그렇기 때문에 격리된 공간에서 샘플 데이터를 만들어서 테스트를 해보시는 것을 추천드립니다.

테이블이 아닌 파일의 경우도 S3에서 Bucket을 새로 만들거나 폴더를 분기해서 완전히 격리된 공간에서 하는 것을 추천 드립니다. 이 부분도 위와 마찬가지로 사용자가 볼 수 없는 별도의 공간이 제일 좋습니다. 결국 중요한것은 어떠한 샘플을 만들든 격리된 공간에 만들고 관리자(데이터엔지니어)만 접근이 되는 또는 개인만 접근이 되는 환경에서 하는 게 가장 좋습니다.

Step 2. 로직 테스트

샘플을 만들었으니 로직을 샘플에 녹여서 테스트를 합니다. SELECT와 같이 조회를 테스트 하는 경우는 큰 이슈가 없으나 아무리 샘플이라도 데이터가 변경되는 경우는 샘플을 무제한으로 찍을 수 없기 때문에 번거로움이 있습니다. 그래서 테스를 할 때는 다음과 같이 살짝 바꿔서 할 수 있습니다.

INSERT

결국 데이터가 잘 들어가는지를 테스트 하기 때문에 껍데기만 그대로 복사해서 데이터가 잘 적재되는지 테스트할 수 있습니다. INSERT를 테스트하는 경우는 보통 해당 테이블에 구문 오류 또는 데이터 타입이 정상적으로 들어와서 문제가 없이 적재가 되는지를 주로 테스트하기 때문에 껍데기만 복사해서 잘 적재되는지만 볼 수 있습니다. 즉, 샘플 데이터를 만들지 않고 할 수도 있습니다.

DELETE

DELETE를 SELECT로 바꿔서 테스트 해볼 수 있습니다. 우선 샘플을 만들고 이 샘플에 DELETE FROM 이 아니고 SELECT FROM으로 구문을 실행합니다. 구문을 실행하면 실제 지워지는 대상자를 알 수 있고 추가적으로 소요되는 시간을 알 수 있습니다. DELETE를 하는 게 결국 SELECT를 해서 지우는 것이므로 이 부분도 함께 테스트를 할 수 있습니다. (물론 다릅니다. 짐작이 된다는 것이지요.)

UPDAETE

샘플 데이터를 굉장히 소수 (10건 정도)만 복사해서 사용하고 특정 조건으로 UPDATE가 잘되는지 볼 수 있습니다. 결국은 UPDATE의 경우 이미 있는 데이터를 바꾸는 작업이므로 이 데이터가 내가 원하는 모양으로 잘 바뀌는지에 대한 테스트가 주 입니다. 그래서 굉장히 작은 샘플을 복사해서 테스트하고 TRUNCATE 후 다시 복사해서 하고 여러 번 반복해서 해보고 하는 방법이 좋다고 봅니다.

SELECT

데이터를 조작하는 것이 아니지만 하실때 파티션, PK, 옵션등 테이블에 설정에 따라서 차이가 굉장히 심하게 나타나므로 이점을 확실히 실서버와 비슷하게 만들어서 해야 합니다. 실제로 그 양이 크지 않으면 샘플을 만들지 않고 실제 데이터를 가지고 하는 경우도 있지만 RDBMS의 경우 Lock이 발생하는 경우도 있고 자원을 독점해서 다른 작업에 지장을 줄 수 있기 때문에 별도의 공간에서 해도 좋다고 생각됩니다.

Step 3. 데이터 확인하기

당연한 이야기지만 테스트 후에 데이터 검증은 필수입니다. SELECT의 경우 자연스럽게 가능하겠지만 나머지 조작이 수반되는 데이터 테스트는 무조건 검증이 필요합니다. 검증을 하는 방법은 여러 가지 있는데요. 제가 생각나는 부분에 대해서 적어 보겠습니다.

1. ORDER BY를 통한 검증

주로 날짜 데이터를 통해서 특정 일자를 업데이트하는 경우가 많습니다. 그렇기 때문에 해당 일자만 정상적으로 반영되었는지 확인하기 위해서는 ORDER BY의 ASC / DESC를 통해서 해당 일자의 값이 정상적으로 변경되었는지 알 수 있습니다. 데이터를 변경하고 WHERE 후에 ORDER BY로 해당 날짜로 정렬하면 값의 변화를 쉽게 알 수 있습니다.

2. 특정 값 조회 해보기

샘플 검증이라고 표현하면 좋을 거 같습니다. 내가 100명의 유저를 대상으로 업데이트를 진행했다고 가정하겠습니다. 그렇다면 내가 데이터를 조작했던 조건(WHERE) 값을 몇 개 샘플링해서 SELECT 해보고 실제로 변경이 잘 이루어졌는지 볼 수 있습니다. 특정 유저의 값을 따라가면서 하나씩 볼 수도 있습니다.

3. DELETE 전에 SELECT로 대상자 확인

앞서 언급하였던 DELETE 부분의 내용입니다. DELETE를 할 때 아마도 WHERE에 특정 조건을 삭제하려고 하는 경우가 많습니다. 그렇기 때문에 DELETE -> SELECT로 변경하고 조건(내가 원하는 대상)이 맞는지 대상 Raw를 확인할 수 있습니다.

4. 건수 체크

데이터를 ETL / ELT 하는 파이프라인을 구현할 때 건수가 정확히 원본 데이터와 맞는지 검사하여 기본적인 검사를 할 수 있습니다. 건수가 정확히 맞으면 일단 넘어온 것은 맞으므로 간단하게 검증이 가능합니다. 실제로 여러 가지 오류로 인해서 데이터가 깨져서 안 들어오거나 줄 바꿈 연산자 같은 기호 때문에 뻥튀기되어서 들어오는 경우도 많습니다.

5. 중복 체크

전부는 아니지만 RDBMS 같은 정형 데이터의 경우 고유 값이 있습니다. 로그 번호 같은 숫자값이 있으면 베스트하고 유저 테이블을 가져올 때는 유저의 고유 값이 있기 마련입니다. 하지만 우리가 사용하는 분산처리 환경의 경우 PK를 지원하지 않는 경우가 많습니다. (있어서 유니크 값이 아닌 경우도 많음) 그렇기 때문에 중복으로 데이터가 적재되지 않았는지 GROUP BY와 HAVING을 통해서 검증이 가능합니다.

Step 4. 소요시간 계산하기

소요시간의 경우 보통 산술적인 수치로 계산해야 합니다. 예를 들면 내가 실제 데이터의 10%를 샘플로 만들었다고 예를 들어 보겠습니다. 10%의 샘플 데이터가 소요시간이 1분이 걸렸다고 가정하면 이를 단순히 1분 * 10을 해서 10분이라고 산술적으로 예상할 수 있습니다. 이외에 조금의 예외 사항이 있기 때문에 *20%를 하면 조금 더 좋다고 생각합니다.

물론 이건 어디까지나 산술적 수치이므로 정확하다고 볼 수 없습니다. 특히 분산처리 환경에서는 옵티마이저(계산하는 놈으로 생각하시면 됩니다.)가 판단할 때 작은 크기와 큰 크기는 엄청나게 다르게 계산하므로 대부분 맞진 않습니다. 그러므로 20% 정도 더 소요시간을 가중해서 계산하였습니다. 그리고 오히려 최대한 크게 잡아서 산정하고 더 빨리 끝난다면 더 좋으므로 최대한 모든 상황을 감안해서 길게 잡기를 권장합니다.

그렇다고 10분짜리를 100분으로 계산하면 너무 오래 걸리므로... 적당한 판단이 중요합니다. 아마도 많은 작업을 하다 보면 아 이 정도면 끝나겠다. 싶은 감이 생깁니다.

Step 5. 비용 계산하기

테스트를 할 때는 비용이 빠질 수 없습니다. 주로 샘플 데이터를 가지고 하였으므로 이 크기를 실제 데이터의 크기와 비교해서 역산하여하는 게 좋습니다. 예를 들면 실제 데이터의 1/10로 테스트를 하였는데 총비용이 100원이면 이를 100 * 10으로 계산하여 할 수 있습니다. 물론 컴퓨팅이 크면 클수록 돈이 더 많이 들기 때문에 그 계산은 쉽지 않습니다.

그래서 많은 밴더사들이 수많은 계산기를 지원합니다. 계산도 쉽고 빠르게 가능하고 편하게 할 수 있습니다. 제가 알고 있는 사이트 몇 개를 추천드립니다. 아래의 사이트는 AWS와 Databricks용입니다. (제가 지금 주로 해서...)

Pricing Calculator (가격 계산기) | Databricks

Databricks에 대한 가격 책정 세부 정보를 참조하세요. 이 예측 도구를 사용하여 Databricks가 다양한 워크로드에 대해 요금을 청구하는 방법을 이해합니다. 무료로 사용해 보세요. 선결제 비용이 없

www.databricks.com

Amazon EC2 Instance Comparison

instances.vantage.sh

[Databricks] 여러 폴더를 외부(external) 테이블로 만들기

주형권 — Thu, 26 Dec 2024 14:44:10 +0900

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

Databricks에서는 다양한 테이블을 만들 수 있습니다. 외부(external) 테이블도 그중 한 가지입니다. 외부 테이블은 csv / json / parquet 등의 데이터를 그대로 Databricks에서 볼 수 있도록 만들어 줍니다. 그래서 Delta로 만드는 수고를 덜어줘서 굉장히 많이 쓰이는 기술입니다.

⚠️ 무엇이 문제였는가?

Databricks에서 외부 테이블을 만들때 하위의 모든 폴더를 포함해서 하나의 테이블로 만들고자 할 때는 잘 안됩니다. 특정 폴더 안에 모든 파일이 있으면 모르겠지만 YYYY/MM/DD와 같이 폴더가 년/월/일로 구분이 되어 있고 이 폴더를 모두 포함해서 하나의 테이블로 만들려고 하면 정상적으로 되지 않습니다.

CREATE TABLE sandbox.z_hkjoo.test_joo
(
  date string
  ,user_key int
  ,user_name string
)USING PARQUET
LOCATION  's3://bucket_name/2024/'

2024년의 모든 월/일을 포함해서 테이블을 만들려고 하면 위와 같이 보통 만듭니다. 그럼 하위의 모든 폴더를 읽어서 테이블로 만든다고 생각이 들지만 그렇지 않습니다. 실제로 테이블은 만들어집니다. 하지만 아무런 값이 없습니다. 아마도 제 생각엔 2024년 폴더 아래에 있는 parquet 파일만 인식하고 폴더를 인식하지 못하는 것으로 보입니다.

그래서 다음과 같이 *을 넣어서 Query를 만들었는데 다음과 같은 오류가 나옵니다.

CREATE TABLE sandbox.z_hkjoo.test_joo
(
  date string
  ,user_key int
  ,user_name string
)USING PARQUET
LOCATION  's3://bucket_name/2024/*'

오류 내용만 보면 S3에 권한이 없다고 보입니다. 하지만 저는 어드민인데요...? 권한 정상입니다.

실제로 이 내용을 검색하면 권한을 주라고 나오는 답변이 굉장히 많습니다. 그런데 이 문제가 전혀 아닙니다. 물론 권한 문제일 수 있으니 꼭 권한을 체크해 주시기 바랍니다.

✔️ 해결방법

해결방법은 의외로 간단 하였습니다. 옵션 한 줄을 추가하면 됩니다.

CREATE TABLE sandbox.z_hkjoo.test_joo
(
  date string
  ,user_key int
  ,user_name string
)USING PARQUET
OPTIONS (recursiveFileLookup "true")
LOCATION  's3://bucket_name/2024/'

OPTIONS (recursiveFileLookup "true") 옵션을 넣으면 하위의 모든 폴더를 읽어서 하나의 테이블로 만들 수 있습니다. 이외에도 여러 가지 옵션이 있는 것으로 보이는데 찾아보니 공식문서에 내용이 없는 거 같습니다. (제가 못 찾았을 수도...?) 옵션을 정리한 곳이 있으면 제보 좀 부탁드립니다.

참고

Create (CSV) External Table From Multiple Files in Sub-directories

Let's say I have a dataset that is ingested on a daily basis and placed within a timestamped sub-directory in a particular location in my data lake (Azure Data Lake Storage). The directory structur...

stackoverflow.com