.create materialized-view

Artículo
10/15/2024

Se aplica a: ✅Microsoft Fabric✅Azure Data Explorer

Una vista materializada es una consulta de agregación sobre una tabla de origen. Representa una única instrucción summarize.

Hay dos maneras posibles de crear una vista materializada, como se indica en la opción de reposición en el comando :

Cree la vista materializada desde ahora:

La vista materializada se crea vacía. Solo incluye registros ingeridos después de la creación de la vista. La creación de este tipo devuelve inmediatamente y la vista está disponible inmediatamente para la consulta.

Cree la vista materializada en función de los registros existentes en la tabla de origen:

Consulte Reposición de una vista materializada.
La creación puede tardar mucho tiempo en completarse, en función del número de registros de la tabla de origen. La vista no estará disponible para las consultas hasta que se complete el reposición.
Cuando use esta opción, el comando create debe ser async. Puede supervisar la ejecución mediante el .show operations comando .
Puede cancelar el proceso de reposición mediante el .cancel operation comando .

Importante

En tablas de origen de gran tamaño, la opción de reposición puede tardar mucho tiempo en completarse. Si este proceso produce un error transitorio mientras se ejecuta, no se reintentará automáticamente. A continuación, debe volver a ejecutar el comando create. Para obtener más información, consulte Reposición de una vista materializada.

Permisos

Este comando requiere permisos de administrador de base de datos. El creador de la vista materializada se convierte en el administrador.

Sintaxis

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )Consulta MaterializedViewName SourceTableName { on table }

Obtenga más información sobre las convenciones de sintaxis.

Parámetros

Nombre	Type	Obligatorio	Descripción
PropertyName, PropertyValue	`string`		Lista de propiedades en forma de pares nombre y valor, de la lista de propiedades admitidas.
MaterializedViewName	`string`	✔️	Nombre de la vista materializada. El nombre de la vista no puede entrar en conflicto con los nombres de tabla o función de la misma base de datos y debe cumplir las reglas de nomenclatura de identificadores.
SourceTableName	`string`	✔️	Nombre de la tabla de origen en la que se define la vista.
Consulta	`string`	✔️	Definición de consulta de la vista materializada. Para obtener más información y limitaciones, consulte la sección Parámetro de consulta.

Nota:

Si la vista materializada ya existe:

Si se especifica la ifnotexists marca, se omite el comando. No se aplica ningún cambio, aunque la nueva definición no coincida con la definición existente.
Si no se especifica la ifnotexists marca, se devuelve un error.
Para modificar una vista materializada existente, use el comando .alter materialized-view .

Propiedades admitidas

Las siguientes propiedades se admiten en la with(cláusula PropertyName = PropertyValue.) Todas las propiedades son opcionales.

Nombre	Escribir	Descripción
Relleno	`bool`	Si desea crear la vista en función de todos los registros que se encuentran actualmente en `SourceTable` (`true`) o crearla desde ahora (`false`). El valor predeterminado es `false`. Para obtener más información, consulte Reposición de una vista materializada.
effectiveDateTime	`datetime`	Solo es relevante cuando se usa `backfill`. Si se establece, la creación solo se rellena con registros ingeridos después de la fecha y hora. `backfill` también debe establecerse en `true`. Esta propiedad espera un literal datetime; por ejemplo, `effectiveDateTime=datetime(2019-05-01)`.
updateExtentsCreationTime	`bool`	Solo es relevante cuando se usa `backfill`. Si se establece `true`en , la hora de creación de la extensión se asigna en función de la clave datetime group-by durante el proceso de reposición. Para obtener más información, consulte Reposición de una vista materializada.
lookback	`timespan`	Válido solo para `arg_max`//`arg_mintake_any` vistas materializadas. Limita el período de tiempo en el que se esperan duplicados. Por ejemplo, si se especifica una búsqueda de 6 horas en una `arg_max` vista, la desduplicación entre los registros recién ingeridos y los existentes tendrá en cuenta solo los registros ingeridos hace hasta 6 horas. Lookback es relativo a ingestion_time(). Si la consulta de vista materializada no conserva el `ingestion_time()` valor, no se puede definir lookback en la vista. Consulte limitaciones de vistas materializadas y problemas conocidos. Definir el período de búsqueda incorrectamente podría dar lugar a duplicados en la vista materializada. Por ejemplo, si se ingiere un registro para una clave específica 10 horas después de ingerir un registro para la misma clave y la búsqueda se establece en 6 horas, esa clave será un duplicado en la vista. El período de búsqueda se aplica durante el tiempo de materialización y el tiempo de consulta.
autoUpdateSchema	`bool`	Si se va a actualizar automáticamente la vista en los cambios de la tabla de origen. El valor predeterminado es `false`. Esta opción solo es válida para las vistas de tipo `arg_max(Timestamp, )`//`arg_min(Timestamp, )take_any()` (solo cuando el argumento de la columna es ).`` Si esta opción se establece `true`en , los cambios realizados en la tabla de origen se reflejarán automáticamente en la vista materializada.
dimensionTables	array	Argumento dinámico que incluye una matriz de tablas de dimensiones en la vista. Consulte Parámetro de consulta.
folder	`string`	Carpeta de la vista materializada.
docString	`string`	Cadena que documenta la vista materializada.
allowMaterializedViewsWithoutRowLevelSecurity	`bool`	Permite crear una vista materializada sobre una tabla con la directiva de seguridad de nivel de fila habilitada.

