G USTY e G USTY F UNCTION

GUSTYe GUSTYFUNCTIONsão componentes intimamente relacionados, de modo

que o primeiro possui um componente aninhado do tipo do segundo em sua arquitetura de sobreposição. Os parâmetros de sua assinatura contextual podem ser vistos na Tabela 11, onde DATAé o tipo base de componente da espécie estrutura de dados na HPC Shelf. É importante

destacar que o parâmetro graph_type não é limitado a GRAPH, o que permite a GUSTY e

GUSTYFUNCTIONaceitar outras versões, ou mesmo ignorar esse parâmetro, permitindo trabalhar

com chaves/valores do MapReduce tradicional. Isso deixa o desenvolvedor livre para realizar suas otimizações, manipulando os tipos de chave e valores, bem como o tipo do grafo, conforme suas necessidades. A Figura 36 apresenta GUSTYFUNCTION e GRAPH modelados no HPE.

Todos os componentes aninhados a GUSTYFUNCTION, definidos a seguir, são acessíveis na

Figura 36 – Componentes GUSTYFUNCTIONe GRAPHmodelados no HPE

• input_bin é do tipo INPUTBIN, com instâncias InputBinInstance recebidas através

de pares chave/valor, onde a chave é a partição da instância;

• input_key_values é um iterador de entrada, composto por uma chave e vários valores; • output_value produz instâncias de pares chave/valor como resultado de um determinado

processamento;

• output_messages é um iterador ou buffer de saída para um conjunto de pares chave/valor, os quais são distribuídos através de conectores, para novos processamentos;

• continuation_value representa um valor de saída incremental. Ou seja, no recebimento de uma chave vinculada ao valor ocorre sua recuperação para incremento, tal como uma soma cumulativa;

• graph é o componente GRAPH, funcionando como um subgrafo paralelo, o qual é alimen-

tado pelo particionamento em InputBinInstance.

Dadas as definições dos componente aninhados, no modelo de programação aplicado ao Gust, todo algoritmo escrito em GUSTYFUNCTION deve conter no mínimo três métodos:

unroll, compute e scatter, descritos em seguida.

• unroll: método destinado a coletar dados em GUSTYFUNCTION, chamado pelo agente

GUSTYsempre que há um novo par chave/valor no iterador de entrada. Permite o incre-

mento de valores que pertencem a uma mesma chave, uma vez que pares são produzidos de forma assíncrona. Ou seja, quando o programador insere um par no buffer de saída (disponibilizado no scatter) esse par já está disponível para consumo na próxima iteração ou fase GUSTY, sendo recuperado e incrementado nesse unroll subsequente. No modelo

GAS (Gather, Apply, and Scatter) do POWERGRAPH(GONZALEZ et al., 2012), unroll

pode ser visto como um gather que usa o método cumulativo denominado sum.

vedor insere a lógica do seu algoritmo. Com chamada controlada por GUSTY, é importante

destacar duas possibilidades de implementação concreta para GUSTY. A primeira forma

consiste em compute ser chamado apenas uma vez na iteração. Isso faz com que o desen- volvedor deva iterar nos vértices do grafo através do retorno do método graph.vertexSet. O programador possui acesso irrestrito e pode focar tanto no subgrafo como nos vértices individuais iterados. A segunda forma consiste no parâmetro de contexto graph_type ser limitado a GRAPH, bem como input_key_type e output_key_type serem limitados a VER- TEX, sendo uma forma mais restritiva. Isso faz com que GUSTYtenha acesso direto aos

componentes aninhados vertex e edgeFactory. Nesse caso, GUSTYdeve chamar, para

cada vértice, a função compute. Além disso, deve fornecer dados e vizinhança, para que o programador tenha foco exclusivo naquele vértice em processamento, embora ele ainda tenha acesso a graph. Os autores chamam esse modelo de “vertex-centric”, realizando o mesmo que a função Apply do modelo GAS, ou o mesmo que a função compute do modelo Pregel, que é ainda mais restritivo, pois apenas fornece dois buffers de mensagens (limitados a digrafo), sendo entrada e saída. Em nosso estudo de caso, usamos apenas a primeira forma, pois nos permitiu atingir resultados de desempenho competitivos com o estado da arte.

• scatter: método usado para enviar dados ao iterador de saída (output_messages), sendo chamado uma única vez pelo GUSTY. Ativado após a etapa compute, supõe-se

que o desenvolvedor já tenha realizado suas computações otimizadas, possivelmente com tabelas hash e tenha explorado todo o poder de processamento do hardware, para finalmente liberar seus dados para partições vizinhas.

Embora com suas devidas finalidades, os três métodos discutidos podem ser usados conforme requisito de algoritmo ou mesmo técnica do desenvolvedor. Por exemplo, o iterador de saída output_messages está sempre disponível, podendo ser usado inclusive dentro de unroll, caso essa lógica seja útil. A Figura 35 apresenta um típico caso de como ocorre uma iteração GUSTY usando esses métodos. Vê-se que, no primeiro unroll, graph está vazio e deve ser

criado através de instâncias do tipo InputBinInstance, recebidas com o valor do vértice na cor branca (padrão). Com o GRAPH devidamente instanciado e unroll finalizado, inicia-se

compute, que deve construir a cor de cada vértice a partir do branco. Vértices cuja consistência não é de responsabilidade da partição permanecem brancos. Após isso, o scatter é ativado. Como o corte, vértices principais devem replicar suas cores aos espelhos. Além disso, vértices

adjacentes ao principal e que estejam em outras partições devem inserir suas cores no iterador de saída da partição. Dessa forma, no próximo unroll, é possível recolher a cor quando ela chegar ao iterador de entrada, na forma de par chave/valor. A partir disso, todos conhecem as cores de todos, possibilitando cálculos de novas cores a partir de cores atuais. Nesse contexto abstrato, cores podem ser qualquer tipo de dados, como um rank (PageRank), um caminho de um vértice fonte até algum vértice destino (SSSP), o identificador de um triângulo (TriangleCount). Esses referidos algoritmos são significativamente explorados por plataformas que processam grafos grandes. Portanto, fazem parte do estudo de caso deste trabalho, sendo explicados nas seções seguintes.