다음을 통해 공유


Azure Synapse Analytics의 전용 SQL 풀(이전의 SQL DW)에 대한 참고 자료

이 참고 자료는 전용 SQL 풀(이전의 SQL DW) 솔루션을 빌드하는 데 유용한 팁과 모범 사례를 제공합니다.

다음 그래픽에서는 전용 SQL 풀(이전의 SQL DW)을 사용하여 데이터 웨어하우스를 설계하는 프로세스를 보여 줍니다.

Sketch

테이블에서 쿼리 및 작업

데이터 웨어하우스에서 실행할 기본 작업 및 쿼리를 미리 알고 있으면 이러한 작업에 대한 데이터 웨어하우스 아키텍처의 우선 순위를 지정할 수 있습니다. 이러한 쿼리 및 작업에는 다음이 포함될 수 있습니다.

  • 하나 또는 두 개의 팩트 테이블을 차원 테이블과 조인하고, 결합된 테이블을 필터링한 다음, 결과를 데이터 마트에 추가합니다.
  • 팩트 영업에 크거나 작은 업데이트를 수행합니다.
  • 테이블에 데이터만 추가합니다.

작업 유형을 알고 있으면 테이블의 디자인을 최적화하는 데 유용합니다.

데이터 마이그레이션

먼저 Azure Data Lake Storage 또는 Azure Blob Storage에 데이터를 로드합니다. 그런 다음, COPY 문을 사용하여 데이터를 준비 테이블에 로드합니다. 다음 구성을 사용합니다.

디자인 권장
배포 라운드 로빈
인덱싱
분할 없음
리소스 클래스 largerc 또는 xlargerc

데이터 마이그레이션, 데이터 로드, ELT(추출, 로드 및 변환) 프로세스에 대해 자세히 알아보세요.

분산 또는 복제된 테이블

테이블 속성에 따라 다음 전략을 사용합니다.

Type 적합한 대상 유의해야 하는 경우...
복제됨 * 압축 후 2GB 스토리지 이하 별모양 스키마의 소형 차원 테이블(~5배 압축) * 많은 쓰기 트랜잭션이 테이블에 있음(예: insert, upsert, delete, update)

* DWU(데이터 웨어하우스 단위) 프로비저닝이 자주 변경됨

* 2-3개 열만 사용하지만 테이블에 많은 열이 있음

* 복제된 테이블을 인덱싱
라운드 로빈(기본값) * 임시/준비 테이블

* 명백한 조인 키 또는 양호한 후보 열이 없음
* 데이터 이동으로 인한 성능 저하
해시 * 팩트 테이블

* 대형 차원 테이블
* 배포 키를 업데이트할 수 없음

:

  • 라운드 로빈으로 시작하지만 대규모 병렬 아키텍처를 활용하는 해시 분산 전략을 목표로 합니다.
  • 공통 해시 키의 데이터 형식이 동일한지 확인합니다.
  • varchar 형식으로 배포하지 마세요.
  • 조인 작업이 빈번한 팩트 테이블에 대한 공통 해시 키가 있는 차원 테이블은 해시 분산될 수 있습니다.
  • sys.dm_pdw_nodes_db_partition_stats를 사용하여 데이터의 모든 왜곡도를 분석합니다.
  • sys.dm_pdw_request_steps를 사용하여 쿼리의 백그라운드 데이터 이동 분석, 시간 브로드캐스트 모니터링 및 작업 순서 섞기를 수행합니다. 이는 분산 전략을 검토하는 데 유용합니다.

복제된 테이블분산 테이블에 대해 자세히 알아보세요.

테이블 인덱싱

인덱싱은 테이블을 빠르게 읽는 데 유용합니다. 필요에 따라 사용할 수 있는 고유한 기술 집합이 있습니다.

Type 적합한 대상 유의해야 하는 경우...
* 스테이징/임시 테이블

* 작은 조회를 통한 소형 테이블
* 전체 테이블을 검색하는 모두 조회
클러스터형 인덱스 * 최대 1억 개 행이 있는 테이블

* 1-2개 열만 많이 사용하는 대형 테이블(1억 개가 넘는 행)
* 복제 테이블에서 사용됨

* 여러 Join, Group By 작업과 관련된 복잡한 쿼리가 있음

* 인덱싱된 열을 업데이트하고 메모리가 필요함
CCI(클러스터형 columnstore 인덱스)(기본값) * 대형 테이블(1억 개가 넘는 행) * 복제 테이블에서 사용됨

* 테이블에서 대량 업데이트 작업 수행

* 테이블을 과도하게 분할하고, 행 그룹이 다른 분산 노드와 파티션에 걸쳐 있지 않음

:

  • 클러스터형 인덱스에 기반하여 필터링에 많이 사용되는 열에 비클러스터형 인덱스를 추가할 수 있습니다.
  • CCI로 테이블에서 메모리를 관리하는 방법에 주의해야 합니다. 데이터를 로드할 때 사용자(또는 쿼리)가 큰 리소스 클래스의 이점을 사용하고자 합니다. 많고 작은 압축 행 그룹을 자르고 만들지 않도록 합니다.
  • Gen2에서 CCI 테이블은 성능을 최대화하기 위해 컴퓨팅 노드에서 로컬로 캐시됩니다.
  • CCI의 경우 행 그룹의 압축 불량으로 인해 성능이 저하될 수 있습니다. 이 경우 CCI를 다시 작성하거나 다시 구성합니다. 압축 행 그룹당 10만 개 이상의 행이 필요합니다. 이상적으로는 하나의 행 그룹에 100만 개 행이 있어야 합니다.
  • 증분 로드 빈도 및 크기에 따라 인덱스를 다시 구성하거나 다시 빌드할 때 자동화하고자 합니다. 봄맞이 대청소는 항상 유용합니다.
  • 행 그룹은 전략적으로 줄입니다. 열려 있는 행 그룹의 크기는? 앞으로 로드할 데이터의 양은?