Advertencia

El sistema deshabilitará automáticamente una vista materializada si los cambios realizados en la tabla de origen de la vista materializada o los cambios en los datos provocarán incompatibilidad entre la consulta de vista materializada y el esquema de vista materializado esperado.
Para evitar este error, la consulta de vista materializada debe ser determinista. Por ejemplo, la bag_unpack o el complemento dinámico da como resultado un esquema no determinista.
Cuando se usa una arg_max(Timestamp, *) agregación y cuando autoUpdateSchema es false, los cambios en la tabla de origen también pueden provocar errores de coincidencia de esquema. Evite este error definiendo la consulta de vista como arg_max(Timestamp, Column1, Column2, ...)o mediante la autoUpdateSchema opción .
El uso autoUpdateSchema puede provocar una pérdida de datos irreversible cuando se quitan las columnas de la tabla de origen.
Supervise la deshabilitación automática de vistas materializadas mediante la métrica MaterializedViewResult.
Después de corregir los problemas de incompatibilidad, debe volver a habilitar explícitamente la vista mediante el comando habilitar la vista materializada.

Crear una vista materializada sobre la vista materializada

Puede crear una vista materializada sobre otra vista materializada solo cuando la vista materializada de origen es una take_any(*) agregación (desduplicación). Para obtener más información, vea Vista materializada sobre la vista materializada y ejemplos.

Sintaxis:

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )Consulta MaterializedViewName SourceMaterializedViewName { on materialized-view }

Parámetros:

Nombre	Type	Obligatorio	Descripción
PropertyName, PropertyValue	`string`		Lista de propiedades en forma de pares nombre y valor, de la lista de propiedades admitidas.
MaterializedViewName	`string`	✔️	Nombre de la vista materializada. El nombre de la vista no puede entrar en conflicto con los nombres de tabla o función de la misma base de datos y debe cumplir las reglas de nomenclatura de identificadores.
SourceMaterializedViewName	`string`	✔️	Nombre de la vista materializada de origen en la que se define la vista.
Consulta	`string`	✔️	Definición de consulta de la vista materializada.

Ejemplos

Cree una vista vacía arg_max que materialice solo los registros ingeridos desde ahora:

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

Cree una vista materializada para agregados diarios con la opción de reposición mediante 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 
}

Cree una vista materializada con backfill y effectiveDateTime. La vista se crea en función de los registros solo a partir de la fecha y hora.

.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
}

Cree una vista materializada que desduplica la tabla de origen, basada en la EventId columna, mediante una búsqueda de 6 horas. Los registros se desduplicarán solo en los registros ingeridos 6 horas antes de los registros actuales.
```
.create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}
```

Cree una vista materializada de muestreo que se basa en la vista materializada anterior DeduplicatedTable :

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

La definición puede incluir operadores adicionales antes de la summarize instrucción , siempre que summarize sea el último:

.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
}

Estas son vistas materializadas que se unen con una tabla de dimensiones:

.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 
}

Comentarios

Parámetro de consulta

Las reglas siguientes limitan la consulta usada en el parámetro Query de vista materializada:

La consulta debe hacer referencia a una tabla de hechos única que sea el origen de la vista materializada. Debe incluir un único summarize operador y una o varias funciones de agregación agregadas por uno o varios grupos por expresiones. El summarize operador siempre debe ser el último operador de la consulta.

Una vista materializada que incluye solo una sola arg_maxarg_mintake_any//agregación puede funcionar mejor que una vista materializada que incluya estas agregaciones junto con otras agregaciones (como ).count/dcount/avg Esto se debe a que algunas optimizaciones solo son relevantes para estos tipos de vistas materializadas. No se aplican cuando la vista incluye funciones de agregación mixtas (donde la mezcla significa tanto comotake_any//arg_maxarg_min otras agregaciones en la misma vista).
La consulta no debe incluir ningún operador que dependa de now(). Por ejemplo, la consulta no debe tener where Timestamp > ago(5d). Use la directiva de retención en la vista materializada para limitar el período de tiempo que cubre la vista.
Los operadores siguientes no se admiten en la consulta de vista materializada: sort, top-nested, top, , partition. serialize
Las agregaciones compuestas no se admiten en la definición de la vista materializada. Por ejemplo, en lugar de usar SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id, defina la vista materializada como: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Durante el tiempo de consulta de vista, ejecute MaterializedViewName | project Id, Result=a/b. La salida necesaria de la vista, incluida la columna calculada (a/b), se puede encapsular en una función almacenada. Acceda directamente a la función almacenada en lugar de acceder a la vista materializada.

No se admiten consultas entre clústeres y entre bases de datos.

No se admiten consultas entre centros de eventos y entre bases de datos.

No se admiten referencias a external_table() y externaldata .
La consulta de vista materializada no puede incluir ninguna llamada que requiera suplantación. En concreto, no se permiten todos los complementos de conectividad de consulta que usan suplantación.
Además de la tabla de origen de la vista, la consulta puede hacer referencia a una o varias tablas de dimensiones. Las tablas de dimensiones deben llamarse explícitamente en las propiedades de la vista. Es importante comprender el siguiente comportamiento cuando se va a combinar con tablas de dimensiones:
- Los registros de la tabla de origen de la vista (la tabla de hechos) solo se materializan una vez. Las actualizaciones de las tablas de dimensiones no tienen ningún impacto en los registros que ya se han procesado desde la tabla de hechos.
- Una latencia de ingesta diferente entre la tabla de hechos y la tabla de dimensiones podría afectar a los resultados de la vista.
  
  Ejemplo: una definición de vista incluye una combinación interna con una tabla de dimensiones. En el momento de la materialización, el registro de dimensión no se ingería completamente, pero ya se ingería en la tabla de hechos. Este registro se quitará de la vista y nunca se volverá a procesar.
  
  Del mismo modo, si la combinación es una combinación externa, el registro de la tabla de hechos se procesará y agregará para ver con un valor NULL para las columnas de la tabla de dimensiones. Los registros que ya se han agregado (con valores NULL) a la vista no se procesarán de nuevo. Sus valores, en columnas de la tabla de dimensiones, seguirán siendo NULL.

Funciones de agregación admitidas

Se admiten las siguientes funciones de agregación:

Consejos de rendimiento

Use una clave de agrupación por fecha y hora: las vistas materializadas que tienen una columna datetime como una de sus claves de grupo por son más eficaces que las que no lo hacen. El motivo es que algunas optimizaciones solo se pueden aplicar cuando hay una clave de grupo por fecha y hora. Si agregar una clave datetime group-by no cambia la semántica de la agregación, se recomienda agregarla. Solo puede hacerlo si la columna datetime es inmutable para cada entidad única.

Por ejemplo, en la agregación siguiente:
```
    SourceTable | summarize take_any(*) by EventId
```
Si EventId siempre tiene el mismo Timestamp valor y, por tanto, agregar Timestamp no cambia la semántica de la agregación, es mejor definir la vista como:
```
    SourceTable | summarize take_any(*) by EventId, Timestamp
```
Sugerencia

