.create materialized-view

아티클
10/15/2024

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

구체화된 뷰는 원본 테이블에 대한 집계 쿼리입니다. 이는 하나의 summarize 문을 보여줍니다.

명령의 백필 옵션에서 설명한 대로 구체화된 뷰를 만드는 방법에는 두 가지가 있습니다.

이제부터 구체화된 뷰를 만듭니다.

구체화된 뷰가 비어 있습니다. 뷰를 만든 후에 수집된 레코드만 포함됩니다. 이러한 종류의 생성은 즉시 반환되며 뷰는 즉시 쿼리에 사용할 수 있습니다.

원본 테이블의 기존 레코드를 기반으로 구체화된 뷰를 만듭니다.

구체화된 뷰 백필을 참조하세요.
원본 테이블의 레코드 수에 따라 만들기를 완료하는 데 시간이 오래 걸릴 수 있습니다. 백필이 완료될 때까지 쿼리에 보기를 사용할 수 없습니다.
이 옵션을 사용하는 경우 create 명령은 .이어야 async합니다. 명령을 사용하여 실행을 모니터링할 .show operations 수 있습니다.
명령을 사용하여 백필 프로세스를 취소할 .cancel operation 수 있습니다.

Important

큰 원본 테이블에서 백필 옵션을 완료하는 데 시간이 오래 걸릴 수 있습니다. 실행하는 동안 이 프로세스가 일시적으로 실패하면 자동으로 다시 시도되지 않습니다. 그런 다음 create 명령을 다시 실행해야 합니다. 자세한 내용은 구체화된 뷰 백필을 참조 하세요.

사용 권한

이 명령에는 데이터베이스 관리자 권한이 필요합니다. 구체화된 뷰의 작성자는 해당 뷰의 관리자가 됩니다.

구문

.create[async] [ifnotexists] materialized-view [ with(PropertyName = PropertyValue,...)] MaterializedViewName SourceTableName { 쿼리 on table }

구문 규칙에 대해 자세히 알아봅니다.

매개 변수

이름	Type	필수	설명
PropertyName, PropertyValue	`string`		지원되는 속성 목록에서 이름 및 값 쌍 형식의 속성 목록입니다.
MaterializedViewName	`string`	✔️	구체화된 뷰의 이름입니다. 뷰 이름은 동일한 데이터베이스의 테이블 또는 함수 이름과 충돌할 수 없으며 식별자 명명 규칙을 준수해야 합니다.
SourceTableName	`string`	✔️	뷰가 정의된 원본 테이블의 이름입니다.
쿼리	`string`	✔️	구체화된 뷰의 쿼리 정의입니다. 자세한 내용 및 제한 사항은 쿼리 매개 변수 섹션을 참조하세요.

참고 항목

구체화된 뷰가 이미 있는 경우:

플래그를 ifnotexists 지정하면 명령이 무시됩니다. 새 정의가 기존 정의와 일치하지 않더라도 변경 내용은 적용되지 않습니다.
플래그를 ifnotexists 지정하지 않으면 오류가 반환됩니다.
기존의 구체화된 뷰를 변경하려면 .alter materialized-view 명령을 사용합니다.

지원되는 속성

