Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
código fonteBig Data na plataforma Java - Revista Java Magazine 103
Neste artigo apresentaremos uma visão conceitual sobre o que é big data, onde se originou, seus motivadores e principais usuários. Demonstraremos também modelos de programação como o MapReduce, assim como ferramentas Java para lidar com big data
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
Com o constante crescimento e facilidade de acesso à tecnologia, cada vez mais e mais volumes de dados são produzidos. Diariamente, são gerados petabytes de informações envolvendo operações comerciais e financeiras, e mesmo no ambiente doméstico é comum encontrar usuários que possuem discos de backup com capacidade de 1 terabyte ou mais.
E com este crescente acesso à tecnologia, empresas como Facebook, Yahoo! e Google culminaram coletando dados em uma escala sem precedentes, números além do comum. Eles foram os primeiros a coletar toneladas de dados oriundos de milhões de usuários.
Arduamente, perceberam que os sistemas convencionais de armazenamento e processamento de dados não atenderiam a suas demandas. Deste modo, nos anos 2000, colocando seus melhores pensadores para criar, foram capazes de desenvolver novas técnicas como MapReduce, BigTable e o Google File System, para lidar com tais volumes e processamento. Assim, após um período utilizando estas tecnologias de forma privada, por volta do ano 2005, Facebook, Yahoo! e Google tomaram a iniciativa de compartilhá-las através da publicação de “white papers”, descrevendo suas tecnologias para soluções que requerem o manuseio de big data.
O termo big data é utilizado para referenciar conjuntos de dados de grande volume, o qual é praticamente inviável o manuseio com ferramentas e técnicas convencionais. Lidar com um grande volume de dados acarreta dificuldades no processamento, tais como: indexação, análise de padrões e até mesmo consultas.
Estes desafios de operações com big data estão presentes em grandes sites como a Amazon, que gera um enorme volume de dados. A rede social Facebook lida com cerca de 40 bilhões de fotos geradas por seus usuários. Atualmente, mais de 350 milhões de usuários ativos acessam a rede social via dispositivos móveis, e são realizados em média 250 milhões de uploads de fotos por dia. Em março de 2008, a rede social Facebook coletava diariamente 200 GB de dados; atualmente, coleta 15 terabytes. Imagine apenas o simples fato de gerar um registro de log para cada uma destas operações, qual seria a quantidade de registros que atingiríamos no período de 365 dias? O projeto Grande Colisor de Hádrons (LHC – Large Hadron Collider), o maior acelerador de partículas do mundo, mantido pela CERN, por exemplo, irá produzir 15 petabytes de dados anualmente.
Outro exemplo de desafio com dados: o recurso de pesquisas Search Assist da Yahoo!, fornece sugestões em tempo real conforme o usuário digita o que deseja pesquisar. Estas sugestões são criadas analisando anos de registros de dados das pesquisas e termos utilizados. Para uma empresa do porte da Yahoo!, este registro de dados resulta em terabytes de arquivos de log em apenas um dia, e centenas de terabytes dentro do período de um ano. Para a Yahoo!, antes de o Hadoop ser utilizado, criar a base de dados para o Search Assist levava 26 dias. Agora, com o Hadoop, leva 20 minutos.
É para lidar com essa constante e crescente necessidade de trabalhar com volumes intensivos de dados que surgiu a definição de big data.
Companhias das mais variadas indústrias, por consequência da crescente capacidade de coletar e processar mais e mais informações, se encontram com problemas para lidar com big data, e anseiam por soluções.
Na busca de oportunidades para prover soluções para este mercado, o big data gera um impacto que faz com que grandes players da indústria, tais como Oracle, IBM, Microsoft e SAP, invistam cada vez mais, na ordem de bilhões de dólares, para se especializarem no gerenciamento e análise de dados nestas proporções.
Esta tendência traz benefícios para vários campos e atividades que necessitam analisar informações de grandes volumes de dados, como: astronomia, biologia, pesquisas científicas, pesquisas militares, meteorologia, imagens de satélite, redes sociais, pesquisa em internet, logs web, transações bancárias, mercado financeiro, e-commerce, etc. Estar apto a processar analiticamente esse enorme conjunto de dados produzido pode gerar benefícios valiosos para instituições financeiras e não-financeiras.
Junto com este termo de categorização (big data), vêm surgindo técnicas e ferramentas poderosas que se tornaram alternativas úteis para tratar esses volumes de dados. O que possibilita prover informações que antes não eram aproveitadas em visões analíticas, por serem tão complicadas e custosas de serem obtidas. Visões que podem apresentar informações estratégicas, que são parte importante nas tomadas de decisões. Dentro destes grandes volumes de dados podem estar escondidos padrões de informações valiosos, antes inacessíveis devido ao grande esforço para extraí-los.
Hoje, com o custo mais baixo do hardware e processamento em arquitetura cloud disponível no mercado, a opção de análise de big data é acessível também para as médias e pequenas corporações. Para estabelecer um data warehouse, é necessário adquirir ferramentas com o preço de alguns milhares de dólares, adquirir o serviço para construção da solução por mais alguns milhares de dólares, depois aguardar algumas dezenas de meses. E durante esses meses, esperar que o investimento (tempo e dinheiro) gasto se justifique, que promova visões que atenderão suas necessidades e lhe fornecerão vantagens sobre os competidores. Por isso, empresas que precisavam processar grandes volumes de dados puderam assim realizar, com o advento de ecossistemas como Hadoop e HBase, soluções para garimpar bilhões de dados de forma mais ágil, e ainda com custo mais acessível. Obviamente, as soluções corporativas de alto-custo de data warehouse não irão desaparecer, o que está acontecendo é que, agora, um data warehouse pode não ser mais a única opção.
"
Este é um post disponível para assinantes MVP
E com este crescente acesso à tecnologia, empresas como Facebook, Yahoo! e Google culminaram coletando dados em uma escala sem precedentes, números além do comum. Eles foram os primeiros a coletar toneladas de dados oriundos de milhões de usuários.
Arduamente, perceberam que os sistemas convencionais de armazenamento e processamento de dados não atenderiam a suas demandas. Deste modo, nos anos 2000, colocando seus melhores pensadores para criar, foram capazes de desenvolver novas técnicas como MapReduce, BigTable e o Google File System, para lidar com tais volumes e processamento. Assim, após um período utilizando estas tecnologias de forma privada, por volta do ano 2005, Facebook, Yahoo! e Google tomaram a iniciativa de compartilhá-las através da publicação de “white papers”, descrevendo suas tecnologias para soluções que requerem o manuseio de big data.
O termo big data é utilizado para referenciar conjuntos de dados de grande volume, o qual é praticamente inviável o manuseio com ferramentas e técnicas convencionais. Lidar com um grande volume de dados acarreta dificuldades no processamento, tais como: indexação, análise de padrões e até mesmo consultas.
Estes desafios de operações com big data estão presentes em grandes sites como a Amazon, que gera um enorme volume de dados. A rede social Facebook lida com cerca de 40 bilhões de fotos geradas por seus usuários. Atualmente, mais de 350 milhões de usuários ativos acessam a rede social via dispositivos móveis, e são realizados em média 250 milhões de uploads de fotos por dia. Em março de 2008, a rede social Facebook coletava diariamente 200 GB de dados; atualmente, coleta 15 terabytes. Imagine apenas o simples fato de gerar um registro de log para cada uma destas operações, qual seria a quantidade de registros que atingiríamos no período de 365 dias? O projeto Grande Colisor de Hádrons (LHC – Large Hadron Collider), o maior acelerador de partículas do mundo, mantido pela CERN, por exemplo, irá produzir 15 petabytes de dados anualmente.
Outro exemplo de desafio com dados: o recurso de pesquisas Search Assist da Yahoo!, fornece sugestões em tempo real conforme o usuário digita o que deseja pesquisar. Estas sugestões são criadas analisando anos de registros de dados das pesquisas e termos utilizados. Para uma empresa do porte da Yahoo!, este registro de dados resulta em terabytes de arquivos de log em apenas um dia, e centenas de terabytes dentro do período de um ano. Para a Yahoo!, antes de o Hadoop ser utilizado, criar a base de dados para o Search Assist levava 26 dias. Agora, com o Hadoop, leva 20 minutos.
É para lidar com essa constante e crescente necessidade de trabalhar com volumes intensivos de dados que surgiu a definição de big data.
Companhias das mais variadas indústrias, por consequência da crescente capacidade de coletar e processar mais e mais informações, se encontram com problemas para lidar com big data, e anseiam por soluções.
Na busca de oportunidades para prover soluções para este mercado, o big data gera um impacto que faz com que grandes players da indústria, tais como Oracle, IBM, Microsoft e SAP, invistam cada vez mais, na ordem de bilhões de dólares, para se especializarem no gerenciamento e análise de dados nestas proporções.
Esta tendência traz benefícios para vários campos e atividades que necessitam analisar informações de grandes volumes de dados, como: astronomia, biologia, pesquisas científicas, pesquisas militares, meteorologia, imagens de satélite, redes sociais, pesquisa em internet, logs web, transações bancárias, mercado financeiro, e-commerce, etc. Estar apto a processar analiticamente esse enorme conjunto de dados produzido pode gerar benefícios valiosos para instituições financeiras e não-financeiras.
Junto com este termo de categorização (big data), vêm surgindo técnicas e ferramentas poderosas que se tornaram alternativas úteis para tratar esses volumes de dados. O que possibilita prover informações que antes não eram aproveitadas em visões analíticas, por serem tão complicadas e custosas de serem obtidas. Visões que podem apresentar informações estratégicas, que são parte importante nas tomadas de decisões. Dentro destes grandes volumes de dados podem estar escondidos padrões de informações valiosos, antes inacessíveis devido ao grande esforço para extraí-los.
Hoje, com o custo mais baixo do hardware e processamento em arquitetura cloud disponível no mercado, a opção de análise de big data é acessível também para as médias e pequenas corporações. Para estabelecer um data warehouse, é necessário adquirir ferramentas com o preço de alguns milhares de dólares, adquirir o serviço para construção da solução por mais alguns milhares de dólares, depois aguardar algumas dezenas de meses. E durante esses meses, esperar que o investimento (tempo e dinheiro) gasto se justifique, que promova visões que atenderão suas necessidades e lhe fornecerão vantagens sobre os competidores. Por isso, empresas que precisavam processar grandes volumes de dados puderam assim realizar, com o advento de ecossistemas como Hadoop e HBase, soluções para garimpar bilhões de dados de forma mais ágil, e ainda com custo mais acessível. Obviamente, as soluções corporativas de alto-custo de data warehouse não irão desaparecer, o que está acontecendo é que, agora, um data warehouse pode não ser mais a única opção.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Ualter Otoni Azambuja Junior
Atua como profissional na área de tecnologia há dezessete anos, dos quais dez dedicados a plataforma Java e soluções de Arquitetura de Aplicação/Integração. Trabalha como Arquiteto de Sistema para o Banco Itaú S/A, é pós-graduado em Tecnologia Orientada a Objetos e possui as certificações: SCJP, SCW...
O que você achou deste post?
10 COMENTÁRIOS
Marcelo Maico
Tenho uma dúvida com relação a esta matéria, hoje tenho uma base com 2 terabytes de dados e uma query que gera algumas informações, uma destas querys leva 3 dias para processar assim entendi que deveria usar o Haadop para escalar isso.
No exemplo apresentado na revista ele mostra a entrada de dados usando um arquivo de texto, no meu caso eu teria que recuperar este dado bruto do banco para então lapida-lo e assim gerar a informação.
Gostaria de saber como eu poderia fazer isso, como extraio estes dados da base visto que esta query que apresentei utiliza aproximadamente 70% das tabelas, neste caso o gargalo ficaria ao recuperar os dados então eu acabaria não tendo tanto êxito. Existe alguma maneria de eu indexar as informações do banco (como um indice do Lucene) ou eu teria mesmo que abrir um conexão com o banco e iterar linha por linha e trabalhar a informação? como faceboox, twitter faz isso?
Incrivel matéria, meus parabéns!
No exemplo apresentado na revista ele mostra a entrada de dados usando um arquivo de texto, no meu caso eu teria que recuperar este dado bruto do banco para então lapida-lo e assim gerar a informação.
Gostaria de saber como eu poderia fazer isso, como extraio estes dados da base visto que esta query que apresentei utiliza aproximadamente 70% das tabelas, neste caso o gargalo ficaria ao recuperar os dados então eu acabaria não tendo tanto êxito. Existe alguma maneria de eu indexar as informações do banco (como um indice do Lucene) ou eu teria mesmo que abrir um conexão com o banco e iterar linha por linha e trabalhar a informação? como faceboox, twitter faz isso?
Incrivel matéria, meus parabéns!
[há +1 mês] -
Responder
[autor]
Ualter Otoni Azambuja Junior
Olá Marcelo,
Pelo que entendi a demora consiste em gerar o resultado final rodando uma query em sua base de dados, assim você já possui o resultado que deseja atingir a partir da base de dados relacional executando uma query, correto ?
O processo poderia ser dividido em fases, primeiro extrair as informações do ambiente transacional, grava-las em uma ambiente de dados distribuídos (um grid de dados), que poderia ser o HDFS (do Hadoop), ou base de dados NoSQL como o HBase (que se fundamenta no modelo Big Table da Google), que é como uma base de dados para o Hadoop. E em seguida, executar os MapReduces sobre essa base de dados NoSQL provendo os resultado que você procura. O trabalho do Hadoop é também prover auxílio mantendo as informações facilitadas (indexadas, lembre-se que estamos falando de um modelo "write-once-read-many-times") assim ter um ambiente disponibilizado para "brincar" com regras MapReduce sobre um grande número de informações distribuída. No Facebook, eles carregam do MySQL para o Hadoop, processam, e depois retornam as informações para o MySQL para serem utilizadas.
(a idéia é: tentar dividir o seu problema em problemas menores e tentar resolve-los, se possível, em paralelo).
O objetivo do Hadoop é conseguir utilizar o poder do processamento paralelo massivo, sobre nós de dados (distribuídos), executando regras para atingir as informações desejadas realizas através do MapReduce.
Para poder te ajudar de maneira mais eficaz, melhor seria conhecer o formato que se apresenta a suas informações no BD Relacional e o objetivo final que precisa atingir com estes dados. Fique a vontade para entrar em contato, ok?
Abraço e obrigado,
Ualter
Pelo que entendi a demora consiste em gerar o resultado final rodando uma query em sua base de dados, assim você já possui o resultado que deseja atingir a partir da base de dados relacional executando uma query, correto ?
O processo poderia ser dividido em fases, primeiro extrair as informações do ambiente transacional, grava-las em uma ambiente de dados distribuídos (um grid de dados), que poderia ser o HDFS (do Hadoop), ou base de dados NoSQL como o HBase (que se fundamenta no modelo Big Table da Google), que é como uma base de dados para o Hadoop. E em seguida, executar os MapReduces sobre essa base de dados NoSQL provendo os resultado que você procura. O trabalho do Hadoop é também prover auxílio mantendo as informações facilitadas (indexadas, lembre-se que estamos falando de um modelo "write-once-read-many-times") assim ter um ambiente disponibilizado para "brincar" com regras MapReduce sobre um grande número de informações distribuída. No Facebook, eles carregam do MySQL para o Hadoop, processam, e depois retornam as informações para o MySQL para serem utilizadas.
(a idéia é: tentar dividir o seu problema em problemas menores e tentar resolve-los, se possível, em paralelo).
O objetivo do Hadoop é conseguir utilizar o poder do processamento paralelo massivo, sobre nós de dados (distribuídos), executando regras para atingir as informações desejadas realizas através do MapReduce.
Para poder te ajudar de maneira mais eficaz, melhor seria conhecer o formato que se apresenta a suas informações no BD Relacional e o objetivo final que precisa atingir com estes dados. Fique a vontade para entrar em contato, ok?
Abraço e obrigado,
Ualter
[há +1 mês] -
Responder
Marcelo Maico
Olá Ualter,
Era essa a dúvida que eu tinha, então executarei esses passos para implementar a solução.
Minha outra dúvida esta em como manter estes dados, visto que eu terei no banco relacional e também no Hadoop. A estratégia seria replicar a persistencia destas informações, ex: quando eu salvar um usuário em minha base relacional
eu imediatamente salvaria no Hadoop? o que geralmente se usa para manter estas informaçoes espelhadas?
Muito Obrigado!
Era essa a dúvida que eu tinha, então executarei esses passos para implementar a solução.
Minha outra dúvida esta em como manter estes dados, visto que eu terei no banco relacional e também no Hadoop. A estratégia seria replicar a persistencia destas informações, ex: quando eu salvar um usuário em minha base relacional
eu imediatamente salvaria no Hadoop? o que geralmente se usa para manter estas informaçoes espelhadas?
Muito Obrigado!
[há +1 mês] -
Responder
[autor]
Ualter Otoni Azambuja Junior
Olá Marcelo,
Tente fazer uma análise conforme a necessidade do tempo(delay) o qual a visão que você quer prover deve estar disponível: imediato, em horas, ou no dia seguinte. Com base nisso, tente planejar Jobs para executar a carga (no HBase ou HDFS) somente das informações que você necessita para rodar os seus MapReduces. Execute estes MapReduces no momento que achar oportuno (via Jobs também de preferência), e assim terá o resultado, que pode ser novamente gravado em uma base relacional (mas agora com a sua visão pronta para exibir, sem necessidade de processar grandes quantidades de dados).
Lembre-se que o Hadoop não é uma solução "pensada" para ser usada em modo real-time/on-line, processando informações transacionais enquanto o seu cliente acessa um site. Ele foi "pensando" para trabalhar com grandes volumes de dados utilizando o modo Batch. O Banco Relacional faz um bom trabalho quando tratamos operações transacionais, porém quando mudamos para o plano analítico,"mining" de informações em grandes massas de dados, por não serem escaláveis não fazem um bom trabalho, por isso neste campo, entra o Hadoop com HDFS ou HBase como repositório de dados distribuído.
Porém, você pode gravar os dados no Hadoop (HDFS ou Base) em real time, no momento em que um evento ocorre (transação), não é incorreto realizar este procedimento. Desde que, não cause impacto na sua operação e você ainda consiga o objetivo desejado para a extração da visão analítica. Espero ter ajudado em algo, qualquer coisa, por favor, entre em contato.
Abraço,
Ualter
Tente fazer uma análise conforme a necessidade do tempo(delay) o qual a visão que você quer prover deve estar disponível: imediato, em horas, ou no dia seguinte. Com base nisso, tente planejar Jobs para executar a carga (no HBase ou HDFS) somente das informações que você necessita para rodar os seus MapReduces. Execute estes MapReduces no momento que achar oportuno (via Jobs também de preferência), e assim terá o resultado, que pode ser novamente gravado em uma base relacional (mas agora com a sua visão pronta para exibir, sem necessidade de processar grandes quantidades de dados).
Lembre-se que o Hadoop não é uma solução "pensada" para ser usada em modo real-time/on-line, processando informações transacionais enquanto o seu cliente acessa um site. Ele foi "pensando" para trabalhar com grandes volumes de dados utilizando o modo Batch. O Banco Relacional faz um bom trabalho quando tratamos operações transacionais, porém quando mudamos para o plano analítico,"mining" de informações em grandes massas de dados, por não serem escaláveis não fazem um bom trabalho, por isso neste campo, entra o Hadoop com HDFS ou HBase como repositório de dados distribuído.
Porém, você pode gravar os dados no Hadoop (HDFS ou Base) em real time, no momento em que um evento ocorre (transação), não é incorreto realizar este procedimento. Desde que, não cause impacto na sua operação e você ainda consiga o objetivo desejado para a extração da visão analítica. Espero ter ajudado em algo, qualquer coisa, por favor, entre em contato.
Abraço,
Ualter
[há +1 mês] -
Responder
Marcelo Maico
Ualter, isso esclareceu muitaaa coisa e agora já tenho um plano em mente, seguirei suas sugestões e irei colocar isso para funcionar um quanto antes.
Mais uma vez agradeço!!! :)
Mais uma vez agradeço!!! :)
[há +1 mês] -
Responder
Leonardo Bruno Pereira De Araujo
Olá Ualter. Excelente Post, eu tenho uma dúvida. O que o HDFS faz quando o arquivo a ser processado é maior que a capacidade do cluster? Por exemplo: O cluster tem capacidade para processar 50 terabytes e o arquivo a ser processado tem 100 terabytes, nesse caso, dividiria o arquivo em 2 e processaria cada um, em 2 momentos?
[há +1 mês] -
Responder
Wesley Yamazack
Olá Leonardo, entramos em contato com o autor para que ele possa te auxiliar, tudo bem ? Peço que aguarde um pouco até que o mesmo possa retornar o contato.
Um abraço.
Um abraço.
[há +1 mês] -
Responder
[autor]
Ualter Otoni Azambuja Junior
Olá Leonardo, obrigado pela leitura e atenção. Analisando este exemplo que você passou, não vejo outra alternativa a não ser possuir um cluster que possibilite armazenar toda essa quantidade de informações, ou, dividi-lo em partes, se isso não for atrapalhar o seu processamento. Sei que há casos de problema do HDFS com arquivos de tamanhos pequenos, já que Big Data nos remete a tamanhos consideráveis, não funciona bem com Small (http://tinyurl.com/cyenyxd). Mas quanto a grandes arquivos, não conheço ainda.
Abraço,
Ualter
Abraço,
Ualter
[há +1 mês] -
Responder
Leonardo Bruno Pereira De Araujo
Ualter pelos prints de tela, notei que vc tem instalado no Macbook o hadoop, você tem algum tutorial, how to...? como fazer a instalação no Mac OS? Gostaria de instalar direto no Mac sem o uso de VirtualBox e etc... é possível ? Mais uma dúvida, sobre o input de arquivos no HDFS, muitos artigos dizem que o Hadoop é ideal para processar grandes arquivos, ordem dos terabytes, minha dúvida: como é carregado/transferido o arquivo do cliente para o NameNode, já que estamos falando de arquivos enormes. Obrigado
[há +1 mês] -
Responder
[autor]
Ualter Otoni Azambuja Junior
Olá Leonardo,
Segue o link relacionado ao ambiente no Mac OS: http://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_(Single-Node_Cluster). Quanto ao NameNode: se eu interpretei bem a sua pergunta, o Cliente acessa as informações do arquivo direto nos DataNodes, no NameNode ele apenas coleta as informações de localização dos blocos de informações que formam o arquivo, que está distribuído entre os DataNodes.
Segue o link relacionado ao ambiente no Mac OS: http://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_(Single-Node_Cluster). Quanto ao NameNode: se eu interpretei bem a sua pergunta, o Cliente acessa as informações do arquivo direto nos DataNodes, no NameNode ele apenas coleta as informações de localização dos blocos de informações que formam o arquivo, que está distribuído entre os DataNodes.
[há +1 mês] -
Responder
Cursos relacionados
Publicidade
