Копирование и преобразование данных в Azure Blob Storage с помощью Azure Data Factory или Azure Synapse Analytics

ПРИМЕНИМО К: Azure Data Factory Azure Synapse Analytics

В этой статье описывается, как использовать Copy activity в конвейерах Azure Data Factory и Azure Synapse для копирования данных из и в Azure Blob Storage. В нем также описывается использование действия Data Flow для преобразования данных в Azure Blob Storage. Дополнительные сведения см. в статьях Azure Data Factory и Azure Synapse Analytics.

Поддерживаемые возможности

Этот соединитель Azure Blob Storage поддерживается для следующих возможностей:

(1) Azure среды выполнения интеграции (2) локальная среда выполнения интеграции

Для Copy activity этот соединитель Blob-хранилища поддерживает следующее:

• Копирование BLOB-объектов в учетные записи хранения общего назначения Azure и из них, а также в горячее и холодное хранилище BLOB-объектов.
• Копирование блобов с помощью ключа учетной записи, служебной общей сигнатуры доступа (SAS), служебного принципала или управляемых удостоверений для аутентификации ресурсов Azure.
• Копирование больших двоичных объектов из блочных, добавочных или страничных BLOB-объектов, а также копирование данных только в блочные BLOB-объекты.
• Копирование BLOB-объектов "как есть", анализ или создание BLOB-объектов c использованием поддерживаемых форматов файлов и кодеков сжатия.
• Сохранение метаданных файла во время копирования.

Get started

Для выполнения действия копирования с конвейером можно использовать один из следующих средств или пакетов SDK:

• Средство копирования данных
• портал Azure
• SDK .NET
• пакет SDK Python
• Azure PowerShell
• REST API
• шаблон Azure Resource Manager

Создание связанной службы Azure Blob Storage с помощью пользовательского интерфейса

Выполните следующие действия, чтобы создать связанную службу Azure Blob Storage в пользовательском интерфейсе портала Azure.

1. Перейдите на вкладку "Управление" в рабочей области Azure Data Factory или Synapse и выберите "Связанные службы", а затем нажмите кнопку "Создать".

   • Фабрика данных Azure
   • Azure Synapse

   

2. Найдите Blob и выберите соединитель Azure Blob Storage.

   

3. Настройте сведения о службе, проверьте подключение и создайте связанную службу.

   Снимок экрана конфигурации для связанной службы Azure Blob Storage.

Сведения о конфигурации соединителя

Следующие разделы содержат сведения о свойствах, которые используются для определения сущностей конвейера Synapse и Data Factory, характерных для хранилища BLOB-объектов.

Свойства связанной службы

Этот соединитель хранилища объектов BLOB поддерживает следующие типы проверки подлинности. Дополнительные сведения см. в соответствующих разделах.

• Анонимная проверка подлинности
• Проверка подлинности на основе ключа учетной записи
• Аутентификация подписи с общим доступом
• Аутентификация сервисного принципала
• Проверка подлинности с помощью назначенного системой управляемого удостоверения
• Аутентификация с помощью управляемого удостоверения, назначаемого пользователем

Анонимная аутентификация

Следующие свойства поддерживаются для проверки подлинности ключа учетной записи хранения в конвейерах Azure Data Factory или Synapse:

Example:

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

Примеры пользовательского интерфейса:

Интерфейс пользовательского интерфейса описан на следующем рисунке. Этот пример использовал Azure открытый набор данных в качестве источника.

Проверка подлинности на основе ключа учетной записи

Следующие свойства поддерживаются для проверки подлинности ключа учетной записи хранения в конвейерах Azure Data Factory или Synapse:

Example:

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

Example: сохраните ключ учетной записи в 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"
        }
    }
}

Аутентификация подписи совместного доступа (SAS)

Подпись общего доступа обеспечивает делегированный доступ к ресурсам в вашей учетной записи хранения. Вы можете использовать производный ключ доступа, чтобы предоставить клиенту ограниченные разрешения на объекты в вашей учетной записи хранения на определенный период.

Не нужно предоставлять совместный доступ к ключам доступа для учетной записи. Подписанный URL-адрес — это универсальный код ресурса (URI), который в своих параметрах запроса содержит все сведения, необходимые для доступа к ресурсу хранилища с прохождением аутентификации. Для доступа к ресурсам хранилища с помощью подписи общей доступа (SAS) клиенту достаточно передать её в соответствующий конструктор или метод.

Дополнительные сведения о подписанных URL-адресах для общего доступа см. в статье Подписанные URL-адреса для общего доступа (SAS): Понимание модели подписанных URL-адресов.

Следующие свойства поддерживаются для использования аутентификации с помощью подписи общего доступа.

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

Example: сохраните ключ учетной записи в 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"
        }
    }
}

При создании URI с общей подписью доступа необходимо учитывать следующее.

