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

SQL 분석 엔드포인트를 사용하면 T-SQL 언어 및 TDS 프로토콜을 사용하여 레이크하우스에서 데이터를 쿼리할 수 있습니다. Fabric Data Warehouse 엔진을 활용합니다.

Tip

파일 크기 및 행 그룹 권장 사항을 포함하여 SQL 분석 엔드포인트 사용을 위해 델타 테이블을 최적화하는 포괄적인 워크로드 간 지침은 워크로드 간 테이블 유지 관리 및 최적화를 참조하세요.

모든 Lakehouse에는 하나의 SQL 분석 엔드포인트가 있습니다. 작업 영역의 SQL 분석 엔드포인트 수는 해당 작업 영역에서 프로비전된 Lakehouse 및 미러된 데이터베이스의 수와 일치합니다.

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

Guidance

자동 메타데이터 검색은 레이크하우스에 커밋된 변경 내용을 추적하며 각 Fabric 작업 영역에는 단일 인스턴스가 있습니다. 레이크하우스와 SQL 분석 엔드포인트 간의 동기화 변경에 대한 대기 시간이 증가하는 것을 관찰하는 경우 한 작업 영역에 많은 수의 레이크하우스가 있기 때문일 수 있습니다. 이러한 시나리오에서는 자동 메타데이터 검색이 확장될 수 있으므로 각 레이크하우스를 별도의 워크스페이스로 마이그레이션하는 것을 고려하세요.
Parquet 파일은 디자인상 변경할 수 없습니다. 업데이트 또는 삭제 작업이 있는 경우 델타 테이블은 업데이트 및 삭제 빈도에 따라 시간이 지남에 따라 파일 수를 늘리는 변경 집합이 포함된 새 Parquet 파일을 추가합니다. 유지 관리를 예약하지 않으면 이 패턴은 결국 읽기 오버헤드를 생성하며 이 조건은 변경 내용을 SQL 분석 엔드포인트에 동기화하는 데 걸리는 시간에 영향을 줍니다. 이 문제를 해결하려면 정기적인 레이크하우스 테이블 유지 관리 작업을 예약하세요.
일부 시나리오에서는 레이크하우스에 커밋된 변경 내용이 연결된 SQL 분석 엔드포인트에 표시되지 않는 것을 관찰할 수 있습니다. 예를 들어 Lakehouse에서 새 테이블을 만들 수 있지만 SQL 분석 엔드포인트에는 아직 나열되지 않았습니다. 또는 레이크하우스의 테이블에 많은 수의 행을 커밋할 수 있지만 이 데이터는 SQL 분석 엔드포인트에 아직 표시되지 않습니다. Fabric 포털에서 온디맨드 메타데이터 동기화를 시작하거나 Refresh SQL Analytics 엔드포인트 메타데이터 REST API를 사용할 수 있습니다.
자동 동기화 프로세스는 모든 델타 기능을 지원하지 않습니다. Fabric의 각 엔진에서 지원하는 기능에 대한 자세한 내용은 Delta Lake 테이블 형식 상호 운용성을 참조하세요.
ETL(추출 변환 및 로드) 처리 중에 테이블 변경 내용이 매우 많은 경우 모든 변경 내용이 처리될 때까지 예상되는 지연이 발생합니다.

SQL 분석 엔드포인트 쿼리를 위한 Lakehouse 테이블 최적화

SQL 분석 엔드포인트가 레이크하우스에 저장된 테이블을 읽을 때 쿼리 성능은 기본 Parquet 파일의 물리적 레이아웃에 따라 크게 달라집니다. 엔진은 Parquet 파일 수준에서 스캔을 병렬화합니다. 너무 많은 작은 파일은 파일 및 메타데이터 오버헤드를 증가시키고, 너무 적은 큰 파일은 스캔 병렬성을 제한할 수 있습니다.