PropertyName PropertyValue ) = 절에서 with (지원되는 속성은 다음과 같습니다. 모든 속성은 선택 사항입니다.

속성	형식	설명
백필	`bool`	현재 ()에 있는 `SourceTabletrue`모든 레코드를 기반으로 뷰를 만들거나() 지금`false`부터 만들 것인지 여부입니다. 기본값은 `false`입니다. 자세한 내용은 구체화된 뷰 백필을 참조 하세요.
effectiveDateTime	`datetime`	를 사용하는 `backfill`경우에만 관련이 있습니다. 설정된 경우 datetime 이후에 수집된 레코드만 사용하여 백필을 생성합니다. `backfill` 은 (을)로 설정해야 합니다 `true`. 이 속성에는 datetime 리터럴이 사용됩니다. 예를 들면 다음과 같습니다 `effectiveDateTime=datetime(2019-05-01)`.
updateExtentsCreationTime	`bool`	를 사용하는 `backfill`경우에만 관련이 있습니다. 설정된 `true`경우 익스텐트 생성 시간은 백필 프로세스 중에 datetime 그룹별 키를 기반으로 할당됩니다. 자세한 내용은 구체화된 뷰 백필을 참조 하세요.
lookback	`timespan`	구체화된 뷰에 `arg_max`//`arg_mintake_any` 만 유효합니다. 중복이 예상되는 기간을 제한합니다. 예를 들어 보기에 `arg_max` 6시간의 조회가 지정된 경우 새로 수집된 레코드와 기존 레코드 간의 중복 제거는 최대 6시간 전에 수집된 레코드만 고려합니다. 조회는 ingestion_time()를 기준으로 합니다. 구체화된 뷰 쿼리가 값을 유지 `ingestion_time()` 하지 않는 경우 뷰에서 조회를 정의할 수 없습니다. 구체화된 뷰 제한 사항 및 알려진 문제를 참조하세요. 조회 기간을 잘못 정의하면 구체화된 뷰에서 중복될 수 있습니다. 예를 들어 특정 키에 대한 레코드가 동일한 키에 대한 레코드를 수집한 후 10시간 후에 수집되고 조회가 6시간으로 설정된 경우 해당 키는 보기에서 중복됩니다. 조회 기간은 구체화 시간과 쿼리 시간 모두에 적용됩니다.
autoUpdateSchema	`bool`	원본 테이블 변경에 대한 뷰를 자동으로 업데이트할지 여부입니다. 기본값은 `false`입니다. 이 옵션은 열의 인수가 있는 경우에만 형식 `arg_max(Timestamp, )`//`arg_min(Timestamp, )take_any()` 보기에만 유효합니다.`` 이 옵션을 설정 `true`하면 원본 테이블의 변경 내용이 구체화된 뷰에 자동으로 반영됩니다.
dimensionTables	배열	뷰에 차원 테이블의 배열을 포함하는 동적 인수입니다. 쿼리 매개 변수를 참조하세요.
폴더	`string`	구체화된 뷰의 폴더입니다.
docString	`string`	구체화된 뷰를 문서화하는 문자열입니다.
allowMaterializedViewsWithoutRowLevelSecurity	`bool`	행 수준 보안 정책을 사용하도록 설정된 테이블에 대해 구체화된 뷰를 만들 수 있습니다.

Warning

구체화된 뷰의 원본 테이블을 변경하거나 데이터가 변경되면 구체화된 뷰 쿼리와 예상 구체화된 뷰 스키마 간의 호환성이 없는 경우 시스템에서 구체화된 뷰를 자동으로 사용하지 않도록 설정합니다.
이 오류를 방지하려면 구체화된 뷰 쿼리가 결정적이어야 합니다. 예를 들어 bag_unpack 또는 피벗 플러그 인은 비결정적 스키마를 생성합니다.
집계를 arg_max(Timestamp, *) 사용하는 경우 및 false인 경우 autoUpdateSchema 원본 테이블을 변경하면 스키마 불일치가 발생할 수도 있습니다. 뷰 쿼리를 로 arg_max(Timestamp, Column1, Column2, ...)정의하거나 옵션을 사용하여 이 오류를 방지합니다 autoUpdateSchema .
사용하면 autoUpdateSchema 원본 테이블의 열이 삭제될 때 되돌릴 수 없는 데이터 손실이 발생할 수 있습니다.
MaterializedViewResult 메트릭을 사용하여 구체화된 뷰의 자동 비활성화를 모니터링합니다.
비호환성 문제를 해결한 후 구체화된 뷰 사용 명령을 사용하여 뷰를 명시적으로 다시 사용하도록 설정해야 합니다.

구체화된 뷰를 통해 구체화된 뷰 만들기

원본 구체화된 뷰가 집계(중복 제거)인 경우에만 다른 구체화된 뷰를 통해 구체화된 뷰 take_any(*) 를 만들 수 있습니다. 자세한 내용은 구체화된 뷰 및 예제에 대한 구체화된 뷰 를 참조하세요.

구문:

.create[async] [ifnotexists] materialized-view [ with(PropertyName = PropertyValue,...)] MaterializedViewName SourceMaterializedViewName { 쿼리 on materialized-view }

매개 변수:

속성	Type	필수	설명
PropertyName, PropertyValue	`string`		지원되는 속성 목록에서 이름 및 값 쌍 형식의 속성 목록입니다.
MaterializedViewName	`string`	✔️	구체화된 뷰의 이름입니다. 뷰 이름은 동일한 데이터베이스의 테이블 또는 함수 이름과 충돌할 수 없으며 식별자 명명 규칙을 준수해야 합니다.
SourceMaterializedViewName	`string`	✔️	뷰가 정의된 원본 구체화된 뷰의 이름입니다.
쿼리	`string`	✔️	구체화된 뷰의 쿼리 정의입니다.

예제

지금부터 수집된 레코드만 구체화하는 빈 arg_max 보기를 만듭니다.

.create materialized-view ArgMax on table T
{
    T | summarize arg_max(Timestamp, *) by User
}

다음을 사용하여 백필 옵션을 사용하여 async일일 집계에 대한 구체화된 뷰를 만듭니다.

.create async materialized-view with (backfill=true, docString="Customer telemetry") CustomerUsage on table T
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day 
}

