Copier et transformer des données dans Stockage Blob Azure à l’aide d’Azure Data Factory ou d’Azure Synapse Analytics

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Cet article décrit comment utiliser l’activité de copie dans des pipelines Azure Data Factory et Azure Synapse pour copier des données depuis et vers Stockage Blob Azure. Il explique également comment utiliser l’activité Data Flow pour transformer des données en Stockage Blob Azure. Pour en savoir plus, lisez les articles d’introduction d’Azure Data Factory et d’Azure Synapse Analytics.

Conseil

Pour découvrir un scénario de migration de lac de données ou d’entrepôt de données, consultez l’article Migrer des données depuis votre lac de données ou entrepôt de données vers Azure.

Fonctionnalités prises en charge

Ce connecteur Stockage Blob Azure est pris en charge pour les fonctionnalités suivantes :

Fonctionnalités prises en charge IR Point de terminaison privé managé
Activité de copie (source/récepteur) ✓ Exclure le compte de stockage V1
Mappage de flux de données (source/récepteur) 0 ✓ Exclure le compte de stockage V1
Activité de recherche ✓ Exclure le compte de stockage V1
Activité GetMetadata ✓ Exclure le compte de stockage V1
Supprimer l’activité ✓ Exclure le compte de stockage V1

① runtime d’intégration Azure ② runtime d’intégration auto-hébergé

Pour l’activité Copy, ce connecteur de stockage d’objets blob prend en charge les opérations suivantes :

  • La copie d’objets blob vers et depuis des comptes de stockage Azure à usage général et un stockage d’objets blob à chaud ou à froid.
  • Copie d’objets blob à l’aide d’une clé de compte, d’une signature d’accès partagé (SAP) de service ou d’identités managées pour des authentifications de ressources Azure.
  • La copie d’objets blob à partir d’objets blob de blocs, d’ajout ou de page, et la copie de données uniquement vers des objets blob de blocs.
  • Copie d’objets blob en l’état, ou analyse/génération d’objets blob avec des formats de fichier et codecs de compression pris en charge.
  • Conservation des métadonnées de fichier lors de la copie.

Bien démarrer

Pour effectuer l’activité Copie avec un pipeline, vous pouvez vous servir de l’un des outils ou kits SDK suivants :

Créer un service lié Stockage Blob Azure à l’aide de l’interface utilisateur

Utilisez les étapes suivantes pour créer un service lié Stockage Blob Azure dans l’interface utilisateur du portail Azure.

  1. Accédez à l’onglet Gérer dans votre espace de travail Azure Data Factory ou Synapse, sélectionnez Services liés, puis sélectionnez Nouveau :

  2. Recherchez « blob », puis sélectionnez le connecteur Stockage Blob Azure.

    Select Azure Blob Storage connector.

  3. Configurez les informations du service, testez la connexion et créez le nouveau service lié.

    Screenshot of configuration for Azure Blob Storage linked service.

Informations de configuration des connecteurs

Les sections suivantes fournissent des informations détaillées sur les propriétés utilisées pour définir les entités de pipeline Data Factory et Synapse spécifiques au stockage Blob.

Propriétés du service lié

Ce connecteur de stockage d’objets blob prend en charge les types d’authentification suivants. Pour plus d’informations, consultez les sections correspondantes.

Notes

  • Si vous utilisez le runtime d’intégration Azure public pour vous connecter à votre Stockage Blob avec l’option Autoriser les services Microsoft approuvés à accéder à ce compte de stockage activée sur le pare-feu Stockage Azure, vous devez recourir à l’authentification par identité managée. Pour plus d’informations sur les paramètres du pare-feu de stockage Azure, consultez Configurer des pare-feu et des réseaux virtuels dans Stockage Azure.
  • Si vous utilisez PolyBase ou l’instruction COPY pour charger des données dans Azure Synapse Analytics et que votre Stockage Blob source ou de préproduction est configuré avec un point de terminaison de réseau virtuel Azure, vous devez utiliser l’authentification par identité managée comme l’exige Azure Synapse. Pour en savoir plus sur la configuration requise, consultez la section sur Authentification par identité managée.

Notes

Les activités Azure HDInsight et Azure Machine Learning prennent en charge uniquement l’authentification utilisant des clés de compte de Stockage Blob Azure.

Authentification anonyme

Les propriétés suivantes sont prises en charge pour l’authentification par clé de compte de stockage dans les pipelines Azure Data Factory ou Synapse :

Propriété Description Obligatoire
type La propriété type doit être définie sur AzureBlobStorage (recommandé) ou AzureStorage (voir les remarques ci-dessous). Oui
containerUri Spécifier l’URI du conteneur de blobs Azure qui a activé l’accès en lecture anonyme en prenant ce format https://<AccountName>.blob.core.windows.net/<ContainerName> et Configurer l’accès en lecture public anonyme pour les conteneurs et les blobs Oui
connectVia Le runtime d’intégration à utiliser pour se connecter à la banque de données. Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé (si votre banque de données se trouve sur un réseau privé). Si cette propriété n’est pas spécifiée, le service utilise le runtime d’intégration Azure par défaut. Non

Exemple :


