Processamento de Dados Massivos/Outros ambientes: diferenças entre revisões

Para a automação de consultas, dois dos primeiros sistemas desenvolvidos são os ambientes Pig <ref> </ref> e Hive <ref> </ref>, desenvolvidos originalmente pela Yahoo! e Facebook, respectivamente, e posteriormente distribuídas como código aberto.

Pig <ref> </ref> oferece uma linguagem de consultas procedural, algumas vezes comparada a Perl, para a expressão de tarefas sobre arquivos que representam uma base de dados organizada como linhas de texto representando registros. O trecho de código a seguir ilustra o uso de Pig para consultar um arquivo com registros de URLs com suas categorias e seu valor de ''pagerank'' (PR), calcular o PR médio para cada categoria e exibir apenas aquelas com PR acima de um mínimo e com quantidade alta de URLs.

Hive <ref> </ref>, por outro lado, se apresenta como um sistema de armazém de dados com uma linguagem de consulta que é próxima a um subconjunto de SQL. Tabelas são normalmente definidas como arquivo textuais com campos separados por tabulações. Em Hive, a mesma consulta anterior tomaria a forma de uma consulta semelhante a SQL, como ilustrado a seguir. O ambiente de processamento se encarregaria de transformar a consulta em uma sequência de ''maps'' e ''reduces'' que geraria o resultado desejado. Comandos adicionais poderiam ser usados para produzir um arquivo como saída.

Diversas soluções para estruturação dos arquivos armazenados no GFS ou HDFS de forma mais eficiente para consultas já foram propostas e são largamente utilizadas. Essas soluções são em geral sistemas de armazenamento denominados “chave-valor” (''key-value stores''), onde a informação é armazenada em função de uma chave pré-definida. Esses sistemas, ao contrário da interface padrão do sistema de arquivos, permitem consultas e atualizações de conteúdo associado a qualquer chave. Exemplos de sistemas desse tipo são o BigTable <ref> </ref>, proposta original da Google, o HBase <ref> </ref>, uma implementação do mesmo conceito para o Hadoop, e outros, como Apache Cassandra <ref> </ref> e Dynamo <ref> </ref>. Em geral, esses sistemas garantem apenas consistência eventual do conteúdo e oferecem compromissos diferentes de implementação em função de diferentes requisitos de aplicação.

Outras soluções buscam novas formas de organização dos dados que ofereçam maior estrutura para os dados e poder de expressão nas consultas, bem como formas de organização que permitam a criação de bases de dados distribuídas geograficamente entre diversos ''datacenters''. Exemplos de projetos nessa linha incluem Megastore <ref> </ref> e Spanner <ref> </ref>, ambos da Google, PNUTS <ref> </ref> da Yahoo!, Dremel <ref> </ref> e outros.

O ambiente de processamento Anthill <ref> </ref> foi desenvolvido no DCC/UFMG para dar suporte a um ambiente de mineração de dados em larga escala denominado Tamanduá <ref> </ref><ref> </ref>. Seu modelo de programação se basea no paradigma denominado filtro-fluxo (''filter-stream''), onde o processamento é descrito como operações executados por filtros que processam um fluxo de dados que passa por eles. Cada filtro é descrito de forma que múltiplas instâncias possam ser criadas para processar elementos do fluxo em paralelo, obtendo paralelismo de dados. Filtros podem ser encadeados de forma a executar diversas etapas de processamento sobre um fluxo, transformando os dados a cada estágio, criando paralelismo de tarefas. Um exemplo de uma aplicação com quatro filtros é ilustrada na figura a seguir.

Alguns outros ambientes de programação também evitam as limitações do MR/Hadoop relacionadas ao uso de arquivos para comunicação. Em particular, o Dryad <ref> </ref>, da Microsoft, permite que o usuário represente seu processamento como um grafo direcionado, também seguindo o modelo filtro-fluxo. No caso do Dryad, uma linguagem especial oferece construtores para que o programador construa o grafo de comunicação. O ambiente de execução cuida da comunicação e o escalonamento de tarefas a partir de então.

A natureza contínua dos dados torna complicado o uso de sistemas baseados em arquivos, como o Hadoop. Essa orientação a arquivos exige que os dados sejam armazenados a cada unidade de tempo (dia, hora, etc.), causando um atraso entre o momento de coleta e processamento. No DCC-UFMG, com base na experiência com o Anthill, foi desenvolvido o Watershed <ref> </ref>, onde os elementos de processamento são orientados a fluxos ininterruptos. Outros sistemas orientados a ''streams'' incluem o IBM S4 <ref> </ref>, rebatizado InfoSphere Streams, e o Twitter Storm <ref> </ref>, recentemente liberado como projeto de código aberto.

Frente a esses problemas, a própria Google desenvolveu um ambiente de processamento específico para esse contexto, o Pregel <ref> </ref>, baseado no paradigma de processamento ''bulk synchronous'' (BSP) <ref> </ref>. Nesse modelo, os algoritmos são expressos do ponto de vista de cada nó, que pode trocar mensagens com outros nós do grafo (não só seus vizinhos). A execução progride em etapas denominadas ''supersteps'', em que cada nó primeiramente recebe todas as mensagens enviadas para ele no ''superstep'' anterior, executa o algoritmo a ele assinalado e envia mensagens para outros nós (que só serão entregues ao final do ''superstep''). Apesar de forçar a ocorrência de barreiras de sincronização, esse modelo escala bem para grafos muito grandes e simplifica as questões de consistência entre nós, já que a comunicação só ocorre entre ''supersteps''. Uma implementação de código aberto do Pregel foi realizada no DCC/UFMG, resultando no sistema Rendero <ref> </ref>.

Para grafos que não atingem as dimensões daqueles para que o Pregel foi criado, o modelo BSP limita a eficiência do processamento. O ambiente GraphLab <ref> </ref> segue uma linha completamente diferente de operação, relaxando as restrições e garantias de consistência no processamento dos nós. O algoritmo também deve ser expresso em termos de nós, mas é permitido a um nó acessar (e alterar) atributos associados às arestas e aos nós vizinhos. Esse recurso aumenta a facilidade de execução em paralelo de diversos nós, mas transfere para o programador a responsabilidade de lidar com o impacto devido a possíveis inconsistências.