Pipelines and activities - Azure Data Factory & Azure Synapse (2024)

APPLIES TO: Azure Data Factory Azure Synapse Analytics

This article helps you understand pipelines and activities in Azure Data Factory and Azure Synapse Analytics and use them to construct end-to-end data-driven workflows for your data movement and data processing scenarios.

Overview

A Data Factory or Synapse Workspace can have one or more pipelines. A pipeline is a logical grouping of activities that together perform a task. For example, a pipeline could contain a set of activities that ingest and clean log data, and then kick off a mapping data flow to analyze the log data. The pipeline allows you to manage the activities as a set instead of each one individually. You deploy and schedule the pipeline instead of the activities independently.

The activities in a pipeline define actions to perform on your data. For example, you can use a copy activity to copy data from SQL Server to an Azure Blob Storage. Then, use a data flow activity or a Databricks Notebook activity to process and transform data from the blob storage to an Azure Synapse Analytics pool on top of which business intelligence reporting solutions are built.

Azure Data Factory and Azure Synapse Analytics have three groupings of activities: data movement activities, data transformation activities, and control activities. An activity can take zero or more input datasets and produce one or more output datasets. The following diagram shows the relationship between pipeline, activity, and dataset:

An input dataset represents the input for an activity in the pipeline, and an output dataset represents the output for the activity. Datasets identify data within different data stores, such as tables, files, folders, and documents. After you create a dataset, you can use it with activities in a pipeline. For example, a dataset can be an input/output dataset of a Copy Activity or an HDInsightHive Activity. For more information about datasets, see Datasets in Azure Data Factory article.

Data movement activities

Copy Activity in Data Factory copies data from a source data store to a sink data store. Data Factory supports the data stores listed in the table in this section. Data from any source can be written to any sink.

For more information, see Copy Activity - Overview article.

Click a data store to learn how to copy data to and from that store.

Data transformation activities

Azure Data Factory and Azure Synapse Analytics support the following transformation activities that can be added either individually or chained with another activity.

For more information, see the data transformation activities article.

Control flow activities

The following control flow activities are supported:

Creating a pipeline with UI

Pipeline JSON

Here is how a pipeline is defined in JSON format:

{ "name": "PipelineName", "properties": { "description": "pipeline description", "activities": [ ], "parameters": { }, "concurrency": <your max pipeline concurrency>, "annotations": [ ] }}

Activity JSON

The activities section can have one or more activities defined within it. There are two main types of activities: Execution and Control Activities.

Execution activities

Execution activities include data movement and data transformation activities. They have the following top-level structure:

{ "name": "Execution Activity Name", "description": "description", "type": "<ActivityType>", "typeProperties": { }, "linkedServiceName": "MyLinkedService", "policy": { }, "dependsOn": { }}

Following table describes properties in the activity JSON definition:

Activity policy

Policies affect the run-time behavior of an activity, giving configuration options. Activity Policies are only available for execution activities.

Activity policy JSON definition

{ "name": "MyPipelineName", "properties": { "activities": [ { "name": "MyCopyBlobtoSqlActivity", "type": "Copy", "typeProperties": { ... }, "policy": { "timeout": "00:10:00", "retry": 1, "retryIntervalInSeconds": 60, "secureOutput": true } } ], "parameters": { ... } }}

Control activity

Control activities have the following top-level structure:

{ "name": "Control Activity Name", "description": "description", "type": "<ActivityType>", "typeProperties": { }, "dependsOn": { }}

Activity dependency

Activity Dependency defines how subsequent activities depend on previous activities, determining the condition of whether to continue executing the next task. An activity can depend on one or multiple previous activities with different dependency conditions.

The different dependency conditions are: Succeeded, Failed, Skipped, Completed.

For example, if a pipeline has Activity A -> Activity B, the different scenarios that can happen are:

• Activity B has dependency condition on Activity A with succeeded: Activity B only runs if Activity A has a final status of succeeded
• Activity B has dependency condition on Activity A with failed: Activity B only runs if Activity A has a final status of failed
• Activity B has dependency condition on Activity A with completed: Activity B runs if Activity A has a final status of succeeded or failed
• Activity B has a dependency condition on Activity A with skipped: Activity B runs if Activity A has a final status of skipped. Skipped occurs in the scenario of Activity X -> Activity Y -> Activity Z, where each activity runs only if the previous activity succeeds. If Activity X fails, then Activity Y has a status of "Skipped" because it never executes. Similarly, Activity Z has a status of "Skipped" as well.

Example: Activity 2 depends on the Activity 1 succeeding

{ "name": "PipelineName", "properties": { "description": "pipeline description", "activities": [ { "name": "MyFirstActivity", "type": "Copy", "typeProperties": { }, "linkedServiceName": { } }, { "name": "MySecondActivity", "type": "Copy", "typeProperties": { }, "linkedServiceName": { }, "dependsOn": [ { "activity": "MyFirstActivity", "dependencyConditions": [ "Succeeded" ] } ] } ], "parameters": { } }}

