ListAzureBlobStorage_v12 2025.10.9.21¶
Bundle¶
org.apache.nifi | nifi-azure-nar
Description¶
Établit la liste des blobs dans un conteneur de stockage Azure Blob. Les détails du listing sont joints à un FlowFile à utiliser avec FetchAzureBlobStorage. Ce processeur est conçu pour fonctionner uniquement sur le nœud principal d’un cluster. Si le nœud principal change, le nouveau nœud principal reprendra là où le précédent s’est arrêté sans dupliquer toutes les données. Le processeur utilise la bibliothèque cliente de stockage Azure Blob v12.
Exigences en matière d’entrées¶
FORBIDDEN
Prend en charge les propriétés dynamiques sensibles¶
false
Propriétés¶
Propriété |
Description |
|---|---|
Préfixe de nom Blob |
Préfixe de recherche pour le listing |
Nom du conteneur |
Nom du conteneur de stockage Azure. Dans le cas d’un processeur PutAzureBlobStorage, le conteneur peut être créé s’il n’existe pas. |
Cible de l’annonce initiale du suivi des entités |
Spécifiez comment la liste initiale doit être gérée. Utilisé par la stratégie « Suivi des entités ». |
Cache d’états de suivi des entités |
Les entités répertoriées sont stockées dans le cache spécifié afin que le processeur puisse reprendre la liste après un redémarrage NiFi ou en cas de changement de nœud principal. La stratégie « Suivi des entités » nécessite le suivi des informations de toutes les entités répertoriées au cours de la dernière « fenêtre de suivi ». Pour prendre en charge un grand nombre d’entités, la stratégie utilise DistributedMapCache au lieu d’un état géré. Le format de la clé de cache est “ListedEntities::{processorId}(::{nodeId})”. Si elle suit les entités répertoriées par nœud, la partie facultative “::{nodeId}” est ajoutée pour gérer l’état séparément. Par exemple : clé de cache à l’échelle du cluster =”ListedEntities::8dda2321-0164-1000-50fa-3042fe7d6a7b”, per node cache key =”ListedEntities::8dda2321-0164-1000-50fa-3042fe7d6a7b::nifi-node3” Le contenu du cache stocké est une chaîne JSON au format Gzip. La clé de cache sera supprimée lorsque la configuration de la liste cible est modifiée. Utilisé par la stratégie « Suivi des entités ». |
Fenêtre de temps du suivi des entités |
Indiquez pendant combien de temps ce processeur doit suivre les entités déjà répertoriées. La stratégie « Suivi des entités » peut sélectionner n’importe quelle entité dont l’horodatage se situe dans la fenêtre temporelle spécifiée. Par exemple, si le paramètre est réglé sur « 30 minutes », toute entité ayant un horodatage au cours des 30 dernières minutes sera la cible de la liste lorsque ce processeur s’exécutera. Une entité répertoriée est considérée comme « nouvelle/mise à jour » et un FlowFile est émis si l’une des conditions suivantes est remplie : 1. n’existe pas dans les entités déjà répertoriées, 2. a un horodatage plus récent que l’entité mise en cache, 3. a une taille différente de l’entité mise en cache. Si l’horodatage d’une entité mise en cache devient plus ancien que la fenêtre temporelle spécifiée, cette entité sera supprimée des entités déjà répertoriées en cache. Utilisé par la stratégie de « Suivi des entités ». |
Stratégie de listing |
Précisez comment déterminer les entités nouvelles/mises à jour. Voir les descriptions de chaque stratégie pour plus de détails. |
Âge maximum du fichier |
L’âge maximum d’un fichier pour qu’il puisse être extrait ; tout fichier plus ancien que cette durée (en fonction de la date de la dernière modification) sera ignoré |
Taille maximale du fichier |
Taille maximale d’un fichier pour qu’il puisse être extrait |
Âge minimum du fichier |
L’âge minimum qu’un fichier doit avoir pour être extrait ; tout fichier plus jeune que cette durée (en fonction de la date de la dernière modification) sera ignoré |
Taille minimale du fichier |
La taille minimale que doit avoir un fichier pour être extrait |
Créateur d’enregistrement |
Spécifie le Record Writer à utiliser pour créer le listing. Si vous ne le précisez pas, un FlowFile sera créé pour chaque entité inscrite sur la liste. Si le Record Writer est spécifié, toutes les entités seront écrites sur un seul FlowFile au lieu d’ajouter des attributs à des FlowFiles individuels. |
identifiants de connexion au stockage |
Controller Service utilisé pour obtenir les identifiants du stockage Azure Blob. |
service proxy-configuration |
Spécifie le Controller Service de configuration proxy pour les requêtes réseau proxy. Dans le cas de SOCKS, il n’est pas garanti que la version SOCKS sélectionnée sera utilisée par le processeur. |
Gestion de l’État¶
Champs d’application |
Description |
|---|---|
CLUSTER |
Après avoir établi une liste de blobs, l’horodatage du blob le plus récent est enregistré si la stratégie de listing « Horodatages de suivi » est utilisée (par défaut). Cela permet au processeur de ne répertorier que des blobs qui ont été ajoutés ou modifiés après cette date lors de la prochaine exécution du processeur. L’état est stocké dans le clustering afin que ce processeur puisse être exécuté sur le nœud principal uniquement et que, si un nouveau nœud principal est sélectionné, le nouveau nœud puisse reprendre là où le précédent s’est arrêté, sans dupliquer les données. |
Relations¶
Nom |
Description |
|---|---|
success |
Tous les FlowFiles reçus sont routés vers le succès |
Écrit les attributs¶
Nom |
Description |
|---|---|
azure.container |
Le nom du conteneur de stockage Azure Blob |
azure.blobname |
Le nom du blob sur le stockage Azure Blob |
azure.primaryUri |
Emplacement principal du blob |
azure.etag |
ETag du blob |
azure.blobtype |
Type du blob (BlockBlob, PageBlob ou AppendBlob) |
mime.type |
Type MIME du contenu |
lang |
Code langue du contenu |
azure.timestamp |
Horodatage du blob |
azure.length |
Longueur du blob |