인덱스에 대해 자세히 알아보세요.

분할

큰 팩트 테이블(10억 개 행 보다 큼)이 있는 경우 테이블을 분할할 수 있습니다. 99%의 경우 파티션 키는 날짜를 기반으로 해야 합니다.

ELT가 필요한 스테이징 테이블을 사용하면 분할의 이점을 활용할 수 있습니다. 데이터 수명 주기 관리가 용이해집니다. 특히 클러스터형 columnstore 인덱스에서 팩트 또는 준비 테이블을 과도하게 분할하지 않도록 주의합니다.

분할에 대해 자세히 알아보세요.

증분 로드

데이터를 증분 방식으로 로드하려면 먼저 더 큰 리소스 클래스를 데이터 로드에 할당해야 합니다. 클러스터형 columnstore 인덱스가 있는 테이블로 로드할 때 특히 중요합니다. 자세한 내용은 리소스 클래스를 참조하세요.

ELT 파이프라인을 데이터 웨어하우스로 자동화하는 데 PolyBase 및 ADF V2를 사용하는 것이 좋습니다.

기록 데이터의 업데이트를 대량으로 일괄 처리하는 경우 INSERT, UPDATE 및 DELETE를 사용하는 대신 CTAS를 사용하여 테이블에 유지할 데이터를 작성하는 것이 좋습니다.

통계 유지 관리

데이터에 중요한 변경 내용이 있는 것 만큼 통계를 업데이트하는 것도 중요합니다. 중요한 변경이 발생했는지 확인하려면 통계 업데이트를 참조하세요. 업데이트된 통계는 쿼리 계획을 최적화합니다. 모든 통계를 유지 관리하는 데 시간이 너무 오래 걸리는 경우 통계가 있는 열을 선택해야 합니다.

또한 업데이트의 빈도를 정의할 수 있습니다. 예를 들어 매일 새 값이 추가될 수 있는 날짜 열을 업데이트할 수 있습니다. 조인에 포함된 열, WHERE 절에 사용된 열 및 GROUP BY에서 찾은 열에 대한 통계를 통해 가장 많은 이점을 얻을 수 있습니다.

통계에 대해 자세히 알아보세요.

리소스 클래스

리소스 그룹은 메모리를 쿼리에 할당하기 위한 방법으로 사용됩니다. 쿼리 또는 로드 속도를 개선하기 위해 더 많은 메모리가 필요한 경우 더 높은 리소스 클래스를 할당해야 합니다. 다른 한편으로, 더 큰 리소스 클래스를 사용하면 동시성에 영향을 줍니다. 모든 사용자를 큰 리소스 클래스로 이동하기 전에 고려해야 할 사항입니다.

쿼리 시간이 오래 걸리는 경우 사용자가 큰 리소스 클래스에서 실행하지 않는지 검사합니다. 큰 리소스 클래스는 많은 동시성 슬롯을 사용합니다. 이는 다른 쿼리를 큐에 대기시킬 수 있습니다.

마지막으로, 전용 SQL 풀(이전의 SQL DW)의 Gen2를 사용하여 각 리소스 클래스가 Gen1보다 2.5배 더 많은 메모리를 가져옵니다.

리소스 클래스 및 동시성으로 작업하는 방법에 대해 자세히 알아보세요.

비용 절감

Azure Synapse의 주요 기능은 컴퓨팅 리소스 관리 기능입니다. 전용 SQL 풀(이전의 SQL DW)을 사용하지 않을 때 일시 중지하여 컴퓨팅 리소스에 대한 청구를 중지할 수 있습니다. 성능 요구를 충족하기 위해 리소스를 확장할 수 있습니다. 일시 중지하려면 Azure Portal 또는 PowerShell을 사용합니다. 확장하려면 Azure Portal, PowerShell, T-SQL 또는 REST API를 사용합니다.

이제 Azure Functions를 통해 원하는 시간에 자동 크기 조정을 수행할 수 있습니다.

Image showing a button labeled

성능을 위한 아키텍처 최적화

허브 및 스포크 아키텍처에서 SQL Database 및 Azure Analysis Services를 고려하는 것이 좋습니다. 이 솔루션은 SQL Database 및 Azure Analysis Services의 고급 보안 기능을 사용하면서 동시에 다른 사용자 그룹 간에 워크로드 격리를 제공할 수 있습니다. 또한 사용자에게 무제한 동시성을 제공하는 방법이기도 합니다.

Azure Synapse Analytics에서 전용 SQL 풀(이전의 SQL DW)을 활용하는 일반적인 아키텍처에 대해 자세히 알아보세요.

전용 SQL 풀(이전의 SQL DW)에서 SQL 데이터베이스의 스포크를 한 번의 클릭으로 배포합니다.

Image showing a button labeled