{
    "name": "AzureBlobStorageAnonymous",
    "properties": {
        "annotations": [],
        "type": "AzureBlobStorage",
        "typeProperties": {
            "containerUri": "https:// <accountname>.blob.core.windows.net/ <containername>",
            "authenticationType": "Anonymous"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Exemples d’interface utilisateur :

L’expérience d’interface utilisateur est décrite dans l’image suivante. Cet exemple utilise le jeu de données ouvert Azure comme source. Si vous souhaitez obtenir le jeu de données bing_covid-19_data.csv ouvert, il vous suffit de choisir le Type d’authentificationAnonyme et de remplir l’URI de conteneur avec https://pandemicdatalake.blob.core.windows.net/public.

Screenshot of configuration for Anonymous examples UI.

Authentification par clé de compte

Les propriétés suivantes sont prises en charge pour l’authentification par clé de compte de stockage dans les pipelines Azure Data Factory ou Synapse :

Propriété Description Obligatoire
type La propriété type doit être définie sur AzureBlobStorage (recommandé) ou AzureStorage (voir les remarques ci-dessous). Oui
connectionString Pour vous connecter au Stockage, pour la propriété connectionString, spécifiez les informations requises.
Vous pouvez également définir une clé de compte dans Azure Key Vault et extraire la configuration accountKey de la chaîne de connexion. Pour plus d’informations, consultez les exemples suivants et l’article Stocker les informations d’identification dans Azure Key Vault.
Oui
connectVia Le runtime d’intégration à utiliser pour se connecter à la banque de données. Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé (si votre banque de données se trouve sur un réseau privé). Si cette propriété n’est pas spécifiée, le service utilise le runtime d’intégration Azure par défaut. Non

Remarque

Un point de terminaison de service BLOB secondaire n’est pas pris en charge lors de l’utilisation de l’authentification par clé de compte. Vous pouvez utiliser d’autres types d’authentification.

Notes

Si vous utilisez le service lié de type AzureStorage, il est toujours pris en charge tel quel. Toutefois, nous vous suggérons d’utiliser désormais le nouveau type de service lié AzureBlobStorage.

Exemple :

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {
          "connectionString": "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
        },
        "connectVia": {
          "referenceName": "<name of Integration Runtime>",
          "type": "IntegrationRuntimeReference"
        }
    }
}

Exemple : stockage de la clé de compte dans Azure Key Vault

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {
            "connectionString": "DefaultEndpointsProtocol=https;AccountName=<accountname>;",
            "accountKey": {
                "type": "AzureKeyVaultSecret",
                "store": {
                    "referenceName": "<Azure Key Vault linked service name>",
                    "type": "LinkedServiceReference"
                },
                "secretName": "<secretName>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Authentification avec une signature d’accès partagé

Une signature d'accès partagé fournit un accès délégué aux ressources de votre compte de stockage. Vous pouvez utiliser une signature d’accès partagé pour octroyer à un client des autorisations d’accès limité à des objets de votre compte de stockage pendant une période donnée.

Vous n’êtes pas obligé de partager vos clés d’accès de compte. La signature d’accès partagé est un URI qui englobe dans ses paramètres de requête toutes les informations nécessaires pour obtenir un accès authentifié à une ressource de stockage. Pour accéder aux ressources de stockage avec la signature d’accès partagé, il suffit au client de transmettre cette dernière à la méthode ou au constructeur approprié.

Pour plus d’informations sur les signatures d’accès partagé, consultez Signatures d’accès partagé : Comprendre le modèle de signature d’accès partagé.

Notes

  • Le service prend désormais en charge les signatures d’accès partagé de service et les signatures d’accès partagé de compte. Pour plus d’informations sur les signatures d’accès partagé, consultez Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé.
  • Dans les configurations de jeu de données ultérieures, le chemin du dossier est le chemin absolu commençant au niveau du conteneur. Vous devez en configurer un qui soit aligné avec le chemin dans votre URI SAS.

Les propriétés suivantes sont prises en charge pour l’utilisation de l’authentification par signature d’accès partagé :

Propriété Description Obligatoire
type La propriété type doit être définie sur AzureBlobStorage (recommandé) ou AzureStorage (voir la remarque ci-dessous). Oui
sasUri Spécifiez l’URI de signature d’accès partagé des ressources de stockage, telles qu’un objet blob ou un conteneur.
Marquez ce champ comme SecureString pour le stocker en toute sécurité. Vous pouvez également placer le jeton SAP dans Azure Key Vault pour utiliser la rotation automatique et supprimer la portion jeton. Pour plus d’informations, consultez les exemples suivants et Stocker des informations d’identification dans Azure Key Vault.
Oui
connectVia Le runtime d’intégration à utiliser pour se connecter à la banque de données. Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé (si votre banque de données se trouve sur un réseau privé). Si cette propriété n’est pas spécifiée, le service utilise le runtime d’intégration Azure par défaut. Non

Notes

Si vous utilisez le service lié de type AzureStorage, il est toujours pris en charge tel quel. Toutefois, nous vous suggérons d’utiliser désormais le nouveau type de service lié AzureBlobStorage.

Exemple :

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {
            "sasUri": {
                "type": "SecureString",
                "value": "<SAS URI of the Azure Storage resource e.g. https://<accountname>.blob.core.windows.net/?sv=<storage version>&st=<start time>&se=<expire time>&sr=<resource>&sp=<permissions>&sip=<ip range>&spr=<protocol>&sig=<signature>>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Exemple : stockage de la clé de compte dans Azure Key Vault

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {
            "sasUri": {
                "type": "SecureString",
                "value": "<SAS URI of the Azure Storage resource without token e.g. https://<accountname>.blob.core.windows.net/>"
            },
            "sasToken": {
                "type": "AzureKeyVaultSecret",
                "store": {
                    "referenceName": "<Azure Key Vault linked service name>", 
                    "type": "LinkedServiceReference"
                },
                "secretName": "<secretName with value of SAS token e.g. ?sv=<storage version>&st=<start time>&se=<expire time>&sr=<resource>&sp=<permissions>&sip=<ip range>&spr=<protocol>&sig=<signature>>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Lorsque vous créez un URI de signature d’accès partagé, prenez en compte les points suivants :

  • Définissez des autorisations de lecture/écriture appropriées sur les objets en fonction de l’utilisation du service lié (lecture, écriture, lecture/écriture).
  • Définissez le paramètre Heure d’expiration correctement. Assurez-vous que l’accès aux objets du stockage n’expire pas pendant la période active du pipeline.
  • L’URI doit être créé au niveau du blob ou du conteneur appropriés en fonction des besoins. Un URI de signature d’accès partagé vers un objet blob permet à la fabrique de données ou au pipeline Synapse d’accéder à cet objet blob spécifique. Un URI de signature d’accès partagé vers un conteneur de stockage Blob permet à la fabrique de données d’itérer via des objets blob dans ce conteneur. Pour fournir l’accès à plus ou moins d’objets ultérieurement ou mettre à jour l’URI de signature d’accès partagé, rappelez-vous de mettre à jour le service lié avec le nouvel URI.

Authentification d’un principal du service

Pour des informations générales sur l’authentification du principal de service du Stockage Azure, consultez Authentifier l’accès au Stockage Azure à l’aide de Microsoft Entra ID.

Pour l’authentification de principal de service, effectuez les étapes suivantes :

  1. Inscrire une application à l’aide de la plateforme d’identités Microsoft. Pour savoir comment, regardez Démarrage rapide : Inscrire une application à l’aide de la plateforme d’identités Microsoft. Prenez note des valeurs suivantes qui vous permettent de définir le service lié :

    • ID de l'application
    • Clé de l'application
    • ID client
  2. Accordez l’autorisation appropriée au principal de service dans Stockage Blob Azure. Pour plus d’informations sur les rôles, consultez Utiliser le portail Azure afin d’attribuer un rôle Azure pour l’accès aux données de blob et de file d’attente.

    • En tant que source, dans Contrôle d’accès (IAM) , accordez au moins le rôle Lecteur des données blob du stockage.
    • En tant que récepteur, dans Contrôle d’accès (IAM) , accordez au moins le rôle Contributeur aux données Blob du stockage.

Les propriétés prises en charge pour un service lié de Stockage Blob Azure sont les suivantes :

Propriété Description Obligatoire
type La propriété type doit être définie sur AzureBlobStorage. Oui
serviceEndpoint Spécifiez le point de terminaison du service Stockage Blob Azure à l’aide du modèle suivant : https://<accountName>.blob.core.windows.net/. Oui
accountKind Spécifiez le type de votre compte de stockage. Les valeurs autorisées sont les suivantes : Stockage (v1 à usage général), StorageV2 (v2 à usage général), BlobStorageou BlockBlobStorage.

Lorsque le service lié Blob Azure est utilisé dans un flux de données, l’authentification par identité managée ou par principal de service n’est pas prise en charge si le type de compte est vide ou « Stockage ». Spécifiez le type de compte approprié, choisissez une autre authentification ou mettez à niveau votre compte de stockage vers la version v2 à usage général.
Non
servicePrincipalId Spécifiez l’ID client de l’application. Oui
servicePrincipalCredentialType Type d’informations d’identification à utiliser pour l’authentification de principal du service. Les valeurs autorisées sont ServicePrincipalKey et ServicePrincipalCert. Oui
servicePrincipalCredential Informations d’identification du principal du service.
Quand vous utilisez ServicePrincipalKey comme type d’informations d’identification, spécifiez la clé de l’application. Marquez ce champ en tant que SecureString afin de le stocker en toute sécurité, ou référencez un secret stocké dans Azure Key Vault.
Lorsque vous utilisez ServicePrincipalCert comme informations d’identification, référencez un certificat dans Azure Key Vault et vérifiez que le type de contenu du certificat est PKCS #12.
Oui
tenant Spécifiez les informations de locataire (nom de domaine ou ID de locataire) dans lesquels se trouve votre application. Récupérez-les en pointant dans l’angle supérieur droit du portail Azure. Oui
azureCloudType Pour l’authentification du principal de service, spécifiez le type d’environnement cloud Azure auquel votre application Microsoft Entra est inscrite.
Les valeurs autorisées sont AzurePublic, AzureChina, AzureUsGovernment et AzureGermany. Par défaut, l’environnement cloud du pipeline de fabrique de données ou Synapse est utilisé.
Non
connectVia Le runtime d’intégration à utiliser pour se connecter à la banque de données. Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé (si votre banque de données se trouve sur un réseau privé). Si cette propriété n’est pas spécifiée, le service utilise le runtime d’intégration Azure par défaut. Non

Remarque

  • Si votre compte d’objet blob active la suppression réversible, l’authentification de principal du service n’est pas prise en charge dans Data Flow.
  • Si vous accédez au stockage d’objets blob via un point de terminaison privé à l’aide de Data Flow, notez que lorsque l’authentification du principal de service est utilisée, Data Flow se connecte au point de terminaison ADLS Gen2 au lieu du point de terminaison Blob. Veillez à créer le point de terminaison privé correspondant dans votre fabrique de données ou votre espace de travail Synapse pour activer l’accès.

Notes

L’authentification du principal du service n’est prise en charge que par le service lié de type « AzureBlobStorage », non par le service lié de type « AzureStorage » précédent.

Exemple :

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {            
            "serviceEndpoint": "https://<accountName>.blob.core.windows.net/",
            "accountKind": "StorageV2",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalKey": {
                "type": "SecureString",
                "value": "<service principal key>"
            },
            "tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>" 
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Authentification d’identité managée affectée par le système

Une fabrique de données ou un pipeline de Synapse peut être associé à une identité managée attribuée par le système pour les ressources Azure, qui représente cette ressource pour l’authentification auprès d’autres services Azure. Vous pouvez utiliser directement cette identité managée attribuée par le système pour l’authentification de stockage d’objets blob, ce qui revient à utiliser votre propre principal de service. Cela permet à la ressource désignée d’accéder aux données et de les copier à partir de votre stockage d’objets blob. Pour en savoir plus sur les identités managées pour les ressources Azure, consultez Identités managées pour les ressources Azure

Pour des informations générales sur l’authentification de Stockage Azure, consultez Authentifier l’accès au Stockage Azure à l’aide de Microsoft Entra ID. Pour utiliser des identités managées afin d’authentifier des ressources Azure, procédez comme suit :

  1. Récupérez les informations d’identité managée affectée par le système en copiant la valeur de l’ID d’objet d’identité managée attribué par le système générée en même temps que votre fabrique ou espace de travail Synapse.

  2. Accordez l’autorisation d’identité managée dans Stockage Blob Azure. Pour plus d’informations sur les rôles, consultez Utiliser le portail Azure afin d’attribuer un rôle Azure pour l’accès aux données de blob et de file d’attente.

    • En tant que source, dans Contrôle d’accès (IAM) , accordez au moins le rôle Lecteur des données blob du stockage.
    • En tant que récepteur, dans Contrôle d’accès (IAM) , accordez au moins le rôle Contributeur aux données Blob du stockage.

Les propriétés prises en charge pour un service lié de Stockage Blob Azure sont les suivantes :

Propriété Description Obligatoire
type La propriété type doit être définie sur AzureBlobStorage. Oui
serviceEndpoint Spécifiez le point de terminaison du service Stockage Blob Azure à l’aide du modèle suivant : https://<accountName>.blob.core.windows.net/. Oui
accountKind Spécifiez le type de votre compte de stockage. Les valeurs autorisées sont les suivantes : Stockage (v1 à usage général), StorageV2 (v2 à usage général), BlobStorageou BlockBlobStorage.

Lorsque le service lié Blob Azure est utilisé dans un flux de données, l’authentification par identité managée ou par principal de service n’est pas prise en charge si le type de compte est vide ou « Stockage ». Spécifiez le type de compte approprié, choisissez une autre authentification ou mettez à niveau votre compte de stockage vers la version v2 à usage général.
Non
connectVia Le runtime d’intégration à utiliser pour se connecter à la banque de données. Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé (si votre banque de données se trouve sur un réseau privé). Si cette propriété n’est pas spécifiée, le service utilise le runtime d’intégration Azure par défaut. Non

Exemple :

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {            
            "serviceEndpoint": "https://<accountName>.blob.core.windows.net/",
            "accountKind": "StorageV2" 
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Authentification d’identité managée affectée par l’utilisateur

Une fabrique de données peut être affectée à une ou plusieurs identités managées par l’utilisateur. Vous pouvez utiliser cette identité managée affectée par l’utilisateur pour l’authentification du stockage Blob, qui permet d’accéder aux données et de les copier depuis ou vers Stockage Blob. Pour en savoir plus sur les identités managées pour les ressources Azure, consultez Identités managées pour les ressources Azure

Pour des informations générales sur l’authentification de Stockage Azure, consultez Authentifier l’accès au Stockage Azure à l’aide de Microsoft Entra ID. Pour utiliser l’authentification par identité managée affectée par l’utilisateur, effectuez les étapes suivantes :

  1. Créez une ou plusieurs identités managées affectées par l’utilisateur et accordez une autorisation dans Stockage Blob Azure. Pour plus d’informations sur les rôles, consultez Utiliser le portail Azure afin d’attribuer un rôle Azure pour l’accès aux données de blob et de file d’attente.

    • En tant que source, dans Contrôle d’accès (IAM) , accordez au moins le rôle Lecteur des données blob du stockage.
    • En tant que récepteur, dans Contrôle d’accès (IAM) , accordez au moins le rôle Contributeur aux données Blob du stockage.
  2. Attribuez une ou plusieurs identités managées affectées par l’utilisateur à votre fabrique de données et créez des informations d’identification pour chaque identité managée affectée par l’utilisateur.

Les propriétés prises en charge pour un service lié de Stockage Blob Azure sont les suivantes :

Propriété Description Obligatoire
type La propriété type doit être définie sur AzureBlobStorage. Oui
serviceEndpoint Spécifiez le point de terminaison du service Stockage Blob Azure à l’aide du modèle suivant : https://<accountName>.blob.core.windows.net/. Oui
accountKind Spécifiez le type de votre compte de stockage. Les valeurs autorisées sont les suivantes : Stockage (v1 à usage général), StorageV2 (v2 à usage général), BlobStorageou BlockBlobStorage.

Lorsque le service lié Blob Azure est utilisé dans un flux de données, l’authentification par identité managée ou par principal de service n’est pas prise en charge si le type de compte est vide ou « Stockage ». Spécifiez le type de compte approprié, choisissez une autre authentification ou mettez à niveau votre compte de stockage vers la version v2 à usage général.
Non
credentials Spécifiez l’identité managée affectée par l’utilisateur en tant qu’objet d’informations d’identification. Oui
connectVia Le runtime d’intégration à utiliser pour se connecter à la banque de données. Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé (si votre banque de données se trouve sur un réseau privé). Si cette propriété n’est pas spécifiée, le service utilise le runtime d’intégration Azure par défaut. Non

Exemple :

{
    "name": "AzureBlobStorageLinkedService",
    "properties": {
        "type": "AzureBlobStorage",
        "typeProperties": {            
            "serviceEndpoint": "https://<accountName>.blob.core.windows.net/",
            "accountKind": "StorageV2",
            "credential": {
                "referenceName": "credential1",
                "type": "CredentialReference"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Important

Si vous utilisez PolyBase ou l’instruction COPY pour charger des données du Stockage Blob (comme source ou emplacement de préproduction) dans Azure Synapse Analytics et que vous avez recours à l’authentification par identité managée pour le Stockage Blob, veillez également à suivre les étapes 1 à 3 de cette aide. Ces étapes inscrivent votre serveur auprès de Microsoft Entra ID et attribuent le rôle de contributeur aux données de l’objet blob de stockage. Data Factory gère le reste. Si vous configurez le Stockage blob avec un point de terminaison de réseau virtuel Azure, vous devez également activer Autoriser les services Microsoft approuvés à accéder à ce compte de stockage dans le menu des paramètres Pare-feu et réseaux virtuels du compte Stockage Azure, comme l’exige Azure Synapse.

Remarque

  • Si votre compte d’objet blob active la suppression réversible, l’authentification d’identité managée affectée par le système/affectée par l’utilisateur n’est pas prise en charge dans Data Flow.
  • Si vous accédez au stockage d’objets blob via un point de terminaison privé à l’aide de Data Flow, notez que lorsque l’authentification d’identité managée attribuée par le système/attribuée par l’utilisateur est utilisée, Data Flow se connecte au point de terminaison ADLS Gen2 au lieu du point de terminaison Blob. Veillez à créer le point de terminaison privé correspondant dans ADF pour activer l’accès.

Notes

L’authentification d’identité managée attribuée par le système/attribuée par l’utilisateur n’est prise en charge que par le service lié de type « AzureBlobStorage », non par le service lié de type « AzureStorage » précédent.

Propriétés du jeu de données

Pour obtenir la liste complète des sections et propriétés disponibles pour la définition de jeux de données, consultez l’article Jeux de données.

Azure Data Factory prend en charge les formats de fichier suivants. Reportez-vous à chaque article pour les paramètres basés sur le format.

Les propriétés suivantes sont prises en charge pour Stockage Blob Azure sous les paramètres location dans un jeu de données basé sur un format :

Propriété Description Obligatoire
type La propriété type de l’emplacement dans le jeu de données doit être définie sur AzureBlobStorageLocation. Oui
conteneur Le conteneur d’objets blob. Oui
folderPath Chemin d’accès au dossier sous le conteneur donné. Si vous souhaitez utiliser un caractère générique pour filtrer le dossier, ignorez ce paramètre et spécifiez-le dans les paramètres de la source de l’activité. Non
fileName Le nom de fichier sous le conteneur et le chemin d’accès du dossier donnés. Si vous souhaitez utiliser un caractère générique pour filtrer les fichiers, ignorez ce paramètre et spécifiez cela dans les paramètres de la source de l’activité. Non

Exemple :

{
    "name": "DelimitedTextDataset",
    "properties": {
        "type": "DelimitedText",
        "linkedServiceName": {
            "referenceName": "<Azure Blob Storage linked service name>",
            "type": "LinkedServiceReference"
        },
        "schema": [ < physical schema, optional, auto retrieved during authoring > ],
        "typeProperties": {
            "location": {
                "type": "AzureBlobStorageLocation",
                "container": "containername",
                "folderPath": "folder/subfolder"
            },
            "columnDelimiter": ",",
            "quoteChar": "\"",
            "firstRowAsHeader": true,
            "compressionCodec": "gzip"
        }
    }
}

Propriétés de l’activité de copie

Pour obtenir la liste complète des sections et des propriétés disponibles pour la définition des activités, consultez l’article Pipelines. Cette section fournit la liste des propriétés que la source et le récepteur du stockage d’objets blob prennent en charge.

Stockage Blob en tant que type de source

Azure Data Factory prend en charge les formats de fichier suivants. Reportez-vous à chaque article pour les paramètres basés sur le format.

Les propriétés suivantes sont prises en charge pour Stockage Blob Azure sous les paramètres storeSettings dans une source de copie basée sur un format :

Propriété Description Obligatoire
type La propriété type sous storeSettings doit être définie sur AzureBlobStorageReadSettings. Oui
Recherchez les fichiers à copier :
OPTION 1 : chemin d’accès statique
Copie à partir du conteneur donné ou du chemin d’accès au dossier/fichier spécifié dans le jeu de données. Si vous souhaitez copier tous les blobs d’un conteneur ou d’un dossier, spécifiez en plus wildcardFileName comme *.
OPTION 2 : préfixe blob
- prefix
Préfixe du nom d’objet blob sous le conteneur donné configuré dans un jeu de données pour filtrer les objets blob sources. Les blobs dont le nom commence par container_in_dataset/this_prefix sont sélectionnés. Il utilise le filtre côté service pour le stockage d’objets blob, qui offre de meilleures performances qu’un filtre de caractères génériques.

Lorsque vous utilisez le préfixe et que vous choisissez de copier le récepteur basé sur un fichier avec conservation de la hiérarchie, notez que le sous-chemin après le dernier signe « / » dans le préfixe est conservé. Par exemple, si vous avez la source container/folder/subfolder/file.txt et que vous configurez le préfixe sous la forme folder/sub, le chemin du fichier conservé est subfolder/file.txt.
Non
OPTION 3 : caractère générique
- wildcardFolderPath
Chemin d’accès du dossier avec des caractères génériques sous le conteneur donné configuré dans un jeu de données pour filtrer les dossiers sources.
Les caractères génériques autorisés sont les suivants : * (correspond à zéro caractère ou plusieurs) et ? (correspond à zéro ou un caractère). Utilisez ^ comme caractère d’échappement si le nom de votre dossier contient des caractères génériques ou ce caractère d’échappement.
Consultez d’autres exemples dans les exemples de filtre de dossier et de fichier.
Non
OPTION 3 : caractère générique
- wildcardFileName
Nom de fichier avec caractères génériques sous le conteneur donné et chemin d’accès du dossier (ou chemin d’accès du dossier en caractères génériques) pour filtrer les fichiers sources.
Les caractères génériques autorisés sont les suivants : * (correspond à zéro caractère ou plusieurs) et ? (correspond à zéro ou un caractère). Utilisez ^ comme caractère d’échappement si le nom de votre fichier contient un caractère générique ou ce caractère d’échappement. Consultez d’autres exemples dans les exemples de filtre de dossier et de fichier.
Oui
OPTION 4 : liste de fichiers
- fileListPath
Indique de copier un ensemble de fichiers donné. Pointez vers un fichier texte contenant la liste des fichiers que vous voulez copier, un fichier par ligne indiquant le chemin d’accès relatif configuré dans le jeu de données.
Lorsque vous utilisez cette option, ne spécifiez pas de nom de fichier dans le jeu de données. Pour plus d’exemples, consultez Exemples de listes de fichiers.
Non
Paramètres supplémentaires :
recursive Indique si les données sont lues de manière récursive à partir des sous-dossiers ou uniquement du dossier spécifié. Notez que lorsque l’option recursive est définie sur true et que le récepteur est un magasin basé sur un fichier, un dossier ou un sous-dossier vide n’est pas copié ou créé sur le récepteur.
Les valeurs autorisées sont true (par défaut) et false.
Cette propriété ne s’applique pas lorsque vous configurez fileListPath.
Non
deleteFilesAfterCompletion Indique si les fichiers binaires seront supprimés du magasin source après leur déplacement vers le magasin de destination. La suppression des fichiers se fait par fichier, Par conséquent, lorsque l’activité de copie échoue, vous pouvez constater que certains fichiers ont déjà été copiés vers la destination et supprimés de la source, tandis que d’autres restent dans le magasin source.
Cette propriété est valide uniquement dans un scénario de copie de fichiers binaires. La valeur par défaut est false.
Non
modifiedDatetimeStart Les fichiers sont filtrés en fonction de l’attribut de dernière modification.
Les fichiers sont sélectionnés si l’heure de leur dernière modification est postérieure ou égale à modifiedDatetimeStart et antérieure à modifiedDatetimeEnd. L’heure est appliquée à un fuseau horaire UTC au format « 2018-12-01T05:00:00Z ».
Les propriétés peuvent avoir la valeur NULL, ce qui a pour effet qu’aucun filtre d’attribut de fichier n’est appliqué au jeu de données. Quand modifiedDatetimeStart a une valeur de DateHeure, mais que la valeur de modifiedDatetimeEnd est NULL, les fichiers dont l’attribut de dernière modification a une valeur supérieure ou égale à la valeur de DateHeure sont sélectionnés. Quand modifiedDatetimeEnd a une valeur de DateHeure, mais que la valeur de modifiedDatetimeStart est NULL, les fichiers dont l’attribut de dernière modification a une valeur inférieure à la valeur de DateHeure sont sélectionnés.
Cette propriété ne s’applique pas lorsque vous configurez fileListPath.
Non
modifiedDatetimeEnd Procédure identique aux propriétés précédentes. Non
enablePartitionDiscovery Pour les fichiers partitionnés, spécifiez s’il faut analyser les partitions à partir du chemin d’accès au fichier et les ajouter en tant que colonnes sources supplémentaires.
Les valeurs autorisées sont false (par défaut) et true.
Non
partitionRootPath Lorsque la découverte de partition est activée, spécifiez le chemin d’accès racine absolu pour pouvoir lire les dossiers partitionnés en tant que colonnes de données.

S’il n’est pas spécifié, par défaut,
– Quand vous utilisez le chemin d’accès du fichier dans le jeu de données ou la liste des fichiers sur la source, le chemin racine de la partition est le chemin d’accès configuré dans le jeu de données.
– Quand vous utilisez le filtre de dossiers de caractères génériques, le chemin d’accès racine de la partition est le sous-chemin d’accès avant le premier caractère générique.
– Quand vous utilisez le préfixe, le chemin d’accès racine de la partition est le sous-chemin d’accès avant le dernier « / ».

Par exemple, en supposant que vous configurez le chemin d’accès dans le jeu de données en tant que « root/folder/year=2020/month=08/day=27 » :
– Si vous spécifiez le chemin d’accès racine de la partition en tant que « root/folder/year=2020 », l’activité de copie génère deux colonnes supplémentaires, month et day, ayant respectivement la valeur « 08 » et « 27 », en plus des colonnes contenues dans les fichiers.
– Si le chemin racine de la partition n’est pas spécifié, aucune colonne supplémentaire n’est générée.
Non
maxConcurrentConnections La limite supérieure de connexions simultanées établies au magasin de données pendant l’exécution de l’activité. Spécifiez une valeur uniquement lorsque vous souhaitez limiter les connexions simultanées. Non

Notes

Pour les formats Parquet et de texte délimité, le type BlobSource pour la source de l’activité Copy mentionnée dans la section suivante est toujours pris en charge à des fins de compatibilité descendante. Nous vous suggérons d’utiliser le nouveau modèle jusqu’à ce que l’interface utilisateur de création ait basculé vers la génération de ces nouveaux types.

Exemple :

"activities":[
    {
        "name": "CopyFromBlob",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<Delimited text input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "DelimitedTextSource",
                "formatSettings":{
                    "type": "DelimitedTextReadSettings",
                    "skipLineCount": 10
                },
                "storeSettings":{
                    "type": "AzureBlobStorageReadSettings",
                    "recursive": true,
                    "wildcardFolderPath": "myfolder*A",
                    "wildcardFileName": "*.csv"
                }
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

Notes

Le conteneur $logs, qui est automatiquement créé au moment de l'activation de Storage Analytics pour un compte de stockage, n'apparaît pas lorsqu'une opération d'énumération des conteneurs est effectuée via l'interface utilisateur. Le chemin d'accès au fichier doit être fourni directement pour permettre à vos données de fabrique ou au pipeline Synapse de consommer les fichiers à partir du conteneur $logs.

Stockage Blob en tant que type de récepteur

Azure Data Factory prend en charge les formats de fichier suivants. Reportez-vous à chaque article pour les paramètres basés sur le format.

Les propriétés suivantes sont prises en charge pour Stockage Blob Azure sous les paramètres storeSettings dans un récepteur de copie basé sur un format :

Propriété Description Obligatoire
type La propriété type sous storeSettings doit être définie sur AzureBlobStorageWriteSettings. Oui
copyBehavior Définit le comportement de copie lorsque la source est constituée de fichiers d’une banque de données basée sur un fichier.

Les valeurs autorisées sont les suivantes :
- PreserveHierarchy (par défaut) : conserve la hiérarchie des fichiers dans le dossier cible. Le chemin relatif du fichier source vers le dossier source est identique au chemin relatif du fichier cible vers le dossier cible.
- FlattenHierarchy : tous les fichiers du dossier source figurent dans le premier niveau du dossier cible. Les noms des fichiers cibles sont générés automatiquement.
- MergeFiles : fusionne tous les fichiers du dossier source dans un seul fichier. Si le nom d’objet blob ou de fichier est spécifié, le nom de fichier fusionné est le nom spécifié. Dans le cas contraire, il s’agit d’un nom de fichier généré automatiquement.
Non
blockSizeInMB Spécifiez la taille du bloc, en Mo, qui est utilisée pour écrire des données dans des objets blobs de blocs. En savoir plus sur les objets blobs de blocs.
Les valeurs autorisées sont comprises entre 4 et 100 Mo.
Par défaut, le service détermine automatiquement la taille du bloc en fonction du type et des données de votre magasin source. Pour une copie non binaire dans un stockage d’objets blob, la taille de bloc par défaut est de 100 Mo, ce qui permet de stocker jusqu’à 4,95 To de données. Cela peut ne pas être optimal si vos données ne sont pas volumineuses, en particulier si vous utilisez le runtime d’intégration auto-hébergé avec des connexions réseau médiocres qui entraînent des problèmes de délai d’expiration d’opération ou de performances. Vous pouvez spécifier explicitement une taille de bloc, tout en veillant à ce que blockSizeInMB*50000 soit suffisamment large pour stocker les données. Dans le cas contraire, l’exécution de l’activité Copy échoue.
Non
maxConcurrentConnections La limite supérieure de connexions simultanées établies au magasin de données pendant l’exécution de l’activité. Spécifiez une valeur uniquement lorsque vous souhaitez limiter les connexions simultanées. Non
metadata Définissez des métadonnées personnalisées lors de la copie dans le récepteur. Chaque objet sous le tableau metadata représente une colonne supplémentaire. name définit le nom de clé de métadonnées et value indique la valeur des données de cette clé. Si la fonctionnalité de conservation des attributs est utilisée, les métadonnées spécifiées vont s’unir/remplacer les métadonnées du fichier source.

Les valeurs de données autorisées sont :
- $$LASTMODIFIED : une variable réservée indique de stocker l’heure de la dernière modification des fichiers sources. Appliquez à la source basée sur un fichier uniquement avec le format binaire.
- Expression
- Valeur statique
Non

Exemple :

"activities":[
    {
        "name": "CopyFromBlob",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<Parquet output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "ParquetSink",
                "storeSettings":{
                    "type": "AzureBlobStorageWriteSettings",
                    "copyBehavior": "PreserveHierarchy",
                    "metadata": [
                        {
                            "name": "testKey1",
                            "value": "value1"
                        },
                        {
                            "name": "testKey2",
                            "value": "value2"
                        },
                        {
                            "name": "lastModifiedKey",
                            "value": "$$LASTMODIFIED"
                        }
                    ]
                }
            }
        }
    }
]

Exemples de filtres de dossier et de fichier

Cette section décrit le comportement résultant de l’utilisation de filtres de caractères génériques dans les noms de fichier et les chemins de dossier.

folderPath fileName recursive Structure du dossier source et résultat du filtrage (les fichiers en gras sont récupérés)
container/Folder* (vide, utiliser la valeur par défaut) false conteneur
    DossierA
        Fichier1.csv
        File2.json
        Sousdossier1
            File3.csv
            File4.json
            File5.csv
    AutreDossierB
        Fichier6.csv
container/Folder* (vide, utiliser la valeur par défaut) true conteneur
    DossierA
        Fichier1.csv
        File2.json
        Sousdossier1
            File3.csv
            File4.json
            File5.csv
    AutreDossierB
        Fichier6.csv
container/Folder* *.csv false conteneur
    DossierA
        Fichier1.csv
        Fichier2.json
        Sousdossier1
            File3.csv
            File4.json
            File5.csv
    AutreDossierB
        Fichier6.csv
container/Folder* *.csv true conteneur
    DossierA
        Fichier1.csv
        Fichier2.json
        Sousdossier1
            File3.csv
            File4.json
            File5.csv
    AutreDossierB
        Fichier6.csv

Exemples de liste de fichiers

Cette section décrit le comportement résultant de l’utilisation d’un chemin d’accès de liste de fichiers dans la source de l’activité Copy.

Supposons que vous disposez de la structure de dossiers sources suivante et que vous souhaitez copier les fichiers en gras :

Exemple de structure source Contenu de FileListToCopy.txt Configuration
conteneur
    DossierA
        Fichier1.csv
        Fichier2.json
        Sousdossier1
            File3.csv
            File4.json
            File5.csv
    Métadonnées
        FileListToCopy.txt
File1.csv
Subfolder1/File3.csv
Subfolder1/File5.csv
Dans le jeu de données :
- Conteneur : container
- chemin d’accès du dossier : FolderA

Dans la source de l’activité Copy :
- chemin d’accès à la liste de fichiers : container/Metadata/FileListToCopy.txt

Le chemin d'accès de la liste de fichiers pointe vers un fichier texte dans le même magasin de données qui comprend une liste de fichiers que vous souhaitez copier. Il comprend un fichier par ligne, avec le chemin relatif du chemin d’accès configuré dans le jeu de données.

Quelques exemples de valeurs recursive et copyBehavior

Cette section décrit le comportement résultant de l’opération de copie pour différentes combinaisons de valeurs recursive et copyBehavior.

recursive copyBehavior Structure du dossier source Cible obtenue
true preserveHierarchy Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
Le dossier cible, Dossier1, est créé avec la même structure que la source :

Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
true flattenHierarchy Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
Le dossier cible, Dossier1, est créé avec la structure suivante :

Folder1
    nom généré automatiquement pour Fichier1
    nom généré automatiquement pour Fichier2
    nom généré automatiquement pour Fichier3
    nom généré automatiquement pour Fichier4
    nom généré automatiquement pour Fichier5
true mergeFiles Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
Le dossier cible, Dossier1, est créé avec la structure suivante :

Folder1
    Le contenu de Fichier1 + Fichier2 + Fichier3 + Fichier4 + Fichier5 est fusionné dans un fichier avec un nom de fichier généré automatiquement.
false preserveHierarchy Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
Le dossier cible, Dossier1, est créé avec la structure suivante :

Folder1
    Fichier1
    Fichier2

Sous-dossier1, où Fichier3, Fichier4 et Fichier5 ne sont pas sélectionnés.
false flattenHierarchy Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
Le dossier cible, Dossier1, est créé avec la structure suivante :

Folder1
    nom généré automatiquement pour Fichier1
    nom généré automatiquement pour Fichier2

Sous-dossier1, où Fichier3, Fichier4 et Fichier5 ne sont pas sélectionnés.
false mergeFiles Folder1
    Fichier1
    Fichier2
    Sousdossier1
        Fichier3
        Fichier4
        Fichier5
Le dossier cible, Dossier1, est créé avec la structure suivante :

Folder1
    Le contenu de Fichier1 + Fichier2 est fusionné dans un fichier avec un nom de fichier généré automatiquement. nom généré automatiquement pour Fichier1

Sous-dossier1, où Fichier3, Fichier4 et Fichier5 ne sont pas sélectionnés.

Conservation des métadonnées lors de la copie

Lorsque vous copiez des fichiers à partir d’Amazon S3, de Stockage Blob Azure ou d’Azure Data Lake Storage Gen2 vers Azure Data Lake Storage Gen2 ou Stockage Blob Azure, vous pouvez choisir de conserver les métadonnées des fichiers avec les données. Pour plus d’informations, consultez Conserver les métadonnées.

Propriétés du mappage de flux de données

Lorsque vous transformez des données en flux de données de mappage, vous pouvez lire et écrire des fichiers à partir de Stockage Blob Azure aux formats suivants :

Les paramètres spécifiques du format se trouvent dans la documentation de ce format. Pour plus d’informations, consultez Transformation de source en flux de données de mappage et Transformation de récepteur en flux de données de mappage.

Transformation de la source

Dans une transformation de source, vous pouvez lire à partir d’un conteneur, d’un dossier ou d’un fichier individuel dans Stockage Blob Azure. Utilisez l’onglet Options de la source pour gérer la façon dont les fichiers sont lus.

Screenshot of source options tab in mapping data flow source transformation.

Chemin d’accès à caractères génériques : L’utilisation d’un modèle à caractères génériques donne pour instruction au service de parcourir en boucle chaque dossier et fichier correspondant dans une même transformation de la source. Il s’agit d’un moyen efficace de traiter plusieurs fichiers dans un seul et même flux. Ajoutez plusieurs modèles de correspondance à caractères génériques avec le signe plus qui apparaît quand vous pointez sur votre modèle à caractères génériques existant.

Dans le conteneur source, choisissez une série de fichiers qui correspondent à un modèle. Seul un conteneur peut être spécifié dans le jeu de données. Votre chemin contenant des caractères génériques doit donc également inclure le chemin de votre dossier à partir du dossier racine.

Exemples de caractères génériques :

  • * Représente un jeu de caractères quelconque.

  • ** Représente une imbrication de répertoires récursifs.

  • ? Remplace un caractère.

  • [] Cherche une correspondance avec le ou les caractères entre crochets.

  • /data/sales/**/*.csv Obtient tous les fichiers .csv se trouvant sous /data/sales.

  • /data/sales/20??/**/ Obtient tous les fichiers datés du XXe siècle.

  • /data/sales/*/*/*.csv Obtient les fichiers .csv à deux niveaux sous /data/sales.

  • /data/sales/2004/*/12/[XY]1?.csv Obtient tous les fichiers .csv datés de décembre 2004, commençant par X ou Y et ayant comme préfixe un nombre à deux chiffres.

Chemin racine de la partition : si vous avez partitionné des dossiers dans votre source de fichier avec un format key=value (par exemple, year=2019), vous pouvez attribuer le niveau supérieur de cette arborescence de dossiers de partitions à un nom de colonne dans votre flux de données.

Tout d’abord, définissez un caractère générique pour inclure tous les chemins d’accès des dossiers partitionnés, ainsi que des fichiers de nœud terminal que vous souhaitez lire.

Screenshot of partition source file settings in mapping data flow source transformation.

Utilisez le paramètre Chemin racine de la partition pour définir le niveau supérieur de la structure de dossiers. Lorsque vous affichez le contenu de vos données à l’aide d’un aperçu des données, vous voyez que le service ajoute les partitions résolues trouvées dans chacun de vos niveaux de dossiers.

Partition root path

Liste de fichiers : Il s’agit d’un ensemble de fichiers. Créez un fichier texte qui inclut une liste de fichiers avec chemin relatif à traiter. Pointez sur ce fichier texte.

Colonne où stocker le nom du fichier : Stockez le nom du fichier source dans une colonne de vos données. Entrez un nouveau nom de colonne pour stocker la chaîne de nom de fichier.

Après l’exécution : après l’exécution du flux de données, choisissez de ne rien faire avec le fichier source, de le supprimer ou de le déplacer. Pour le déplacement, les chemins sont des chemins relatifs.

Pour déplacer les fichiers sources vers un autre emplacement de post-traitement, sélectionnez tout d’abord « Déplacer » comme opération de fichier. Définissez ensuite le répertoire de provenance (« from »). Si vous n’utilisez pas de caractères génériques pour votre chemin, le paramètre « from » sera le même dossier que votre dossier source.

Si vous avez un chemin d’accès source contenant un caractère générique, votre syntaxe se présente comme suit :

/data/sales/20??/**/*.csv

Vous pouvez spécifier « from » comme suit :

/data/sales

Et vous pouvez spécifier « to » comme suit :

/backup/priorSales

Dans le cas présent, tous les fichiers qui provenaient de /data/sales sont déplacés dans /backup/priorSales.

Notes

Les opérations de fichier s’exécutent uniquement quand vous démarrez le flux de données à partir d’une exécution de pipeline (débogage ou exécution) qui utilise l’activité Exécuter le flux de données dans un pipeline. Les opérations de fichiers ne s’exécutent pas en mode débogage de Data Flow.

Filtrer par date de dernière modification : vous pouvez filtrer les fichiers traités en spécifiant une plage de dates correspondant à leur dernière modification. Toutes les valeurs de DateHeure sont exprimées en temps universel coordonné (UTC).

Activer la capture des changements de données : si ce paramètre est activé, vous obtenez les fichiers nouveaux ou modifiés uniquement à partir de la dernière exécution. Vous obtiendrez toujours le chargement initial des données d’instantané complètes lors de la première exécution, suivi de la capture des fichiers modifiés uniquement lors des prochaines exécutions.

Screenshot showing Enable change data capture.

Propriétés du récepteur

Dans la transformation de récepteur, vous pouvez écrire dans un conteneur ou un dossier dans Stockage Blob Azure. L’onglet Paramètres vous permet de gérer la façon dont les fichiers sont écrits.

Sink options

Effacer le contenu du dossier : Détermine si le contenu du dossier de destination doit être effacé avant l’écriture des données.

Option de nom de fichier : Détermine la façon dont les fichiers de destination sont nommés dans le dossier de destination. Les options de nom de fichier sont les suivantes :

  • Par défaut : Autorisez Spark à nommer les fichiers en fonction des valeurs par défaut de la partition.
  • Modèle : Entrez un modèle qui énumère vos fichiers de sortie par partition. Par exemple, loans[n].csv crée loans1.csv, loans2.csv, etc.
  • Par partition : Entrez un nom de fichier pour chaque partition.
  • Comme les données de la colonne : Définissez le fichier de sortie sur la valeur d’une colonne. Le chemin est relatif au conteneur du jeu de données et non pas au dossier de destination. Si vous avez un chemin de dossier dans votre jeu de données, il est remplacé.
  • Sortie d’un seul fichier : Combinez les fichiers de sortie partitionnés en un seul fichier nommé. Le chemin est relatif au dossier du jeu de données. Sachez que cette opération de fusion peut échouer en raison de la taille du nœud. Nous ne recommandons pas cette option pour les jeux de données volumineux.

Tout mettre entre guillemets : Détermine si toutes les valeurs doivent être placées entre guillemets.

Propriétés de l’activité Lookup

Pour en savoir plus sur les propriétés, consultez Activité Lookup.

Propriétés de l’activité GetMetadata

Pour en savoir plus sur les propriétés, consultez Activité GetMetadata.

Propriétés de l’activité Delete

Pour en savoir plus sur les propriétés, consultez Activité Delete.

Modèles hérités

Notes

Les modèles suivants sont toujours pris en charge tels quels à des fins de compatibilité descendante. Nous vous suggérons d’utiliser le nouveau modèle mentionné précédemment. L’interface utilisateur de création a basculé vers la génération du nouveau modèle.

Modèle de jeu de données hérité

Propriété Description Obligatoire
type La propriété type du jeu de données doit être définie sur AzureBlob. Oui
folderPath Chemin d’accès au conteneur et au dossier dans le stockage d’objets blob.

Le filtre de caractères génériques est pris en charge pour le chemin d’accès, à l’exclusion du nom du conteneur. Les caractères génériques autorisés sont les suivants : * (correspond à zéro caractère ou plusieurs) et ? (correspond à zéro ou un caractère). Utilisez ^ comme caractère d’échappement si le nom de votre dossier contient un caractère générique ou ce caractère d’échappement.

Par exemple myblobcontainer/myblobfolder/. Consultez d’autres exemples dans les exemples de filtre de dossier et de fichier.
Oui pour l’activité Copy ou Lookup, Non pour l’activité GetMetadata
fileName Filtre de nom ou de caractères génériques pour les blobs sous la valeur folderPath spécifiée. Si vous ne spécifiez pas de valeur pour cette propriété, le jeu de données pointe vers tous les objets blob du dossier.

Pour le filtre, les caractères génériques autorisés sont les suivants : * (correspond à zéro caractère ou plus) et ? (correspond à zéro ou un caractère).
- Exemple 1 : "fileName": "*.csv"
- Exemple 2 : "fileName": "???20180427.txt"
Utilisez ^ comme caractère d’échappement si le nom de votre fichier contient un caractère générique ou ce caractère d’échappement.

Lorsque fileName n’est pas spécifié pour un jeu de données de sortie et que preserveHierarchy n’est pas spécifié dans le récepteur d’activité, l’activité Copy génère automatiquement le nom d’objet blob selon le modèle suivant : « Data.[GUID d’exécution d’activité].[GUID si FlattenHierarchy].[format si configuré].[compression si configurée] ». Par exemple : « Data.0a405f8a-93ff-4c6f-b3be-f69616f1df7a.txt.gz ».

Si vous effectuez la copie à partir d’une source tabulaire à l’aide d’un nom de tableau au lieu d’une requête, le modèle du nom est [table name].[format].[compression if configured]. Par exemple : « MyTable.csv ».
Non
modifiedDatetimeStart Les fichiers sont filtrés en fonction de l’attribut de dernière modification. Les fichiers seront sélectionnés si l’heure de leur dernière modification est supérieure ou égale à modifiedDatetimeStart et inférieure à modifiedDatetimeEnd. L’heure est appliquée au fuseau horaire UTC au format « 2018-12-01T05:00:00Z ».

N’oubliez pas que l’activation de ce paramètre affecte les performances globales du déplacement de données lorsque vous souhaitez filtrer d’énormes quantités de fichiers.

Les propriétés peuvent avoir la valeur NULL, ce qui a pour effet qu’aucun filtre d’attribut de fichier n’est appliqué au jeu de données. Quand modifiedDatetimeStart a une valeur de DateHeure, mais que la valeur de modifiedDatetimeEnd est NULL, les fichiers dont l’attribut de dernière modification a une valeur supérieure ou égale à la valeur de DateHeure sont sélectionnés. Quand modifiedDatetimeEnd a une valeur de DateHeure, mais que la valeur de modifiedDatetimeStart est NULL, les fichiers dont l’attribut de dernière modification a une valeur inférieure à la valeur de DateHeure sont sélectionnés.
Non
modifiedDatetimeEnd Les fichiers sont filtrés en fonction de l’attribut de dernière modification. Les fichiers seront sélectionnés si l’heure de leur dernière modification est supérieure ou égale à modifiedDatetimeStart et inférieure à modifiedDatetimeEnd. L’heure est appliquée au fuseau horaire UTC au format « 2018-12-01T05:00:00Z ».

N’oubliez pas que l’activation de ce paramètre affecte les performances globales du déplacement de données lorsque vous souhaitez filtrer d’énormes quantités de fichiers.

Les propriétés peuvent avoir la valeur NULL, ce qui a pour effet qu’aucun filtre d’attribut de fichier n’est appliqué au jeu de données. Quand modifiedDatetimeStart a une valeur de DateHeure, mais que la valeur de modifiedDatetimeEnd est NULL, les fichiers dont l’attribut de dernière modification a une valeur supérieure ou égale à la valeur de DateHeure sont sélectionnés. Quand modifiedDatetimeEnd a une valeur de DateHeure, mais que la valeur de modifiedDatetimeStart est NULL, les fichiers dont l’attribut de dernière modification a une valeur inférieure à la valeur de DateHeure sont sélectionnés.
Non
format Si vous souhaitez copier des fichiers en l’état entre des magasins de fichiers (copie binaire), ignorez la section Format dans les deux définitions de jeu de données d’entrée et de sortie.

Si vous souhaitez analyser ou générer des fichiers dans un format spécifique, les types de format de fichier suivants sont pris en charge : TextFormat, JsonFormat, AvroFormat, OrcFormat et ParquetFormat. Définissez la propriété type située sous Format sur l’une de ces valeurs. Pour en savoir plus, voir les sections Format Text, Format JSON, Format Avro, Format Orc et Format Parquet.
Non (uniquement pour un scénario de copie binaire)
compression Spécifiez le type et le niveau de compression pour les données. Pour plus d’informations, voir Formats de fichier et de codecs de compression pris en charge.
Les types pris en charge sont : GZip, Deflate, BZip2 et ZipDeflate.
Les niveaux pris en charge sont Optimal et Fastest.
Non

Conseil

Pour copier tous les objets blob d’un dossier, spécifiez folderPath uniquement.
Pour copier un seul objet blob avec un nom donné, spécifiez folderPath pour la partie dossier et fileName pour le nom du fichier.
Pour copier un sous-ensemble d’objets blob d’un dossier, spécifiez folderPath avec la partie dossier et fileName avec un filtre de caractères génériques.

Exemple :

{
    "name": "AzureBlobDataset",
    "properties": {
        "type": "AzureBlob",
        "linkedServiceName": {
            "referenceName": "<Azure Blob Storage linked service name>",
            "type": "LinkedServiceReference"
        },
        "typeProperties": {
            "folderPath": "mycontainer/myfolder",
            "fileName": "*",
            "modifiedDatetimeStart": "2018-12-01T05:00:00Z",
            "modifiedDatetimeEnd": "2018-12-01T06:00:00Z",
            "format": {
                "type": "TextFormat",
                "columnDelimiter": ",",
                "rowDelimiter": "\n"
            },
            "compression": {
                "type": "GZip",
                "level": "Optimal"
            }
        }
    }
}

Modèle source hérité pour l’activité Copy

Propriété Description Obligatoire
type La propriété type de la source de l’activité Copy doit être définie sur BlobSource. Oui
recursive Indique si les données sont lues de manière récursive à partir des sous-dossiers ou uniquement du dossier spécifié. Lorsque l’option recursive est définie sur true et que le récepteur est un magasin basé sur un fichier, aucun dossier ou sous-dossier vide n’est copié ou créé au niveau du récepteur.
Les valeurs autorisées sont true (par défaut) et false.
Non
maxConcurrentConnections La limite supérieure de connexions simultanées établies au magasin de données pendant l’exécution de l’activité. Spécifiez une valeur uniquement lorsque vous souhaitez limiter les connexions simultanées. Non

Exemple :

"activities":[
    {
        "name": "CopyFromBlob",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<Azure Blob input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
                "recursive": true
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

Modèle de récepteur hérité pour l’activité Copy

Propriété Description Obligatoire
type La propriété type du récepteur de l’activité Copy doit être définie sur BlobSink. Oui
copyBehavior Définit le comportement de copie lorsque la source est constituée de fichiers d’une banque de données basée sur un fichier.

Les valeurs autorisées sont les suivantes :
- PreserveHierarchy (par défaut) : conserve la hiérarchie des fichiers dans le dossier cible. Le chemin d’accès relatif du fichier source vers le dossier source est identique au chemin d’accès relatif du fichier cible vers le dossier cible.
- FlattenHierarchy : tous les fichiers du dossier source figurent dans le premier niveau du dossier cible. Les noms des fichiers cibles sont générés automatiquement.
- MergeFiles : fusionne tous les fichiers du dossier source dans un seul fichier. Si le nom d’objet blob ou de fichier est spécifié, le nom de fichier fusionné est le nom spécifié. Dans le cas contraire, il s’agit d’un nom de fichier généré automatiquement.
Non
maxConcurrentConnections La limite supérieure de connexions simultanées établies au magasin de données pendant l’exécution de l’activité. Spécifiez une valeur uniquement lorsque vous souhaitez limiter les connexions simultanées. Non

Exemple :

"activities":[
    {
        "name": "CopyToBlob",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<Azure Blob output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "BlobSink",
                "copyBehavior": "PreserveHierarchy"
            }
        }
    }
]

Capture des données modifiées

Azure Data Factory peut obtenir des fichiers nouveaux ou modifiés uniquement à partir du Stockage Blob Azure en activant l’option **Activer la capture des changements de données** dans la transformation source du flux de données de mappage. Avec cette option de connecteur, vous pouvez lire les fichiers nouveaux ou mis à jour uniquement et appliquer des transformations avant de charger les données transformées dans les jeux de données de destination de votre choix. Pour plus d’informations, consultez Capture des changements de données.

.

Pour obtenir la liste des magasins de données pris en charge par l'activité Copy en tant que sources et récepteurs, consultez Magasins de données pris en charge.