Databricks에서 고동시성, 저지연 데이터 웨어하우스를 설계하는 방법

Databricks 데이터 웨어하우스에서 생산 수준의 분석 구현

데이터가 중요한 비즈니스 결정을 주도하는 조직에서는 고동시성, 저지연 데이터 웨어하우징이 필수적입니다. 이것은 수백 명의 동시 사용자를 지원하고, 대화형 분석을 위한 빠른 쿼리 성능을 제공하며, 빠르고 정확한 의사결정을 위한 실시간 인사이트를 가능하게 하는 것을 의미합니다. 생산용 데이터 웨어하우스는 단순한 지원 시스템 이상입니다—이는 성장과 혁신을 촉진하는 촉매제입니다.

Databricks는 레이크하우스 아키텍처 를 선도하여 데이터, 분석 및 AI 작업을 통합하였습니다. 이로 인해 비용이 많이 드는 데이터 중복 및 복잡한 시스템 통합이 제거되었습니다. 자체 최적화 성능이 내장된 레이크하우스는 경쟁력 있는 가격/성능 을 제공하면서 운영을 간소화합니다. 오픈 레이크하우스로서, Databricks SQL을 통해 중요한 데이터에 빠르고 안전하게 접근할 수 있으며, 통합 보안 및 거버넌스를 통해 BI, 분석 및 AI 도구를 전체 생태계에 걸쳐 제공합니다. 대부분의 사용자들이 이러한 외부 도구를 통해 웨어하우스와 상호 작용하기 때문에 오픈 인터피러러빌리티는 필수적입니다. 이 플랫폼은 데이터와 사용자뿐만 아니라 팀이 의존하는 도구의 다양성이 증가함에 따라 쉽게 확장되며, Databricks AI/BI, Mosaic AI 등의 강력한 내장 기능을 제공하면서 기존 생태계와의 유연성과 상호 운용성을 유지합니다. 

이 블로그는 Databricks 데이터 인텔리전스 플랫폼을 이용하여 고동시성, 저지연 성능을 극대화하는 방법에 대한 조직의 레이크하우스 아키텍처 여정을 위한 종합적인 가이드를 제공합니다—초기 설계부터 중간 구현, 그리고 지속적인 최적화까지. 우리가 탐구할 것:

• 데이터 웨어하우스의 핵심 구조 요소와 그들이 플랫폼 성능에 미치는 종합적인 영향.
• 이러한 구조 요소의 최적화를 안내하는 구조화된 성능 튜닝 프레임워크.
• 규모에 따른 지속적인 성능을 보장하기 위한 모니터링 전략과 튜닝 방법론에 대한 모범 사례.
• 이 원칙들이 실제로 어떻게 함께 작동하는지 보여주는 실제 사례 연구.

주요 아키텍처 고려사항

전통적인 데이터 웨어하우스의 기본 원칙들이 여전히 적용되지만 - 예를 들어, 탄탄한 데이터 모델링, 강력한 데이터 관리 및 내장된 데이터 품질 - 생산용 분석을 위한 현대적인 레이크하우스를 설계하는 것은 보다 전체적인 접근 방식을 필요로 합니다. 이에 중심이 되는 것은 통합 거버넌스 프레임워크이며, Unity Catalog (AWS | Azure | GCP)는 이를 제공하는 데 중요한 역할을 합니다. 모든 데이터 및 AI 자산에 걸쳐 접근 제어, 계보 추적 및 감사 가능성을 표준화함으로써, Unity Catalog는 규모에 따른 일관된 거버넌스를 보장합니다. 이는 데이터 볼륨, 사용자 동시성 및 플랫폼 복잡성이 증가함에 따라 점점 더 필요해지는 요소입니다.

효과적인 디자인이 필요합니다:

1. 입증된 아키텍처 최고의 사례 채택
2. 상호 연결된 구성 요소 간의 트레이드오프에 대한 이해
3. 비즈니스 요구 사항에 기반한 동시성, 지연 및 규모에 대한 명확한 목표

호수가 있는 집에서는 설계 단계 초기에 내린 건축적 선택에 따라 성능 결과가 영향을 받습니다. 이러한 의도적인 디자인 결정들은 다음과 같은 다섯 가지 중요한 축을 통해 현대적인 레이크하우스가 기존 데이터 웨어하우스로부터 어떻게 근본적으로 벗어나는지를 강조합니다:

이러한 아키텍처 고려 사항을 염두에 두고, 고동시성과 저지연을 규모에 맞게 제공할 수 있는 생산용 데이터 웨어하우스를 구현하는 실용적인 프레임워크를 살펴봅시다.

기술 솔루션 분석

다음 프레임워크는 기업 고객과의 실제 업무를 통해 개발된 모범 사례와 구조 원칙을 요약합니다. 새로운 데이터 웨어하우스를 구축하든, 레거시 플랫폼에서 마이그레이션하든, 기존 레이크하우스를 튜닝하든, 이 가이드라인은 생산 시간을 단축하면서 확장 가능하고, 성능이 우수하고, 비용 효율적인 결과를 제공하는 데 도움이 될 것입니다.

사용 사례 중심의 평가로 시작하십시오

구현하기 전에, 가장 느린 대시보드나 가장 자원이 많이 필요한 파이프라인과 같은 중요한 작업 부하에 대한 빠른 평가를 권장합니다. 이 접근법은 성능 차이를 식별하고 최적화를 위한 영역을 우선 순위로 지정하는 데 도움이 됩니다.

다음 질문들로 분석을 구성하십시오:

