Databricks 모니터링 가이드, 시스템 테이블과 실시간 알림을 어떻게 나눠 쓸까

시스템 테이블이 보여주는 범위와 한계

시스템 테이블은 Databricks의 성능, 비용, 사용량 분석에서 1차 자료 역할을 합니다. 감사 로그, 비용 기록, 성능 지표, SQL 웨어하우스 이벤트까지 폭넓게 담고 있는데요. 하지만 원문에서 분명히 짚듯이 이 데이터는 실시간이 아니고 스키마별로 지연 시간이 다릅니다. 그래서 분 단위로 즉각 반응해야 하는 알림 용도로는 적합하지 않아요. billing 스키마는 기본 활성화돼 있어서 system.billing.usage로 모든 과금 대상 사용량을 바로 조회할 수 있지만, 나머지 시스템 테이블 스키마는 수동으로 활성화해야 한다는 점도 실무에서 놓치기 쉬운 부분입니다.

컴퓨팅, 작업/파이프라인, 쿼리 모니터링

컴퓨팅 쪽은 system.compute.clusters, system.compute.node_timeline, system.compute.warehouse_events 같은 테이블이 클래식 컴퓨트와 서버리스 컴퓨트, SQL 웨어하우스를 모두 커버합니다. 클래식 컴퓨트 클러스터는 모니터링 에이전트로 수집해 외부 저장소로 보낼 수 있고, Spark UI에서는 DAG 시각화, skew/spill/shuffle 지표, JVM 스레드 덤프, 드라이버/익스큐터 로그까지 확인할 수 있어서 느린 작업 트러블슈팅에 특히 유용합니다. 작업과 파이프라인은 system.lakeflow.* 테이블이 작업/태스크 정의와 실행 타임라인을 제공하는데, 이것도 실시간이 아니라서 실패 알림은 Databricks 내장 작업 알림을 Slack, Microsoft Teams, PagerDuty, HTTP webhook으로 연결해 받아야 합니다. 쿼리 성능은 system.query.history 테이블과 Databricks UI의 쿼리 히스토리 페이지, 서버리스 쿼리용 query insights로 세분화해서 들여다볼 수 있어요.

데이터 품질, 계보, Model Serving 모니터링

데이터 품질은 Unity Catalog의 데이터 프로파일링과 Data Quality Monitoring UI로 완전성, 최신성 같은 지표를 추적하고 SQL 알림을 걸 수 있습니다. system.access.table_lineage와 system.access.column_lineage는 계보 이벤트를 1년 롤링 윈도우로 보관하고, Catalog Explorer는 계보 데이터를 무기한 보관합니다. Spark 레벨 계보 메타데이터까지 필요하면 클래식 컴퓨트 클러스터에 OpenLineage Spark 통합을 설치해 Marquez 같은 오픈소스 도구나 Datadog으로 시각화할 수 있어요. Model Serving은 엔드포인트 헬스 지표를 OpenMetrics 포맷으로 노출하기 때문에 Prometheus, Datadog 등 OpenMetrics 호환 에이전트로 실시간 요청 수, 에러 수, 지연 시간, 컴퓨트 사용량을 추적할 수 있습니다. Databricks Serving UI에서는 최근 14일치 헬스 지표를 볼 수 있고, 서비스 로그는 휘발성이지만 빌드 로그는 최대 30일 보관됩니다.

실무 적용 체크리스트

Unity Catalog로 접근 권한을 위임해 시스템 테이블을 활성화하면 Databricks UI뿐 아니라 외부 모니터링 도구도 Databricks SQL API로 데이터를 끌어와 분석할 수 있습니다. 운영 환경을 설계할 때는 시스템 테이블을 비용/성능/사용량 분석과 대시보드용으로, 작업 알림과 Jobs API와 호스트 기반 에이전트를 실시간 알림용으로 역할을 나눠 조합하는 게 핵심입니다. 데이터 품질과 계보 추적은 시스템 테이블 분석과 Catalog Explorer 시각화를 함께 쓰고, Model Serving 엔드포인트는 OpenMetrics 엔드포인트와 inference 테이블을 같이 활성화해 성능 분석과 LLM judges/scorers를 함께 운용하는 방식을 검토해보세요. 다음 편에서는 Datadog의 Databricks 통합과 Data Observability: Jobs Monitoring을 다룰 예정이라고 합니다.

자주 묻는 질문

마케팅 자동화 란 무엇이고 Databricks와 무슨 관련이 있나요

마케팅 자동화는 반복되는 마케팅 업무를 도구로 자동 실행하는 체계를 말하는데, 이번 글 자체는 마케팅 자동화가 아니라 Databricks 데이터 엔지니어링 파이프라인의 모니터링을 다룹니다. 다만 마케팅 데이터 파이프라인이 Databricks 위에서 돌아간다면 이 시스템 테이블 구조를 그대로 참고할 수 있습니다.

bigquery 란 무엇이고 Databricks와 어떻게 다른가요

BigQuery는 Google Cloud의 서버리스 데이터 웨어하우스이고 Databricks는 Apache Spark 기반의 데이터 레이크하우스 플랫폼이라는 점에서 성격이 다릅니다. 이번 원문은 BigQuery를 다루지 않고 Databricks 자체 모니터링 리소스에 집중합니다.

Databricks 시스템 테이블은 실시간 알림에 쓸 수 있나요

아니요, 원문에서 명확히 설명하듯 시스템 테이블 데이터는 실시간이 아니고 스키마마다 지연 시간이 다릅니다. 즉각적인 알림이 필요하면 작업 알림, Jobs API 쿼리, 호스트 기반 텔레메트리 에이전트를 함께 써야 합니다.

Databricks 모니터링 툴 중 어떤 것부터 활성화해야 하나요

billing 스키마는 기본 활성화돼 있어 바로 비용 데이터를 조회할 수 있고, 나머지 스키마(compute, query, lakeflow 등)는 Unity Catalog를 통해 수동으로 활성화해야 합니다. 모니터링 목적에 맞춰 필요한 스키마를 선택적으로 켜는 방식이 적절합니다.