BI 서빙 팁; 성능 및 TCO 극대화

BI 대시보드가 느리고, 이를 튜닝하는 데 너무 많은 시간과 비용이 소모됩니다.

익숙한 패턴입니다. 대시보드 쿼리가 30초가 걸리면, 누군가 이를 빠르게 하기 위해 집계 테이블을 만듭니다. 이 테이블은 새로 고침 파이프라인이 필요합니다. 파이프라인은 모니터링이 필요합니다. 그런 다음 두 번째 BI 도구가 약간 다른 형태로 동일한 데이터를 필요로 하여, 누군가 별도의 파이프라인을 사용하여 또 다른 집계 테이블을 만듭니다. 머지않아, 각기 다른 데이터 최신성 유지 기간, 거버넌스 격차, 그리고 컴퓨팅 비용 청구 항목을 가진 집계, 추출, 도구별 의미 계층의 확산을 관리하게 됩니다.

BI 워크로드는 다른 분석 워크로드와 다릅니다. 이들은 높은 동시성, 지연 시간에 민감하며, 쿼리 패턴이 반복적입니다. 이러한 조합은 데이터 모델링, 저장, 최적화 및 제공에 대한 신중한 접근 방식을 요구합니다. 좋은 소식은 Databricks가 물리적 데이터 레이아웃부터 거버넌스되는 의미 계층까지 BI 제공을 위한 전체 스택을 제공하며, 각 계층은 그 아래 계층의 성능 향상을 증폭시킨다는 것입니다.

이 게시물은 쿼리 성능 및 비용에서 가장 큰 개선을 위해 어디에 집중해야 하는지에 대한 실용적인 지침과 함께 해당 스택을 아래에서 위로 설명합니다.

BI 제공 스택

각 계층에 대해 자세히 알아보기 전에, 전체 그림은 다음과 같습니다.

Unity Catalog는 원시 데이터부터 의미 계층을 거쳐 소비에 이르기까지 계보 및 액세스 제어를 통해 전반적인 거버넌스를 제공합니다. 각 계층은 성능 및 비용의 다른 측면을 다룹니다. 하나씩 살펴보겠습니다.

물리적 계층 최적화

물리적 계층은 대부분의 BI 성능이 결정되는 곳입니다. 이 부분을 제대로 하면 의미 계층을 건드리지 않아도 모든 쿼리가 이점을 얻습니다.

차원 모델링으로 시작하기

스타 스키마는 BI 쿼리 성능의 황금 표준으로 남아 있습니다. 서브로게이트 키를 통해 팩트 테이블에 조인된 넓고 비정규화된 차원 테이블은 쿼리 옵티마이저에게 깔끔하고 예측 가능한 조인 경로를 제공합니다.

Databricks는 필요한 관계형 모델링 구성 요소를 완벽하게 지원합니다: 기본 및 외래 키 제약 조건(옵티마이저 힌트를 위한 RELY 포함), 서브로게이트 키를 위한 ID 열, 그리고 CHECK 및 NOT NULL 제약 조건. 메달리온 아키텍처를 따르는 경우, 정규화된 또는 Data Vault 모델을 Silver에 유지하고 BI 소비를 위해 Gold에 비정규화된 스타 스키마를 구축하세요.

자세한 구현 패턴(SCD Type-1 및 Type-2 처리, MERGE를 사용한 팩트 테이블 ETL, 지연 도착 차원)은 Databricks SQL에서 차원 데이터 웨어하우스 구현 블로그 시리즈를 참조하세요.

관리형 테이블 사용

Unity Catalog 관리형 테이블은 이 스택의 다른 모든 것의 기반입니다. Unity Catalog는 관리형 테이블에 대한 모든 읽기, 쓰기, 저장 및 최적화 책임을 관리합니다. 이는 외부 테이블에서는 얻을 수 없는 자동 기능을 잠금 해제합니다: 예측 최적화(아래에서 다룸)는 기본적으로 활성화됩니다. 자동 리퀴드 클러스터링은 쿼리 패턴이 변경됨에 따라 적응하는 클러스터링 키를 선택합니다. 메타데이터 캐싱은 항상 켜져 있어 클라우드 스토리지 요청을 줄이고 쿼리 계획을 가속화합니다.

