주요 컨텐츠로 이동

AI/BI 대시보드 성능 최적화를 위한 상위 10가지 모범 사례 (파트 2)

AI/BI Dashboards Performance Optimization

발행일: February 4, 2026

솔루션2 min read

작성자: 타르지치우스 팔 시몬, 로빈 휘브너

이 포스트 공유하기

우리와 함께하세요

Summary

  • 대규모 환경에서도 Databricks AI/BI 대시보드를 일관되게 빠르게 만들기 위한 실용적인 플레이북—이미 프로덕션 환경에 대시보드가 있으며 사용량 증가에 따라 대시보드가 계속해서 빠르게 유지되기를 바라는 팀을 대상으로 합니다.
  • 대시보드 디자인, warehouse 구성, Lakehouse 데이터 패턴을 하나의 반복 가능한 접근 방식으로 결합하여 가장 영향력 있는 10가지 모범 사례를 한곳에서 다룹니다.
  • 명확하고 실행 가능한 지침과 개선 사항을 검증하기 위해 살펴봐야 할 사항이 포함되어 있으므로, 하나의 대시보드를 기준으로 삼고 몇 가지 변경 사항을 적용하여 속도, 안정성 및 비용 면에서 실질적인 이득을 측정할 수 있습니다.

이 게시물은 대규모 Databricks AI/BI 대시보드 성능 최적화에 대한 2부작 시리즈의 두 번째 파트입니다. 

이전 게시물에서는 레이아웃, 필터, 매개변수, 캐싱이 클릭할 때마다 시스템에서 수행하는 작업량을 어떻게 결정하는지에 대해 집중적으로 살펴보았습니다. 이러한 최적화만으로도 대시보드가 빠르다고 느껴지게 하는 데 충분합니다. 

이번 게시물에서는 사용량이 증가해도 빠른 속도를 유지하는 플랫폼 기반에 초점을 맞춥니다. 안정적이고 예측 가능한 성능을 달성하기 위해 웨어하우스 선택 및 크기 조정, 데이터 모델링 및 스키마 선택, 파일 레이아웃 및 클러스터링, 그리고 재계산 대신 구체화를 사용해야 하는 경우에 대해 살펴보겠습니다.

최적화 #6: 설계에 맞는 웨어하우스 구성을 선택하세요 

대시보드 형태(페이지, 쿼리 믹스, 사용자 버스티니스)를 DBSQL 웨어하우스 유형 및 크기 조정에 맞춰 시스템이 큐잉 없이 작업을 신속하게 수용하도록 하세요.

보이는 위젯이 함께 제출되기 때문에 대시보드는 자연스럽게 일시적인 동시성 스파이크를 생성합니다. 웨어하우스가 버스트를 감당하지 못하면 큐잉(Peak Queued Queries > 0)이 발생하고, 특히 피크 시간대에 타일 로드 시간이 일관되지 않게 됩니다.

DBSQL 웨어하우스 동시성 작동 방식

  • 서버리스 + IWM: 서버리스는 지능형 워크로드 관리를 사용하여 비용을 예측하고, 쿼리를 수락하고 우선순위를 지정하며, 신속하게 자동 확장합니다. 일반적인 startup은 2~6초이므로 수동 튜닝 없이도 버스트가 낮은 지연 시간을 유지합니다.
  • Pro/Classic: '클러스터당 동시 쿼리 10개' 게이트가 고정되어 있고, 자동 확장은 분 단위 임계값에 따라 클러스터를 추가하며 startup은 수 분이 걸리므로, 예상 동시성에 따라 용량을 계획하고 페이지 로드 시 급증을 방지해야 합니다.
  • 모니터링 및 적정 규모 조정: '최대 대기 쿼리 수(Peak Queued Queries)'와 '쿼리 기록(Query History)'을 주시하고, 피크가 0을 초과하여 지속되면 클러스터 크기를 늘리거나(특히 '쿼리 프로필(Query Profile)'에 디스크로 스필(spill to disk)이 표시되는 경우) 최대 클러스터 수를 늘리세요. 

