Novas funções e operadores de string no Fabric Data Warehouse (Preview)
TL;DR: Fabric Data Warehouse agora oferece funções de busca aproximada (fuzzy matching) — EDIT_DISTANCE, EDIT_DISTANCE_SIMILARITY, JARO_WINKLER_DISTANCE, JARO_WINKLER_SIMILARITY — e operadores modernos (||, ||=, UNISTR). Para empresas brasileiras, isso significa detectar variações de nomes, endereços e dados cadastrais diretamente no T-SQL, reduzindo pipelines externos e acelerando projetos de deduplicação e integração de dados.
Por que isso importa para quem lida com dados reais?
Dados do mundo real são imprevisíveis. Em cadastros de clientes brasileiros, é comum o nome "Ana Maria" aparecer como "Ana-Maria", "Ana maria" ou "Ana Maria Silva". Cidades como "São Paulo" viram "Sao Paulo", " S.Paulo" ou "SAO PAULO". Endereços, nomes de produtos e categorias sofrem do mesmo problema. Essas diferenças tornam buscas exatas (WHERE nome = 'Ana Maria') ineficazes para tarefas como deduplicação, enriquecimento de dados ou análise de similaridade.
O Fabric Data Warehouse ataca esse problema com funções nativas de comparação aproximada de strings. Não é preciso mais extrair dados para um job Python, usar bibliotecas externas ou configurar pipelines complexos de limpeza. A lógica de matching pode ser aplicada diretamente na consulta T-SQL.
Como as novas funções funcionam na prática?
A Microsoft disponibilizou quatro funções principais, divididas em dois grupos:
| Função | Objetivo | Uso típico |
|---|---|---|
EDIT_DISTANCE |
Mede quantas edições (inserção, remoção, substituição) separam duas strings | Encontrar o 'custo' de transformar uma string em outra |
EDIT_DISTANCE_SIMILARITY |
Retorna um score normalizado (0 a 1) de similaridade baseado em edit distance | Filtrar ou ranquear candidatos a match com threshold |
JARO_WINKLER_DISTANCE |
Mede distância baseada em trocas de caracteres, com peso extra para prefixos comuns | Comparação de nomes próprios, onde o começo da palavra é mais relevante |
JARO_WINKLER_SIMILARITY |
Versão normalizada da distância Jaro-Winkler | Ideal para agrupar variações de um mesmo nome (ex.: "Philip" vs "Phillip") |
Além disso, o Fabric Data Warehouse agora suporta:
- Operador
||: Concatenação de strings no estilo ANSI SQL, mais legível e portável entre bancos (útil para quem migra de PostgreSQL ou MySQL). - Operador
||=: Concatenação direta em variáveis, simplificando scripts de stored procedures. - Função
UNISTR: Permite usar sequências de escape Unicode em strings, essencial para trabalhar com caracteres acentuados, símbolos e textos internacionais sem depender de collation.
Exemplo real: detectando variações de nomes de cidades em notas fiscais
Suponha que você tenha uma tabela de invoices com city names inconsistentes — "Hongkong", "Hong-Kong", "Hong Kong". Antes, você precisaria de uma lógica complexa ou de uma ferramenta externa. Agora:
SELECT city, COUNT(*)
FROM invoices
WHERE EDIT_DISTANCE(city, 'Hong Kong') <= 2
GROUP BY city;
Isso retorna todas as variações que estão a até 2 edições de "Hong Kong", agrupando-as. O mesmo padrão se aplica a dados brasileiros: EDIT_DISTANCE(cidade_cliente, 'São Paulo') <= 2 capturaria "Sao Paulo", "S Paulo", "São Paulo" e similares.
E para identificar potenciais duplicatas?
Use JARO_WINKLER_SIMILARITY com um threshold:
SELECT *
FROM clientes
WHERE JARO_WINKLER_SIMILARITY(nome, 'João Silva') > 0.90;
Isso pode revelar registros como "João Silva", "João SIlva" ou "Joao Silva", ajudando na limpeza e na unificação de bases.
O que muda no dia a dia do time de dados?
- Menos pipelines de limpeza: a lógica de fuzzy matching fica no SQL, reduzindo dependência de camadas externas (Python, Spark, ferramentas de ETL).
- Consultas mais expressivas: operadores
||e||=tornam o código T-SQL mais limpo e portável entre bancos. - Suporte a Unicode nativo: com
UNISTR, caracteres acentuados e símbolos são tratados de forma explícita, evitando surpresas com charset. - Portabilidade: desenvolvedores que vêm de outros bancos (PostgreSQL, MySQL) encontram um ambiente mais familiar.
No entanto, fique atento: as funções estão em preview. Antes de usar em produção, vale testar a performance com datasets reais — especialmente EDIT_DISTANCE, que pode ser custosa em tabelas muito grandes se aplicada sem filtros.
Impacto para empresas brasileiras
Para times de dados no Brasil, essa atualização é especialmente relevante. Dados cadastrais brasileiros são notoriamente inconsistentes — nomes com acentos, abreviações, variações regionais ("Rio de Janeiro" vs "Rio", "RJ") e erros de digitação. Ter funções de approximate string matching diretamente no warehouse reduz a fricção de projetos de:
- Deduplicação de clientes (CRM, bases legadas, importação de terceiros)
- Integração de dados (fusão de bases de diferentes sistemas)
- Análise de localização (cidades, bairros, endereços)
- Enriquecimento de dados (correção automática baseada em similaridade)
Em vez de construir um pipeline complexo com Python + Spark + bibliotecas de fuzzy matching, você pode começar com uma simples consulta SQL. Claro, para volumes muito grandes ou matching multi-campo, uma solução dedicada ainda faz sentido — mas para 80% dos casos, as novas funções já resolvem.
Próximos passos
Teste as funções em seu ambiente Fabric Data Warehouse (em preview). Comece com um caso real: pegue uma tabela com nomes de clientes ou cidades e experimente EDIT_DISTANCE_SIMILARITY com thresholds de 0.8 a 0.95. Compare os resultados com sua base tratada. Se encontrar variações que seu pipeline atual não captura, isso é um sinal de que as novas funções podem reduzir retrabalho.
Para mais detalhes, consulte a documentação oficial:
- EDIT_DISTANCE (Transact-SQL)
- EDIT_DISTANCE_SIMILARITY (Transact-SQL)
- JARO_WINKLER_DISTANCE (Transact-SQL)
- JARO_WINKLER_SIMILARITY (Transact-SQL)
- || operator (Transact-SQL)
- ||= operator (Transact-SQL)
- UNISTR (Transact-SQL)
Perguntas Frequentes
-
Qual a vantagem prática do EDIT_DISTANCE para empresas brasileiras?
Empresas brasileiras lidam frequentemente com dados cadastrais inconsistentes — 'Maria de Souza' vs 'Maria Souza', ou 'Belo Horizonte' vs 'B. Horizonte'. O EDIT_DISTANCE permite encontrar essas variações com uma simples consulta T-SQL, sem precisar carregar dados para ferramentas externas de ETL ou bibliotecas Python. -
O UNISTR resolve problemas de caracteres acentuados no SQL?
Sim. O UNISTR permite escrever strings Unicode usando sequências de escape. Na prática, você pode representar caracteres como 'ã' (\u00E3) ou 'ç' (\u00E7) de forma explícita no código T-SQL, evitando problemas de collation e encoding que são comuns em ambientes com dados em português. -
Essas funções substituem o uso de Python ou Spark para fuzzy matching?
Não completamente. Para datasets muito grandes ou lógicas complexas com múltiplos campos, Python/Spark continuam sendo mais flexíveis. Mas para consultas ad-hoc, validação em tempo real e pipelines leves, as novas funções eliminam a necessidade de orquestrar um job externo — ganho de simplicidade e latência. -
Essas funções já estão disponíveis em produção ou ainda em preview?
Estão em preview. Microsoft recomenda testar em ambientes de desenvolvimento e compartilhar feedback. Em produção, é prudente validar o comportamento com dados reais antes de usar em consultas críticas, especialmente em relação a performance com tabelas grandes.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
