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 diferente, uma política de retenção e outras políticas 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 a partir de 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 mostra 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 acionadas quando os dados são adicionados à segunda tabela de origem. Depois de acionados, 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 da 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 política de atualização 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 propriedade ManagedIdentity 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 com uma tabela de dimensão estática 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 em 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 de 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 textos explicativos (usando um plugin).
• A consulta não tem acesso de leitura a tabelas que tenham a política RestrictedViewAccess habilitada.
• Por padrão, o de política de ingestão de Streaming de está habilitado para todas as tabelas na Casa de Eventos. 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 .altertableTableNamepolicystreamingingestionPolicyObject para desativá-lo.

Advertência

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 funções armazenadas arbitrárias que a consulta pode fazer referência 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 à tabela Source na parte Query da política ou em funções referenciadas pela parte Query:

• 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 objeto é representado como um conjunto de propriedades JSON, com as seguintes propriedades definidas.

Propriedade	Tipo	Descrição
IsEnabled	bool	Indica se a política de atualização é verdadeira - habilitada ou falsa - desabilitada
Fonte	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
IsTransactional	bool	Indica se a política de atualização é transacional ou não, o padrão é falso. Se a política for transacional e a política de atualização falhar, a tabela de origem não será atualizada.
PropagateIngestionProperties	bool	Indica se as propriedades especificadas durante a ingestão na tabela de origem, como as tags de extensão e o tempo de criação, se aplicam à tabela de destino.
Identidade gerenciada	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 diretiva 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:verdadeiro para garantir que a tabela de destino não perca dados em falhas transitórias.

Observação

São permitidas atualizações em cascata, por exemplo, da tabela A, para a tabela B, para a tabela C. No entanto, se as políticas de atualização forem definidas de forma circular, isso será detetado 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 gestão

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 (puxar)
• .ingest (inline)
• .set | .append | .set-or-append | .set-or-replace
• extensões .move
• .substituir extensões
  • O comando PropagateIngestionProperties só tem efeito em operações de ingestão. Quando a política de atualização é acionada como parte de um comando .move extents ou .replace extents, essa opção não tem efeito.

Advertência

Quando a política de atualização é invocada como parte de um comando .set-or-replace, por padrão, os dados em 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 comando replace for invocado. Em vez disso, considere usar .set-or-append.

Remover dados da tabela de origem

Depois de ingerir dados para a tabela de destino, você pode, opcionalmente, removê-los da tabela de origem. Defina um período de exclusão suave de 0sec (ou 00:00:00) na política de retenção de da tabela de origeme a política de atualização como transacional. Aplicam-se as seguintes condições:

• Os dados de origem não podem ser consultados a partir da 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 aliciamento em segundo plano em extensões na tabela de origem.

Observação

Quando a tabela de origem tem um período de exclusão suave de 0sec (ou 00:00:00), qualquer política de atualização referente a essa tabela deve ser transacional.

Impacto no 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 propriedade Source, o nome da tabela de origem, como MySourceTable
• Defina a propriedade Query 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 de IsTransactional de política de atualização define se a política de atualização é transacional e pode afetar o comportamento da atualização de política, da seguinte maneira:

• IsTransactional:false: Se o valor for definido como o valor padrão, falso , a política de atualização não garante 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 apenas 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 garante 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 configuração IsTransactional 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 comando .show ingestion failures 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 extrair, transformar, carregar

Você pode usar as configurações de diretiva de atualização para executar extrair, transformar, carregar (ETL).

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 digitada em 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