Raw e RawI: operadores algébricos estendidos na SciWfA para extrair

Apesar da abordagem algébrica do SCC apresentar três procedimentos para descrever a execução de uma ativação (i.e., instrumentação, execução e extração), a álgebra relacional para workflows científicos, conhecida como SciWfA (OGASAWARA et al., 2011), não permite descrever a extração e a indexação de dados científicos em uma transformação dos dados. Nesse sentido, essa álgebra foi estendida nesta tese, adicionando- se dois operadores algébricos para permitir a extração e a indexação de dados científicos, sendo esses novos operadores algébricos conhecidos como Raw e RawI, respectivamente. Semelhante aos operadores originais do SCC, os operadores Raw e RawI devem apresentar o tipo da atividade operada, os operandos adicionais e a relação de entrada. Como operandos adicionais, esses operadores necessitam de duas informações: o nome do atributo da relação de entrada que apresenta como valores as referências para os arquivos a terem seu conteúdo extraído e os nomes dos atributos que precisam ter seus valores capturados desses arquivos.

Ademais, o tempo de processamento computacional pode variar de acordo com o operador algébrico. Para o operador Raw, existe apenas um comportamento possível: a invocação de programas externos para extrair dados científicos de arquivos. Logo, a especificação da transformação de dados deve contemplar a linha de comando para invocar os programas externos. Já o operador RawI permite dois comportamentos possíveis: a invocação de ferramentas alternativas, como o FastBit; ou o uso de algoritmos desenvolvidos em determinados cartuchos da arquitetura RDC para indexar dados científicos acessados em arquivos. Consequentemente, a invocação de ferramentas alternativas exige a especificação da linha de comando para executar essas ferramentas, ao especificar a transformação de dados, enquanto que o uso de cartuchos com algoritmos próprios requer apenas a identificação do cartucho a ser utilizado. No contexto desta tese, desenvolveu-se dois cartuchos com algoritmos próprios na arquitetura RDC, mas inspirados

68

em soluções existentes, como o Cartucho FITS10 e o Cartucho CSV baseado na geração de índices posicionais, conforme a proposta do NoDB (ALAGIANNIS et al., 2015). Vale ressaltar que, caso seja de interesse do usuário, as invocações para as ferramentas alternativas podem ser acopladas como um cartucho com algoritmo próprio, sem que o usuário tenha que ter conhecimento de como deve invocar essas ferramentas para indexar os dados científicos.

Além disso, a relação do número de tuplas consumidas e produzidas varia consideravelmente nesses operadores algébricos, pois depende da quantidade de arquivos analisados e do próprio volume de dados presente nesses arquivos. Portanto, essa relação pode ser representada por 1:n, a fim de que a operação desempenhada pelo operador Raw ou RawI apresente o comportamento mais genérico possível (i.e., expressando que cada arquivo de entrada pode extrair um ou mais elementos de dados científicos). Nessa circunstância, assume-se que cada invocação desses operadores é responsável por acessar e, eventualmente, indexar dados científicos presentes em apenas um arquivo. Diante dessas informações, os operadores algébricos Raw e RawI podem ser especificados formalmente, conforme apresentado abaixo:

𝑅𝑒𝑙𝑎çã𝑜𝑠𝑎í𝑑𝑎← 𝑅𝑎𝑤 ( 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑎𝑒𝑥𝑡𝑒𝑟𝑛𝑜, { {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑎𝑟𝑞𝑢𝑖𝑣𝑜𝑠}, {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠𝑎𝑐𝑒𝑠𝑠𝑎𝑑𝑜𝑠} }, 𝑅𝑒𝑙𝑎çã𝑜𝑒𝑛𝑡𝑟𝑎𝑑𝑎 ) (2) 𝑅𝑒𝑙𝑎çã𝑜𝑠𝑎í𝑑𝑎← 𝑅𝑎𝑤𝐼 ( 𝐹𝑒𝑟𝑟𝑎𝑚𝑒𝑛𝑡𝑎𝑎𝑙𝑡𝑒𝑟𝑛𝑎𝑡𝑖𝑣𝑎 𝑜𝑢 𝐶𝑎𝑟𝑡𝑢𝑐ℎ𝑜𝑖𝑛𝑑𝑒𝑥𝑎çã𝑜, { {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑎𝑟𝑞𝑢𝑖𝑣𝑜𝑠}, {𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠𝑎𝑐𝑒𝑠𝑠𝑎𝑑𝑜𝑠} }, 𝑅𝑒𝑙𝑎çã𝑜𝑒𝑛𝑡𝑟𝑎𝑑𝑎 ) (3)

Diferentemente da álgebra original de workflows científicos, i.e., SciWfA, essa extensão da álgebra também considerou que os operadores Raw e RawI só podem ser especificados em uma certa atividade do workflow, quando um dos outros operadores algébricos (Map, SplitMap, Reduce, Filter e Query) também for definido anteriormente nessa mesma atividade. Essa especificação caracteriza a extração e a indexação de dados como um pós-processamento de dados para uma determinada atividade, a fim de representar os dados produzidos em uma relação de saída.

69

A Figura 10(a) mostra um exemplo de atividade (denominada de A) sem extração de dados, que é composta apenas pelo operador algébrico Map. Enquanto isso, a Figura 10 (b) e a Figura 10(c) mostram atividades, denominadas de Ae e Ai, sendo regidas pelos

