Compartilhar via

Declarar transformação no fluxo de dados de mapeamento

  • Artigo

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

Os fluxos de dados estão disponíveis nos pipelines do Azure Data Factory e do Azure Synapse. Este artigo se aplica ao fluxo de dados de mapeamento. Se você for iniciante nas transformações, veja o artigo introdutório Transformar dados usando um fluxo de dados de mapeamento.

A transformação de declaração permite que você crie regras personalizadas dentro de seus fluxos de dados de mapeamento para a qualidade de dados e a validação de dados. Você pode criar regras que determinarão se os valores atendem a um domínio de valor esperado. Além disso, você pode criar regras que verificam a exclusividade da linha. A transformação de declaração ajudará a determinar se cada linha em seus dados atende a um conjunto de critérios. A transformação de declaração também permite que você defina mensagens de erro personalizadas quando as regras de validação de dados não são atendidas.

Tipo de declaração

Configuração

No painel de configuração de transformação da declaração, você escolherá o tipo de declaração, fornecerá um nome exclusivo para a declaração, dará uma descrição opcional e definirá a expressão e o filtro opcional. O painel de pré-visualização de dados indicará quais linhas falharam em suas declarações. Além disso, você pode testar cada marca de linha downstream usando isError() e hasError() para linhas com declarações com falha.

Configurações de declaração

Tipo de declaração

  1. Esperar verdadeiro: o resultado da expressão deve ser avaliado como um resultado booliano verdadeiro. Use isso para validar os intervalos de valores de domínio em seus dados.
  2. Esperar único: defina uma coluna ou uma expressão como uma regra de exclusividade em seus dados. Use isso para marcar linhas duplicadas.
  3. Esperar existente: essa opção só está disponível quando você seleciona um segundo fluxo de entrada. Existe examinará ambos os fluxos e determinará se as linhas existem em ambos com base nas colunas ou nas expressões que você especificou. Para adicionar o segundo fluxo para existir, selecione Additional streams.

Afirmar configuração

Falha no fluxo de dados

Selecione fail data flow se você deseja que sua atividade de fluxo de dados falhe imediatamente assim que a regra de asserção falhar.

ID da declaração

A ID da declaração é uma propriedade na qual você inserirá um nome (cadeia de caracteres) para sua declaração. Você poderá usar o identificador mais adiante no fluxo de dados usando hasError() ou para gerar o código de falha de asserção. As IDs de declaração devem ser exclusivas em cada fluxo de dados.

Descrição da declaração

Insira uma descrição da cadeia de caracteres para sua declaração aqui. Você também pode usar expressões e valores de coluna de contexto de linha aqui.

Filtrar

Filter é uma propriedade opcional em que você pode filtrar a declaração para apenas um subconjunto de linhas com base no valor da expressão.

Expression

Insira uma expressão para avaliação para cada uma de suas asserções. Você pode ter várias asserções para cada transformação de declaração. Cada tipo de declaração requer uma expressão de que o ADF precisará avaliar para testar se a declaração foi aprovada.

Ignorar NULLs

Por padrão, a transformação de declaração incluirá NULLs na avaliação de declaração de linha. Você pode optar por ignorar os valores NULLs com essa propriedade.

Falhas de linha de declaração direta

Quando uma declaração falha, opcionalmente, você pode direcionar essas linhas de erro para um arquivo no Azure usando a guia "Erros" na transformação do coletor. Você também terá uma opção na transformação do coletor para não gerar linhas com falhas de asserção ignorando as linhas de erro.

Exemplos

source(output(
		AddressID as integer,
		AddressLine1 as string,
		AddressLine2 as string,
		City as string,
		StateProvince as string,
		CountryRegion as string,
		PostalCode as string,
		rowguid as string,
		ModifiedDate as timestamp
	),
	allowSchemaDrift: true,
	validateSchema: false,
	isolationLevel: 'READ_UNCOMMITTED',
	format: 'table') ~> source1
source(output(
		CustomerID as integer,
		AddressID as integer,
		AddressType as string,
		rowguid as string,
		ModifiedDate as timestamp
	),
	allowSchemaDrift: true,
	validateSchema: false,
	isolationLevel: 'READ_UNCOMMITTED',
	format: 'table') ~> source2
source1, source2 assert(expectExists(AddressLine1 == AddressLine1, false, 'nonUS', true(), 'only valid for U.S. addresses')) ~> Assert1

Script de fluxo de dados

Exemplos

source1, source2 assert(expectTrue(CountryRegion == 'United States', false, 'nonUS', null, 'only valid for U.S. addresses'),
	expectExists(source1@AddressID == source2@AddressID, false, 'assertExist', StateProvince == 'Washington', toString(source1@AddressID) + ' already exists in Washington'),
	expectUnique(source1@AddressID, false, 'uniqueness', null, toString(source1@AddressID) + ' is not unqiue')) ~> Assert1

Conteúdo relacionado