Total de visualizações de página

quinta-feira, 29 de dezembro de 2011

Big Data- Parte X- Os Big Data e a cafeína.



Na primeira semana de Novembro, eu retornava  de um jantar com amigos do MPS, quando chegando em casa olhei os “posts” do Twitter. Um deles, contava sobre o caso de uma tentativa de estupro numa Universidade, aqui pertinho de casa, que tinha acabado de acontecer, há não mais do que 2 horas. Naquele evento, na realidade, consumi uma informação  fornecida pelo poder das redes sociais, informação essa que ainda não estava dos domínios do Dr. Google, que, em tese, tudo sabe e tudo informa, ou pelo menos assim deveria. Ou seja, em certas circunstâncias, as redes sociais estão informando antes que o Dr. Google e isso aos olhos atentos de Larry Page e Sergei Brin não é boa coisa. E essa tem sido justamente  uma das preocupações da grande empresa de busca: As informações estão chegando rapidamente à rede, via contatos sociais, mas  demoram um pouco mais para serem pescadas pelos  seus analisadores de páginas web, que vasculham o universo digital. No início do mês de Novembro, a gigante anunciava uma mudança nos seus métodos e algoritmos de buscas, a fim de produzir respostas mais atualizadas. Essa mudança é o reconhecimento pela Google de sua dependência da atualidade da informação e de certa forma, da sombra de ameaça que as redes sociais estão trazendo para cima da maior empresa de informações do planeta. Os resultados de um jogo de futebol, nas tardes de domingo, aparecem muito mais rapidamente no Twitter, FB,etc , com comentários inclusive, e somente depois são pescados pelos “crawlers” do Google. As redes sociais, por seu lado, tem incentivado fortemente  a colocação de informações em tempo real, criando um ambiente com o maior grau possível de atualidade. Bem que a gigante de Mountain View já havia tentado um acordo com o Twitter a fim de analisar em tempo(quase)  real as suas mensagens de 140 toques. O acordo foi definido por um tempo, mas depois as empresas não convergiram em termos de renovação do acerto e o mecanismo do Google foi desabilitado. É claro que  a Google ainda responde por 66% das pesquisas web nos EUA, mas o americano já está se acostumando a buscar nas redes sociais a informação do tipo “break news” que só depois(horas, minutos?) estará nas estruturas de Big Table da Google.   Nesse campo, o Twitter é imbatível com a sua instantaneidade de 140 batidas e oferece um produto colateral interessante: As informações poderão já vir com certa análise, crítica, percepções de  espanto, alegria, frustação,etc . Ou seja, além da informação “ in-natura”, certas considerações de “sentimento”  poderão tecer o seu contexto. Dai o crescimento de “Sentiment Analysis”, que discutiremos depois.  O Google acostumou o seu público a consumir informações com certa latência. Páginas “velhas” com as indicações sobre os restaurantes em NYC, ou a escalação do Vasco no jogo que já aconteceu são a tônica do grande depósito. O Google tem uma média de 500 alterações  no seu algoritmo por ano e esse desafio de buscar mais atualidade está na tela de radar da  grande empresa. A ideia é analisar os termos de buscas colocados na caixa de pesquisa e tentar entender  o grau de “freshness(sem tradução, por favor) daquilo que está por ser mostrado. No último anúncio de melhoria de sua máquina de busca(fevereiro de 2011), a ideia foi aumentar o ranking de páginas “mais interessantes”, a fim de “esconder” as de baixa qualidade de interesse, que insistem em inundar as pesquisas com artigos de menor interesse, porém atreladas a consultas também populares. Isso, garante o Google, melhorará a disponibilização de informações mais atuais. Essas melhorias estão escoradas no novo método de indexação definido pela Google, que tem o sugestivo nome de “Cafeina” (Caffeine), que além de varrer a teia digital de forma mais rápida, também o fará de forma constante, em vez de latência de algumas semanas, como acontecia. Como cafeína é um composto alcalóide que tem a propriedade de manter as pessoas mais acesas e alertas, o algoritmo, pelo menos no nome, faz todo o sentido......    

quarta-feira, 21 de dezembro de 2011

Big Data- Parte IX- Os Big Data e as formas de armazenamento-Novas soluções-II.



Continuação do post anterior: Discutindo alternativas para implantação de Big Data com novas proposições e estruturações físicas.