Sample copy pipeline

In the following sample pipeline, there is one activity of type Copy in the activities section. In this sample, the copy activity copies data from an Azure Blob storage to a database in Azure SQL Database.

{ "name": "CopyPipeline", "properties": { "description": "Copy data from a blob to Azure SQL table", "activities": [ { "name": "CopyFromBlobToSQL", "type": "Copy", "inputs": [ { "name": "InputDataset" } ], "outputs": [ { "name": "OutputDataset" } ], "typeProperties": { "source": { "type": "BlobSource" }, "sink": { "type": "SqlSink", "writeBatchSize": 10000, "writeBatchTimeout": "60:00:00" } }, "policy": { "retry": 2, "timeout": "01:00:00" } } ] }}

Note the following points:

• In the activities section, there is only one activity whose type is set to Copy.
• Input for the activity is set to InputDataset and output for the activity is set to OutputDataset. See Datasets article for defining datasets in JSON.
• In the typeProperties section, BlobSource is specified as the source type and SqlSink is specified as the sink type. In the data movement activities section, click the data store that you want to use as a source or a sink to learn more about moving data to/from that data store.

For a complete walkthrough of creating this pipeline, see Quickstart: create a Data Factory.

Sample transformation pipeline

In the following sample pipeline, there is one activity of type HDInsightHive in the activities section. In this sample, the HDInsight Hive activity transforms data from an Azure Blob storage by running a Hive script file on an Azure HDInsight Hadoop cluster.

{ "name": "TransformPipeline", "properties": { "description": "My first Azure Data Factory pipeline", "activities": [ { "type": "HDInsightHive", "typeProperties": { "scriptPath": "adfgetstarted/script/partitionweblogs.hql", "scriptLinkedService": "AzureStorageLinkedService", "defines": { "inputtable": "wasb://adfgetstarted@<storageaccountname>.blob.core.windows.net/inputdata", "partitionedtable": "wasb://adfgetstarted@<storageaccountname>.blob.core.windows.net/partitioneddata" } }, "inputs": [ { "name": "AzureBlobInput" } ], "outputs": [ { "name": "AzureBlobOutput" } ], "policy": { "retry": 3 }, "name": "RunSampleHiveActivity", "linkedServiceName": "HDInsightOnDemandLinkedService" } ] }}

Note the following points:

• In the activities section, there is only one activity whose type is set to HDInsightHive.
• The Hive script file, partitionweblogs.hql, is stored in the Azure Storage account (specified by the scriptLinkedService, called AzureStorageLinkedService), and in script folder in the container adfgetstarted.
• The defines section is used to specify the runtime settings that are passed to the hive script as Hive configuration values (for example, ${hiveconf:inputtable}, ${hiveconf:partitionedtable}).

The typeProperties section is different for each transformation activity. To learn about type properties supported for a transformation activity, click the transformation activity in the Data transformation activities.

For a complete walkthrough of creating this pipeline, see Tutorial: transform data using Spark.

Multiple activities in a pipeline

The previous two sample pipelines have only one activity in them. You can have more than one activity in a pipeline. If you have multiple activities in a pipeline and subsequent activities are not dependent on previous activities, the activities might run in parallel.

You can chain two activities by using activity dependency, which defines how subsequent activities depend on previous activities, determining the condition whether to continue executing the next task. An activity can depend on one or more previous activities with different dependency conditions.

Scheduling pipelines

Pipelines are scheduled by triggers. There are different types of triggers (Scheduler trigger, which allows pipelines to be triggered on a wall-clock schedule, as well as the manual trigger, which triggers pipelines on-demand). For more information about triggers, see pipeline execution and triggers article.

To have your trigger kick off a pipeline run, you must include a pipeline reference of the particular pipeline in the trigger definition. Pipelines & triggers have an n-m relationship. Multiple triggers can kick off a single pipeline, and the same trigger can kick off multiple pipelines. Once the trigger is defined, you must start the trigger to have it start triggering the pipeline. For more information about triggers, see pipeline execution and triggers article.

For example, say you have a Scheduler trigger, "Trigger A," that I wish to kick off my pipeline, "MyCopyPipeline." You define the trigger, as shown in the following example:

Trigger A definition

{ "name": "TriggerA", "properties": { "type": "ScheduleTrigger", "typeProperties": { ... } }, "pipeline": { "pipelineReference": { "type": "PipelineReference", "referenceName": "MyCopyPipeline" }, "parameters": { "copySourceName": "FileSource" } } }}

Related content

See the following tutorials for step-by-step instructions for creating pipelines with activities:

• Build a pipeline with a copy activity
• Build a pipeline with a data transformation activity

How to achieve CI/CD (continuous integration and delivery) using Azure Data Factory

• Continuous integration and delivery in Azure Data Factory