Descrição geral de exportação de dados contínua

  • Artigo

Este artigo descreve a exportação contínua de dados do Kusto para uma tabela externa com uma consulta de execução periódica. Os resultados são armazenados na tabela externa, que define o destino, como Armazenamento de Blobs do Azure e o esquema dos dados exportados. Este processo garante que todos os registos são exportados "exatamente uma vez", com algumas exceções. Por predefinição, a exportação contínua é executada num modo distribuído, onde todos os nós são exportados em simultâneo, pelo que o número de artefactos depende do número de nós no cluster. A exportação contínua não foi concebida para dados de transmissão em fluxo de baixa latência a partir do cluster.

Para ativar a exportação contínua de dados, crie uma tabela externa e, em seguida, crie uma definição de exportação contínua que aponte para a tabela externa.

Em alguns casos, tem de utilizar uma identidade gerida para configurar com êxito uma tarefa de exportação contínua. Para obter mais informações, veja Utilizar uma identidade gerida para executar uma tarefa de exportação contínua.

Permissões

Todos os comandos de exportação contínua requerem, pelo menos, permissões de Administração da Base de Dados.

Diretrizes de exportação contínua

  • Esquema de saída:

    • O esquema de saída da consulta de exportação tem de corresponder ao esquema da tabela externa à qual exporta.

  • Frequência:

    • A exportação contínua é executada de acordo com o período de tempo configurado na intervalBetweenRuns propriedade . O valor recomendado para este intervalo é, pelo menos, vários minutos, consoante as latências que está disposto a aceitar. O intervalo de tempo pode ser tão baixo como um minuto, se a taxa de ingestão for elevada.

      Nota

      O intervalBetweenRuns serve apenas como recomendação e não é garantido que seja preciso. A exportação contínua não é adequada para exportar agregações periódicas. Por exemplo, uma configuração de intervalBetweenRuns=1h com uma agregação por hora (T | summarize by bin(Timestamp, 1h)) não funcionará conforme esperado, uma vez que a exportação contínua não será executada exatamente à hora. Por conseguinte, cada classe por hora receberá várias entradas nos dados exportados.

  • Número de ficheiros:

    • O número de ficheiros exportados em cada iteração de exportação contínua depende da forma como a tabela externa é particionada. Para obter mais informações, veja Exportar para o comando de tabela externa. Cada iteração de exportação contínua escreve sempre em novos ficheiros e nunca acrescenta aos existentes. Como resultado, o número de ficheiros exportados também depende da frequência com que a exportação contínua é executada. O parâmetro frequency é intervalBetweenRuns.

  • Contas de armazenamento de tabelas externas:

    • Para um melhor desempenho, o cluster e as contas de armazenamento devem estar colocalizados na mesma região do Azure.
    • A exportação contínua funciona de forma distribuída, de modo a que todos os nós no cluster estejam a exportar em simultâneo. Em clusters grandes e se o volume de dados exportado for grande, isto pode levar à limitação do armazenamento. É recomendado configurar várias contas de armazenamento para a tabela externa. Veja falhas de armazenamento durante os comandos de exportação para obter mais detalhes.

Exportação exatamente uma vez

Para garantir a exportação "exatamente uma vez", a exportação contínua utiliza cursores de base de dados. A consulta de exportação contínua não deve incluir um filtro de carimbo de data/hora. O mecanismo de cursors da base de dados garante que os registos não são processados mais do que uma vez. Adicionar um filtro de carimbo de data/hora na consulta pode levar à falta de dados nos dados exportados.

A política IngestionTime tem de ser ativada em todas as tabelas referenciadas na consulta que devem ser processadas "exatamente uma vez" na exportação. A política está ativada por predefinição em todas as tabelas criadas recentemente.

A garantia de exportação "exatamente uma vez" é apenas para ficheiros comunicados no comando mostrar artefactos exportados. A exportação contínua não garante que cada registo seja escrito apenas uma vez na tabela externa. Se ocorrer uma falha após o início da exportação e alguns dos artefactos já tiverem sido escritos na tabela externa, a tabela externa poderá conter duplicados. Se uma operação de escrita tiver sido abortada antes da conclusão, a tabela externa poderá conter ficheiros danificados. Nestes casos, os artefactos não são eliminados da tabela externa, mas não serão reportados no comando mostrar artefactos exportados. Consumir os ficheiros exportados com as show exported artifacts command garantias de não haver duplicações nem danos.

Exportar de tabelas de factos e dimensões

Por predefinição, todas as tabelas referenciadas na consulta de exportação são consideradas tabelas de factos. Como tal, estão no âmbito do cursor da base de dados. A sintaxe declara explicitamente quais as tabelas com âmbito (facto) e que não têm âmbito (dimensão). Veja o over parâmetro no comando create (criar) para obter detalhes.

A consulta de exportação inclui apenas os registos associados desde a execução da exportação anterior. A consulta de exportação pode conter tabelas de dimensão nas quais todos os registos da tabela de dimensões estão incluídos em todas as consultas de exportação. Ao utilizar associações entre tabelas de factos e dimensões na exportação contínua, tenha em atenção que os registos na tabela de factos só são processados uma vez. Se a exportação for executada enquanto os registos nas tabelas de dimensão estiverem em falta para algumas chaves, os registos das respetivas chaves serão perdidos ou incluirão valores nulos para as colunas de dimensão nos ficheiros exportados. Devolver registos perdidos ou nulos depende se a consulta utiliza a associação interna ou externa. A forcedLatency propriedade na definição de exportação contínua pode ser útil nesses casos, em que as tabelas de factos e dimensões são ingeridas ao mesmo tempo para registos correspondentes.

