Criar regras de qualidade de dados

A qualidade dos dados mede a integridade dos dados em uma organização. Você avalia a qualidade dos dados usando índices de qualidade de dados. O Catálogo unificado do Microsoft Purview gera pontuações com base na avaliação dos dados em relação às regras que você define.

As regras de qualidade de dados são diretrizes essenciais que as organizações estabelecem para garantir a precisão, a consistência e a integridade de seus dados. Essas regras ajudam a manter a integridade e a confiabilidade dos dados.

Aqui estão alguns dos principais aspectos das regras de qualidade de dados:

• Precisão: os dados devem representar com precisão as entidades do mundo real. O contexto é importante! Por exemplo, se você estiver armazenando endereços de clientes, verifique se eles correspondem aos locais reais.

• Completude: essa regra identifica dados vazios, nulos ou ausentes. Ele valida que todos os valores estão presentes, embora não necessariamente corretos.

• Conformidade: essa regra garante que os dados sigam os padrões de formatação de dados, como representação de datas, endereços e valores permitidos.

• Consistência: Essa regra verifica se valores diferentes do mesmo registro estão em conformidade com uma determinada regra e se não há contradições. A consistência de dados garante que as mesmas informações sejam representadas uniformemente em diferentes registros. Por exemplo, se você tiver um catálogo de produtos, nomes e descrições consistentes de produtos serão cruciais.

• Pontualidade: Esta regra visa garantir que os dados estejam acessíveis no menor tempo possível. Isso garante que os dados estejam atualizados.

• Exclusividade: essa regra verifica se os valores não são duplicados. Por exemplo, se deve haver apenas um registro por cliente, então não há vários registros para o mesmo cliente. Cada cliente, produto ou transação deve ter um identificador exclusivo.

Ciclo de vida da qualidade dos dados

A criação de regras de qualidade de dados é a sexta etapa no ciclo de vida de qualidade de dados. As etapas anteriores são:

1. Atribua aos usuários permissões de administrador de qualidade de dados no Catálogo unificado para usar todos os recursos de qualidade de dados.
2. Registrar e verificar uma fonte de dados no Mapa de Dados do Microsoft Purview.
3. Adicione seu ativo de dados a um produto de dados.
4. Configure uma conexão de fonte de dados para preparar sua fonte para a avaliação de qualidade de dados.
5. Configure e execute a criação de perfil de dados para um ativo em sua fonte de dados.

Funções necessárias

• Para criar e gerenciar regras de qualidade de dados, os usuários precisam da função de administrador de qualidade de dados.
• Para exibir regras de qualidade existentes, os usuários precisam da função de leitor de qualidade de dados.

Exibir regras de qualidade de dados existentes

1. No Catálogo unificado, selecione Gerenciamento de integridade e, em seguida, selecione Qualidade dos dados.

2. Selecione um domínio de governança e, em seguida, selecione um produto de dados.

3. Selecione um ativo de dados na lista Ativos de dados .

4. Selecione a guia Regras para ver as regras existentes aplicadas ao ativo.

5. Selecione uma regra para navegar pelo histórico de desempenho da regra aplicada ao ativo de dados selecionado.

   

Regras de qualidade de dados disponíveis

A Qualidade de Dados do Microsoft Purview permite a configuração das regras a seguir. Essas regras estão disponíveis prontas para uso e oferecem uma maneira low-code a no-code para medir a qualidade de seus dados.

Regra	Definição
Atualização	Confirma que todos os valores estão atualizados.
Valores exclusivos	Confirma se os valores em uma coluna são exclusivos.
Correspondência de formato de cadeia de caracteres	Confirma se os valores em uma coluna correspondem a um formato específico ou a outros critérios.
Correspondência de tipo de dados	Confirma se os valores em uma coluna correspondem aos requisitos de tipo de dados.
Linhas duplicadas	Verifica se há linhas duplicadas com os mesmos valores em duas ou mais colunas.
Campos vazios/em branco	Procura campos em branco e vazios em uma coluna em que deveria haver valores.
Pesquisa de tabela	Confirma que um valor em uma tabela pode ser localizado na coluna específica de outra tabela.
Personalizados	Crie uma regra personalizada com o construtor de expressões visuais.

