Modificações complementares

Durante o processo de criação do ChironSN, bem como durante a avaliação experimental, algumas possibilidades de modificações foram detectadas. Algumas delas

40

estavam ligadas a melhorias no código, com relação ao aproveitamento dos recursos computacionais. Outras modificações foram motivadas pela análise de resultados obtidos na realização de experimentos preliminares.

Essa seção apresenta tais modificações, e como elas se integram ao ChironSN. Um fator comum entre elas é que todas são aplicáveis apenas às atividades cujo operador algébrico prevê a execução de um programa pelas ativações.

3.3.1 Adição de tipos de atributo de relação

A descrição conceitual de um workflow científico processado pelo Chiron prevê três opções que o cientista pode utilizar para definir o tipo dos atributos que compõem uma relação: float (número), string (texto) e file (referências a arquivos). Cada um desses tipos é mapeado para uma coluna de uma tabela na base de dados de proveniência, onde o valor do atributo é armazenado.

Para a maioria dos workflows, esses tipos são suficientes para representar os dados manipulados. Entretanto, o tipo string é mapeado para uma coluna com 250 caracteres de tamanho, o que pode dificultar experimentos que precisem manipular longas cadeias de texto. Para os experimentos desta dissertação, o tipo text foi incluído à implementação do ChironSN, que é mapeado para o tipo de mesmo nome na base de dados, permitindo que textos de qualquer extensão sejam utilizados como valores.

Uma situação diferente diz respeito ao tipo float, que parece exagerado quando o

workflow precisa lidar apenas com números naturais ou inteiros. O tipo float aceita um

parâmetro opcional onde se define a quantidade de casas decimais, mas do ponto de vista computacional, ele não deixa de ser estrutura de dados que ocupa pelo menos o dobro de espaço em memória que um número natural/inteiro. Em vista disso, o tipo

integer também foi adicionado à implementação do ChironSN.

3.3.2 Quantidade variável de tuplas por ativação

A álgebra que suporta o Chiron não especifica uma quantidade de tuplas que deve ser consumidas em uma ativação. Todavia, a implementação do Chiron considera apenas uma tupla sendo consumida por ativação, balizada pelo comportamento usual onde as ativações manipulam arquivos cujas referências estão contidas naquela tupla transmitida.

41

Quando as tuplas contêm os dados reais, sem referências a arquivos, o tempo de processar uma tupla em um nó remoto tende a ser menor que os tempos gastos com transmissão da mensagem MPI, inicialização da ativação e extração dos dados produzidos. Utilizar despacho estático e enviar um conjunto de ativações de uma só vez é uma opção, mas se considerarmos ativações de uma mesma atividade, todas elas terão instruções semelhantes, variando apenas a tupla com os dados a serem consumidos.

Sendo assim, a melhor opção é agrupar essas tuplas e enviar dentro de uma única ativação, ao invés de criar uma ativação para cada tupla. Com isso em mente, o parâmetro numTuplesPerActivation foi incluído como parâmetro de execução das atividades, sendo aplicado no momento em que as ativações são criadas. A Figura 12 mostra como utilizar o parâmetro no XML de descrição do experimento.

Figura 12 - Utilização do parâmetro numTuplesPerActivation

Qualquer valor positivo é válido, e será a quantidade de tuplas que o ChironSN alocará para cada ativação. O valor -1 é usado quando se deseja que o ChironSN envie uma ativação para cada uma das linhas de execução aptas a processar ativações, considerando todas as instâncias do ChironSN ativas. Nesse caso, a quantidade de tuplas por ativação será a divisão entre o total de tuplas de entrada e o total dessas linhas de execução. Quando o parâmetro é omitido, utiliza-se o comportamento padrão do Chiron, de uma tupla por ativação.

Em atividades de Reduce, vários fragmentos horizontais agrupados pelos respectivos atributos podem ser incluídos em uma mesma ativação. Se o valor do parâmetro numTuplesPerActivation é alcançado no meio de um fragmento, as tuplas continuam sendo adicionadas à ativação até que esse fragmento esteja completo. Esse parâmetro é ignorado quando as tuplas de entrada contêm pelo menos uma referência a arquivo.

