Diferenças entre edições de "Processamento de Dados Massivos/Outros ambientes"

m
sem resumo de edição
(Criou nova página com '= Outros ambientes = Apesar de sua larga aplicação, é importante observar que o modelo MapReduce e o Hadoop têm limitações. Primeiramente, muitas aplicações req...')
 
m
Muitas das tarefas desenvolvidas em sistemas de processamento de dados massivos ainda se assemelham muito a consultas tradicionais em bancos de dados relacionais. Realizar uma projeção, uma seleção ou um ''join'' sobre um conjunto de linhas de entrada exige uma ou mais sequências de ''maps'' e ''reduces''. Para simplificar a tarefa dos usuários nesses casos, diversos tipos de sistemas de gerência de dados foram propostos e implementados sobre a plataforma Hadoop ou em outros contextos semelhantes. Esses sistemas costumam ser denominados de forma geral como NOSQL, usualmente interpretado como “Not Only SQL”, em contraposição à linguagem de consulta usualmente utilizada em bancos de dados relacionais.
 
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.
 
<pre>urls_ok = FILTER urls BY pagerank &gt; 0.25
</pre>
 
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.
 
<pre>SELECT categoria, AVG(pagerank)
</pre>
 
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.
 
== Anthill ==
 
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.
 
[[Imagem:Exemplo_Anthill.png|Center]]
A comunicação entre filtros no Anthill se dá por canais de comunicação na rede, sem o uso de arquivo intermediários, o que reduz a latência e aumenta a possibilidade de exploração de paralelismo por operações que podem ser superpostas à comunicação. Além disso, o Anthill permite a expressão de fluxos de comunicação com realimentação, onde o resultado de uma etapa do processamento é injetado de volta em um estágio anterior da cadeia de filtros. Esse recurso possibilita a implementação eficiente de algoritmos cíclicos como os encontrados em aplicações de mineração de dados que operam com o refinamento de soluções intermediárias.
 
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.
 
== Fluxos de dados (''streams'') ==
A operação contínua de serviços em nuvem tem gerado diversas fontes de dados ininterruptas que criam novas possibilidades de processamento e novas demandas. No Observatório da Web, uma parte do processamento consiste na observação de mensagens enviadas pelo Twitter. Um extrator obtém continuamente novas mensagens (''twits'') sobre um determinado tema, de onde são extraídas as ''hashtags'' usadas e as palavras usadas para posteriormente se fazer a análise do conteúdo.
 
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.
 
== Grafos ==
Outro contexto que tem ganhado atenção da comunidade é aquele das aplicações de processamento de grandes grafos, que surgem da representação de relacionamentos entre usuários em redes sociais, por exemplo. Apesar de haver muitos trabalhos sobre o uso de Hadoop nesses casos, a maioria dos algoritmos sobre grafos tem características que não se adaptam bem ao modelo MapReduce. Esses algoritmos frequentemente exigem diversas iterações sobre o conjunto de dados, bem como padrões de comunicação irregulares ditados pela estrutura dos grafos considerados. Essas oprações são difíceis de representar como etapas de mapeamento e redução isoladas.
 
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.
 
{{AutoCat}}
 
==Referências==
 
<references/>
49

edições