SQL 분석 엔드포인트 성능 고려 사항

아티클
10/31/2024

적용 대상:✅ Microsoft Fabric의 SQL 분석 엔드포인트

SQL 분석 엔드포인트를 사용하면 T-SQL 언어 및 TDS 프로토콜을 사용하여 Lakehouse에서 데이터를 쿼리할 수 있습니다. 모든 Lakehouse에는 하나의 SQL 분석 엔드포인트가 있습니다. 작업 영역의 SQL 분석 엔드포인트 수는 해당 작업 영역에서 프로비전된 Lakehouse 및 미러된 데이터베이스의 수와 일치합니다.

백그라운드 프로세스는 Lakehouse에서 변경 내용을 검사하고 작업 영역의 Lakehouse에 커밋된 모든 변경 내용에 대해 SQL 분석 엔드포인트를 최신 상태로 유지하는 작업을 담당합니다. 동기화 프로세스는 Microsoft Fabric 플랫폼에서 투명하게 관리됩니다. Lakehouse에서 변경 내용이 감지되면 백그라운드 프로세스가 메타데이터를 업데이트하고 SQL 분석 엔드포인트는 Lakehouse 테이블에 커밋된 변경 내용을 반영합니다. 정상 작동 조건에서는 Lakehouse와 SQL 분석 엔드포인트 간의 지연 시간이 1분 미만입니다. 실제 시간 길이는 이 문서에서 구분되는 여러 요인에 따라 몇 초에서 분까지 달라질 수 있습니다.

Lakehouse의 SQL 분석 엔드포인트에서 자동으로 생성된 스키마

SQL 분석 엔드포인트는 작업 영역 사용자가 수정할 수 없도록 자동으로 생성된 테이블을 관리합니다. 사용자는 고유한 SQL 스키마, 뷰, 프로시저 및 기타 데이터베이스 개체를 추가하여 데이터베이스 모델을 보강할 수 있습니다.

Lakehouse의 모든 델타 테이블에 대해 SQL 분석 엔드포인트는 dbo 스키마에 테이블을 자동으로 생성합니다. SQL 분석 엔드포인트에 대한 자동 생성된 스키마 데이터 형식은 Microsoft Fabric의 데이터 형식을 참조하세요.

SQL 분석 엔드포인트의 테이블은 약간의 지연으로 만들어집니다. 레이크에서 Delta Lake 테이블을 만들거나 업데이트하면 Delta Lake 테이블을 참조하는 SQL 분석 엔드포인트 테이블이 자동으로 생성/새로 고쳐집니다.

테이블을 새로 고치는 데 걸리는 시간은 델타 테이블의 최적화 방식과 관련이 있습니다. 자세한 내용은 Delta Lake 테이블 최적화 및 V-Order를 검토하여 주요 시나리오에 대해 자세히 알아보고, 최대 성능을 위해 델타 테이블을 효율적으로 유지하는 방법에 대한 자세한 가이드를 참조하세요.

Fabric 포털에서 자동 메타데이터 검사를 수동으로 새로 고칠 수 있습니다. SQL 분석 엔드포인트 페이지의 탐색기 도구 모음에서 새로 고침 단추를 선택하여 스키마를 새로 고칩니다. SQL 분석 엔드포인트 쿼리로 이동하여 다음 이미지와 같이 새로 고침 단추를 찾습니다.

지침

자동 메타데이터 검색은 Lakehouse에 커밋된 변경 내용을 추적하며 Fabric 작업 영역당 단일 인스턴스입니다. Lakehouse와 SQL 분석 엔드포인트 간의 동기화 변경에 대한 대기 시간이 증가하는 것을 관찰하는 경우 한 작업 영역에 많은 수의 Lakehouse가 있기 때문일 수 있습니다. 이러한 시나리오에서는 자동 메타데이터 검색의 크기를 조정할 수 있으므로 각 Lakehouse를 별도의 작업 영역으로 마이그레이션하는 것이 좋습니다.
Parquet 파일은 디자인상 변경할 수 없습니다. 업데이트 또는 삭제 작업이 있는 경우 델타 테이블은 업데이트 및 삭제 빈도에 따라 시간 경과에 따라 파일 수를 늘려 변경 집합이 있는 새 parquet 파일을 추가합니다. 예약된 유지 관리가 없는 경우 결국 이 패턴은 읽기 오버헤드를 생성하며 이는 변경 내용을 SQL 분석 엔드포인트에 동기화하는 데 걸리는 시간에 영향을 줍니다. 이 문제를 해결하려면 일반 Lakehouse 테이블 유지 관리 작업을 예약합니다.
일부 시나리오에서는 Lakehouse에 커밋된 변경 내용이 연결된 SQL 분석 엔드포인트에 표시되지 않는 것을 관찰할 수 있습니다. 예를 들어 Lakehouse에서 새 테이블을 만들었을 수도 있지만 SQL 분석 엔드포인트에는 나열되지 않습니다. 또는 Lakehouse의 테이블에 많은 수의 행을 커밋했을 수 있지만 이 데이터는 SQL 분석 엔드포인트에 표시되지 않습니다. SQL 쿼리 편집기 새로 고침 리본 옵션에서 트리거되는 주문형 메타데이터 동기화를 시작하는 것이 좋습니다. 이 옵션은 백그라운드 메타데이터 동기화가 완료되기를 기다리는 대신 주문형 메타데이터 동기화를 강제로 수행합니다.
모든 델타 기능이 자동 동기화 프로세스에서 이해되는 것은 아닙니다. 패브릭의 각 엔진에서 지원하는 기능에 대한 자세한 내용은 Delta Lake 상호 운용성을 참조하세요.