및 을 사용하여 구체화된 뷰 backfill effectiveDateTime만들기 뷰는 datetime의 레코드에만 따라 만들어집니다.

.create async materialized-view with (backfill=true, effectiveDateTime=datetime(2019-01-01)) CustomerUsage on table T 
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day
}

6시간의 조회를 사용하여 열에 EventId 따라 원본 테이블을 중복 제거하는 구체화된 뷰를 만듭니다. 레코드는 현재 레코드 6시간 전에 수집된 레코드에 대해서만 중복 제거됩니다.
```
.create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}
```

이전 DeduplicatedTable 구체화된 뷰를 기반으로 하는 다운샘플링 구체화된 뷰를 만듭니다.

.create materialized-view DailyUsage on materialized-view DeduplicatedTable
{
    DeduplicatedTable
    | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
}

정의는 마지막 연산자가 summarize 있는 한 summarize 문 앞에 추가 연산자를 포함할 수 있습니다.

.create materialized-view CustomerUsage on table T 
{
    T 
    | where Customer in ("Customer1", "Customer2", "CustomerN")
    | parse Url with "https://contoso.com/" Api "/" *
    | extend Month = startofmonth(Timestamp)
    | summarize count(), dcount(User), max(Duration) by Customer, Api, Month
}

차원 테이블과 조인되는 구체화된 뷰는 다음과 같습니다.

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T
{
    T
    | lookup DimUsers on User  
    | summarize arg_max(Timestamp, *) by User 
}

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T 
{
    DimUsers | project User, Age, Address
    | join kind=rightouter hint.strategy=broadcast T on User
    | summarize arg_max(Timestamp, *) by User 
}

설명

쿼리 매개 변수

다음 규칙은 구체화된 뷰 쿼리 매개 변수에 사용되는 쿼리를 제한합니다.

쿼리는 구체화된 뷰의 원본인 단일 팩트 테이블을 참조해야 합니다. 단일 summarize 연산자와 하나 이상의 그룹별로 식별로 집계된 하나 이상의 집계 함수 를 포함해야 합니다. 연산자는 summarize 항상 쿼리의 마지막 연산자여야 합니다.