서버리스를 먼저 선택하는 이유

  • 대화형 BI에 Serverless 권장: 가장 빠른 startup, IWM을 통한 동적 동시성, 더욱 효율적인 IO.

실용적인 크기 조정 휴리스틱

  • 더 큰 클러스터 크기로 시작하고 테스트 후 규모를 줄이세요. Serverless 자동 확장이 동시성 버스트를 처리하도록 하고, 큐 피크가 지속될 때만 최대 clusters를 늘리세요.
  • 과도한 ETL과 BI는 분리하세요: 워크로드/도메인별로 전용 Serverless 웨어하우스를 할당하여 캐시 오염을 방지하고 IWM이 워크로드 패턴을 학습하도록 하세요.
  • 작고 빈번한 쿼리를 우선적으로 처리하세요. Serverless IWM은 짧은 상호작용을 보호하고 혼합 로드 중에 빠르게 확장됩니다. Overview가 가장 가벼운 타일을 먼저 실행하도록 페이지를 설계하세요. 

자세한 내용은 다음을 참조하세요. https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior 

최적화 #7: 데이터 모델링 모범 사례 적용

잘 설계된 데이터 모델은 AI/BI 대시보드의 핵심적인 성능 기능입니다. 스타 스키마는 BI 쿼리 작성 및 최적화 방식과 직접적으로 일치하므로 인터랙티브 분석에 가장 효과적이고 예측 가능한 모델링 패턴입니다.

스타 스키마에서 중앙 팩트 테이블은 측정 가능한 이벤트(판매, 트랜잭션, 클릭)를 포함하며 주변 차원 테이블(날짜, 고객, 제품, 지역)에 조인됩니다. 이 구조는 조인 복잡성을 최소화하고 데이터 중복을 줄이며 간단하고 안정적인 쿼리 패턴으로 효율적인 집계를 가능하게 합니다. 결과적으로 대시보드는 더 적은 조인을 실행하고 더 적은 데이터를 스캔하며 캐싱 및 쿼리 최적화의 이점을 더 일관되게 얻을 수 있습니다.

조인 키 데이터 유형은 중요하지만 종종 간과되는 세부 사항입니다. 차원 테이블과 팩트 테이블 조인에는 문자열이 아닌 정수 기반 대리 키를 사용해야 합니다. 정수 조인은 훨씬 더 빠르고, 메모리를 덜 사용하며, 캐시 효율성을 개선하고, Photon이 고도로 최적화된 벡터화된 경로를 사용하여 조인을 실행할 수 있도록 합니다. 문자열 기반 조인은 CPU 비용을 증가시키며 데이터와 동시성이 증가함에 따라 숨겨진 병목 현상이 될 수 있습니다.

Databricks에서 이 패턴은 Lakehouse 아키텍처와 자연스럽게 어울립니다. 골드 레이어는 Unity Catalog 테이블로 저장된 팩트 및 차원으로 모델링되어야 하며, AI/BI 대시보드, 메트릭 뷰 및 구체화된 뷰를 위한 관리되고 재사용 가능한 시맨틱 기반을 제공해야 합니다.

핵심은 간단합니다. BI 쿼리가 실제로 실행되는 방식을 모델링하세요. 골드 레이어에서 정수 조인 키를 사용하는 스타 스키마는 더 간단한 SQL, 더 빠른 조인, 대규모 환경에서 더 예측 가능한 성능을 제공합니다.

최적화 #8: Parquet 최적화 기법

대시보드가 쿼리당 훨씬 적은 데이터를 읽도록 데이터 레이아웃을 설계한 다음, 엔진이 Parquet 통계 및 선택적 읽기를 활용하도록 하세요. 

파일 레이아웃을 성능 요소로 취급하세요