Atualização

A regra de atualização verifica se o ativo é atualizado dentro do tempo esperado. O frescor é determinado pela seleção das últimas datas modificadas.

Observação

A pontuação da regra de atualização é 100 (aprovado) ou 0 (reprovado). A regra de atualização não tem suporte para Snowflake, Catálogo do Unity do Azure Databricks, Google BigQuery, Synapse e Microsoft SQL do Azure.

Valores exclusivos

A regra de valores exclusivos afirma que todos os valores na coluna especificada devem ser exclusivos. Todos os valores exclusivos são tratados como aprovado e os valores que não são exclusivos são tratados como falha. Se a regra Campos vazios/em branco não estiver definida na coluna, os valores nulos ou vazios serão ignorados para os fins dessa regra.

Correspondência de formato de cadeia de caracteres

A regra de correspondência de formato verifica se todos os valores na coluna são válidos. Se você não definir a regra Campos vazios/em branco em uma coluna, a regra ignorará valores nulos ou vazios.

Essa regra pode validar cada valor na coluna usando três abordagens diferentes:

1. Enumeração: essa abordagem usa uma lista de valores separados por vírgula. Se o valor avaliado não corresponder a um dos valores listados, ele falhará na verificação ao marcar. Você pode escapar de vírgulas e barras invertidas usando uma barra invertida (\). Portanto, a \, b, c contém dois valores: o primeiro é a , b e o segundo é c.

1. Como Padrão: like(<i>&lt;string&gt;</i> : string, <i>&lt;pattern match&gt;</i> : string) => boolean O padrão é uma cadeia de caracteres à qual a regra corresponde literalmente. As exceções são os seguintes símbolos especiais: _ corresponde a qualquer caractere na entrada (semelhante a . expressões posix regulares) % corresponde a zero ou mais caracteres na entrada (semelhante a .posix expressões regulares). O caractere de escape é . Se um caractere de escape preceder um símbolo especial ou outro caractere de escape, o caractere a seguir será correspondido literalmente. É inválido escapar de qualquer outro caractere.

   • like('icecream', 'ice%') -> true

   

2. Expressão regular: regexMatch(<i>&lt;string&gt;</i> : string, <i>&lt;regex to match&gt;</i> : string) => boolean

   Verifica se a cadeia de caracteres corresponde ao padrão regex fornecido. Use <regex>(aspas invertidas) para corresponder a uma cadeia de caracteres sem escapar.

   • regexMatch('200.50', '(\\d+).(\\d+)') -> true
   • regexMatch('200.50', `(\d+).(\d+)`) -> true

   

Correspondência de tipo de dados

A regra de correspondência de tipo de dados especifica o tipo de dados esperado para a coluna associada. Como o mecanismo de regras é executado em muitas fontes de dados diferentes, ele não pode usar tipos nativos como BIGINT ou VARCHAR. Em vez disso, ele usa seu próprio sistema de tipos e traduz tipos nativos nesse sistema. Essa regra informa ao mecanismo de verificação de qualidade qual de seus tipos internos usar para o tipo nativo. O sistema de tipos de dados vem do sistema de tipos Microsoft Azure Fluxo de Dados usado no Azure Data Factory.

Durante uma verificação de qualidade, o mecanismo testa todos os tipos nativos em relação ao tipo de correspondência de tipo de dados. Se não for possível converter o tipo nativo no tipo de correspondência de tipo de dados, ele tratará essa linha como um erro.

Linhas duplicadas

A regra Linhas duplicadas verifica se a combinação dos valores na coluna é exclusiva para cada linha da tabela.

No exemplo a seguir, a expectativa é que a concatenação de CompanyName, CustomerID,EmailAddress, FirstName e LastName produza um valor exclusivo para todas as linhas da tabela.

Cada ativo pode ter zero ou uma instância dessa regra.

Campos vazios/em branco

