Algoritmo Paralelo e Eficiente para o Problema de ... · ALGORITMO PARALELO E EFICIENTE PARA O PROBLEMA DE PAREAMENTO DE DADOS Dissertac~ao apresentada ao Programa de P os-Gradua˘c~ao

ALGORITMO PARALELO E EFICIENTE PARA

O PROBLEMA DE PAREAMENTO DE DADOS

WALTER DOS SANTOS FILHO

ALGORITMO PARALELO E EFICIENTE PARA

O PROBLEMA DE PAREAMENTO DE DADOS

Dissertação apresentada ao Programa dePós-Graduação em Ciência da Computaçãodo Instituto de Ciências Exatas da Univer-sidade Federal de Minas Gerais como req-uisito parcial para a obtenção do grau deMestre em Ciência da Computação.

Orientador: Wagner Meira Junior

Belo Horizonte

Abril de 2008

c© 2008, Walter dos Santos Filho.Todos os direitos reservados.

Santos Filho, Walter dosS237a Algoritmo Paralelo e Eficiente para o Problema de

Pareamento de Dados / Walter dos Santos Filho. —Belo Horizonte, 2008

xxiv, 78 f. : il. ; 29cm

Dissertação (mestrado) — Universidade Federal deMinas Gerais

Orientador: Wagner Meira Junior

1. Pareamento de Registros - Teses. 2. Deduplicação- Teses. 3. Paralelismo - Teses. 4. Algoritmo - Teses.I. Orientador. II T́ıtulo.

CDU 519.6*73(043)

Aos meus pais, à minha esposa e à minha famı́lia, pilares da minha vida

vii

Agradecimentos

Talvez mesmo antes de imaginar o que um dia seria minha dissertação de mestrado, eu

já pensava nesta seção. Aqui é posśıvel relembrar pessoas que me ajudaram na vida

pessoal, acadêmica e profissional. Gostaria que soubessem que se alcancei este sonho,

muito devo a elas.

Primeiramente, agradeço a Deus que sempre me deu forças quando precisei e me

deu um lar e possibilidades de ser feliz.

Agradecer minha famı́lia me emociona sempre. Obrigado minha mãe, Geralda e

meu pai Walter (de quem ainda sinto muita falta). O amor de vocês foi a maior riqueza

que tive. Obrigado às minhas irmãs, Elóısa e Sônia, que foram para mim meu horizonte

acadêmico e profissional. À Diane, minha esposa, que sempre entendeu minha ausência

em alguns momentos, pois ela me compreendia e sabia deste sonho. Obrigado aos meus

sobrinhos, Kelly, Jean, Karen e Eric, que me propiciam momentos de diversão, afinal,

para ser sério, é preciso se divertir.

Gostaria de agradecer aos mestres que estiveram ao meu lado ao longo de toda

minha vida de estudante. Obrigado à Marilene que um dia acreditou que eu poderia

ser mais do que eu era. Obrigado ao meu orientador e amigo Wagner Meira, pessoa

fantástica em sua inteligência e em querer o bem-estar e desenvolvimento de todos. Se

eu tiver que nomear alguém que faz o mundo dar um passo à frente, esse alguém é você,

Meira. Obrigado à minha co-orientadora, Carla, por seu apoio e eterna gentileza. Obri-

gado à Eliane e à Prefeitura Municipal de Belo Horizonte, por terem disponibilizado a

base de dados usada nesse trabalho. Obrigado ao Altigran, que mesmo distante, nos

ajudou a traçar os rumos de minha dissertação. Obrigado à Mariângela, Augusto e

Odilon, do GPES/Faculdade de Medicina da UFMG.

Obrigado aos professores Renato e Dorgival, especialmente pela ajuda nos artigos

e discussões sobre meu trabalho. Obrigado também ao professor Antônio Alfredo por

sua ajuda ao longo da graduação.

Não há como eu retribuir a ajuda dos amigos Adriano César e Leonardo de

Araújo na realização deste momento. Obrigado a vocês pelos momentos de conv́ıvio e

ix

por acreditarem em mim. Obrigado aos amigos do Speed: Elisa, Fernando Henrique,

Leonardo Rocha, Gustavo Orair, Tiago Macambira, Adriano Veloso, Hélio, Arlei, Car-

los e especialmente Thiago Teixeira e Charles Gonçalves pela ajuda e companheirismo

no desenvolvimento de nossas pesquisas, ao Bruno Coutinho e George pela ajuda com

o Anthill e pelo SBAC e finalmente ao André (Hawks) por sua ajuda principalmente

no Estágio em Docência.

Obrigado novamente ao Leonardo de Araújo, a Rafael Paiva e a Rodrigo Mor-

eira por permitirem que eu me ausentasse da nossa empresa para que eu alcançasse o

mestrado.

Obrigado àqueles que acreditaram que este dia chegaria e torceram por mim:

pessoal da Grad972, Renato Maia, Eduardo Ostos, Gracielle Ferraz.

A todos vocês, meu mais sincero agradecimento e voto de felicidades.

x

Resumo

Em um mundo onde cada vez mais a informação se torna importante, contar com bases

de dados confiáveis e consistentes é requisito essencial para tomada de decisão, análise

de tendências, detecção de fraudes, mineração de dados, suporte a clientes, inteligência

de negócio entre outros. Uma das formas de melhorar a qualidade dos dados é eliminar

réplicas e consolidar a informação.

Neste trabalho, apresentamos a ferramenta chamada FERAPARDA (FERra-

menta de Apoio ao PAReamento de DAdos). Ela permite combinar informação de

várias bases de dados por meio do pareamento probabiĺıstico de registros. O processo

de pareamento se baseia na construção e comparação de pares registros, comparando

nomes, endereços e outros atributos que geralmente não serviriam como identificadores

individuais e na classificação probabiĺıstica do resultado.

Não é raro encontrarmos bases com milhares senão milhões de registros, onde os

dados podem apresentar problemas como ausência, inconsistência, erros de entrada ou

mesmo duplicidade de informação. Tais problemas e a quantidade de registros obrigam

a comparação de muitos pares (no pior caso, quadrático em relação ao tamanho da

base), algo que torna o processo muito demorado para ser executado em um único

computador. Geralmente, o processo de pareamento de registros é executado mais

de uma vez com seus parâmetros sendo ajustados a cada execução, uma vez que car-

acteŕısticas da base de dados podem tornar dif́ıcil a decisão sobre o resultado. Um

exemplo são bases de dados onde nomes de pessoas ocorrem com grande freqüência ou

ainda situações onde é muito dif́ıcil diferenciar se dois registros dizem respeito à mesma

pessoa, como é o caso de gêmeos.

Existem muitas ferramentas que realizam o pareamento probabiĺıstico de reg-

istros. No entanto, poucos trabalhos discutem a paralelização do processo, que se

torna ainda mais necessária quando lidamos com bases de dados reais. Para diminuir o

tempo de processamento, estudamos neste trabalho formas de paralelizar o algoritmo

de pareamento de registro. Apresentamos e discutimos cada etapa do processo de

pareamento e como ele foi paralelizado. Conseguimos com sucesso implementar uma

xi

solução capaz de escalar bem quando executada em um cluster de computadores.

Neste trabalho também discutimos diferentes aspectos do paralelismo aplicados

ao problema e também como a localidade de referência pode ser explorada a fim de

maximizar o desempenho e escala da implementação, sem no entanto demandar uma

grande quantidade de recursos, especialmente memória principal. Mostramos como o

uso de cache de comunicação é fundamental para a escalabilidade e como uma das

etapas - a blocagem - tem importância direta neste resultado.

Esperamos que a ferramenta FERAPARDA possa ser usada em diferentes bases

de dados, desde bases comerciais até bases da saúde e de programas sociais a fim de

melhorar a qualidade da informação e melhorar a qualidade dos serviços que se baseiam

em tal informação.

xii

Abstract

In a world where the information is becoming more important each day, the availability

of reliable and consistent databases is essential for decision-making, trend analysis,

fraud detection, data mining, customer support, and business intelligence, among other

data-intensive applications. In order to sustain data quality standards, it is frequently

necessary to discard replicas and consolidate the information.

In this work we introduce a tool named FERAPARDA (from the Portuguese

acronym for “tool for record linkage”). It allows the combination of information from

several sources through probabilistic record linkage. The linkage process is based on

building and comparing pairs of records in a per attribute basis, that is, matching

names, addresses and other attributes that are not unique identifiers, and finding repli-

cas probabilistically.

Large databases containing thousands and even millions of records are quite com-

mon, and they usually present several problems such as missing and inconsistent data,

input errors or even replicated information. These problems and the database size re-

sult in a need for comparing a large number of pairs of records (presenting a quadratic

complexity in the worst case), making the process laborious and time-consuming for

the execution in a single machine. Generally, the linkage process is calibrated itera-

tively, as a consequence of database characteristics, such as very frequent names or

challenging pseudo-replicas, such as records from twins.

There are several tools that perform probabilistic linkage of records. However,

few efforts discuss the process parallelization, what is even more importante for real

datasets. In order to reduce the execution time, we discuss parallelization strategies of

the record linkage algorithm. We present and discuss each step in the linkage process

and how it was parallelized. We were succesful in the sense that our solution scales

well in computing clusters.

This work also discusses various parallelization issues applied to the problem and

how the reference locality may be exploited towards maximizing performance without

requiring a large amount of resources, in particular memory. We show that the usage

xiii

of a communication cache is key for the scalability of the algorithm and how one of the

linkage steps, blocking, is fundamental in this work.

We believe that FERAPARDA is capable of performing the linkage of various

databases, from commercial to health records, enhancing the quality of the data and

the services that are based on that information.

xiv

Lista de Figuras

1.1 Cenário de Armazéns de Dados onde diferentes bases devem ser consolidadas 2

