Copy and transform data in Azure Blob storage by using Azure Data Factory

• 08/05/2020
• 29 minutes to read
• • 
  • 
  • 
  • 
  • 
  • +15

APPLIES TO: Azure Data Factory Azure Synapse Analytics (Preview)

This article outlines how to use the Copy activity in Azure Data Factory to copy data from and to Azure Blob storage. It also describes how to use the Data Flow activity to transform data in Azure Blob storage. To learn about Azure Data Factory, read the introductory article.

Supported capabilities

This Azure Blob storage connector is supported for the following activities:

• Copy activity with supported source/sink matrix
• Mapping data flow
• Lookup activity
• GetMetadata activity
• Delete activity

For the Copy activity, this Blob storage connector supports:

• Copying blobs to and from general-purpose Azure storage accounts and hot/cool blob storage.
• Copying blobs by using an account key, a service shared access signature (SAS), a service principal, or managed identities for Azure resource 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.
• Preserving file metadata during copy.

Get started

To perform the Copy activity with a pipeline, you can use one of the following tools or SDKs:

• The Copy Data tool
• The Azure portal
• The .NET SDK
• The Python SDK
• Azure PowerShell
• The REST API
• The Azure Resource Manager template

The following sections provide details about properties that are used to define Data Factory entities specific to Blob storage.

Linked service properties

This Blob storage connector supports the following authentication types. See the corresponding sections for details.

• Account key authentication
• Shared access signature authentication
• Service principal authentication
• Managed identities for Azure resource authentication

Account key authentication

Data Factory supports the following properties for storage account key authentication:

Example:

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

Example: store the account key in 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"
        }            
    }
}

Shared access signature authentication

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.

Data Factory supports the following properties for using shared access signature authentication:

Example:

{
    "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>&amp;st=<start time>&amp;se=<expire time>&amp;sr=<resource>&amp;sp=<permissions>&amp;sip=<ip range>&amp;spr=<protocol>&amp;sig=<signature>>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Example: store the account key in 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>" 
            }
        },
        "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 or blob 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 a 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.

Service principal authentication

For general information about Azure Storage service principal authentication, see Authenticate access to Azure Storage using Azure Active Directory.

To use service principal authentication, follow these steps:

1. Register an application entity in Azure Active Directory (Azure AD) by following Register your application with an Azure AD tenant. Make note of these values, which you use to define the linked service:

   • Application ID
   • Application key
   • Tenant ID

2. Grant the service principal proper permission in Azure Blob storage. For more information on the roles, see Manage access rights to Azure Storage data with RBAC.

   • As source, in Access control (IAM), grant at least the Storage Blob Data Reader role.
   • As sink, in Access control (IAM), grant at least the Storage Blob Data Contributor role.

These properties are supported for an Azure Blob storage 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"
        }
    }
}

Managed identities for Azure resource authentication

A data factory can be associated with a managed identity for Azure resources, which represents this specific data factory. You can directly use this managed identity for Blob storage authentication, which is similar to using your own service principal. It allows this designated factory to access and copy data from or to Blob storage.

For general information about Azure Storage authentication, see Authenticate access to Azure Storage using Azure Active Directory. To use managed identities for Azure resource authentication, follow these steps:

1. Retrieve Data Factory managed identity information by copying the value of the managed identity object ID generated along with your factory.

2. Grant the managed identity permission in Azure Blob storage. For more information on the roles, see Manage access rights to Azure Storage data with RBAC.

   • As source, in Access control (IAM), grant at least the Storage Blob Data Reader role.
   • As sink, in Access control (IAM), grant at least the Storage Blob Data Contributor role.

These properties are supported for an Azure Blob storage linked service:

Example:

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

Dataset properties

For a full list of sections and properties available for defining datasets, see the Datasets article.

Azure Data Factory supports the following file formats. Refer to each article for format-based settings.

• Avro format
• Binary format
• Delimited text format
• Excel format
• JSON format
• ORC format
• Parquet format
• XML format

The following properties are supported for Azure Blob storage under location settings in a format-based dataset:

Example:

{
    "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"
        }
    }
}

Copy activity properties

For a full list of sections and properties available for defining activities, see the Pipelines article. This section provides a list of properties that the Blob storage source and sink support.

Blob storage as a source type

Azure Data Factory supports the following file formats. Refer to each article for format-based settings.

• Avro format
• Binary format
• Delimited text format
• Excel format
• JSON format
• ORC format
• Parquet format
• XML format

The following properties are supported for Azure Blob storage under storeSettings settings in a format-based copy source:

Example:

"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>"
            }
        }
    }
]

Blob storage as a sink type

Azure Data Factory supports the following file formats. Refer to each article for format-based settings.

• Avro format
• Binary format
• Delimited text format
• Excel format
• JSON format
• ORC format
• Parquet format
• XML format