42

3.3.3 Criação das Ativações

Nessa etapa do ciclo de execução do Chiron, as tuplas da relação de entrada de uma atividade são alocadas para as ativações que irão processá-las. Essas tuplas são identificadas por um código único e sequencial, gerado no momento de inserção na base de proveniência, e cada ativação armazena os códigos das tuplas alocadas para ela. Duas modificações foram feitas na consulta que itera sobre as tuplas de uma relação e extrai os códigos que serão vinculados às ativações.

A primeira alteração foi no conjunto de atributos que eram incluídos na consulta. Na base de proveniência, uma tupla contém o valor dos atributos e o seu código identificador. A consulta incluía todos esses campos, sendo que o único necessário era o código, pois nessa etapa o importante é a quantidade, e não o conteúdo das tuplas. Na nova versão da consulta, apenas o código é considerado na projeção. Um caso particular é a consulta das tuplas para uma atividade de Reduce, onde o valor do atributo de agrupamento também é incluído na projeção.

A segunda alteração consistiu em alterar o modo de execução da consulta, a fim de evitar que todas as tuplas fossem recuperadas do banco de dados e armazenadas em memória, de uma só vez. As tuplas agora são iteradas através de um cursor que recupera os dados do banco em blocos. Conforme as tuplas de um bloco são iteradas, um novo bloco é recuperado do banco. Essa medida reduz as chances de falhas por insuficiência de memória RAM.

3.3.4 Transmissão das tuplas para as ativações

A utilização de uma quantidade variável de tuplas por ativação (numTuplesPerActivation) originou um problema relacionado ao tempo de resposta da linha de execução que processa as solicitações de ativações. As mensagens MPI recebidas são tratadas sequencialmente, e é importante que essas mensagens sejam respondidas o mais rápido possível com ativações prontas para execução. Uma fila de mensagens não respondidas representa ociosidade nos nós que contêm instâncias executoras do ChironSN.

Quando a quantidade de tuplas por ativação aumentou, o tempo para responder a mensagem também aumentou, visto que mais dados passaram a ser recuperados do banco e inseridos na ativação que seria enviada na mensagem MPI. Há de se destacar

43

que uma mensagem de solicitação recebida normalmente contém uma ativação já executada, com dados produzidos que devem ser salvos na base de dados.

Para contornar esse problema e manter baixo o tempo de resposta às solicitações, optou-se por criar uma etapa anterior à execução das ativações, onde são escritos em disco arquivos que contêm as tuplas que cada ativação irá processar. Cada um desses arquivos é salvo já nos respectivos diretórios de execução de cada ativação. Essa etapa é executada independentemente do sistema de arquivos escolhido para o experimento. Quando o HDFS está sendo utilizado, a localização desses arquivos criados também é considerada no momento em que o ChironSN seleciona as ativações para execução.

Outra modificação feita para minimizar os tempos de transmissão de mensagens foi mover para a instância coordenadora a extração dos dados produzidos pelas ativações. Ao invés da instância executora extrair os dados produzidos e enviar através da mensagem MPI, ela envia apenas a notificação de que terminou a execução, e uma linha de execução na instância coordenadora se preocupa em extrair esses dados produzidos e armazená-los na base de proveniência. Quando todas as ativações disponíveis terminam de executar, o ChironSN espera essa linha de execução terminar de extrair todos os dados, para então prosseguir com a execução de outras atividades.

3.3.5 Adição de parâmetro à instrumentação de ativação

Cada ativação tem um diretório próprio, onde arquivos produzidos e consumidos ficam armazenados. Quando o ChironSN invoca a execução do programa associado à ativação, ele o faz de tal forma que o programa seja executado no contexto desse diretório. No entanto, quando esse diretório está no HDFS, isso é impossível.

A solução encontrada para notificar o programa sobre o diretório que deve ser manipulado foi adicionar o parâmetro WORKDIR às opções de instrumentação do ChironSN. Se a linha de comando utilizada por uma ativação para invocar o programa contiver esse parâmetro, este será substituído pelo diretório de trabalho daquela ativação.