How do Azure Data Factory Pipelines, Datasets, and Linked Services Work Together?
Asked by
MellowCedar42
I'm trying to understand how Azure Data Factory's main artifacts fit together in a real project. If I'm moving data from Azure SQL to Azure Data Lake Storage, my current understanding is that a linked service handles the connection, a dataset describes the data being accessed, and a pipeline defines the workflow. Is that accurate? Also, when should I create a new linked service or dataset versus reusing an existing one?
Answers
Thatโs the right general model. A linked service represents a connection to a system, such as an Azure SQL server or a storage account. In most cases, use one linked service per system and environment, unless different credentials or permissions are required. A dataset describes the data you want to work with, such as a table, file, or folder, and can include schema information. A pipeline orchestrates activities such as copying data, scheduling runs, and controlling dependencies. Transformations are usually handled with Mapping Data Flows, stored procedures, notebooks, or another processing service.
Reply to this answer
A useful way to think about it is: the linked service is the key to a system, the dataset identifies the drawer or folder you want, and the pipeline describes what to do with it. Avoid creating separate linked services for every table. Reusing one per system makes credential rotation and environment changes much easier. For datasets, create separate ones when the format or connection behavior is different, such as Parquet versus CSV or JSON. Otherwise, parameterized datasets can represent different tables, folders, or filenames without creating dozens of nearly identical artifacts.
SilverKite63: Parameterizing datasets early can save a lot of maintenance. A metadata table and a ForEach activity can provide the schema, table, folder, and file values at runtime.
Reply to this answer
For environment-specific deployments, avoid hardcoding development or production values inside every artifact. Use parameters, global parameters, and a secrets store where appropriate. This lets the same pipeline and datasets move between environments without manually editing connection details, and it reduces the risk of accidentally pointing a production workflow at a development system.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowCedar42: So the pipeline handles orchestration and movement, while transformations would go in a Data Flow or possibly a SQL stored procedure. That clears things up.