AODP: Um Data Flow de particionamento

O ParallelNACluster depende do resultado da execução do FRANCE. A Figura 6.14 ilustra essa dependência e mostra o FRANCE recebendo como entrada o conjunto de catálogos e o número de partições desejado. A saída produzida por

ele contém um arquivo com as quatro fronteiras geradas que dão origem às cinco partições. Esse arquivo, juntamente com o conjunto de catálogos, são usados como entrada no ParallelNACluster.

Figura 6.14: Modelo de Implementação do ParallelNACluster para Apache Spark

O FRANCE executa de forma centralizada, logo o conjunto de catálogos usado como entrada precisa estar no disco local da máquina onde ele é executado. No entanto, o ParallelNACluster executa de forma distribuída e seus arquivos de en- trada, precisam estar em um sistema de arquivos distribuído, como o HDFS. Portanto, para executar o ParallelNACluster é necessário realizar uma sequência de passos an- teriores à sua execução. Eles são:

• tornar conhecidas as fronteiras entre as partições: para identificar as fronteiras em um conjunto de catálogos é preciso realizar seu particionamento com o soft- ware que implementa o FRANCE e executa de forma centralizada. A sua saída deve ser usada como entrada do ParallelNACluster;

• copiar os arquivos de entrada do ParallelNACluster para o sistema de arquivos distribuído: o conjunto de catálogos e o resultado do FRANCE deve ser copiado para o HDFS.

Esse pré-processamento executado manualmente requer tempo e atenção na manipulação dos arquivos. Qualquer erro compromete o resultado final do casa- mento, pois caso usemos o arquivo de fronteiras que não se refira ao mesmo conjunto

de catálogos usado como entrada no ParallelNACluster, as partições ficarão desba- lanceadas e pode ocorrer erro na alocação da memória. Portanto, precisamos de um processo automatizado que realize o pré-processamento dos dados e os direcione ao ParallelNACluster conforme mostrado na Figura 6.14.

Com o objetivo de resolver esse problema, desenvolvemos um workflow, chamado AODP (Application Oriented Data Partitioning), que organiza todas as etapas necessárias para a execução ParallelNACluster. Ele realiza o pré-processamento dos dados de diferentes catálogos, que estão em disco local, de forma que eles possam ser usados como entrada do ParallelNACluster em ambiente distribuído.

O AODP foi desenvolvido para executar através do QEF (PORTO et al., 2007), Query Evaluation Framework e está disponível à comunidade no endereço https://github.com/vinipires/AODP. O QEF é um framework que provê um ambiente para definição e execução de planos de consulta de forma distribuída, e permite a comunicação entre os componentes de execução de consulta e o acesso a fontes de dados heterogêneas. Os planos de consulta são representados por um QEP – Query Execution Plan – e constituídos de operadores que comunicam-se entre si para a obtenção de um resultado.

Basicamente, o workflow possui a estratégia FRANCE de particionamento, a cópia dos dados no HDFS e a execução do ParallelNACluster. Ele é apresentado graficamente pela Figura 6.15. Os círculos centrais representam cada um dos opera- dores: TupleScan, FRANCE, CopyToHdfs e ParallelNACluster.

O operador TupleScan é responsável por obter o dataset do disco local e o deixar disponível para os demais operadores.

O operador FRANCE é responsável pelo particionamento dos dados em histogramas equi-depth, conforme apresentado na subseção 6.1.2. Ele recebe como entrada o dataset formado por um conjunto de catálogos armazenado no disco local e gera como saída um arquivo contendo os intervalos em RA (Ascensão Reta) do particionamento, isto é, os valores em RA onde o espaço foi cortado. Como o FRANCE é uma visão dos dados, ele não pode ser paralelizado e executa localmente.

O terceiro operador, CopyToHdfs, recebe dois arquivos como entrada, o mesmo dataset e a lista de partições produzida pelo operador anterior. O objetivo do CopyToHdfs é copiar esses arquivos, que estão no disco local, para o HDFS e deixá- los disponíveis à todos os nós do cluster, tornando possível a execução da versão paralela do NACluster.

