구체화된 보기 모니터링

2025-02-05

적용 대상: ✅Microsoft Fabric ✅Azure Data Explorer

다음과 같은 방법으로 구체화된 뷰의 상태를 모니터링합니다.

Azure Monitor사용하여 Azure Portal 구체화된 뷰 메트릭을 모니터링합니다. 구체화된 뷰 연령 메트릭(MaterializedViewAgeSeconds)을 기본 메트릭으로 사용하여 뷰의 새로 고침을 모니터링합니다.

Microsoft Fabric 작업 영역에서 구체화된 보기 메트릭을 모니터링합니다. 구체화된 뷰 연령 메트릭을 기본 메트릭으로 MaterializedViewAgeSeconds 사용하여 뷰의 새로 고침을 모니터링합니다. 자세한 내용은 작업 영역 모니터링 사용참조하세요.

.show materialized-view사용하여 IsHealthy 속성을 모니터링합니다.
를 사용하여 .show materialized-view failures오류를 확인합니다.

참고 항목

구체화는 지속적인 오류가 있더라도 데이터를 건너뛰지 않습니다. 뷰는 항상 원본 테이블의 모든 레코드에 따라 쿼리의 최신 스냅샷을 반환하도록 보장됩니다. 일정한 오류로 인해 쿼리 성능이 크게 저하되지만 뷰 쿼리에서 잘못된 결과가 발생하지는 않습니다.

비정상 구체화된 뷰 문제 해결

MaterializedViewAge 메트릭이 지속적으로 증가하고 MaterializedViewHealth 메트릭에 보기가 비정상임을 표시하는 경우 다음 권장 사항에 따라 근본 원인을 식별합니다.

클러스터의 구체화된 뷰 수와 구체화된 뷰의 현재 용량을 확인합니다.
```
.show capacity 
| where Resource == "MaterializedView"
| project Resource, Total, Consumed
```
출력

자원 합계 소비

MaterializedView 1 0
- 동시에 실행할 수 있는 구체화된 뷰 수는 Total 열에 표시된 용량에 따라 달라지지만 Consumed 열에는 현재 실행 중인 구체화된 뷰 수가 표시됩니다. 구체화된 뷰 용량 정책 사용하여 최소 및 최대 동시 작업 수를 지정하고 시스템의 기본 동시성 수준을 재정의할 수 있습니다. 시스템은 클러스터의 사용 가능한 리소스에 따라 Total표시된 현재 동시성을 결정합니다. 다음 예제에서는 시스템의 결정을 재정의하고 최소 동시 작업을 1에서 3으로 변경합니다.
```
.alter-merge cluster policy capacity '{  "MaterializedViewsCapacity": { "ClusterMinimumConcurrentOperations": 3 } }'
```
- 이 정책을 명시적으로 변경하는 경우 클러스터의 상태를 모니터링하고 다른 워크로드가 이 변경의 영향을 받지 않는지 확인합니다.

자원	합계	소비
MaterializedView	1	0

.show materialized-view 오류사용하여 구체화 프로세스 중에 오류가 있는지 확인합니다.
- 오류가 영구적이면 시스템에서 구체화된 뷰를 자동으로 사용하지 않도록 설정합니다. 사용하지 않도록 설정되었는지 확인하려면 .show materialized-view 명령을 사용하고 IsEnabled 열의 값이 false있는지 확인합니다. 그런 다음 .show journal 명령을 사용하여 저널 사용 안 함 이벤트를 확인합니다. 영구 실패의 예는 구체화된 뷰와 호환되지 않는 원본 테이블 스키마 변경입니다. 자세한 내용은 .create materialized-view 명령참조하세요.
- 오류가 일시적인 경우 시스템은 자동으로 작업을 다시 시도합니다. 그러나 오류가 발생하면 구체화가 지연되고 구체화된 뷰의 기간이 늘어나게 될 수 있습니다. 이러한 유형의 오류는 예를 들어 메모리 제한에 도달하거나 쿼리 제한 시간을 초과할 때 발생합니다. 일시적인 오류를 해결하는 더 많은 방법은 다음 권장 사항을 참조하세요.
.show 명령 및 쿼리 명령을 사용하여 구체화 프로세스를 분석합니다. Databasename 및 ViewName 대체하여 특정 보기를 필터링합니다.
```
.show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"
```
- MemoryPeak 열의 메모리 사용량을 확인하여 런어웨이 쿼리 같은 메모리 제한에 도달하여 실패한 작업을 식별합니다. 기본적으로 구체화 프로세스는 노드당 15GB 메모리 피크로 제한됩니다. 구체화 프로세스 중에 실행된 쿼리 또는 명령이 이 값을 초과하면 메모리 제한으로 인해 구체화에 실패합니다. 노드당 메모리 최대 메모리를 늘리려면 $materialized 보기 워크로드 그룹변경합니다. 다음 예제에서는 구체화하는 동안 노드당 최대 64GB 메모리 피크를 사용하도록 구체화된 뷰 워크로드 그룹을 변경합니다.
```
.alter-merge workload_group ['$materialized-views'] ```
{
  "RequestLimitsPolicy": {
    "MaxMemoryPerQueryPerNode": {
      "Value": 68719241216
    }
  }
} 
```
  참고 항목
  
  MaxMemoryPerQueryPerNode 각 노드에서 사용할 수 있는 총 메모리의 50%를 초과할 수 없습니다.
- 구체화 프로세스가 콜드 캐시에 도달하는지 확인합니다. 다음 예제에서는 구체화된 뷰에 대한 지난 날의 캐시 통계를 ViewName.
```
.show commands-and-queries 
| where ClientActivityId startswith "DN.MaterializedViews;ViewName"
| where StartedOn > ago(1d)
| extend HotCacheHits = tolong(CacheStatistics.Shards.Hot.HitBytes), 
         HotCacheMisses = tolong(CacheStatistics.Shards.Hot.MissBytes), 
         HotCacheRetrieved = tolong(CacheStatistics.Shards.Hot.RetrieveBytes), 
         ColdCacheHits = tolong(CacheStatistics.Shards.Cold.HitBytes), 
         ColdCacheMisses = tolong(CacheStatistics.Shards.Cold.MissBytes), 
         ColdCacheRetrieved = tolong(CacheStatistics.Shards.Cold.RetrieveBytes)