Triplestore:
Outra forma de estruturação de dados se avizinha, buscando uma maior flexibilidade na definição dos bancos de dados construídos na era dos zettabytes. É chamada de Triplestore e nasceu como uma forma de embutir dados e metadados na própria estrutura armazenada. Diferentemente dos modelos relacionais que se baseiam na definição de ênuplas(várias colunas com valores, numa relação normalizada), conceito simplificado para tuplas, a abordagem de triplestore chega com uma proposta diferente. A ideia é que a unidade de armazenamento mínima seja uma tripla, ou seja a conjugação de “sujeito” “predicado”  e “objeto”. Por exemplo, “Barbieri” “escreveu” “livro” , ou “Isabella”  “toca”  “violão”, ou “Cláudio”  “tem”  “30”  (idade). Dessa forma, o armazenamento se dá conjugando os metadados com os dados, explicitados através da tripla combinação desses elementos. Isso sugere uma maior flexibilização na incorporação de novos atributos, visto que se insere uma estrutura atômica do modelo, sem impacto direto em conceitos de tabelas, linhas, etc. O modelo se baseia no framework RDF- Resource Description Framework (RDF) . Semelhantemente ao modelo relacional existe também acoplado a ele uma linguagem de acesso e possibilidades de indexações instantâneas. Os gerenciadores de triplestore já se mostram com a capacidade para  armazenar bilhões de triplas e alguns nomes já surgem nesse novo cenário, engrossando os conceitos da Web semântica. Por exemplo, 3store, Allegrograph, Bigdata, BigOWLIM, Sesame, Soprano,Virtuoso,etc são nomes que aparecem nesse cenário de novas alternativas estruturais. O site da W3C http://www.w3.org/wiki/LargeTripleStores mostra uma relação com diversos produtos desta nova cepa e alguns resultados alcançados por mais de 15 desses RDF Data Base Engine. Alguns desses produtos, como Virtuoso apresenta novas formas de indexações com bitmap, tradicionalmente usado em pesquisas de campos de baixa cardinalidade.
Casssandra:
Outra variante de modelo de dados para esses novos tipos de Bancos de dados é, por exemplo, o usado no Cassandra:
a)As colunas, que são as residências das informações, são associadas logicamente em conjuntos chamados “família”. Uma família de colunas pode ter várias colunas, ou até uma outra família dentro dela. As famílias são definidas no momento da criação do BD. Porém, após esse momento, pode-se criar colunas novas dentro daquela família de colunas;
b)As colunas são associadas a chaves específicas, ou seja uma tupla(linha no relacional) pode ter colunas diferentes. No modelo relacional deve-se usar o conceito de “nulos” para as colunas que não tem valores naquela tupla. Os valores de uma família de colunas, associadas a uma chave, são armazenadas juntas.
Em alguns produtos semelhantes, as colunas são armazenadas também contendo as regras de  de domínios, numa espécie de acoplamento dos dados com os seus metadados, todos habitando o mesmo espaço. Isso permite que  consistências e integridades sejam aplicadas no momento de acesso ao dado, agilizando as verificações e manipulações  aplicadas sobre eles e definidas como regras.
MongoDB
Um dos produtos que começa a aparecer nessa nova seara de NoSQL é o MongoDB. Já usado em algumas aplicações específicas em BH, o produto se denomina um Banco de dados de documentos. Na realidade, o conceito de documento apresentado pelo produto pode ser entendido como o de um “objeto complexo”. Semelhantemente aos SGBDOO(Bancos de Dados orientados a objetos) dos anos 80, o Mongo permite sob a capa de um documento, a definição de um objeto complexo.  E o que é um objeto complexo, então? Um objeto complexo é a definição de uma estrutura de dados, totalmente flexível e sem regras estruturais colocadas, como vimos no modelo relacional, ou um pouco nos anteriores(hierárquico e rede). Nessa nova proposta, por exemplo, cada linha(só para dar a equivalência conceitual com os relacionais), pode conter qualquer número de dados associados a uma chave primaria, um Object-id definido internamente. Os dados associados a cada chave podem formar famílias de colunas, sendo que cada coluna pode ser , por sua vez, uma estrutura complexa, como outra família de colunas, ou array, ou apontadores recursivos. Cada linha, identificada, pode ter um número de colunas diferente de outras linhas da mesma Entidade.  Por exemplo, um  certo cliente poderá ter 20 colunas, e outro 100, fugindo um pouco das abordagens de campos nulos, trazidos nos conceitos relacionais, para tornar as linhas homogêneas. Assim, por exemplo,  um documento (objeto) Projeto pode ser formado de dados de projetos, de dados de Equipes, que por sua vez são formadas de dados de Empregados. O que acontece é que o que seriam estruturas bem comportadas em modelos relacionais ou hierárquicos, no MongoDB, pode aparecem como um objeto complexo, como que já “joined” e entrelaçados. Embora com uma estruturação complexa, passível de recursividades, o produto permite que a busca seja feita somente trazendo os pedaços de informações desejadas. Usam a indexação baseada em BTree e permitem acessos muito rápidos em dados estruturados segundo essa concepção. Não oferece conceitos transacionais padrão de ACID e de SQL, ficando por conta do programador a incumbência de estabelecer esses controles, caso desejados. Tem forte vocação para inserções em massa, com dados sem grande volatilidade de modificações. Exatamente como se espera em aplicações como Twitter, Linkedin,Facebook, e-mails, etc onde milhões de “posts”  são inseridos, mas não deletados ou modificados. A sua estrutura de objeto complexo permite a modelagem de informações de forma rica, criando possibilidades de aplicações em gerência de conhecimento, repositórios para produtos de BPM, etc.


