다음을 통해 공유

성능 효율성 모범 사례

  • 아티클

이 문서에서는 다음 섹션에 나열된 아키텍처 원칙에 따라 구성된 성능 효율성 관련 모범 사례를 설명합니다.

1. 수직 크기 조정, 수평 크기 조정, 선형 확장성

모범 사례를 살펴보기 전에 수평적 크기 조정, 수직 크기 조정, 선형 확장성이라는 몇 가지 분산 컴퓨팅 개념을 살펴보겠습니다.

  • 수직 크기 조정: 단일 컴퓨터에서 리소스를 추가하거나 제거하여 수직으로 크기를 조정합니다(일반적으로 CPU, 메모리 또는 GPU). 이는 일반적으로 워크로드를 중지하고, 더 큰 컴퓨터로 이동하고, 다시 시작하는 것을 의미합니다. 수직 크기 조정에는 제한이 있습니다. 더 큰 컴퓨터가 없거나 다음 더 큰 컴퓨터의 가격이 엄청나게 높을 수 있습니다.
  • 수평 크기 조정: 분산 시스템에서 노드를 추가하거나 제거하여 수평으로 크기를 조정합니다. 수직 크기 조정의 한계에 도달하면 솔루션은 수평으로 크기를 조정합니다. 분산 컴퓨팅은 여러 컴퓨터(클러스터라고 함)가 있는 시스템을 사용하여 워크로드를 실행합니다. 이를 위해서는 Databricks Data Intelligence Platform, Apache Spark, Photon의 엔진에서 지원하는 대로 병렬 실행을 위해 워크로드 준비가 필요하다는 것을 이해해야 합니다. 이렇게 하면 여러 저렴한 컴퓨터를 더 큰 컴퓨팅 시스템으로 결합할 수 있습니다. 더 많은 컴퓨팅 리소스가 필요한 경우 수평 크기 조정은 클러스터에 더 많은 노드를 추가하고 더 이상 필요하지 않을 때 제거합니다. 기술적으로는 제한이 없지만(Spark 엔진이 부하 분산의 복잡한 부분을 수행), 많은 수의 노드로 관리 복잡성이 증가합니다.
  • 선형 확장성은 시스템에 리소스를 더 추가할 때 사용된 처리량과 리소스 간의 관계가 선형이라는 의미입니다. 이는 병렬 작업이 독립적인 경우에만 가능합니다. 그렇지 않은 경우 추가 계산을 위해 클러스터의 다른 노드 집합에서 한 노드 집합에 대한 중간 결과가 필요합니다. 노드 간의 이 데이터 교환에는 한 노드 집합에서 다른 노드 집합으로 네트워크를 통해 결과를 전송하는 작업이 포함되며, 상당한 시간이 걸립니다. 일반적으로 분산 컴퓨팅은 데이터 배포 및 교환을 관리하는 데 약간의 오버헤드가 있습니다. 따라서 분산 시스템에서 실행할 때 단일 노드에서 분석할 수 있는 작은 데이터 세트 워크로드가 더 느려질 수 있습니다. Databricks Data Intelligence 플랫폼은 워크로드의 고유한 요구 사항을 충족하기 위해 유연한 컴퓨팅(단일 노드 및 분산)을 제공합니다.

2. 서버리스 아키텍처 사용

서버리스 컴퓨팅 사용

Databricks Data Intelligence Platform에서 서버리스 컴퓨팅을 사용하면 컴퓨팅 계층이 고객의 Azure Databricks 계정에서 실행됩니다. 서비스는 Databricks에 의해 완전히 관리되고 지속적으로 향상됩니다. 고객이 사용하는 것에 대해서만 비용을 지불하는 것 외에도 생산성이 향상됩니다.

  • 클라우드 관리자는 더 이상 할당량 조정, 네트워크 리소스 만들기 및 유지 관리, 청구 원본 연결과 같은 복잡한 클라우드 환경을 관리할 필요가 없습니다. 낮은 수준의 클라우드 구성 요소를 관리하는 대신 더 높은 가치의 프로젝트에 시간을 집중할 수 있습니다.
  • 사용자는 0에 가까운 클러스터 시작 대기 시간과 향상된 쿼리 동시 실행을 활용할 수 있습니다.

