Compartilhar via

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

  • Artigo

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 descreve uma exibição de alto nível de uma diretiva de atualização. Ele mostra duas diretivas 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.

O diagrama mostra uma visão geral da política de atualização.

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 cluster 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 diretiva 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 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 com uma tabela de dimensão estática em seu banco de dados.

Atualizar consulta de política

Se a política de atualização estiver 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 clusters.
    • 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 têm a política RestrictedViewAccess habilitada.
  • Para obter as limitações da política de atualização na ingestão de streaming, consulte Limitações de ingestão de streaming.

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 referenciar a 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("ClusterName").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 Type Descrição
IsEnabled bool Indica se a política de atualização é true - habilitada ou false - desabilitada
Origem string Nome da tabela que dispara 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.
PropagateIngestionProperties bool Estados se as propriedades especificadas durante a ingestão na tabela de origem, como marcas de extensão e tempo de criação, se aplicam à tabela de destino.
ManagedIdentity 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 system palavra reservada. A diretiva 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 diretiva 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, 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 para cada tabela da cadeia.

Comandos de gerenciamento

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

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 as extensões são criadas em uma tabela de origem. Essas ações podem ser feitas usando qualquer um dos seguintes comandos:

Aviso

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

Remover dados da tabela de origem

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

  • 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 preparação em segundo plano em extensões na tabela de origem.

Observação

Quando a tabela de origem tem um período de exclusão flexível de (ou 00:00:00), qualquer política de 0sec 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 do cluster, 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 querieso , 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
  • Definir 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 de política IsTransactional de atualização define se a diretiva 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, 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 apenas para a tabela de origem e não para a 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 diretiva usando o .show ingestion failures comando com o seguinte comando:

.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 extração, transformação, carregamento (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 por 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 são 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