Resumo da ópera:

Com a diminuição de custos de armazenamento e a busca por maior rapidez e flexibilidade nas estruturações e pesquisas, o conceito de BI2 também se valerá dessas novas proposições, principalmente para armazenamento de grandes volumes de dados que se mostram como forte tendência nessa década. Existe um conjunto enorme de alternativas desenvolvidas e em desenvolvimento, na sua maioria dentro do espaço dos códigos livres. O segredo para se adotar uma proposição correta  será:
1)Analisar cuidadosamente os seus requisitos de dados(estruturados, semi-estruturados, ou não estruturados), com análise crítica das necessidades de volumes, velocidade de processamento e periodicidade e tipos de atualização;
2)Executar provas de conceitos, usando essas novas propostas e verificando a sua efetiva aplicação no item anterior(requisitos). Essas ferramentas podem ser “baixadas” de núcleos sérios como Fundação Apache, por exemplo;
3)Analisar a relação custo benefício, que envolverá não somente a parte de arquitetura de “nós” , mas também a capacitação da equipe em técnicas em conceitos returbinados como DFMS(Distributed File Management System), processamentos em arquiteturas  paralelas, ambiente de alta tolerância, replicações,etc;
4)Finalmente decidir na teoria do melhor “encaixe” nas necessidades da empresa,  cuidando para deixar de lado o ímpeto pelo uso dos modismos. Lembre-se que para cada problema poderá aparecer uma solução adequada, seja ela o velho e tradicional SGBDD, ou os novos e desafiadores frameworks, como Hadoop/MapReduce, ou soluções NOSQL.
A figura abaixo ilustra os principais conceitos que diferenciam o tradicional modelo relacional e os novos modelos NoSQL.
A figura abaixo ilustra os principais conceitos que diferenciam o tradicional modelo relacional e os novos modelos NoSQL.



Fontes:

Barbieri,C. BI2-Business Intelligence-Modelagem e Qualidade. Elsevier,2011
Roebuck, K. Storing and managing  big data-NoSQL,Hadoop and more
O´Reilly Radar Team. Big Data Now: Current perspectives from O´Reilly Radar
Sydle-Entrevista com a equipe de BD da empresa, sobre a aplicação de MongoDB-Novembro de 2011



sábado, 10 de dezembro de 2011

Big Data- Parte VIII- Os Big Data e as formas de armazenamento-Novas soluções-I.