Databricks는 다양한 워크로드에 대해 관리형 서비스를 제공합니다.

  • SQL 워크로드용 서버리스 SQL 웨어하우스

    작업 영역 관리자는 컴퓨팅을 즉시 사용하도록 설정하고 Azure Databricks에서 관리하는 서버리스 SQL 웨어하우스를 만들 수 있습니다. 원래 Databricks SQL 웨어하우스와 마찬가지로 Databricks SQL 쿼리와 함께 사용합니다. 서버리스 컴퓨팅은 SQL 웨어하우스의 시작 시간이 매우 빠르며, Databricks에서 인프라를 관리하고 최적화합니다.

  • 효율적이고 안정적인 워크플로를 위한 서버리스 작업

    작업에 서버리스 컴퓨팅을 사용하면 인프라를 구성하고 배포하지 않고도 Databricks 작업을 실행할 수 있습니다. 서버리스 컴퓨팅을 사용하면 데이터 처리 및 분석 파이프라인을 구현하는 데 집중하고, Databricks가 워크로드에 대한 컴퓨팅 최적화 및 크기 조정을 포함하여 컴퓨팅 리소스를 효율적으로 관리합니다. 자동 크기 조정 및 Photon은 작업을 실행하는 컴퓨팅 리소스에 대해 자동으로 사용하도록 설정됩니다.

    청구 가능한 사용량 시스템 테이블을 쿼리하여 작업에 서버리스 컴퓨팅을 사용하는 작업의 비용을 모니터링할 수 있습니다.

  • Notebooks에 대한 서버리스 컴퓨팅

    작업 영역이 서버리스 대화형 컴퓨팅을 사용하도록 설정된 경우 작업 영역의 모든 사용자는 Notebooks에서 서버리스 컴퓨팅 리소스에 액세스할 수 있습니다. 추가 권한이 필요하지 않습니다.

엔터프라이즈급 모델 서비스 사용

Mosaic AI 모델 서비스는 AI 모델을 배포, 관리 및 쿼리하는 통합 인터페이스를 제공합니다. 서비스하는 각 모델은 웹 또는 클라이언트 애플리케이션에 통합할 수 있는 REST API로 사용할 수 있습니다.

모델 서비스는 모델을 배포하기 위해 가용성이 높고 대기 시간이 짧은 서비스를 제공합니다. 서비스는 수요 변화에 맞게 자동으로 확장 또는 축소되며 대기 시간 성능을 최적화하면서 인프라 비용을 절감합니다. 이 기능은 서버리스 컴퓨팅을 사용합니다.

3. 성능을 위한 워크로드 디자인

데이터 수집 및 액세스 패턴 이해

성능 관점에서 "집계 및 지점 액세스" 또는 "스캔 및 검색"과 같은 데이터 액세스 패턴은 데이터 크기에 따라 다르게 동작합니다. 큰 파일은 스캔 쿼리에 더 효율적이며, 작은 파일은 특정 행을 찾기 위해 더 적은 데이터를 읽어야 하므로 검색에 더 적합합니다.

수집 패턴의 경우 일반적으로 DML 문을 사용합니다. DML 문은 데이터가 클러스터될 때 가장 성능이 향상되며 데이터의 섹션을 격리하기만 하면 됩니다. 수집 중에 데이터를 클러스터링하고 격리 가능한 상태로 유지하는 것이 중요합니다. 자연스러운 시간 정렬 순서를 유지하고 수집 대상 테이블에 가능한 한 많은 필터를 적용하는 것이 좋습니다. 추가 전용 및 덮어쓰기 수집 워크로드의 경우 비교적 저렴한 작업이므로 고려해야 할 사항이 많지 않습니다.

수집 및 액세스 패턴은 종종 명백한 데이터 레이아웃 및 클러스터링을 가리킵니다. 그렇지 않은 경우 비즈니스에 더 중요한 것을 결정하고 해당 목표를 더 잘 달성하는 방법에 집중합니다.

유익한 경우 병렬 계산 사용

가치 실현 시간은 데이터를 사용할 때 중요한 차원입니다. 많은 사용 사례는 단일 머신에서 쉽게 구현할 수 있지만(작은 데이터, 몇 가지 간단한 계산 단계), 대용량 데이터 집합을 처리해야 하거나, 복잡한 알고리즘으로 인해 실행 시간이 길거나, 수백~수천 번 반복해야 하는 사용 사례가 종종 있습니다.

