Créer une table
AzureQueue sont les mêmes que ceux pris en charge par le moteur de table AzureBlobStorage. Consultez la section des paramètres ici.
Comme avec le moteur de table AzureBlobStorage, les utilisateurs peuvent utiliser l’émulateur Azurite pour le développement local avec Azure Storage. Pour plus de détails, cliquez ici.
Exemple
Paramètres
S3Queue, mais sans le préfixe s3queue_. Voir la liste complète des paramètres.
Pour obtenir la liste des paramètres configurés pour la table, utilisez la table system.azure_queue_settings. Disponible à partir de 24.10.
Vous trouverez ci-dessous les paramètres compatibles uniquement avec AzureQueue et non applicables à S3Queue.
after_processing_move_connection_string
- String.
after_processing_move_container
- String.
SELECT à partir du moteur de table AzureQueue
stream_like_engine_allow_direct_select sur True.
Le moteur AzureQueue dispose d’un paramètre spécial pour les requêtes SELECT : commit_on_select. Définissez-le sur False pour conserver les données dans la file d’attente après leur lecture, ou sur True pour les supprimer.
Description
SELECT n’est pas particulièrement utile pour l’importation en continu (sauf pour le débogage), car chaque fichier ne peut être importé qu’une seule fois. Il est plus pratique de mettre en place un traitement en temps réel à l’aide de vues matérialisées. Pour ce faire :
- Utilisez le moteur pour créer une table qui lit depuis le chemin spécifié dans Azure Blob Storage et traitez-la comme un flux de données.
- Créez une table avec la structure souhaitée.
- Créez une vue matérialisée qui convertit les données du moteur et les insère dans une table créée précédemment.
MATERIALIZED VIEW est associée au moteur, elle commence à collecter les données en arrière-plan.
Les arguments du moteur ont la forme AzureQueue(connection_string, container_name, blobpath, format[, compression]).
Exemple :
Colonnes virtuelles
_path— Chemin d’accès au fichier._file— Nom du fichier.
Introspection
enable_logging_to_queue_log=1.
Les capacités d’introspection sont les mêmes que pour le moteur de table S3Queue, avec toutefois quelques différences notables :
- Utilisez
system.azure_queue_metadata_cachepour l’état en mémoire de la file d’attente pour les versions du serveur >= 25.1. Pour les versions antérieures, utilisezsystem.s3queue_metadata_cache(il contiendrait également des informations sur les tablesazure). - Utilisez la table
system.azure_queue_metadatapour inspecter directement l’état stocké dans Keeper : le nombre de nœudsprocessed,processingetfailedpar objet de métadonnées et, à la demande, leur contenu. Il s’agit de l’équivalentAzureQueuedesystem.s3_queue_metadata. - Activez
system.azure_queue_logvia la configuration principale de ClickHouse, par exemple.
system.s3queue_metadata_cache, mais pour les fichiers traités et ceux ayant échoué.
La table a la structure suivante :
Limitations
AzureQueue partage la même implémentation que S3Queue et présente les mêmes limitations. En particulier, une coupure d’alimentation au niveau matériel du nœud ClickHouse peut entraîner la perte silencieuse de lignes consommées : un fichier est enregistré comme traité dans Keeper (et, avec after_processing = 'delete', son blob source est supprimé) dès la fin de l’insert, mais les lignes insérées ne sont durablement écrites qu’une fois la part cible synchronisée avec fsync, ce qui ne se produit pas de manière synchrone par défaut (fsync_after_insert = 0). Pour le chemin de consommation recommandé via une vue matérialisée, définir fsync_after_insert = 1 (et fsync_part_directory = 1) sur la table MergeTree cible réduit considérablement cette fenêtre.