Databricks SQL은 다음과 같은 경우 가장 빠릅니다.

  • 메타데이터(최소/최대 통계)를 사용하여 전체 파일 프루닝,
  • 크고 연속적인 청크를 효율적으로 읽고,
  • 수천 개의 작은 파일이 열리는 것을 방지합니다.

따라서 가장 큰 두 가지 이점은 파일을 최적의 크기로 압축하고,
조건자가 파일을 정리할 수 있도록 데이터를 클러스터링하는 것입니다.

자세한 내용은 여기에서 확인할 수 있습니다: https://www.databricks.com/discover/pages/optimize-data-workloads-guide

전형적인 안티패턴: WHERE customer_id = ? 와 같은 대시보드 필터 선택적인 것처럼 보이지만, 데이터가 클러스터링되어 있지 않으면 일치하는 행이 여기저기 흩어져 있어 엔진이 여전히 방대한 양의 파일을 검사하게 됩니다.

기술

  • Photon 을 사용하여 Parquet에 내장된 Predictive IO 의 이점을 활용하세요. Photon은 AI 지원 선택적 읽기와 병렬 IO를 적용하여 일치하지 않는 블록을 건너뛰고 더 적은 수의 파일을 나열함으로써 수동 인덱싱 없이 빠른 선택적 스캔을 제공합니다.
  • 관리형 테이블에 예측 최적화 사용: Databricks는 관찰된 워크로드 패턴(OPTIMIZE (파일 크기를 정상으로 유지하기 위한 압축), ANALYZE (최신 통계), VACUUM (정리), Liquid 클러스터링 (적응형 layout))을 기반으로 테이블 유지 관리를 자동으로 예약하고 실행하여 수동 튜닝의 필요성을 없애고 대규모 환경에서 읽기 가격/성능을 개선할 수 있습니다. 실제로 이는 작은 파일을 사전에 압축하여(OPTIMIZE를 통해) Parquet 메타데이터(footers + min/max stats)가 데이터 건너뛰기, 선택적 스캔, BI 스캔/동시성에 대해 효과적으로 유지되도록 함으로써 파일 크기를 정상으로 유지하는 데 도움이 됩니다.
  • 필요 시 동일한 운영을 수동으로 Trigger: 더 세밀한 제어가 필요하거나 더 빠른 가치 실현이 필요할 때(예: 대규모 수집/백필, 스키마 변경 후 또는 알려진 보고 피크 전) OPTIMIZE 및 ANALYZE와 같은 명령을 실행하여 직접 운영을 수행할 수도 있습니다. 핵심은 의도적으로 접근하는 것입니다. 테이블 변경 빈도에 맞춰 유지 관리 주기를 조정하고, 다운스트림의 동시성, 지연 시간, 스캔 효율성 향상을 통해 compute 비용이 정당화되도록 해야 합니다.
  • 과도한 파티셔닝 대신 Liquid Clustering 을 채택하세요. Liquid는 포인트 조회와 선택적 스캔을 위해 데이터를 점진적으로 클러스터링합니다. 전체를 다시 작성할 필요 없이 언제든지(카디널리티가 높은 경우에도) 클러스터링 열을 변경할 수 있으며, 사용 패턴이 변화함에 따라 레이아웃도 조정됩니다.
  • 대시보드 조건에 맞춰 레이아웃을 정렬합니다. Predictive IO가 “Investigate” 및 “Deep dive” 페이지에서 대규모 데이터를 건너뛸 수 있도록 일반적인 필터/그룹화 차원(예: 날짜, 고객, 지역)을 반영하는 Liquid 클러스터링 열을 선택하세요. 

결과: 불안정한 인덱스나 수동 튜닝 없이 동일한 인사이트에 대해 더 적은 파일에 액세스하고, 더 많은 블록을 건너뛰며, 월클락(wall-clock) 시간이 단축됩니다. 

자세한 내용은 다음을 참조하세요. 

최적화 #9: 메트릭 뷰 머티리얼라이제이션 활용