2.1 O processo de pareamento de registros . . . . . . . . . . . . . . . . . . . . 7

2.2 Geração de pares na blocagem . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Faixas de classificação dos pares comparados . . . . . . . . . . . . . . . . . 10

2.4 Faixas de classificação dos pares comparados . . . . . . . . . . . . . . . . . 11

4.1 Abstração filtro-fluxo do Anthill . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Uso de fluxos rotulados para especificar instância do filtro . . . . . . . . . 21

4.3 Pareamento de registro na visão de filtros lógicos . . . . . . . . . . . . . . 22

4.4 Visão de implementação dos filtros . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Avaliação de speedup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Mensagens trocadas entre filtros . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Quantidade de cada tipo de mensagem que originou comparação de registro 37

5.4 Balanceamento de carga considerando pares comparados . . . . . . . . . . 38

6.1 Distância de pilha para os traces original e modificado . . . . . . . . . . . 43

6.2 Referência espacial em um grafo representando pares candidatos . . . . . . 46

6.3 Seqüências únicas nos traces original e modificado . . . . . . . . . . . . . . 49

7.1 Tempo de execução para estratégias utilizando-se o registro menos recen-

temente lido (1) e registro mais recentemente lido (2) para a decisão do

encaminhamento da mensagem, variando-se tamanho da cache (com 4 in-

stâncias do do filtro Reader). . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Tempo de execução para estratégias utilizando-se o registro menos recen-

temente lido (1) e registro mais recentemente lido (2) para a decisão do

encaminhamento da mensagem, variando-se tamanho da cache (com 8 in-

stâncias do do filtro Reader). . . . . . . . . . . . . . . . . . . . . . . . . . . 54

xv

7.3 Total de registros enviados entre instâncias do filtro Comparator variando-se

tamanho da cache, 2 e 4 instâncias do filtro Reader . . . . . . . . . . . . . 55


tamanho da cache, 6 e 8 instâncias do filtro Reader . . . . . . . . . . . . . 56


tamanho da cache, 10 e 12 instâncias do filtro Reader . . . . . . . . . . . . 57

7.6 Comparação do tempo de execução do algoritmo quando utilizando-se a a

heuŕıstica versus utilizando maior identificador de registro . . . . . . . . . 58

7.7 Comparação do número de registros enviados durante a execução do algo-

ritmo quando utilizando-se a a heuŕıstica versus utilizando maior identifi-

cador de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.8 Comparação do percentual de redução no número de registros enviados

utilizando-se a a heuŕıstica versus utilizando maior identificador de registro 59

7.9 Speedup variando-se o tamanho da cache: 10% e 40% da base de dados . . 60

7.10 Speedup variando-se o tamanho da cache: 70% e 100% da base de dados . 61

7.11 Tempo de execução para tamanhos mı́nimos da cache e 10 instâncias . . . 62

7.12 Tempo de execução em função do tamanho da cache partição de registros

local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

xvi

Lista de Tabelas

2.1 Exemplos de funções de comparação de strings . . . . . . . . . . . . . . . . 9

4.1 Registros que geram pares candidatos redundantes para cláusulas de predicado 24

5.1 Estat́ısticas das comparações para 1 milhão de registros . . . . . . . . . . . 38

A.1 Atributos dos registros gerados pelo DsGen . . . . . . . . . . . . . . . . . 73

B.1 Parâmetros usados para comparação . . . . . . . . . . . . . . . . . . . . . 75

xvii

Lista de Algoritmos

1 Algoritmo seqüencial para uma base de dados . . . . . . . . . . . . . . . 11

2 Algoritmo seqüencial para duas bases de dados . . . . . . . . . . . . . . 12

3 Algoritmo para o filtro Reader . . . . . . . . . . . . . . . . . . . . . . . 23

4 Blocking filter algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Merger filter algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Algoritmo para o filtro Comparator . . . . . . . . . . . . . . . . . . . . . 27

7 Algoritmo para o filtro Classifier . . . . . . . . . . . . . . . . . . . . . . 28

8 Algoritmo escolha da instância que receberá o par a ser comparado . . . 45

9 Função EnviarPar() modificada para a heuŕıstica . . . . . . . . . . . . . 47

10 Algoritmo do Filtro Blocking . . . . . . . . . . . . . . . . . . . . . . . . 48

xix

Sumário

Agradecimentos ix

Resumo xi

Abstract xiii

Lista de Figuras xv

Lista de Tabelas xvii

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Pareamento de Registros 5

2.1 O Problema do Pareamento de Registros . . . . . . . . . . . . . . . . . 5

2.2 O Processo de Pareamento de Registros . . . . . . . . . . . . . . . . . . 6

2.2.1 Limpeza e Padronização e Análise dos Dados . . . . . . . . . . . 6

2.2.2 Blocagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.4 Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Revisão Bibliográfica 13

3.1 Pareamento de Registros . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Blocagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

xxi

4 O Algoritmo Paralelo de Pareamento de Registros 19

4.1 Anthill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Paralelização do Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Filtro Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Filtro Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.3 Filtro Merger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.4 Filtro Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.5 Filtro Comparator . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.6 Filtro Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.7 Extensões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Decisões de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Avaliação do Algoritmo 33

5.1 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Caracterização das Bases de Dados . . . . . . . . . . . . . . . . 33

5.1.2 Avaliação dos Resultado . . . . . . . . . . . . . . . . . . . . . . 34

5.1.3 Definição dos Parâmetros para os Experimentos . . . . . . . . . 34

5.1.4 Avaliação da Escalabilidade . . . . . . . . . . . . . . . . . . . . 35

6 Entendendo e Explorando a Localidade de Referência 41

6.1 Localidade de Referência . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Evidência da Localidade Temporal . . . . . . . . . . . . . . . . . . . . 42

6.3 Explorando a Localidade de Referência Temporal . . . . . . . . . . . . 44

6.3.1 Utilizando a Cache de Registros da Partição Local . . . . . . . . 44

6.3.2 Reduzindo a Comunicação Através da Localidade de Referência 45

6.3.3 Influência da Blocagem na Localidade de Referência . . . . . . . 47

6.4 Evidência da Localidade Espacial . . . . . . . . . . . . . . . . . . . . . 49

6.5 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7 Avaliando a Localidade de Referência 51

7.1 Avaliando a Escolha da Instância para Comparação . . . . . . . . . . . 51

7.2 Utilizando a heuŕıstica baseada em grafos . . . . . . . . . . . . . . . . . 53

7.3 Avaliando o Algoritmo com a Cache de Comunicação . . . . . . . . . . 58

7.4 Utilizando a Cache de Registros da Partição Local . . . . . . . . . . . . 62

7.5 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8 Conclusão 65

xxii

8.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Referências Bibliográficas 69

A Atributos considerados pelo DsGen 73

B Atributos, funções e parâmetros de comparação 75

C Configuração do pareamento usada para experimentos com locali-

dade de referência 77

xxiii

Caṕıtulo 1

Introdução

O volume de dados gerados e armazenados por organizações e empresas tem crescido

cada vez mais nos últimos anos, bem como a preocupação com a qualidade desses dados.

Informação imprecisa pode levar a decisões errôneas e, por isto, manter bases consis-

tentes e confiáveis é fundamental. Mas nem sempre isto é posśıvel. Bases reais geral-

mente são alimentadas com registros provenientes de procedimentos administrativos,

questionários, reconhecimento através de OCR, extração de dados de mı́dias eletrônicas

e inserção manual. Durante a transcrição, digitação ou mesmo armazenamento dos da-

dos, é muito provável que sejam introduzidos erros e variações em algum momento. Por

exemplo, em bibliotecas digitais como a ACM, DBLP, Google Acadêmico e Citeseer, é

comum encontrarmos variações na escrita do nome de autores, conferências e mesmo

t́ıtulo dos artigos [Kan & Tan, 2008] em decorrência do processo de OCR e mesmo

porque não é seguida uma única forma de escrita de nomes, t́ıtulos e conferências.

Consideramos uma entidade como sendo uma representação de um conceito real

em determinado contexto. Como exemplos de entidades, podemos citar autores, artigos

e conferências em bibliotecas digitais, pacientes, médicos e hospitais em bases da saúde

ou ainda clientes e produtos em bases comerciais. Uma mesma entidade pode ter

parte de seus dados segmentados em duas ou mais bases. Por exemplo, uma mesma

pessoa pode ter seus dados pessoais registrados em um cadastro escolar, em prontuários

hospitalares, em cadastros bancários, entre outros. Damos o nome de pareamento de

registro (record linkage) ao processo de combinar informações de uma mesma entidade

que se encontram segmentadas em várias bases de dados [Winkler, 2006].

Uma variação do problema de pareamento de registro ocorre quando temos uma

única base e há duplicidade de informação como, por exemplo, um mesmo cliente

cadastrado duas vezes. Das diversas variações de uma mesma entidade, podemos es-

colher uma (arbitrariamente ou não) como sendo a canônica, enquanto todas as outras

1

2 Caṕıtulo 1. Introdução

seriam as suas réplicas. Em muitos casos, essas réplicas podem degradar o desempenho

e a confiança de uma base de dados e por isto devem ser eliminadas. Ao processo de

eliminar réplicas em uma base de dados dá-se o nome de deduplicação.

O pareamento de registros envolve comparar pares de registros e avaliar se ambos

se referem à mesma entidade. No caso extremo, todos os registros serão comparados

contra todos os outros, resultado em (n− 1)× (n− 2)/2 comparações no processo dededuplicação e m × n comparações no processo de pareamento de registros. Existemtécnicas (apresentadas na seção 3.2) que se propõem a diminuir o número de compara-

ções mas, ainda assim, esse número pode ser bem grande, o que torna o processamento

paralelo uma escolha quando precisamos diminuir o tempo de processamento.

1.1 Motivação

