Criar tabela
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
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.
after_processing_move_container
- String.
SELECT no motor de tabela AzureQueue
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:
- Use o motor para criar uma tabela para consumir do caminho especificado no Azure Blob Storage e considere-a um fluxo de dados.
- Crie uma tabela com a estrutura desejada.
- Crie uma visão materializada que converta os dados do motor e os insira em uma tabela criada anteriormente.
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.
Introspecção
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:
- Use
system.azure_queue_metadata_cachepara o estado em memória da fila em versões do servidor >= 25.1. Em versões anteriores, usesystem.s3queue_metadata_cache(ele também conterá informações para tabelasazure). - Use a tabela
system.azure_queue_metadatapara inspecionar diretamente o estado armazenado no Keeper: o número de nósprocessed,processingefailedpor objeto de metadados e, sob demanda, seus conteúdos. Esta é a equivalenteAzureQueuedesystem.s3_queue_metadata. - Ative
system.azure_queue_logpor meio da configuração principal do ClickHouse, por exemplo.
system.s3queue_metadata_cache, mas para arquivos processados e arquivos com falha.
A tabela tem a seguinte estrutura:
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.