Databricks 플랫폼의 클러스터 환경은 이러한 워크로드를 효율적으로 배포하기에 좋은 환경입니다. 클러스터의 모든 노드에서 SQL 쿼리를 자동으로 병렬 처리하고 Python 및 Scala가 동일한 작업을 수행할 수 있도록 라이브러리를 제공합니다. 내부적으로 Apache Spark 및 Photon 엔진은 쿼리를 분석하고, 최적의 병렬 실행 방법을 결정하고, 탄력적인 방식으로 분산 실행을 관리합니다.

일괄 처리 작업과 동일한 방식으로 구조적 스트리밍은 최상의 성능을 위해 클러스터에 스트리밍 작업을 분산합니다.

병렬 컴퓨팅을 사용하는 가장 쉬운 방법 중 하나는 Delta Live Tables를 사용하는 것입니다. SQL 또는 Python에서 작업의 태스크 및 종속성을 선언한 다음 Delta Live Tables는 실행 계획, 효율적인 인프라 설정, 작업 실행 및 모니터링을 처리합니다.

데이터 과학자가 사용하는 pandas는 Python 프로그래밍 언어용으로 사용하기 쉬운 데이터 구조와 데이터 분석 도구를 제공하는 Python 패키지입니다. 그러나 Pandas는 빅 데이터로 스케일 아웃되지 않습니다. Spark의 Pandas API는 Apache Spark에서 작동하는 pandas와 동등한 API를 제공하여 이 격차를 메웁니다.

또한 플랫폼에는 표준 기계 학습 라이브러리 MLlib에서 병렬화된 기계 학습 알고리즘이 함께 제공됩니다. 기본 제공 다중 GPU 사용을 지원합니다. DeepSpeed 배포자 또는 TorchDistributor를 사용하여 딥 러닝을 병렬 처리할 수도 있습니다.

전체 실행 체인 분석

대부분의 파이프라인 또는 사용 패턴에는 시스템 체인이 포함됩니다. 예를 들어 BI 도구를 사용하면 성능이 다음과 같은 여러 요인에 의해 영향을 받습니다.

  • BI 도구 자체.
  • BI 도구와 SQL 엔진을 연결하는 커넥터.
  • BI 도구가 쿼리를 보내는 SQL 엔진.

동급 최고의 성능을 위해서는 최상의 성능을 위해 전체 체인을 고려하고 선택/조정해야 합니다.

더 큰 클러스터 선호

특히 워크로드가 선형적으로 확장되는 경우 더 큰 클러스터를 계획합니다. 이 경우 워크로드에 큰 클러스터를 사용하는 것은 더 작은 클러스터를 사용하는 것보다 비싸지 않습니다. 단지 더 빠릅니다. 핵심은 워크로드 기간에 클러스터를 임대하는 것입니다. 따라서 두 개의 작업자 클러스터를 스핀업하고 1시간이 걸리는 경우 전체 시간 동안 해당 작업자에 대한 비용을 지불하게 됩니다. 마찬가지로 네 개의 작업자 클러스터를 스핀업하고 30분만 걸리는 경우(선형 확장성이 적용된 경우) 비용은 동일합니다. 비용이 매우 유연한 SLA를 사용하는 기본 동인인 경우 자동 크기 조정 클러스터는 일반적으로 가장 저렴하지만 반드시 가장 빠른 것은 아닙니다.

참고 항목

클러스터를 자동으로 관리하므로 서버리스 컴퓨팅에는 큰 클러스터를 사용하지 않아도 됩니다.

네이티브 Spark 작업 사용

UDF(사용자 정의 함수)는 Spark SQL의 기능을 확장하는 좋은 방법입니다. 그러나 네이티브 함수가 있는 경우 Python 또는 Scala UDF를 사용하지 마세요.

이유:

  • Python과 Spark 간에 데이터를 전송하려면 Serialization이 필요합니다. 이로 인해 쿼리 속도가 크게 느려집니다.
  • 플랫폼에 이미 존재하는 기능을 구현하고 테스트하기 위한 노력이 증가했습니다.

네이티브 함수가 누락되어 Python UDF로 구현해야 하는 경우 Pandas UDF를 사용합니다. Apache 화살표를 사용하면 데이터가 Spark와 Python 간에 효율적으로 앞뒤로 이동할 수 있습니다.

