Atualmente quando o assunto é Big Data, um tema que é tratado praticamente como sinônimo é o Hadoop, mas que fique claro que podemos ter Big Data sem Hadoop, assim como, Hadoop sem Big Data.

Hadoop

Hadoop é um framework para processamento distribuído e particionamento de grande volume de dados.

Foi criado pelo Yahoo e depois entregue à Apache.

O Hadoop é composto de dois componentes principais:

HDFS (Hadoop Distributed File System)

Componente de storage do Hadoop, otimizado para alto throughtput e que funciona melhor na leitura e escrita de grande arquivos (Gigabytes para cima). Os dados no HDFS podem estar ou não estruturados.

Dentre as características do HDFS estão a escalabilidade e disponibilidade graças a replicação de dados e tolerância a falhas. O HDFS replica os arquivos um número configurado de vezes e é tolerante a falhas tanto em hardware quanto em software.

O HDFS segue a arquitetura master-slave. Seus dois componentes principais são:

- Namenode: Responsável por armazenar os metadados (informações sobre quais datanodes são responsáveis por quais blocos de dados de cada arquivo);

- Datanode: Componentes nos quais são armazenados os dados.

Map Reduce

O Map Reduce é um framework computacional para processamento paralelo criado pelo Google. Ele abstrai as dificuldade do trabalho com dados distribuídos, trazendo referências da arquitetura shared-nothing na qual cada nó é independente e auto-suficiente, eliminando quaisquer problemas que o compartilhamento de informações pode trazer.

Consiste das seguintes funções:

- Map: Responsável por receber os dados na forma de chave/valor representando de forma lógica cada registro dos dados de entrada, podendo ser, por exemlo, uma linha em um arquivo de log ou de uma tabela. A função map retorna uma lista com zero ou mais dados chave/valor e deve ser codificada pelo desenvolvedor, através de outras ferramentas ou da API Java;

- Shuffle: A etapa de shuffle é responsável por organizar o retorno da função Map, atribuindo para a entrada de cada Reduce todos os valores associados a uma mesma chave. Este etapa é realizada pela biblioteca do MapReduce;

- Reduce: Por fim, ao receber os dados de entrada a função Reduce retorna uma lista de chave/valor contendo zero ou mais registros, semelhante ao Map, deve ser codificada pelo desenvolvedor.

A arquitetura do MapReduce é semelhante ao do HDFS, master-slave. No MapReduce os componentes são:

- JobTracker: Ele recebe o job MapReduce e programa as tarefas map e reduce para execução, coordenando as atividades nos TaskTrackers;
- TaskTracker: Componente responsável por executar as tarefas de map e reduce e informar o progresso das atividades.
Ecossitema Hadoop

Existem muitos projetos que tem por objetivo endereçar algumas necessidades específicas de um sistema que utilize o Hadoop. Segue abaixo a descrição de alguns deles:

>> Ambari: Tem o objetivo de simplificar a monitoração e gerenciamento dos Hadoop Clusters;
>> Avro: Sistema de serialização de dados;
>> Flume: Serviço para coleta, agregação e transporte de grandes quantidades de dados de log para o HDFS;
>> HBase: Banco de dados orientado a coluna, roda em cima do HDFS, pode ser utilizado como fonte ou destino do para as funções de MapReduce;
>> Hive: Sistema de Data Warehouse para o Hadoop que facilita sumarização de dados e queries ad-hoc. Linguagem similar ao SQL;
>> Mahout: Biblioteca escalável de machine learning e mineração de dados;
>> Pig: Provê uma linguagem de mais alto nível para a criação de jobs MapReduce;
>> Sqoop: Ferramenta para importar dados de banco de dados relacionais para o Hadoop e vice-versa;
>> Zookeeper: Serviço de coordenação de alto desempenho para sistemas distribuídos.

Quem usa hadoop?

Nos dias de hoje, muitas empresas já utilizam o Hadoop para diversos fins, segue algumas delas:

Facebook: Armazenamento de logs internos e dados para fonte de informação, análise e machine learning;
Linkedin: Utilizado para diversas atividades como descoberta de “People you may know”, sugestão de pessoas que o perfil deva conhecer;
Twitter: Armazenamento e processamento, principalmente, de tweets e arquivos de log.
Outros clientes e suas utilizações em: http://wiki.apache.org/hadoop/PoweredBy.