O problema de pareamento de registros é encontrado nas mais diferentes áreas. Na

área de saúde, diversos trabalhos [Drumond & Machado, 2008; Cherchiglia et al., 2007]

têm usado técnicas de pareamento de registros com a finalidade de integrar bases de

dados diferentes e extrair informações para estudo de poĺıticas de saúde. Trabalhos

sobre qualidade das bibliotecas digitais [Kan & Tan, 2008] discutem a consolidação

de nomes de autores e eliminação de informação incorreta ou redundante. O Censo

americano vem utilizando o pareamento de registro há anos para melhorar a qualidade

dos dados [Jaro, 1989] e inclusive reduzir custos com o próprio levantamento dos dados,

dispensando visitas de entrevistadores quando a informação pudesse ser obtida de outra

fonte [Winkler, 2006]. Empresas privadas têm economizado milhões de dólares ao

resolver problemas de estoque e loǵıstica ao deduplicar suas bases de dados [Kan &

Tan, 2008].

Figura 1.1. Cenário de Armazéns de Dados onde diferentes bases devem serconsolidadas

O volume dos dados é a principal motivação técnica para a criação de um algo-

ritmo para a paralelização do problema de pareamento de registros. Dados fornecidos

1.2. Objetivos 3

pelo Datasus [Datasus, 2008] mostram que de 1995 a 2007, foram realizadas quase 160

milhões de internações hospitalares no Brasil. Em 2004, um levantamento realizado

pelo Governo Federal descobriu que existiam 541 milhões de registros de cidadãos in-

scritos nos cadastros sociais e que, destes, 289 milhões foram facilmente identificados

como réplicas. Outros 252 milhões de registros excedem em muito o número de habi-

tantes do páıs e portanto, existem mais réplicas [Serpro, 2004]. Pelo que conhecemos,

existem na literatura poucos estudos sobre a paralelização da deduplicação de reg-

istros [Peter Christen, 2004; Kawai et al., 2006; Lee & Kim, 2007]. Nestes estudos, os

detalhes sobre a paralelização não estão claros e mesmo as bases de dados utilizadas

para os testes são muito pequenas se comparadas às bases reais.

1.2 Objetivos

Este trabalho tem como objetivo entender o processo de pareamento de registros e

implementar um arcabouço extenśıvel que suporte a execução das várias etapas do

processo em paralelo, sendo uma continuação do trabalho apresentado pelo autor Santos

et al. [2007].

1.3 Contribuições

1. Este trabalho apresenta a proposta de um algoritmo paralelo e eficiente e sua

implementação para o problema de pareamento de registros. Apresentamos como

cada etapa do processo foi paralelizada e discutimos as principais decisões de

implementação.

2. Foi constrúıda uma ferramenta, chamada FERAPARDA, que permite realizar o

pareamento de registros utilizando diferentes funções de comparação e de codifi-

cação de caracteres. A ferramenta também poderá ser estendida para contemplar

outras técnicas de blocagem, de pareamento e também novas etapas no processo.

3. Discutimos como explorar a localidade de referência no problema. Implemen-

tamos uma cache de comunicação que reduziu significativamente a necessidade

de troca de registros. Avaliamos também como a blocagem influencia na locali-

dade de referência e que, ao final, uma cache pequena é suficiente para processar

milhões de pares, mantendo uma boa escalabilidade.

4. A ferramenta FERAPARDA, resultado deste trabalho, foi aplicada a uma base

real em um estudo conduzido junto à Secretaria Municipal de Saúde de Belo

4 Caṕıtulo 1. Introdução

Horizonte. O trabalho ajudou na identificação de subnotificações de óbito em

Belo Horizonte.

5. Apresentamos também o estado da arte dos trabalhos relacionados a pareamento

de registros e como esse problema tem sido abordado no tocante ao processamento

paralelo.

1.4 Organização

Essa dissertação está dividida da seguinte forma: o caṕıtulo 2 apresenta os conceitos e

etapas do pareamento de registros; o caṕıtulo 3 apresenta uma visão geral dos trabalhos

relacionados; o caṕıtulo 4 apresenta o algoritmo de pareamento de registros em paralelo,

discutindo suas decisões, oportunidades de paralelização exploradas e como foi feita

sua implementação. O caṕıtulo 5 avalia a primeira implementação do algoritmo; o

caṕıtulo 6 apresenta a extensão da implementação original para suporte a caches e

discute como explorar a localidade de referência. O caṕıtulo 7 mostra os resultados

obtidos com a utilização de caches e, finalmente, o caṕıtulo 8 apresenta as conclusões

e trabalhos futuros.

Caṕıtulo 2

Pareamento de Registros

Neste caṕıtulo, são apresentados os principais conceitos aplicados ao trabalho, espe-

cialmente aqueles relacionados ao pareamento de registros.

A seção 2.1 apresenta a definição de pareamento de registro. A seção 2.2 apresenta

as etapas do processo.

2.1 O Problema do Pareamento de Registros

O problema de pareamento de registro é conhecido por vários nomes na literatura:

record linkage, deduplicação, entity resolution, merge-purge problem, entre outros [Win-

kler, 2006]. Neste trabalho, decidimos utilizar o termo pareamento de registro para o

processo de combinar informações de várias bases de dados que se referem a uma mesma

entidade. Neste caso, podem existir relações 1-para-1, como no caso de associação de

um registro de um nascido vivo e seu registro de óbito ou ainda 1-para-muitos, como

registro de paciente e suas internações. O termo adotado é deduplicação quando se faz

referência ao processo particular de pareamento de registros que visa eliminar réplicas.

Esta deduplicação pode ser interna (uma única base de dados) ou não (eliminação de

réplicas por meio da junção de duas ou mais bases de dados sendo mescladas).

Se existe algum identificador ou chave formada por um conjunto de atributos

dispońıvel em todas as bases de dados sendo pareadas, o processo de pareamento de

registros é trivial, bastando uma operação de join em SQL ou algo equivalente. En-

tretanto, em muitos casos, esse identificador não existe ou não é disponibilizado por

questões de confidencialidade e técnicas mais sofisticadas necessitam ser usadas. Essas

técnicas podem ser classificadas em dois grandes grupos: determinista (ou baseada em

regras) e probabiĺıstica (baseada em probabilidades de concordância e de discordância

em pares sabidamente corretos e incorretos). O pareamento de registro determinista

5

6 Caṕıtulo 2. Pareamento de Registros

pode ser aplicado caso exista um conjunto de atributos que formam uma chave de lig-

ação. Para obter bons resultados, essa chave de ligação deve ser formada por atributos

precisos, robustos, estáveis ao longo do tempo e presentes em todas as bases de dados

envolvidas. Uma alternativa às chaves de ligação é o uso de um conjunto de regras.

O uso desse conjunto de regras flexibiliza o pareamento, mas pode ser de dif́ıcil elabo-

ração. Na prática, o pareamento de registros determinista é viável apenas em pequenas

bases de dados e resultados emṕıricos mostram que seus resultados são piores do que

o pareamento probabiĺıstico [Christen & Goiser, 2007].

A técnica probabiĺıstica tradicional [Fellegi & Sunter, 1969] utiliza os atributos

comuns das entidades, tais como nomes, endereços e datas para identificar pares de

registros reais. Esses atributos podem conter erros na escrita, estarem em formatos

inconsistentes, abreviados, desatualizados ou mesmo ausentes. Um par é considerado

verdadeiro (match) se os atributos comuns predominantemente casam entre si e é con-

siderado falso (non-match) se os atributos comuns predominantemente discordam.

2.2 O Processo de Pareamento de Registros

O processo de pareamento de registros pode ser dividido em etapas, como pode ser

visto na Figura 2.1.

2.2.1 Limpeza e Padronização e Análise dos Dados

As primeiras etapas do processo de pareamento de registros são a limpeza e a padroniza-

ção. Essas duas etapas convertem os dados de entrada de formato bruto para dados

bem-formados e consistentes na medida do posśıvel. É comum encontrarem-se ca-

sos onde a informação é bastante precária ou não é confiável e o melhor a se fazer é

considerá-la como ausente.

A análise dos dados irá identificar os parâmetros a serem usados nas etapas de

blocagem, comparação e classificação. Esta análise, regra geral, é feita por um espe-

cialista, ou os parâmetros são gerados por um algoritmo de aprendizado [de Carvalho

et al., 2006].

Apesar de fazer parte do processo de pareamento de registros, essas etapas não

serão abordadas neste trabalho, uma vez que foram consideradas relativamente simples

do ponto de vista de paralelização e, geralmente, são realizadas apenas uma vez.

2.2. O Processo de Pareamento de Registros 7

Figura 2.1. O processo de pareamento de registros

2.2.2 Blocagem

A blocagem (do inglês - blocking), também conhecida como indexação [Peter Christen,

2004], tem como objetivo limitar o número de comparações. Considerando-se a dedu-

plicação, o número máximo de comparações é |A| × (|A| − 1)/2 e para o pareamentode registros é |A| × |B|, sendo |A| e |B| a quantidade de registros nas bases de dados.Entretanto, pode-se perceber que a maior parte das comparações são supérfluas. Como

exemplo, para duas bases de dados com 10 mil registros cada, teremos 100 milhões de

comparações no pareamento de registros no caso extremo. Assumindo que a relação

entre duas bases de dados é uńıvoca, o número máximo de pares verdadeiros é domi-

nado pelo tamanho da menor base. Portanto, o número de pares candidatos cresce de

forma quadrática, mas o número de pares reais cresce linearmente [Baxter et al., 2003].

Diversos trabalhos (ver Caṕıtulo 3) discutem diferentes estratégicas de blocagem.

Neste trabalho, foi implementada a blocagem clássica. Para definirmos quais os atrib-

utos dos registros e quais transformações serão aplicadas na blocagem, utiliza-se o