네이티브 플랫폼 엔진 사용

Photon은 데이터 수집, ETL, 스트리밍, 데이터 과학, 대화형 쿼리에서 데이터 레이크에서 직접 저렴한 비용으로 빠른 쿼리 성능을 제공하는 Azure Databricks의 엔진입니다. Photon은 Apache Spark API와 호환되므로 시작하는 것은 코드 변경 및 잠금 없이 켜는 것만큼 쉽습니다.

Photon은 기존 SQL 및 DataFrame API 호출을 더 빠르게 실행하고 워크로드당 총 비용을 줄여주는 고성능 런타임의 일부입니다. Databricks SQL 웨어하우스에서는 Photon이 기본적으로 사용됩니다.

하드웨어 및 워크로드 유형 이해

모든 클라우드 VM이 똑같게 만들어지는 것은 아닙니다. 클라우드 공급자가 제공하는 다양한 컴퓨터 제품군은 모두 서로 다르기 때문에 문제가 될 수 있습니다. RAM과 코어의 명백한 차이점과 프로세서 유형 및 생성, 네트워크 대역폭 보장, 로컬 고속 스토리지 대 로컬 디스크 대 원격 디스크 등에 미묘한 차이점이 있습니다. "스폿" 시장에서도 차이가 있습니다. 워크로드에 가장 적합한 VM 유형을 결정하기 전에 이러한 차이를 이해해야 합니다.

참고 항목

서버리스 컴퓨팅은 클러스터를 자동으로 관리하므로 서버리스 컴퓨팅에는 필요하지 않습니다.

캐싱 사용

캐싱은 자주 액세스하는 데이터를 더 빠른 매체에 저장하여 원래의 데이터 원본에 액세스하는 것과 비교하여 검색하는 데 필요한 시간을 줄입니다. 이로 인해 대기 시간이 짧아지고 응답 시간이 단축되어 애플리케이션의 전반적인 성능과 사용자 환경이 크게 향상될 수 있습니다. 캐싱은 원래 데이터 원본에 대한 요청 수를 최소화하여 네트워크 트래픽 및 데이터 전송 비용을 줄이는 데 도움이 됩니다. 이러한 효율성 향상은 외부 API 또는 종량제 데이터베이스를 사용하는 애플리케이션에 특히 유용할 수 있습니다. 시스템 전체에 부하를 더 균등하게 분산하여 병목 상태 및 잠재적 가동 중지 시간을 방지할 수 있습니다.

Azure Databricks에서 사용할 수 있는 캐싱 유형은 다음과 같습니다. 다음은 각 유형의 특징입니다.

  • 디스크 캐시 사용

    디스크 캐시(이전의 "델타 캐시")는 원격 데이터의 복사본을 가상 머신의 로컬 디스크(예: SSD)에 저장합니다. 광범위한 쿼리의 성능을 향상시킬 수 있지만 임의 하위 쿼리의 결과를 저장하는 데 사용할 수 없습니다. 디스크 캐시는 데이터 파일이 만들어지거나 삭제되는 시기를 자동으로 검색하고 그에 따라 콘텐츠를 업데이트합니다. 디스크 캐싱을 사용할 때 권장되는(그리고 가장 쉬운) 방법은 클러스터를 구성할 때 SSD 볼륨으로 작업자 유형을 선택하는 것입니다. 이러한 작업자는 디스크 캐싱에 대해 사용하도록 설정되고 구성됩니다.

  • Spark 캐싱 방지

    Spark 캐시(.persist() 및 .unpersist() 사용)는 모든 하위 쿼리 데이터와 Parquet 이외의 형식(예: CSV, JSON, ORC)으로 저장된 데이터의 결과를 저장할 수 있습니다. 그러나 쿼리의 잘못된 위치에서 사용하는 경우 모든 메모리를 사용할 수 있으며 쿼리 속도가 크게 느려질 수도 있습니다. 일반적으로 영향을 정확히 알지 못하는 경우 Spark 캐싱을 방지합니다.

  • 쿼리 결과 캐시

    SQL 웨어하우스를 통한 모든 쿼리에 대한 클러스터별 쿼리 결과 캐싱입니다. 쿼리 결과 캐싱을 활용하려면 예를 들어 조건자(예: = NOW())를 사용하지 않는 결정적 쿼리에 집중합니다. 쿼리가 결정적이고 기본 데이터가 델타 형식이고 변경되지 않은 경우 SQL 웨어하우스는 쿼리 결과 캐시에서 직접 결과를 반환합니다.

  • Databricks SQL UI 캐싱

    모든 쿼리 및 레거시 대시보드의 사용자별 캐싱으로 인해 Databricks SQL UI가 생성됩니다.