A regra Campos vazios/em branco afirma que as colunas identificadas não devem conter nenhum valor nulo. Para cadeias de caracteres, a regra também não permite valores vazios ou somente espaços em branco. Durante uma verificação de qualidade de dados, o mecanismo trata qualquer valor nessa coluna que não seja nulo como correto. Essa regra afeta outras regras, como os Valores exclusivos ou as regras de correspondência de formato . Se você não definir essa regra em uma coluna, essas regras ignorarão automaticamente os valores nulos quando forem executadas nessa coluna. Se você definir essa regra em uma coluna, essas regras examinarão valores nulos ou vazios nessa coluna e os considerarão para fins de pontuação.

Pesquisa de tabela

A regra de pesquisa de tabela examina cada valor na coluna em que você define a regra e a compara com uma tabela de referência. Por exemplo, uma tabela primária tem uma coluna chamada "local" que contém cidades, estados e CEPs no formato "cidade, CEP do estado". Uma tabela de referência chamada "citystate" contém todas as combinações legais de cidades, estados e códigos postais com suporte nos Estados Unidos. O objetivo é comparar todos os locais na coluna atual com relação a essa lista de referência para garantir que apenas combinações legais sejam usadas.

Para configurar essa regra, insira o nome "citystatezip" na caixa de diálogo de ativos de pesquisa. Em seguida, selecione o ativo desejado e a coluna com a qual deseja comparar.

Observação

A tabela de referência ou o ativo de dados deve pertencer ao mesmo domínio de governança. Você não pode comparar um ativo de dados em diferentes domínios de governança.

Regras personalizadas

A regra personalizada permite que você especifique regras que validam linhas com base em um ou mais valores nessa linha. Você pode usar a linguagem de expressão regular, a expressão do Azure Data Factory e a linguagem de expressão SQL para criar regras personalizadas.

Uma regra personalizada tem três partes:

1. Expressão de linha: essa expressão booleana se aplica a cada linha aprovada pela expressão de filtro. Se essa expressão retornar true, a linha passará. Se ela retornar false, a linha falhará.

2. Expressão de filtro: essa condição opcional restringe o conjunto de dados no qual a condição de linha é avaliada. Para ativá-la, marque a caixa de seleção Usar expressão de filtro . Essa expressão retorna um valor booliano. A expressão de filtro se aplica a uma linha e, se retornar true, essa linha será considerada para a regra. Se a expressão de filtro retornar false para essa linha, isso significa que ela é ignorada para os fins dessa regra. O comportamento padrão da expressão de filtro é passar todas as linhas, portanto, se você não especificar uma expressão de filtro, todas as linhas serão consideradas.

3. Expressão nula: verifica como os valores NULL devem ser tratados. Essa expressão retorna um booliano que lida com casos em que há dados ausentes. Se a expressão retornar true, a expressão de linha não será aplicada.

Cada parte da regra funciona de forma semelhante às condições existentes de Qualidade de Dados do Microsoft Purview. Uma regra só será aprovada se a expressão de linha for avaliada como TRUE para o conjunto de dados que corresponde à expressão de filtro e tratar valores ausentes, conforme especificado na expressão nula.

Exemplo: uma regra para garantir que "fareAmount" seja positivo e "tripDistance" seja válido:

• Expressão de linha: tripDistance > 0 AND fareAmount > 0
• Expressão de filtro: paymentType = 'CRD'
• Expressão nula: tripDistance IS NULL

Criar uma regra personalizada

1. No Catálogo unificado, acesse Gerenciamento de> integridadeQualidade de dados.
2. Selecione um domínio de governança, selecione um produto de dados e, em seguida, selecione um ativo de dados.
3. Na guia Regras , selecione Nova regra.

Criar uma regra personalizada usando a expressão do ADF (Azure Data Factory)

1. Para criar a regra usando a expressão regular ou a expressão ADF, selecione Personalizado na lista de opções de regras e selecione Avançar.

2. Adicione o nome e a Descrição da regra e selecione Criar.

   

Exemplos de regras personalizadas