단일 arg_max//arg_mintake_any 집계만 포함하는 구체화된 뷰는 다른 집계(예:avgcount/dcount/ )와 함께 이러한 집계를 포함하는 구체화된 뷰보다 더 나은 성능을 발휘할 수 있습니다. 일부 최적화는 이러한 종류의 구체화된 뷰와만 관련이 있기 때문입니다. 보기에 혼합 집계 함수가 포함된 경우 적용되지 않습니다(혼합은 동일한 보기의 다른 집계와 둘 다 arg_maxtake_any/arg_min/의미함).
쿼리에는 에 의존하는 연산자가 포함되어서는 안 됩니다 now(). 예를 들어 쿼리에는 .가 없어야 where Timestamp > ago(5d)합니다. 구체화된 뷰에서 보존 정책을 사용하여 보기에서 다루는 기간을 제한합니다.
구체화된 뷰 쿼리sortpartitiontop-nestedtopserialize에서는 다음 연산자가 지원되지 않습니다.
복합 집계는 구체화된 뷰의 정의에서 지원되지 않습니다. 예를 들어 구체화된 뷰를 사용하는 SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id대신 다음과 SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id같이 정의합니다. 쿼리 시간 보기 중에 .를 실행 MaterializedViewName | project Id, Result=a/b합니다. 계산 열()a/b을 포함하여 뷰의 필수 출력을 저장된 함수에 캡슐화할 수 있습니다. 구체화된 뷰에 직접 액세스하는 대신 저장된 함수에 액세스합니다.

클러스터 간 및 데이터베이스 간 쿼리는 지원되지 않습니다.

이벤트 하우스 간 및 데이터베이스 간 쿼리는 지원되지 않습니다.

external_table() 및 externaldata에 대한 참조는 지원되지 않습니다.
구체화된 뷰 쿼리에는 가장이 필요한 설명선이 포함될 수 없습니다. 특히 가장을 사용하는 모든 쿼리 연결 플러그 인 은 허용되지 않습니다.
뷰의 원본 테이블 외에도 쿼리에서 하나 이상의 차원 테이블을 참조할 수 있습니다. 뷰 속성에서 차원 테이블을 명시적으로 호출해야 합니다. 차원 테이블과 조인할 때는 다음 동작을 이해하는 것이 중요합니다.
- 뷰의 원본 테이블(팩트 테이블)에 있는 레코드는 한 번만 구체화됩니다. 차원 테이블에 대한 업데이트는 팩트 테이블에서 이미 처리된 레코드에 영향을 주지 않습니다.
- 팩트 테이블과 차원 테이블 간의 다른 수집 대기 시간은 보기 결과에 영향을 줄 수 있습니다.
  
  예: 뷰 정의에는 차원 테이블과 내부 조인이 포함됩니다. 구체화 당시 차원 레코드는 완전히 수집되지 않았지만 이미 팩트 테이블에 수집되었습니다. 이 레코드는 보기에서 삭제되고 다시는 처리되지 않습니다.
  
  마찬가지로 조인이 외부 조인인인 경우 팩트 테이블의 레코드가 처리되고 차원 테이블 열의 null 값으로 보기에 추가됩니다. 뷰에 이미 추가된 레코드(null 값 포함)는 다시 처리되지 않습니다. 차원 테이블의 열에서 해당 값은 null로 유지됩니다.

지원되는 집계 함수

지원되는 집계 함수는 다음과 같습니다.

성능 팁

datetime 그룹별 키 사용: 날짜/시간 열을 그룹별 키 중 하나로 사용하는 구체화된 뷰는 그렇지 않은 뷰보다 더 효율적입니다. 그 이유는 날짜/시간 그룹별 키가 있는 경우에만 일부 최적화를 적용할 수 있기 때문입니다. datetime group-by 키를 추가해도 집계의 의미 체계가 변경되지 않는 경우 추가하는 것이 좋습니다. 각 고유 엔터티에 대해 datetime 열이 변경할 수 없는 경우에만 이 작업을 수행할 수 있습니다.

예를 들어 다음 집계에서 다음을 수행합니다.
```
    SourceTable | summarize take_any(*) by EventId
```
항상 값이 같 Timestamp 으므로 추가 Timestamp 해도 집계의 의미 체계가 변경되지 않는 경우 EventId 뷰를 다음과 같이 정의하는 것이 좋습니다.
```
    SourceTable | summarize take_any(*) by EventId, Timestamp
```
팁

날짜/시간 그룹별 키에 늦게 도착하는 데이터는 구체화된 뷰의 성능에 부정적인 영향을 미칠 수 있습니다. 예를 들어 구체화된 뷰가 그룹별 키 중 하나로 사용하고 bin(Timestamp, 1d) 원본 테이블에 새로 수집된 레코드에 이전 Timestamp 값이 있다고 가정합니다. 이러한 레코드는 구체화된 뷰에 부정적인 영향을 줄 수 있습니다.