Nota

A exportação contínua de apenas tabelas de dimensão não é suportada. A consulta de exportação tem de incluir, pelo menos, uma única tabela de factos.

Monitorizar a exportação contínua

Monitorize o estado de funcionamento das suas tarefas de exportação contínua com as seguintes métricas de exportação:

  • Continuous export max lateness - Latência máxima (em minutos) das exportações contínuas no cluster. Este é o tempo entre agora e a hora mínima ExportedTo de todas as tarefas de exportação contínua no cluster. Para obter mais informações, veja .show continuous export comando.
  • Continuous export result - Resultado de êxito/falha de cada execução de exportação contínua. Esta métrica pode ser dividida pelo nome de exportação contínua.

Utilize o .show continuous export failures comando para ver as falhas específicas de uma tarefa de exportação contínua.

Aviso

Se uma exportação contínua falhar durante mais de 7 dias devido a uma falha permanente, a exportação será automaticamente desativada pelo sistema. Os erros permanentes incluem: tabela externa não encontrada, erro de correspondência entre o esquema da consulta de exportação contínua e o esquema de tabela externo, a conta de armazenamento não está acessível. Depois de o erro ter sido corrigido, pode reativar a exportação contínua com o .enable continuous export comando .

Consumo de recursos

  • O impacto da exportação contínua no cluster depende da consulta em que a exportação contínua está em execução. A maioria dos recursos, como a CPU e a memória, são consumidos pela execução da consulta.
  • O número de operações de exportação que podem ser executadas em simultâneo é limitado pela capacidade de exportação de dados do cluster. Para obter mais informações, veja Comandos de gestão de limitação. Se o cluster não tiver capacidade suficiente para processar todas as exportações contínuas, algumas começarão a ficar atrasadas.
  • O comando mostrar comandos e consultas pode ser utilizado para estimar o consumo de recursos.
    • | where ClientActivityId startswith "RunContinuousExports" Filtre para ver os comandos e consultas associados à exportação contínua.

Exportar dados históricos

A exportação contínua começa a exportar dados apenas a partir do ponto de criação. Os registos ingeridos antes dessa hora devem ser exportados separadamente com o comando de exportação não contínua. Os dados históricos podem ser demasiado grandes para serem exportados num único comando de exportação. Se necessário, particione a consulta em vários lotes mais pequenos.

Para evitar duplicados com dados exportados pela exportação contínua, utilize StartCursor o comando mostrar exportação contínua e exporte apenas o where cursor_before_or_at valor do cursor. Por exemplo:

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

Seguido de:

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

Exportação contínua de uma tabela com Segurança ao Nível da Linha

Para criar uma tarefa de exportação contínua com uma consulta que faça referência a uma tabela com a política de Segurança ao Nível da Linha, tem de:

Exportação contínua para tabela delta - Pré-visualização

A exportação contínua para uma tabela delta está atualmente em pré-visualização.

Importante

A criação de partições de tabelas Delta não é suportada na exportação contínua de dados.

O Kusto não escreverá em tabelas delta existentes se a versão do escritor do protocolo delta for superior a 1.

Para definir a exportação contínua para uma tabela delta, siga os seguintes passos:

  1. Crie uma tabela delta externa, conforme descrito em Criar e alterar tabelas externas delta no Armazenamento do Azure.

    Nota

    Se o esquema não for fornecido, o Kusto tentará inferi-lo automaticamente se já existir uma tabela delta definida no contentor de armazenamento de destino.
    A criação de partições de tabelas Delta não é suportada.

  2. Defina a exportação contínua para esta tabela com os comandos descritos em Criar ou alterar a exportação contínua.

    Importante

    O esquema da tabela delta tem de estar sincronizado com a consulta de exportação contínua. Se a tabela delta subjacente for alterada, a exportação poderá começar a falhar com um comportamento inesperado.

Limitações

Geral:

  • Os seguintes formatos são permitidos nas tabelas de destino: CSV, TSV, JSONe Parquet.
  • A exportação contínua não foi concebida para trabalhar em vistas materializadas, uma vez que uma vista materializada pode ser atualizada, enquanto os dados exportados para armazenamento são sempre anexados apenas e nunca atualizados.
  • Não é possível criar a exportação contínua em bases de dados de seguidores , uma vez que as bases de dados de seguidores são só de leitura e a exportação contínua requer operações de escrita.
  • Os registos na tabela de origem têm de ser ingeridos diretamente na tabela, utilizando uma política de atualização ou ingeridos a partir de comandos de consulta. Se os registos forem movidos para a tabela com extensões .move ou utilizando a tabela .rename, a exportação contínua poderá não processar estes registos. Veja as limitações descritas na página Cursors da Base de Dados .
  • Se os artefactos utilizados pela exportação contínua se destinarem a acionar notificações do Event Grid, veja a secção problemas conhecidos na documentação do Event Grid.

Entre bases de dados e entre clusters:

  • A exportação contínua não suporta chamadas entre clusters.
  • A exportação contínua suporta chamadas entre bases de dados apenas para tabelas de dimensão. Todas as tabelas de factos têm de residir na base de dados local. Veja mais detalhes em Exportar de tabelas de factos e dimensões.
  • Se a exportação contínua incluir chamadas entre bases de dados, tem de ser configurada com uma identidade gerida.

Políticas:

Conteúdo relacionado