압축 사용

Azure Databricks의 Delta Lake는 테이블에서 쿼리 읽기 속도를 개선할 수 있습니다. 한 가지 방법은 작은 파일을 더 큰 파일로 병합하는 것입니다. OPTIMIZE 명령을 실행하여 압축을 트리거합니다. 데이터 파일 레이아웃 최적화를 참조하세요.

Delta Lake는 쓰기 및 OPTIMIZE 작업을 위한 대상 파일 크기를 자동으로 구성하는 옵션을 제공합니다. Databricks는 이러한 설정의 대부분을 자동으로 조정하고 적절한 크기의 파일을 검색하여 테이블 성능을 자동으로 개선하는 기능을 사용하도록 설정합니다.

  • 자동 압축은 델타 테이블 파티션 내의 작은 파일을 결합하여 작은 파일 문제를 자동으로 줄입니다. 자동 압축은 테이블에 대한 쓰기가 성공한 후 발생하고 쓰기를 수행한 클러스터에서 동기적으로 실행됩니다. 자동 압축은 이전에 압축되지 않은 파일만 압축합니다.
  • 최적화된 쓰기는 데이터가 작성될 때 파일 크기를 개선하고 테이블의 후속 읽기에 도움이 됩니다. 최적화된 쓰기는 각 파티션에 기록되는 작은 파일의 수를 줄이기 때문에 분할된 테이블에 가장 효과적입니다.

자세한 내용은 데이터 파일 크기를 제어하도록 Delta Lake 구성을 참조하세요.

데이터 건너뛰기 사용

데이터를 건너뛰면 쿼리 조건을 충족하지 않는 데이터를 건너뛰어 쿼리 성능이 크게 향상될 수 있습니다. 따라서 읽고 처리해야 하는 데이터의 양이 줄어들어 쿼리 실행 시간이 빨라집니다.

이를 위해 델타 테이블에 데이터를 쓸 때 데이터 건너뛰기 정보가 자동으로 수집됩니다(기본적으로 Azure Databricks의 Delta Lake는 테이블 스키마에 정의된 처음 32개 열에 대한 통계를 수집합니다). Azure Databricks의 Delta Lake는 쿼리 시 이 정보(최솟값 및 최댓값)를 사용하여 더 빠른 쿼리를 제공합니다. Delta Lake에 대한 데이터 건너뛰기를 참조하세요.

최상의 결과를 얻으려면 동일한 파일 집합에서 관련 정보를 배치하는 기술인 Z 순서 지정을 사용합니다. 이 공동 배치는 Azure Databricks의 Delta Lake 데이터 건너뛰기 알고리즘에서 자동으로 사용됩니다. 이 동작은 Delta Lake에서 읽어야 하는 데이터의 양을 크게 줄입니다.

또는 데이터 레이아웃 결정을 간소화하고 쿼리 성능을 최적화하는 새로운 리퀴드 클러스터링을 사용합니다. 시간이 지남에 따라 분할 및 z 순서 지정을 대체합니다. Databricks에서는 모든 새 델타 테이블에 리퀴드 클러스터링을 설정하는 것이 좋습니다. 리퀴드 클러스터링은 기존 데이터를 다시 작성하지 않고도 클러스터링 키를 다시 정의할 수 있는 유연성을 제공하므로 시간이 지남에 따라 분석 요구 사항과 함께 데이터 레이아웃이 발전할 수 있습니다. Databricks에서는 모든 새 델타 테이블에 리퀴드 클러스터링을 설정하는 것이 좋습니다.

다음과 같은 특징이 있는 테이블은 리퀴드 클러스터링의 이점을 누릴 수 있습니다.

  • 높은 카디널리티 열로 필터링되는 테이블.
  • 데이터 분포가 크게 왜곡된 테이블.
  • 빠르게 늘어나고 유지 관리 및 튜닝 작업이 필요한 테이블.
  • 동시 쓰기 요청을 사용하는 테이블.
  • 시간이 지나면서 액세스 패턴이 변경되는 테이블.
  • 일반적인 파티션 키가 너무 많거나 너무 적은 파티션을 테이블에 만들 수 있는 테이블.