Spark에서 작성한 테이블의 경우, Fabric Spark 런타임 2.0 이상 버전에서 기본 설정을 사용하세요. 이 런타임들은 기본적으로 적응형 목표 파일 크기를 통해 테이블별로 가장 최적의 목표 파일 크기를 선택할 수 있게 하며, 작은 테이블은 128MB, 가장 큰 테이블은 1GB까지 가능합니다. 기본 구성 위에 정적인 타겟이나 임의의 행 수 제한을 설정하는 것은 피하세요. 행 제한은 행 너비를 고려하지 않아 좁은 테이블에 작은 파일을 만들 수 있습니다.

Fabric Spark 1.3 런타임을 사용 중이라면, 선택 기능 형태로 제공되는 적응형 타겟 파일 크기와 파일 수준 압축 타겟을 활성화하세요.

V-Order는 주로 Power BI Direct Lake의 이점을 제공하며, 일부 워크로드에서는 압축을 개선할 수 있지만, 일반적으로 SQL 분석 엔드포인트 성능을 최적화하기 위해 기본적으로 필수이거나 권장되지는 않습니다.

기본 쓰기 설정이 테이블 유지보수를 대체하지는 않습니다. 테이블이 바뀔 때 건강한 레이아웃을 유지하기 위해 다음과 같은 방법을 사용하세요:

주기적으로 추가되는 동기식 쓰기 지연이 허용되는 워크로드에 대해서는 자동 압축 을 활성화합니다. 자동 압축은 테이블에 너무 많은 작은 파일이 있을 때만 실행되는 Spark 기능입니다.
자동 압축으로 인한 주기적인 지연 시간이 데이터 업데이트 SLA를 충족하지 못하는 워크로드에 대해 주기적인 OPTIMIZE 작업을 예약하세요.
보존 및 타임 트래블 요구 사항에 따라 VACUUM를 실행하여 Delta 로그가 더 이상 참조하지 않는 파일을 제거하세요. VACUUM 저장 공간을 줄이긴 하지만 활성 파일 레이아웃은 개선되지 않습니다.
고카디널리티 파티셔닝과 많은 작은 파일을 만드는 맞춤형 작성기 구성을 피하세요.

자동 압축을 사용하지 않는 경우, 유지 관리가 필요한 테이블을 식별하려면 OPTIMIZE를 실행하기 전에 데이터 파이프라인과 sys.sp_get_table_health_metrics T-SQL 저장 프로시저를 사용하세요. 자습서는 상태 검사에 따라 Lakehouse 테이블 최적화를 참조하세요.

Note

Lakehouse 테이블의 일반적인 유지 관리에 대한 지침은 Lakehouse에서 테이블 유지 관리 실행을 참조하세요.

파티션 크기 고려 사항

파티션 레이아웃은 SQL 분석 엔드포인트가 변경 사항을 발견하고 동기화하는 데 걸리는 시간을 달라줍니다. 많은 파티션이나 작은 Parquet 파일은 메타데이터 스캐닝 오버헤드를 증가시킵니다. 다음 사례를 따릅니다.

각 고유값마다 파티션을 생성할 수 있으므로 카디널리티가 높은 분할 열은 피하세요. 1GB에 근접하거나 그 이상의 파티션을 생성하는 열을 선택하세요. 자세한 내용은 델타 레이크 테이블 분할을 참조하세요.
배치 및 스트리밍 인제스팅은 변경이 잦거나 작을 때 작은 파일을 생성할 수 있습니다. 이 파일을 압축하기 위해 정기적으로 호숫가 테이블 관리를 하세요.

각 파티션의 크기와 파일 수를 평가하려면 파티션 세부 정보를 위해 샘플 스크립트를 사용하세요.

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

다음 노트북을 사용하여 델타 테이블을 지지하는 파티션의 크기와 세부 정보를 상세히 담은 보고서를 출력하세요.

먼저, 변수 delta_table_path에 델타 테이블의 ABFSS 경로를 제공하세요.
- 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']}")

피드백

이 페이지가 도움이 되었나요?

2026-09-16 에 마지막으로 업데이트됨