최적화 #7: 데이터 모델링 모범 사례 적용에서는 명확하게 정의된 팩트, 차원, KPI를 사용하는 스타 스키마의 중요성에 중점을 두었습니다. 메트릭 뷰는 Databricks AI/BI에서 이러한 원칙의 직접적인 연장선입니다.

메트릭 뷰 는 BI 시맨틱을 중심으로 설계되었습니다. 즉, 측정값과 차원으로 구성되어 KPI 모델링을 위한 자연스러운 추상화를 제공합니다. 이를 통해 팀은 비즈니스 메트릭을 한 번 정의하고 여러 대시보드, 에이전트 및 기타 클라이언트 도구에서 동일한 KPI를 일관되게 재사용할 수 있습니다. 이를 통해 중복이 감소하고 KPI 드리프트가 방지되며, 도입이 확대되면서 분석 로직의 일관성이 유지됩니다.

메트릭 뷰 구체화를 사용하면 Databricks가 자주 사용되는 집계를 자동으로 사전 계산하고 유지 관리합니다. 이러한 집계는 증분식으로 업데이트되며, 쿼리 시 옵티마이저는 대시보드 쿼리를 가장 잘 일치하는 사전 계산된 결과로 투명하게 다시 작성합니다. 결과적으로 대시보드 쿼리는 팀이 별도의 집계 테이블이나 사용자 지정 파이프라인을 관리할 필요 없이 상호 작용당 훨씬 적은 데이터를 스캔합니다.

메트릭 뷰를 사용하지 않는 경우, Materialized View를 사용하여 동일한 접근 방식을 적용할 수 있습니다. 예를 들어, 대규모 팩트 테이블의 집계 버전을 미리 계산하여 저장하면 대시보드에서 훨씬 작고 최적화된 데이터 세트를 쿼리할 수 있습니다. 이를 통해 스캔하는 데이터 양을 줄이고 사용자 상호작용마다 비용이 많이 드는 집계를 반복적으로 재계산하지 않아도 되므로 성능이 크게 향상됩니다.

이 모든 기술은 동일한 것을 최적화합니다. 바로 더 적은 데이터를 스캔하는 것입니다. KPI를 한 번 정의하고 Metric Views 또는 Materialized Views로 자주 사용되는 집계를 미리 계산하면, 대시보드는 대용량 팩트 테이블을 반복적으로 집계할 필요가 없어집니다. 스캔되는 바이트 수가 적을수록 쿼리 속도가 빨라지고, 지연 시간을 더 쉽게 예측할 수 있으며, 대규모 환경에서 더 나은 성능을 얻을 수 있습니다.

자세한 내용은 다음을 참조하세요. 

최적화 #10: 데이터 유형 최적화

데이터 유형은 모든 대시보어 쿼리에 대해 Databricks SQL이 읽고, 이동하고, 처리해야 하는 데이터의 양에 직접적인 영향을 미칩니다. 완벽한 SQL과 캐싱을 사용하더라도 비효율적인 데이터 유형은 IO, 메모리 압박, CPU 비용을 조용히 증가시켜 타일 속도를 저하시키고 동시성을 감소시킵니다.

내부적으로 Databricks SQL은 컬럼 기반 Parquet 파일에서 작동합니다. 더 작고 잘 선택된 데이터 유형은 다음을 의미합니다.

  • 스토리지에서 스캔되는 데이터 감소(더 좁은 열),
  • 더 나은 캐시 밀도(메모리 및 결과 캐시에 더 많은 값이 저장됨),
  • Photon에서 더 빠른 벡터화된 실행(SIMD 친화적인 Layout),
  • 최소/최대 통계가 더 조밀하여 데이터 건너뛰기가 더욱 효과적입니다.