• 가장 중요한 성능 지표는 무엇이며 (예: 쿼리 지연, 처리량, 동시성), 이들은 비즈니스 기대치와 어떻게 비교되나요?
• 이 작업 부하를 누가, 언제, 얼마나 자주 사용하나요?
• 컴퓨팅 비용은 업무 가치에 비례하나요?

이 평가는 목표 개선을 위한 기반을 만들고, 최적화 노력을 비즈니스 영향과 일치시키는 데 도움이 됩니다.

구현 프레임워크

아래 프레임워크는 Databricks에서 웨어하우스를 구현하거나 현대화하는 단계별 접근법을 개요화합니다:

1. 현재 상태 평가 및 목표 우선 순위 설정
   • 성능, 비용, 확장성 목표와 비교하여 기존 아키텍처를 평가하고 비교합니다.
   • 동시성, 지연, 규모, 비용, SLA 등의 비즈니스(및 기술) 요구 사항을 정의하여 목표가 계속 바뀌지 않도록 하십시오.
   • 비즈니스에 가장 큰 영향을 미치는 차이점을 식별하고 가치와 복잡성에 기반하여 개선을 우선 순위로 지정합니다 (신규 설계, 이전 중 또는 생산 중인 경우).
2. 웨어하우스 아키텍처와 거버넌스 정의
   • 논리적 세분화 설계: 어떤 팀이나 사용 사례가 SQL 웨어하우스를 공유하거나 전용으로 필요한지 결정합니다.
   • 웨어하우스를 적절한 크기로 조정하고, 태깅을 적용하고 기본값을 정의합니다(예: 캐시 설정, 시간 초과 등).
   • 기본 캐싱, 웨어하우스 타임아웃, BI 도구에서의 JDBC 타임아웃 및 SQL 구성 매개변수와 같은 세부적인 구성을 이해하고 계획하십시오(AWS | Azure | GPC).
   • 웨어하우스 관리 모델을 수립하고 관리자 (AWS | Azure | GCP)와 최종 사용자 (AWS | Azure | GCP)의 역할과 책임을 다룹니다.
   • 투자하고 교육 을 제공하고 구현 템플릿을 제공하여 팀 간 일관성을 보장합니다.
3. 관찰 가능성 활성화
   • SQL 웨어하우스 사용에 대한 관찰 및 모니터링을 활성화하여 이상 징후를 탐지하고, 비효율적인 작업 부하를 찾아내고, 리소스 사용을 최적화합니다.
   • 박스 밖의 기능을 활성화하십시오 (AWS | Azure | GCP) 그리고 사용자 정의 텔레메트리와 가능한 곳에서 경고/수정을 자동화하십시오.
   • 시스템 테이블, 웨어하우스 모니터링 및 쿼리 프로필을 활용하여 spill, shuffle 또는 queuing과 같은 문제를 식별하는 방법을 배웁니다.
   • 비용 데이터와 계보 메타데이터(예: 쿼리 히스토리 테이블을 통한 BI 도구 컨텍스트)를 통합하여 성능과 지출을 상관시킵니다.
4. 최적화 및 모범 사례 구현
   • 관찰 가능성에서 얻은 통찰력을 활용하여 작업 부하 성능을 비즈니스 및 기술 요구 사항과 일치시킵니다.
   • 비용, 레이아웃, 컴퓨팅 효율성을 위한 AI 기능 을 구현합니다.
   • 학습 내용을 재사용 가능한 템플릿, 문서 및 체크리스트로 코딩하여 팀 간에 모범 사례를 확장하십시오.
   • 노력 (복잡성, 시간, 전문성) 대 영향 (성능, 비용, 유지 관리 오버헤드) 매트릭스를 사용하여 점진적으로 최적화합니다.

아래 섹션에서는 이 프레임워크의 각 단계를 살펴보며, 신중한 설계와 실행이 어떻게 Databricks에서 고동시성, 저지연 및 비즈니스와 연계된 비용 성능을 가능하게 하는지 이해해봅시다.

현재 상태 평가 및 목표 우선 순위 설정

베스트 프랙티스와 튜닝 기법에 대해 깊이 파고들기 전에, 컴퓨트 크기 조정, 데이터 레이아웃 및 데이터 모델링과 같이 lakehouse 성능을 형성하는 기본적인 레버를 이해하는 것이 중요합니다. 이들은 팀이 고동시성, 저지연, 규모 목표를 달성하기 위해 직접 영향을 줄 수 있는 영역입니다.

아래의 점수표는 각 레버에 대한 성숙도를 평가하고 노력을 집중할 곳을 식별하는 간단한 매트릭스를 제공합니다. 이를 사용하려면, 각 레버를 다음 세 가지 차원에서 평가하십시오: 비즈니스 요구 사항을 얼마나 잘 충족하는지, 베스트 프랙티스와 얼마나 잘 일치하는지, 팀이 해당 영역에서 보유한 기술 능력의 수준과 거버넌스입니다. 각 교차점에 빨강-황색-녹색 (RAG) 등급을 적용하여 강점 (녹색), 개선 필요 영역 (황색) 및 중요한 공백 (빨강)을 빠르게 시각화합니다. 이 블로그의 후반부에 있는 모범 사례와 평가 기법은 이 등급을 결정하는 데 도움이 될 것입니다 - 이 방향성을 더 세밀한 성숙도 평가와 함께 사용하세요. 이 연습은 팀 간의 대화를 안내하고, 숨겨진 병목 현상을 드러내고, 훈련이나 아키텍처 변경, 자동화에 투자할 곳을 결정하는 데 도움이 될 수 있습니다.