파티션 크기 고려 사항

Lakehouse에서 델타 테이블에 대한 파티션 열을 선택하면 변경 내용을 SQL 분석 엔드포인트에 동기화하는 데 걸리는 시간에도 영향을 줍니다. 파티션 열의 파티션 수와 크기는 성능에 중요합니다.

카디널리티가 높은 열(대부분 또는 전적으로 고유 값으로 만든)은 많은 수의 파티션을 생성합니다. 많은 수의 파티션은 변경 내용에 대한 메타데이터 검색 스캔의 성능에 부정적인 영향을 줍니다. 열의 카디널리티가 높은 경우 분할할 다른 열을 선택합니다.
각 파티션의 크기도 성능에 영향을 줄 수 있습니다. 1GB 이상(또는 이에 가까운)의 파티션을 생성하는 열을 사용하는 것이 좋습니다. 델타 테이블 유지 관리, 최적화에 대한 모범 사례를 따르는 것이 좋습니다. 파티션을 평가하는 python 스크립트는 파티션 세부 정보에 대한 샘플 스크립트를 참조하세요.

크기가 작은 parquet 파일의 양이 많으면 Lakehouse 및 연결된 SQL 분석 엔드포인트 간의 변경 내용을 동기화하는 데 걸리는 시간이 늘어나게 됩니다. 하나 이상의 이유로 델타 테이블에 많은 수의 parquet 파일이 있을 수 있습니다.

고유 값 수가 많은 델타 테이블에 대한 파티션을 선택하는 경우 각 고유 값으로 분할되고 과도하게 분할될 수 있습니다. 카디널리티가 높지 않고 개별 파티션 크기가 1GB 이상인 파티션 열을 선택합니다.
일괄 처리 및 스트리밍 데이터 수집 속도는 Lakehouse에 기록되는 변경 빈도 및 크기에 따라 작은 파일을 생성할 수도 있습니다. 예를 들어 Lakehouse로 들어오는 적은 양의 변경 내용이 있을 수 있으며 이로 인해 작은 parquet 파일이 생성됩니다. 이 문제를 해결하려면 일반 Lakehouse 테이블 유지 관리를 구현하는 것이 좋습니다.

파티션 세부 정보에 대한 샘플 스크립트

다음 Notebook을 사용하여 델타 테이블을 뒷받침하는 파티션의 크기 및 세부 정보를 자세히 설명하는 보고서를 인쇄합니다.

먼저 변수 delta_table_path에서 델타 테이블에 대한 ABSFF 경로를 제공해야 합니다.
- Fabric 포털 탐색기에서 델타 테이블의 ABFSS 경로를 가져올 수 있습니다. 테이블 이름을 마우스 오른쪽 단추로 클릭한 다음 옵션 목록에서 COPY PATH를 선택합니다.
스크립트는 델타 테이블에 대한 모든 파티션을 출력합니다.
스크립트는 각 파티션을 반복하여 파일의 총 크기와 수를 계산합니다.
스크립트는 파티션, 파티션당 파일 및 파티션당 크기(GB)의 세부 정보를 출력합니다.

전체 스크립트는 다음 코드 블록에서 복사할 수 있습니다.

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
  from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
  delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

다음을 통해 공유

SQL 분석 엔드포인트 성능 고려 사항

Lakehouse의 SQL 분석 엔드포인트에서 자동으로 생성된 스키마

지침

파티션 크기 고려 사항

파티션 세부 정보에 대한 샘플 스크립트

피드백

추가 리소스

다음을 통해 공유

SQL 분석 엔드포인트 성능 고려 사항

Lakehouse의 SQL 분석 엔드포인트에서 자동으로 생성된 스키마

지침

파티션 크기 고려 사항

파티션 세부 정보에 대한 샘플 스크립트

관련 콘텐츠

피드백

추가 리소스