Microsoft Fabric의 Synapse Data Warehouse 성능 지침
적용 대상✅: Microsoft Fabric 내 Warehouse
Microsoft Fabric에서 웨어하우스의 성능을 이해하는 데 도움이 되는 지침입니다. 이 문서에서는 집중해야 할 지침과 중요한 문서를 찾을 수 있습니다. Microsoft Fabric의 Warehouse는 워크로드 관리, 동시성 및 스토리지 관리와 같은 활동이 플랫폼에서 내부적으로 관리되는 SaaS 플랫폼입니다. 이 내부 성능 관리 외에도 잘 설계된 웨어하우스에 대한 성능 쿼리를 개발하여 성능을 향상시킬 수 있습니다.
콜드 실행(콜드 캐시) 성능
로컬 SSD 및 메모리 를 사용한 캐싱은 자동으로 수행됩니다. 쿼리의 처음 1-3 실행은 후속 실행보다 눈에 띄게 느리게 수행됩니다. 콜드 실행 성능 문제가 발생하는 경우 콜드 실행 성능을 향상시킬 수 있는 몇 가지 작업을 수행할 수 있습니다.
첫 번째 실행의 성능이 중요한 경우 수동으로 통계를 만들어 보세요. 통계 문서를 검토하여 통계의 역할을 더 잘 이해하고 쿼리 성능을 개선하기 위해 수동 통계를 만드는 방법에 대한 지침을 확인하세요. 그러나 첫 번째 실행의 성능이 중요하지 않은 경우 첫 번째 쿼리에서 생성되는 자동 통계에 의존할 수 있으며 이후 실행에서 계속 활용될 수 있습니다(기본 데이터가 크게 변경되지 않는 한).
Power BI를 사용하는 경우 가능한 경우 Direct Lake 모드를 사용합니다.
성능 모니터링 메트릭
현재 모니터링 허브에는 웨어하우스가 포함되지 않습니다. 데이터 웨어하우스를 선택하는 경우 탐색 모음에서 모니터링 허브에 액세스할 수 없습니다.
패브릭 관리자는 웨어하우스를 포함하는 용량의 사용률을 추적하는 최신 정보에 대한 용량 사용률 및 메트릭 보고서에 액세스할 수 있습니다.
DMV(동적 관리 뷰)를 사용하여 쿼리 실행 모니터링
DMV(동적 관리 뷰)를 사용하여 웨어하우스에서 연결, 세션 및 요청 상태를 모니터링할 수 있습니다.
통계
웨어하우스는 쿼리 엔진을 사용하여 지정된 SQL 쿼리에 대한 실행 계획을 만듭니다. 쿼리를 제출할 때 쿼리 최적화 프로그램은 가능한 모든 계획을 열거하고 가장 효율적인 후보를 선택하려고 합니다. 오버헤드가 가장 적은 계획을 결정하려면 엔진에서 각 연산자가 처리할 수 있는 작업량 또는 행의 양을 평가할 수 있어야 합니다. 그런 다음 각 계획의 비용에 따라 예상 작업량이 가장 적은 계획을 선택합니다. 통계는 쿼리 최적화 프로그램에서 이러한 비용을 예측할 수 있도록 데이터에 대한 관련 정보를 포함하는 개체입니다.
또한 각 데이터 로드 또는 데이터 업데이트 후 통계를 수동으로 업데이트하여 최상의 쿼리 계획을 작성할 수 있도록 할 수 있습니다.
자세한 정보 통계 및 자동으로 생성된 통계를 보강하는 방법은 패브릭 데이터 웨어하우징의 통계를 참조 하세요.
데이터 수집 지침
웨어하우스로의 데이터 수집에는 다음과 같은 네 가지 옵션이 있습니다.
- COPY(Transact-SQL)
- 데이터 파이프라인
- 데이터 흐름
- 웨어하우스 간 수집
가장 적합한 옵션을 결정하고 일부 데이터 수집 모범 사례를 검토하려면 수집 데이터를 검토합니다.
INSERT 문을 일괄 처리로 그룹화(트리클 삽입 방지)
다음 예제와 같이 INSERT 문이 있는 작은 테이블에 한 번 로드하는 것이 요구 사항에 따라 가장 좋은 방법일 수 있습니다. 그러나 하루 종일 수천 또는 수백만 개의 행을 로드해야 하는 경우 싱글톤 INSERTS가 최적이 아닙니다.
INSERT INTO MyLookup VALUES (1, 'Type 1')
이러한 세류 로드 시나리오를 처리하는 방법에 대한 지침은 데이터 수집 모범 사례를 참조 하세요.
트랜잭션 크기 최소화
INSERT, UPDATE 및 DELETE 문은 트랜잭션에서 실행됩니다. 이러한 명령문이 실패하면 롤백되어야 합니다. 긴 롤백의 가능성을 줄이려면 되도록이면 트랜잭션 크기를 최소화합니다. INSERT, UPDATE 및 DELETE 문을 여러 부분으로 나누어 트랙잭션 크기를 최소화할 수 있습니다. 예를 들어 1시간이 소요될 것으로 예상되는 INSERT가 있는 경우 INSERT를 네 부분으로 나눌 수 있습니다. 그러면 각 실행이 15분으로 단축됩니다.
CTAS(Transact-SQL)를 사용하여 DELETE를 사용하는 대신 테이블에 유지할 데이터를 작성하는 것이 좋습니다. CTAS에 동일한 시간이 걸리는 경우 트랜잭션 로깅을 최소화하고 필요한 경우 신속하게 취소할 수 있으므로 실행하는 것이 안전합니다.
클라이언트 애플리케이션 및 Microsoft Fabric 배치
클라이언트 애플리케이션을 사용하는 경우 클라이언트 컴퓨터와 가까운 지역에서 Microsoft Fabric을 사용하고 있는지 확인합니다. 클라이언트 애플리케이션의 예로 Power BI Desktop, SQL Server Management Studio 및 Azure Data Studio가 있습니다.
별표 스키마 데이터 디자인 활용
별표 스키마는 데이터를 팩트 테이블 및 차원 테이블로 구성합니다. 고도로 정규화된 OLTP 시스템에서 데이터를 비정규화하고, 트랜잭션 데이터 및 엔터프라이즈 마스터 데이터를 쿼리 시간에 조인을 최소화하고, 읽는 행 수를 줄이고, 집계 및 그룹 처리를 용이하게 하는 일반적이고 정리되고 검증된 데이터 구조로 수집하여 분석 처리를 용이하게 합니다.
더 많은 웨어하우스 디자인 지침은 데이터 웨어하우징의 테이블을 참조 하세요.
쿼리 결과 집합 크기 줄이기
쿼리 결과 집합 크기를 줄이면 큰 쿼리 결과로 인한 클라이언트 쪽 문제를 방지할 수 있습니다. SQL 쿼리 편집기 결과 집합은 이 브라우저 기반 UI에서 이러한 문제를 방지하기 위해 처음 10,000개 행으로 제한됩니다. 10,000개 이상의 행을 반환해야 하는 경우 SSMS(SQL Server Management Studio) 또는 Azure Data Studio를 사용합니다.
성능에 가장 적합한 데이터 형식 선택
테이블을 정의할 때 데이터를 지원하는 가장 작은 데이터 형식을 사용하면 쿼리 성능이 향상됩니다. 이 권장 사항은 CHAR 및 VARCHAR 열에 중요합니다. 열에서 가장 긴 값이 25자인 경우 열을 VARCHAR(25)로 정의합니다. 기본 길이가 큰 모든 문자 열을 정의하지 마세요.
가능하다면 정수 기반 데이터 형식을 사용합니다. SORT, JOIN 및 GROUP BY 작업은 문자 데이터보다 정수에서 더 빠르게 수행됩니다.
지원되는 데이터 형식 및 자세한 내용은 데이터 형식을 참조 하세요.
SQL 분석 엔드포인트 성능
SQL 분석 엔드포인트의 성능에 대한 정보 및 권장 사항은 SQL 분석 엔드포인트 성능 고려 사항을 참조 하세요.