• Задайте для объектов соответствующие разрешения на чтение или запись. Они устанавливаются с учетом назначения связанной службы (чтение, запись, чтение и запись).
• Задайте время окончания срока действия соответствующим образом. Убедитесь, что срок действия доступа к объектам хранилища не истекает в период активности конвейера.
• В зависимости от потребности URI следует создать для нужного контейнера или BLOB-объекта. URI с подписью общего доступа для объекта BLOB позволяет Фабрике данных или конвейеру Synapse получить доступ к этому конкретному объекту BLOB. URI с общей подписью доступа для контейнера хранилища Blob позволяет Azure Data Factory или конвейеру Synapse перебирать объекты Blob в этом контейнере. Чтобы предоставить доступ к большему или меньшему количеству объектов позднее или обновить URI подписанного URL-адреса, не забудьте обновить связанную службу с помощью нового URI.

Аутентификация служебного принципала

Общие сведения о проверке подлинности субъекта-службы Azure Storage см. в статье Authenticate access to Azure Storage using Microsoft Entra ID.

Чтобы использовать проверку подлинности служебного принципала, выполните следующие действия.

1. Зарегистрируйте приложение с помощью Microsoft identity platform. Дополнительные сведения см. в статье Quickstart: регистрация приложения с помощью Microsoft identity platform. Запишите эти значения, которые используются для определения связанной службы:

   • Идентификатор приложения
   • ключ приложения.
   • Идентификатор арендатора

2. Предоставьте субъекту-службе соответствующее разрешение в Azure Blob Storage. Дополнительные сведения о ролях см. в статье Использование портала Azure для назначения роли Azure для доступа к данным объектов blob и очередей.

   • В качестве источника в Системе управления доступом (IAM) предоставьте как минимум роль Читатель данных хранилища Blob.
   • В Системе управления идентификацией и доступом (IAM)приемнику необходимо выделить роль не ниже участника для данных BLOB-объектов хранилища.

Эти свойства поддерживаются для связанной службы Azure Blob Storage:

Example:

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

Аутентификация с использованием системного управляемого удостоверения

Фабрику данных или конвейер Synapse можно связать с системным управляемым удостоверением для ресурсов Azure, что позволяет этому ресурсу проходить аутентификацию в других службах Azure. Это назначаемое системой управляемое удостоверение можно использовать для проверки подлинности хранилища Blob-объектов, как и собственный служебный принципал. Оно позволяет назначенному ресурсу получать доступ к данным и копировать их из/в хранилище объектов Blob. Дополнительные сведения об управляемых удостоверениях для ресурсов Azure см. в статье Управляемые удостоверения для ресурсов Azure

Общие сведения о проверке подлинности Azure Storage см. в разделе Authenticate access to Azure Storage using Microsoft Entra ID. Чтобы использовать управляемые удостоверения для проверки подлинности ресурсов Azure, выполните следующие действия.

1. Получите сведения о назначаемом системой управляемом удостоверении, скопировав значение идентификатора объекта назначаемого системой управляемого удостоверения, созданного вместе с рабочей областью Фабрики данных Azure или Synapse.

2. Предоставьте разрешение управляемого удостоверения в Azure Blob Storage. Дополнительные сведения о ролях см. в статье Использование портала Azure для назначения роли Azure для доступа к данным объектов blob и очередей.

   • В качестве источника в Системе управления доступом (IAM) предоставьте как минимум роль Читатель данных хранилища Blob.
   • В Системе управления идентификацией и доступом (IAM)приемнику необходимо выделить роль не ниже участника для данных BLOB-объектов хранилища.

Эти свойства поддерживаются для связанной службы Azure Blob Storage:

Example:

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

Проверка подлинности с помощью назначаемого пользователем управляемого удостоверения

Фабрике данных может быть назначено одно или несколько управляемых удостоверений, назначаемых пользователем. Вы можете использовать это управляемое удостоверение, назначенное пользователем, для аутентификации в хранилище BLOB-объектов, что позволяет получить доступ к данным и копировать их из хранилища BLOB-объектов или в него. Дополнительные сведения об управляемых удостоверениях для ресурсов Azure см. в статье Управляемые удостоверения для ресурсов Azure

Общие сведения о проверке подлинности Azure storage см. в разделе Authenticate access to Azure Storage using Microsoft Entra ID. Для использования проверки подлинности с помощью управляемого удостоверения, назначаемого пользователем, выполните приведенные ниже действия.

1. Создайте одно или несколько управляемых удостоверений, назначенных пользователем, и предоставьте разрешения в Azure Blob Storage. Дополнительные сведения о ролях см. в статье Использование портала Azure для назначения роли Azure для доступа к данным объектов blob и очередей.

   • В качестве источника в Системе управления доступом (IAM) предоставьте как минимум роль Читатель данных хранилища Blob.
   • В Системе управления идентификацией и доступом (IAM)приемнику необходимо выделить роль не ниже участника для данных BLOB-объектов хранилища.