| summarize HotCacheHits = format_bytes(sum(HotCacheHits)), 
            HotCacheMisses = format_bytes(sum(HotCacheMisses)),
            HotCacheRetrieved = format_bytes(sum(HotCacheRetrieved)), 
            ColdCacheHits =format_bytes(sum(ColdCacheHits)), 
            ColdCacheMisses = format_bytes(sum(ColdCacheMisses)),
            ColdCacheRetrieved = format_bytes(sum(ColdCacheRetrieved))
```
  출력
  
  HotCacheHits HotCacheMisses HotCacheRetrieved ColdCacheHits ColdCacheMisses ColdCacheRetrieved
  
  26GB 0바이트 0바이트 1GB 0바이트 866MB
  - 뷰가 핫 캐시에 완전히 없는 경우 구체화에서 디스크 누락이 발생할 수 있으므로 프로세스가 상당히 느려질 수 있습니다.
  - 구체화된 뷰에 대한 캐싱 정책을 늘리면 캐시 누락을 방지할 수 있습니다. 자세한 내용은 핫 및 콜드 캐시 및 캐싱 정책 .alter materialized-view 정책 캐싱 명령 참조하세요.
- .show 쿼리 명령을 사용하여 ScannedExtentsStatistics 확인하여 구체화가 이전 레코드를 검색하는지 확인합니다. 스캔된 익스텐트 수가 많고 MinDataScannedTime 오래된 경우 구체화 주기는 뷰의 부분의 구체화된 전부 또는 대부분을 스캔해야 합니다. 델타교집합을 찾으려면 검사가 필요합니다. 델타 및 구체화된 부분에 대한 자세한 내용은 구체화된 뷰가작동하는 방식을 참조하세요. 다음 권장 사항은 델타교집합을 최소화하여 구체화된 주기에서 스캔되는 데이터의 양을 줄이는 방법을 제공합니다.
구체화 주기가 콜드 캐시를 포함하여 많은 양의 데이터를 검색하는 경우 구체화된 뷰 정의를 다음과 같이 변경하는 것이 좋습니다.
- 뷰 정의에 datetime 그룹별 키를 포함합니다. 이렇게 하면 이 열 늦게 도착하는 데이터가 없는 한검색되는 데이터의 양을 크게 줄일 수 있습니다. 자세한 내용은 성능 팁참조하세요. 그룹별 키에 대한 업데이트가 지원되지 않으므로 구체화된 새 뷰를 만들어야 합니다.
- 뷰 정의의 일부로 lookback 사용합니다. 자세한 내용은 .create 구체화된 뷰 지원 속성 참조하세요.

HotCacheHits	HotCacheMisses	HotCacheRetrieved	ColdCacheHits	ColdCacheMisses	ColdCacheRetrieved
26GB	0바이트	0바이트	1GB	0바이트	866MB

MaterializedViewResult 메트릭 또는 IngestionUtilization 메트릭이 InsufficientCapacity 값을 표시할 있는지 확인하여 수집 용량이 충분한지 확인합니다. 사용 가능한 리소스의 크기를 조정하거나(기본 설정) 수집 용량 정책변경하여 수집 용량을 늘릴 수 있습니다.

MaterializedViewResult 메트릭InsufficientCapacity 값을 표시하는지 확인하여 수집 용량이 충분한지 확인합니다. 사용 가능한 리소스의 크기를 조정하여 수집 용량을 늘릴 수 있습니다.

구체화된 뷰가 여전히 비정상 상태이면 서비스에 모든 데이터를 정시에 구체화할 수 있는 충분한 용량이나 리소스가 없습니다. 다음 옵션을 고려합니다.
- 최소 인스턴스 수를 늘려 클러스터를 확장합니다. 최적화된 자동 크기 조정 구체화된 뷰를 고려하지 않으며 구체화된 뷰가 비정상인 경우 클러스터를 자동으로 확장하지 않습니다. 구체화된 뷰를 수용하기 위해 클러스터에 더 많은 리소스를 제공하려면 최소 인스턴스 수를 설정해야 합니다.
- 이벤트 하우스를 확장하여 구체화된 보기를 수용할 수 있는 더 많은 리소스를 제공합니다. 자세한 내용은 최소 사용사용을 참조하세요.
- 구체화된 뷰를 각각 데이터의 하위 집합을 포함하는 여러 작은 보기로 나눕니다. 예를 들어 구체화된 뷰의 그룹별 키에서 높은 카디널리티 키를 기준으로 분할할 수 있습니다. 모든 뷰는 동일한 원본 테이블을 기반으로 하며 각 뷰는 SourceTable | where hash(key, number_of_views) == i기준으로 필터링됩니다. 여기서 i 집합 {0,1,…,number_of_views-1}일부입니다. 그런 다음, 더 작은 구체화된 모든 뷰를 공용 구조체를 저장된 함수 정의할 수 있습니다. 쿼리에서 이 함수를 사용하여 결합된 데이터에 액세스합니다.
보기를 분할하면 CPU 사용량이 증가할 수 있지만 구체화 주기에서 메모리 최대 사용량이 줄어듭니다. 메모리 제한으로 인해 단일 보기가 실패하는 경우 메모리 최대값을 줄이는 것이 도움이 될 수 있습니다.

MaterializedViewResult 메트릭

MaterializedViewResult 메트릭은 구체화 주기의 결과에 대한 정보를 제공하며 구체화된 뷰 상태의 문제를 식별하는 데 사용할 수 있습니다. 메트릭에는 차원과 DatabaseMaterializedViewName 차원이 포함됩니다Result.

차원에는 Result 다음 값 중 하나가 있을 수 있습니다.

성공: 구체화가 성공적으로 완료되었습니다.
SourceTableNotFound: 구체화된 뷰의 원본 테이블이 삭제되었으므로 구체화된 뷰가 자동으로 비활성화됩니다.
SourceTableSchemaChange: 구체화된 뷰 정의와 호환되지 않는 방식으로 원본 테이블의 스키마가 변경되었습니다. 구체화된 뷰 쿼리가 구체화된 뷰 스키마와 더 이상 일치하지 않으므로 구체화된 뷰는 자동으로 비활성화됩니다.

InsufficientCapacity: 수집 용량부족하여 인스턴스에 구체화된 뷰를 구체화할 수 있는 충분한 용량이 없습니다. 용량 부족 오류는 일시적일 수 있지만 자주 다시 발생하는 경우 인스턴스를 확장하거나 정책에서 관련 용량을 늘려 보세요.

InsufficientCapacity: 수집 용량 부족으로 인해 인스턴스에 구체화된 뷰를 구체화할 수 있는 충분한 용량이 없습니다. 용량 부족 오류는 일시적일 수 있지만 자주 다시 발생하는 경우 인스턴스를 스케일 아웃하거나 용량을 늘려 보세요. 자세한 내용은 용량 크기 계획을 참조하세요.

InsufficientResources: 데이터베이스에 구체화된 뷰를 구체화할 수 있는 충분한 리소스(CPU/메모리)가 없습니다. 리소스 오류가 부족하면 일시적일 수 있지만 자주 다시 발생하는 경우 스케일 업 또는 스케일 아웃을 시도합니다. 자세한 내용은 비정상 구체화된 뷰 문제 해결을 참조하세요.

팔로워 데이터베이스의 구체화된 뷰

구체화된 뷰는 팔로워 데이터베이스에서 정의할 수 있습니다. 그러나 이러한 구체화된 뷰의 모니터링은 구체화된 뷰가 정의된 리더 데이터베이스를 기반으로 해야 합니다. 특별한 사항

MaterializedViewExtentsRebuild은 리더 데이터베이스에만 존재합니다. 모니터링(MaterializedViewAgeSeconds, MaterializedViewHealth, MaterializedViewRecordsInDelta)과 관련된 메트릭도 팔로워 데이터베이스에 표시됩니다.

.show materialized-view failures 명령은 리더 데이터베이스에서만 작동합니다.

리소스 사용량 추적

구체화된 뷰 리소스 사용: 구체화된 뷰 구체화 프로세스에서 사용하는 리소스는 명령을 사용하여 .show commands-and-queries 추적할 수 있습니다. 다음(바꾸기 DatabaseName 및 ViewName)을 사용하여 특정 보기에 대한 레코드를 필터링합니다.

.show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"

구체화된 뷰
구체화된 뷰 사용 사례

다음을 통해 공유

구체화된 보기 모니터링

비정상 구체화된 뷰 문제 해결

MaterializedViewResult 메트릭

팔로워 데이터베이스의 구체화된 뷰

리소스 사용량 추적

관련 콘텐츠

피드백

추가 리소스