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

  • Artigo

As políticas de atualização são mecanismos de automatização acionados quando são escritos novos dados numa tabela. Eliminam a necessidade de orquestração especial ao executar uma consulta para transformar os dados ingeridos e guardar o resultado numa tabela de destino. Podem ser definidas várias políticas de atualização numa única tabela, permitindo transformações diferentes e guardando dados em múltiplas tabelas em simultâneo. As tabelas de destino podem ter um esquema, política de retenção e outras políticas diferentes da tabela de origem.

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

O diagrama seguinte mostra uma vista de alto nível de uma política de atualização. Mostra duas políticas de atualização que são acionadas quando os dados são adicionados à segunda tabela de origem e resultam na adição de dados transformados às duas tabelas de destino.

Diagrama a mostrar uma descrição geral da política de atualização.

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

Nota

  • A tabela de origem e de destino tem de estar na mesma base de dados.
  • O esquema da função de política de atualização e o esquema da tabela de destino têm de corresponder aos nomes, tipos e ordem das colunas.

A ingestão de dados formatados melhora o desempenho e o CSV é preferido devido ao seu formato bem definido. No entanto, por vezes, não tem controlo sobre o formato dos dados ou quer enriquecer os dados ingeridos, por exemplo, ao associar registos a uma tabela de dimensão estática na base de dados.

Atualizar consulta de política

Se a política de atualização estiver definida na tabela de destino, várias consultas podem ser executadas em dados ingeridos numa tabela de origem. Se existirem várias políticas de atualização, a ordem de execução não é necessariamente conhecida.

Limitações de consultas

  • A consulta relacionada com a política pode invocar funções armazenadas, mas:
    • Não é possível efetuar consultas entre clusters.
    • Não consegue aceder a dados externos ou a tabelas externas.
    • Não é possível efetuar chamadas (utilizando um plug-in).
  • A consulta não tem acesso de leitura a tabelas que tenham a política RestrictedViewAccess ativada.
  • Para obter as limitações da política de atualização na ingestão de transmissão em fluxo, veja Limitações da ingestão de transmissão em fluxo.

Aviso

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

Estas 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. Por conseguinte, é fundamental fazer alterações com cuidado para garantir que a política de atualização permanece intacta.

Ao referenciar a Source tabela na Query parte da política ou em funções referenciadas pela Query parte:

  • Não utilize o nome qualificado da tabela. Em vez disso, utilize TableName.
  • Não utilize database("DatabaseName").TableName nem 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 à mesma. Cada objeto é representado como um conjunto de propriedades JSON, com as seguintes propriedades definidas.

Propriedade Tipo Description
IsEnabled bool Indica se a política de atualização é verdadeira – ativada ou falsa – desativada
Origem string Nome da tabela que aciona a invocação da política de atualização
Consulta string Uma consulta utilizada para produzir dados para a atualização
IsTransactional bool Indica que, se a política de atualização for transacional ou não, a predefinição é falsa. Se a política for transacional e a política de atualização falhar, a tabela de origem não será atualizada.
PropagateIngestionProperties bool Os estados se as propriedades especificadas durante a ingestão na tabela de origem, como etiquetas de extensão e tempo de criação, se aplicarem à tabela de destino.
ManagedIdentity string A identidade gerida em nome da qual a política de atualização é executada. A identidade gerida pode ser um ID de objeto ou a system palavra reservada. A política de atualização tem de ser configurada com uma identidade gerida quando a consulta referencia tabelas noutras bases de dados ou tabelas com uma política de segurança ao nível da linha ativada. Para obter mais informações, veja Utilizar uma identidade gerida para executar uma política de atualização.

Nota

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

Nota

As atualizações em cascata são permitidas, por exemplo, da tabela A à tabela B, à tabela C. No entanto, se as políticas de atualização forem definidas de forma circular, estas são detetadas no runtime e a cadeia de atualizações é cortada. Os dados são ingeridos apenas uma vez para cada tabela na cadeia.

Comandos de gestão

Os comandos de gestão de políticas de atualização incluem:

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

As políticas de atualização têm efeito quando os dados são ingeridos ou movidos para uma tabela de origem, ou as extensões são criadas numa tabela de origem, utilizando qualquer um dos seguintes comandos:

Aviso

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

Remover dados da tabela de origem

Depois de ingerir dados para a tabela de destino, pode, opcionalmente, removê-lo da tabela de origem. Defina um período de eliminação recuperável de 0sec (ou 00:00:00) na política de retenção da tabela de origem e 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 tratamento em segundo plano em extensões na tabela de origem.

Nota

Quando a tabela de origem tem um período de eliminação recuperável de 0sec (ou 00:00:00), qualquer política de atualização que referencie esta tabela tem de ser transacional.

Impacto no 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 com a política. Pode testar o impacto de desempenho de uma política de atualização ao invocar a política em extensões já existentes, antes de criar ou alterar a política ou na função utilizada com a consulta.

Avaliar a utilização de recursos

Utilize .show queries, para avaliar a utilização de recursos (CPU, memória, etc.) 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 com o nome 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

Falhas

Com a predefinição de IsTransactional:false, os dados ainda podem ser ingeridos na tabela de origem, mesmo que a política não seja executada.

A definição IsTransactional:true garante a consistência entre os dados na tabela de origem e de destino. No entanto, se as condições da política falharem, os dados não serão ingeridos na tabela de origem. Em alternativa, dependendo das condições, por vezes, os dados são ingeridos na tabela de origem, mas não para a tabela de destino. No entanto, se a política estiver definida incorretamente ou se existir um erro de correspondência de esquema, os dados não são ingeridos na tabela de origem ou de destino. Por exemplo, um erro de correspondência entre o esquema de saída da consulta e a tabela de destino pode ser causado pela remoção de uma coluna da tabela de destino.

Pode ver as falhas com o .show ingestion failures comando .

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

Tratamento de falhas

Política nãotransacional

Quando definida como IsTransactional:false, qualquer falha na execução da política é ignorada. A ingestão não é repetida automaticamente. Pode repetir a ingestão manualmente.

Política transacional

Quando definido como IsTransactional:true, se o método de ingestão for pull, o serviço Gestão de Dados está envolvido e a ingestão é repetida automaticamente de acordo com as seguintes condições:

  • As repetições são executadas até que uma das seguintes definições de limite configurável seja cumprida: DataImporterMaximumRetryPeriod ou DataImporterMaximumRetryAttempts
  • Por predefinição, a DataImporterMaximumRetryPeriod definição é de dois dias e DataImporterMaximumRetryAttemptsé 10
  • O período de recuo começa em 2 minutos e duplica. Assim, a espera começa com 2 min, depois aumenta para 4 min, para 8 min, para 16 min e assim por diante.

Em qualquer outro caso, pode repetir manualmente a ingestão.

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

Pode utilizar as definições de política de atualização para efetuar extração, transformação, carregamento (ETL).

Neste exemplo, utilize 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 com tipo de cadeia na qual os dados são ingeridos.
  • A tabela de destino - Contém o esquema pretendido. A política de atualização está 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 criámos:

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

  5. Para esvaziar a tabela de origem após a ingestão de dados na tabela de destino, defina a política de retenção na tabela de origem para ter 0s como o respetivo SoftDeletePeriod.

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

Conteúdo relacionado