Cenário	Expressões
Valide se state_id é igual a Califórnia e aba_Routing_Number corresponde a um determinado padrão regex e a data de nascimento está dentro de um determinado intervalo	state_id=='California' && regexMatch(toString(aba_Routing_Number), '^((0[0-9])|(1[0-2])|(2[1-9])|(3[0-2])|(6[1-9])|(7[0-2])|80)([0-9]{7})$') && between(dateOfBirth,toDate('1968-12-13'),toDate('2020-12-13'))==true()
Verificar se VendorID é igual a 124	{VendorID}=='124'
Verifique se fare_amount é igual ou maior que 100	{fare_amount} >= "100"
Valide se fare_amount for maior que 100 e tolls_amount não for igual a 100	{fare_amount} >= "100"||{tolls_amount} != "400"
Verificar se a classificação é inferior a 5	Rating < 5
Verifique se o número de dígitos no ano é 4	length(toString(year)) == 4
Compare duas colunas bbToLoanRatio e bankBalance para marcar se seus valores são iguais	compare(variance(toLong(bbToLoanRatio)),variance(toLong(bankBalance)))<0
Verificar se o número de caracteres aparado e concatenado em nome, sobrenome, LoanID,uuid é maior que 20	length(trim(concat(firstName,lastName,LoanID,uuid())))>20
Verifique se aba_Routing_Number corresponde a determinado padrão regex e a data da transação inicial é maior que 12-11-2022, e Disallow-Listed é false e o bankBalance médio é maior que 50000 e state_id é igual a 'Massachusetts', 'Tennessee', 'Dakota do Norte' ou 'Alabama'	regexMatch(toString(aba_Routing_Number), '^((0[0-9])|(1[0-2])|(2[1-9])|(3[0-2])|(6[1-9])|(7[0-2])|80)([0-9]{7})$') && toDate(addDays(toTimestamp(initialTransaction, 'yyyy-MM-dd\'T\'HH:mm:ss'),15))>toDate('2022-11-12') && ({Disallow-Listed}=='false') && avg(toLong(bankBalance))>50000 && (state_id=='Massachusetts' || state_id=='Tennessee ' || state_id=='North Dakota' || state_id=='Alabama')
Valide se aba_Routing_Number corresponde a determinado padrão regex e se dateOfBirth está entre 1968-12-13 e 2020-12-13	regexMatch(toString(aba_Routing_Number), '^((0[0-9])|(1[0-2])|(2[1-9])|(3[0-2])|(6[1-9])|(7[0-2])|80)([0-9]{7})$') && between(dateOfBirth,toDate('1968-12-13'),toDate('2020-12-13'))==true()
Verifique se o número de valores exclusivos em aba_Routing_Number é igual a 1.000.000 e o número de valores exclusivos em EMAIL_ADDR é igual a 1.000.000	approxDistinctCount({aba_Routing_Number})==1000000 && approxDistinctCount({EMAIL_ADDR})==1000000

A expressão de filtro e a expressão de linha são definidas usando a linguagem de expressão do Azure Data Factory, com a linguagem definida aqui. No entanto, nem todas as funções definidas para a linguagem de expressão genérica do ADF estão disponíveis. A lista completa de funções disponíveis está na lista Funções disponível na caixa de diálogo expressão. Não há suporte para as seguintes funções definidas aqui : isDelete, isError, isIgnore, isInsert, isMatch, isUpdate, isUpsert, partitionId, pesquisa em cache e funções Window.

Observação

<regex> (aspas invertidas) pode ser usado em expressões regulares incluídas em regras personalizadas para corresponder à cadeia de caracteres sem escapar caracteres especiais. A linguagem de expressão regular é baseada em Java. Aprenda sobre expressões regulares e Java e entenda os caracteres que precisam ser escapados.

Criar uma regra personalizada usando a expressão SQL

As regras SQL personalizadas na Qualidade de Dados do Microsoft Purview fornecem uma maneira flexível de definir verificações de qualidade de dados usando predicados SQL do Spark. Esse recurso permite que os usuários criem regras diretamente no Spark SQL para cenários avançados de validação. Somente uma expressão de linha é necessária; As expressões FILTER e NULL são opcionais para personalização posterior. Use regras de SQL personalizadas para atender a requisitos de negócios complexos e aprimorar a qualidade dos dados, usando todos os recursos do Spark SQL. As regras SQL personalizadas permitem a validação de dados complexa que pode não ser possível apenas com expressões do ADF. Ao escrever predicados SQL do Spark, você pode atender às necessidades comerciais exclusivas e manter altos padrões de qualidade de dados.

