Compartir a través de

.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 está 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 reintenta 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

Debe tener al menos permisos de administrador de base de datos para ejecutar este comando. El creador de la vista materializada se convierte en su administrador.

Sintaxis

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

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

Parámetros

Nombre Tipo 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 Tipo 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 rellena 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 en true, la hora de creación de extensiones 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 Intervalo de tiempo que limita el período durante el que se esperan duplicados o actualizaciones. Para obtener más información, consulte período de búsqueda.
lookback_column string Columna string de la vista que actúa como referencia para el período de búsqueda. Si esta columna está vacía, pero el lookback tiene un valor, la vista materializada usa una búsqueda predeterminada. Para obtener más información, consulte período de búsqueda.
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 trueen , los cambios realizados en la tabla de origen se reflejan automáticamente en la vista materializada.
dimensionTables arreglo Argumento dinámico que incluye una matriz de tablas de dimensiones en la vista. Consulte Parámetro de consulta.
carpeta 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 deshabilita automáticamente una vista materializada si los cambios realizados en la tabla de origen de la vista materializada, o los cambios en los datos, provocan 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 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 .enable materialized-view .

Período de retrospectiva

Un lookback especifica el período de tiempo máximo esperado entre dos registros de la misma combinación de teclas agrupadas por en la tabla de origen de vista materializada. Establecer un lookback puede mejorar significativamente el rendimiento de la vista materializada.

Por ejemplo, considere una vista materializada que se usa para almacenar el último evento para cada sesión de un servicio web. La vista se define de la siguiente manera:

Events | summarize arg_max(ReceivedTime, *) by SessionId

Cuando esté claro que una sesión no dura más de un día, se puede establecer el período y lookback_column para mejorar el lookback rendimiento:

.create materialized-view with(lookback=1d, lookback_column = "ReceivedTime") SessionEvents on table Events
{
    Events
    | summarize arg_max(ReceivedTime, *) by SessionId
}

Si se establece una búsqueda en una vista materializada, se reduce la parte de la vista analizada durante la materialización. En lugar de examinar toda la vista materializada, solo la parte que se encuentra dentro del período de búsqueda se combina con la diferencia durante la materialización. Para obtener más información, consulte Funcionamiento de las vistas materializadas. Aunque este paso puede mejorar significativamente el rendimiento de la vista materializada, establecer un período de búsqueda incorrecto puede dar lugar a registros duplicados. En el ejemplo anterior, si un registro se ingiere dos días después de un registro para el mismo SessionId, la vista materializada tendrá registros duplicados para ese SessionId.

Columna lookback

El período de búsqueda siempre es relativo a una datetime columna de la vista materializada. Hay dos maneras de definir esta columna:

  • Predeterminado: En relación con la ingestion_time() del registro en la tabla de origen. Los registros solo se desduplican en los registros que se ingieren en la tabla de origen después de un período de búsqueda relativo a los registros actuales. Este tipo de búsqueda es válido solo para arg_maxlas vistas materializadas , arg_mino take_any , y solo para las vistas que conservan el tiempo de ingesta. Para obtener más información, vea Limitaciones de vistas materializadas y problemas conocidos. Puede configurar la opción predeterminada estableciendo la lookback propiedad sin la lookback_column propiedad .

  • lookback_column (versión preliminar): Relativo a una datetime columna de la vista materializada. El lookback se especifica explícitamente en la definición de vista materializada mediante la lookback_column propiedad . Para más información, consulte Limitaciones conocidas. Puede configurar la opción de columna lookback estableciendo las lookback propiedades y lookback_column .

Limitaciones conocidas

  • Una vez definido , lookback_column no se puede cambiar su valor.
  • El uso de puede lookback_column provocar duplicados si la columna tiene datetime(null) valores. En tales casos, para una combinación determinada de claves group-by, la vista puede acabar con un registro que tiene un datetime(null) valor y otro con un valor distinto de NULL.

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 SourceMaterializedViewNameon materialized-view{}

Parámetros:

Nombre Tipo 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 seis horas. Los registros solo se desduplican en los registros ingeridos seis 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 en función de la DeduplicatedTable vista materializada:

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

  • Cree una vista materializada que desduplica la tabla de origen, basada en la EventId columna, mediante una búsqueda de seis horas. Los registros se desduplican en los registros cuya Timestamp diferencia máxima es de seis horas respecto a los registros actuales.

    .create materialized-view with(lookback=6h, lookback_column = "Timestamp") LatestEventID on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
}

  • 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_max/arg_min/take_anyagregació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 comoarg_max/arg_min/ otras agregaciones en la misma vista).take_any

  • 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 quita de la vista y nunca se vuelve a procesar.

      Del mismo modo, si la combinación es una combinación externa, los registros de la tabla de hechos se procesan y agregan para ver con un valor NULL para las columnas de la tabla de dimensiones. Los registros que ya se agregaron (con valores NULL) a la vista no se vuelven a procesar. Sus valores, en columnas de la tabla de dimensiones, permanecen null.

Funciones de agregación admitidas

Se admiten las siguientes funciones de agregación:

Consejos de rendimiento

  • Use una clave de grupo por fecha y hora: las vistas materializadas que tienen una datetime columna 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 datetime columna 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 debe examinar la vista materializada durante los seis meses anteriores. Si este período está en caché en frío, la materialización experimenta errores de caché que tienen 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 SubscriptionIdfiltra . 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 crea en función de los registros disponibles en la tabla de origen. O bien, se crea 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 produce un error en el comando y se requiere 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é en frío. 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 la base de datos es baja, ya que el aumento puede afectar significativamente al consumo de CPU de la base de datos.

Por ejemplo, el siguiente comando rellena 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 ejecuta 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 asigna tiempo de creación basado en 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 quitan de la tabla especificada durante el reposición (movido, no copiado).

Las extensiones de reposición por movimiento no se admiten para todas las funciones de agregación admitidas en vistas materializadas. Se produce un error en las agregaciones como avg(), dcount(), en las que los datos subyacentes almacenados en la vista son diferentes a 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 comienza 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 incluyen 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 usa como línea base para la vista materializada. Solo los registros de T que se ingieren después de la hora de creación de la vista se incluyen 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_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 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. Notifica de nuevo 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 notifica un error.

Sintaxis

.cancel operation operationId

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

Parámetros

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

Salida

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 finaliza en un plazo de 10 minutos, CancellationState indica un error. Después, se puede cancelar la creación.

Contenido relacionado