conceito de predicado de blocagem [Hernandez & Stolfo, 1998]. Um predicado é uma

disjunção de conjunções, onde cada termo da conjunção define uma função de trans-

formação sobre o registro. De forma simplista, um predicado de blocagem tem sua

definição semelhante à definição da cláusula where de SQL. Um exemplo de predicado

é P = (nome ∧ ano de nascimento) ∪ (sobrenome ∧ cidade).Quando aplicado a um registro, o predicado de blocagem é capaz de gerar uma


chave de blocagem para cada conjunção. Registros que geraram a mesma chave de

blocagem farão parte de um bloco e as comparações são realizadas apenas entre registros

do mesmo bloco (ver Figura 2.2). No exemplo, o predicado de blocagem é definido como

a concatenação do ano e da cidade, gerando a chave 1 977NY. Os identificadores dos

registros que já foram processados estão listados dentro do bloco (1, 43, 53, . . . e 87).

Quando um novo registro com identificador 3 23 é lido a partir da entrada, uma chave

de blocagem com valor 1 977NY é gerada e o bloco com a mesma chave é recuperado.

Forma-se então um produto cartesiano entre o conjunto de registros já existentes no

bloco e o registro recém-lido.

Figura 2.2. Geração de pares na blocagem

A definição do predicado de blocagem deve considerar dois aspectos principais

que influenciam diretamente o número de pares gerados e a qualidade do resultado

final:

1. Erros nos atributos: Erros nos atributos podem prejudicar a qualidade dos pares

gerados, ao levar à exclusão de pares que seriam, de fato, verdadeiros. Por isto, a

escolha dos atributos deve levar em conta a qualidade da informação ali contida.

2. Freqüência dos valores dos atributos: Alguns atributos podem ter poucos valores

e por isto, serem pouco discriminativos. Por exemplo, o atributo sexo é pouco

discriminativo, pois, geralmente, ele segmenta a base de dados em apenas dois

valores. Nomes comuns, como Maria e sobrenomes como Silva podem, também,

dominar a geração dos pares.

Por fim, existe um compromisso quando se define o predicado de blocagem. Um

predicado mais restritivo conduz à geração de um número maior de pequenos blocos.

2.2. O Processo de Pareamento de Registros 9

Neste caso, os erros, ainda que pequenos, poderão fazer com que pares verdadeiros se-

jam exclúıdos da comparação. Por outro lado, com um predicado menos restritivo ter-

emos poucos blocos de tamanho maior, possivelmente cobrindo mais pares verdadeiros,

mas com crescimento importante do número de pares totais gerados e aumento no

tempo de processamento.

2.2.3 Comparação

A etapa de comparação utiliza os pares gerados pela etapa de blocagem e, em seguida,

produz um resultado numérico associado à comparação dos atributos dos registros. A

comparação pode ser determinista ou probabiĺıstica, conforme observado na seção 2.1.

Neste trabalho, apenas a probabiĺıstica é considerada, muito embora a determinista

possa ser facilmente implementada.

A função de comparação de atributos é baseada em probabilidades de concordân-

cia e discordância em pares verdadeiramente corretos ou incorretos. A fim de definir

se um par gerado é correto ou incorreto, podem ser utilizadas algumas funções auxil-

iares de comparação de atributos, que podem ser bastante simples, como comparação

exata de caracteres ou números, ou podemos utilizar funções que levam em conta erros

tipográficos ou ainda variações fonéticas.

Neste caso, cada função de comparação retornaria um valor numérico, o qual pode

ser normalizado entre zero e um, onde zero indica que os valores dos atributos são total-

mente diferentes e um valor acima de um mı́nimo pré-estabelecido indica concordância.

O valor mı́nimo para concordância é um fator de ajuste. Quanto mais próximo de zero,

maior a tolerância a erros. A tabela 2.1 mostra alguns valores para a comparação de

nomes usando diferentes funções.

Nome 1 Nome 2 Jaro Winkler Dist. Edição Bigramjose josue 0.9330 0.9530 0.8000 0.5710

mariana adriana 0.9050 0.9050 0.7140 0.6670homero rogerio 0.6210 0.6210 0.5710 0.3640karla carla 0.8670 0.8670 0.8000 0.7500

geralda geralda 1.0000 1.0000 1.0000 1.0000cibele sibele 0.8890 0.8890 0.8330 0.8000felipe phillippe 0.6200 0.6200 0.4440 0.4620

vander wander 0.8890 0.8890 0.8330 0.8000maria marta 0.8670 0.9070 0.8000 0.5000

Tabela 2.1. Exemplos de funções de comparação de strings


2.2.4 Classificação

A última etapa, classificação, considera alguma função de similaridade que sumariza

os resultados da comparação do par de registro e classifica-o em um par verdadeiro, um

par falso, ou um par posśıvel (não classificado como verdadeiro ou falso).

Figura 2.3. Faixas de classificação dos pares comparados

Neste trabalho, aplica-se uma discriminação dos pares conforme sugerida por

Fellegi e Sunter. Declara-se (ou considera-se) um par como verdadeiro quando a soma

dos resultados das comparações dos atributos é superior a um limiar Tsuperior. Do

mesmo modo, um par é declarado (ou considerado) falso quando a soma dos resultados

das comparações dos atributos é inferior a um limiar Tinferior. Um par é declarado

(ou considerado) com um par posśıvel quando a soma dos resultados das comparações

dos atributos situa-se entre os limiares Tinferior e Tsuperior, como pode ser visto na

Figura 2.3. Os valores de Tinferior e Tsuperior são parâmetros para o processo e podem

ser obtidos pela análise dos dados ou por algum algoritmo de aprendizado.

A região de classificação de pares como posśıveis idealmente deverá ser a menor

posśıvel. Nessa região encontram-se pares verdadeiros e pares falsos que não puderam

ser discriminados pelas funções de comparação. Dois trabalhos, neste caso, poderão

ser feitos: análise manual dos pares ou, então, refinar o pareamento para essa região,

mudando-se os parâmetros de comparação.

A Figura 2.4 mostra um exemplo do resultado final obtido na comparação de

registros de uma base sintética. O histograma dos pesos representa a soma de resultados

numéricos de concordâncias e discordâncias, resultantes da comparação dos pares. As

duas barras verticais em x = 19 e x = 31, 5 representam respectivamente Tinferior e

Tsuperior.

2.3. Algoritmos 11

−30 −20 −10 0 10 20 30 40 50 60

Log

da fr

eqüê

ncia

Peso de concordância

Pares falsosPares verdadeiros

Figura 2.4. Faixas de classificação dos pares comparados

2.3 Algoritmos

O algoritmo seqüencial para o processo de pareamento de registros é a sua representação

direta, como pode ser visto nos Algoritmos 2 (duas bases) e 1 (uma única base - interno).

A diferença entre eles está na geração dos pares candidatos.

PareamentoUmaBase (Base, Config, Predicado):1HashTable← ∅2foreach Registro ∈ Base do3

foreach Conjunção ∈ Predicado do4Key ← ∅5foreach funcaoTransformar ∈ Conjunção do6

Key ← concatenar(Key, funcaoTransformar(Registro))7/*Cria um novo bloco*/8if Block ← get(HashTable, Key) = NULL then9

Block ← createBlock()10put(HashTable, Key, Block)11

/*Comparaç~ao*/12foreach OldRec ∈ Block do13

Pair ← (Record, OldRec)14Result← compare(Configuration, Pair)15isPair ← classify(Result)16

Block.Append(Record)17

Algoritmo 1: Algoritmo seqüencial para uma base de dados


PareamentoDuasBases (BaseMenor, BaseMaior, Config, Predicado):1HashTable← ∅2foreach Registro ∈ BaseMenor do3

foreach Conjunção ∈ Predicado do4Key ← ∅5foreach funcaoTransformar ∈ Conjunção do6

Key ← concatenar(Key, funcaoTransformar(Registro))7/*Cria um novo bloco*/8if Block ← get(HashTable, Key) = NULL then9

Block ← createBlock()10put(HashTable, Key, Block)11

Block.Append(Record)12

foreach Registro ∈ BaseMenor do13foreach Conjunção ∈ Predicado do14

Key ← ∅15foreach funcaoTransformar ∈ Conjunção do16

Key ← concatenar(Key, funcaoTransformar(Registro))17/*Recupera um bloco existente*/18if Block ← get(HashTable, Key) 6= NULL then19

/*Comparaç~ao*/20foreach OldRec ∈ Block do21

Pair ← (Record, OldRec)22Result← compare(Configuration, Pair)23isPair ← classify(Result)24

Algoritmo 2: Algoritmo seqüencial para duas bases de dados

Quando duas bases são utilizadas, uma otimização de memória implica gerar

todos os blocos a partir da menor base de dados em número de registros(linhas 3-12 ,

algoritmo 2). Em seguida, cada registro da base maior é lido e assim que são formados

os pares, esse registro pode ser descartado. Caso a chave de blocagem gerada para

o registro da maior base não tenha correspondente na base menor, nenhum par será

gerado (linhas 13-24) , algoritmo 2). Esta função lê os dados do registro e transforma

um ou mais atributos em parte da chave de blocagem a ser utilizada. Exemplos de

funções de transformação incluem as funções de codificação de caracteres, usadas para

diminuir os problemas causados por erros nos registros.

Caṕıtulo 3

Revisão Bibliográfica

Feita a introdução sobre os conceitos relacionados ao pareamento de registros,

apresenta-se neste caṕıtulo uma visão geral das pesquisas relacionadas ao presente

trabalho. A seção 3.1 cita os principais trabalhos que formalizaram a abordagem prob-

abiĺıstica para o problema de pareamento de registros. A seção 3.2 apresenta as prin-

cipais técnicas de blocagem utilizadas hoje e os trabalhos que discutem a aplicação,

