Skip to main content
Este motor oferece integração com o ecossistema do Azure Blob Storage, permitindo importar dados em streaming.

Criar tabela

Parâmetros do motor Os parâmetros de AzureQueue são os mesmos compatíveis com o motor de tabela AzureBlobStorage. Consulte a seção de parâmetros aqui. Assim como no motor de tabela AzureBlobStorage, os usuários podem usar o emulador Azurite para desenvolvimento local com o Azure Storage. Mais detalhes aqui. Exemplo

Configurações

O conjunto de configurações compatíveis é praticamente o mesmo do motor de tabela S3Queue, mas sem o prefixo s3queue_. Consulte a lista completa de configurações. Para obter a lista de configurações definidas para a tabela, use a tabela system.azure_queue_settings. Disponível a partir da versão 24.10. Abaixo estão as configurações compatíveis apenas com o AzureQueue e não aplicáveis ao S3Queue.

after_processing_move_connection_string

String de conexão do Azure Blob Storage para a qual os arquivos processados com sucesso serão movidos, caso o destino seja outro contêiner do Azure. Valores possíveis:
  • String.
Valor padrão: string vazia.

after_processing_move_container

Nome do contêiner para o qual os arquivos processados com sucesso serão movidos, caso o destino seja outro contêiner do Azure. Valores possíveis:
  • String.
Valor padrão: string vazia. Exemplo:

SELECT no motor de tabela AzureQueue

Consultas SELECT são proibidas por padrão em tabelas AzureQueue. Isso segue o padrão comum de fila, em que os dados são lidos uma vez e depois removidos da fila. O SELECT é proibido para evitar perda acidental de dados. No entanto, às vezes isso pode ser útil. Para isso, você precisa definir a configuração stream_like_engine_allow_direct_select como True. O motor AzureQueue tem uma configuração especial para consultas SELECT: commit_on_select. Defina-a como False para preservar os dados na fila após a leitura, ou True para removê-los.

Descrição

SELECT não é particularmente útil para importação em streaming (exceto para depuração), porque cada arquivo pode ser importado apenas uma vez. É mais prático criar fluxos em tempo real usando visões materializadas. Para fazer isso:
  1. Use o motor para criar uma tabela para consumir do caminho especificado no Azure Blob Storage e considere-a um fluxo de dados.
  2. Crie uma tabela com a estrutura desejada.
  3. Crie uma visão materializada que converta os dados do motor e os insira em uma tabela criada anteriormente.
Quando a MATERIALIZED VIEW é vinculada ao motor, ela começa a coletar dados em segundo plano. Os argumentos do motor têm a forma AzureQueue(connection_string, container_name, blobpath, format[, compression]). Exemplo:

Colunas virtuais

  • _path — Caminho do arquivo.
  • _file — Nome do arquivo.
Para mais informações sobre colunas virtuais, veja aqui.

Introspecção

Ative o logging da tabela usando a configuração de tabela enable_logging_to_queue_log=1. Os recursos de introspecção são os mesmos do motor de tabela S3Queue, com algumas diferenças específicas:
  1. Use system.azure_queue_metadata_cache para o estado em memória da fila em versões do servidor >= 25.1. Em versões anteriores, use system.s3queue_metadata_cache (ele também conterá informações para tabelas azure).
  2. Use a tabela system.azure_queue_metadata para inspecionar diretamente o estado armazenado no Keeper: o número de nós processed, processing e failed por objeto de metadados e, sob demanda, seus conteúdos. Esta é a equivalente AzureQueue de system.s3_queue_metadata.
  3. Ative system.azure_queue_log por meio da configuração principal do ClickHouse, por exemplo.
Esta tabela persistente contém as mesmas informações que system.s3queue_metadata_cache, mas para arquivos processados e arquivos com falha. A tabela tem a seguinte estrutura:
Exemplo:

Limitações

AzureQueue compartilha a mesma implementação do S3Queue e tem as mesmas limitações. Em particular, uma perda de energia no nível do dispositivo do nó do ClickHouse pode causar a perda silenciosa de linhas consumidas: um arquivo é registrado como processado no Keeper (e, com after_processing = 'delete', seu blob de origem é removido) assim que o insert termina, mas as linhas inseridas só se tornam duráveis quando a part de destino é sincronizada com fsync, o que, por padrão, não ocorre de forma síncrona (fsync_after_insert = 0). Para o caminho de consumo recomendado por meio de visão materializada, definir fsync_after_insert = 1 (e fsync_part_directory = 1) na tabela MergeTree de destino reduz substancialmente essa janela.
Última modificação em 14 de agosto de 2026