레이크하우스 성능을 주도하는 구성 요소와 그것들을 구현하는 프레임워크가 정의되면, 다음은 무엇인가요? 모범 사례(무엇 을 할 것인가), 튜닝 기법(어떻게 할 것인가) 및 평가 방법(언제 할 것인가)의 조합은 성능 목표를 달성하기 위한 행동을 제공합니다. 

특정한 모범 사례와 세부적인 구성 기법에 초점을 맞추어, 고성능 데이터 웨어하우스를 운영하는 데 중요한 몇 가지 구성 요소가 조화롭게 작동하도록 합니다.

웨어하우스 아키텍처와 거버넌스 정의

컴퓨트 (Databricks SQL 웨어하우스)

컴퓨팅이 종종 주요 성능 레버로 간주되지만, 컴퓨팅 크기 결정은 항상 데이터 레이아웃 설계 및 모델링/쿼리와 함께 고려되어야 합니다. 이들은 필요한 성능을 달성하기 위해 필요한 컴퓨팅에 직접적인 영향을 미칩니다.

SQL 웨어하우스의 적절한 크기 조정은 비용 효과적인 확장에 중요합니다. 정확한 크기 조정을 위한 크리스탈 볼은 없지만, SQL 웨어하우스 컴퓨트를 구성하고 크기를 조정하기 위한 주요 휴리스틱을 따르는 것이 좋습니다.

• SQL 서버리스 웨어하우스 활성화: 즉시 컴퓨트, 탄력적인 자동 확장을 제공하며 완전히 관리되어, 버스티하고 일관성 없는 BI/분석 워크로드를 포함한 모든 유형의 사용에 대한 운영을 단순화합니다. Databricks는 인프라를 완전히 관리하며, 그 인프라 비용이 포함되어 있어 TCO 감소의 가능성을 제공합니다.
• 워크로드와 사용자 이해: 사용자 (인간/자동화)와 그들의 쿼리 패턴 (대화형 BI, ad hoc, 예약된 보고서)을 세분화하여 애플리케이션 컨텍스트, 목적, 팀, 기능 등에 의한 논리적 그룹화로 범위를 정하는 다른 웨어하우스를 사용합니다. 이러한 세분화에 따라 다중 웨어하우스 아키텍처를 구현하여 더 세밀한 크기 조정 제어와 독립적인 모니터링 기능을 갖게 됩니다. 비용 속성을 위한 태그가 강제되어야 합니다. 소음을 일으키는 이웃을 방지하기 위한 다가오는 기능에 대한 액세스를 위해 Databricks 계정 담당자에게 연락하십시오.
• 반복적인 크기 조정 및 확장: 초기 웨어하우스 크기나 최소/최대 클러스터 설정에 대해 과도하게 생각하지 마십시오. 다음 섹션의 메커니즘을 사용하여 실제 워크로드 성능을 모니터링하여 조정하는 것이 upfront 추측보다 훨씬 효과적입니다. 데이터 볼륨과 사용자 수는 필요한 컴퓨트를 정확히 추정하지 않습니다. 쿼리의 유형, 패턴 및 쿼리 부하의 동시성은 더 나은 메트릭이며, Intelligent Workload Management (IWM) (AWS | Azure | GCP)에서 자동화된 이점이 있습니다.
• 크기 조정 vs. 확장 시기 이해: 자원이 많이 필요한 복잡한 쿼리를 수용해야 할 때 (예: 대규모 집계 및 다중 테이블 조인과 같은) 웨어하우스 크기 ("티셔츠 크기")를 늘립니다. 이는 높은 메모리를 필요로 하며, 디스크 스파일의 빈도와 메모리 사용률을 모니터링합니다. 폭발적인 동시 사용과 많은 쿼리가 실행을 기다리는 결과로 인한 지속적인 대기 상황을 처리할 때 클러스터 수를 늘립니다. 이는 몇 가지 강력한 쿼리가 대기 중이 아닙니다.
• 가용성과 비용의 균형: 자동 중지 설정을 구성합니다. 서버리스의 빠른 콜드 스타트는 유휴 시간에 대한 중요한 비용 절약 방법입니다.

레이크하우스에서의 물리적 데이터(파일) 레이아웃

빠른 쿼리는 데이터 스킵에서 시작되며, 쿼리 엔진은 메타데이터와 통계를 사용하여 관련 파일만 읽어 효율적인 파일 정리를 수행합니다. 데이터의 물리적 구성은 이러한 프루닝에 직접적인 영향을 미치므로, 파일 레이아웃 최적화는 고동시성, 저지연 성능에 중요합니다.

Databricks에서 데이터 레이아웃 기법의 진화는 최적의 파일 조직을 위한 다양한 접근법을 제공합니다.

새로운 테이블에 대해 Databricks는 기본적으로 관리 테이블 을 사용하고 Auto Liquid Clustering 을 사용하는 것을 권장합니다 (AWS | Azure | GCP) 그리고 Predictive Optimization (AWS | Azure | GCP). Auto Liquid Clustering은 쿼리 패턴에 기반하여 데이터를 지능적으로 조직화하며, 단일 명령에서 활성화하기 위한 힌트로 초기 클러스터링 열을 지정할 수 있습니다. Predictive Optimization은 자동으로 OPTIMIZE, VACUUM 및 ANALYZE와 같은 유지 보수 작업을 처리합니다. 

