A Tabela 3 apresenta os frameworks discutidos neste capítulo e suas características. A metodologia para identificação dessas características se baseia em uma revisão sistemática, após aplicação de comandos (strings) de buscas nos meios digitais ACM, IEEE, Scopus, Springer, Science Direct. Dentre os artigos lidos, destacam os Surveys (DOEKEMEIJER; VARBANESCU, 2014; MCCUNE et al., 2015), que apresentam resultados compatíveis. A tabela possui a seguinte organização:
• Computação: divide-se em V/G/M, respectivamente referente ao modelo de programação com abstração em vértices, grafos/subgrafos, matrizes, bem como de propósito geral com (PG); pulL/pusH (L/H) referente à direção das informações; Fases, refere-se à quantidade de etapas adotadas para iniciar um novo ciclo de iteração;
• Execução: síncrona (S), assíncrona (A) e híbrida (H); • Ambiente: distribuído (D) e centralizado (C);
quando excedem a capacidade de memória;
• Partição: a partição dos dados é estática, dinâmica ou não se aplica (Não), devido ao uso de memória compartilhada pelo framework;
• Mutável: quando a plataforma permite mutação do grafo durante o processamento (Sim ou Não).
Computação
V/G/M/PG pulL/pusH Fases Execução Ambiente OutOfCore Partição Mutável
GUST** G/V L/H 1 ou 2 H D Não Estática Não
BPP V L 1 A C Sim Não sim
ExPregel V H 1 S D Sim Estática sim
Giraph V H 1 S D Sim Estática sim
Spark GraphX G L/H 2 H D Sim Estática sim
Giraph++ G/V L/H 1 H D Não Estática sim
Giraphx V L 1 A C Não Estática sim
GoFFish G L 1 A D Não Estática não
GPS V H 1 S D Não Dinâmica sim
Grace V L 1 H C Não Não não
GraphChi V L 1 A C Sim Não sim
GraphHP V H 2 H D Não Estática não
GraphLab V L 3 A C Não Não não
GasCL V L 3 A C Não Não não
Kineograph V L/H 1 H D Não Estática não
LFGraph V L 1 S D Não Estática não
Mizan V H 1 S D Não Dinâmica sim
PowerGraph V L/H 3 H D Não Estática não
PowerSwitch V L/H 3 H D Não Estática não
Pregel V H 1 S D Não Estática sim
Pregelix V H 1 S D Sim Estática sim
Presto M H 1 S D Não Dinâmica não
Signal/collect V H 2 H C Não Não não
Trinity V L/H 1 H D Não Estática não
Twister* PG H 2 S D Não Não não
X-Stream V H 2 S C Sim Não sim
MR-MPI PG H 2 S D Sim Estática sim
*MapReduce iterativo usando publish/subscribe.
**Arcabouço de componentes (deste trabalho) que utiliza fluxo computacional (Workflow).
Tabela 3 – Tabela de características.
Dos modelos apresentados neste trabalho, destacam-se MapReduce, Pregel e GAS, a partir dos quais frameworks foram desenvolvidos e ofereceram algum tipo de contribuição relevante envolvendo computação em grafos de larga escala. Existem grupos de características que são compartilhadas nessas plataformas, como o tipo de programação, comunicação, particio- namento, ambiente, uso de memória e estratégia de cada iteração organizada em fases. Cada característica oferece algum tipo de benefício para o algoritmo, mas eventualmente são exclu- dentes. Por exemplo, o framework PowerGraph, que implementa o modelo GAS, permite definir se haverá ou não sincronismo na atualização de vértices. Sua versão híbrida, o PowerSwitch, faz experimentos com os algoritmos PageRank, SSSP, Coloração de grafos e LBP-Loopy Belief Propagation, chegando-se à conclusão de que o assincronismo nem sempre é rentável para
atingir melhor tempo de execução. PowerSwitch se apoia em heurísticas para decidir quando um modo síncrono é viável. Entretanto, ele ainda não suporta computação centrada em sub- grafos, característica útil quando existe computação intensa de muitos vértices, resolvendo um problema local para posterior troca de mensagens e resolução do problema global. Suportando características do PowerGraph e Pregel, o Spark GraphX tem representado o estado-da-arte para processamento de grafos, especialmente no aspecto arquitetura, uma vez que em desempenho não superou seu precursor PowerGraph. Contudo, suporta subgrafos e tem oferecido aspectos técnicos importantes, como iteratividade com o usuário, através de um terminal de comandos em linguagem funcional Scala. Em um cluster que roda Spark, deve-se ajustar os XML’s Spark com a configuração do cluster, ou parametrizar a execução de aplicações por linha de comando7, para
instanciar um objeto do tipo SparkContext, que permite a paralelização de RDDs nos termos da arquitetura do cluster. Um cluster Spark deve ter seus parâmetros rigorosamente configurados, especialmente para processar grandes grafos. Nesses problemas, apesar do sistema de arquivos distribuído, a memória é exigida, e seguem os limites das máquinas virtuais, que devem controlar muitos objetos.
Neste trabalho, introduz-se um arcabouço de componentes paralelos para suportar grafos. Nele, o componente controlador da estrutura de dados utiliza tipos primitivos ao invés de objetos, reduzindo a exigência de memória. Esse arcabouço contribui com o estado-da-arte em alguns aspectos, tais omo: utilização de arquitetura baseada em componentes paralelos; suporte a requisitos da HPC Shelf, uma nuvem de componentes destinada à execução de aplicações em um ou mais clusters, os quais são plataforma virtuais vinculadas ao contexto da aplicação. Nos próximos capítulos, introduzem-se os conceitos para atingir essas contribuições, iniciando com definições e atributos da nuvem de componente HPC Shelf.
4 HPC SHELF
HPC Shelf é um conceito de plataforma orientada a componentes para provimento de serviços de computação de alto desempenho, sob a abstração de nuvens computacionais. Através de uma aplicação da HPC Shelf, usuários ditos especialistas podem descrever problemas, possivelmente usando abstrações de alto nível, dentro de um determinado domínio de interesse, cuja solução demanda inerentemente por grande capacidade computacional, possivelmente extrapolando a capacidade oferecida por plataformas de computação paralela as quais o usuário tem acesso. Para solução desses problemas, a HPC Shelf oferece sistemas de computação paralelaconstruídos através da composição e orquestração de componentes paralelos do modelo Hash, através da tecnologia de workflows científicos.
Sistemas de computação paralela executam sobre infraestruturas de computação paralela potencialmente oferecidas por diferentes centros de computação. Para isso, utilizam a abstração de plataformas virtuais, as quais representam plataformas de computação paralela instanciadas sobre tais infraestruturas, possivelmente usando mecanismos de virtualização já difundidos em nuvens computacionais. Plataformas virtuais são tratadas sob a visão de componentes da espécie plataforma, do modelo Hash. O conjunto de plataformas virtuais, disponibilizado através da HPC Shelf para atender as aplicações representa a infraestrutura computacional da HPC Shelf.
Como ilustrado na Figura 19, uma aplicação da HPC Shelf pode ser enxergada como uma nuvem to tipo SaaS (Software-as-a-Service), implementada sobre um framework de aplicações, conhecido SAFe (Shelf Application Framework), o qual, por sua vez, constitui uma nuvem do tipo PaaS (Platform-as-a-Service). Finalmente, a infraestrutura de computação sobre a qual as plataformas virtuais são instanciadas forma uma nuvem IaaS (Infrastructure-as-a-Service) sob a perpectiva do SAFe.
As seções a seguir apresentam maiores detalhes sobre a plataforma HPC Shelf. Porém, inicialmente, são apresentados alguns fundamentos necessários sobre as tecnologias de componentes de software aplicada no contexto de Computação de Alto Desempenho.