BI 제공뿐만 아니라 Bronze, Silver, Gold 계층 전반에 걸쳐 플랫폼 전체에서 관리형 테이블을 사용하세요. 이들은 Unity Catalog의 기본 테이블 유형이며, 이 스택의 다른 모든 최적화와 함께 성능 및 거버넌스 이점이 증폭됩니다.

리퀴드 클러스터링 적용

리퀴드 클러스터링은 정적 파티셔닝 및 수동 Z-ORDER을 대체하며, 이러한 접근 방식과 달리 기존 데이터를 다시 작성하지 않고도 클러스터링 키를 재정의할 수 있습니다. 테이블 생성 시 CLUSTER BY (col1, col2)를 추가하거나 기존 테이블에 ALTER TABLE를 사용하세요. 어떤 열을 선택해야 할지 확실하지 않은 경우, CLUSTER BY AUTO를 통해 예측 최적화가 관찰된 쿼리 패턴을 기반으로 키를 선택하도록 할 수 있습니다.

BI 워크로드의 경우, 가장 일반적인 필터 및 조인 열(날짜 키, 지역, 제품 카테고리)을 기준으로 클러스터링하세요. 최대 4개의 열을 선택할 수 있으며, 두 열이 높은 상관 관계를 가지면 하나만 포함하세요. 대시보드가 클러스터 열을 기준으로 필터링할 때, 리퀴드 클러스터링은 데이터 스키핑을 통해 쿼리 성능을 향상시킵니다.

예측 최적화가 나머지를 처리하도록 하세요

예측 최적화는 이러한 작업의 이점을 얻을 수 있는 테이블에 대해 OPTIMIZE, VACUUM 및 통계 수집을 자동으로 실행하므로, 이러한 작업을 직접 예약할 필요가 없습니다. 이는 Photon 쓰기 중에 Delta 데이터 스키핑 통계와 쿼리 옵티마이저 통계를 모두 수집하고, 기존 테이블에 대한 통계를 백필합니다. 관찰된 워크로드에서 이는 평균 22%의 성능 향상을 가져왔습니다. 반복적인 필터 패턴을 가진 BI 워크로드의 경우, 그 영향은 특히 중요합니다. 더 나은 통계는 더 나은 데이터 스키핑과 더 효율적인 쿼리 계획을 의미합니다.

카탈로그 수준에서 예측 최적화를 활성화하고 실행하도록 두세요. 예측 최적화를 사용하는 것은 가장 높은 수익률과 가장 적은 노력을 요하는 최적화 중 하나입니다.

결과: BI 쿼리는 더 적은 데이터를 스캔하고, 더 효율적으로 조인하며, 실행 비용이 적게 듭니다. 그리고 아직 의미 계층은 건드리지도 않았습니다.

메트릭 뷰: 메트릭을 한 번만 정의하세요

이제 흥미로운 부분이 나옵니다. 대부분의 조직에서는 동일한 비즈니스 메트릭이 여러 곳에 정의되어 있습니다. 한 BI 도구에서는 수익 계산, 다른 도구에서는 약간 다른 계산, 지난 분기에 누군가 작성한 SQL 노트북에서는 세 번째 변형이 있습니다. 각 정의는 독립적으로 달라집니다. 어느 것이 정확한지 아무도 확신하지 못합니다.

Unity Catalog의 메트릭 뷰는 헤드리스 BI 계층, 즉 특정 BI 도구와 독립적으로 데이터 모델과 KPI를 한 번만 정의하는 단일 거버넌스 의미 계층을 제공하여 이 문제를 해결합니다. SQL 또는 Unity Catalog Explorer의 포인트 앤 클릭 UI에서 중앙 집중식으로 정의합니다. AI/BI 대시보드, Genie, SQL 노트북 및 타사 BI 도구는 모두 동일한 정의에서 메트릭을 해결합니다. 메트릭을 한 번 정의하면 모든 소비자(사람 또는 AI)가 동일한 답변을 얻습니다.