Bom pessoal, por hoje é só, o objetivo era ser o mais breve possível nesta introdução ao Hadoop, passando pelos seus principais componentes.

Espero que tenham gostado.

Um abraço e até a próxima.

Fillipe Massuda

Post publicado em Aquele Blog de SOA

Antes uma pequena introduçao sobre Big Data.

Segundo Edd Dumbill, em Planning for Big Data:

Big Data são dados que extrapolam a capacidade de processamento de sistemas banco de dados convencionais.

Esses dados devem se enquadrar no chamado 3V’s:

>> Velocidade: Os dados são gerados em velocidade nas quais não é possível processá-los em tempo real, ou ainda é necessário que esses dados sejam processados mais rapidamente que um processo batch para que uma resposta seja retornada o quanto antes;

>> Volume: Caracteriza o processamento de uma grande quantidade de dados, que provavelmente não deve se limitar a uma base de dados ou data warehouse. Muitas empresas já devem ter essa grande quantidade de dados, mas o desafio é a capacidade de processar esses dados que geralmente estão distribuídos;

>> Variedade: Variedade está muito ligado ao volume, os dados também podem ser gerados de diversas fontes, não necessariamente de uma única organização, com modelo de dados distintos e tipos de dados distintos.

Mas então, qual é o relacionamento entre Big Data e APIs?

Hoje as APIs são alavancadores da geração e consumo de informações que estão dispersas na nuvem, em redes sociais e principalmente nas aplicações móveis. O boom do volume de dados estruturados e não-estruturados está sendo possível por diversos motivos, principalmente pela conectividade que as APIs propiciam. Big Data é o desafio que as empresas terão para conseguir extrair o melhor proveito desse volume de dados que são gerados voluntariamente e involuntariamente por máquinas e usuários, mas invariavelmente, na maior parte dos casos, trafegados através de uma API.

Com essa avalanche de dados, temos que buscar oportunidades nas informações geradas pelas nossas empresas. Não há pra onde correr, a quantidade de dados gerados nos últimos anos vem crescendo exponencialmente.

Em um estudo feito pela empresa DOMO em parceria com a Column Five Media, dentre outros dados foi demonstrado que a cada minuto são gerados 100.000 tweets. Hoje em dia, muitas empresas já são obrigadas a analisar tweets para receber um feedback sobre seus serviços ou produtos.

Espero que tenham gostado.

Um abraço e até a próxima.

Fillipe Massuda

developer.[you].com

developer.[you].com

Abraço,
Daniel Varanda

Entenda porque empresas como Netflix, Extra, Twitter, Trip Advisor e Mercado Livre estão ampliando o alcance dos seus negócios através de APIs.

Algumas histórias que você precisa conhecer:
• Como acelerar sua integração com a rede de parceiros
• Velocidade, segurança e controle em estratégias Mobile
• A valorização da marca e a criação de um ecossistema
• A transformação do negócio através da inovação aberta

Data:
Quarta-feira, 24 de Abril de 2013, 10:00 – 11:00

Inscrições gratuitas no site:
https://www3.gotomeeting.com/register/920021910

Aproveitem!

O modelo canônico é mantido de forma flexível e geral, dado que ele potencialmente absorve uma variedade de definições de entidades, ou seja, não há restrições nos elementos do modelo canônico (ex: elementos obrigatórios, valor máximo e mínimo, quantidade máxima de caracteres permitido, etc…). Desta forma, a utilização do modelo canônico nas operações dos serviços podem tornar o contrato do serviço não tão bem definido. Por isso, a utilização do modelo canônico nos parâmetros de entrada e saída (request e response) das operações dos serviços deve ser feita de forma cautelosa, pois os consumidores do serviço poderão não saber quais elementos devem ou não serem preenchidos e quais são os limites de valores de cada elemento.

Caso o contrato do serviço necessite especificar claramente essas definições para que os consumidores possam utilizá-lo, os elementos das operações do serviço podem ser definidos no “Service Schema Model” sem a utilização do modelo canônico, mas baseando-se nele, de forma que apenas os elementos necessários para o serviço sejam utilizados, assim, no “Service Schema Model” podemos adicionar as restrições necessárias aos elementos.

