.create materialized-view
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
[] [async
ifnotexists
] 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. |
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 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_min take_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 cuandoautoUpdateSchema
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 comoarg_max(Timestamp, Column1, Column2, ...)
o mediante laautoUpdateSchema
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
[] [async
ifnotexists
] 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. |
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
yeffectiveDateTime
. 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 quesummarize
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. Elsummarize
operador siempre debe ser el último operador de la consulta.Una vista materializada que incluye solo una sola
arg_max
arg_min
take_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_max
arg_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 tenerwhere 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, ejecuteMaterializedViewName | 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:
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 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 mismoTimestamp
valor y, por tanto, agregarTimestamp
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 antiguosTimestamp
. 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 unResourceId
valor que a menudo se filtrará medianteSubscriptionId
. Suponiendo que unResourceId
valor siempre pertenece al mismoSubscriptionId
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 esmin(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 porEventId
instancia y se usará como línea base para la vista materializada. Solo se incluirán los registros enT
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 lamove_extents_from
propiedad , solo las extensiones enDeduplicatedTable
cuyoMaxCreatedOn
valor es mayor queeffectiveDateTime
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 esource_ingestion_time_from
move_extents_from
indica que la vista materializada se rellenó de dos orígenes:Tabla
move_extents_from
:DeduplicatedTable
en el ejemplo siguiente. Esta tabla debe incluir todos los datos históricos para recompletar. Opcionalmente, puede usar laeffectiveDateTime
propiedad para incluir solo extensiones enDeduplicatedTable
cuyoMaxCreatedOn
valor sea mayor queeffectiveDateTime
.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 quesource_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
. TableDeduplicatedTable
es una tabla desduplicada deT
. Incluye todos los datos históricos, desduplicados hasta2020-01-01 00:00
. Elcreate
comando usaDeduplicatedTable
para rerrellenar la vista materializada mediante extensiones de movimiento. Elcreate
comando también incluye todos los registros deT
que se han ingerido desde2020-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 operation
operationId
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.