메트릭 뷰는 중앙 집중식 메트릭 정의를 넘어섭니다. 의미론적 메타데이터가 이들을 차별화합니다. display_name, comment 및 synonyms와 같은 필드는 AI 시스템이 비즈니스 질문을 올바르게 해석하는 데 필요한 컨텍스트를 제공합니다. 사용자가 Genie에게 "지난주 수익이 얼마였나요?"라고 물을 때, 이러한 주석은 Genie가 자연어를 올바른 측정값 및 차원에 매핑하는 방식입니다. 사용자 지정 프롬프트나 별도의 용어집이 필요 없습니다. Databricks를 기반으로 구축된 AI 에이전트에도 동일하게 적용됩니다. Unity Catalog에 액세스할 수 있는 모든 에이전트는 하드코딩된 SQL 대신 의미 계층을 통해 거버넌스되는 메트릭을 검색하고 쿼리할 수 있습니다. 메타데이터가 풍부할수록 AI는 더 정확하게 올바른 답변을 제공합니다.

모든 Databricks 고객이 액세스할 수 있으므로 시스템 테이블을 사용하는 예시입니다. 하지만 동일한 패턴이 수익, 주문량 또는 고객 유지와 같은 비즈니스 KPI에도 적용됩니다. 이 메트릭 뷰는 DBSQL 웨어하우스 메트릭을 계산합니다:

소비자는 거버넌스되는 메트릭 정의를 참조하기 위해 MEASURE()를 사용하여 메트릭 뷰를 쿼리합니다:

메트릭은 메트릭 뷰에서 한 번 정의됩니다. metv_dbsql_metrics를 쿼리하는 모든 대시보드, Genie 공간 또는 노트북은 동일한 결과를 얻습니다. 아래는 메트릭 뷰를 소스로 사용하는 대시보드입니다.

Genie가 동일한 메트릭 뷰를 사용하는 모습입니다.

여러 BI 도구에 메트릭 정의가 분산되어 있는 팀의 경우, Metric Views는 시맨틱 레이어를 Databricks로 통합하는 방법을 제공합니다. 각 도구에서 개별 메트릭 로직을 유지 관리하는 대신, Unity Catalog에서 한 번 정의하고 BI 도구를 해당 관리되는 소스에 연결할 수 있습니다.

핵심 구현은 Apache Spark™(SPARK-54119)에서 오픈 소스로 제공되며, Unity Catalog OSS 지원이 예정되어 있어 공급업체 종속성 없이 개방형 표준을 기반으로 구축할 수 있습니다. AI가 BI 워크로드의 더 많은 부분을 차지하게 되면서 이러한 개방성은 더욱 중요해집니다. 데이터를 쿼리하는 에이전트는 각 메트릭이 무엇을 의미하는지에 대한 일관되고 기계가 읽을 수 있는 정의가 필요하며, 개방형 표준을 통해 공급업체별 도구뿐만 아니라 모든 도구 또는 에이전트가 동일하게 관리되는 메트릭을 추론할 수 있습니다.

메트릭 뷰 구체화: 오버헤드 없는 OLAP 성능

기존에는 BI 대시보드가 너무 느릴 때 집계 테이블을 구축하는 것이 해결책이었습니다. 스타 스키마 위에 구체화된 뷰 또는 사용자 지정 사전 집계 테이블을 만들고, 새로 고침 파이프라인을 설정한 다음, BI 도구를 새 테이블로 다시 지정했습니다. 이 방법은 효과적이었지만, 유지 관리해야 할 객체와 파이프라인 계층이 추가되었고, 집계 로직이 변경될 때마다 BI 도구 쿼리를 일치시키기 위해 업데이트해야 했습니다.

메트릭 뷰 구체화는 더 간단한 대안을 제공합니다. 메트릭 뷰에서 구체화를 활성화하면 플랫폼은 BI 도구가 이미 쿼리하는 동일한 메트릭 정의 뒤에서 사전 집계된 결과를 자동으로 유지 관리합니다. 별도의 집계 테이블을 구축할 필요도 없고, BI 도구 쿼리를 리팩터링할 필요도 없습니다. 내부적으로 발생하는 일은 다음과 같습니다.

• 자동 사전 집계: 메트릭 결과가 미리 계산되어 저장됩니다.
• 증분 새로 고침: 전체 재계산 없이 메트릭이 최신 상태를 유지합니다.
• 지능형 쿼리 재작성: 엔진이 쿼리를 가장 적합한 구체화로 라우팅합니다.
• 투명한 라우팅: 사용자는 동일한 방식으로 메트릭을 쿼리하며, 시스템은 가장 빠른 경로를 제공합니다.

