마지막 업데이트: 2026년 3월 | 대상: 데이터 엔지니어, 플랫폼 엔지니어, 데이터 아키텍트
Databricks 플랫폼을 운영하다 보면 "지금 우리 클러스터는 얼마나 쓰고 있지?", "저 사람이 어떤 테이블에 접근했지?", "이 파이프라인이 왜 이렇게 느리지?"라는 질문이 자연스럽게 나온다. 이런 운영 관찰(operational observability) 문제를 SQL 한 줄로 해결해 주는 것이 System Tables다.
1. System Tables란?
System Tables는 Databricks가 호스팅하는 분석용 운영 데이터 저장소다. Unity Catalog의 system 카탈로그 하위에 위치하며, 계정 전체의 활동 이력을 Delta 형식으로 제공한다. 중요한 특징은 다음과 같다.
- 읽기 전용(read-only): 데이터를 직접 수정하거나 삭제할 수 없다.
- Delta Sharing 기반: Databricks가 내부 스토리지에 데이터를 저장하고 Delta Sharing 프로토콜로 각 테넌트에게 공유한다.
- 스트리밍 지원: 대부분의 테이블이 Spark Structured Streaming의 소스로 사용 가능하다 (
skipChangeCommits=true필수). - 무료 보존 기간: 대부분 365일치 데이터를 비용 없이 조회할 수 있다 (GA 테이블 기준).
-- System Tables에 접근하려면 Unity Catalog 활성화 필수
GRANT USE SCHEMA ON SCHEMA system.billing TO `data-team@company.com`;
GRANT SELECT ON TABLE system.billing.usage TO `data-team@company.com`;2. Unity Catalog 내 계층 구조
System Tables는 Unity Catalog의 3단계 네임스페이스(catalog.schema.table) 최상위에 있는 system 카탈로그에 위치한다.
system (카탈로그)
├── access (접근 로그 & 리니지)
├── billing (비용 & 사용량)
├── compute (클러스터 & 웨어하우스)
├── lakeflow (잡 & 파이프라인)
├── marketplace (마켓플레이스 이벤트)
├── mlflow (ML 실험 & 런)
├── query (쿼리 히스토리)
├── serving (모델 서빙)
├── storage (예측 최적화)
└── sharing (Delta Sharing)아래는 Databricks 공식 문서에서 제공하는 시스템 테이블 간의 Entity Relationship Diagram이다. 각 테이블의 Primary/Foreign Key 관계를 한눈에 볼 수 있다.
3. 주요 스키마별 테이블 상세
3-1. system.billing — 비용 분석의 핵심
| 테이블 경로 | 설명 | 보존 기간 |
|---|---|---|
system.billing.usage | 계정 전체 청구 가능 사용량 기록 | 365일 |
system.billing.list_prices | SKU별 가격 변동 이력 | 무제한 |
system.billing.usage는 글로벌 데이터를 포함하므로 멀티 리전 환경에서도 단일 쿼리로 전체 비용을 집계할 수 있다. sku_name, usage_quantity, usage_unit 컬럼을 활용해 DBU 소비 현황을 제품/팀별로 드릴다운하는 것이 일반적이다.
-- 최근 30일간 워크스페이스별 DBU 소비량 Top 5
SELECT
workspace_id,
sku_name,
SUM(usage_quantity) AS total_dbu
FROM system.billing.usage
WHERE usage_date >= CURRENT_DATE() - INTERVAL 30 DAYS
GROUP BY workspace_id, sku_name
ORDER BY total_dbu DESC
LIMIT 5;3-2. system.access — 감사(Audit) & 데이터 리니지
| 테이블 경로 | 설명 | 보존 기간 |
|---|---|---|
system.access.audit | 워크스페이스 감사 이벤트 전체 기록 | 365일 |
system.access.table_lineage | 테이블 단위 읽기/쓰기 이벤트 | 365일 |
system.access.column_lineage | 컬럼 단위 읽기/쓰기 이벤트 | 365일 |
system.access.workspaces_latest | 계정 내 워크스페이스 메타데이터 | 무제한 |
audit 테이블은 actionName과 requestParams 컬럼을 JSON으로 제공한다. GET_TABLE, CREATE_TABLE, DELETE 등의 이벤트를 추적하거나 특정 사용자의 행동 패턴을 분석하는 데 활용된다.
-- 특정 테이블에 대한 최근 접근 이력 추적
SELECT
event_time,
user_identity.email AS user_email,
action_name,
request_params.table_full_name AS target_table
FROM system.access.audit
WHERE request_params.table_full_name = 'prod.sales.orders'
AND event_date >= CURRENT_DATE() - INTERVAL 7 DAYS
ORDER BY event_time DESC;3-3. system.lakeflow — 잡/파이프라인 모니터링
Lakeflow 스키마는 데이터 엔지니어링 워크플로우를 관찰하기 위한 핵심 스키마다. 현재 6개 테이블이 GA 또는 Public Preview로 제공된다.
| 테이블 경로 | 설명 |
|---|---|
system.lakeflow.jobs | 계정 내 모든 잡 정의 (SCD Type 2) |
system.lakeflow.job_tasks | 잡에 속한 태스크 전체 이력 |
system.lakeflow.job_run_timeline | 잡 런의 시작/종료 시간 추적 |
system.lakeflow.job_task_run_timeline | 태스크 런 단위 시간 및 컴퓨트 리소스 추적 |
system.lakeflow.pipelines | DLT 파이프라인 전체 이력 (SCD Type 2) |
system.lakeflow.pipeline_update_timeline | 파이프라인 업데이트 단위 시간 추적 |
-- 최근 7일간 실패한 잡 런과 소요 시간 분석
SELECT
j.name AS job_name,
r.run_id,
r.result_state,
ROUND((r.period_end_ms - r.period_start_ms) / 60000, 1) AS duration_min
FROM system.lakeflow.job_run_timeline r
JOIN system.lakeflow.jobs j
ON r.job_id = j.job_id
WHERE r.result_state = 'FAILED'
AND r.period_start_ms >= UNIX_MILLIS(CURRENT_TIMESTAMP() - INTERVAL 7 DAYS)
ORDER BY duration_min DESC;3-4. system.compute — 클러스터 & 웨어하우스
| 테이블 경로 | 설명 | 보존 기간 |
|---|---|---|
system.compute.node_timeline | 전체 컴퓨트 리소스의 활용률 메트릭 | 90일 |
system.compute.node_types | 사용 가능한 노드 타입 및 하드웨어 스펙 | 무제한 |
system.compute.warehouse_events | SQL 웨어하우스 시작/중지/스케일링 이벤트 | 365일 |
system.compute.warehouses | SQL 웨어하우스 구성 변경 이력 | 365일 |
node_timeline은 CPU/메모리 활용률 데이터를 제공하므로, 클러스터 오토스케일링 정책을 튜닝하거나 유휴 클러스터를 식별하는 데 유용하다.
3-5. system.query — 쿼리 성능 관찰
system.query.history는 SQL 웨어하우스 및 서버리스 컴퓨트에서 실행된 모든 쿼리 기록을 담는다. 실행 시간, 스캔된 데이터 양, 사용자 정보 등이 포함돼 있어 슬로우 쿼리 탐지나 쿼리 최적화 우선순위 결정에 활용된다.
-- 평균 실행 시간 Top 10 슬로우 쿼리 (최근 24시간)
SELECT
statement_id,
executed_by,
ROUND(total_duration_ms / 1000.0, 2) AS duration_sec,
statement_text
FROM system.query.history
WHERE start_time >= CURRENT_TIMESTAMP() - INTERVAL 1 DAY
AND status = 'FINISHED'
ORDER BY total_duration_ms DESC
LIMIT 10;4. 스트리밍으로 실시간 파이프라인 구성
System Tables는 Spark Structured Streaming의 소스로 활용해 실시간 모니터링 파이프라인을 구성할 수 있다. 단, Delta Sharing 특성상 skipChangeCommits 옵션을 반드시 설정해야 한다.
# 실시간 비용 이상 탐지 파이프라인 예시
(spark.readStream
.option("skipChangeCommits", "true")
.table("system.billing.usage")
.createOrReplaceTempView("streaming_usage")
)
# 시간당 DBU가 임계값 초과 시 알람 발생 로직 연결 가능주의:
Trigger.AvailableNow는 Delta Sharing 스트리밍에서 지원되지 않으며, 내부적으로Trigger.Once로 변환된다. 또한 기본 VACUUM 보존 기간이 7일이므로 스트리밍 지연이 7일을 초과하면 쿼리가 실패할 수 있다.
5. 권한 설정 Best Practice
-- 1. 스키마 수준 USE 권한 부여
GRANT USE SCHEMA ON SCHEMA system.billing TO `analyst-group`;
GRANT USE SCHEMA ON SCHEMA system.access TO `security-team`;
GRANT USE SCHEMA ON SCHEMA system.lakeflow TO `data-engineering-team`;
-- 2. 테이블 수준 SELECT 권한 부여
GRANT SELECT ON TABLE system.billing.usage TO `analyst-group`;
GRANT SELECT ON TABLE system.access.audit TO `security-team`;
-- 3. 특정 팀용 뷰 생성으로 컬럼 수준 접근 제어
CREATE VIEW prod.monitoring.team_billing AS
SELECT workspace_id, sku_name, usage_quantity, usage_date
FROM system.billing.usage
WHERE tags['team'] = 'data-platform';Account Admin은 기본적으로 모든 System Tables에 접근할 수 있다. 일반 사용자는 스키마별로 USE와 SELECT 권한을 받아야 하며, 민감한 audit 테이블은 보안팀에만 노출하는 것이 권장된다.
6. 주요 활용 시나리오 요약
| 시나리오 | 사용 테이블 | 핵심 가치 |
|---|---|---|
| 팀별 비용 차지백(Chargeback) | billing.usage + billing.list_prices | 태그 기반 비용 분배 자동화 |
| 데이터 접근 감사 | access.audit | 규정 준수 및 내부 감사 |
| 데이터 리니지 시각화 | access.table_lineage + access.column_lineage | 영향도 분석 및 데이터 신뢰성 확보 |
| 잡 SLA 모니터링 | lakeflow.job_run_timeline | 파이프라인 지연 자동 탐지 |
| 슬로우 쿼리 튜닝 | query.history | 쿼리 성능 개선 우선순위 결정 |
| 클러스터 효율화 | compute.node_timeline | 유휴 리소스 식별 및 비용 절감 |
마치며
System Tables는 단순한 로그 테이블이 아니다. Databricks 플랫폼 전체를 데이터로 관찰하는 인터페이스다. 비용, 보안, 성능, 리니지를 SQL 하나로 통합 관찰할 수 있다는 점에서 플랫폼 엔지니어링 팀의 핵심 도구가 됐다.
2026년 현재 System Tables는 지속적으로 확장 중이며, MLflow, AI Gateway, Model Serving 등 AI 관련 스키마가 빠르게 추가되고 있다. 플랫폼 관찰 전략을 수립할 때 System Tables를 중심에 두는 것을 강력히 권장한다.
참고: Monitor account activity with system tables — Databricks 공식 문서