YARN5_{, uma plataforma de gerenciamento de recursos de computação em clusters} responsável pelo agendamento de jobs no ambiente distribuído. O operador recebe como entrada o conjunto de catálogos e o arquivo contendo a lista de partições, todos eles armazenados no HDFS. Como saída, este operador gera o resultado do casa- mento produzido pela versão paralela do NACluster.

Figura 6.15: AODP: Um workflow de particionamento.

6.3 Considerações Finais

Iniciamos este capítulo demonstrando que em casos de grande volume de dados, o NACluster, apresentado no Capítulo 5, possui limitações físicas, pois precisa- ria de computadores com demasiada memória RAM para ser executado, algo que nos dias de hoje custa muito caro. Para baratear o processo e facilitar seu uso na comu- nidade que necessita processar grandes volumes de dados, propomos o ParallelNA- Cluster, um algoritmo de clusterização que executa de forma distribuída e propõe-se a dar resultados semelhantes ao NACluster.

A solução paralela proposta requer alguns cuidados especiais. O primeiro deles, o particionamento, precisa preservar a vizinhança e manter o balanceamento das partições. Para atender este requisito, usamos o FRANCE (FRAgmeNtador de Catálogos Espaciais) para realizar o particionamento em uma dimensão. O segundo cuidado especial é com as fronteiras produzidas pelo particionamento. O NACluster precisa da vizinhança para realizar o casamento segundo seu algoritmo. No entanto, particionar os dados com o FRANCE, faz com que a vizinhança da fronteira de duas partições vizinhas seja separada. Portanto, conhecer as fronteiras e os objetos próxi- mos em partições vizinhas torna-se essencial para a execução da clusterização nestes

objetos. Para esse tratamento especial das fronteiras propomos o SCIBoundary, um algoritmo recursivo que objetiva encontrar os objetos influenciados elas.

Para automatizar e acelerar a execução do pré-processamento dos dados, propomos a terceira contribuição deste capítulo, o AODP, um workflow para particiona- mento dos dados em disco local e execução do casamento dos mesmos em ambiente distribuído através do ParallelNACluster.

7 EXPERIMENTOS

Este capítulo apresenta os experimentos realizados nesta tese. Eles são divididos em duas partes. Primeiramente apresentamos os experimentos com o NA- Cluster e em seguida com o ParallelNACluster.

Na Seção 7.1 discutimos como simulamos o Golden Standard e os conjun- tos de catálogos a serem usados como entrada nas implementações. O objetivo das simulações é avaliar a qualidade do NACluster.

Em seguida, na Seção 7.2, analisamos os resultados dos experimentos do NACluster aplicados a diversos conjuntos de catálogos. No primeiro experimento, selecionamos três conjuntos de catálogos, aplicamos o NACluster sobre eles e medi- mos a qualidade dos casamentos através da precisão, abrangência e medida-F. Em seguida, na Subseção 7.2.1, propomos uma métrica para avaliar a ambiguidade do ponto de vista dos objetos, ou seja, o quanto cada objeto é ambíguo em relação aos clusters, com o objetivo de encontrarmos alguma correlação entre a qualidade da clusterização do NACluster e a ambiguidade existente no agrupamento. Na Subse- ção 7.2.2 realizamos experimentos para medir o tempo de execução do NACluster em relação ao aumento do volume do conjunto de catálogos. E na Subseção 7.2.3, re- alizamos uma análise para verificar se a escolha dos centroides iniciais influencia na saída do NACluster.

Na Seção 7.3 fazemos uma comparação entre um algoritmo de cross-matching bastante utilizado na comunidade, o Q3C Join, e o NACluster. E, finalmente, na Se- ção 7.4 apresentamos o último experimento com o NACluster e apontamos um caso particular que pode ocorrer na estratégia de casamento.

Na Seção 7.5 realizamos experimentos com o ParallelNACluster. Avaliamos a qualidade do seu casamento, bem como do casamento produzido pela fronteira. Além disso, analisamos o impacto da mudança dos parâmetros do Apache Spark na submissão da aplicação distribuída e testamos a escalabilidade ao aumentarmos o volume de dados.

E, finalmente, na Seção 7.6 fizemos testes com o AODP e discutimos a pro- porção de tempo que cada operador usa para executar e identificamos os parâmetros que influenciam diretamente nesta proporção.