몇 가지 방법이 가장 중요합니다.

  • 식별자에는 가능한 한 STRING 대신 INT / BIGINT를 사용하세요. 문자열은 스캔, 비교, 캐시하는 데 비용이 많이 들지만 숫자 키는 훨씬 더 저렴합니다.
  • 문자열 기반 날짜보다 DATE 또는 TIMESTAMP를 사용하는 것이 좋습니다. 네이티브 시간 유형은 조건자 푸시다운, 효율적인 비교, 더 나은 프루닝을 가능하게 합니다.
  • 데이터에 맞는 가장 작은 숫자 유형(INT 대 BIGINT, FLOAT 대 DOUBLE)을 사용해 열 너비와 메모리 사용량을 줄이세요.
  • 필요한 경우가 아니라면 BI용 테이블에서 과도한 정밀도의 DECIMAL을 남용하지 마세요. 고정밀도 십진수는 집계 중 CPU 비용을 증가시킵니다.
  • 스키마를 깔끔하고 안정적으로 유지하세요. 암시적 캐스트(예: 쿼리 시 STRING → INT)는 최적화를 비활성화하고 모든 실행에서 불필요한 compute를 추가합니다.

BI 워크로드에서 이러한 선택의 영향은 빠르게 누적됩니다. 대시보드 페이지는 각각 수백만 개의 행을 스캔하는 수십 개의 쿼리를 실행할 수 있습니다. 좁고 유형이 잘 지정된 열은 스캔 시간을 줄이고 캐시 적중률을 개선하며 Photon이 최고 효율로 작동할 수 있도록 합니다.

경험상, 스키마 설계를 성능 기능으로 취급하세요. 레이크하우스에서 데이터 유형을 한 번만 최적화하면 현재 및 미래의 모든 대시보드가 자동으로 이점을 얻습니다.

결론

열 가지 모범 사례 전체의 주제는 간단합니다. 매번 대시보드 상호 작용의 전체 비용을 지불하지 마세요. 뷰당 시스템의 작업량을 줄이고(팬아웃 및 스캔 데이터 감소), 수행하는 작업은 재사용할 수 있도록 만드세요(공유 데이터세트, 결정적 쿼리, 캐시, 사전 계산된 집계). 이러한 요소들이 맞아떨어지면 동시성 하에서 성능이 안정화되고 비용 예측이 가능해집니다.

가장 많이 사용하는 대시보드에 대해 다음 질문에 "예"라고 답할 수 있어야 합니다.

  • 사용자는 빠른 첫 페인트 (가벼운 랜딩 뷰 + 합리적인 기본값)를 경험하나요?
  • 일반적인 상호작용은 소수의 저비용 쿼리 를 트리거하나요? (파라미터가 스캔 후가 아니라 조기에 필터링됨)
  • 반복 뷰가 캐시 히트 (결정적 타일, 타일 간 재사용, 예약된 웜업)로 전환되고 있습니까?
  • 웨어하우스가 큐잉 또는 스필링 없이 피크 부하를 흡수할 수 있습니까(피크 큐 쿼리는 0에 가깝게 유지되고 쿼리 프로필은 스필되지 않음)?
  • Lakehouse는 읽기(정상적인 파일 크기, Liquid Clustering, 정제된 데이터 유형 및 사전 계산된 핫 집계)에 최적화되어 있나요?

실제 사용률이 높은 대시보드 하나를 선택하여 빠른 기준(첫 페인트, 상호 작용 지연 시간, 최대 대기 쿼리 수, 스필, 캐시 적중률)을 실행하고, 가장 효과가 큰 몇 가지 변경 사항을 적용한 후 다시 측정하세요. 이를 꾸준히 실천하면 데이터와 사용자가 증가해도 '가끔 빠른' AI/BI에서 안정적으로 빠른 AI/BI로 전환됩니다.

참고 자료 및 추가 정보

 

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

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요

다음은 무엇인가요?

ETL and BI Migration Strategies

솔루션

January 27, 2025/1분 이내 소요

Databricks로의 마이그레이션 탐색: 아키텍처와 전략적 접근법

DeepSeek R1 on Databricks

공지사항

January 31, 2025/1분 이내 소요

DeepSeek R1 on Databricks