외부 테이블을 사용하는 기존 배포에 대해, 이러한 AI 기반 기능을 최대한 활용하기 위해 관리 테이블로 마이그레이션을 고려하십시오. 우선적으로 높은 읽기 및 지연 민감 테이블을 우선시하십시오. Databricks는 자동화된 솔루션(AWS | Azure | GCP)을 제공하며, ALTER TABLE...SET MANAGED 명령을 사용하여 마이그레이션 과정을 단순화합니다. 또한, Databricks는 오픈 테이블 형식 전략의 일부로 관리 Iceberg 테이블을 지원합니다.

데이터 모델링 / 쿼리

모델링은 비즈니스 요구사항이 데이터 구조를 만나는 곳입니다. 항상 최종 소비 패턴을 이해하고, 김볼, 인몬, 데이터 볼트 또는 비정규화 접근법을 사용하여 조직의 선호 방법론에 따라 이러한 비즈니스 요구 사항을 모델링하십시오. Databricks의 레이크하우스 아키텍처는 모두를 지원합니다.

Unity Catalog 의 기능은 계보, 기본 키(PK), 제약 조건, 스키마 진화 기능을 포함하여 관찰 및 발견을 넘어서 확장됩니다. 이들은 Databricks 쿼리 최적화기에 중요한 힌트를 제공하여 더 효율적인 쿼리 계획을 가능하게 하고 쿼리 성능을 향상시킵니다. 예를 들어, PK와 외래 키 를 RELY 를 사용하여 선언하면 최적화기가 중복 조인을 제거할 수 있어 속도에 직접적인 영향을 미칩니다. Unity Catalog의 강력한 스키마 진화 지원은 데이터 모델이 시간이 지남에 따라 적응하면서도 유연성을 보장합니다. Unity Catalog는 ANSI SQL 기반의 표준 거버넌스 모델을 제공합니다.

추가적으로 관련된 자료로는 데이터 웨어하우징 모델링 기법 과 차원 데이터 웨어하우징에 대한 3부작 시리즈(Part 1, Part 2 및 Part 3)가 있습니다.

관찰 가능성 활성화

모니터링 활성화와 액션 튜닝 결정은 컴퓨트, 물리적 파일 레이아웃, 쿼리 효율성 등 데이터 웨어하우스 구성 요소의 상호 연결성을 완벽하게 강조합니다. 

1. 대시보드와 애플리케이션을 통해 관찰 가능성을 확립하는 것으로 시작합니다.
2. 성능 병목 현상을 식별하고 진단한 후 수정하는 패턴을 정의합니다.
3. 알림과 에이전트 수정 작업을 통해 자동화를 반복적으로 구축합니다.
4. 병목 현상을 일으키는 일반적인 추세를 컴파일하고 이를 개발 모범 사례, 코드 리뷰 체크 및 템플릿에 통합합니다.

지속적인 모니터링은 생산에서 지속적으로 높은 일관된 성능과 비용 효율성을 유지하는 데 필수적입니다. 표준 패턴을 이해하면 사용 패턴이 변화함에 따라 튜닝 결정을 세밀하게 조정할 수 있습니다.

모니터링 및 조정: 각 웨어하우스의 내장된 모니터링 탭 (AWS | Azure | GCP)을 사용하여 최대 동시 쿼리, 사용률 및 기타 주요 통계에 대한 실시간 인사이트를 얻습니다. 이는 관찰을 위한 빠른 참조를 제공하지만, 알림 및 조치를 촉진하기 위한 추가 기법으로 보완해야 합니다.

• 3에 특히 주의를 기울이십시오. 이는 주어진 웨어하우스에 대한 동시성 제한으로 인해 대기열이 발생하며 (크기 조정에 의해 영향을 받을 수 있음) 및 5는 대기열에 대한 응답으로 자동 확장 이벤트를 보여줍니다. 6 은 쿼리 기록을 캡처하며, 오래 실행되고 비효율적인 워크로드를 식별하고 조사하는 데 좋은 시작점입니다.

시스템 테이블 활용: 더 세밀하고 맞춤형 모니터링을 지원합니다. 시간이 지남에 따라 사용자 정의 대시보드와 알림을 개발하지만, 준비된 제안을 활용하세요:

• The Granular SQL Warehouse Monitoring Dashboard 는 누가 비용을 발생시키는지, 무엇이 비용을 발생시키는지 이해함으로써 정보를 기반으로 한 확장 결정에 대한 종합적인 시각을 제공합니다.
• The DBSQL Workflow Advisor 는 스케일링, 쿼리 성능을 통해 병목 현상과 비용 속성을 식별하는 뷰를 제공합니다.
• 맞춤형 SQL 알림을 도입합니다 (AWS | Azure | GCP) 위의 모니터링 이벤트에서 배운 내장 알림을 위해.

SQL 웨어하우스 이상의 비용 속성 및 관찰 가능성에 관심이 있는 고객들에게는, 이 전용 블로그, Databricks와 함께하는 비용 성숙도 여정: 혼돈에서 제어로가 귀중한 자료가 될 것입니다.

쿼리 프로파일 사용:  쿼리 프로파일 (AWS | Azure | GCP) 도구는 개별 쿼리 성능 문제에 대한 주요 진단 도구입니다. 이 도구는 자세한 실행 계획을 제공하고 필요한 컴퓨트에 영향을 미치는 병목 현상을 찾아내는 데 도움이 됩니다.

쿼리 프로필에서 찾아볼 시작점 제안 몇 가지:

• 프루닝이 발생하는지 확인합니다. 프루닝이 발생해야 하는 경우 (AWS | Azure | GCP) (즉, 테이블의 메타데이터/통계를 사용하여 저장소에서 읽는 데이터를 줄임), 이는 예측 또는 조인을 적용하면 예상되지만 발생하지 않는 경우, 파일 레이아웃 전략을 분석합니다. 이상적으로, 읽어야 하는 파일/파티션 수는 낮아야 하며, 프루닝해야 하는 파일 수는 높아야 합니다.
• "스케줄링"에서 몇 초 이상의 상당한 양의 벽시계 시간이 소비되는 것은 대기열을 제안합니다.
• '클라이언트에 의한 결과 가져오기' 시간이 대부분을 차지하면 외부 도구/응용 프로그램과 SQL 웨어하우스 간의 네트워크 문제를 나타낼 수 있습니다.
• 캐시에서 읽은 바이트는 사용 패턴에 따라 다르며, 동일한 테이블에서 동일한 웨어하우스를 사용하여 쿼리를 실행하는 사용자는 파일을 다시 스캔하는 대신 캐시된 데이터를 자연스럽게 활용할 것입니다.
• DAG (Directed Acyclic Graph–AWS | Azure | GCP)를 사용하면 시간이 걸린 단계, 사용된 메모리, 읽은 행 수를 식별할 수 있습니다. 이는 매우 복잡한 쿼리에 대한 성능 문제를 좁히는 데 도움이 될 수 있습니다.
• 작은 파일 문제 를 감지하려면 (데이터 파일이 최적 크기보다 훨씬 작아서 처리가 비효율적인 경우), 이상적으로 평균 파일 크기는 테이블 크기에 따라 128MB에서 1GB 사이여야 합니다:
  • 쿼리 계획의 대부분이 소스 테이블을 스캔하는 데 사용됩니다.
  • 실행 DESCRIBE DETAIL [Table Name]. 평균 파일 크기를 찾으려면, sizeInBytes 를 numFiles로 나눕니다. 또는, 쿼리 프로파일에서 [Bytes read] / [Files read]를 사용합니다.
• 비효율적인 shuffle hash join을 감지하려면:
  • DAG에서 조인 단계를 선택하고 "Join algorithm"을 확인합니다.
  • 파일 프루닝이 없거나 적습니다.
  • DAG에서 셔플은 두 테이블(조인의 양쪽, 왼쪽 이미지와 같이)에서 모두 발생합니다. 테이블 중 하나가 충분히 작다면, 브로드캐스트 해시 조인 을 수행하도록 고려하십시오(오른쪽 이미지에 표시).
    • 적응형 쿼리 실행(AQE)은 브로드캐스트 조인에 대해 <=30 MB 데이터 크기를 기본값으로 합니다 - 일반적으로 데이터 크기가 200 MB 미만인 테이블은 브로드캐스팅을 평가하기 위한 좋은 후보입니다. 1 GB는 하드 한계입니다.
  • 항상 필터를 적용하여 소스 데이터 세트를 줄이는 것을 확인합니다.

최적화 및 모범 사례 구현

성능 문제: 4 S's + 큐잉

새로운 작업 부하에 대한 컴퓨트를 구성하거나 최적화하는 경우, 가장 일반적인 성능 문제를 이해하는 것이 필요합니다. 이들은 일반적인 별칭인 "4 S's"에 들어가며, 추가로 (큐잉)이 추가되었습니다:

SQL 웨어하우스에서 쿼리 지연을 줄이려면 spill, queuing 그리고/또는 shuffle (skew 와 작은 파일들은 나중에 다룰 예정)이 주요 성능 병목 현상인지 확인하세요. 이 종합 가이드는 더 많은 세부 정보를 제공합니다. 루트 원인을 확인한 후, 아래의 가이드라인을 적용하여 SQL 웨어하우스 크기를 조정하고 영향을 측정하세요.

• 디스크 스플 (메모리에서 디스크로): SQL 웨어하우스가 메모리를 모두 사용하면 임시 결과를 디스크에 쓰는 스플이 발생하며, 이는 메모리 내 처리보다 훨씬 느립니다. 쿼리 프로필에서 "spill (bytes)" 또는 "spill time"에 대한 어떤 금액이라도 이것이 발생하고 있음을 나타냅니다.

스파일을 완화하기 위해, SQL 웨어하우스 T-셔츠 크기를 늘려 더 많은 메모리를 제공합니다. 쿼리 메모리 사용량은 또한 조기 필터링, 왜곡 감소 및 조인 단순화와 같은 쿼리 최적화 기법을 통해 줄일 수 있습니다. 적절한 크기의 파일을 사용하거나 Liquid Clustering을 적용하여 파일 레이아웃을 개선하면 실행 중에 스캔 및 셔플되는 데이터의 양을 더욱 제한할 수 있습니다.

시스템 테이블에 대한 도우미 쿼리는 SQL 알림 또는 AI/BI 대시보드로 변환될 수 있습니다.

• 쿼리 대기열: SQL 웨어하우스 모니터링 화면에서 지속적인 대기열(피크 대기 쿼리가 >10인 경우)이 자동 스케일링 이벤트로 즉시 해결되지 않으면 웨어하우스의 최대 스케일링 값을 늘립니다. 대기열은 쿼리가 사용 가능한 리소스를 기다리는 동안 직접적으로 지연을 추가합니다.

시스템 테이블에 대한 도우미 쿼리는 SQL 알림 또는 AI/BI 대시보드로 변환될 수 있습니다.

