.create materialized-view

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. Incluye solo los 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, según el 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 grandes, 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, vea Reposición de una vista materializada.

Permisos

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

Syntax

.create[] [asyncifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon tableSourceTableName{Consulta}

Más información sobre las convenciones de sintaxis.

Parámetros

Nombre	Tipo	Requerido	Descripción
PropertyName, PropertyValue	string		Lista de propiedades en forma de pares de 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.
Consultar	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 propiedades siguientes se admiten en la with( cláusula PropertyName=PropertyValue). Todas las propiedades son opcionales.

Nombre	Tipo	Descripción
Relleno	bool	Si se va a crear la vista en función de todos los registros que se encuentran actualmente en SourceTable (true), o para crearla a partir de ahora (false). El valor predeterminado es false. Para obtener más información, vea Reposición de una vista materializada.
effectiveDateTime	datetime	Solo es relevante cuando se usa backfill. Si se establece, la creación se revierte solo con los 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 trueen , 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, vea 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 registros recién ingeridos y las existentes tendrá en cuenta solo los registros ingeridos hace hasta 6 horas. Lookback es relativo a ingestion_time. Definir el período de devolución 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 devolución de búsqueda se establece en 6 horas, esa clave será un duplicado en la vista. El período de devolución 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 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 trueen , los cambios 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, el complemento bag_unpack o 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 mediante la definición de la consulta de vista como arg_max(Timestamp, Column1, Column2, ...), o mediante la autoUpdateSchema opción .
• El uso autoUpdateSchema de podría 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 .

Creación de 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,...)] MaterializedViewNameon materialized-viewSourceMaterializedViewName{Consulta}

Parámetros:

Nombre	Tipo	Requerido	Descripción
PropertyName, PropertyValue	string		Lista de propiedades en forma de pares de 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.
Consultar	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, en función de 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 base 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 materialized view:

• La consulta debe hacer referencia a una única tabla de hechos 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 agregación única arg_maxarg_mintake_any//podría funcionar mejor que una vista materializada que incluye 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 las medias mixtasarg_max//arg_mintake_any y 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 la 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. Obtenga acceso a la función almacenada en lugar de acceder directamente a la vista materializada.

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

• No se admiten referencias a external_table() ni 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 comportamiento siguiente al combinar con tablas de dimensiones:

  • Los registros de la tabla de origen de la vista (la tabla de hechos) solo se materializan una vez. Novedades a 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 procesará de nuevo.

    Del mismo modo, si la combinación es una combinación externa, se procesará el registro de la tabla de hechos y se 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:

• count
• countif
• dcount
• dcountif
• min
• max
• avg
• avgif
• sum
• sumif
• arg_max
• arg_min
• take_any
• take_anyif
• hll
• make_set
• make_list
• make_bag
• percentile, percentiles
• tdigest

Consejos de rendimiento

• Use una clave de grupo por fecha y hora: las vistas materializadas que tienen una columna datetime como una de sus claves de agrupación son más eficaces que las que no lo hacen. El motivo es que algunas optimizaciones solo se pueden aplicar cuando hay una clave datetime group-by. 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 lo 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 varios valores atípicos en los datos tienen valores muy antiguos Timestamp . Estos valores atípicos pueden afectar negativamente a la vista materializada.

  Se recomienda que, en la consulta de vista materializada, filtre los registros atípicos o normalice estos registros a la hora actual.

• Definir un período de búsqueda: si es aplicable a su escenario, agregar una lookback propiedad puede mejorar significativamente el rendimiento de las 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 mediante una de las claves agrupadas de 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, inclúyela en las claves agrupadas 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 
  }
  

• Usar 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 de 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 lo 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 para reposición en varios lotes y ejecuta varias operaciones de ingesta para volver a 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 del clúster. Realice un seguimiento del progreso del reposición mediante el .show operations comando .

Se reintentan los errores transitorios que se producen como parte del proceso de reposición. 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 de 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 escalabilidad horizontal.

Si experimenta errores en la creación de vistas, 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 de cada operación de ingesta).

  Reducir este valor puede ser útil cuando se produce un error en la creación en los límites de memoria o en los tiempos de espera de consulta. Aumentar este valor puede acelerar la creación de vistas, suponiendo que el clúster 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 del clúster es baja, ya que el aumento puede afectar significativamente al consumo de CPU del clúster.

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 de grupo por fecha y hora, el proceso de reposición admite la invalidación de la hora de creación de la extensión en función de la columna datetime. Esto puede ser útil, por ejemplo, si desea que los registros más antiguos se quiten 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 Timestamp clave group-by:

.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 al mover extensiones 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 cual. 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 migración de extensiones 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 la 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 provocar cierta 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 reposición 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 está usando 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 usted mismo en una tabla temporal mediante la ingesta de comandos de consulta y una de las herramientas de orquestación recomendadas. Cuando la tabla temporal incluya todos los registros para el reposición, cree la vista materializada basada en esa tabla.

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 de 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 se incluyen extensiones en DeduplicatedTable cuyo MaxCreatedOn valor es mayor que effectiveDateTime en el reposición (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_frommove_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 reposición. 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. La reposición de esta tabla incluye solo los 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 reposición 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. La tabla 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 rellenar 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 la vista materializada y notifica si la cancelación se realizó correctamente.

Incluso si la cancelación no se realiza 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 lo indica.

Syntax

.cancel operationoperationId

Más información sobre las convenciones de sintaxis.

Parámetros

Nombre	Tipo	Requerido	Descripción
operationId	guid	✔️	El identificador de operación devuelto por el .create async materialized-view comando .

Output

Nombre	Tipo	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. A continuación, se puede cancelar la creación.