원문: BI Serving Pointers; Maximizing for Performance and TCO 저자: Chris Koester 게시일: 2026년 5월 27일
요약
- 물리 레이어를 스타 스키마 + Liquid Clustering + Predictive Optimization 으로 구성하여 BI 쿼리를 가속합니다.
- Unity Catalog Metric Views 로 거버넌스된 비즈니스 지표를 한 번 정의 — 모든 BI 도구, Genie space, AI 에이전트가 단일 진실 공급원(single source of truth) 에서 동일한 값을 받습니다(headless semantic layer).
- 집계 인식 머티리얼라이제이션(aggregate-aware materialization) 을 활성화하여 별도의 집계 테이블을 만들고 유지보수하지 않고도 OLAP 스타일의 사전 집계 성능을 얻습니다.
BI 대시보드가 느리고, 튜닝에 너무 많은 시간과 돈이 듭니다. 익숙한 패턴입니다. 대시보드 쿼리가 30 초 걸리면, 누군가가 그것을 빠르게 만들기 위해 집계 테이블을 만듭니다. 그 테이블은 리프레시 파이프라인이 필요합니다. 파이프라인은 모니터링이 필요합니다. 그 후 두 번째 BI 도구가 약간 다른 모양의 같은 데이터를 필요로 해서, 누군가가 별도 파이프라인을 사용해 또 다른 집계 테이블을 만듭니다. 얼마 지나지 않아 집계, 추출, 도구별 시맨틱 레이어가 난립한 상태를 관리하게 됩니다 — 각각 자체의 staleness 윈도우, 자체의 거버넌스 공백, 컴퓨트 청구서의 별도 항목과 함께. BI 워크로드는 다른 분석 워크로드와 다릅니다. 매우 동시성이 높고, 지연에 민감하며, 쿼리 패턴이 반복적입니다. 이 조합은 데이터 모델링·저장·최적화·서빙에 대한 의도적인 접근을 요구합니다. 좋은 소식: Databricks 는 BI 서빙을 위한 전체 스택을 제공합니다 — 물리적 데이터 레이아웃부터 거버넌스된 시맨틱 레이어까지 — 그리고 각 레이어는 그 아래 레이어의 성능 이득을 복합적으로(compound) 증폭시킵니다. 이 글은 그 스택을 바닥부터 위로(bottom-up) 살펴보며, 쿼리 성능과 비용에서 가장 큰 개선을 위해 어디에 집중해야 하는지를 실용적으로 가이드합니다.
BI 서빙 스택
각 레이어로 들어가기 전, 전체 그림은 다음과 같습니다.
Unity Catalog 가 전반에 걸쳐 거버넌스를 제공합니다 — raw 데이터부터 시맨틱, 소비까지의 리니지와 접근 제어. 각 레이어는 성능·비용의 서로 다른 측면을 다룹니다. 하나씩 살펴봅시다.
물리 레이어 최적화
물리 레이어는 BI 성능의 대부분이 결정되는 곳입니다. 여기를 잘 맞추면 시맨틱 레이어를 건드리기 전부터 모든 쿼리가 혜택을 봅니다.차원 모델링으로 시작하기
스타 스키마는 BI 쿼리 성능의 황금 표준으로 남아 있습니다. 넓은(wide) 비정규화 차원 테이블이 대리키(surrogate key)를 통해 팩트 테이블에 조인되면, 쿼리 옵티마이저에게 깨끗하고 예측 가능한 조인 경로를 제공합니다. Databricks 는 필요한 관계형 모델링 구성 요소를 완전히 지원합니다 — 기본 키와 외래 키 제약 (옵티마이저 힌트를 위한RELY 포함), 대리키를 위한 identity column, 그리고 CHECK 및 NOT NULL 제약. 메달리온 아키텍처를 따른다면, 정규화 또는 Data Vault 모델은 Silver 에 두고, BI 소비를 위한 비정규화 스타 스키마는 Gold 에서 구축하세요.
상세 구현 패턴 — SCD Type-1/2 처리, MERGE 를 사용한 팩트 ETL, 늦게 도착하는 차원 처리 — 은 Implementing a Dimensional Data Warehouse in Databricks SQL 블로그 시리즈를 참고하세요.
Managed Tables 사용
Unity Catalog managed tables 는 이 스택의 모든 것의 토대입니다. Unity Catalog 가 managed table 에 대한 모든 읽기·쓰기·저장·최적화 책임을 관리합니다. 이것이 external table 에서는 얻을 수 없는 자동 기능들을 풀어줍니다 — Predictive Optimization (아래에서 다룹니다) 이 기본 활성화됩니다. 자동 Liquid Clustering 은 쿼리 패턴이 변할 때 적응하는 클러스터링 키를 선택합니다. 메타데이터 캐싱 은 항상 켜져 있어, 클라우드 스토리지 요청을 줄이고 쿼리 계획을 가속합니다. 플랫폼 전반에 걸쳐 managed table 을 사용하세요 — BI 서빙뿐 아니라 Bronze, Silver, Gold 레이어 모두에서. Unity Catalog 의 기본 테이블 타입이며, 성능·거버넌스 혜택이 이 스택의 다른 모든 최적화와 복합적으로 증폭됩니다.Liquid Clustering 적용
Liquid clustering 은 정적 파티셔닝과 수동Z-ORDER 를 대체합니다 — 그리고 그 접근들과 달리, 기존 데이터를 다시 쓰지 않고도 클러스터링 키를 재정의할 수 있습니다. 테이블 생성 시 CLUSTER BY (col1, col2) 를 추가하거나, 기존 테이블에 ALTER TABLE 을 사용하세요. 어떤 컬럼을 선택할지 확실하지 않다면, CLUSTER BY AUTO 가 Predictive Optimization 으로 관찰된 쿼리 패턴에 기반해 키를 선택하게 할 수 있습니다.
BI 워크로드의 경우, 가장 일반적인 필터·조인 컬럼 에 클러스터링하세요 — 날짜 키, 지역, 제품 카테고리. 최대 네 개의 컬럼을 선택할 수 있으며, 두 컬럼이 매우 상관 관계가 높다면 하나만 포함하세요. 대시보드가 클러스터 컬럼으로 필터링하면, liquid clustering 은 데이터 스키핑을 통해 쿼리 성능을 개선합니다.
Predictive Optimization 에 맡기기
Predictive Optimization 은OPTIMIZE, VACUUM, 통계 수집을 그것이 도움이 되는 테이블에 자동으로 실행합니다 — 이 잡들을 직접 스케줄링할 필요가 없습니다. Photon 쓰기 동안 Delta 데이터 스키핑 통계와 쿼리 옵티마이저 통계를 모두 수집하고, 기존 테이블에 대한 통계를 백필(back-fill)합니다. 관찰된 워크로드에서 이는 평균 22% 성능 개선 을 제공했습니다. 반복적 필터 패턴을 가진 BI 워크로드의 경우, 영향이 특히 큽니다 — 더 나은 통계는 더 나은 데이터 스키핑과 더 효율적인 쿼리 계획을 의미합니다.
카탈로그 수준에서 Predictive Optimization 을 활성화하고 그냥 동작하게 두세요. Predictive Optimization 사용은 수익률 최고, 노력 최저 의 최적화 중 하나입니다.
결과: BI 쿼리가 더 적은 데이터를 스캔하고, 더 효율적으로 조인하고, 실행 비용이 더 낮아집니다 — 시맨틱 레이어는 아직 건드리지도 않았습니다.
Metric Views — 지표를 한 번만 정의
여기서부터 흥미로워집니다. 대부분의 조직은 같은 비즈니스 지표가 여러 곳에 정의되어 있습니다 — 한 BI 도구에 매출 계산이 있고, 다른 도구에 약간 다른 것이 있고, 누군가가 지난 분기에 작성한 SQL 노트북에 세 번째 변형이 있습니다. 각 정의는 독립적으로 표류(drift)합니다. 누구도 어떤 것이 맞는지 확신하지 못합니다. Unity Catalog 의 Metric Views 는 headless BI 레이어를 제공함으로써 이를 해결합니다 — 데이터 모델과 KPI 를 특정 BI 도구와 무관하게 한 번 정의하는 단일 거버넌스된 시맨틱 레이어. SQL 이나 Unity Catalog Explorer 의 포인트앤클릭 UI 로 중앙에서 정의합니다. AI/BI Dashboards, Genie, SQL 노트북, 서드파티 BI 도구가 모두 같은 정의에서 지표를 resolve 합니다. 지표를 한 번 정의하면, 모든 소비자 — 사람이든 AI 든 — 가 같은 답을 얻습니다. Metric View 는 중앙화된 지표 정의를 넘어섭니다 — 시맨틱 메타데이터가 차별점입니다.display_name, comment, synonyms 같은 필드가 AI 시스템에 비즈니스 질문을 올바르게 해석할 수 있는 컨텍스트를 줍니다. 사용자가 Genie 에게 “지난 주 매출은 얼마였어?” 라고 물을 때, 그 어노테이션이 Genie 가 자연어를 올바른 측정값(measure)과 차원으로 매핑하는 방법입니다. 커스텀 프롬프트나 별도 용어집이 필요 없습니다. Databricks 위에 만들어진 AI 에이전트도 마찬가지입니다 — Unity Catalog 에 접근 가능한 어떤 에이전트든 하드코딩된 SQL 대신 시맨틱 레이어를 통해 거버넌스된 지표를 발견하고 쿼리할 수 있습니다. 메타데이터가 풍부할수록 AI 가 더 정확한 답을 제공합니다.
다음은 시스템 테이블을 사용한 예시 — 모든 Databricks 고객이 접근 가능하기 때문 — 이지만, 같은 패턴이 매출, 주문량, 고객 유지 같은 비즈니스 KPI 에도 적용됩니다. 이 Metric View 는 DBSQL warehouse 메트릭을 계산합니다.
소비자는 MEASURE() 를 사용해 거버넌스된 지표 정의를 참조하여 Metric View 를 쿼리합니다.
지표는 Metric View 에 한 번만 정의됩니다. metv_dbsql_metrics 를 쿼리하는 모든 대시보드, Genie space, 노트북이 같은 결과를 얻습니다. 아래는 metric view 를 소스로 사용하는 대시보드입니다.
같은 metric view 를 사용하는 Genie 입니다.
여러 BI 도구에 지표 정의가 흩어진 팀에 Metric Views 는 시맨틱 레이어를 Databricks 로 통합하는 경로를 제공합니다. 각 도구에 별도의 지표 로직을 유지하는 대신, Unity Catalog 에서 한 번 정의하고 BI 도구를 거버넌스된 그 출처에 연결합니다.
코어 구현은 Apache Spark™ 에 오픈소스로 공개되어 있으며 (SPARK-54119), Unity Catalog OSS 지원도 곧 추가됩니다 — 즉, 벤더 락인 없는 개방형 표준 위에서 구축합니다. AI 가 BI 워크로드를 더 많이 떠맡으면서 그 개방성이 더욱 중요해집니다. 데이터를 쿼리하는 에이전트는 각 지표의 의미에 대한 일관되고 머신 판독 가능한 정의가 필요하며, 개방 표준은 벤더 특정 도구가 아닌 어떤 도구나 에이전트든 같은 거버넌스된 지표 위에서 추론할 수 있게 합니다.
Metric View 머티리얼라이제이션 — 오버헤드 없이 OLAP 성능
전통적으로 BI 대시보드가 너무 느릴 때의 답은 집계 테이블을 만드는 것이었습니다. 스타 스키마 위에 materialized view 나 커스텀 사전 집계 테이블을 만들고, 리프레시 파이프라인을 세팅하고, BI 도구를 새 테이블로 다시 가리키게 했습니다. 동작은 했지만, 유지보수할 객체와 파이프라인 전체 레이어가 추가됐고, 집계 로직이 바뀔 때마다 BI 도구 쿼리도 그에 맞춰 업데이트해야 했습니다. Metric View 머티리얼라이제이션은 더 단순한 대안을 제공합니다. Metric View 에 머티리얼라이제이션을 활성화하면, 플랫폼이 BI 도구가 이미 쿼리하는 같은 지표 정의 뒤에서 사전 집계 결과를 자동 유지합니다 — 별도 집계 테이블을 만들 필요도, BI 도구 쿼리를 리팩터링할 필요도 없습니다. 내부 동작은 다음과 같습니다.- 자동 사전 집계: 지표 결과가 미리 계산되어 저장됩니다.
- 증분 리프레시: 전체 재계산 없이 지표가 최신으로 유지됩니다.
- 지능적 쿼리 재작성: 엔진이 쿼리를 사용 가능한 최적의 머티리얼라이제이션으로 라우팅합니다.
- 투명한 라우팅: 사용자는 지표를 같은 방식으로 쿼리하고, 시스템이 가장 빠른 경로를 서빙합니다.
실용적 TCO 포인터
빠른 쿼리와 낮은 비용은 경쟁 목표가 아닙니다 — 스캔 데이터를 줄이는 모든 최적화는 지불하는 컴퓨트도 줄입니다. 그리고 스택의 각 최적화는 복합 효과를 냅니다. Liquid clustering 과 더 나은 통계가 데이터 스키핑과 쿼리 계획을 개선합니다. 머티리얼라이제이션이 증분 리프레시되어 대시보드를 서빙하기 위한 SQL warehouse 컴퓨트가 줄어듭니다. 비용을 낮추는 몇 가지 추가 방법:- SQL warehouse 의 적정 크기 선택. BI 동시성 버스트에 대해 오토스케일링이 있는 서버리스 SQL warehouse 를 사용하세요. 사용한 만큼만 지불하며, 피크 용량에 대해 지불하지 않습니다.
- DBSQL 의 캐싱 계층 활용. Disk cache 가 핫 데이터를 warehouse 로컬에 유지하고, Query Result Cache (QRC) 가 반복 쿼리를 재실행 없이 서빙합니다. 일관된 쿼리 패턴의 대시보드의 경우, 캐싱은 많은 요청을 거의 0 컴퓨트 비용으로 밀리초 지연 응답으로 바꿉니다.
- 중복 데이터 이동 제거. Extract 나 import 대신 DirectQuery 또는 라이브 연결 로 레이크하우스에서 BI 를 직접 서빙하세요.
- 시스템 테이블로 모니터링.
system.billing.usage와system.query.history같은 시스템 테이블로 대시보드/사용자/warehouse 별 BI 사용을 추적할 수 있습니다. 시스템 테이블 위에 Metric View 와 AI/BI Dashboard 를 구축하여 BI 사용에 대한 가시성을 확보하세요.
시작하기
전체 스택을 한 번에 구현할 필요는 없습니다. 가장 영향이 큰 곳부터 시작하세요.- managed table, 기본/외래 키, liquid clustering 으로 Gold 계층 스타 스키마 구축(또는 검증)
- 카탈로그에 Predictive Optimization 활성화 —
OPTIMIZE/VACUUM/통계 수집 자동 관리 - 핵심 비즈니스 KPI 에 대해 Metric View 정의 — SQL 또는 UC Explorer UI 로 시작
- 가장 트래픽이 많은 지표에 Metric View 머티리얼라이제이션 활성화
- 결과 모니터링 — 대시보드를 Metric View 로 가리키고 시스템 테이블로 쿼리 성능 추적