benef́ıcios bem como os problemas e limitações de cada técnica. O estudo dessas técni-

cas foi importante para o trabalho, uma vez que permitiu avaliar os principais requisitos

para que novas técnicas fossem inclúıdas na aplicação. Além disto, como será discu-

tido no caṕıtulo 6, a blocagem terá papel fundamental quando localidade de referência

é explorada. Finalmente, a seção 3.3 apresenta as algumas ferramentas usadas em

pesquisas, limitando-se apenas àquelas que suportam processamento paralelo.

3.1 Pareamento de Registros

O pareamento de registros vem sendo utilizado há muitos anos, com o objetivo de

eliminar réplicas ou unificar, por meio de associações, registros que estejam contidos

em bases de dados distintas. Entre as bases de dados que podem ser pareadas estão

as de dados médicos sobre pacientes; dados do Censo; dados sobre contribuintes ou

benef́ıcios do Governo, entre outros.

Em seu trabalho, Gill [Gill, 2001] afirma que, apesar de existirem alguns es-

tudos sobre o pareamento de registros feitos na segunda metade do século XIX e

primeira metade do século XX, foi a partir de 1950 que estudos mais confiáveis sur-

giram. As primeiras análises a tratar o pareamento probabiĺıstico de registros [New-

combe, 1967][Acheson, 1968] avaliaram a viabilidade da aplicação da técnica. Nestes,

utilizaram-se pesos obtidos essencialmente de forma emṕırica, por meio de inspeção

13

14 Caṕıtulo 3. Revisão Bibliográfica

manual de freqüência de acertos em pares sabidamente verdadeiros. A elaboração de

uma sustentação teórica para o pareamento probabiĺıstico foi feita nos fins da década

de 1960, com os trabalhos de Nathan (1967) [Nathan, 1967], Tepping [Tepping, 1968],

D’Andrea Du Bois [N. S. D’Andrea Du Bois, 1969] e de Fellegi e Sunter [Fellegi &

Sunter, 1969]. Este último se tornou o principal trabalho da área, tornando-se também

a referência definitiva sobre pareamento probabiĺıstico de registros.

3.2 Blocagem

Os métodos de blocagem buscam selecionar de forma eficiente um subconjunto dos

pares de registros a serem comparados em etapas posteriores do processo. Diferentes

técnicas têm procurado diminuir a quantidade de pares candidatos e cobrir o maior

número posśıvel de pares reais.

A blocagem clássica ou padrão agrupa todos os registros que geraram a mesma

chave em um bloco; apenas registros dentro do mesmo bloco são comparados entre

si. Em sua definição, um registro será inserido apenas dentro de um único bloco.

Sua implementação é simples e eficiente quando se utiliza um ı́ndice invertido [Baxter

et al., 2003]. Cada chave de blocagem cria uma entrada nesse ı́ndice assim que é gerada

pelo primeiro registro. Cada novo registro que gera uma chave existente é inserido no

ı́ndice. Ao final da leitura dos registros, a lista de registros é extráıda da lista invertida

e formam-se os pares a partir de cada bloco.

Uma das principais limitações associadas a esta técnica de blocagem se refere

à inserção de um registro em um bloco incorreto, comum quando existem erros de

entrada. Para evitar esse tipo de problema, podemos utilizar funções de codificação de

caracteres ou, ainda, usar mais de uma opção de blocagem.

Hernandez et al. [Hernandez & Stolfo, 1998] propuseram uma blocagem baseada

na utilização uma lista invertida, onde as entradas são ordenada pela chave de

blocagem. A premissa básica é a de que uma janela deslizante de tamanho fixo w > 1

move-se seqüencialmente sobre os registros ordenados e todos aqueles que estiverem

dentro da mesma janela serão comparados. A principal vantagem desta técnica é que

a quantidade final de pares pode ser controlada. Ao final, cada registro gerará 2w - 1

pares para comparação, resultando um total de O(nw) pares em uma base de dados

com n registros no total [Baxter et al., 2003]. A desvantagem é que para o seu funciona-

mento correto, essa técnica assume que a ordenação não apresenta erros (especialmente

erros no primeiro caractere da chave). Contudo, podemos superar esta limitação: caso

haja suspeita de erros, podemos definir uma combinação de chaves e utilizar funções

3.2. Blocagem 15

de codificação de caracteres.

Uma outra técnica de blocagem é a Q-gramas [Baxter et al., 2003]. A blocagem

Q-gramas permite que pequenas variações nos valores das chaves (inclusão, alteração e

remoção de caracteres) não influenciem o resultado final. Nesta técnica, cada registro

é inserido em mais de um bloco. A chave é transformada em uma lista de q-gramas

(divisões da chave em partes de q caracteres) e todas as combinações desses q-gramas

acima de um certo limiar t são criadas. Em seguida, os q-gramas que compõem cada

combinação são novamente concatenados e usados como chave da lista invertida. Por

exemplo, para uma chave original de blocagem ’silva’, com q = 2 (isto é, bigrama) e

limiar t = 0, 8, temos a seguinte lista de bigramas: [′si′,′ il′,′ lv′,′ va′]. O tamanho da

lista e o limiar são utilizados com a finalidade de determinar as combinações a serem

geradas. No caso, o tamanho da lista é multiplicado pelo limiar, resultando em 4×0, 8 =3, 2, arredondando, 3. Isto implica que todas as combinações de tamanho maior ou

igual a 3 serão consideradas: [′si′,′ il′,′ lv′,′ va′], [′si′,′ il′,′ lv′], [′si′,′ il′,′ va′], [′si′,′ lv′,′ va′]

e [′il′,′ lv′,′ va′]. As chaves inseridas na lista invertida serão, assim, ’siillvva’, ’siillv’,

’siilva’, ’silvva’ e ’illvva’. O tamanho da chave de blocagem impacta diretamente esta

técnica, podendo levar a uma explosão no número de combinações.

Bilenko, Kamath e Mooney discutem em seu trabalho [Bilenko et al., 2006] téc-

nicas adaptativas para a blocagem, visando melhorar a escalabilidade do pareamento.

Segundo os autores, as técnicas mais utilizadas em anos recentes, baseadas na utiliza-

ção de funções de similaridade ou na indexação, requerem um ajuste manual e fino,

para que se minimize número de pares falsos e maximize o número de pares positivos.

Deste modo, os autores apresentam uma abordagem capaz de gerar, a partir de uma

base de treinamento, predicados de blocagem na forma normal disjuntiva (disjunctive

normal form - DNF).

Ainda sobre a blocagem, Bilenko discute em sua dissertação [Bilenko, 2006] o uso

de algoritmos de clustering, especificamente o K-Means, obtendo resultados interes-

santes sobre funções de similaridade aplicadas tanto na blocagem, quanto na compara-

ção de registros.

Baxter e Gu [Gu & Baxter, 2004] apresentam em seu trabalho o conceito de

filtros adaptativos para a blocagem. Para estes autores, por melhor que seja a chave

de blocagem, quase sempre haverá blocos muito grandes. Por exemplo, para o idioma

inglês, Smith e Taylor são sobrenomes comuns. A idéia seria então reprocessar todos

os blocos que são considerados grandes, realizando uma espécie de filtragem dentro

da blocagem, para eliminar pares não relevantes, ou seja, claramente não referentes

ao mesmo indiv́ıduo ou entidade. Assim, informações semânticas podem auxiliar essa

técnica e são de extrema importância. Por exemplo certas doenças como o câncer de

16 Caṕıtulo 3. Revisão Bibliográfica

útero não são aplicáveis a um dos sexos.

3.3 Ferramentas

O Febrl [Peter Christen, 2004] é uma das mais completas ferramentas de pareamento

de registros disponibilizadas como software livre. Esta ferramenta implementa a abor-

dagem clássica para o pareamento de registros [Fellegi & Sunter, 1969] e foi con-

strúıdo como projeto de pesquisa da Australian National University para pareamento

de registros da área médica. Ao longo dos anos, a ferramenta vem sendo estendida

e aprimorada com várias técnicas de blocagem (clássica, sorting blocking, q-grams),

funções de comparação (incluindo informações geo-espaciais), tabelas de correção de

erros (lookups) e processamento paralelo. Um dos autores do Febrl, Christen, discute

em seu trabalho [Christen, 2005] a geração de bases sintéticas para o pareamento de

registros e inclui no Febrl a implementação da ferramenta DsGen. Esta ferramenta

gerou as bases sintéticas usadas nos primeiros experimentos desta dissertação.

Especificamente sobre o paralelismo de dados o Febrl utiliza uma interface de

programação escrita na linguagem Python e que abstrai as chamadas às funções da

biblioteca MPI [Gropp et al., 1996]. Em vários testes realizados com bases reais, o

Febrl não suportou mais do que 3 milhões de pares. Sempre ocorria um problema de

falta de memória, ainda que o computador dispusesse de 2GB de memória principal.

Além disto, por ser totalmente escrito em Python - uma linguagem interpretada - o

desempenho geral do Febrl não é bom, sendo três ordens de grandeza mais lento do

que a implementação em C realizada neste trabalho.

Kawai, Garcia-Molina e Benjelloun, em seu trabalho [Kawai et al., 2006], esten-

dem o conceito de generic entity resolution [Benjelloun et al., 2005] e implementam um

algoritmo para pareamento de registros chamado P-Swoosh. Basicamente, essa famı́lia

de algoritmos considera dois conjuntos de registros, R e R′. R contém os registros a

serem pareados e R′ será o conjunto-resultado. Os seguintes passos são realizados:

1. Escolher um registro de R como sendo o alvo, removendo-o de R.

2. Comparar o registro alvo com todos os registros de R′.

3. Se há concordância (casamento), mesclar todos os registros, gerando um novo com