이전에 전체 팩트 테이블을 스캔했던 대시보드 쿼리는 이제 사전 집계된 구체화를 통해 더 낮은 지연 시간과 더 낮은 컴퓨팅 비용으로 처리됩니다. 위에 제시된 대시보드 및 Genie 예시는 모두 동일한 Metric View를 쿼리했으며, 두 쿼리 모두 구체화로 투명하게 라우팅되었습니다. 아래 Genie의 쿼리 계획은 이를 보여줍니다.

실용적인 TCO 팁

더 빠른 쿼리와 더 낮은 비용은 상충되는 목표가 아닙니다. 스캔되는 데이터를 줄이는 모든 최적화는 지불해야 하는 컴퓨팅 비용도 줄입니다. 그리고 스택의 각 최적화는 복합적으로 작용합니다. Liquid clustering과 더 나은 통계는 데이터 건너뛰기 및 쿼리 계획을 개선합니다. 구체화는 증분 방식으로 새로 고칠 수 있어 SQL 웨어하우스가 대시보드를 제공하는 데 필요한 컴퓨팅 비용을 줄입니다. 비용을 절감하는 몇 가지 추가 방법은 다음과 같습니다.

• SQL 웨어하우스 크기 조정. BI 동시성 급증을 위해 자동 스케일링이 가능한 서버리스 SQL 웨어하우스를 사용하세요. 피크 용량이 아닌 사용한 만큼만 비용을 지불합니다.
• DBSQL의 캐싱 계층 활용. 디스크 캐시는 자주 사용되는 데이터를 웨어하우스 로컬에 유지하고, 쿼리 결과 캐시(QRC)는 반복되는 쿼리를 재실행 없이 제공합니다. 일관된 쿼리 패턴을 가진 대시보드의 경우, 캐싱은 많은 요청을 거의 제로에 가까운 컴퓨팅 비용으로 밀리초 단위의 지연 시간 응답으로 전환합니다.
• 불필요한 데이터 이동 제거. 추출 또는 가져오기를 사용하는 대신 DirectQuery 또는 라이브 연결을 통해 레이크하우스에서 BI를 직접 제공하세요.
• 시스템 테이블로 모니터링. system.billing.usage 및 system.query.history과 같은 시스템 테이블을 사용하여 대시보드, 사용자 및 웨어하우스별 BI 사용량을 추적할 수 있습니다. 시스템 테이블에 Metric Views 및 AI/BI 대시보드를 구축하여 BI 사용량에 대한 가시성을 확보하세요.

시작하기

전체 스택을 한 번에 구현할 필요는 없습니다. 가장 큰 효과를 볼 수 있는 부분부터 시작하세요.

1. 관리형 테이블, 기본/외래 키, liquid clustering을 사용하여 골드 레이어 스타 스키마를 구축(또는 검증)하세요.
2. 카탈로그에서 예측 최적화(Predictive Optimization)를 활성화하여 OPTIMIZE, VACUUM 및 통계 수집을 자동 관리하세요.
3. 핵심 비즈니스 KPI에 대한 Metric Views를 정의하세요. SQL 또는 UC Explorer UI로 시작할 수 있습니다.
4. 트래픽이 가장 많은 메트릭에 대해 Metric View 구체화를 활성화하세요.
5. 결과를 모니터링하세요. 대시보드를 Metric Views에 연결하고 시스템 테이블을 통해 쿼리 성능을 추적하세요.

Databricks는 BI 서비스 스택의 모든 계층에서 최적화를 제공합니다. 관리형 테이블, liquid clustering 및 예측 최적화(Predictive Optimization)는 스캔되는 데이터와 사용되는 컴퓨팅을 최소화합니다. Metric Views는 대시보드, Genie 및 AI 에이전트에 일관되게 서비스를 제공하는 관리형 시맨틱 레이어에 비즈니스 로직을 중앙 집중화합니다. 구체화는 수동 사전 집계 파이프라인 없이도 1초 미만의 쿼리 성능을 제공합니다. 이러한 계층들이 함께 작용하여 쿼리 지연 시간과 총 소유 비용을 모두 절감합니다.

기존 골드 레이어 테이블에 첫 번째 Metric View를 정의하고 구체화를 활성화하는 것부터 시작하세요. 시작하는 데 필요한 자료는 아래를 참조하세요.

• Unity Catalog Metric Views 개요
• AI/BI에서 Metric Views 활용
• SQL 편집기에서 Metric Views 쿼리
• Databricks SQL에서 차원 데이터 웨어하우스 구현

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)