• 높은 병렬화/낮은 셔플: 쿼리가 많은 독립적인 작업으로 분할될 수 있고—예를 들어, 대규모 데이터 세트에 걸친 필터 또는 집계와 같은—Query Profiles에서 셔플이 낮게 나타나는 경우, SQL 웨어하우스 티셔츠 크기를 늘리면 처리량을 향상시키고 대기를 줄일 수 있습니다. 낮은 셔플은 노드 간 데이터 이동이 최소화되어 더 효율적인 병렬 실행을 가능하게 합니다.
• 좁은 변환 (예: 포인트 조회, 집계 조회)은 일반적으로 동시 쿼리 처리를 위한 더 많은 스케일링에서 이익을 얻습니다. Wide transformations (집계가 있는 복잡한 조인)은 일반적으로 스케일링보다 더 큰 웨어하우스 크기에서 더 많은 이점을 얻습니다.
• 높은 셔플: 반대로, 셔플이 높으면 쿼리 실행 중에 노드 간에 대량의 데이터가 교환됩니다. 이는 종종 조인, 집계 또는 잘 정리되지 않은 데이터로 인해 발생합니다. 이는 중요한 성능 병목 현상이 될 수 있습니다. 쿼리 프로파일에서는 "shuffle bytes written", "shuffle bytes read" 아래의 큰 값이나 셔플 관련 단계에서의 긴 지속 시간으로 높은 셔플이 나타납니다. 이러한 메트릭이 지속적으로 높으면, 단순히 컴퓨트를 확장하는 것보다 쿼리를 최적화하거나 물리적 데이터 레이아웃을 개선하는 것이 최선입니다.

시스템 테이블에 대한 도우미 쿼리는 SQL 알림 또는 AI/BI 대시보드로 변환될 수 있습니다.

매크로 모니터링 뷰 취하기

이러한 분석과 규칙은 쿼리가 웨어하우스에 미치는 영향을 미시적 수준에서 이해하는 데 도움이 되지만, 크기 결정은 매크로 수준에서 이루어집니다. 일반적으로, 이전 섹션의 모니터링 기능을 활성화하고(그리고 사용자 정의) 무슨 일이 일어나는지 확인한 다음, 스파일, 왜곡, 대기열 등에 대한 임계치 측정을 설정하여 리사이징이 필요한 시점의 지표로 사용합니다. 이 임계값들을 평가하여 임계값이 충족되는 빈도나 정상 운영 중에 임계값이 초과되는 시간의 비율에 따라 영향 점수를 생성합니다. 몇 가지 예시 측정치를 공유하려면(이를 특정 비즈니스 요구 사항 및 SLA를 사용하여 정의):

• 하루 중 피크 큐에 대기 중인 쿼리가 10개 이상인 시간의 비율
• 장기간에 걸쳐 상위 5%의 셔플이 가장 많거나 피크 사용 시간 동안 일관되게 상위 5%의 셔플이 가장 많은 쿼리
• 쿼리가 디스크로 넘치는 경우가 쿼리의 20% 이상이거나, 쿼리가 실행될 때 25% 이상 디스크로 넘치는 경우

이를 인식하는 것이 필요하며, 고려해야 할 상충 관계가 있으며, 따라야 할 단일 레시피나 모든 데이터 웨어하우스에 일괄적으로 적용할 수 있는 것은 없습니다. 대기 시간이 문제가 아니라면, 새벽에 새로 고침하는 쿼리에 대해서는 초저지연을 위해 튜닝하지 않고 높은 지연 시간으로 비용 효율성을 인식할 수 있습니다. 이 블로그는 고유한 구현 요구 사항에 기반한 데이터 웨어하우스의 진단 및 튜닝 방법에 대한 모범 사례와 방법론에 대한 가이드를 제공합니다.

레이크하우스에서 물리적 데이터(파일) 레이아웃 최적화

아래에는 레이크하우스에 저장된 물리적 데이터 파일을 관리하고 최적화하는 데 도움이 되는 몇 가지 모범 사례가 있습니다. 이러한 기법과 모니터링 기법을 사용하여 데이터 웨어하우스 분석 작업에 영향을 미치는 문제를 진단하고 해결하십시오.

• 필요한 경우 테이블의 데이터 스킵을 조정하십시오 (AWS | Azure | GCP). Delta 테이블은 기본적으로 처음 32개 열에 대한 최소/최대 및 기타 통계 메타데이터를 저장합니다. 이 숫자를 늘리면 DML 작업 실행 시간이 늘어날 수 있지만, 추가 열이 쿼리에서 필터링되는 경우 쿼리 실행 시간을 줄일 수 있습니다.
• 작은 파일 문제가 있는지 확인하려면 테이블 속성(numFiles, sizeInBytes, clusteringColumns, partitionColumns)을 검토하고, 예측 최적화와 Liquid Clustering를 사용하거나, 적절하게 구성된 데이터 위에 OPTIMIZE 압축 루틴을 실행하도록 합니다.
• 자동 액체 클러스터링을 활성화하고 수동 튜닝을 제거하기 위해 예측 최적화를 활용하는 것이 권장되지만, 기본적인 모범 사례를 이해하고 선택적으로 수동으로 튜닝할 수 있는 능력을 갖추는 것이 도움이 됩니다. 클러스터링 열을 선택하기 위한 유용한 경험 법칙은 다음과 같습니다:
  • 단일 열부터 시작하십시오. 이는 가장 자연스럽게 술어로 사용되는 열입니다(아래의 제안을 사용), 명확한 후보가 몇 개 있지 않다면. 종종, 큰 테이블만이 >1 클러스터 키에서 이익을 얻습니다.
  • 사용할 열을 우선 순위로 두면 읽기를 쓰기보다 최적화하는 데 우선 순위를 둡니다. 그들은 1) 필터 술어로 사용되어야 하며, 2) GROUP BY 또는 JOIN 작업에 사용되어야 하며, 3) MERGE 열이어야 합니다.
  • 일반적으로, 높은 카디널리티를 가져야 합니다(하지만 고유하지는 않음). 해당 열에서 빠른 조회가 필요하지 않는 한 UUID 문자열과 같은 의미 없는 값을 피하세요.
  • 파티션 열을 설정할 때처럼 카디널리티를 줄이지 마세요 (예: 타임스탬프를 날짜로 변환).
  • 두 개의 관련 열(예: 타임스탬프와 날짜스탬프)을 사용하지 마세요 - 항상 카디널리티가 더 높은 것을 선택하세요.
  • CREATE TABLE 구문에서 키의 순서는 중요하지 않습니다. 다차원 클러스터링이 사용됩니다.