2. Назначьте одно или несколько управляемых удостоверений, назначаемых пользователем, вашей фабрике данных и создайте учетные данные для каждого из таких удостоверений.

Эти свойства поддерживаются для связанной службы Azure Blob Storage:

Example:

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

Свойства набора данных

Полный список разделов и свойств, доступных для определения наборов данных, см. в статье о наборах данных.

Azure Data Factory поддерживает следующие форматы файлов. Дополнительные сведения о параметрах с учетом форматирования см. в соответствующих статьях.

• Формат Avro
• Двоичный формат
• Формат текста с разделителями
• формат Excel
• Формат JSON
• Формат ORC
• Формат файла Parquet
• ФОРМАТ XML

Следующие свойства поддерживаются для Azure Blob Storage в разделе location в наборе данных на основе формата:

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

Полный список разделов и свойств, доступных для определения действий, см. в статье Конвейеры. В этом разделе приведен список свойств, поддерживаемых источником и получателем хранилища объектов Blob.

Хранилище BLOB как тип источника

Azure Data Factory поддерживает следующие форматы файлов. Дополнительные сведения о параметрах с учетом форматирования см. в соответствующих статьях.

• Формат Avro
• Двоичный формат
• Формат текста с разделителями
• формат Excel
• Формат JSON
• Формат ORC
• Формат файла Parquet
• ФОРМАТ XML

Следующие свойства поддерживаются для Azure Blob Storage в разделе параметров, связанных с источником копирования, работающим на основе формата storeSettings.

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-хранилище как тип приемника

Azure Data Factory поддерживает следующие форматы файлов. Дополнительные сведения о параметрах с учетом форматирования см. в соответствующих статьях.

• Формат Avro
• Двоичный формат
• Формат текста с разделителями
• Формат JSON
• Формат ORC
• Формат файла Parquet

Следующие свойства поддерживаются для Azure Blob Storage в настройках storeSettings в приемнике копирования, основанном на формате:

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",
                    "metadata": [
                        {
                            "name": "testKey1",
                            "value": "value1"
                        },
                        {
                            "name": "testKey2",
                            "value": "value2"
                        },
                        {
                            "name": "lastModifiedKey",
                            "value": "$$LASTMODIFIED"
                        }
                    ]
                }
            }
        }
    }
]

Примеры фильтров папок и файлов

В этом разделе описывается поведение пути папки и имени файла при использовании фильтров с подстановочными знаками.

Примеры списков файлов

В этом разделе описывается поведение, возникающее при использовании пути к списку файлов в источнике деятельности копирования.

Предположим, что у вас есть следующая исходная структура папок и вы хотите скопировать файлы, выделенные полужирным шрифтом:

Некоторые примеры recursive и copyBehavior

В данном разделе описываются результаты выполнения операции копирования при использовании различных сочетаний значений recursive и copyBehavior.

Сохранение метаданных во время копирования

При копировании файлов из Amazon S3, Azure Blob Storage или Azure Data Lake Storage Gen2 в Azure Data Lake Storage Gen2 или Azure Blob Storage можно сохранить метаданные файла вместе с данными. Подробнее см. в разделе Сохранение метаданных.

Сопоставление свойств потока данных

При преобразовании данных в потоках данных сопоставления можно считывать и записывать файлы из Azure Blob Storage в следующих форматах:

• Avro
• Текст с разделителями
• Delta
• Excel
• JSON
• Parquet

Конкретные параметры приведены в документации для соответствующего формата. Дополнительные сведения см. в статьях Преобразование источника в потоке данных для сопоставления и Преобразование приемника в потоке данных для сопоставления.

Преобразование источника

При преобразовании источника можно считывать данные из контейнера, папки или отдельного файла в Azure Blob Storage. Используйте вкладку Параметры источника для управления чтением файлов.

Пути с подстановочными знаками: Использование шаблона с подстановочными знаками указывает службе перебрать каждую соответствующую папку и файл в ходе одного преобразования источника. Это эффективный способ обработки нескольких файлов в одном потоке. Добавьте несколько шаблонов сопоставления с подстановочными знаками с помощью значка "плюс", который появляется при наведении указателя мыши на существующий шаблон с подстановочными знаками.

В исходном контейнере выберите файлы, соответствующие шаблону. В наборе данных можно указать только контейнер. Ваш путь с подстановочными знаками должен также включать путь к папке, начиная с корневой папки.

Примеры подстановочных знаков:

• * — представляет любой набор символов.

• ** — представляет рекурсивную вложенность каталога.

• ? — заменяет один символ.

• [] — соответствует одному или нескольким символам в квадратных скобках.

