Azure Databricks에서 용량에 도달했을 때 해야 할 일을 알아보세요!
Azure Databricks의 용량 제약은 제품 문제가 아니라 Azure의 기본 VM 가용성에서 비롯됩니다. 클러스터가 생성되거나 확장될 때 Azure에서 동적으로 VM을 프로비저닝합니다. 특정 VM SKU가 지역적으로 부족한 경우 클러스터 작업이 중단될 수 있습니다. 가장 효율적인 해결 경로는 Azure 용량 수용 프로세스를 시작할 수 있는 Microsoft 계정 팀에 연락하는 것입니다. 연락하기 전에 구독 ID, 원하는 지역, VM 제품군 및 SKU, 코어 수, 워크로드 특성 및 타임라인과 같은 특정 세부 정보를 준비하는 것이 중요합니다.용량 이해는 세 가지 계층을 포함합니다. Azure 인프라, Azure Databricks 플랫폼 및 Spark 실행 자체입니다. 첫 번째 계층인 Azure 인프라는 VM SKU 가용성, 지역 공급 및 구독 vCPU 할당량에 의해 관리됩니다. 두 번째 계층인 Azure Databricks 플랫폼은 작업, 태스크 및 웨어하우스에 대한 자체 정의된 리소스 제한이 있습니다. 세 번째 계층인 Spark 실행은 병렬 처리, 메모리 압력 및 I/O 수요를 포함합니다. 용량 문제는 종종 보류 중이거나 자동 확장 실패로 인해 클러스터가 멈추는 것과 같은 일관되지 않은 동작으로 나타납니다.진단하려면 클러스터 종료 이유 및 이벤트 로그를 확인한 다음 Azure 활동 로그와 교차 참조하십시오. 지역 용량 부족과 할당량 제한을 구별하십시오. 할당량 문제는 증가 요청이 필요하지만 용량 문제는 VM SKU 변경이 필요할 수 있습니다. 즉각적인 제약에 직면했을 때 비피크 시간에 작업을 다시 시도하거나 다른 VM SKU 또는 제품군으로 전환하십시오. CPU 집약적인 작업의 경우 F 시리즈 또는 I/O 집약적인 워크로드의 경우 L 시리즈와 같은 대체 VM 제품군을 고려하십시오.여러 Azure 지역에 걸쳐 워크스페이스를 배포하여 지역 다양성을 구현하면 용량 제약에 대한 복원력이 향상됩니다. 또한 컴퓨팅을 확장하는 것이 항상 해결책은 아닙니다. 데이터 왜곡 또는 과도한 셔플과 같은 워크로드 설계 문제는 용량 문제를 모방할 수 있습니다. 다시 파티셔닝, 캐싱 및 쿼리 설계를 통해 Spark 실행을 최적화하는 것이 종종 더 효과적입니다. 마지막으로 승인된 용량을 유지하려면 비 서버리스 워크로드의 경우 인스턴스 풀을 구성하여 컴퓨팅을 적극적으로 배포된 상태로 유지하십시오.