기술에 대한 자세한 내용은 Databricks, Spark, Delta Lake 워크로드 최적화를 위한 포괄적인 가이드를 참조하세요.

Delta Lake에 대한 예측 최적화 사용

예측 최적화를 사용하면 Databricks에서 델타 테이블에 대한 유지 관리 작업을 수동으로 관리할 필요가 없습니다. 예측 최적화를 사용하도록 설정하면 Databricks는 유지 관리 작업의 이점을 얻을 수 있는 테이블을 자동으로 식별하고 사용자에 대해 실행합니다. 유지 관리 작업은 필요에 따라 실행되어 유지 관리 작업에 대한 불필요한 실행과 추적 및 문제 해결 성능과 관련된 부담을 모두 제거합니다.

오버 분할 방지

과거에는 분할이 데이터를 건너뛰는 가장 일반적인 방법이었습니다. 그러나 분할은 정적이며 파일 시스템 계층 구조로 나타납니다. 시간이 지남에 따라 액세스 패턴이 변경되므로 파티션을 쉽게 변경할 수 있는 방법은 없습니다. 분할은 과도하게 분할되는 경우가 많습니다. 즉, 너무 작은 파일이 있는 파티션이 너무 많으면 쿼리 성능이 저하됩니다.

Databricks에서는 크기가 1TB 미만인 테이블을 분할하지 않고 각 파티션의 데이터가 1GB 이상이 될 것으로 예상하는 경우에만 열로 분할하는 것이 좋습니다.

분할보다 더 나은 선택은 Z 순서 지정 또는 최신 리퀴드 클러스터링입니다(위 참조).

조인 성능 최적화

  • 범위 조인 최적화를 고려합니다.

    범위 조인은 간격 또는 간격 겹침 조건의 포인트를 사용하여 두 관계가 조인될 때 발생합니다. Databricks Runtime의 범위 조인 최적화 지원은 쿼리 성능을 대폭 향상시킬 수 있지만 신중한 수동 튜닝이 필요합니다.

  • 적응형 쿼리 실행을 사용합니다.

    AQE(적응 쿼리 실행)는 쿼리 실행 중에 발생하는 쿼리 다시 최적화입니다. 다음과 같은 4가지 주요 기능이 있습니다.

    • 정렬 병합 조인을 브로드캐스트 해시 조인으로 동적으로 변경합니다.
    • 교환 순서 섞기 후 파티션을 동적으로 병합합니다.
    • 정렬 병합 조인 및 순서 섞기 해시 조인에서 기울이기를 동적으로 처리합니다.
    • 빈 관계를 동적으로 감지하고 전파합니다.

    AQE를 사용하도록 설정하는 것이 좋습니다. 다른 기능은 별도로 구성할 수 있습니다.

자세한 내용은 Databricks, Spark, Delta Lake 워크로드 최적화를 위한 포괄적인 가이드를 참조하세요.

분석 테이블을 실행하여 테이블 통계 수집

ANALYZE TABLE 문은 지정된 스키마의 테이블에 대한 통계를 수집합니다. 이러한 통계는 쿼리 최적화 프로그램에서 최적의 쿼리 계획을 생성하거나, 올바른 조인 유형을 선택하거나, 해시 조인에서 올바른 빌드 쪽을 선택하거나, 다방향 조인에서 조인 순서를 보정하는 데 사용됩니다.

이러한 쿼리 최적화를 제대로 활용하려면 ANALYZE TABLE 명령을 정기적으로 실행해야 합니다(이상적으로는 하루에 한 번 또는 데이터가 10% 이상 변경된 경우 중 먼저 발생하는 시점에).

4. 개발 범위에서 성능 테스트 실행

프로덕션 데이터를 나타내는 데이터 테스트

프로덕션 데이터(읽기 전용) 또는 유사한 데이터에 대한 성능 테스트를 실행합니다. 유사한 데이터를 사용하는 경우 볼륨, 파일 레이아웃, 데이터 기울이기와 같은 특성은 성능에 큰 영향을 주므로 프로덕션 데이터와 유사해야 합니다.

리소스 사전 준비 고려