Com o aparecimento do conceito de Big Data, novas formas de armazenamento e acesso aos dados, agora em escalas muito superiores, começaram a aparecer. Acostumados com os conceitos de Bancos de Dados e de DataWarehouse como sinônimos de depósitos de grandes volumes, a comunidade começou a se inteirar de novos termos e produtos, até então desconhecidos na camada das aplicações tradicionais. Nomes como Hadoop, BigCouch, BigTable, Cassandra, Cloudera, MongoDB, Hive, etc começam a surgir e a serem discutidos como soluções para essa nova fase de estruturação e acesso de grandes volumes de dados, sem uma grife por trás, digamos assim. Marcas desconhecidas no grande mercado dos gerenciadores de dados.
De maneira geral esses produtos podem ser entendidos como participantes de camadas que tem estruturações arquiteturais diferentes. Uns são mais voltados para o armazenamento  dos dados, normalmente na forma distribuída, onde as unidades de informações(dados, metadados  etc)  são espalhadas por centenas e até milhares de “nós” processadores ligados em rede, com topologias diferentes(master-slave, ou peer-to-peer). Podem ter a conformação de Gerenciadores de bancos de dados distribuídos (SGBDD) ou  de    gerenciadores de  arquivos distribuídos(DFS). A diferença está no conjunto de funcionalidades embutidas, com os SGBD distribuídos, que  normalmente oferecem aspectos de schemas, DDL, conceitos de ACID, acrônimo para Atomicidade, Consistência, Isolamento e Durabilidade. Nessa categoria, os produtos ditos NOSQL DB podem oferece características diferentes dos “ tradicionais” SGBDD, não se utilizando de linguagem SQL e modificando os aspectos de normalização(por exemplo, abdicando da 1ª forma normal),  e assim, se afastando do modelo relacional, tradicional nos produtos SGBD a partir da década de 80. Nessa categoria aparecem o BigTable, da Google, o Dynamo da Amazon, o Cassandra do Facebook, por exemplo. São produtos de BD que priorizaram a disponibilidade dos dados à sua consistência., em função do volume  e do estilo de aplicação a que foram direcionados inicialmente. Por outro lado, no domínio dos DFS(sistemas de arquivos distribuídos), aparecem nomes como Hadoop, framework inspirado no GFS(Google File System), inspirado inicialmente nos laboratórios de Mountain View. Acoplados às camadas de distribuição e armazenamento de dados, aparecem  frameworks capazes de comandar o tratamento das pesquisas , agora resolvidas em milhares de “nós”, com dados replicados para garantir alta tolerância e retornar os dados selecionados, filtrados e consolidados. Nesse universo apareceu o padrão MapReduce. Essa dupla, Haddop-MapReduce é hoje, um par de conceitos dentre os mais discutidos na computação de nuvem e serviram para a produção de várias tecnologias derivadas.
Hadoop-MapReduce
Oriundos do fenômeno Google que ensinou ao mundo como processar e pesquisar montanhas gigantescas de dados, essa nova tendência aparece com muita força nas soluções emergentes do mercado de altíssimo volume de dados. Em 2003, quando o Google se defrontou com o desafio de indexar a internet toda, colocando todas as páginas passíveis de serem acessadas pelas suas máquinas de buscas, apareceram as primeiras ideias. Para resolver esse enigma, um conjunto de engenheiros da Google definiu o conceito de  MapReduce, conjugado com o complexo sistema de gerência de dados (FMS) desenvolvido pela própria Google, que seria a origem do Hadoop.
A ideia por trás do MapReduce é um framework de programação que foca fortemente o processamento e o armazenamento distribuído de dados, além de estruturações de dados que em nada lembram as tradicionais tabelas e relações que conhecemos. Com o melhor da filosofia  “dividir para conquistar”, a proposta visa a quebrar um enorme conjunto de dados em “tascos” menores  que serão espalhados por milhares de nós processadores. Um nó controlador, tipo master, quebra as perguntas em pequenas consultas que são enviadas aos nós processadores subordinados e depois retornam, quando são agregadas numa resposta coesa. O Google reescreveu todo o seu sistema de indexação para se utilizar das vantagens da proposta de MapReduce. Além de trabalhar com essa esquadrilha de nós processadores, o framework ainda possibilita a estratégia de fault-tolerance, que garante que, mesmo que haja queda em alguns dos muitos nós, os remanescentes se incumbirão de realizar as tarefas que não puderam ser terminadas. Os dados são replicados em vários nós, garantindo que no caso de falhas de uma cópia, outras estarão disponíveis.  A proposta foi revolucionária na medida em que permitiu que, em vez de um ou alguns supercomputadores, todo o processamento possa ser executado por inúmeras máquinas menores, mais baratas e com menor investimento. Um conjunto de processadores comprados como “commodities”, alocados em vários racks, acabaram formando um instrumento poderoso para processar altos volumes de dados. No conceito de cluster Haddop, cada um dos servidores da rede pode ter 2,4 ou 8 processadores e você poderá ter centenas de servidores, cada qual tomando conta de um pedaço do grande volume de dados, traduzido em fragmentos distribuídos.  O resultado oriundo desses milhares de processadores, originados de uma consulta, retornam para uma camada redutora que transforma os milhares de resultados parciais em um conjunto final a ser entregue a quem fez a solicitação.  A tecnologia permitiu que a Google tornasse o seu sistema muito mais inteligente trocando a complexidade anteriormente existente pelas análises de comportamentos dos usuários Google, com oferecimento de novos produtos e desenvolvimento de melhorias que alcançaram também os produtos Google Maps e Google Earth. Os detalhes mais secretos da tecnologia MapReduce e de seu Google FMS permaneceram proprietários, porém a empresa permitiu a publicação aberta de alguns conceitos subjacentes. Essas publicações permitiram o desenvolvimento de alternativas no mercado. Quando o site Yahoo percebeu a força da proposta do concorrente, juntou esforços para desenvolver algo semelhante, criando o Hadoop, batizado em função do nome de um brinquedo (baby elephant). O Hadoop não é considerado propriamente um SGBD (Sistema Gerenciador de Bancos de Dados), ficando mais centrado na categoria de um gerenciador distribuído de arquivos - DFMS (Distributed File Management System). É caracterizado pela ausência de uma linguagem específica como o SQL e por uma  forma estrutural menos rigorosa, como a definida pelo modelo relacional, que é moldado por normalizações e regras de dependências funcionais. O Hadoop, ao contrário, permite uma forma flexível de definições estruturais e não oferece uma linguagem DML (Data Manipulation Language) padrão, podendo ser trabalhado por qualquer linguagem do mercado. O Hadoop tem grande parte de sua força na combinação com a estratégia de distribuição de dados, através de uma arquitetura MPP, em que uma esquadrilha de servidores oferece “escalabilidade” linear. O Hadoop aplica o modelo de programação do MapReduce, possibilitando a criação de aplicativos em qualquer linguagem e que roda em paralelo, dentro da arquitetura distribuída estabelecida. O Hadoop não trabalha na forma transacional, sendo vocacionado para processamentos batchs que executam os programas desenvolvidos. Nesse estágio não há consultas interativas. Não comporta acessos randômicos aos dados, trabalhando de forma sequencial, o que pode trazer certas restrições em tipos de processamentos com workload misto (atualização e consulta) que exigem acessos aleatórios. Hoje o Hadoop se destaca como um ambiente de processamento com “escalabilidade” infinita, tratando altíssimos volumes de dados que seriam inviáveis de ser tratados (armazenados e processados) num RDBMS tradicional. Como um DFMS, o Hadoop permite o tratamento de dados estruturados, semiestruturados e não estruturados, potencializando o seu uso na web. Hoje o Hadoop permite a análise do que cerca de 300 milhões de pessoas veem no site do Yahoo, minerando o seu comportamento e alternando dinamicamente home páginas por onde eles se deslocam. O Yahoo estima um investimento de dezenas de milhões de dólares no seu desenvolvimento, mas a sua essência é mantida como open-source. Até a Microsoft, normalmente refratária aos aspectos de open-source, também adotou o Hadoop quando incorporou a empresa Powerset a fim de melhorar a sua máquina de busca. No Facebook, o Hadoop é usado para gerenciar 40 bilhões de fotos armazenadas na maior das redes sociais. A empresa Eyealike, por sua vez, aplica o Hadoop para o reconhecimento facial em fotos.  O Hadoop agora é um framework  de código aberto da Apache e está sendo usado por algumas empresas como Comscore (especializada em aplicações de inteligência no mercado digital) e  CBS Interactive (com foco em marketing digital) para tratar gigantescos volumes de dados e prepará-los para estruturas de BI/analytics.
O produto pode ser obtido na Apache Foundation, em módulos independentes, mas pode ser comprado de terceiros como Cloudera e IBM, em pacotes. O pacote é uma unidade com vários componentes testados para garantir compatibilidade e estabilidade entre as partes, além de vir com suporte e serviços na base de assinatura. A Cloudera também está  desenvolvendo aplicativos focados em segmentos verticais, como financeiro, biotecnologia, energia, varejo e seguros baseados nos conceitos do MapReduce e em um FMS (File Management System) similar (com busca paralelizada em sistemas MPP e fault tolerance). Em algumas soluções, como a da Aster, são desenvolvidas funções de tratamento de pesquisa, otimização, particionamento de dados, classificação, etc., por vezes embutidas numa sintaxe SQL-like e que são executadas nos “nós” em que partições de dados são previamente armazenadas. Isso tudo dentro do estilo de arquitetura que envolve dezenas de centenas de nós, alguns com objetivos específicos, como armazenamento de metadados, analisador, otimizador e distribuidor de consultas . Com o objetivo de otimizar os acessos, o Hadoop adota blocos físicos de tamanho grande (64MB). A solução também foca o processamento in-memory e máquinas MPP (Massive Parallel Processing). Essa arquitetura é voltada para o tratamento de grandes arquivos, como click-stream data base, que registram os passos de um internauta pelo site através dos cliques de uma sessão, ou para o processamento de dados da Catalina, por exemplo, em que pesquisam dados de milhões de clientes que usam cupom, para montar modelos de comportamento.  A parte cuidadosa na adoção de umas solução dessas é  exatamente a sua  imaturidade, comparada com o SQL quarentão, além de conceitos novos, incomuns e não tão fáceis como os tradicionais relacionais. A Google e a IBM têm programas para o ensino do Hadoop nas universidades, visando à sua maior adoção. Outros produtos dessa linhagem são GreenPlum, adquirido pela gigante do mundo de armazenamento EMC e DataMeer.