campos multi-dimensionais. Os registros que geraram esse novo são removidos.

Esse novo registro é o canônico.

4. Se não há concordância, insere o registro alvo em R′.

3.4. Sumário 17

5. Repetir o passo 1 até que R esteja vazio.

Parece claro não haver a etapa de blocagem. Contudo, esta etapa pode ser in-

troduzida por meio de regras de usuário. Em um caso extremo, onde R não possui

qualquer par verdadeiro, cada registro será comparado com outros N ∗ (N + 1)/2 reg-istros. O P-Swoosh pode funcionar com bases replicadas, isto é, cada processador tem

sua própria cópia, ou em um esquema de grid onde os registros são divididos em b buck-

ets disjuntos (diferentemente do FERAPARDA, que distribui pares de registros). Para

esse esquema, b ∗ (b + 1)/2 processadores são necessários. Cada processador executa oalgoritmo de pareamento de registros sobre seu bucket e encaminha o resultado para

um processador mestre. Após ter recebido todos os resultados, o processador mestre

consolida a informação e distribui novamente os buckets até que o conjunto R esteja

vazio. A versão paralela consegue um speedup praticamente linear até 15 processadores.

Além disto, o trabalho tem uma discussão interessante sobre forma de paralelização e

também sobre balanceamento de carga. Porém, sua implementação em Java e os testes

realizados com bases de dados com 5 mil e 20 mil registros mostram que o P-Swoosh foi

criado com o objetivo principal de testar os conceitos sem, efetivamente, possibilitar o

processamento de grandes bases de dados reais. Por gerar uma grande quantidade de

pares candidatos e agregar a cada momento novas informações ao registro canônico.

3.4 Sumário

Até onde pôde ser avaliado, nenhum trabalho na literatura discute maiores detalhes

sobre a paralelização do problema de pareamento de registros. O assunto é ampla-

mente estudado em suas etapas, como a blocagem e a comparação mas, geralmente, os

experimentos consideram apenas dezenas de milhares de registros.

Caṕıtulo 4

O Algoritmo Paralelo de Pareamento

de Registros

Neste caṕıtulo descrevemos a implementação do algoritmo de pareamento de registros

em paralelo. A seção 4.1 apresenta o ambiente de execução Anthill, base fundamen-

tal para a construção e para a eficiência do algoritmo, discutindo os seus conceitos

e abstrações fundamentais. A decomposição do processo de pareamento de registros

em filtros é descrita na seção 4.2. O conjunto de premissas para a implementação do

algoritmo e algumas decisões importantes são apresentadas e discutidas na seção 4.3.

4.1 Anthill

Esta seção apresenta o ambiente e o modelo de programação usados na implementação

do algoritmo paralelo de pareamento de registros. O Anthill Ferreira et al. [2005] foi

escolhido como ambiente de programação para a implementação. Ele permite que uma

aplicação seja dividida em partes que podem ser instanciadas e executadas em diferentes

unidades de processamento. Cada uma dessas partes realiza uma transformação sobre

os dados e encaminha o resultado para a parte seguinte, formando uma espécie de

pipeline de execução. Os autores do Anthill chamam esse conceito de modelo filtro-

fluxo (filter-stream model).

No modelo filtro-fluxo, filtros são representações de cada estágio de computação

onde os dados são transformados. Os fluxos são abstrações para a comunicação, per-

mitindo a transferência de buffers de dados de tamanho fixo de um filtro para o próximo

no pipeline, resumindo a criação de uma aplicação à decomposição em filtros.

Na decomposição em filtros, a aplicação é modelada como um fluxo de dados e

então implementada como uma rede de filtros, sendo o paralelismo de tarefas realizado

19

20 Caṕıtulo 4. O Algoritmo Paralelo de Pareamento de Registros

por meio de um pipeline. Em tempo de execução, várias cópias de cada filtro da

aplicação podem ser instanciadas em diferentes máquinas de um cluster. O ambiente

Anthill permite dinamicamente conectar cada filtro origem ao destino por meio dos

fluxos, como pode ser visto na Figura 4.1.

Figura 4.1. Abstração filtro-fluxo do Anthill

O Anthill explora três possibilidades de paralelismo: paralelismo de tarefa, de

dados e assincronia. Ao dividir a computação em vários estágios de um pipeline (par-

alelismo de dados), cada estágio podendo ser replicado múltiplas vezes (para processar

dados em paralelo), podemos ter um paralelismo de grão-fino e como tudo isto acontece

de forma asśıncrona, a execução poderá estar livre de gargalos.

Em várias aplicações constrúıdas com o Anthill, foi posśıvel observar que a solução

natural freqüentemente era um grafo ćıclico, onde a execução consistia de várias iter-

ações sobre os filtros. A aplicação pode começar com uma representação inicial da

solução e, a cada nova iteração pelo ciclo do pipeline, tal solução pode ser refinada.

Esse comportamento leva a execuções asśıncronas, pois poderão existir soluções (pos-

sivelmente de diferentes iterações), geradas simultaneamente em tempo de execução.

Em diversas aplicações, incluindo o processo de pareamento de registros, a com-

putação apresenta uma natureza ćıclica, ou seja, geralmente existem dependências entre

4.2. Paralelização do Algoritmo 21

diferentes dados que trafegam pelo ciclo. Como cada estágio da computação pode ter

várias réplicas, deve haver uma maneira de encaminhar o resultado de uma computação

em dado ciclo de volta a uma instância espećıfica em um ciclo posterior. Isto pode ser

necessário, por exemplo, se existe algum estado associado com todas as partes interde-

pendentes dos dados e uma delas reside apenas em uma instância de um filtro. Assim,

todas as partes dependentes devem ser roteadas para tal instância espećıfica. Para isto,

o Anhill usa uma abstração chamada fluxo rotulado (labeled stream), caracteŕıstica que

o difere de seus predecessores. Um fluxo rotulado é criado pelo programador para as-

sociar um rótulo a cada mensagem. Uma função (hash) também é definida para que

cada rótulo aplicado a uma mensagem possa ser usado para encaminhar as mensagens

para uma instância espećıfica de um filtro (Figura 4.2).

Figura 4.2. Uso de fluxos rotulados para especificar instância do filtro

O mecanismo de fluxo rotulado permite controle total da aplicação sobre o rotea-

mento de suas mensagens. Como a função hash é chamada em tempo de execução, a

decisão sobre o roteamento é tomada individualmente para cada mensagem e pode ser

alterada dinamicamente durante a evolução da execução. Esta caracteŕıstica permite,

entre outras coisas, a reconfiguração dinâmica para balanceamento de carga em apli-

cações irregulares. A função hash também pode ser relaxada de forma a permitir que

a mensagem seja encaminhada para mais de uma instância (multicast ou broadcast).

Isto é particularmente interessante para aplicações onde um único dado de entrada

influencia vários dados de sáıda.

4.2 Paralelização do Algoritmo

A paralelização do processo de pareamento de registros segmentou a aplicação em

seis filtros lógicos: Reader, Blocking, Merger, Scheduler, Comparator e Classifier. O

mapeamento entre a etapa do processo e o filtro do Anthill que a realizada pode ser visto


Figura 4.3. Pareamento de registro na visão de filtros lógicos

na Figura 4.3. Note que o existe uma relação direta entre a etapa de leitura e o filtro

Reader, etapa de blocagem e o filtro Blocking, etapa de comparação e o filtro Comparator

e etapa de classificação e o filtro Result. Note que a etapa de blocagem é realizada

também no filtro Reader e duas novas etapas foram inclúıdas: uma para eliminar pares

candidatos redundantes (filtro Merger) e outra para explorar a localidade de referência

(filtro Scheduler). Nas subseções a seguir apresentaremos os as razões dessas decisões

e os detalhes de cada filtro.

4.2.1 Filtro Reader

O filtro Reader (Algoritmo 3) é responsável por ler cada registro da base de dados,

atribuir um identificador interno ao processo e gerar uma chave para conjunção do

predicado de blocagem. A geração do identificador interno é feita utilizando-se um

contador seqüencial para cada instância do filtro Reader (por meio da fórmula id =

totalDeInstancias ∗ sequencia + rank). Desta forma, podemos saber qual a origemde cada registro dentro do pipeline, viabilizando a utilização fluxos rotulados (labeled-

streams), necessários em vários estágios. Note que a geração de chave de blocagem, algo

que deveria ser feito na etapa seguinte, já ocorre neste momento. Com isto, somente


meta-dados são trafegados e não todo o registro.

Reader (Dataset, Configuration, Rank, Instances):1sequence← 02foreach Records ∈ Dataset do3

Key ← ∅4Record.id← sequence ∗ Instances + rank5foreach Conjunction ∈ Predicate do6

foreach Transformation ∈ Conjunction do7Key ← concatenate(Key, transform(Record))8

sendToblocker(Record.id, Key, Conjunction)9

sequence← sequence + 110Algoritmo 3: Algoritmo para o filtro Reader

O balanceamento de carga para este filtro é trivial. Cada instância ficará

com uma partição de n-avos da base de dados (onde n é o número de instâncias).

Cada instância gerará a mesma quantidade de chaves de blocagem e salvo diferenças

mı́nimas, o custo será o mesmo.

4.2.2 Filtro Blocking

Assim que uma chave de blocagem é gerada, ela é enviada juntamente com o identi-

ficador do registro e identificador da conjunção para o filtro Blocking (Algoritmo 3,

linha 9).

A comunicação entre o filtro Reader e o filtro Blocking é feita por meio de fluxos

rotulados baseados na própria chave de blocagem. Não há como um mesmo bloco

estar fragmentado entre as posśıveis várias instâncias do filtro Blocking. Sabemos

que, de acordo com a distribuição das chaves de blocagem, podem ocorrer problemas

relacionados ao desbalanceamento de carga. Uma melhoria seria particionar o bloco