쿼리 및 데이터 형식과 관계없이 클러스터의 첫 번째 쿼리는 항상 후속 쿼리보다 느립니다. 이는 모든 다른 하위 시스템이 시작하고 필요한 모든 데이터를 읽기 때문입니다. 사전 준비는 성능 테스트 결과에 큰 영향을 줍니다.

  • 클러스터 사전 준비: 클러스터 리소스를 여러 계층에서 초기화해야 합니다. 클러스터를 미리 사용할 수 있습니다 Databricks 풀은 유휴 상태의 즉시 사용할 수 있는 인스턴스 집합입니다. 이러한 유휴 상태의 인스턴스를 사용하여 클러스터 노드를 만들면 클러스터 시작 및 자동 크기 조정 시간이 줄어듭니다.
  • 캐시 사전 준비: 캐싱이 설정의 일부인 경우 첫 번째 실행은 데이터가 캐시에 있는지 확인하여 후속 작업을 가속화합니다. 특정 쿼리를 실행하여 캐시를 초기화함으로써 캐시를 사전 준비할 수 있습니다(예: 클러스터를 다시 시작한 후). 이렇게 하면 처음 몇 개 쿼리의 성능이 크게 향상될 수 있습니다.

따라서 다양한 시나리오의 동작을 이해하려면 사전 준비 및 후속 실행 여부와 상관없이 첫 번째 실행의 성능을 테스트합니다.

병목 상태 확인

병목 현상은 프로덕션에서 부하가 증가함에 따라 전반적인 성능을 저하시킬 수 있는 워크로드의 영역입니다. 디자인 타임에 병목 현상을 식별하고 더 높은 워크로드에 대해 테스트하면 워크로드를 프로덕션 환경에서 안정적으로 유지하는 데 도움이 됩니다.

5. 성능 모니터링

쿼리 성능 모니터링

쿼리 성능을 모니터링하면 다양한 쿼리에서 리소스를 사용하는 방법을 이해할 수 있습니다. 느리게 실행되는 쿼리를 식별하여 시스템의 성능 병목 상태를 정확히 파악할 수 있습니다. 중요한 시스템 리소스를 사용하여 불안정 또는 가동 중지 시간을 초래할 수도 있는 쿼리를 식별할 수있습니다. 이 정보는 리소스 할당을 최적화하고, 낭비를 줄이고, 리소스가 효율적으로 사용되고 있는지 확인하는 데 도움이 됩니다.

Databricks Data Intelligence 플랫폼에는 다양한 모니터링 기능(운영 우수성 - 모니터링, 경고 및 로깅 설정 참조)이 있으며, 그 중 일부는 성능 모니터링에 사용할 수 있습니다.

  • 쿼리 프로필: 쿼리 프로필 기능을 사용하여 쿼리 실행 중 성능 병목 현상 문제를 해결합니다. 각 쿼리 작업 및 관련 메트릭(예: 소요 시간, 처리된 행 수, 처리된 행 및 메모리 사용량)을 시각화합니다.
  • SQL 웨어하우스 모니터링:라이브 통계, 최대 쿼리 수 차트, 실행 중인 클러스터 차트, 쿼리 기록 테이블을 확인하여 SQL 웨어하우스를 모니터링합니다.

스트리밍 워크로드 모니터링

스트리밍 모니터링을 사용하면 데이터를 분석하고 발생하는 문제를 감지하여 시스템의 성능 및 동작에 대한 실시간 인사이트를 제공할 수 있습니다. 스트리밍 데이터를 분석하여 추세, 패턴, 최적화 기회를 식별할 수 있습니다. 이렇게 하면 시스템을 미세 조정하고, 리소스 사용률을 개선하고, 비용을 절감하는 데 도움이 됩니다.

스트리밍 쿼리의 경우 Spark UI에서 기본 제공 구조적 스트리밍 모니터링을 사용하거나 Apache Spark 스트리밍 쿼리 수신기 인터페이스를 사용하여 외부 서비스에 메트릭을 푸시합니다.

작업 성능 모니터링

작업 모니터링은 오류, 지연 또는 성능 병목 상태와 같은 Databricks 작업의 문제를 식별하고 해결하는 데 도움이 됩니다. 작업 모니터링은 작업 성능에 대한 인사이트를 제공하여 리소스 사용률을 최적화하고 낭비를 줄이며 전반적인 효율성을 향상시킬 수 있습니다.