• /data/sales/**/*.csv — возвращает все файлы .csv в папке /data/sales.

• /data/sales/20??/**/ — возвращает все файлы, созданные в 20 веке.

• /data/sales/*/*/*.csv — возвращает файлы .csv, расположенные двумя уровнями ниже папки /data/sales.

• /data/sales/2004/*/12/[XY]1?.csv — возвращает все файлы .csv, созданные в декабре 2004 года, которые начинаются с X или Y с двузначным числом в качестве префикса.

Корневой путь раздела. Если в источнике файлов имеются секционированные папки формата key=value (например, year=2019), то верхний уровень этого дерева секционированной папки можно назначить имени столбца в потоке данных.

Во-первых, задайте подстановочный знак, чтобы включить все пути, которые содержатся в секционированных папках, и конечные файлы, которые вы хотите прочитать.

Для определения верхнего уровня структуры папок используйте параметр Корневой путь раздела. При просмотре содержимого данных с помощью предварительного просмотра данных вы увидите, что служба добавляет разрешенные секции, найденные на каждом из уровней папок.

Список файлов: это набор файлов. Создайте текстовый файл, который включает список относительных путей файлов для обработки. Укажите на этот текстовый файл.

Столбец для хранения имени файла: сохраните имя исходного файла в столбце в данных. Укажите здесь новое имя столбца для хранения строки имени файла.

После завершения: выберите ничего делать с исходным файлом после запуска потока данных, удалите исходный файл или переместите исходный файл. Пути для перемещения являются относительными.

Чтобы переместить исходные файлы в другое расположение после обработки, сначала выберите "Переместить" для операции с файлом. Затем задайте исходный каталог. Если вы не используете подстановочные знаки для пути, в настройке "from" будет использоваться та же папка, что и ваш исходный каталог.

Если у вас есть исходный путь с подстановочным знаком, синтаксис выглядит следующим образом:

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

Можно указать «from» как:

/data/sales

А в качестве целевой точки можно указать:

/backup/priorSales

В этом случае все файлы, источником которых является папка /data/sales, перемещаются в папку /backup/priorSales.

Фильтр по последнему изменению: вы можете отфильтровать файлы для обработки, указав диапазон дат момента последнего изменения. Все значения даты и времени указаны в формате UTC.

Включите запись измененных данных: если верно, вы получите новые или измененные файлы только после последнего запуска. При первом запуске всегда выполняется начальная загрузка данных, то есть получается полный моментальный снимок, а при следующих запусках записываются только новые или измененные файлы.

Свойства приемника

В синковом преобразовании вы можете записывать в контейнер или папку в Azure Blob Storage. Используйте вкладку Параметры для управления записью файлов.

Очистить папку: определяет, очищается ли целевая папка перед записью данных.

Параметр имени файла: определяет, как целевые файлы именуются в целевой папке. Доступные параметры имени файла:

• По умолчанию: разрешить SPARK назначать файлы в соответствии с исходными настройками PART.
• Шаблон. Введите шаблон, который перечисляет выходные файлы на секцию. Например, loans[n].csv создает loans1.csvи loans2.csvт. д.
• На раздел: введите одно имя файла для каждого раздела.
• Как данные в столбце: задайте выходной файл значению столбца. Путь задается относительно контейнера набора данных, а не папки назначения. Если в вашем наборе данных указан путь к папке, он будет переопределен.
• Выходные данные в один файл: объединение секционированных выходных файлов в один именованный файл. Путь задается относительно папки набора данных. Операция слияния может завершиться ошибкой в зависимости от размера узла. Этот параметр не рекомендуется использовать для больших наборов данных.

Все в кавычках: указывает, следует ли заключать все значения в кавычки.

Свойства действия поиска

Подробные сведения об этих свойствах см. в разделе Действие поиска.

Свойства операции GetMetadata

Подробные сведения об этих свойствах см. в статье Действие GetMetadata.

Свойства удаления активности

Чтобы узнать подробности о свойствах, ознакомьтесь со статьей Удаление активности.

Устаревшие модели

Устаревшая модель набора данных

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

Устаревшая исходная модель для 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>"
            }
        }
    }
]

Устаревшая модель приемника для 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"
            }
        }
    }
]

фикcирование изменений данных

Azure Data Factory может получать новые или измененные файлы только из Azure Blob Storage, включив **включение захвата измененных данных** в преобразовании источника данных сопоставления. Этот параметр соединителя позволяет считывать только новые или обновленные файлы и применять преобразования перед загрузкой преобразованных данных в нужные целевые наборы. Дополнительные сведения см. в статье об отслеживании измененных данных .

Связанный контент

Список хранилищ данных, поддерживаемых Copy activity в качестве источников и приемников, см. в разделе Сопортированные хранилища данных.