entre as várias instâncias e enviar uma mensagem por multicast do filtro Reader, mas

deixamos esse estudo como trabalho futuro.

O filtro Blocking (Algoritmo 4) mantém uma lista de todos os identificadores

de registro que geraram a mesma chave de blocagem. Quando uma nova mensagem

chega até esse filtro, ele identifica se é necessário criar um novo bloco ou simplesmente

adicionar o registro a um já existente. Ainda durante a recepção da mensagem, o

filtro Blocking gera os pares candidatos, como pode ser visto na Figura 2.2. Note que

durante o processo de blocagem, os filtros de leitura continuam a gerar novas demandas,

podendo levar à sobrecarga do pipeline. O Anthill é constrúıdo sobre o PVM [Sunderam,

1990] e não raramente encontramos problemas com o buffer de mensagens.


Blocking ():1HashTable← ∅2foreach Message from Reader do3

Key ← Message.key4Conjunction ← Message.conjunction5if Block ← get(HashTable, Key, Conjunction) == NULL then6

Block ← createBlock()7put(HashTable, Key, Conjunction, Message.id)8

foreach OldRec ∈ Block do9Pair ← sort(OldRec, Message.id) sendTomerger(Pair)10

Algoritmo 4: Blocking filter algorithm

4.2.3 Filtro Merger

A Tabela 4.1 mostra como as disjunções de um predicado de blocagem podem se sobre-

por e gerar pares candidatos repetidos, o que resultaria em processamento redundante.

Os registros 1000 e 1100 são inseridos nos mesmos dois blocos (um para cada disjunção).

Com isto, durante a geração de pares candidatos, o par (1000, 1100) será gerado duas

vezes.

Predicado = (sobrenome OU ano nascimento)Identificador Nome Nascimento1000 Luiz Silva 17/01/19801100 Felipe Silva 11/10/ 1980

Tabela 4.1. Registros que geram pares candidatos redundantes para cláusulasde predicado

O filtro Merger (Algoritmo 5) eliminará quaisquer pares candidatos redun-

dantes. Ele mantém um conjunto de todos os pares que foram gerados pelo processo de

pareamento até o momento. Assim que um par redundante é identificado, ele é descar-

tado. Uma otimização interessante aplicada neste filtro pode ser explorada pelo fato da

geração de pares ser um processo crescente quando existe balanceamento de carga. Um

par formado identificadores pequenos só ocorre no ińıcio e assim é posśıvel descartá-lo

pouco tempo depois. Isto permite manter um histórico de pares gerados pequeno, da

ordem de dezenas de milhares, configurável através de parâmetro, implementado como

uma lista circular.

Como o trabalho do filtro Merger é bem simples, não há necessidade de termos

mais de uma instância.


Merger ():1HashTable← ∅2foreach Message from Blocker do3

Pair ←Message.pair4Key ← f(Pair)5if get(HashTable, Key) == NULL then6

sendTocomparator(Message.pair)7put(HashTable, Key)8

Algoritmo 5: Merger filter algorithm

4.2.4 Filtro Scheduler

O filtro Scheduler tem como objetivo organizar o fluxo de pares candidatos provenientes

do filtro Merger de forma a diminuir o custo de comunicação (ver subseção 4.2.5), me-

lhorar o balanceamento de carga distribuindo melhor os pares entre as instâncias do

filtro Comparator ou um misto dos dois.

As mensagens geradas pelo filtro Scheduler precisam ser entregues a instâncias

espećıficas do filtro Comparator e para isto são usados fluxos rotulados. A escolha

da instância que receberá o par candidato para comparação considera a origem dos

registros:

• Ambos os registros que formam o par foram originados da mesmapartição de dados: O par é enviado para a instância que originou os registros.

Não há comunicação entre instâncias do filtro Comparator.

• Cada registro foi originado em uma partição de dados diferente: Con-siderando um cenário onde não exista nenhum tipo de cache de comunicação,

qualquer escolha é satisfatória, uma vez que todos os registros necessários de-

verão necessariamente ser comunicados. Entretanto, se utilizarmos uma cache

de comunicação, a decisão deve utilizar alguma heuŕıstica a fim de maximizar

sua utilização. Note que havendo ou não uma cache, o filtro Scheduler sempre

envia o par para uma instância que tenha pelo menos um dos registros, pois, do

contrário, o custo de comunicação dobraria.

Deixamos a discussão sobre o filtro Scheduler para o Caṕıtulo 6, onde apresenta-

mos as nossas abordagens para otimização do uso da cache e exploração da localidade

de referência.


4.2.5 Filtro Comparator

Conceitualmente, os filtros Reader e Comparator são diferentes, mas, por questões de

otimização (notadamente por causa da localidade de referência), eles são implementados

como um único processo do sistema operacional (filtro ReaderComparator). Reforçamos

que a leitura dos dados e a comparação dos registros continuam sendo duas tarefas

diferentes e que a implementação como um único processo do sistema operacional foi

decidida tendo como base a otimização e utilização de uma cache.

A Figura 4.4 mostra o pipeline em sua implementação real. Unir os filtros Reader e

Comparator envolve criar um ciclo no pipeline. Como dito, no filtro ReaderComparator

podemos ter dados em diferentes ciclos de processamento. Enquanto registros ainda

são lidos, mensagens de comparação já são recebidas e processadas.

Figura 4.4. Visão de implementação dos filtros

O filtro Comparator sempre receberá um par a ser comparado onde pelo menos

um dos registros está na partição local da base de dados (algoritmo 6, linha 8). Se

ambos os registros estão presentes em sua partição dos dados (linha 11), o trabalho

do filtro Comparator é simplesmente aplicar as regras de comparação e encaminhar o

resultado para o próximo estágio do pipeline (linhas 12-14).

As instâncias do filtro Comparator podem receber três tipos de mensagens

diferentes: Compare (CmpMsg), ReceiveAndCompareRecord (RCRMsg) e Compare-

AlreadyReceivedRecord (CRRMsg). Se uma instância de Comparator recebe uma men-

sagem CmpMsg e o registro complementar já se encontra na cache, nenhuma comuni-

cação extra é realizada e a comparação é feita imediatamente (linhas 15-17).

Se um dos registros não faz parte da partição local, a instância verifica se o

seu registro já foi enviado para a instância que possui o registro complementar. Em

caso positivo, é enviada a mensagem CRRMsg (linhas 18-19), do contrário, envia-

se a mensagem RCRMsg (linhas 20-22). Comparativamente, a mensagem CRRMsg

é formada apenas pelos identificadores dos registros, ao passo que RCRMsg contém

os mesmos identificadores e ainda todo o registro. Logo, diminuir a quantidade de

mensagens RCRMsg reduz o custo de comunicação, uma vez que os registros podem


ocupar centenas de bytes. A instância que recebe o par e possui apenas um registro

sempre o envia, dado que, com esta abordagem, diminúımos a comunicação e evitamos

a necessidade de sincronização que existiria se cada instância do filtro Comparator

tivesse que solicitar a outra instância o registro ausente.

Ao receber uma mensagem do tipo CRRMsg, basta a instância do filtro Compara-

tor comparar o par. Note que assumimos que sempre que essa mensagem for recebida,

existirá uma sincronia entre a cache e o emissor de forma que o último saberá quando

um registro faz ou não parte da primeira. No caso de receber uma mensagem RCRMsg,

a única diferença é que o registro é salvo na cache para uso futuro.

Comparator (DatasetPartition):1SentCache← ∅2RecCache← ∅3foreach Message received do4

id1←Message.pair.id15id2←Message.pair.id26/*It Always has this record*/7Record1← get(DatasetPartition, id1)8if Message.type = Compare then9

/*Instance has both records?*/10if id2 ∈ DatasetPartition then11

Record2← get(DatasetPartition, id2)12R← compare(Record1, Record2)13sendToclassifier(R)14

else if id2 ∈ RecCache then15R← compare(id1, id2)16sendToclassifier(R)17

else if id2 ∈ SentCache then18sendToprocess(owner(id2), id1, id2)19

else20sendRecord(owner(id2), record(id1), id2)21put(SentCache, id1, owner(id2))22

else if Message.type = CRRmsg then23Record2← get(RecCache, id2)24R← compare(Record1, Record2)25sendToclassifier(R)26

else if Message.type = RCRmsg then27Record2← Message.Record28R← compare(Record1, Record2)29sendToclassifier(R)30put(RecCache, id2)31

Algoritmo 6: Algoritmo para o filtro Comparator


É importante lembrar que uma das premissas para o algoritmo é que a base de

dados não está previamente ordenada. Não foi posśıvel encontrar uma estratégia efi-

ciente para particionar uma base de dados de forma a se obter um balanceamento

de carga perfeito. Empiricamente, percebemos que não ocorrem grandes desbalancea-

mentos (ver Caṕıtulos 5 e 7), mas não é posśıvel generalizar.

A primeira versão do algoritmo considera uma cache de tamanho ilimitado para a

comunicação de registros entre instâncias do filtro Comparator. Na prática, o tamanho

pode ser limitado sem perda de desempenho (como será discutido no Caṕıtulo 6). Por

hora, consideramos que todos os registros comunicados entre as instâncias estarão na

cache e nunca irão expirar. Assumimos uma abordagem conservadora e implemen-

tamos a cache individualizada por instância e mantemos uma sincronização entre o

emissor e o receptor. Portanto, uma instância sabe exatamente quando outra possui

determinado registro em sua cache de comunicação. Mesmo no caso de cache limitada,

assumindo que a ordem das mensagens sempre é respeitada, torna-se posśıvel manter

a consistência.

4.2.6 Filtro Classifier

O último filtro é chamado de Classifier (Algoritmo 7). Ele classifica os pares de