모든 것을 함께 가져오기: 체계적인 접근법

이 블로그는 첫 세 가지 구조적 레버에 초점을 맞춥니다. 기타 중요한 구현 구성 요소들이 ETL/ELT, 인프라 프린트, DevOps 및 거버넌스를 포함하여 고동시성, 확장 가능하고, 지연 시간이 짧은 데이터 웨어하우스를 구축하는 데 기여합니다. 레이크하우스를 구현하는 추가 제품 관점은 여기에서 찾을 수 있으며, Databricks, Spark 및 Delta Lake 작업을 최적화하기 위한 종합 가이드에서 다양한 모범 사례를 찾을 수 있습니다.

데이터 웨어하우스의 기본 구성 요소인 컴퓨트, 데이터 레이아웃 및 모델링/쿼리는 매우 상호 의존적입니다. 성능을 효과적으로 개선하려면 반복적인 과정이 필요합니다: 지속적으로 모니터링하고, 최적화하고, 새로운 작업 부하가 최적화된 청사진을 준수하도록 보장합니다. 그리고 기술 모범 사례가 변경되고 비즈니스 요구사항이 변경됨에 따라 그 청사진을 발전시키십시오. 웨어하우스를 정확한 동시성, 지연 시간 및 확장성 요구사항에 맞게 조정하는 도구와 지식이 필요합니다. 강력한 거버넌스, 투명성, 모니터링 및 보안이 이 핵심 구조 프레임워크를 가능하게 합니다. 이들은 별개의 고려 사항이 아니라 Databricks에서 최고 수준의 데이터 웨어하우스 경험을 제공하는 기반입니다.

이제, 프레임워크와 기본적인 베스트 프랙티스, 튜닝 및 모니터링 레버가 실제로 적용되어 조직이 데이터 웨어하우스 성능과 효율성을 크게 향상시킨 최근의 고객 예를 살펴보겠습니다.

실제 시나리오와 타협

이메일 마케팅 플랫폼 최적화

비즈니스 컨텍스트

이메일 마케팅 플랫폼은 e-commerce 소매업체에게 풍부한 고객 데이터를 기반으로 개인화된 고객 여정을 만드는 도구를 제공합니다. 이 애플리케이션은 사용자가 이메일 캠페인을 대상 고객에게 조정하도록 하여, 클라이언트가 세분화 전략을 수립하고 성능을 추적하는 데 도움이 됩니다. 실시간 분석은 그들의 비즈니스에 매우 중요합니다 - 고객들은 클릭률, 바운스 및 참여 데이터와 같은 캠페인 성능 지표에 대한 즉시적인 가시성을 기대합니다.

초기 도전

플랫폼은 분석 인프라에 성능 및 비용 문제를 겪고 있었습니다. 그들은 대형 SQL 서버리스 웨어하우스를 운영하고 있었고, 1-5 클러스터로 자동 확장하며, 심지어 피크 보고 기간 동안 XL로 업그레이드해야 했습니다. 그들의 아키텍처는 다음에 의존하였습니다:

1. 지속적인 구조화된 스트리밍을 통해 메시지 큐에서 델타 레이크로 실시간 스트리밍 데이터
2. 스트림된 레코드를 히스토리 테이블로 통합하는 야간 작업
3. 과거 테이블과 스트리밍 데이터 사이의 쿼리 시간 유니온
4. 쿼리 시간에 복잡한 집계 및 중복 제거 로직 실행

이 접근 방식은 모든 고객 대시보드 새로 고침이 강력한 처리를 필요로 하므로 비용이 더 많이 들고 응답 시간이 느려집니다.

SQL 웨어하우스를 모니터링하다 보니, 상당한 큐잉 (노란색 열)이 있었으며, 사용량이 급증하는 기간에는 오토스케일링이 적절하게 작동했지만 작업 부하를 따라잡지 못했습니다:

대기열의 원인을 진단하기 위해, 쿼리 이력(AWS | Azure | GCP)과 시스템 테이블을 사용하여 대기열이 단순히 기본적이고 좁은 쿼리의 높은 볼륨 때문인지, 아니면 성능이 떨어지는 쿼리를 개선하기 위해 최적화가 필요한지를 판단하기 위해 몇 가지 장시간 실행 쿼리와 가장 자주 실행되는 쿼리를 확인했습니다. 

이는 장기 실행 쿼리의 예제 프로필에서 몇 가지 중요한 지적입니다:

• 낮은 프루닝 (가장 최근 2주를 반환하기 위해 시간 기간에 대한 상당한 필터링에도 불구하고)은 스캔되는 데이터량이 상당하다는 것을 의미합니다.
• 높은 셔플—분석적 집계로 인해 셔플이 필연적으로 발생하지만, 이는 과거와 최근 데이터에 걸친 메모리 사용의 대부분입니다.
• 일부 경우에 디스크로의 스파일.