operadores algébricos Raw e RawI para permitir a extração e a indexação de dados científicos, respectivamente. A extração de dados desse exemplo considera a invocação de um programa externo, conhecido como extractData, enquanto que a indexação de dados é baseada na invocação da ferramenta alternativa FastBit. Os arquivos de dados científicos seguem o formato CSV, sendo especificados como operandos adicionais, enquanto os valores dos atributos a1, a2 e a3 são capturados dos arquivos CSV.

Além das contribuições associadas ao formalismo das transformações de dados ao longo da simulação computacional, a extensão da álgebra de workflows científicos apresenta vantagens relacionadas às análises exploratórias de dados científicos. Dado que os operadores algébricos Raw e RawI permitem a captura de dados científicos presentes em arquivos, análises, que levam em consideração o conteúdo específico do domínio, podem ser tratadas a partir do processamento de consultas à base de dados de proveniência. Ao mesmo tempo, estruturas de dados que antes apresentavam um alto custo para o seu armazenamento na base de dados de proveniência por meio da extração de dados, agora podem contar com a extensão da álgebra para aplicar técnicas de indexação. Dessa forma, o uso do operador RawI permite o armazenamento dos índices referentes ao conteúdo desses arquivos na base de proveniência, assumindo um espaço reduzido em comparação com a carga dos valores dos atributos.

Figura 10. Atividades usando a SciWfA estendida: (a) sem extração/indexação, (b) com extração e (c) com indexação de dados científicos.

70

Por exemplo, ao invés de armazenar os valores dos elementos de uma matriz, o operador algébrico pode ser responsável por indexar a posição de início da matriz, o número de elementos e o tamanho de cada elemento de dados. Ao ser necessário utilizar o valor propriamente dito do atributo por uma consulta ou mesmo pela própria máquina de execução paralela, o acesso a esse valor de atributo pode ser obtido por meio dos índices gerados e armazenados na base de dados de proveniência. Como protótipo de índices posicionais desenvolvidos nesta tese, considerou-se as estruturas de índices para os seguintes tipos de dados (Tabela 3): numérico, textual, arquivo, lista, matriz e malha.

Estrutura

de dados Formato do índice

Numérico [posição_início, tamanho]

Textual [posição_início, tamanho]

Arquivo [posição_início, tamanho]

Lista [posição_início, tamanho, elementos, delimitador] Matriz [posição_início, tamanho, linhas, colunas, delimitador] Malha [posição_início, tamanho, xdepth, ydepth, zdepth, delimitador]

Tabela 3. Estruturas de dados apoiadas pelo operador RawI.

Destaca-se também que cada estrutura de dados apresenta sua própria construção de índices. No caso de valores numéricos, textuais e arquivos, os índices apresentam a posição de início e o número de posições ocupadas por ele, ou seja, o seu tamanho. Já as estruturas de dados para listas, matrizes e malhas, além de possuírem a especificação da posição inicial e do tamanho de cada elemento, elas apresentam um delimitador e o número de elementos em cada uma de suas dimensões de representação. Ou seja, para uma matriz, duas dimensões são definidas para expressar o número de elementos (e.g., linhas e colunas). Vale ressaltar que assumimos tamanhos fixos para a representação de conteúdos que seguem as estruturas de dados de lista, matriz e malha. Portanto, o segundo elemento (tamanho) no formato do índice não deveria estar presente na representação dessas estruturas de dados.

Existem circunstâncias também em que após o processamento de um modelo computacional, os usuários necessitam extrair dados de diferentes formatos de arquivos e que, para isso, eles devem utilizar um algoritmo de extração ou de indexação de dados científicos para cada formato de arquivo. Assim, o pós-processamento pode ser

71

caracterizado pela execução de extratores e/ou indexadores de forma paralela, conforme mostrado na Figura 11. Entretanto, a definição de uma atividade pela álgebra de workflows científicos corresponde a uma transformação de dados, que consome uma relação de entrada e produz uma relação de saída (OGASAWARA et al., 2011). Logo, a execução paralela dos extratores produz várias relações de saída, o que contradiz a definição de uma atividade. Ao mesmo tempo, do ponto de vista de uma atividade, os resultados de extração apresentam um significado semântico para o modelo computacional executado pelo operador algébrico antes dos operadores Raw e RawI. Logo, tais operadores não podem ser separados conceitualmente em uma outra atividade.

Somando-se a isso, os dados científicos obtidos nos operadores Raw e RawI normalmente estão relacionados. Logo, considerou-se a definição de outro operador algébrico na SciWfA, conhecido como Join, com o objetivo de associar os elementos de dados (i.e., dados científicos) obtidos por mais de um operador dos tipos Raw ou RawI. Logo, esse operador permite que apenas uma relação de saída seja gerada ao término de uma atividade. A Figura 11 mostra um exemplo de atividade com dois operadores de extração/indexação de dados e o uso do operador Join. Para a especificação do operador Join, deve-se informar o algoritmo de junção a ser aplicado (e.g., equi-junção), os atributos de junção (representados como operandos adicionais, e.g., a1) e as relações de entrada (i.e.,

relações de saída após a execução dos operadores Raw e RawI). Formalmente, o operador Join pode ser definido da seguinte forma:

𝑅𝑒𝑙𝑎çã𝑜𝑠𝑎í𝑑𝑎← 𝐽𝑜𝑖𝑛(𝐴𝑙𝑔𝑜𝑟𝑖𝑡𝑚𝑜𝑗𝑢𝑛çã𝑜, { 𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 }, 𝑅𝑒𝑙𝑎çõ𝑒𝑠𝑒𝑛𝑡𝑟𝑎𝑑𝑎) (4)

72

Capítulo 5 – DfAnalyzer: componentes para a análise de dados