registros em concordância, discordância ou posśıvel concordância (necessitando neste

caso intervenção e análise humana), utilizando o pareamento probabiĺıstico [Fellegi &

Sunter, 1969].

Classifier ():1foreach Message from Comparator do2

C ←Message.c3C ′ ← f(C)4if C ′ > upperthreshold then5

Par é uma concordância.6

else if C ′ < lowerthreshold then7Par é uma discordância.8

else9Posśıvel concordância.10

Algoritmo 7: Algoritmo para o filtro Classifier

4.2.7 Extensões

Uma posśıvel melhoria no processo de pareamento de registros seria a inclusão de um

estágio que aplicasse a transitividade como discutida no trabalho de Hernandez [Her-

4.3. Decisões de Implementação 29

nandez & Stolfo, 1998]. Supondo que a blocagem não consiga cobrir todos os pares

reais (registros acabaram em blocos diferentes), se houver pares capazes de ligar os

diferentes blocos podeŕıamos aplicar a transitividade. Por exemplo, para um predicado

de blocagem P = {C1|C2} com duas conjunções, se um par verdadeiro par1 = (a, b)pertencer ao blocos gerados por C1 e o par verdadeiro par2 = (b, c) pertencer ao bloco

gerado por C2, podemos assumir sem perda que o par par3 = (a, c) também é ver-

dadeiro. Uma implementação paralela deste estágio é deixada como trabalho futuro.

4.3 Decisões de Implementação

A implementação do algoritmo de pareamento de registros em paralelo teve como base

as seguintes premissas:

1. A solução final deve se tornar um arcabouço onde novos filtros (ab-

strações do ambiente Anthill) poderão ser inclúıdos bem como algum

filtro existente poderá ter sua implementação substitúıda.

Neste trabalho, apenas uma das técnicas de blocagem (a clássica) foi imple-

mentada. É interessante poder avaliar outras técnicas considerando-se o as-

pecto da paralelização e escalabilidade. A maior parte dos trabalhos sobre

blocagem [Bilenko, 2006; Bilenko et al., 2006; Baxter et al., 2003] consideram

apenas aspectos relacionados à cobertura de pares verdadeiros e total de pares

gerados. Deixamos essa avaliação como trabalho futuro. A modelagem por meio

de filtros e fluxos permite ainda imaginarmos outros estágios para o pipeline.

Um exemplo é a inclusão de um filtro para aplicar a transitividade de pares ver-

dadeiros [Hernandez & Stolfo, 1998] ou ainda incorporar aspectos semânticos ou

algum refinamento da etapa de blocagem.

2. A partição dos dados e sua disposição (ordenação) não são conhecidos

de antemão.

A definição da melhor blocagem no processo de pareamento de registros muitas

vezes é feita de forma emṕırica. A implementação não requer qualquer restrição

sobre a disposição (ordenação dos dados). Desta forma, o usuário pode sim-

plesmente trocar a definição da blocagem sem precisar reconstruir ı́ndices ou

reordenar toda a base de dados. Evidentemente, podem existir situações onde o

algoritmo teria ganhos ao utilizar dados dispostos de forma a explorar ao máx-

imo a localidade de referência. Contudo, não encontramos uma forma de tornar


isto válido para todos os casos. A ordenação também poderá provocar um des-

balanceamento de carga. Assumindo que toda a base é ordenada e depois par-

ticionada entre as instâncias, dependendo do predicado de blocagem poderemos

ter um bloco muito grande ficando a cargo de apenas uma instância de filtro. É

o caso de atributos mais freqüentes.

3. Não é necessário processar todos os posśıveis pares candidatos, mas é

fundamental cobrir a maior parte dos pares reais.

A etapa de blocagem é cŕıtica para o processo. Quanto menos restritiva, maior o

número de pares candidatos gerados, causando uma explosão combinatória. Por

outro lado, com uma blocagem restritiva, pares reais poderão exclúıdos do bloco

formado. Sabendo deste compromisso, preferimos construir uma solução que seja

robusta o suficiente para processar grandes quantidades de pares e que explore

aspectos da localidade de referência para maximizar o throughput.

4. Por maior que seja o número de máquinas no cluster, ainda assim

poderá existir uma base de dados que não caberá em memória princi-

pal.

A implementação deve trabalhar com um conjunto de dados pequenos em

memória principal, descartando os dados após o processamento e tendo como

recuperá-los da memória secundária quando necessário. Foi implementada uma

cache que armazena em memória principal os registros da partição de dados local

a cada instância do filtro Reader. Também existem abstrações na implementação

que permitem estender o conceito de fonte de dados. Uma fonte de dados pode

ser um arquivo, uma conexão a um servidor de banco de dados ou qualquer outra

fonte que forneça dados estruturados.

5. Existe a possibilidade de que haja um desbalanceamento provocado

pela irregularidade dos dados.

Um filtro escalonador (scheduler) deve ser definido para rotear os pares candidatos

para uma das instâncias do filtro Comparator. Sua implementação tem como

objetivo diminuir o número de mensagens trocadas entre os filtros (explorando a

localidade de referência), servir como um balanceador de carga ou algo um misto

de ambos.

6. A solução é livre e aberta.

Gostaŕıamos que a solução contribúısse com outros projetos de pesquisa, pudesse

ser estendida e também fosse usada como ferramenta por empresas e pelo Gov-

4.4. Discussão 31

erno. No estágio em que se encontra, a ferramenta necessita de um especialista

para a configuração de parâmetros, análise dos resultados, ajustes finos e gestão

de bases de dados. Deixaremos como trabalho futuro a melhoria da interface de

usuário.

4.4 Discussão

Consideramos que a implementação do nosso algoritmo escala por explorar alguns as-

pectos do paralelismo de tarefas, paralelismo de dados e uso da assincronia, dispońıveis

no ambiente de execução Anthill.

O paralelismo de tarefas é implementado por meio de um pipeline controlado

pela dependência dos dados, como apresentado na Figura 4.3. As instâncias do fil-

tro Reader não precisam ler toda a partição de dados antes de enviar a informação

para o filtro Blocking. Assim que um registro é lido, ele é imediatamente colocado no

pipeline para processamento. Como resultado, múltiplas tarefas podem ser executadas

simultaneamente.

Ao utilizar mais de uma instância dos filtros, estamos aproveitando o paralelismo

de dados. Notadamente, os filtros Reader e Comparator exploram bem essa caracteŕıs-

tica. Outro filtro que também é bom candidato ao paralelismo de dados é o Blocking.

As instâncias desse filtro iteram sobre uma lista de identificadores de registros em

O(n), sendo n o tamanho médio dos blocos. Quando usamos muitas instâncias do

filtro Reader ou mesmo quando tamanho médio n é grande, o filtro Blocking pode ficar

sobrecarregado. Neste caso, podemos utilizar mais de uma instância, apesar de que a

distribuição das chaves de blocagem pode provocar um desbalanceamento de carga.

A assincronicidade é explorada primeiramente por meio da eliminação de pares

redundantes no filtro Merger (portanto, não há relação 1 : 1 entre pares candidatos

gerados e efetivamente comparados). Ainda podemos executar mais de um instância

de um filtro ou mesmo filtros diferentes em um mesmo computador (especialmente se

multi-core). Enquanto um processo está ocioso, outro pode fazer uso dos recursos.

Observamos que, por meio do uso de multiprogramação, o desempenho do algoritmo

pode ser otimizado, especialmente em relação ao uso de CPU.

A sobrecarga do pipeline em certas ocasiões é um problema que pode levar a um

consumo excessivo de memória, devido aos buffers de comunicação do PVM. Ideal-

mente, deveria ser implementado um mecanismo de sincronização entre produtor e

consumidor. Esta questão fica em aberto e possivelmente será resolvida com a nova

versão do Anthill que usa como base o MPI [Gropp et al., 1996].

Caṕıtulo 5

Avaliação do Algoritmo

Neste caṕıtulo apresentamos a avaliação experimental do nosso algoritmo paralelo de

pareamento de registros. Aqui consideramos a primeira versão do algoritmo, sem

otimizações relacionadas à localidade de referência.

5.1 Experimentos

Os experimentos foram executados em um cluster formado por computadores AMD

Athlon 64 3200+ com 2GB de RAM, conectados por uma rede Gigabit Ethernet e

executando o sistema operacional Linux 2.6.

5.1.1 Caracterização das Bases de Dados

Dada a dificuldade de se conseguir bases de dados reais grandes o suficiente para a real-

ização dos experimentos, decidimos utilizar o gerador sintético de carga DsGen provido

pela ferramenta Febrl [Peter Christen, 2004]. O gerador reproduz certas caracteŕısti-

cas dos dados reais, como ausência, erros tipográficos, variações fonéticas, freqüência

e variações na escrita de nomes e mesmo variações em endereços postais. O DsGen

possui uma série de tabelas que permitem-no gerar bases bem próximas às reais, com

uma consideração: a base segue caracteŕısticas do idioma inglês. Como parâmetros de

entrada, o DsGen espera o nome de uma função de distribuição de probabilidade, a

quantidade de erros introduzidos por registro e a quantidade de réplicas. Os registros

gerados pelo DsGen têm tamanho variável e são formados pelos atributos descritos na

tabela A.1 do Apêndice A.

Foram geradas bases de até 1 milhão de registros, com 10% sendo réplicas e, em

média, 5 erros introduzidos por registro. Utilizamos a distribuição de probabilidade

33

34 Caṕıtulo 5. Avaliação do Algoritmo

uniforme, conforme exemplos do Febrl. Entendemos que outras distribuições poderiam

ser u

Documents

Algoritmo Paralelo e Eficiente para o Problema de ... · ALGORITMO PARALELO E EFICIENTE PARA O PROBLEMA DE PAREAMENTO DE DADOS Dissertac~ao apresentada ao Programa de P os-Gradua˘c~ao