Los datos de llegada tardía en una clave de grupo de fecha y hora pueden tener un impacto negativo en el rendimiento de la vista materializada. Por ejemplo, supongamos que una vista materializada usa bin(Timestamp, 1d) como una de sus claves de agrupación y los registros recién ingeridos en la tabla de origen tienen valores antiguos Timestamp . Estos registros pueden afectar negativamente a la vista materializada.

Si espera registros de llegada tardía ingeridos en la tabla de origen, ajuste la directiva de almacenamiento en caché de la vista materializada en consecuencia. Por ejemplo, si se espera que los registros con marca de tiempo de seis meses se ingieren en la tabla de origen, el proceso de materialización tendrá que examinar la vista materializada durante los seis meses anteriores. Si este período está en caché en frío, la materialización experimentará errores de caché que tendrán un impacto negativo en el rendimiento de la vista.

Si no se esperan registros de llegada tardía, se recomienda que, en la consulta de vista materializada, filtre estos registros o normalice sus valores de marca de tiempo a la hora actual.
Definir un período de búsqueda: si es aplicable a su escenario, agregar una propiedad puede mejorar significativamente el rendimiento de las lookback consultas. Para obtener más información, consulte Propiedades admitidas.
Agregar columnas que se usan con frecuencia para filtrar como claves agrupadas: las consultas de vista materializadas se optimizan cuando se filtran por una de las claves agrupadas por la vista materializada. Si sabe que el patrón de consulta a menudo filtrará por una columna inmutable según una entidad única en la vista materializada, incluyéela en las claves de agrupación por la vista materializada.

Por ejemplo, una vista materializada expone arg_max por un ResourceId valor que a menudo se filtrará mediante SubscriptionId. Suponiendo que un ResourceId valor siempre pertenece al mismo SubscriptionId valor, defina la consulta de vista materializada como:
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}
```
La definición anterior es preferible sobre lo siguiente:
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}
```

Use directivas de actualización cuando corresponda: la vista materializada puede incluir transformaciones, normalizaciones y búsquedas en tablas de dimensiones. Sin embargo, se recomienda mover estas operaciones a una directiva de actualización. Deje solo la agregación para la vista materializada.

Por ejemplo, es mejor definir la siguiente directiva de actualización:

.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}]'

Y defina la siguiente vista materializada:

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

La alternativa, de incluir la directiva de actualización como parte de la consulta de vista materializada, podría funcionar peor y, por tanto, no se recomienda:

.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
}

Sugerencia

Si necesita el mejor rendimiento del tiempo de consulta, pero puede tolerar cierta latencia de datos, use la función materialized_view().

Reposición de una vista materializada

Al crear una vista materializada mediante la backfill propiedad , la vista materializada se creará en función de los registros disponibles en la tabla de origen. O bien, se creará en función de un subconjunto de esos registros, si usa effectiveDateTime.

En segundo plano, el proceso de reposición divide los datos en varios lotes y ejecuta varias operaciones de ingesta para rellenar la vista. El proceso puede tardar mucho tiempo en completarse cuando el número de registros de la tabla de origen es grande. La duración del proceso depende del tamaño de la base de datos. Realice un seguimiento del progreso del reposición mediante el .show operations comando .

Los errores transitorios que se producen como parte del proceso de reposición se reintentan. Si se agotan todos los reintentos, se producirá un error en el comando y se requerirá una nueva ejecución manual del comando create.

No se recomienda usar reposición cuando el número de registros de la tabla de origen supere number-of-nodes X 200 million (a veces incluso menos, dependiendo de la complejidad de la consulta). Una alternativa es la opción reposición mediante extensiones de movimiento.

No se admite el uso de la opción de reposición para los datos de una caché inactiva. Aumente el período de caché activa, si es necesario, durante la creación de la vista. Esto puede requerir el escalado horizontal.

Si experimenta errores en la creación de la vista, intente cambiar estas propiedades:

MaxSourceRecordsForSingleIngest: de forma predeterminada, el número de registros de origen en cada operación de ingesta durante el reposición es de 2 millones por nodo. Puede cambiar este valor predeterminado estableciendo esta propiedad en el número deseado de registros. (El valor es el número total de registros en cada operación de ingesta).

