Copiar e transformar dados no Banco de Dados SQL do Azure usando o Azure Data Factory ou o Azure Synapse Analytics
APLICA-SE A:
Azure Data Factory Azure Synapse Analytics
Gorjeta
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!
Este artigo descreve como usar a Atividade de Cópia no Azure Data Factory ou nos pipelines do Azure Synapse para copiar dados de e para o Banco de Dados SQL do Azure e usar o Fluxo de Dados para transformar dados no Banco de Dados SQL do Azure. Para saber mais, leia o artigo introdutório do Azure Data Factory ou do Azure Synapse Analytics.
Capacidades suportadas
Este conector da Base de Dados SQL do Azure tem suporte para as seguintes capacidades:
| Capacidades suportadas | IR | Ponto final privado gerido |
|---|---|---|
| Atividade de cópia (origem/coletor) | (1) (2) | ✓ |
| Mapeando o fluxo de dados (origem/coletor) | (1) | ✓ |
| Atividade de Pesquisa | (1) (2) | ✓ |
| Atividade GetMetadata | (1) (2) | ✓ |
| Atividade de script | (1) (2) | ✓ |
| Atividade de procedimento armazenado | (1) (2) | ✓ |
(1) Tempo de execução de integração do Azure (2) Tempo de execução de integração auto-hospedado
Para atividade de cópia, este conector do Banco de Dados SQL do Azure dá suporte a estas funções:
- Copiar dados usando a autenticação SQL e a autenticação de token do Aplicativo Microsoft Entra com uma entidade de serviço ou identidades gerenciadas para recursos do Azure.
- Como origem, recuperando dados usando uma consulta SQL ou um procedimento armazenado. Você também pode optar por copiar paralelamente de uma fonte do Banco de Dados SQL do Azure, consulte a seção Cópia paralela do banco de dados SQL para obter detalhes.
- Como um coletor, criando automaticamente a tabela de destino se não existir com base no esquema de origem; anexar dados a uma tabela ou invocar um procedimento armazenado com lógica personalizada durante a cópia.
Se você usar a camada sem servidor do Banco de Dados SQL do Azure, observe que, quando o servidor estiver pausado, a execução da atividade falhará em vez de aguardar que a retomada automática esteja pronta. Você pode adicionar repetição de atividade ou encadear atividades adicionais para garantir que o servidor esteja ativo após a execução real.
Importante
Se você copiar dados usando o tempo de execução de integração do Azure, configure uma regra de firewall no nível do servidor para que os serviços do Azure possam acessar o servidor. Se você copiar dados usando um tempo de execução de integração auto-hospedado, configure o firewall para permitir o intervalo de IP apropriado. Esse intervalo inclui o IP da máquina usado para se conectar ao Banco de Dados SQL do Azure.
Começar agora
Para executar a atividade Copiar com um pipeline, você pode usar uma das seguintes ferramentas ou SDKs:
- A ferramenta Copiar dados
- O portal do Azure
- O SDK do .NET
- O SDK do Python
- Azure PowerShell
- A API REST
- O modelo do Azure Resource Manager
Criar um serviço vinculado do Banco de Dados SQL do Azure usando a interface do usuário
Use as etapas a seguir para criar um serviço vinculado do Banco de Dados SQL do Azure na interface do usuário do portal do Azure.
Navegue até a guia Gerenciar em seu espaço de trabalho do Azure Data Factory ou Synapse e selecione Serviços Vinculados e clique em Novo:
Procure SQL e selecione o conector do Banco de Dados SQL do Azure.
Configure os detalhes do serviço, teste a conexão e crie o novo serviço vinculado.
Detalhes de configuração do conector
As seções a seguir fornecem detalhes sobre as propriedades usadas para definir o Azure Data Factory ou entidades de pipeline Synapse específicas para um conector do Banco de Dados SQL do Azure.
Propriedades do serviço vinculado
Estas propriedades genéricas têm suporte para um serviço vinculado do Banco de Dados SQL do Azure:
| Property | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type deve ser definida como AzureSqlDatabase. | Sim |
| connectionString | Especifique as informações necessárias para se conectar à instância do Banco de Dados SQL do Azure para a propriedade connectionString . Você também pode colocar uma senha ou chave principal de serviço no Cofre de Chaves do Azure. Se for autenticação SQL, extraia a password configuração da cadeia de conexão. Para obter mais informações, consulte o exemplo JSON seguindo a tabela e Armazenar credenciais no Cofre da Chave do Azure. |
Sim |
| azureCloudType | Para autenticação da entidade de serviço, especifique o tipo de ambiente de nuvem do Azure no qual seu aplicativo Microsoft Entra está registrado. Os valores permitidos são AzurePublic, AzureChina, AzureUsGovernment e AzureGermany. Por padrão, a fábrica de dados ou o ambiente de nuvem do pipeline Synapse é usado. |
Não |
| alwaysEncryptedSettings | Especifique as informações alwaysencryptedsettings necessárias para habilitar o Always Encrypted para proteger dados confidenciais armazenados no SQL Server usando identidade gerenciada ou entidade de serviço. Para obter mais informações, consulte o exemplo JSON seguindo a tabela e a seção Usando sempre criptografado . Se não for especificado, a configuração padrão sempre criptografada será desabilitada. | Não |
| ConecteVia | Esse tempo de execução de integração é usado para se conectar ao armazenamento de dados. Você pode usar o tempo de execução de integração do Azure ou um tempo de execução de integração auto-hospedado se seu armazenamento de dados estiver localizado em uma rede privada. Se não for especificado, o tempo de execução de integração padrão do Azure será usado. | Não |
Para diferentes tipos de autenticação, consulte as seguintes seções sobre propriedades específicas, pré-requisitos e exemplos JSON, respectivamente:
- Autenticação SQL
- Autenticação do principal de serviço
- Autenticação de identidade gerenciada atribuída pelo sistema
- Autenticação de identidade gerenciada atribuída pelo usuário
Gorjeta
Se você acertar um erro com o código de erro "UserErrorFailedToConnectToSqlServer" e uma mensagem como "O limite de sessão para o banco de dados é XXX e foi atingido", adicione Pooling=false à sua cadeia de conexão e tente novamente. Pooling=falsetambém é recomendado para a configuração de serviço vinculado do tipo SHIR (Self Hosted Integration Runtime). O pool e outros parâmetros de conexão podem ser adicionados como novos nomes e valores de parâmetros na seção Propriedades de conexão adicionais do formulário de criação de serviço vinculado.
Autenticação do SQL
Para usar o tipo de autenticação SQL, especifique as propriedades genéricas descritas na seção anterior.
Exemplo: usando a autenticação SQL
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;User ID=<username>@<servername>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Exemplo: palavra-passe no Cofre de Chaves do Azure
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;User ID=<username>@<servername>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30",
"password": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "<Azure Key Vault linked service name>",
"type": "LinkedServiceReference"
},
"secretName": "<secretName>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Exemplo: Usar sempre criptografado
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;User ID=<username>@<servername>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30"
},
"alwaysEncryptedSettings": {
"alwaysEncryptedAkvAuthType": "ServicePrincipal",
"servicePrincipalId": "<service principal id>",
"servicePrincipalKey": {
"type": "SecureString",
"value": "<service principal key>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Autenticação do principal de serviço
Para usar a autenticação da entidade de serviço, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:
| Property | Descrição | Obrigatório |
|---|---|---|
| servicePrincipalId | Especifique o ID do cliente do aplicativo. | Sim |
| servicePrincipalKey | Especifique a chave do aplicativo. Marque este campo como SecureString para armazená-lo com segurança ou fazer referência a um segredo armazenado no Cofre de Chaves do Azure. | Sim |
| inquilino | Especifique as informações do locatário, como o nome de domínio ou ID do locatário, sob o qual seu aplicativo reside. Recupere-o passando o mouse no canto superior direito do portal do Azure. | Sim |
Você também precisa seguir os passos abaixo:
Crie um aplicativo Microsoft Entra a partir do portal do Azure. Anote o nome do aplicativo e os seguintes valores que definem o serviço vinculado:
- ID da aplicação
- Chave de aplicação
- ID de Inquilino do
Provisione um administrador do Microsoft Entra para seu servidor no portal do Azure, se ainda não tiver feito isso. O administrador do Microsoft Entra deve ser um usuário do Microsoft Entra ou um grupo do Microsoft Entra, mas não pode ser uma entidade de serviço. Esta etapa é feita para que, na próxima etapa, você possa usar uma identidade do Microsoft Entra para criar um usuário de banco de dados contido para a entidade de serviço.
Crie usuários de banco de dados contidos para a entidade de serviço. Conecte-se ao banco de dados do qual você deseja copiar dados usando ferramentas como o SQL Server Management Studio, com uma identidade Microsoft Entra que tenha pelo menos a permissão ALTER ANY USER. Execute o seguinte T-SQL:
CREATE USER [your application name] FROM EXTERNAL PROVIDER;Conceda à entidade de serviço as permissões necessárias como normalmente faz para usuários SQL ou outros. Execute o código a seguir. Para mais opções, consulte este documento.
ALTER ROLE [role name] ADD MEMBER [your application name];Configure um serviço vinculado do Banco de Dados SQL do Azure em um espaço de trabalho do Azure Data Factory ou Synapse.
Exemplo de serviço vinculado que usa a autenticação da entidade de serviço
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;Connection Timeout=30",
"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"
}
}
}
Autenticação de identidade gerenciada atribuída pelo sistema
Um data factory ou espaço de trabalho Synapse pode ser associado a uma identidade gerenciada atribuída pelo sistema para recursos do Azure que representa o serviço ao autenticar em outros recursos no Azure. Você pode usar essa identidade gerenciada para autenticação do Banco de Dados SQL do Azure. A fábrica designada ou o espaço de trabalho Synapse pode acessar e copiar dados de ou para seu banco de dados usando essa identidade.
Para usar a autenticação de identidade gerenciada atribuída pelo sistema, especifique as propriedades genéricas descritas na seção anterior e siga estas etapas.
Provisione um administrador do Microsoft Entra para seu servidor no portal do Azure, se ainda não tiver feito isso. O administrador do Microsoft Entra pode ser um usuário do Microsoft Entra ou um grupo do Microsoft Entra. Se você conceder ao grupo com identidade gerenciada uma função de administrador, ignore as etapas 3 e 4. O administrador tem acesso total à base de dados.
Crie usuários de banco de dados contidos para a identidade gerenciada. Conecte-se ao banco de dados do qual você deseja copiar dados usando ferramentas como o SQL Server Management Studio, com uma identidade Microsoft Entra que tenha pelo menos a permissão ALTER ANY USER. Execute o seguinte T-SQL:
CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;Conceda a identidade gerenciada necessária permissões como você normalmente faz para usuários SQL e outros. Execute o código a seguir. Para mais opções, consulte este documento.
ALTER ROLE [role name] ADD MEMBER [your_resource_name];Configure um serviço vinculado do Banco de Dados SQL do Azure.
Exemplo
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;Connection Timeout=30"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Autenticação de identidade gerenciada atribuída pelo usuário
Um data factory ou espaço de trabalho Synapse pode ser associado a uma identidade gerenciada atribuída pelo usuário que representa o serviço ao autenticar outros recursos no Azure. Você pode usar essa identidade gerenciada para autenticação do Banco de Dados SQL do Azure. A fábrica designada ou o espaço de trabalho Synapse pode acessar e copiar dados de ou para seu banco de dados usando essa identidade.
Para usar a autenticação de identidade gerenciada atribuída pelo usuário, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:
| Property | Descrição | Obrigatório |
|---|---|---|
| credenciais | Especifique a identidade gerenciada atribuída pelo usuário como o objeto de credencial. | Sim |
Você também precisa seguir os passos abaixo:
Provisione um administrador do Microsoft Entra para seu servidor no portal do Azure, se ainda não tiver feito isso. O administrador do Microsoft Entra pode ser um usuário do Microsoft Entra ou um grupo do Microsoft Entra. Se você conceder ao grupo com identidade gerenciada atribuída pelo usuário uma função de administrador, ignore as etapas 3. O administrador tem acesso total à base de dados.
Crie usuários de banco de dados contidos para a identidade gerenciada atribuída pelo usuário. Conecte-se ao banco de dados do qual você deseja copiar dados usando ferramentas como o SQL Server Management Studio, com uma identidade Microsoft Entra que tenha pelo menos a permissão ALTER ANY USER. Execute o seguinte T-SQL:
CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;Crie uma ou várias identidades gerenciadas atribuídas pelo usuário e conceda à identidade gerenciada atribuída pelo usuário as permissões necessárias como você normalmente faz para usuários SQL e outros. Execute o código a seguir. Para mais opções, consulte este documento.
ALTER ROLE [role name] ADD MEMBER [your_resource_name];Atribua uma ou várias identidades gerenciadas atribuídas pelo usuário ao seu data factory e crie credenciais para cada identidade gerenciada atribuída pelo usuário.
Configure um serviço vinculado do Banco de Dados SQL do Azure.
Exemplo:
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;Connection Timeout=30",
"credential": {
"referenceName": "credential1",
"type": "CredentialReference"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Propriedades do conjunto de dados
Para obter uma lista completa de seções e propriedades disponíveis para definir conjuntos de dados, consulte Conjuntos de dados.
As seguintes propriedades têm suporte para o conjunto de dados do Banco de Dados SQL do Azure:
| Property | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type do conjunto de dados deve ser definida como AzureSqlTable. | Sim |
| esquema | Nome do esquema. | Não para a fonte, Sim para o lavatório |
| tabela | Nome da tabela/vista. | Não para a fonte, Sim para o lavatório |
| tableName | Nome da tabela/vista com esquema. Esta propriedade é suportada para compatibilidade com versões anteriores. Para nova carga de trabalho, use schema e table. |
Não para a fonte, Sim para o lavatório |
Exemplo de propriedades de conjunto de dados
{
"name": "AzureSQLDbDataset",
"properties":
{
"type": "AzureSqlTable",
"linkedServiceName": {
"referenceName": "<Azure SQL Database linked service name>",
"type": "LinkedServiceReference"
},
"schema": [ < physical schema, optional, retrievable during authoring > ],
"typeProperties": {
"schema": "<schema_name>",
"table": "<table_name>"
}
}
}
Propriedades da atividade Copy
Para obter uma lista completa de seções e propriedades disponíveis para definir atividades, consulte Pipelines. Esta seção fornece uma lista de propriedades suportadas pela fonte e coletor do Banco de Dados SQL do Azure.
Banco de Dados SQL do Azure como a origem
Gorjeta
Para carregar dados do Banco de Dados SQL do Azure de forma eficiente usando o particionamento de dados, saiba mais em Cópia paralela do banco de dados SQL.
Para copiar dados do Banco de Dados SQL do Azure, as seguintes propriedades são suportadas na seção de fonte de atividade de cópia:
| Property | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type da fonte de atividade de cópia deve ser definida como AzureSqlSource. O tipo "SqlSource" ainda é suportado para compatibilidade com versões anteriores. | Sim |
| sqlReaderQuery | Esta propriedade usa a consulta SQL personalizada para ler dados. Um exemplo é select * from MyTable. |
Não |
| sqlReaderStoredProcedureName | O nome do procedimento armazenado que lê dados da tabela de origem. A última instrução SQL deve ser uma instrução SELECT no procedimento armazenado. | Não |
| storedProcedureParameters | Parâmetros para o procedimento armazenado. Os valores permitidos são pares de nome ou valor. Os nomes e o invólucro dos parâmetros devem corresponder aos nomes e invólucros dos parâmetros do procedimento armazenado. |
Não |
| Nível de isolamento | Especifica o comportamento de bloqueio de transação para a fonte SQL. Os valores permitidos são: ReadCommitted, ReadUncommitted, RepeatableRead, Serializable, Snapshot. Se não for especificado, o nível de isolamento padrão do banco de dados será usado. Consulte este documento para obter mais detalhes. | Não |
| partitionOptions | Especifica as opções de particionamento de dados usadas para carregar dados do Banco de Dados SQL do Azure. Os valores permitidos são: None (padrão), PhysicalPartitionsOfTable e DynamicRange. Quando uma opção de partição é habilitada (ou seja, não None), o grau de paralelismo para carregar simultaneamente dados de um Banco de Dados SQL do Azure é controlado pela parallelCopies configuração na atividade de cópia. |
Não |
| partitionSettings | Especifique o grupo de configurações para particionamento de dados. Aplique quando a opção de partição não Nonefor . |
Não |
Em partitionSettings: |
||
| partitionColumnName | Especifique o nome da coluna de origem no número inteiro ou no tipo data/data/hora (int, smallint, bigint, date, smalldatetimedatetimedatetime2, , ou datetimeoffset) que será usado pelo particionamento de intervalo para cópia paralela. Se não for especificado, o índice ou a chave primária da tabela será detetado automaticamente e usado como a coluna de partição.Aplique quando a opção de partição for DynamicRange. Se você usar uma consulta para recuperar os dados de origem, conecte ?AdfDynamicRangePartitionCondition a cláusula WHERE. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL. |
Não |
| partiçãoUpperBound | O valor máximo da coluna de partição para divisão do intervalo de partições. Esse valor é usado para decidir a passada da partição, não para filtrar as linhas na tabela. Todas as linhas na tabela ou no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Aplique quando a opção de partição for DynamicRange. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL. |
Não |
| partiçãoLowerBound | O valor mínimo da coluna de partição para divisão do intervalo de partições. Esse valor é usado para decidir a passada da partição, não para filtrar as linhas na tabela. Todas as linhas na tabela ou no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Aplique quando a opção de partição for DynamicRange. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL. |
Não |
Tenha em atenção os seguintes pontos:
- Se sqlReaderQuery for especificado para AzureSqlSource, a atividade de cópia executará essa consulta na fonte do Banco de Dados SQL do Azure para obter os dados. Você também pode especificar um procedimento armazenado especificando sqlReaderStoredProcedureName e storedProcedureParameters se o procedimento armazenado tiver parâmetros.
- Ao usar o procedimento armazenado na origem para recuperar dados, observe se o procedimento armazenado for projetado como retornando esquema diferente quando um valor de parâmetro diferente for passado, você poderá encontrar falha ou ver um resultado inesperado ao importar esquema da interface do usuário ou ao copiar dados para o banco de dados SQL com a criação automática de tabelas.
Exemplo de consulta SQL
"activities":[
{
"name": "CopyFromAzureSQLDatabase",
"type": "Copy",
"inputs": [
{
"referenceName": "<Azure SQL Database input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "AzureSqlSource",
"sqlReaderQuery": "SELECT * FROM MyTable"
},
"sink": {
"type": "<sink type>"
}
}
}
]
Exemplo de procedimento armazenado
"activities":[
{
"name": "CopyFromAzureSQLDatabase",
"type": "Copy",
"inputs": [
{
"referenceName": "<Azure SQL Database input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "AzureSqlSource",
"sqlReaderStoredProcedureName": "CopyTestSrcStoredProcedureWithParameters",
"storedProcedureParameters": {
"stringData": { "value": "str3" },
"identifier": { "value": "$$Text.Format('{0:yyyy}', <datetime parameter>)", "type": "Int"}
}
},
"sink": {
"type": "<sink type>"
}
}
}
]
Definição de procedimento armazenado
CREATE PROCEDURE CopyTestSrcStoredProcedureWithParameters
(
@stringData varchar(20),
@identifier int
)
AS
SET NOCOUNT ON;
BEGIN
select *
from dbo.UnitTestSrcTable
where dbo.UnitTestSrcTable.stringData != stringData
and dbo.UnitTestSrcTable.identifier != identifier
END
GO
Banco de Dados SQL do Azure como o coletor
Gorjeta
Saiba mais sobre os comportamentos, configurações e práticas recomendadas de gravação com suporte em Práticas recomendadas para carregar dados no Banco de Dados SQL do Azure.
Para copiar dados para o Banco de Dados SQL do Azure, as seguintes propriedades são suportadas na seção coletor de atividade de cópia:
| Property | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type do coletor de atividade de cópia deve ser definida como AzureSqlSink. O tipo "SqlSink" ainda é suportado para compatibilidade com versões anteriores. | Sim |
| pré-CopyScript | Especifique uma consulta SQL para que a atividade de cópia seja executada antes de gravar dados no Banco de Dados SQL do Azure. É invocado apenas uma vez por execução de cópia. Use essa propriedade para limpar os dados pré-carregados. | Não |
| tableOption | Especifica se a tabela de coletor deve ser criada automaticamente se não existir com base no esquema de origem. A criação automática de tabelas não é suportada quando o coletor especifica o procedimento armazenado. Os valores permitidos são: none (padrão), autoCreate. |
Não |
| sqlWriterStoredProcedureName | O nome do procedimento armazenado que define como aplicar dados de origem em uma tabela de destino. Este procedimento armazenado é invocado por lote. Para operações que são executadas apenas uma vez e não têm nada a ver com dados de origem, por exemplo, excluir ou trugar, use a preCopyScript propriedade.Veja o exemplo de Invocar um procedimento armazenado de um coletor SQL. |
Não |
| storedProcedureTableTypeParameterName | O nome do parâmetro do tipo de tabela especificado no procedimento armazenado. | Não |
| sqlWriterTableType | O nome do tipo de tabela a ser usado no procedimento armazenado. A atividade de cópia torna os dados que estão sendo movidos disponíveis em uma tabela temporária com esse tipo de tabela. O código de procedimento armazenado pode mesclar os dados que estão sendo copiados com os dados existentes. | Não |
| storedProcedureParameters | Parâmetros para o procedimento armazenado. Os valores permitidos são pares de nome e valor. Os nomes e o invólucro dos parâmetros devem corresponder aos nomes e invólucros dos parâmetros do procedimento armazenado. |
Não |
| writeBatchSize | Número de linhas a serem inseridas na tabela SQL por lote. O valor permitido é inteiro (número de linhas). Por padrão, o serviço determina dinamicamente o tamanho de lote apropriado com base no tamanho da linha. |
Não |
| writeBatchTimeout | O tempo de espera para que a operação de inserção, upsert e procedimento armazenado seja concluída antes que ele atinja o tempo limite. Os valores permitidos são para o período de tempo. Um exemplo é "00:30:00" por 30 minutos. Se nenhum valor for especificado, o tempo limite será padronizado como "00:30:00". |
Não |
| disableMetricsCollection | O serviço coleta métricas como DTUs do Banco de Dados SQL do Azure para otimização de desempenho de cópia e recomendações, o que introduz acesso adicional ao banco de dados mestre. Se você estiver preocupado com esse comportamento, especifique true para desativá-lo. |
Não (o padrão é false) |
| maxConcurrentConnections | O limite superior de conexões simultâneas estabelecidas para o armazenamento de dados durante a execução da atividade. Especifique um valor somente quando quiser limitar conexões simultâneas. | Não |
| WriteBehavior | Especifique o comportamento de gravação para a atividade de cópia para carregar dados no Banco de Dados SQL do Azure. O valor permitido é Inserir e Upsert. Por padrão, o serviço usa inserir para carregar dados. |
Não |
| upsertSettings | Especifique o grupo de configurações para o comportamento de gravação. Aplique quando a opção WriteBehavior for Upsert. |
Não |
Em upsertSettings: |
||
| useTempDB | Especifique se deseja usar uma tabela temporária global ou uma tabela física como a tabela provisória para upsert. Por padrão, o serviço usa a tabela temporária global como a tabela provisória. valor é true. |
Não |
| interimSchemaName | Especifique o esquema provisório para criar uma tabela provisória se a tabela física for usada. Nota: o usuário precisa ter a permissão para criar e excluir tabela. Por padrão, a tabela provisória compartilhará o mesmo esquema da tabela de coletores. Aplique quando a opção useTempDB for False. |
Não |
| chaves | Especifique os nomes das colunas para identificação de linha exclusiva. Uma única chave ou uma série de chaves podem ser usadas. Se não for especificado, a chave primária será usada. | Não |
Exemplo 1: Acrescentar dados
"activities":[
{
"name": "CopyToAzureSQLDatabase",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<Azure SQL Database output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "AzureSqlSink",
"tableOption": "autoCreate",
"writeBatchSize": 100000
}
}
}
]
Exemplo 2: Invocar um procedimento armazenado durante a cópia
Saiba mais detalhes em Invocar um procedimento armazenado a partir de um coletor SQL.
"activities":[
{
"name": "CopyToAzureSQLDatabase",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<Azure SQL Database output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "AzureSqlSink",
"sqlWriterStoredProcedureName": "CopyTestStoredProcedureWithParameters",
"storedProcedureTableTypeParameterName": "MyTable",
"sqlWriterTableType": "MyTableType",
"storedProcedureParameters": {
"identifier": { "value": "1", "type": "Int" },
"stringData": { "value": "str1" }
}
}
}
}
]
Exemplo 3: Dados Upsert
"activities":[
{
"name": "CopyToAzureSQLDatabase",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<Azure SQL Database output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "AzureSqlSink",
"tableOption": "autoCreate",
"writeBehavior": "upsert",
"upsertSettings": {
"useTempDB": true,
"keys": [
"<column name>"
]
},
}
}
}
]
Cópia paralela do banco de dados SQL
O conector do Banco de Dados SQL do Azure na atividade de cópia fornece particionamento de dados interno para copiar dados em paralelo. Você pode encontrar opções de particionamento de dados na guia Origem da atividade de cópia.
Quando você habilita a cópia particionada, a atividade de cópia executa consultas paralelas na fonte do Banco de Dados SQL do Azure para carregar dados por partições. O grau paralelo é controlado pela parallelCopies configuração na atividade de cópia. Por exemplo, se você definir parallelCopies como quatro, o serviço gerará e executará simultaneamente quatro consultas com base na opção e nas configurações de partição especificadas, e cada consulta recuperará uma parte dos dados do Banco de Dados SQL do Azure.
Sugere-se que habilite a cópia paralela com particionamento de dados, especialmente quando carrega uma grande quantidade de dados do Banco de Dados SQL do Azure. A seguir estão sugeridas configurações para diferentes cenários. Ao copiar dados para o armazenamento de dados baseado em arquivo, é recomendável gravar em uma pasta como vários arquivos (especifique apenas o nome da pasta), caso em que o desempenho é melhor do que gravar em um único arquivo.
| Cenário | Configurações sugeridas |
|---|---|
| Carga completa a partir de uma mesa grande, com divisórias físicas. | Opção de partição: Partições físicas da tabela. Durante a execução, o serviço deteta automaticamente as partições físicas e copia os dados por partições. Para verificar se a sua tabela tem partição física ou não, pode consultar esta consulta. |
| Carga completa a partir de uma tabela grande, sem partições físicas, enquanto com uma coluna inteira ou datetime para particionamento de dados. | Opções de partição: Partição de intervalo dinâmico. Coluna de partição (opcional): especifique a coluna usada para particionar dados. Se não for especificado, o índice ou a coluna de chave primária será usado. Limite superior da partição e limite inferior da partição (opcional): Especifique se deseja determinar o passo da partição. Isso não é para filtrar as linhas na tabela, todas as linhas na tabela serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente os valores. Por exemplo, se a coluna de partição "ID" tiver valores que variam de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com cópia paralela como 4, o serviço recuperará dados por 4 partições - IDs no intervalo <=20, [21, 50], [51, 80] e >=81, respectivamente. |
| Carregue uma grande quantidade de dados usando uma consulta personalizada, sem partições físicas, enquanto com uma coluna inteira ou data/data/hora para particionamento de dados. | Opções de partição: Partição de intervalo dinâmico. Consulta: SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>.Coluna de partição: especifique a coluna usada para particionar dados. Limite superior da partição e limite inferior da partição (opcional): Especifique se deseja determinar o passo da partição. Isso não é para filtrar as linhas na tabela, todas as linhas no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Durante a execução, o serviço substitui ?AdfRangePartitionColumnName pelo nome da coluna real e intervalos de valores para cada partição e envia para o Banco de Dados SQL do Azure. Por exemplo, se a coluna de partição "ID" tiver valores que variam de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com cópia paralela como 4, o serviço recuperará dados por 4 partições - IDs no intervalo <=20, [21, 50], [51, 80] e >=81, respectivamente. Aqui estão mais consultas de exemplo para diferentes cenários: 1. Consulte toda a tabela: SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition2. Consulta a partir de uma tabela com seleção de colunas e filtros adicionais de cláusula where: SELECT <column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>3. Consulta com subconsultas: SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>4. Consulta com partição em subconsulta: SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition) AS T |
Práticas recomendadas para carregar dados com a opção de partição:
- Escolha uma coluna distinta como coluna de partição (como chave primária ou chave exclusiva) para evitar distorção de dados.
- Se a tabela tiver partição incorporada, use a opção de partição "Partições físicas da tabela" para obter um melhor desempenho.
- Se você usar o Tempo de Execução de Integração do Azure para copiar dados, poderá definir "Unidades de Integração de Dados (DIU)" (>4) maiores para utilizar mais recursos de computação. Verifique os cenários aplicáveis lá.
- "Grau de paralelismo de cópia" controlar os números de partição, definir este número muito grande às vezes prejudica o desempenho, recomendo definir este número como (DIU ou número de nós IR auto-hospedados) * (2 a 4).
Exemplo: carga completa a partir de uma mesa grande com partições físicas
"source": {
"type": "AzureSqlSource",
"partitionOption": "PhysicalPartitionsOfTable"
}
Exemplo: consulta com partição de intervalo dinâmico
"source": {
"type": "AzureSqlSource",
"query": "SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>",
"partitionOption": "DynamicRange",
"partitionSettings": {
"partitionColumnName": "<partition_column_name>",
"partitionUpperBound": "<upper_value_of_partition_column (optional) to decide the partition stride, not as data filter>",
"partitionLowerBound": "<lower_value_of_partition_column (optional) to decide the partition stride, not as data filter>"
}
}
Exemplo de consulta para verificar a partição física
SELECT DISTINCT s.name AS SchemaName, t.name AS TableName, pf.name AS PartitionFunctionName, c.name AS ColumnName, iif(pf.name is null, 'no', 'yes') AS HasPartition
FROM sys.tables AS t
LEFT JOIN sys.objects AS o ON t.object_id = o.object_id
LEFT JOIN sys.schemas AS s ON o.schema_id = s.schema_id
LEFT JOIN sys.indexes AS i ON t.object_id = i.object_id
LEFT JOIN sys.index_columns AS ic ON ic.partition_ordinal > 0 AND ic.index_id = i.index_id AND ic.object_id = t.object_id
LEFT JOIN sys.columns AS c ON c.object_id = ic.object_id AND c.column_id = ic.column_id
LEFT JOIN sys.partition_schemes ps ON i.data_space_id = ps.data_space_id
LEFT JOIN sys.partition_functions pf ON pf.function_id = ps.function_id
WHERE s.name='[your schema]' AND t.name = '[your table name]'
Se a tabela tiver partição física, você verá "HasPartition" como "sim" como a seguir.
Práticas recomendadas para carregar dados no Banco de Dados SQL do Azure
Ao copiar dados para o Banco de Dados SQL do Azure, você pode precisar de um comportamento de gravação diferente:
- Acrescentar: Meus dados de origem têm apenas novos registros.
- Upsert: Meus dados de origem têm inserções e atualizações.
- Substituir: Quero recarregar uma tabela de dimensão inteira de cada vez.
- Escrever com lógica personalizada: preciso de processamento extra antes da inserção final na tabela de destino.
Consulte as respetivas seções sobre como configurar no serviço e as práticas recomendadas.
Acrescentar dados
A anexação de dados é o comportamento padrão desse conector de coletor do Banco de Dados SQL do Azure. O serviço faz uma inserção em massa para gravar na sua tabela de forma eficiente. Você pode configurar a origem e o coletor de acordo com a atividade de cópia.
Fazer upsert de dados
A atividade de cópia agora suporta o carregamento nativo de dados em uma tabela temporária de banco de dados e, em seguida, atualize os dados na tabela de coletor se a chave existir e insira novos dados. Para saber mais sobre configurações de upsert em atividades de cópia, consulte Banco de Dados SQL do Azure como coletor.
Substituir a tabela inteira
Você pode configurar a propriedade preCopyScript no coletor de atividade de cópia. Nesse caso, para cada atividade de cópia executada, o serviço executa o script primeiro. Em seguida, ele executa a cópia para inserir os dados. Por exemplo, para substituir a tabela inteira pelos dados mais recentes, especifique um script para primeiro excluir todos os registros antes de carregar em massa os novos dados da fonte.
Gravar dados com lógica personalizada
As etapas para gravar dados com lógica personalizada são semelhantes às descritas na seção Dados Upsert. Quando precisar aplicar processamento extra antes da inserção final dos dados de origem na tabela de destino, você poderá carregar em uma tabela de preparo e, em seguida, invocar a atividade de procedimento armazenado ou invocar um procedimento armazenado no coletor de atividade de cópia para aplicar dados ou usar o Mapeamento de Fluxo de Dados.
Invocar um procedimento armazenado a partir de um coletor SQL
Ao copiar dados para o Banco de Dados SQL do Azure, você também pode configurar e invocar um procedimento armazenado especificado pelo usuário com parâmetros adicionais em cada lote da tabela de origem. O recurso de procedimento armazenado aproveita os parâmetros com valor de tabela.
Você pode usar um procedimento armazenado quando os mecanismos de cópia internos não atendem à finalidade. Um exemplo é quando você deseja aplicar processamento extra antes da inserção final dos dados de origem na tabela de destino. Alguns exemplos de processamento extra são quando você deseja mesclar colunas, procurar valores adicionais e inserir em mais de uma tabela.
O exemplo a seguir mostra como usar um procedimento armazenado para fazer um upsert em uma tabela no Banco de Dados SQL do Azure. Suponha que os dados de entrada e a tabela Marketing do coletor tenham três colunas: ProfileID, State e Category. Faça o upsert com base na coluna ProfileID e aplique-o apenas para uma categoria específica chamada "ProductA".
Em seu banco de dados, defina o tipo de tabela com o mesmo nome de sqlWriterTableType. O esquema do tipo de tabela é o mesmo que o esquema retornado pelos dados de entrada.
CREATE TYPE [dbo].[MarketingType] AS TABLE( [ProfileID] [varchar](256) NOT NULL, [State] [varchar](256) NOT NULL, [Category] [varchar](256) NOT NULL )Em seu banco de dados, defina o procedimento armazenado com o mesmo nome de sqlWriterStoredProcedureName. Ele lida com dados de entrada de sua fonte especificada e mescla na tabela de saída. O nome do parâmetro do tipo de tabela no procedimento armazenado é o mesmo que tableName definido no conjunto de dados.
CREATE PROCEDURE spOverwriteMarketing @Marketing [dbo].[MarketingType] READONLY, @category varchar(256) AS BEGIN MERGE [dbo].[Marketing] AS target USING @Marketing AS source ON (target.ProfileID = source.ProfileID and target.Category = @category) WHEN MATCHED THEN UPDATE SET State = source.State WHEN NOT MATCHED THEN INSERT (ProfileID, State, Category) VALUES (source.ProfileID, source.State, source.Category); ENDNo pipeline do Azure Data Factory ou Synapse, defina a seção do coletor SQL na atividade de cópia da seguinte maneira:
"sink": { "type": "AzureSqlSink", "sqlWriterStoredProcedureName": "spOverwriteMarketing", "storedProcedureTableTypeParameterName": "Marketing", "sqlWriterTableType": "MarketingType", "storedProcedureParameters": { "category": { "value": "ProductA" } } }
Ao gravar dados no Banco de Dados SQL do Azure usando o procedimento armazenado, o coletor divide os dados de origem em minilotes e, em seguida, faz a inserção, para que a consulta extra no procedimento armazenado possa ser executada várias vezes. Se você tiver a consulta para que a atividade de cópia seja executada antes de gravar dados no Banco de Dados SQL do Azure, não é recomendável adicioná-la ao procedimento armazenado, adicione-a na caixa Script Pré-cópia.
Mapeando propriedades de fluxo de dados
Ao transformar dados em mapeamento de fluxo de dados, você pode ler e gravar em tabelas do Banco de Dados SQL do Azure. Para obter mais informações, consulte a transformação de origem e a transformação de coletor no mapeamento de fluxos de dados.
Transformação da fonte
As configurações específicas do Banco de Dados SQL do Azure estão disponíveis na guia Opções de Origem da transformação de origem.
Entrada: selecione se você aponta sua fonte para uma tabela (equivalente a Select * from <table-name>) ou insere uma consulta SQL personalizada.
Consulta: Se você selecionar Consulta no campo de entrada, insira uma consulta SQL para sua fonte. Essa configuração substitui qualquer tabela escolhida no conjunto de dados. As cláusulas Order By não são suportadas aqui, mas você pode definir uma instrução SELECT FROM completa. Você também pode usar funções de tabela definidas pelo usuário. select * from udfGetData() é um UDF em SQL que retorna uma tabela. Essa consulta produzirá uma tabela de origem que você pode usar em seu fluxo de dados. Usar consultas também é uma ótima maneira de reduzir linhas para testes ou pesquisas.
Gorjeta
A expressão de tabela comum (CTE) em SQL não é suportada no modo de consulta de fluxo de dados de mapeamento, porque o pré-requisito de usar esse modo é que as consultas podem ser usadas na cláusula de consulta SQL FROM, mas as CTEs não podem fazer isso. Para usar CTEs, você precisa criar um procedimento armazenado usando a seguinte consulta:
CREATE PROC CTESP @query nvarchar(max)
AS
BEGIN
EXECUTE sp_executesql @query;
END
Em seguida, use o modo Procedimento armazenado na transformação de origem do fluxo de dados de mapeamento e defina o @query exemplo with CTE as (select 'test' as a) select * from CTEsemelhante. Em seguida, você pode usar CTEs conforme o esperado.
Procedimento armazenado: escolha esta opção se desejar gerar uma projeção e dados de origem a partir de um procedimento armazenado executado a partir do banco de dados de origem. Você pode digitar o esquema, o nome do procedimento e os parâmetros ou clicar em Atualizar para solicitar que o serviço descubra os esquemas e os nomes dos procedimentos. Em seguida, você pode clicar em Importar para importar todos os parâmetros do procedimento usando o formulário @paraName.
- Exemplo de SQL:
Select * from MyTable where customerId > 1000 and customerId < 2000 - Exemplo de SQL parametrizado:
"select * from {$tablename} where orderyear > {$year}"
Tamanho do lote: insira um tamanho de lote para fragmentar dados grandes em leituras.
Nível de isolamento: O padrão para fontes SQL no mapeamento do fluxo de dados é ler sem confirmação. Você pode alterar o nível de isolamento aqui para um destes valores:
- Leia Comprometido
- Ler Não Comprometido
- Leitura repetível
- Serializável
- Nenhum (ignorar o nível de isolamento)
Habilitar extração incremental: use esta opção para informar ao ADF para processar apenas linhas que foram alteradas desde a última vez que o pipeline foi executado. Para habilitar a extração incremental com desvio de esquema, escolha tabelas baseadas em colunas Incremental/Marca d'água em vez de tabelas habilitadas para Captura de Dados de Alteração Nativa.
Coluna incremental: Ao usar o recurso de extração incremental, você deve escolher a data/hora ou a coluna numérica que deseja usar como marca d'água na tabela de origem.
Habilitar captura de dados de alteração nativa (Visualização): use esta opção para dizer ao ADF para processar apenas dados delta capturados pela tecnologia de captura de dados de alteração SQL desde a última vez que o pipeline foi executado. Com essa opção, os dados delta, incluindo inserção de linha, atualização e exclusão, serão carregados automaticamente sem a necessidade de qualquer coluna incremental. Você precisa habilitar a captura de dados de alteração no Banco de Dados SQL do Azure antes de usar essa opção no ADF. Para obter mais informações sobre essa opção no ADF, consulte Captura de dados de alteração nativa.
Comece a ler desde o início: definir essa opção com extração incremental instruirá o ADF a ler todas as linhas na primeira execução de um pipeline com a extração incremental ativada.
Transformação do lavatório
As configurações específicas do Banco de Dados SQL do Azure estão disponíveis na guia Configurações da transformação do coletor.
Método de atualização: determina quais operações são permitidas no destino do banco de dados. O padrão é permitir apenas inserções. Para atualizar, atualizar ou excluir linhas, uma transformação de linha de alteração é necessária para marcar linhas para essas ações. Para atualizações, upserts e exclusões, uma coluna ou colunas de chave devem ser definidas para determinar qual linha alterar.
O nome da coluna que você escolher como a chave aqui será usado pelo serviço como parte da atualização subsequente, upsert, excluir. Portanto, você deve escolher uma coluna que existe no mapeamento de coletor. Se desejar não escrever o valor nesta coluna de chave, clique em "Ignorar colunas de chave de escrita".
Você pode parametrizar a coluna de chave usada aqui para atualizar sua tabela de destino do Banco de Dados SQL do Azure. Se você tiver várias colunas para uma chave composta, clique em "Expressão personalizada" e poderá adicionar conteúdo dinâmico usando a linguagem de expressão de fluxo de dados, que pode incluir uma matriz de cadeias de caracteres com nomes de coluna para uma chave composta.
Ação da tabela: determina se todas as linhas da tabela de destino devem ser recriadas ou removidas antes da gravação.
- Nenhuma: Nenhuma ação será feita para a mesa.
- Recriar: A tabela será descartada e recriada. Necessário se criar uma nova tabela dinamicamente.
- Truncate: Todas as linhas da tabela de destino serão removidas.
Tamanho do lote: Controla quantas linhas estão sendo escritas em cada bucket. Lotes maiores melhoram a compactação e a otimização da memória, mas correm o risco de exceções de falta de memória ao armazenar dados em cache.
Usar TempDB: Por padrão, o serviço usará uma tabela temporária global para armazenar dados como parte do processo de carregamento. Como alternativa, você pode desmarcar a opção "Usar TempDB" e, em vez disso, pedir ao serviço para armazenar a tabela de retenção temporária em um banco de dados de usuário localizado no banco de dados que está sendo usado para esse coletor.
Scripts SQL pré e pós: insira scripts SQL de várias linhas que serão executados antes (pré-processamento) e depois que os dados (pós-processamento) forem gravados no banco de dados do Sink
Gorjeta
- Recomenda-se quebrar scripts de lote único com vários comandos em vários lotes.
- Somente instruções DDL (Data Definition Language) e DML (Data Manipulation Language) que retornam uma contagem de atualização simples podem ser executadas como parte de um lote. Saiba mais em Executando operações em lote
Processamento da linha de erro
Ao gravar no Banco de Dados SQL do Azure, determinadas linhas de dados podem falhar devido a restrições definidas pelo destino. Alguns erros comuns:
- Dados binários ou de cadeia de caracteres seriam truncados na tabela
- Não é possível inserir o valor NULL na coluna
- A instrução INSERT entrou em conflito com a restrição CHECK
Por padrão, uma execução de fluxo de dados falhará no primeiro erro que receber. Você pode optar por Continuar no erro que permite que o fluxo de dados seja concluído mesmo que linhas individuais tenham erros. O serviço fornece diferentes opções para você lidar com essas linhas de erro.
Confirmação de transação: escolha se seus dados são gravados em uma única transação ou em lotes. Uma única transação proporcionará um desempenho pior, mas nenhum dado gravado será visível para outras pessoas até que a transação seja concluída.
Dados rejeitados de saída: se habilitado, você pode gerar as linhas de erro em um arquivo csv no Armazenamento de Blobs do Azure ou em uma conta do Azure Data Lake Storage Gen2 de sua escolha. Isso gravará as linhas de erro com três colunas adicionais: a operação SQL como INSERT ou UPDATE, o código de erro de fluxo de dados e a mensagem de erro na linha.
Relatar erro bem-sucedido: Se habilitado, o fluxo de dados será marcado como um sucesso, mesmo se forem encontradas linhas de erro.
Mapeamento de tipo de dados para o Banco de Dados SQL do Azure
Quando os dados são copiados de ou para o Banco de Dados SQL do Azure, os mapeamentos a seguir são usados dos tipos de dados do Banco de Dados SQL do Azure para os tipos de dados provisórios do Azure Data Factory. Os mesmos mapeamentos são usados pelo recurso de pipeline Synapse, que implementa o Azure Data Factory diretamente. Para saber como a atividade de cópia mapeia o esquema de origem e o tipo de dados para o coletor, consulte Mapeamentos de esquema e tipo de dados.
| Tipo de dados do Banco de Dados SQL do Azure | Tipo de dados provisórios do Data Factory |
|---|---|
| bigint | Int64 |
| binário | Byte[] |
| bit | Boolean |
| char | String, Char[] |
| data | DateTime |
| Datetime | DateTime |
| datetime2 | DateTime |
| Datetimeoffset | DateTimeOffset |
| Decimal | Decimal |
| Atributo FILESTREAM (varbinary(max)) | Byte[] |
| Float | Duplo |
| image | Byte[] |
| número inteiro | Int32 |
| dinheiro | Decimal |
| Nchar | String, Char[] |
| ntexto | String, Char[] |
| numérico | Decimal |
| Nvarchar | String, Char[] |
| real | Única |
| versão de linha | Byte[] |
| PequenoDateTime | DateTime |
| smallint | Int16 |
| dinheiro pequeno | Decimal |
| sql_variant | Object |
| texto | String, Char[] |
| hora | TimeSpan |
| carimbo de data/hora | Byte[] |
| tinyint | Byte |
| uniqueidentifier | GUID |
| Varbinary | Byte[] |
| varchar | String, Char[] |
| xml | String |
Nota
Para tipos de dados mapeados para o tipo provisório decimal, atualmente a atividade Copiar suporta precisão de até 28. Se você tiver dados com precisão maior que 28, considere converter em uma cadeia de caracteres na consulta SQL.
Propriedades da atividade de pesquisa
Para saber detalhes sobre as propriedades, verifique Atividade de pesquisa.
Propriedades de atividade GetMetadata
Para saber detalhes sobre as propriedades, verifique a atividade GetMetadata
Usando sempre criptografado
Quando você copia dados de/para o Banco de Dados SQL do Azure com Always Encrypted, siga as etapas abaixo:
Armazene a Chave Mestra de Coluna (CMK) em um Cofre de Chaves do Azure. Saiba mais sobre como configurar o Always Encrypted usando o Azure Key Vault
Certifique-se de obter acesso ao cofre de chaves onde a Chave Mestra de Coluna (CMK) está armazenada. Consulte este artigo para obter as permissões necessárias.
Crie um serviço vinculado para se conectar ao seu banco de dados SQL e habilite a função 'Sempre criptografado' usando a identidade gerenciada ou a entidade de serviço.
Nota
A Base de Dados SQL do Azure Always Encrypted suporta os cenários abaixo:
- Os armazenamentos de dados de origem ou coletor estão usando identidade gerenciada ou entidade de serviço como tipo de autenticação de provedor de chave.
- Os armazenamentos de dados de origem e coletor estão usando a identidade gerenciada como tipo de autenticação do provedor de chaves.
- Os armazenamentos de dados de origem e coletor estão usando a mesma entidade de serviço que o tipo de autenticação do provedor de chaves.
Nota
Atualmente, o Banco de Dados SQL do Azure Always Encrypted só tem suporte para transformação de origem no mapeamento de fluxos de dados.
Captura nativa de dados de alteração
O Azure Data Factory pode dar suporte a recursos nativos de captura de dados de alteração para SQL Server, Banco de Dados SQL do Azure e SQL MI do Azure. Os dados alterados, incluindo inserção de linha, atualização e exclusão em repositórios SQL, podem ser detetados e extraídos automaticamente pelo fluxo de dados de mapeamento do ADF. Com a experiência sem código no mapeamento de fluxo de dados, os usuários podem facilmente obter o cenário de replicação de dados de repositórios SQL anexando um banco de dados como armazenamento de destino. Além disso, os usuários também podem compor qualquer lógica de transformação de dados para obter um cenário de ETL incremental a partir de repositórios SQL.
Certifique-se de manter o pipeline e o nome da atividade inalterados, para que o ponto de verificação possa ser registrado pelo ADF para que você obtenha dados alterados da última execução automaticamente. Se você alterar o nome do pipeline ou o nome da atividade, o ponto de verificação será redefinido, o que leva você a começar do início ou obter alterações a partir de agora na próxima execução. Se você quiser alterar o nome do pipeline ou o nome da atividade, mas ainda assim manter o ponto de verificação para obter dados alterados da última execução automaticamente, use sua própria chave de ponto de verificação na atividade de fluxo de dados para conseguir isso.
Quando você depura o pipeline, esse recurso funciona da mesma forma. Lembre-se de que o ponto de verificação será redefinido quando você atualizar o navegador durante a execução de depuração. Depois de estar satisfeito com o resultado do pipeline da execução de depuração, você pode ir em frente para publicar e acionar o pipeline. No momento em que você aciona pela primeira vez seu pipeline publicado, ele é reiniciado automaticamente desde o início ou recebe alterações a partir de agora.
Na seção de monitoramento, você sempre tem a chance de executar novamente um pipeline. Quando você está fazendo isso, os dados alterados são sempre capturados do ponto de verificação anterior da execução do pipeline selecionado.
Exemplo 1:
Quando você encadeia diretamente uma transformação de origem referenciada ao conjunto de dados habilitado para SQL CDC com uma transformação de coletor referenciada a um banco de dados em um fluxo de dados de mapeamento, as alterações ocorridas na origem SQL serão aplicadas automaticamente ao banco de dados de destino, para que você obtenha facilmente o cenário de replicação de dados entre bancos de dados. Você pode usar o método update na transformação do coletor para selecionar se deseja permitir inserir, permitir atualização ou permitir exclusão no banco de dados de destino. O script de exemplo no mapeamento de fluxo de dados é como abaixo.
source(output(
id as integer,
name as string
),
allowSchemaDrift: true,
validateSchema: false,
enableNativeCdc: true,
netChanges: true,
skipInitialLoad: false,
isolationLevel: 'READ_UNCOMMITTED',
format: 'table') ~> source1
source1 sink(allowSchemaDrift: true,
validateSchema: false,
deletable:true,
insertable:true,
updateable:true,
upsertable:true,
keys:['id'],
format: 'table',
skipDuplicateMapInputs: true,
skipDuplicateMapOutputs: true,
errorHandlingOption: 'stopOnFirstError') ~> sink1
Exemplo 2:
Se quiser habilitar o cenário de ETL em vez da replicação de dados entre bancos de dados via SQL CDC, você pode usar expressões no mapeamento de fluxo de dados, incluindo isInsert(1), isUpdate(1) e isDelete(1) para diferenciar as linhas com diferentes tipos de operação. A seguir está um dos scripts de exemplo para mapear o fluxo de dados na derivação de uma coluna com o valor: 1 para indicar linhas inseridas, 2 para indicar linhas atualizadas e 3 para indicar linhas excluídas para transformações downstream para processar os dados delta.
source(output(
id as integer,
name as string
),
allowSchemaDrift: true,
validateSchema: false,
enableNativeCdc: true,
netChanges: true,
skipInitialLoad: false,
isolationLevel: 'READ_UNCOMMITTED',
format: 'table') ~> source1
source1 derive(operationType = iif(isInsert(1), 1, iif(isUpdate(1), 2, 3))) ~> derivedColumn1
derivedColumn1 sink(allowSchemaDrift: true,
validateSchema: false,
skipDuplicateMapInputs: true,
skipDuplicateMapOutputs: true) ~> sink1
Limitação conhecida:
- Somente as alterações líquidas do SQL CDC serão carregadas pelo ADF via cdc.fn_cdc_get_net_changes_.
Conteúdos relacionados
Para obter uma lista de armazenamentos de dados suportados como fontes e coletores pela atividade de cópia, consulte Formatos e armazenamentos de dados suportados.