Pontos fortes da estratégia Hadoop:
Sempre que as novidades aparecem é importante analisá-las sob certos aspectos, conforme a seguir:
Custo: o software é livre e, quando comparado com o custo de uma estrutura de SGBD relacional necessário para tratar dados no volume da era dos zettabytes, torna-se mais atraente ainda;
Dados: por possuir uma abordagem sem esquema formal  de dados o Hadoop e o MapReduce trabalham bem com qualquer tipo de dados. O MapReduce interpreta os dados em tempo de execução, baseado em estruturas simplificadas do tipo “chave=valor”  definidos em um programa de MapReduce. Dessa forma, o programa pode trabalhar com facilidade no tratamento de dados estruturados, semiestruturados e não-estruturados, como imagens, textos, etc;
Escalabilidade: o produto é um DFMS que trabalha em arquitetura MPP que roda em um conjunto de servidores, oferecendo “escalabilidade” linear. Possui overhead pequeno se comparado com os gerenciadores relacionais;
Modelos de dados: o Hadoop é um DFMS que não necessita de um esquema ou conceitos de normalização para tratar os dados, nem uma linguagem especial para acessá-los. O produto oferece alta performance e facilidade, via aplicações como Flume, para receber, tratar e transferir altos volumes de dados;
Administração do ambiente: o produto automaticamente gerencia as falhas nos diversos nós da arquitetura, além de oferecer facilidades para manipulação grandes clusters de máquinas, rodando programas que executam em arquitetura paralela.
A figura abaixo ilustra o conceito de Hadoop-MapReduce























