Visão geral da política de atualização

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer

As políticas de atualização são mecanismos de automação acionados quando novos dados são gravados em uma tabela. Eles eliminam a necessidade de orquestração especial executando uma consulta para transformar os dados ingeridos e salvar o resultado em uma tabela de destino. Várias políticas de atualização podem ser definidas em uma única tabela, permitindo diferentes transformações e salvando dados em várias tabelas simultaneamente. As tabelas de destino podem ter um esquema, uma política de retenção e outras políticas diferentes da tabela de origem.

Por exemplo, uma tabela de origem de rastreamento de alta taxa pode conter dados formatados como uma coluna de texto livre. A tabela de destino pode incluir linhas de rastreamento específicas, com um esquema bem estruturado gerado por uma transformação dos dados de texto livre da tabela de origem usando o operador de análise. Para obter mais informações, cenários comuns.

O diagrama a seguir ilustra uma exibição de alto nível de uma política de atualização. Ele mostra duas políticas de atualização que são disparadas quando os dados são adicionados à segunda tabela de origem. Depois de disparados, os dados transformados são adicionados às duas tabelas de destino.

Uma política de atualização está sujeita às mesmas restrições e práticas recomendadas que a ingestão regular. A política é dimensionada de acordo com o tamanho do Eventhouse e é mais eficiente ao lidar com a ingestão em massa.

Observação

• A tabela de origem e de destino deve estar no mesmo banco de dados.
• O esquema da função de política de atualização e o esquema da tabela de destino devem corresponder em seus nomes de coluna, tipos e ordem.
• A função de atualização de política pode fazer referência a tabelas em outros bancos de dados. Para fazer isso, a política de atualização deve ser definida com uma ManagedIdentity propriedade e a identidade gerenciada deve ter viewerfunção nos bancos de dados referenciados. A ingestão de dados formatados melhora o desempenho, e o CSV é preferido por ser um formato bem definido. Às vezes, no entanto, você não tem controle sobre o formato dos dados ou deseja enriquecer os dados ingeridos, por exemplo, unindo registros a uma tabela de dimensões estáticas em seu banco de dados.

Consulta de política de atualização

Se a política de atualização for definida na tabela de destino, várias consultas poderão ser executadas nos dados ingeridos em uma tabela de origem. Se houver várias políticas de atualização, a ordem de execução não será necessariamente conhecida.

Limitações da consulta

• A consulta relacionada à política pode invocar funções armazenadas, mas:
  • Ele não pode executar consultas entre eventos.
  • Ele não pode acessar dados externos ou tabelas externas.
  • Ele não pode fazer chamadas (usando um plug-in).
• A consulta não tem acesso de leitura a tabelas que têm a política RestrictedViewAccess habilitada.
• Por padrão, a política de ingestão de streaming está habilitada para todas as tabelas no Eventhouse. Para usar funções com o operador join em uma política de atualização, a política de ingestão de streaming deve ser desabilitada. Use o comando TableNamePolicyObject para desabilitá-lo.

Aviso

Uma consulta incorreta pode impedir a ingestão de dados na tabela de origem. É importante observar que as limitações, bem como a compatibilidade entre os resultados da consulta e o esquema das tabelas de origem e destino, podem causar uma consulta incorreta para impedir a ingestão de dados na tabela de origem.

Essas limitações são validadas durante a criação e execução da política, mas não quando as funções armazenadas arbitrárias que a consulta pode referenciar são atualizadas. Portanto, é crucial fazer quaisquer alterações com cautela para garantir que a política de atualização permaneça intacta.

Ao fazer referência à Source tabela na Query parte da política ou em funções referenciadas pela Query parte:

• Não use o nome qualificado da tabela. Em vez disso, use TableName.
• Não use database("<DatabaseName>").TableName ou cluster("<EventhouseName>").database("<DatabaseName>").TableName.

O objeto de política de atualização

Uma tabela pode ter zero ou mais objetos de política de atualização associados a ela. Cada um desses objetos é representado como um recipiente de propriedades JSON, com as propriedades a seguir definidas.

Propriedade	Type	Descrição
IsEnabled	bool	Declara se a política de atualização é verdadeira - habilitada ou falsa - desabilitada
Origem	string	Nome da tabela que aciona a invocação da política de atualização
Consulta	string	Uma consulta usada para produzir dados para a atualização
IsTransacional	bool	Indica se a política de atualização é transacional ou não, o padrão é false. Se a política for transacional e a política de atualização falhar, a tabela de origem não será atualizada.
Propagar	bool	Declara se as propriedades especificadas durante a assimilação na tabela de origem, como marcas de extensão e hora de criação, se aplicam à tabela de destino.
Identidadegerenciada	string	A identidade gerenciada em nome da qual a política de atualização é executada. A identidade gerenciada pode ser uma ID de objeto ou a palavra reservada system . A política de atualização deve ser configurada com uma identidade gerenciada quando a consulta faz referência a tabelas em outros bancos de dados ou tabelas com uma política de segurança em nível de linha habilitada. Para obter mais informações, consulte Usar uma identidade gerenciada para executar uma política de atualização.

Observação

Em sistemas de produção, defina IsTransactional:true para garantir que a tabela de destino não perca dados em falhas transitórias.

Observação

Atualizações em cascata são permitidas, por exemplo, da tabela A para a tabela B e para a tabela C. No entanto, se as políticas de atualização forem definidas de maneira circular, isso será detectado em tempo de execução e a cadeia de atualizações será cortada. Os dados são ingeridos apenas uma vez em cada tabela da cadeia.

Comandos de gerenciamento