Reducir este valor puede resultar útil cuando se produce un error en la creación de límites de memoria o tiempos de espera de consulta. Aumentar este valor puede acelerar la creación de vistas, suponiendo que la base de datos pueda ejecutar la función de agregación en más registros que el valor predeterminado.
Concurrency: las operaciones de ingesta, que se ejecutan como parte del proceso de reposición, se ejecutan simultáneamente. De forma predeterminada, la simultaneidad es min(number_of_nodes * 2, 5). Puede establecer esta propiedad para aumentar o disminuir la simultaneidad. Se recomienda aumentar este valor solo si la CPU de databse es baja, ya que el aumento puede afectar significativamente al consumo de CPU de la base de datos.

Por ejemplo, el siguiente comando volverá a rellenar la vista materializada de 2020-01-01. El número máximo de registros de cada operación de ingesta es de 3 millones. El comando ejecutará las operaciones de ingesta con simultaneidad de 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)
}

Si la vista materializada incluye una clave datetime group-by, el proceso de reposición admite la invalidación del tiempo de creación de la extensión en función de la columna datetime. Esto puede ser útil, por ejemplo, si desea quitar registros más antiguos antes de los recientes, ya que la directiva de retención se basa en el tiempo de creación de la extensión. La updateExtentsCreationTime propiedad solo se admite si la vista incluye una clave datetime group-by que usa la bin() función . Por ejemplo, el siguiente reposición asignará tiempo de creación en función de la clave group-by Timestamp :

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

Reposición mediante extensiones de movimiento

La opción de reposición mediante reposición de extensiones de movimiento rellena la vista materializada basada en una tabla existente, que no es necesariamente la tabla de origen de la vista materializada. Para lograr el reposición , mueva extensiones de la tabla especificada a la tabla de vista materializada subyacente. Este proceso implica que:

Los datos de la tabla especificada deben tener el mismo esquema que el esquema de vista materializado.
Los registros de la tabla especificada se mueven a la vista tal como está. Se supone que se desduplican en función de la definición de la vista materializada.

Por ejemplo, si la vista materializada tiene la agregación siguiente:

T | summarize arg_max(Timestamp, *) by EventId

A continuación, los registros de la tabla de origen para la operación de extensiones de movimiento ya deben desduplicarse mediante EventID.

Dado que la operación usa extensiones .move, los registros se quitarán de la tabla especificada durante el reposición (movido, no copiado).

No se admite el reposición por extensiones de movimiento para todas las funciones de agregación admitidas en vistas materializadas. Se producirá un error en las agregaciones, como avg(), dcount(), en las que los datos subyacentes almacenados en la vista son diferentes de la propia agregación.

La vista materializada solo se rellenó en función de la tabla especificada. La materialización de registros en la tabla de origen de la vista comenzará desde la hora de creación de la vista de forma predeterminada.

Si la tabla de origen de la vista materializada ingiere datos continuamente, la creación de la vista mediante extensiones de movimiento podría dar lugar a una pérdida de datos. Esto se debe a que los registros ingeridos en la tabla de origen, en el breve tiempo entre el tiempo de preparación de la tabla para rerrellenar desde y el momento en que se crea la vista, no se incluirán en la vista materializada. Para controlar este escenario, puede establecer la source_ingestion_time_from propiedad en la hora de inicio de la vista materializada sobre la tabla de origen.

Casos de uso

La opción de reposición mediante extensiones de movimiento puede ser útil en dos escenarios principales:

Si ya tiene una tabla que incluye los datos de origen desduplicados para la vista materializada y no necesita estos registros en esta tabla después de la creación de la vista porque solo usa la vista materializada.
Cuando la tabla de origen de la vista materializada es muy grande y la reposición de la vista basada en la tabla de origen no funciona bien debido a las limitaciones mencionadas anteriormente. En este caso, puede organizar el proceso de reposición en una tabla temporal mediante la ingesta de comandos de consulta. Cuando la tabla temporal incluya todos los registros para el reposición, cree la vista materializada basada en esa tabla.

También puede usar una de las herramientas de orquestación recomendadas.

Ejemplos:

En el ejemplo siguiente, la tabla DeduplicatedTable incluye un único registro por EventId instancia y se usará como línea base para la vista materializada. Solo se incluirán los registros en T que se ingieren después de la hora de creación de la vista en la vista materializada.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
Si la effectiveDateTime propiedad se especifica junto con la move_extents_from propiedad , solo las extensiones en DeduplicatedTable cuyo MaxCreatedOn valor es mayor que effectiveDateTime se incluyen en el rerrelleno (movido a la vista materializada):
```
.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
} 
```
En el ejemplo siguiente se muestra el uso de la source_ingestion_time_from propiedad en la opción de reposición mediante extensiones de movimiento. El uso de e source_ingestion_time_from move_extents_from indica que la vista materializada se rellenó de dos orígenes:
- Tablamove_extents_from: DeduplicatedTable en el ejemplo siguiente. Esta tabla debe incluir todos los datos históricos para recompletar. Opcionalmente, puede usar la effectiveDateTime propiedad para incluir solo extensiones en DeduplicatedTable cuyo MaxCreatedOn valor sea mayor que effectiveDateTime.
- Tabla de origen de la vista materializada: T en el ejemplo siguiente. El reposición de esta tabla solo incluye registros cuyo valor de ingestion_time() es mayor que source_ingestion_time_from.
  
  La source_ingestion_time_from propiedad solo se debe usar para controlar la posible pérdida de datos en el breve tiempo entre preparar la tabla para rerrellenar desde (DeduplicatedTable) y el tiempo en que se crea la vista. No establezca esta propiedad demasiado lejos en el pasado. Esto iniciaría la vista materializada con un retraso significativo, lo que podría ser difícil de ponerse al día.
En el ejemplo siguiente, supongamos que la hora actual es 2020-01-01 03:00. Table DeduplicatedTable es una tabla desduplicada de T. Incluye todos los datos históricos, desduplicados hasta 2020-01-01 00:00. El create comando usa DeduplicatedTable para rerrellenar la vista materializada mediante extensiones de movimiento. El create comando también incluye todos los registros de T que se han ingerido desde 2020-01-01.
```
.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
} 
```

Cancelación de la creación de vistas materializadas

Puede cancelar el proceso de creación de vistas materializadas cuando use la opción de reposición. Esta acción es útil cuando la creación tarda demasiado tiempo y quiere detenerla mientras se ejecuta.

Advertencia

La vista materializada no se puede restaurar después de ejecutar este comando.

El proceso de creación no se puede cancelar inmediatamente. El comando cancel indica la materialización que se va a detener y la creación comprueba periódicamente si se solicitó una cancelación. El comando cancel espera un período máximo de 10 minutos hasta que se cancele el proceso de creación de vistas materializada y notifica si la cancelación se realizó correctamente.

Aunque la cancelación no se realice correctamente en un plazo de 10 minutos y el comando cancel notifica un error, la vista materializada probablemente se cancelará más adelante en el proceso de creación. El .show operations comando indica si se canceló la operación.

Si la operación ya no está en curso cuando se emite el .cancel operation comando, el comando notificará un error que indica esto.

Sintaxis

.cancel operationoperationId

Obtenga más información sobre las convenciones de sintaxis.

Parámetros

Nombre	Type	Obligatorio	Descripción
`operationId`	`guid`	✔️	Identificador de operación devuelto desde el `.create async materialized-view` comando.

Output

Nombre	Escribir	Descripción
OperationId	`guid`	Identificador de la operación del `.create materialized-view` comando.
Operación	`string`	Tipo de operación.
StartedOn	`datetime`	Hora de inicio de la operación de creación.
CancellationState	`string`	Uno de: `Canceled successfully` (se canceló la creación), `Cancellation failed` (espere a que se agote el tiempo de espera de cancelación), `Unknown` (la creación de la vista ya no se está ejecutando, pero esta operación no la canceló).
ReasonPhrase	`string`	Motivo por el que la cancelación no se realizó correctamente.

Ejemplos

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

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

Si la cancelación no ha finalizado en un plazo de 10 minutos, CancellationState indicará un error. Después, se puede cancelar la creación.

Compartir a través de

.create materialized-view

Permisos

Sintaxis

Parámetros

Propiedades admitidas

Crear una vista materializada sobre la vista materializada

Ejemplos

Comentarios

Parámetro de consulta

Funciones de agregación admitidas

Consejos de rendimiento

Reposición de una vista materializada

Reposición mediante extensiones de movimiento

Casos de uso

Cancelación de la creación de vistas materializadas

Sintaxis

Parámetros

Output

Ejemplos

Comentarios

Recursos adicionales