1. Para criar a regra usando a linguagem de expressão SQL, selecione Personalizada (SQL) na lista de opções de regras e selecione Avançar.

2. Adicione o nome e a Descrição da regra e selecione Criar.

   Cenário	Expressões
   Valida padrões de cadeia de caracteres corretos (por exemplo, rateCodeId começando com "1" e numérico) e filtra por tipos de pagamento válidos.	Row: rateCodeId RLIKE '^1[0-9]+$' Filter: paymentType IN ('CRD', 'CSH') Null: rateCodeId IS NULL
   Garante comparações corretas de colunas entre puLocationId e doLocationId, e a tarifa comparada com a distância da viagem.	Row: puLocationId > doLocationId AND fareAmount > tripDistance * 10' Filter: paymentType <> 'CSH'' Null: tripDistance IS NULL
   Verifica se o paymentType está em uma determinada lista (Cartão, Dinheiro), filtrando linhas com base nos valores das tarifas.	Row: paymentType IN ('CRD', 'CSH')' Filter: fareAmount >= 50 Null: paymentType IS NULL
   Garante que a distância esteja dentro de um intervalo inclusivo (5 a 10 milhas) ao lidar com NULL e filtrar por tipos de pagamento válidos.	Row: tripDistance BETWEEN 5 AND 10 Filter: paymentType <> 'CRD' Null: tripDistance IS NULL
   Garante que o conjunto de dados não exceda um valor NULL de 20% para fareAmount.	Row: (SELECT avg(CASE WHEN fareAmount IS NULL THEN 1 ELSE 0 END) FROM nycyellowtaxidelta1BillionPartitioned) < 0.20' Filter: vendorID IN ('VTS', 'CMT')
   Verifica se há pelo menos dois valores de paymentType distintos no conjunto de dados.	Row: (SELECT count(DISTINCT paymentType) FROM nycyellowtaxidelta1BillionPartitioned) >= 2 Filter: vendorID IN ('1', '2')
   Garante que o valor médio da tarifa do conjunto de dados esteja dentro de um intervalo especificado (80 <= avg <= 140).	Row: (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) BETWEEN 80 AND 140 ' Filter: paymentType IN ('CRD', 'CSH')
   Garante que o tripDistance máximo no conjunto de dados seja <= 10 milhas.	Row: (SELECT max(tripDistance) FROM nycyellowtaxidelta1BillionPartitioned) <= 10.0 Filter: vendorID IN ('VTS', 'CMT')
   Garante que o desvio padrão de fareAmount esteja abaixo de um determinado limite (< 30).	Row: (SELECT stddev_samp(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) < 30.0 Filter: vendorID IN ('VTS', 'CMT')
   Garante que o valor médio da tarifa do conjunto de dados esteja dentro do limite especificado (<= 15).	Row: (SELECT percentile_approx(fareAmount, 0.5) FROM nycyellowtaxidelta1BillionPartitioned) <= 15.0 Filter: vendorID IN ('VTS', 'CMT')
   Garante que o vendorId seja exclusivo no conjunto de dados em paymentType específico.	Row: COUNT(1) OVER (PARTITION BY vendorID) = 1 Filter: paymentType IN ('CRD', 'CSH','1', '2') Null: vendorID IS NULL
   Garante que a combinação de puLocationId e doLocationId seja exclusiva no conjunto de dados.	Row: COUNT(1) OVER (PARTITION BY puLocationId, doLocationId) = 1 Filter: paymentType IN ('CRD', 'CSH') Null: puLocationId IS NULL OR doLocationId IS NULL
   Garante que o vendorId seja exclusivo por paymentType.	Row: COUNT(1) OVER (PARTITION BY paymentType, vendorID) = 1 ,Filter: rateCodeId < 25, Null: vendorID IS NULL
   Garante que o tpepPickupDateTime da linha seja maior que um determinado carimbo de data/hora de corte.	Row: tpepPickupDateTime >= TIMESTAMP '2014-01-03 00:00:00' Filter: paymentType IN ('CRD', 'CSG', '1', '2') Null: tpepPickupDateTime IS NULL
   Cada viagem deve ser concluída dentro de 1 hora	Row: (unix_timestamp(tpepDropoffDateTime) - unix_timestamp(tpepPickupDateTime)) <= 3600 Filter: paymentType IN ('CRD', 'CSH', '1', '2') Null: tpepPickupDateTime IS NULL OR tpepDropoffDateTime IS NULL
   Mantém apenas a viagem de tarifa mais alta por local de retirada.	Row: row_number() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1, Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0, Null: fareAmount IS NULL OR puLocationId IS NULL
   Todos empataram com as tarifas mais altas por passe de local de retirada (não apenas o primeiro por row_number).	Row: rank() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1 Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0 Null: fareAmount IS NULL OR puLocationId IS NULL
   A tarifa não deve diminuir ao longo do tempo para cada tipo de pagamento.	Row: fareAmount >= lag(fareAmount) OVER (PARTITION BY paymentType ORDER BY tpepPickupDateTime) Null: tpepPickupDateTime IS NULL OR fareAmount IS NULL
   A tarifa de cada linha dentro de 10 da média do grupo por tipo de pagamento.	Row: abs(fareAmount - avg(fareAmount) OVER (PARTITION BY paymentType)) <= 10 Filter: paymentType IN ('CRD', 'CSH','1','2') Null: fareAmount IS NULL
   O total das distâncias da viagem não deve exceder 20 milhas.	Row: sum(tripDistance) OVER (ORDER BY tpepPickupDateTime ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) <= 20 Filter: paymentType = '1' Null: tripDistance IS NULL
   Verifica se a tarifa de cada viagem está acima da média global para fornecedores qualificados.	Row: fareAmount > (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) Filter: vendorID IN ('VTS', 'CMT') Null: fareAmount IS NULL
   Verifica se o tripDistance de cada linha é maior que o mínimo para seu paymentType (Cartão/Dinheiro).	Row: tripDistance > (SELECT min(u.tripDistance) FROM (SELECT tripDistance, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD', 'CSH') Null: tripDistance IS NULL
   Para cada viagem, verifica se a tarifa está acima da média para seu tipo de pagamento	Row: fareAmount > (SELECT avg(u.fareAmount) FROM (SELECT fareAmount, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD','CSH','1','2') AND vendorID IN ('VTS','CMT') Null: fareAmount IS NULL
   Valida se a coluna fareAmount (numérica) pode ser representada corretamente como uma cadeia de caracteres correspondente ao padrão numérico (números positivos com decimais opcionais). Isso usa a conversão, pois fareAmount é uma coluna numérica.	Row: CAST(fareAmount AS STRING) RLIKE '^[0-9]+(\.[0-9]+)?$' Filter: paymentType IN ('CRD', 'CSH') Null: fareAmount IS NULL
   Garante que o tpepPickupDateTime seja um carimbo de data/hora válido no formato aaaa-MM-dd HH:mm:ss. Esta coluna já está no formato DATETIME	Row: to_timestamp(tpepPickupDateTime, 'yyyy-MM-dd HH:mm:ss') IS NOT NULL Filter: paymentType IN ('CRD', 'CSH') Null: tpepPickupDateTime IS NULL
   Garante que os valores paymentType sejam normalizados para minúsculas e não tenham espaços à direita ou à esquerda.	Row: lower(trim(paymentType)) IN ('card','cash') AND length(trim(paymentType)) > 0 Null: paymentType IS NULL OR trim(paymentType) = ''
   Calcula com segurança a proporção de fareAmount para tripDistance, garantindo que a divisão por zero não ocorra verificando primeiro se tripDistance > é 0.	Row: CASE WHEN tripDistance > 0 THEN fareAmount / tripDistance ELSE NULL END >= 10 Filter: tripDistance > 0 AND vendorID IN ('VTS', 'CMT')
   Demonstra como a coalescência pode substituir valores nulos por valores padrão (por exemplo, 0,0) e garante que apenas linhas válidas sejam retornadas.	Row: coalesce(fareAmount, 0.0) >= 5 Filter: paymentType IN ('CRD','CSH')

Práticas recomendadas para escrever regras SQL personalizadas

• Mantenha as expressões simples. Procure escrever expressões claras, diretas e fáceis de manter.
• Use funções internas do Spark SQL. Use a avançada biblioteca de funções do Spark SQL para manipulação de cadeia de caracteres, tratamento de data e operações numéricas para minimizar erros e melhorar o desempenho.
• Teste com um conjunto de dados pequeno primeiro. Valide regras em um conjunto de dados pequeno antes de aplicá-las em escala para identificar possíveis problemas antecipadamente.

Limitações e considerações conhecidas para regras de expressões SQL

Referências de coluna ambíguas e sombreamento de coluna

• Problema: quando uma coluna aparece na consulta externa e na subconsulta (ou em diferentes partes da consulta) com o mesmo nome, o Spark SQL pode não conseguir resolver qual coluna usar. Esse problema resulta em erros lógicos ou na execução incorreta da consulta. Esse problema pode surgir em consultas aninhadas, subconsultas ou junções, levando a ambiguidade ou sombreamento.

• Ambiguidade: ocorre quando um nome de coluna está presente na consulta externa e na subconsulta sem qualificação clara, fazendo com que o Spark SQL não tenha certeza sobre qual coluna referenciar.

• Sombreamento: refere-se a quando uma coluna na consulta externa é "substituída" ou "sombreada" pela mesma coluna na subconsulta, fazendo com que a referência externa seja ignorada.

  Expressão de exemplo:

  distance_km > 
  ( 
  SELECT min(distance_km) 
  FROM Tripdata t  
  WHERE t.payment_type = payment_type -- ambiguous outer reference  
  )
  

• Problema: o payment_type não qualificado é resolvido para o escopo mais próximo que tem uma coluna com esse nome, ou seja, o t.payment_type interno, não o payment_type da linha externa. Isso transforma o predicado em t.payment_type = t.payment_type (sempre TRUE), para que sua subconsulta se torne um min global em vez de um min de grupo.

• Solução: para resolve essa ambiguidade e evitar o sombreamento de coluna, renomeie a coluna interna na subconsulta, garantindo que o payment_type da consulta externa permaneça inequívoco.

Expressão corrigida:

  distance_km > 
  ( 
  SELECT min(u.distance_km) 
  FROM ( 
  SELECT distance_km, payment_type AS pt 
  FROM Tripdata 
  ) u 
   WHERE u.pt = payment_type   -- this `payment_type` now binds to OUTER row 
  )

• Na subconsulta, a coluna payment_type tem o alias de pt (ou seja, payment_type AS pt) e you.pt é usado na condição.
• Na consulta externa, o payment_type original agora pode ser claramente referenciado e o Spark SQL o resolve corretamente como o payment_type externo.

Operações de janela (consideração de desempenho)

• Operações de janela como ROW_NUMBER() e RANK() podem ser caras, especialmente para grandes conjuntos de dados. Use-os criteriosamente e teste o desempenho em conjuntos de dados menores antes de aplicá-los em escala. Considere o uso de PARTITION BY para reduzir o escopo dos dados.

Escape de nome de coluna no Spark SQL

• Se os nomes das colunas contiverem caracteres especiais (como espaços, hífens ou outros caracteres não alfanuméricos), eles deverão ser evitados com acentos graves.
• Exemplo se o nome da coluna for order-id e a regra precisar ser maior que 10.
• Expressão incorreta: order-id > 10
• Expressão correta: `order-id`> 10

Referência de nome de ativo de dados em expressões

Ao referenciar seu ativo de dados em expressões SQL, você precisa seguir regras específicas de limpeza. O nome original do ativo de dados não precisa ser atualizado, mas o nome do ativo de dados referenciado em expressões SQL deve ser limpo para atender aos seguintes critérios:

Regra	Descrição	Exemplo - Nome Original	Exemplo - Nome limpo
Caracteres permitidos	Somente letras (A-Z, a-z), números (0-9) e sublinhados (_) são permitidos. Caracteres especiais (espaços, hifens, pontos etc.) devem ser removidos.	dataset_v1 de nove+2023	mydataset_v12023
Cortar sublinhados	Os sublinhados no início ou no final do nome devem ser removidos.	my_dataset_	my_dataset
Limite de caracteres	O nome final limpo não deve exceder 64 caracteres.	[Um nome longo que excede 64 caracteres]	[Os primeiros 64 caracteres do nome higienizado]

Se o nome do ativo de dados já seguir essas diretrizes (ou seja, não contiver caracteres especiais, sublinhados à direita/esquerda e estiver dentro do limite de 64 caracteres), ele poderá ser usado no estado em que se encontra em suas expressões SQL sem nenhuma modificação.

Como limpar um nome de conjunto de dados

Siga estas etapas para garantir que o nome do conjunto de dados seja válido para expressões SQL:

1. Remover caracteres especiais: remova todos os caracteres, exceto letras, números e sublinhados.
2. Cortar sublinhados: remova todos os sublinhados à direita ou à esquerda.
3. Truncate: se o nome resultante exceder 64 caracteres, trunce-o para caber dentro do limite de 64 caracteres.

Exemplo: Nome do ativo de dados f07d724d-82c9-4c75-97c4-c5baf2cd12a4.parquet

1. Remover caracteres especiais: f07d724d82c94c7597c4c5baf2cd12a4parquet
2. Cortar sublinhados: (N/A neste caso, pois não há sublinhados à esquerda ou à direita.)
3. Truncate: o nome resultante tem 54 caracteres, o que está abaixo do limite de 64 caracteres.

Nome de referência SQL final: f07d724d82c94c7597c4c5baf2cd12a4parquet

Observação

O nome original do ativo de dados permanece inalterado. Somente o nome do ativo de dados usado nas expressões SQL precisa seguir essas regras. Para nomes de coluna que contêm caracteres especiais, como espaços ou hifens, você pode escapar deles usando aspas invertidas em expressões SQL.

Não há suporte para junções

As regras SQL personalizadas na Qualidade de Dados do Microsoft Purview não dão suporte a junções. As regras devem operar em um único conjunto de dados. Você não pode unir várias tabelas ou conjuntos de dados ao escrever essas regras personalizadas.

Operações SQL sem suporte (DML, DCL e SQL prejudicial)

As regras de SQL personalizadas não dão suporte a operações DML (Linguagem de Manipulação de Dados) ou DCL (Linguagem de Controle de Dados), como INSERT, UPDATE, DELETE, GRANT e outras operações SQL prejudiciais, como TRUNCATE, DROP e ALTER. Não há suporte para essas operações porque modificam os dados ou o estado do banco de dados.

Regras geradas automaticamente assistidas por IA

A geração automatizada de regras assistida por IA para medição da qualidade dos dados usa técnicas de inteligência artificial (IA) para criar automaticamente regras para avaliar e melhorar a qualidade dos dados. As regras geradas automaticamente são específicas do conteúdo. A maioria das regras comuns é gerada automaticamente para que você não precise se esforçar muito para criar regras personalizadas.

Para procurar e aplicar regras geradas automaticamente:

1. Na guia Regras de um ativo de dados, selecione Sugerir regras.

2. Navegue pela lista de regras sugeridas.

   

3. Selecione regras na lista de regras sugeridas a serem aplicadas ao ativo de dados.

   

Limitação

Você pode aplicar no máximo 200 regras de qualidade de dados por ativo de dados para uma verificação de qualidade de dados. A verificação falhará se mais de 200 regras estiverem ativas para um único ativo. Se você precisar definir mais de 200 regras para um ativo de dados, elas poderão fazer isso, mas somente até 200 regras podem estar em um estado ativo (ON) a qualquer momento.

Para contornar esse limite:

• Adicione o mesmo ativo de dados a vários produtos de dados para distribuir regras entre eles.
• Ative e desative regras conforme necessário para garantir que não haja mais de 200 regras ativas ao mesmo tempo.

Próximas etapas

1. Configure e execute uma verificação de qualidade de dados em um produto de dados para avaliar a qualidade de todos os ativos com suporte no produto de dados.
2. Examine os resultados da verificação para avaliar a qualidade atual dos dados do seu produto de dados.