Vale ressaltar que essa abordagem não desqualifica o valor do modelo canônico, já que ele continua sendo utilizado de forma conceitual, representando as entidades corporativas, facilitando o entendimento do negócio.

Abraço,
Daniel Varanda

Bacili tem notado uma procura cada vez maior por parte dos setores varejista e de finanças por APIs. MercadoLivre é um bom exemplo nacional. E há casos surpreendentes, como o API da Ford para a criação de apps para seus carros conectados. A Sensedia trabalha no momento com dois projetos no Brasil. Um deles é para o grupo Pão de Açúcar, que vai abrir uma API para que terceiros vendam seus produtos através do marketplace online de sites do Ponto Frio e do Extra.

O CEO da Sensedia explica que as APIs podem ser divididas em três tipos, de acordo com o público alvo: a privada (voltada para uso interno da empresa); a aberta somente a parceiros pré-definidos; e a pública, acessível a qualquer desenvolvedor. Esta última é a que mais cresce, especialmente por conta do interesse em apps móveis. O executivo ressalta, contudo, que são necessários alguns cuidados para que a API seja atraente ao desenvolvimento móvel. “Os protocolos precisam ser mais simples, especialmente no Brasil, onde a rede 3G implica em uma limitação de banda. Além disso, é preciso um cuidado com o tamanho da tela”, aconselha.

As APIs também podem ser classificadas de acordo com o seu modelo de negócios. Algumas são totalmente gratuitas, como aquela de autenticação do Facebook, cada vez mais usada por apps móveis e aplicações na web. Outras adotam o modelo “freemium”, como a do Google Maps: o uso até determinada quantidade de vezes é gratuito, mas depois cobra-se do desenvolvedor. E há APIs que remuneram os desenvolvedores, como a recém-lançada API do serviço de streaming de música Deezer, em que o desenvolvedor recebe por cada assinante que conquistar.

A construção de uma API pública pode levar poucas semanas, se o cliente já tiver muita coisa pronta, às vezes em razão de desenvolvimentos internos. “Mas se o sistema tiver sido construído de forma monolítica, no mainframe, aí leva mais tempo”, comenta Bacili.

Bacili tem notado uma procura cada vez maior por parte dos setores varejista e de finanças por APIs. MercadoLivre é um bom exemplo nacional. E há casos surpreendentes, como o API da Ford para a criação de apps para seus carros conectados. A Sensedia trabalha no momento com dois projetos no Brasil. Um deles é para o grupo Pão de Açúcar, que vai abrir uma API para que terceiros vendam seus produtos através do marketplace online de sites do Ponto Frio e do Extra.

O CEO da Sensedia explica que as APIs podem ser divididas em três tipos, de acordo com o público alvo: a privada (voltada para uso interno da empresa); a aberta somente a parceiros pré-definidos; e a pública, acessível a qualquer desenvolvedor. Esta última é a que mais cresce, especialmente por conta do interesse em apps móveis. O executivo ressalta, contudo, que são necessários alguns cuidados para que a API seja atraente ao desenvolvimento móvel. “Os protocolos precisam ser mais simples, especialmente no Brasil, onde a rede 3G implica em uma limitação de banda. Além disso, é preciso um cuidado com o tamanho da tela”, aconselha.

As APIs também podem ser classificadas de acordo com o seu modelo de negócios. Algumas são totalmente gratuitas, como aquela de autenticação do Facebook, cada vez mais usada por apps móveis e aplicações na web. Outras adotam o modelo “freemium”, como a do Google Maps: o uso até determinada quantidade de vezes é gratuito, mas depois cobra-se do desenvolvedor. E há APIs que remuneram os desenvolvedores, como a recém-lançada API do serviço de streaming de música Deezer, em que o desenvolvedor recebe por cada assinante que conquistar.

A construção de uma API pública pode levar poucas semanas, se o cliente já tiver muita coisa pronta, às vezes em razão de desenvolvimentos internos. “Mas se o sistema tiver sido construído de forma monolítica, no mainframe, aí leva mais tempo”, comenta Bacili.