원본 테이블에 늦게 도착하는 레코드가 예상되는 경우 구체화된 뷰의 캐싱 정책을 적절하게 조정합니다. 예를 들어 타임스탬프가 6개월 전인 레코드가 원본 테이블에 수집될 것으로 예상되는 경우 구체화 프로세스는 이전 6개월 동안 구체화된 뷰를 검색해야 합니다. 이 기간이 콜드 캐시에 있는 경우 구체화에서 캐시 누락이 발생하므로 보기의 성능에 부정적인 영향을 줍니다.

이러한 지연 도착 레코드가 예상되지 않는 경우 구체화된 뷰 쿼리에서 이러한 레코드를 필터링하거나 타임스탬프 값을 현재 시간으로 정규화하는 것이 좋습니다.
조회 기간 정의: 시나리오에 해당하는 경우 속성을 추가 lookback 하면 쿼리 성능이 크게 향상될 수 있습니다. 자세한 내용은 지원되는 속성을 참조 하세요.
그룹별 키로 필터링하는 데 자주 사용되는 열 추가: 구체화된 뷰 쿼리는 구체화된 뷰의 그룹별 키 중 하나로 필터링될 때 최적화됩니다. 쿼리 패턴이 구체화된 뷰의 고유 엔터티에 따라 변경할 수 없는 열로 필터링되는 경우가 많다면 구체화된 뷰의 그룹별 키에 포함합니다.

예를 들어 구체화된 뷰는 arg_max 종종 필터링되는 값으로 ResourceId SubscriptionId노출됩니다. 값이 ResourceId 항상 동일한 SubscriptionId 값에 속한다고 가정하고 구체화된 뷰 쿼리를 다음과 같이 정의합니다.
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}
```
위의 정의는 다음보다 좋습니다.
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}
```

적절한 경우 업데이트 정책 사용: 구체화된 뷰에는 차원 테이블의 변환, 정규화 및 조회가 포함될 수 있습니다. 그러나 이러한 작업을 업데이트 정책으로 이동하는 것이 좋습니다. 구체화된 뷰의 집계만 그대로 둡니다.

예를 들어 다음 업데이트 정책을 정의하는 것이 좋습니다.

.alter-merge table Target policy update 
@'[{"IsEnabled": true, 
    "Source": "SourceTable", 
    "Query": 
        "SourceTable 
        | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
        | lookup DimResources on ResourceId
        | mv-expand Events
    "IsTransactional": false}]'

그리고 다음과 같은 구체화된 뷰를 정의합니다.

.create materialized-view Usage on table Events
{
    Target 
    | summarize count() by ResourceId 
}

구체화된 뷰 쿼리의 일부로 업데이트 정책을 포함하는 대안은 성능이 더 나빠서 권장되지 않을 수 있습니다.

.create materialized-view Usage on table SourceTable
{
    SourceTable
    | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
    | lookup DimResources on ResourceId
    | mv-expand Events
    | summarize count() by ResourceId
}

팁

최상의 쿼리 시간 성능이 필요하지만 일부 데이터 대기 시간을 허용할 수 있는 경우 materialized_view() 함수를 사용합니다.

구체화된 뷰 백필

속성을 사용하여 backfill 구체화된 뷰를 만드는 경우 원본 테이블에서 사용할 수 있는 레코드를 기반으로 구체화된 뷰가 만들어집니다. 또는 사용하는 effectiveDateTime경우 해당 레코드의 하위 집합을 기반으로 만들어집니다.

백필 프로세스는 백필할 데이터를 여러 일괄 처리로 분할하고 여러 수집 작업을 실행하여 뷰를 백필합니다. 원본 테이블의 레코드 수가 클 때 프로세스를 완료하는 데 시간이 오래 걸릴 수 있습니다. 프로세스 기간은 데이터베이스 크기에 따라 달라집니다. 명령을 사용하여 백필의 진행률을 추적합니다 .show operations .