이러한 중요한 쿼리를 관찰한 결과, 컴퓨트, 데이터 레이아웃 및 쿼리 기법에 걸쳐 최적화 작업을 수행하게 되었습니다.

최적화 접근법

Databricks 배송 솔루션 아키텍트와 함께 작업하여, 플랫폼은 몇 가지 핵심 최적화를 구현했습니다:

1. 병합 빈도 증가: 매일 밤에서 매시간으로 변경된 병합, 이로 인해 쿼리 시간에 처리가 필요한 스트리밍 데이터의 양이 크게 줄었습니다.
2. Materialized Views 구현: 집계 테이블을 매시간 증분적으로 새로 고침하는 materialized view로 변환하여 쿼리 시간 처리가 최근 1시간의 데이터에만 제한되도록 복잡한 집계 로직을 새로 고침하는 동안 사전 계산합니다.
3. 현대적인 데이터 조직: Hive 스타일 파티셔닝에서 쿼리 패턴에 기반한 최적의 클러스터링 열을 지능적으로 선택하고 시간이 지남에 따라 적응하는 자동 액체 클러스터링으로 전환했습니다.

결과

6주간의 발견 및 구현 과정 후, 플랫폼은 배포 즉시 눈에 띄는 개선을 보았습니다:

1. 인프라 비용 감소: 자동 스케일링이 있는 대형 서버리스 웨어하우스에서 자동 스케일링이 없는 소형 서버리스 웨어하우스로 축소하였습니다.
2. 개선된 쿼리 성능: 최종 사용자 대시보드의 지연 시간이 줄어들어 고객 경험이 향상되었습니다.
3. 간소화된 운영: 자주 발생하는 최종 사용자 성능 불만과 지원 사례로 인한 운영 오버헤드가 제거되었습니다.

최적화 후의 쿼리 프로필 예시:

• 파일 레이아웃이 최적화되면서 읽어야 할 데이터/파일의 양을 줄이기 위해 더 많은 파일 pruning이 발생했습니다.
• 디스크로의 스폴 없음.
• 분석적 집계로 인해 셔플이 여전히 발생하지만, 더 효율적인 프루닝과 런타임에 계산할 필요가 없는 사전 집계된 요소로 인해 셔플량이 크게 줄어듭니다.

이 변환은 데이터 모델링 모범 사례를 적용하고, 서버리스 컴퓨팅을 활용하고, Databricks의 고급 기능인 materialized views와 liquid clustering을 사용함으로써 성능과 비용 효율성을 크게 향상시키는 방법을 보여줍니다.

주요 핵심 사항

• 데이터 웨어하우스의 동시성, 지연 및 규모에 대한 요구 사항을 중점적으로 고려하십시오. 그런 다음, 최고의 사례, 관찰 가능성 기능 및 튜닝 기법을 사용하여 이러한 요구 사항을 충족하십시오.
• 컴퓨팅의 적절한 크기 조정, 강력한 데이터 레이아웃 실천 (AI에 의해 크게 도움)을 중점적으로 구현하고, 데이터 모델과 쿼리를 우선적으로 처리하십시오.
• 최고의 데이터 웨어하우스는 Databricks 레이크하우스입니다. 새로운 기능으로 이어지는 혁신적인 접근 방식을 활용하고, 기본적인 데이터 웨어하우스 원칙과 결합하십시오.
• AI/ML을 희생하지 않고 전통적인 데이터 웨어하우싱 요구 사항을 충족하십시오 (Databricks와 함께 이를 활용하고 있습니다).
• 크기를 무작정 지정하고 튜닝하지 마십시오; 내장된 관찰 가능성을 활용하여 모니터링, 최적화 및 비용 절약 작업을 자동화하십시오.
• 최적의 가격 성능과 BI 및 분석 워크로드의 변동 사용 패턴을 지원하기 위해 Databricks SQL Serverless를 채택하십시오.

다음 단계 및 추가 리소스

고동시성, 저지연 데이터 웨어하우스를 확장하는 것은 보일러플레이트 레시피를 따르는 것으로는 이루어지지 않습니다. 고려해야 할 타협이 있으며, 많은 구성 요소가 모두 함께 작동합니다. 데이터 웨어하우징 전략을 확정하거나, 구현 중이며 라이브로 전환하는 데 어려움을 겪고 있거나, 현재의 발자국을 최적화하고 있다면, 이 블로그에서 개요를 제시한 모범 사례와 프레임워크를 고려하여 전체적으로 접근해 보십시오. Databricks가 모든 데이터 웨어하우싱 요구 사항을 지원하는 방법에 대해 논의하거나 도움이 필요하면 연락하십시오.

Databricks Delivery Solutions Architects (DSAs)는 조직 전반의 데이터 및 AI 이니셔티브를 가속화합니다. 그들은 아키텍처 리더십을 제공하고, 플랫폼을 비용과 성능에 최적화하며, 개발자 경험을 향상시키고, 성공적인 프로젝트 실행을 주도합니다. DSAs는 초기 배포와 생산용 솔루션 사이의 격차를 메우며, 데이터 엔지니어링, 기술 리드, 경영진 및 기타 이해관계자를 포함한 다양한 팀과 긴밀하게 협력하여 맞춤형 솔루션과 더 빠른 가치 창출을 보장합니다. DSA로부터 맞춤 실행 계획, 전략적 지침 및 데이터 및 AI 여정 전반에 걸친 지원을 받으려면 Databricks 계정 팀에 문의하십시오.

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