The following properties are supported for Azure Blob storage under storeSettings settings in a format-based copy sink:

Example:

"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"
                }
            }
        }
    }
]

Folder and file filter examples

This section describes the resulting behavior of the folder path and file name with wildcard filters.

File list examples

This section describes the resulting behavior of using a file list path in the Copy activity source.

Assume that you have the following source folder structure and want to copy the files in bold:

Some recursive and copyBehavior examples

This section describes the resulting behavior of the Copy operation for different combinations of recursive and copyBehavior values.

Preserving metadata during copy

When you copy files from Amazon S3, Azure Blob storage, or Azure Data Lake Storage Gen2 to Azure Data Lake Storage Gen2 or Azure Blob storage, you can choose to preserve the file metadata along with data. Learn more from Preserve metadata.

Mapping data flow properties

When you're transforming data in mapping data flows, you can read and write files from Azure Blob storage in the following formats:

• Avro
• Delimited text
• Delta
• Excel
• JSON
• Parquet

Format specific settings are located in the documentation for that format. For more information, see Source transformation in mapping data flow and Sink transformation in mapping data flow.

Source transformation

In source transformation, you can read from a container, folder, or individual file in Azure Blob storage. Use the Source options tab to manage how the files are read.

Wildcard paths: Using a wildcard pattern will instruct Data Factory to loop through each matching folder and file in a single source transformation. This is an effective way to process multiple files within a single flow. Add multiple wildcard matching patterns with the plus sign that appears when you hover over your existing wildcard pattern.

From your source container, choose a series of files that match a pattern. Only a container can be specified in the dataset. Your wildcard path must therefore also include your folder path from the root folder.

Wildcard examples:

• * Represents any set of characters.

• ** Represents recursive directory nesting.

• ? Replaces one character.

• [] Matches one or more characters in the brackets.

• /data/sales/**/*.csv Gets all .csv files under /data/sales.

• /data/sales/20??/**/ Gets all files in the 20th century.

• /data/sales/*/*/*.csv Gets .csv files two levels under /data/sales.

• /data/sales/2004/*/12/[XY]1?.csv Gets all .csv files in December 2004 starting with X or Y prefixed by a two-digit number.

Partition root path: If you have partitioned folders in your file source with a key=value format (for example, year=2019), then you can assign the top level of that partition folder tree to a column name in your data flow's data stream.

First, set a wildcard to include all paths that are the partitioned folders plus the leaf files that you want to read.

Use the Partition root path setting to define what the top level of the folder structure is. When you view the contents of your data via a data preview, you'll see that Data Factory will add the resolved partitions found in each of your folder levels.

List of files: This is a file set. Create a text file that includes a list of relative path files to process. Point to this text file.

Column to store file name: Store the name of the source file in a column in your data. Enter a new column name here to store the file name string.

After completion: Choose to do nothing with the source file after the data flow runs, delete the source file, or move the source file. The paths for the move are relative.

To move source files to another location post-processing, first select "Move" for file operation. Then, set the "from" directory. If you're not using any wildcards for your path, then the "from" setting will be the same folder as your source folder.

If you have a source path with wildcard, your syntax will look like this:

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

You can specify "from" as:

/data/sales

And you can specify "to" as:

/backup/priorSales

In this case, all files that were sourced under /data/sales are moved to /backup/priorSales.

Filter by last modified: You can filter which files you process by specifying a date range of when they were last modified. All datetimes are in UTC.

Sink properties

In the sink transformation, you can write to either a container or a folder in Azure Blob storage. Use the Settings tab to manage how the files get written.

Clear the folder: Determines whether or not the destination folder gets cleared before the data is written.

File name option: Determines how the destination files are named in the destination folder. The file name options are:

• Default: Allow Spark to name files based on PART defaults.
• Pattern: Enter a pattern that enumerates your output files per partition. For example, loans[n].csv will create loans1.csv, loans2.csv, and so on.
• Per partition: Enter one file name per partition.
• As data in column: Set the output file to the value of a column. The path is relative to the dataset container, not the destination folder. If you have a folder path in your dataset, it will be overridden.
• Output to a single file: Combine the partitioned output files into a single named file. The path is relative to the dataset folder. Be aware that the merge operation can possibly fail based on node size. We don't recommend this option for large datasets.

Quote all: Determines whether to enclose all values in quotation marks.

Lookup activity properties

To learn details about the properties, check Lookup activity.

GetMetadata activity properties

To learn details about the properties, check GetMetadata activity.

Delete activity properties

To learn details about the properties, check Delete activity.

Legacy models

Legacy dataset model

Example:

{
    "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"
            }
        }
    }
}

Legacy source model for the Copy activity

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>"
            }
        }
    }
]

Legacy sink model for the Copy activity

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"
            }
        }
    }
]

Next steps

For a list of data stores that the Copy activity in Data Factory supports as sources and sinks, see Supported data stores.