백필 프로세스의 일부로 발생하는 일시적인 오류는 다시 시도됩니다. 모든 재시도가 모두 소진되면 명령이 실패하고 create 명령의 수동 다시 실행이 필요합니다.

원본 테이블의 레코드 수가 초과 number-of-nodes X 200 million 될 때 백필을 사용하지 않는 것이 좋습니다(쿼리의 복잡성에 따라 더 적은 경우도 있습니다). 다른 방법은 이동 익스텐트별 백필 옵션입니다 .

콜드 캐시의 데이터에 대해서는 백필 옵션을 사용할 수 없습니다. 필요한 경우 뷰를 만드는 동안 핫 캐시 기간을 늘입니다. 이를 위해서는 스케일 아웃이 필요할 수 있습니다.

뷰 만들기에 오류가 발생하는 경우 다음 속성을 변경해 보세요.

MaxSourceRecordsForSingleIngest: 기본적으로 백필 중에 각 수집 작업의 원본 레코드 수는 노드당 2백만 개입니다. 이 속성을 원하는 레코드 수로 설정하여 이 기본값을 변경할 수 있습니다. 값은 각 수집 작업의 총 레코드 수입니다.

이 값을 줄이면 메모리 제한 또는 쿼리 시간 제한에서 생성에 실패할 때 유용할 수 있습니다. 이 값을 늘리면 데이터베이스가 기본값보다 많은 레코드에서 집계 함수를 실행할 수 있다고 가정하면 보기 생성 속도가 빨라지게 됩니다.
Concurrency: 백필 프로세스의 일부로 실행되는 수집 작업은 동시에 실행됩니다. 기본적으로 동시성은 .입니다 min(number_of_nodes * 2, 5). 이 속성을 설정하여 동시성을 늘리거나 줄일 수 있습니다. 증가가 데이터베이스의 CPU 사용량에 크게 영향을 줄 수 있으므로 데이터 데이터의 CPU가 낮은 경우에만 이 값을 늘리는 것이 좋습니다.

예를 들어 다음 명령은 구체화된 뷰를 .에서 2020-01-01백필합니다. 각 수집 작업의 최대 레코드 수는 3백만 개입니다. 명령은 동시성을 2사용하여 수집 작업을 실행합니다.

.create async materialized-view with (
        backfill=true,
        effectiveDateTime=datetime(2020-01-01),
        MaxSourceRecordsForSingleIngest=3000000,
        Concurrency=2
    )
    CustomerUsage on table T
{
    T
    | summarize count(), dcount(User), max(Duration) by Customer, bin(Timestamp, 1d)
}

구체화된 뷰에 datetime 그룹별 키가 포함된 경우 백필 프로세스는 datetime 열에 따라 익스텐트 생성 시간을 재정의할 수 있습니다. 예를 들어 보존 정책은 익스텐트 생성 시간을 기반으로 하기 때문에 이전 레코드를 최근 레코드보다 더 오래 삭제하려는 경우에 유용할 수 있습니다. 이 updateExtentsCreationTime 속성은 뷰에 함수를 사용하는 bin() datetime group-by 키가 포함된 경우에만 지원됩니다. 예를 들어 다음 백필은 그룹별 키에 Timestamp 따라 생성 시간을 할당합니다.

.create async materialized-view with (
        backfill=true,
        updateExtentsCreationTime=true
    )
    CustomerUsage on table T
{
    T
    | summarize count() by Customer, bin(Timestamp, 1d)
}

이동 익스텐트별 백필

이동 익스텐트를 기준으로 백필하는 옵션은 구체화된 뷰의 원본 테이블이 아닌 기존 테이블을 기반으로 구체화된 뷰를 백필합니다. 지정된 테이블에서 기본 구체화된 뷰 테이블로 익스텐트 이동으로 백필을 수행합니다. 이 프로세스는 다음을 의미합니다.

지정된 테이블의 데이터에는 구체화된 뷰 스키마와 동일한 스키마가 있어야 합니다.
지정한 테이블의 레코드가 있는 그대로 뷰로 이동됩니다. 구체화된 뷰의 정의에 따라 중복 제거된 것으로 간주됩니다.

