| title | description | author | manager | ms.reviewer | ms.service | ms.workload | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|---|---|---|
Copy data to or from Azure Blob storage by using Data Factory | Microsoft Docs |
Learn how to copy data from supported source data stores to Azure Blob storage, or from Blob storage to supported sink data stores, by using Data Factory. |
linda33wj |
craigg |
douglasl |
data-factory |
data-services |
conceptual |
11/08/2018 |
jingwang |
[!div class="op_single_selector" title1="Select the version of Data Factory service you are using:"]
This article outlines how to use Copy Activity in Azure Data Factory to copy data to and from Azure Blob storage. It builds on the Copy Activity overview article that presents a general overview of Copy Activity.
To learn about Azure Data Factory, read the introductory article.
You can copy data from any supported source data store to Blob storage. You also can copy data from Blob storage to any supported sink data store. For a list of data stores that are supported as sources or sinks by the copy activity, see the Supported data stores table.
Specifically, this Blob storage connector supports:
- Copying blobs to and from general-purpose Azure storage accounts and hot/cool blob storage.
- Copying blobs by using account key, service shared access signature, service principal or managed identities for Azure resources authentications.
- Copying blobs from block, append, or page blobs and copying data to only block blobs.
- Copying blobs as is or parsing or generating blobs with supported file formats and compression codecs.
Note
If you enables "Allow trusted Microsoft services to access this storage account" option on Azure Storage firewall settings, using Azure Integration Runtime to connect to Blob storage will fail with forbidden error, as ADF are not treated as trusted Microsoft service. Please use Self-hosted Integration Runtime as connect via instead.
[!INCLUDE data-factory-v2-connector-get-started]
The following sections provide details about properties that are used to define Data Factory entities specific to Blob storage.
Azure Blob connector support the following authentication types, refer to the corresponding section on details:
- Account key authentication
- Shared access signature authentication
- Service principal authentication
- Managed identities for Azure resources authentication
Note
HDInsights, Azure Machine Learning and Azure SQL Data Warehouse PolyBase load only support Azure Blob storage account key authentication.
To use storage account key authentication, the following properties are supported:
| Property | Description | Required |
|---|---|---|
| type | The type property must be set to AzureBlobStorage (suggested) or AzureStorage (see notes below). | Yes |
| connectionString | Specify the information needed to connect to Storage for the connectionString property. Mark this field as a SecureString to store it securely in Data Factory, or reference a secret stored in Azure Key Vault. | Yes |
| connectVia | The integration runtime to be used to connect to the data store. You can use Azure Integration Runtime or Self-hosted Integration Runtime (if your data store is in a private network). If not specified, it uses the default Azure Integration Runtime. | No |
Note
If you were using "AzureStorage" type linked service, it is still supported as-is, while you are suggested to use this new "AzureBlobStorage" linked service type going forward.
Example:
{
"name": "AzureBlobStorageLinkedService",
"properties": {
"type": "AzureBlobStorage",
"typeProperties": {
"connectionString": {
"type": "SecureString",
"value": "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}A shared access signature provides delegated access to resources in your storage account. You can use a shared access signature to grant a client limited permissions to objects in your storage account for a specified time. You don't have to share your account access keys. The shared access signature is a URI that encompasses in its query parameters all the information necessary for authenticated access to a storage resource. To access storage resources with the shared access signature, the client only needs to pass in the shared access signature to the appropriate constructor or method. For more information about shared access signatures, see Shared access signatures: Understand the shared access signature model.
Note
- Data Factory now supports both service shared access signatures and account shared access signatures. For more information about these two types and how to construct them, see Types of shared access signatures.
- In later dataset configuration, the folder path is the absolute path starting from container level. You need to configure one aligned with the path in your SAS URI.
Tip
To generate a service shared access signature for your storage account, you can execute the following PowerShell commands. Replace the placeholders and grant the needed permission.
$context = New-AzureStorageContext -StorageAccountName <accountName> -StorageAccountKey <accountKey>
New-AzureStorageContainerSASToken -Name <containerName> -Context $context -Permission rwdl -StartTime <startTime> -ExpiryTime <endTime> -FullUri
To use shared access signature authentication, the following properties are supported:
| Property | Description | Required |
|---|---|---|
| type | The type property must be set to AzureBlobStorage (suggested) or AzureStorage (see notes below). | Yes |
| sasUri | Specify the shared access signature URI to the Storage resources, such as blob, container, or table. Mark this field as a SecureString to store it securely in Data Factory, or reference a secret stored in Azure Key Vault. | Yes |
| connectVia | The integration runtime to be used to connect to the data store. You can use the Azure Integration Runtime or the Self-hosted Integration Runtime (if your data store is located in a private network). If not specified, it uses the default Azure Integration Runtime. | No |
Note
If you were using "AzureStorage" type linked service, it is still supported as-is, while you are suggested to use this new "AzureBlobStorage" linked service type going forward.
Example:
{
"name": "AzureBlobStorageLinkedService",
"properties": {
"type": "AzureBlobStorage",
"typeProperties": {
"sasUri": {
"type": "SecureString",
"value": "<SAS URI of the Azure Storage resource>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}When you create a shared access signature URI, consider the following points:
- Set appropriate read/write permissions on objects based on how the linked service (read, write, read/write) is used in your data factory.
- Set Expiry time appropriately. Make sure that the access to Storage objects doesn't expire within the active period of the pipeline.
- The URI should be created at the right container/blob or table level based on the need. A shared access signature URI to a blob allows Data Factory to access that particular blob. A shared access signature URI to an Blob storage container allows Data Factory to iterate through blobs in that container. To provide access to more or fewer objects later, or to update the shared access signature URI, remember to update the linked service with the new URI.
For Azure Storage service principal authentication in general, refer to Authenticate access to Azure Storage using Azure Active Directory.
To use service principal authentication, follow these steps:
-
Register an application entity in Azure Active Directory (Azure AD) by following Register your application with an Azure AD tenant. Make note of the following values, which you use to define the linked service:
- Application ID
- Application key
- Tenant ID
-
Grant the service principal proper permission in Azure Blob storage. Refer to Manage access rights to Azure Storage data with RBAC with more details on the roles.
- As source, in Access control (IAM), grant at least Storage Blob Data Reader role.
- As sink, in Access control (IAM), grant at least Storage Blob Data Contributor role.
These properties are supported for an Azure Blob storage linked service:
| Property | Description | Required |
|---|---|---|
| type | The type property must be set to AzureBlobStorage. | Yes |
| serviceEndpoint | Specify the Azure Blob storage service endpoint with the pattern of https://<accountName>.blob.core.windows.net/. |
Yes |
| servicePrincipalId | Specify the application's client ID. | Yes |
| servicePrincipalKey | Specify the application's key. Mark this field as a SecureString to store it securely in Data Factory, or reference a secret stored in Azure Key Vault. | Yes |
| tenant | Specify the tenant information (domain name or tenant ID) under which your application resides. Retrieve it by hovering the mouse in the top-right corner of the Azure portal. | Yes |
| connectVia | The integration runtime to be used to connect to the data store. You can use Azure Integration Runtime or Self-hosted Integration Runtime (if your data store is in a private network). If not specified, it uses the default Azure Integration Runtime. | No |
Note
Service principal authentication is only supported by "AzureBlobStorage" type linked service but not previous "AzureStorage" type linked service.
Example:
{
"name": "AzureBlobStorageLinkedService",
"properties": {
"type": "AzureBlobStorage",
"typeProperties": {
"serviceEndpoint": "https://<accountName>.blob.core.windows.net/",
"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"
}
}
}A data factory can be associated with a managed identity for Azure resources, which represents this specific data factory. You can directly use this service identity for Blob storage authentication similar to using your own service principal. It allows this designated factory to access and copy data from/to your Blob storage.
For Azure Storage MSI authentication in general, refer to Authenticate access to Azure Storage using Azure Active Directory.
To use managed identities for Azure resources authentication, follow these steps:
-
Retrieve data factory service identity by copying the value of "SERVICE IDENTITY APPLICATION ID" generated along with your factory.
-
Grant the managed identity proper permission in Azure Blob storage. Refer to Manage access rights to Azure Storage data with RBAC with more details on the roles.
- As source, in Access control (IAM), grant at least Storage Blob Data Reader role.
- As sink, in Access control (IAM), grant at least Storage Blob Data Contributor role.
These properties are supported for an Azure Blob storage linked service:
| Property | Description | Required |
|---|---|---|
| type | The type property must be set to AzureBlobStorage. | Yes |
| serviceEndpoint | Specify the Azure Blob storage service endpoint with the pattern of https://<accountName>.blob.core.windows.net/. |
Yes |
| connectVia | The integration runtime to be used to connect to the data store. You can use Azure Integration Runtime or Self-hosted Integration Runtime (if your data store is in a private network). If not specified, it uses the default Azure Integration Runtime. | No |
Note
Managed identities for Azure resources authentication is only supported by "AzureBlobStorage" type linked service but not previous "AzureStorage" type linked service.
Example:
{
"name": "AzureBlobStorageLinkedService",
"properties": {
"type": "AzureBlobStorage",
"typeProperties": {
"serviceEndpoint": "https://<accountName>.blob.core.windows.net/"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}For a full list of sections and properties available for defining datasets, see the Datasets article. This section provides a list of properties supported by the Blob storage dataset.
To copy data to and from Blob storage, set the type property of the dataset to AzureBlob. The following properties are supported.
| Property | Description | Required |
|---|---|---|
| type | The type property of the dataset must be set to AzureBlob. | Yes |
| folderPath | Path to the container and folder in the blob storage. Wildcard filter is not supported. An example is myblobcontainer/myblobfolder/. | Yes for Copy/Lookup activity, No for GetMetadata activity |
| fileName | Name or wildcard filter for the blob(s) under the specified "folderPath". If you don't specify a value for this property, the dataset points to all blobs in the folder. For filter, allowed wildcards are: * (matches zero or more characters) and ? (matches zero or single character).- Example 1: "fileName": "*.csv"- Example 2: "fileName": "???20180427.txt"Use ^ to escape if your actual file name has wildcard or this escape char inside.When fileName isn't specified for an output dataset and preserveHierarchy isn't specified in the activity sink, the copy activity automatically generates the blob name with the following pattern: "Data.[activity run id GUID].[GUID if FlattenHierarchy].[format if configured].[compression if configured]". An example is "Data.0a405f8a-93ff-4c6f-b3be-f69616f1df7a.txt.gz". |
No |
| format | If you want to copy files as is between file-based stores (binary copy), skip the format section in both the input and output dataset definitions. If you want to parse or generate files with a specific format, the following file format types are supported: TextFormat, JsonFormat, AvroFormat, OrcFormat, and ParquetFormat. Set the type property under format to one of these values. For more information, see the Text format, JSON format, Avro format, Orc format, and Parquet format sections. |
No (only for binary copy scenario) |
| compression | Specify the type and level of compression for the data. For more information, see Supported file formats and compression codecs. Supported types are GZip, Deflate, BZip2, and ZipDeflate. Supported levels are Optimal and Fastest. |
No |
Tip
To copy all blobs under a folder, specify folderPath only.
To copy a single blob with a given name, specify folderPath with folder part and fileName with file name.
To copy a subset of blobs under a folder, specify folderPath with folder part and fileName with wildcard filter.
Example:
{
"name": "AzureBlobDataset",
"properties": {
"type": "AzureBlob",
"linkedServiceName": {
"referenceName": "<Azure Blob storage linked service name>",
"type": "LinkedServiceReference"
},
"typeProperties": {
"folderPath": "mycontainer/myfolder",
"fileName": "myfile.csv.gz",
"format": {
"type": "TextFormat",
"columnDelimiter": ",",
"rowDelimiter": "\n"
},
"compression": {
"type": "GZip",
"level": "Optimal"
}
}
}
}For a full list of sections and properties available for defining activities, see the Pipelines article. This section provides a list of properties supported by the Blob storage source and sink.
To copy data from Blob storage, set the source type in the copy activity to BlobSource. The following properties are supported in the copy activity source section.
| Property | Description | Required |
|---|---|---|
| type | The type property of the copy activity source must be set to BlobSource. | Yes |
| recursive | Indicates whether the data is read recursively from the subfolders or only from the specified folder. Note that when recursive is set to true and the sink is a file-based store, an empty folder or subfolder isn't copied or created at the sink. Allowed values are true (default) and false. |
No |
Example:
"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>"
}
}
}
]To copy data to Blob storage, set the sink type in the copy activity to BlobSink. The following properties are supported in the sink section.
| Property | Description | Required |
|---|---|---|
| type | The type property of the copy activity sink must be set to BlobSink. | Yes |
| copyBehavior | Defines the copy behavior when the source is files from a file-based data store. Allowed values are: - PreserveHierarchy (default): Preserves the file hierarchy in the target folder. The relative path of source file to source folder is identical to the relative path of target file to target folder. - FlattenHierarchy: All files from the source folder are in the first level of the target folder. The target files have autogenerated names. - MergeFiles: Merges all files from the source folder to one file. If the file or blob name is specified, the merged file name is the specified name. Otherwise, it's an autogenerated file name. |
No |
Example:
"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"
}
}
}
]This section describes the resulting behavior of the Copy operation for different combinations of recursive and copyBehavior values.
| recursive | copyBehavior | Source folder structure | Resulting target |
|---|---|---|---|
| true | preserveHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
The target folder Folder1 is created with the same structure as the source: Folder1 File1 File2 Subfolder1 File3 File4 File5 |
| true | flattenHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
The target Folder1 is created with the following structure: Folder1 autogenerated name for File1 autogenerated name for File2 autogenerated name for File3 autogenerated name for File4 autogenerated name for File5 |
| true | mergeFiles | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
The target Folder1 is created with the following structure: Folder1 File1 + File2 + File3 + File4 + File5 contents are merged into one file with an autogenerated file name. |
| false | preserveHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
The target folder Folder1 is created with the following structure: Folder1 File1 File2 Subfolder1 with File3, File4, and File5 is not picked up. |
| false | flattenHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
The target folder Folder1 is created with the following structure: Folder1 autogenerated name for File1 autogenerated name for File2 Subfolder1 with File3, File4, and File5 is not picked up. |
| false | mergeFiles | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
The target folder Folder1 is created with the following structure Folder1 File1 + File2 contents are merged into one file with an autogenerated file name. autogenerated name for File1 Subfolder1 with File3, File4, and File5 is not picked up. |
For a list of data stores supported as sources and sinks by the copy activity in Data Factory, see Supported data stores.