Os comandos de gerenciamento de política de atualização incluem:

• .show table *TableName* policy update mostra a política de atualização atual de uma tabela.
• .alter table *TableName* policy update Define a política de atualização atual de uma tabela.
• .alter-merge table *TableName* policy update Acrescenta definições à política de atualização atual de uma tabela.
• .delete table *TableName* policy update exclui a política de atualização atual de uma tabela.

A política de atualização é iniciada após a ingestão

As políticas de atualização entram em vigor quando os dados são ingeridos ou movidos para uma tabela de origem, ou extensões são criadas em uma tabela de origem. Essas ações podem ser feitas usando qualquer um dos seguintes comandos:

• .ingest (pull)
• .ingest (embutido)
• .set | .append | .set-or-append | .set-or-replace
• .mover extensões
• .substituir extensões
  • O PropagateIngestionProperties comando só entra em vigor em operações de ingestão. Quando a política de atualização é disparada como parte de um .move extents comando or .replace extents , essa opção não tem efeito.

Aviso

Quando a política de atualização é invocada como parte de um .set-or-replace comando, por padrão, os dados nas tabelas derivadas são substituídos da mesma forma que na tabela de origem. Os dados podem ser perdidos em todas as tabelas com uma relação de política de atualização se o replace comando for invocado. Considere o uso de .set-or-append em seu lugar.

Remover dados da tabela de origem

Depois de assimilar dados na tabela de destino, você pode removê-los da tabela de origem. Defina um período de exclusão reversível de (ou 0sec) na política00:00:00tabela de origem e a política de atualização como transacional. As seguintes condições se aplicam:

• Os dados de origem não podem ser consultados na tabela de origem
• Os dados de origem não persistem no armazenamento durável como parte da operação de ingestão
• O desempenho operacional melhora. Os recursos pós-ingestão são reduzidos para operações de limpeza em segundo plano em extensões na tabela de origem.

Observação

Quando a tabela de origem tem um período de exclusão reversível de (ou 0sec), qualquer política de 00:00:00 atualização que faça referência a essa tabela deve ser transacional.

Impacto sobre o desempenho

As políticas de atualização podem afetar o desempenho e a ingestão de extensões de dados é multiplicada pelo número de tabelas de destino. É importante otimizar a consulta relacionada à política. Você pode testar o impacto no desempenho de uma política de atualização invocando a política em extensões já existentes, antes de criar ou alterar a política ou na função usada com a consulta.

Avaliar o uso de recursos

Use .show queries, para avaliar o uso de recursos (CPU, memória e assim por diante) com os seguintes parâmetros:

• Defina a Source propriedade, o nome da tabela de origem, como MySourceTable
• Defina a Query propriedade para chamar uma função chamada MyFunction()

// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
    MySourceTable
    | project ExtentId = extent_id(), IngestionTime = ingestion_time()
    | where IngestionTime > ago(10m)
    | top 1 by IngestionTime desc
    | project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
    MySourceTable
    | where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction

Configurações transacionais

A configuração da política IsTransactional de atualização define se a política de atualização é transacional e pode afetar o comportamento da atualização da política, da seguinte maneira:

• IsTransactional:false: se o valor for definido como o valor padrão, false, a política de atualização não garantirá a consistência entre os dados na tabela de origem e de destino. Se uma política de atualização falhar, os dados serão ingeridos somente na tabela de origem e não na tabela de destino. Nesse cenário, a operação de ingestão é bem-sucedida.
• IsTransactional:true: Se o valor for definido como true, a configuração garantirá a consistência entre os dados nas tabelas de origem e de destino. Se uma política de atualização falhar, os dados não serão ingeridos na tabela de origem ou de destino. Nesse cenário, a operação de ingestão não é bem-sucedida.

Tratamento de falhas

Quando as atualizações de política falham, elas são tratadas de forma diferente com base no fato de a IsTransactional configuração ser true ou false. Os motivos comuns para falhas na política de atualização são:

• Uma incompatibilidade entre o esquema de saída da consulta e a tabela de destino.
• Qualquer erro de consulta.

Você pode exibir falhas de atualização de política usando o .show ingestion failures comando com o seguinte comando: Em qualquer outro caso, você pode repetir manualmente a ingestão.

.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true

Exemplo de extração, transformação, carregamento

Você pode usar as configurações de política de atualização para executar ETL (extração, transformação e carregamento).

Neste exemplo, use uma política de atualização com uma função simples para executar ETL. Primeiro, criamos duas tabelas:

• A tabela de origem - Contém uma única coluna do tipo cadeia de caracteres na qual os dados são ingeridos.
• A tabela de destino - Contém o esquema desejado. A política de atualização é definida nesta tabela.

1. Vamos criar a tabela de origem:

   .create table MySourceTable (OriginalRecord:string)
   

2. Em seguida, crie a tabela de destino:

   .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
   

3. Em seguida, crie uma função para extrair dados:

   .create function
    with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions')
        ExtractMyLogs()
       {
       MySourceTable
       | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string
       | project-away OriginalRecord
   }
   

4. Agora, defina a política de atualização para invocar a função que criamos:

   .alter table MyTargetTable policy update
   @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
   

5. Para esvaziar a tabela de origem depois que os dados forem ingeridos na tabela de destino, defina a política de retenção na tabela de origem para ter 0s como seu SoftDeletePeriod.

    .alter-merge table MySourceTable policy retention softdelete = 0s
   

Conteúdo relacionado

• Cenários comuns para usar políticas de atualização de tabela
• Tutorial: rotear dados usando políticas de atualização de tabela