예를 들어 구체화된 뷰에 다음과 같은 집계가 있는 경우

T | summarize arg_max(Timestamp, *) by EventId

그런 다음, 이동 익스텐트 작업에 대한 원본 테이블의 레코드는 이미 에 의해 EventID중복 제거되어야 합니다.

작업에서 .move 익스텐트(.move extents)를 사용하므로 백필 중에 지정된 테이블에서 레코드가 제거됩니다(복사되지 않고 이동됨).

이동 익스텐트별 백필은 구체화된 뷰에서 지원되는 모든 집계 함수에 대해 지원되지 않습니다. 뷰에 저장된 기본 데이터가 집계 자체와 다른 집계(예: avg()dcount()집계)에 대해 실패합니다.

구체화된 뷰는 지정된 테이블을 기반으로만 백필됩니다. 뷰의 원본 테이블에 있는 레코드의 구체화는 기본적으로 뷰 생성 시간부터 시작됩니다.

구체화된 뷰의 원본 테이블이 지속적으로 데이터를 수집하는 경우 이동 익스텐트로 보기를 만들면 데이터가 손실될 수 있습니다. 이는 원본 테이블에 수집된 레코드가 백필할 테이블을 준비하는 시간과 뷰를 만든 시간 사이의 짧은 시간에 구체화된 뷰에 포함되지 않기 때문입니다. 이 시나리오를 처리하려면 원본 테이블을 통해 구체화된 뷰의 시작 시간으로 속성을 설정할 source_ingestion_time_from 수 있습니다.

사용 사례

이동 익스텐트별 백필 옵션은 다음 두 가지 주요 시나리오에서 유용할 수 있습니다.

구체화된 뷰에 대해 중복 제거된 원본 데이터가 포함된 테이블이 이미 있는 경우 구체화된 뷰만 사용하므로 뷰를 만든 후에 이 테이블에 이러한 레코드가 필요하지 않습니다.
구체화된 뷰의 원본 테이블이 매우 크고 원본 테이블을 기반으로 뷰를 백필하는 것은 앞에서 언급한 제한 사항 때문에 제대로 작동하지 않습니다. 이 경우 쿼리 명령에서 수집을 사용하여 백필 프로세스를 임시 테이블로 직접 오케스트레이션할 수 있습니다. 임시 테이블에 백필에 대한 모든 레코드가 포함된 경우 해당 테이블을 기반으로 구체화된 뷰를 만듭니다.

권장되는 오케스트레이션 도구 중 하나를 사용할 수도 있습니다.

예:

다음 예제에서 테이블 DeduplicatedTable 은 인스턴스당 EventId 단일 레코드를 포함하며 구체화된 뷰의 기준선으로 사용됩니다. 뷰 생성 시간 후에 수집되는 레코드 T 만 구체화된 뷰에 포함됩니다.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
속성과 effectiveDateTime 함께 move_extents_from 속성이 지정된 경우 해당 값이 백필에 DeduplicatedTable MaxCreatedOn 포함된 것보다 effectiveDateTime 큰 범위만(구체화된 뷰로 이동)
```
.create async materialized-view with 
    (move_extents_from=DeduplicatedTable, effectiveDateTime=datetime(2019-01-01)) 
    MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
다음 예제에서는 이동 익스텐트별 백필 옵션에서 속성을 사용하는 source_ingestion_time_from 방법을 보여 줍니다. 둘 다 source_ingestion_time_from move_extents_from 사용하고 구체화된 뷰가 다음 두 소스에서 백필됨을 나타냅니다.
- 다음 move_extents_from 예제에서는 다음 표를 참조하세요DeduplicatedTable. 이 테이블에는 백필할 모든 기록 데이터가 포함되어야 합니다. 필요에 따라 속성을 사용하여 값이 effectiveDateTime 1보다 effectiveDateTime큰 익스텐트 DeduplicatedTable MaxCreatedOn 만 포함할 수 있습니다.
- 구체화된 뷰T의 원본 테이블은 다음 예제에서 확인할 수 있습니다. 이 테이블의 백필에는 ingestion_time() 값이 보다 source_ingestion_time_from큰 레코드만 포함됩니다.
  
  이 속성은 source_ingestion_time_from ()에서DeduplicatedTable 백필할 테이블을 준비하는 시간과 뷰를 만든 시간 사이의 짧은 시간에 가능한 데이터 손실을 처리하는 데만 사용해야 합니다. 과거에 이 속성을 너무 멀리 설정하지 마세요. 그러면 구체화된 뷰가 상당한 지연으로 시작되며 따라 잡기 어려울 수 있습니다.
다음 예제에서는 현재 시간이 .입니다 2020-01-01 03:00. 테이블 DeduplicatedTable 은 중복 제거된 .의 테이블입니다 T. 여기에는 모든 기록 데이터가 포함되며, 다음까지 2020-01-01 00:00중복 제거됩니다. 이 create 명령은 이동 익스텐스를 사용하여 구체화된 뷰를 백필하는 데 사용합니다 DeduplicatedTable . 이 명령에는 create 이후 2020-01-01수집된 모든 레코드 T 도 포함됩니다.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable, source_ingestion_time_from=datetime(2020-01-01)) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```