Grande volume de dados
(Tera-Peta-Exa) dividido em
milhares de pequenos arquivos
Milhares de nós processadores, com dados e funções de Map e Reduce

       Dados e funções
  replicadas,
       Armazenamento  key-value, alta
taxa de compressão
       MPP
       Fault Tolerant







Consulta: é mapeada (dividida) em diversas subconsultas
Enviada a diversos nós processadores, controlado pelo nó master
Retornam ao Master que os consolida (Reduce) na resposta
Nó master


Resultado
Map
Reduce
Outros “nós”
























Grande volume de dados
(Tera-Peta-Exa) dividido em
milhares de pequenos arquivos
Milhares de nós processadores, com dados e funções de Map e Reduce

       Dados e funções
  replicadas,
       Armazenamento  key-value, alta
taxa de compressão
       MPP
       Fault Tolerant







Consulta: é mapeada (dividida) em diversas subconsultas
Enviada a diversos nós processadores, controlado pelo nó master
Retornam ao Master que os consolida (Reduce) na resposta
Nó master


Resultado
Map
Reduce
Outros “nós”




















Grande volume de dados
(Tera-Peta-Exa) dividido em
milhares de pequenos arquivos
Milhares de nós processadores, com dados e funções de Map e Reduce

       Dados e funções
  replicadas,
       Armazenamento  key-value, alta
taxa de compressão
       MPP
       Fault Tolerant







Consulta: é mapeada (dividida) em diversas subconsultas
Enviada a diversos nós processadores, controlado pelo nó master
Retornam ao Master que os consolida (Reduce) na resposta
Nó master


Resultado
Map
Reduce
Outros “nós”