구체화된 뷰 만들기 취소

백필 옵션을 사용하는 경우 구체화된 뷰 만들기 프로세스를 취소할 수 있습니다. 이 작업은 만들기가 너무 오래 걸리고 실행 중인 동안 중지하려는 경우에 유용합니다.

Warning

이 명령을 실행한 후에는 구체화된 뷰를 복원할 수 없습니다.

생성 프로세스를 즉시 취소할 수 없습니다. 취소 명령은 구체화를 중지하도록 신호를 보내며 생성은 정기적으로 취소가 요청되었는지 확인합니다. 취소 명령은 구체화된 뷰 만들기 프로세스가 취소될 때까지 최대 10분 동안 대기하며 취소에 성공하면 다시 보고합니다.

취소가 10분 이내에 성공하지 못하고 취소 명령이 실패를 보고하더라도 구체화된 뷰는 생성 프로세스의 뒷부분에서 자체 취소될 수 있습니다. 이 .show operations 명령은 작업이 취소되었는지를 나타냅니다.

명령이 실행될 때 .cancel operation 작업이 더 이상 진행되지 않으면 명령에서 오류를 보고합니다.

구문

.cancel operationoperationId

구문 규칙에 대해 자세히 알아봅니다.

매개 변수

이름	Type	필수	설명
`operationId`	`guid`	✔️	명령에서 반환된 작업 ID입니다 `.create async materialized-view` .

출력

이름	형식	설명
OperationId	`guid`	명령의 작업 ID입니다 `.create materialized-view` .
연산	`string`	작업의 유형입니다.
StartedOn	`datetime`	만들기 작업의 시작 시간입니다.
CancellationState	`string`	다음 중 하나( `Canceled successfully` 만들기가 취소됨), `Cancellation failed` (취소 시간이 초과될 때까지 대기) `Unknown` (보기 만들기가 더 이상 실행되지 않지만 이 작업으로 취소되지 않음).
ReasonPhrase	`string`	취소가 성공하지 못한 이유입니다.

예제

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e

OperationId	연산	StartedOn	CancellationState	ReasonPhrase
`c4b29441-4873-4e36-8310-c631c35c916e`	`MaterializedViewCreateOrAlter`	`2020-05-08 19:45:03.9184142`	`Canceled successfully`

취소가 10분 CancellationState 이내에 완료되지 않은 경우 실패를 나타냅니다. 그런 다음 만들기를 취소할 수 있습니다.

다음을 통해 공유

.create materialized-view

사용 권한

구문

매개 변수

지원되는 속성

구체화된 뷰를 통해 구체화된 뷰 만들기

예제

설명

쿼리 매개 변수

지원되는 집계 함수

성능 팁

구체화된 뷰 백필

이동 익스텐트별 백필

사용 사례

구체화된 뷰 만들기 취소

구문

매개 변수

출력

예제

피드백

추가 리소스