5) O Futuro do MainFrame

As tecnologias de informação (TI) competem por existir num mercado bravo, implacável e extremamente dinâmico. A história está repleta de casos de tecnologias que foram muito importantes em uma certa época, mas que foram perdendo força até a extinção ou próximo disso. O profissional de TI prudente deve viver especulando o ambiente futuro, cuidando sempre de sua empregabilidade, de forma a decidir da melhor forma possível a prioridade do que se vai estudar, e consequentemente o que se vai ignorar. Conheço vários casos de pessoas que tornaram-se especialistas numa tecnologia que não interessa mais, e passaram de uma situação em que eram valorizados profissionalmente e salarialmente para outra bem diferente. Essas coisas acontecem com o mesmo dinamismo do mercado de TI, ou seja, num tempo comparável ao que a CPU do seu computador leva para somar números em ponto flutuante.

Um assunto de interesse especial é especular sobre o futuro do Mainframe (também chamado de computador de grande porte). Num resumo brevíssimo da história de TI, pode-se dizer que a humanidade não tinha computadores minimamente decentes até meados da segunda guerra mundial. Com o fim dessa e o início do período de guerra fria, houve vários avanços na computação digital. As primeiras gerações de computação usavam linguagem de máquina e assembler, o que é extremamente complexo. A primeira linguagem de programação de terceira geração foi FORTRAN, em 1957, com ênfase em computação científica, e usada até hoje. A segunda linguagem de computação inventada foi o COBOL, em 1959, com ênfase em computação comercial, e também usada até hoje.

Um nicho em que se encontra facilmente hoje em dia o uso de COBOL e Mainframe é no setor bancário. Claro que todas as tecnologias evoluíram desde sua criação. A versão atual dos Mainframes e do COBOL é baseada na sua própria história, mas adaptou-se para servir a quem lhe contrata. Uma qualidade que o Mainframe provê para seus clientes é uma excelente robustez (“robustez 5 noves”, isso é, 99,999% de tempo no ar, o que permite a no máximo 5 minutos fora do ar por ano). Outra qualidade do Mainframe é sua excelente capacidade de processamento, que permite dar conta de um número gigantesco de transações por segundo. Mas essas qualidades são entregues com alguns problemas. Um deles é o preço, que é bem expressivo, e transforma-se num custo operacional para o cliente, que compreensivelmente está sempre pensando em formas de reduzi-los. Outro problema mais sutil é a confiança que um cliente de Mainframe tem de que permanecerá conseguindo contratar profissionais para manter seu processamento funcionando. Esse segundo problema decorre do fato de que com o surgimento da microinformática no final da década de 1970, e o crescimento explosivo de sua utilização, a nova geração quase sempre confunde computação com microinformática e ignora o Mainframe. O uso generalizado de cloud computing, que é em geral feito com servidores Linux instanciados na quantidade que se deseja para atender necessidade de processamento que se tem, fez mais uma vez a nova geração distanciar-se do Mainframe, pois a resolução de grandes problemas de TI é feita com uso massivo de microinformática.

Fazem alguns anos, eu fui chamado para conversar com o setor de RH da Stefanini (uma grande empresa de serviço de software, com atuação no Rio de Janeiro e clientes em vários países). A chefe do RH reconhecia que nós da UFRJ formávamos bons profissionais, e nos chamou para ajudar a resolver um problema específico: eles precisavam urgentemente de gente com conhecimento de COBOL e Mainframe. Queriam que montássemos um curso extra desse assunto. Eu retruquei que reconhecia o problema deles, mas que não é muito simples convencer a nova geração a estudar isso (e nem a nós professores a montar cursos desse assunto). Argumentei que a verdadeira necessidade da Stefanini é o que o mercado inteiro precisa: uma solução para o grave problema de o que fazer com os Mainframes. Esse problema é muito sério, pois não se consegue mudar a cultura rapidamente. Mas o tempo segue indo para frente, com os profissionais de COBOL aumentando de idade e sem haver quase ninguém da nova geração para repô-los. Eu propus trabalhar junto com a Stefanini num projeto que ajudasse a se produzir uma solução geral e decente para a substituição dos Mainframes por outra coisa. Mas como eles apenas queriam um curso de COBOL, nossa conversa acabou sem nenhuma consequência. E o problema de o que fazer com os Mainframes segue aumentando sua agudez e gritando por uma solução.

Com o surgimento da tecnologia de Big Data, facilitou-se ainda mais a transformação de um conjunto de computadores (em geral Linux) em um cluster. Agrupando os computadores com software de Big Data (e.g. Spark), consegue-se 2 qualidades muito desejáveis: robustez (pois no caso de um computador falhar o cluster segue trabalhando), e desempenho (pois o paralelismo do Big Data faz aumentar muito a capacidade de processamento do cluster). Essas duas qualidades são justamente o diferencial que os Mainframes sustentam na hora de serem vendidos. Considerando que com o Big Data se consegue finalmente produzir com microinformática as qualidades do Mainframe, surge então a pergunta: será que finalmente conseguimos encontrar uma forma de fazer a microinformática substituir o Mainframe? Antes de ficar animado em demasia é bom lembrar que já se tentou antes substituir o uso de Mainframe, e há casos antológicos de fracasso. Um dos mais citados é a falência do Banco Bamerindus. O leitor interessado pode procurar no Google por “bamerindus Mainframe fracasso” e verá várias histórias. Além disso, deve-se sempre registrar o fato de que Big Data não é uma tecnologia de aceleração computacional de aplicação genérica. Os problemas de TI que permitem tirar proveito das qualidades especiais da arquitetura Big Data devem permitir que os dados fiquem armazenados em HDFS, por exemplo.

Uma empresa ou entidade que hoje está usando Mainframe, muito compreensivelmente, deve olhar com suspeição para um projeto de se implantar Big Data para substituir o Mainframe. Um roteiro prudente para o gestor de TI é o de definir experiências e provas de conceito para serem feitas com tecnologia de Big Data, e verificar na prática o tempo que leva uma aplicação para ser desenvolvida e mantida, e o desempenho e a robustez do serviço quando colocado em produção. É por provar-se viável com experiências práticas que o Big Data poderá abocanhar o mercado. Há um valor adicional no uso de Big Data: trata-se de uma tecnologia open-source, em oposição à tecnologia dos Mainframes, que são tecnologias proprietárias. O cliente pode avaliar por suas próprias perspectivas qual a qualidade e preço do serviço de TI quando é baseado em tecnologias proprietárias, em comparação o que é baseado em tecnologias open-source e padrões abertos. Muita gente tem verificado que essa última abordagem entrega serviço melhor e mais barato. Além da perspectiva do cliente, há também a perspectiva da nação Brasileira. Um projeto de TI baseado em solução proprietária produz um fluxo de dinheiro do Brasil para o local onde moram os proprietários das empresas donas das licenças (muitos moram nos EUA). Essa drenagem de recursos empobrece nossa sociedade. Alternativamente, um projeto de TI baseado em qualquer alternativa open-source (inclusive Big Data) faz o cliente pagar salários e impostos dentro do Brasil, o que irriga e faz aumentar nossa economia local.

Em resumo: A análise do ambiente permite especular que veremos cada vez mais casos de Big Data substituindo usos tradicionais de Mainframe. Nesse jogo, vão ganhar os que souberem de fato desenvolver aplicações Big Data, pois esses são os que vão ganhar os novos contratos. Os usuários e consumidores de serviços de TI vão ganhar também, pois vão livrar-se de hardware e software proprietário, e passar a resolver seus problemas com hardware de prateleira e software básico open-source, o que gerará mais flexibilidade e menor custo. As universidades, escolas de TI e estudantes também vão ganhar, pois poderão usar a melhor tecnologia do mundo sem maiores dificuldades, para seus testes e pesquisas. Pelo mesmo motivo, ganharão também os empreendedores inovadores. Vai ganhar a sociedade brasileira como um todo, pois se deixará de fazer fluir nosso dinheiro para o exterior, em licenças de software. Vão perder os que vendem soluções proprietárias baseadas em Mainframe, que verão esse mercado diminuir (a menos que evoluam seu produto, e entreguem alguma qualidade exclusiva e útil).

--------------------------------------------------------------------------------

Sergio Barbosa Villas-Boas (sbVB), Ph.D.

software development, Big Data, cloud, mobile, IoT, HPC, optimization

sbvillasboas@gmail.com, sbvb@poli.ufrj.br

Skype: sbvbsbvb

http://www.sbVB.com.br

https://www.linkedin.com/in/sbvbsbvb

+55-21-97699-1337

4) Hello Big Data: word count

#bigdata #hadoop #spark

Para quem deseja entender os mecanismos internos da tecnologia de Big Data, um bom começo é estudar o algoritmo “word count”. Trata-se de um algoritmo simples, e que vale-se das boas características do Big Data para produzir um desempenho altamente escalável; de certa forma esse é um algoritmo “Hello World of Big Data”. Considere o seguinte problema: é dado um conjunto de arquivos em formato de texto plano. Deseja-se produzir um relatório com a contagem do número de ocorrências de cada palavra que ocorre nos textos. O algoritmo é descrito a seguir. Faz-se um laço para varrer cada um dos arquivos do conjunto de entrada. Para cada arquivo encontrado, deve-se abri-lo, e varrer cada linha, varrendo cada palavra de cada linha. Para cada palavra encontrada, deve-se acrescentá-la a um objeto contenedor de pares chave-valor, sendo a chave a palavra, e o valor a contagem do número de ocorrências. Na hora de acrescentar uma palavra ao contenedor, se a palavra não existe, cria-se uma chave nova com valor 1. Se a palavra já existe, incrementa-se da contagem correspondente.

Se o volume de dados é enorme, o tempo de execução pode tornar-se insuportavelmente lento. Esse algoritmo pode ser escrito para Big Data, de forma a tirar proveito pleno do elemento especial do Big Data: o sistema de arquivos distribuído HDFS. O conjunto de arquivos de entrada deverá ser carregado no HDFS de um cluster Big Data. Para os arquivos grandes, são criadas divisões e cada parte é salva fisicamente em workers diferentes do mesmo cluster. Um job em Big Data é executado em 3 fases: map-shuffle-reduce. A fase shuffle é sempre a mesma, e portanto é feita internamente pelo software de Big Data (Hadoop ou Spark). É preciso que se escreva o código para implementar as fases map e reduce. Muitas pessoas resumem essa forma de execução de jobs com o nome “Map Reduce”.

Em Hadoop (Big Data geração 1), é explícita a definição do código da fase map e da fase reduce. Usando a linguagem Java, para se escrever a fase map, cria-se uma classe que estende MapReduceBase e implementa Mapper, e escreve-se o código do método map. Para se escrever a fase reduce, cria-se uma classe que estende MapReduceBase e implementa Reducer, e escreve-se o código do método reduce. Para se criar um job Big Data, instancia-se um objeto JobConf, seta-se parâmetros (incluindo passar o nome da classe de Map e de Reduce), e a partir desse objeto, executa-se o job.

Em Spark (Big Data geração 2) é tudo mais simples para o desenvolvedor. Usando a linguagem funcional scala, com 1 linha de código carrega-se os dados num objeto RDD (Resilient Distributed Dataset). Os RDD's são centrais no Spark, e representam uma coleção de qualquer coisa, já tirando proveito das qualidades especiais do Big Data (uso de sistema de arquivos distribuído). Nas linhas de código seguintes executam-se transformações no objeto RDD, de forma a produzir a saída desejada. Internamente o Spark também usa map-shuffle-reduce, mas devido a forma sintética de escrita de código isso não fica tão explícito quanto no caso de Hadoop. O estilo sintético do código em linguagem funcional Scala, base do Spark, é altamente valioso. Com esse estilo, escreve-se menos, e com isso foca-se mais no algoritmo e menos no “encanamento”. O leitor interessado pode procurar no Google por “Hadoop word count example” e “Spark word count example”, e verá que no primeiro caso encontrará um código de 58 linhas, e no segundo um código de 5 linhas. A linguagem orientada a objetos java tem grande tradição, enquanto a linguagem funcional Scala é mais recente, menos conhecida, mas vem crescendo rapidamente. Apesar de a linguagem Scala eventualmente assustar um desenvolvedor experiente, recomendo aos interessados em desenvolver código de aplicações Big Data priorizar o estudo da geração 2 (Spark), com a linguagem funcional Scala.

Na fase map do algoritmo, o código incide sobre um pedaço do conjunto dos dados de entrada, criando em cada worker um contenedor de pares chave-valor, sendo a chave a palavra corrente e o valor 1. A etapa shuffle do algoritmo faz os dados serem transmitidos pela rede, de forma a que em um worker seja feito o trabalho de redução, que nesse caso consiste em somar as ocorrências com mesma chave. Se o conjunto de dados é gigantesco, pode-se acelerar esse algoritmo por se alocar numerosos workers no cluster Big Data. Na fase map do algoritmo cada worker trabalha sobre dados com dimensão igual ao conjunto original dividido pelo número de workers. A escalabilidade é próximo de perfeita nessa fase.

Big Data não é uma arquitetura de software para aceleração computacional com aplicação genérica. Para que ocorra o desempenho de execução altamente escalável do Big Data, é preciso que os dados estejam no HDFS, e que seja possível que na fase map do algoritmo se possa aplicar o foco computacional em cada pedaço do dado de entrada de forma independente.


Seja o problema não computacional a seguir, como metáfora para o uso de Big Data. Alguns palitos são espalhados por toda a área de uma praia muito grande (digamos Copacabana). Deseja-se contar os palitos. Esse problema pode ser resolvido rapidamente dividindo-se a área total em muitos blocos, cada um pequeno, e alocando-se um trabalhador para procurar independentemente em cada bloco. Essa seria a fase map. Em seguida, cada trabalhador transmite (fase shuffle) para um trabalhador que consolide o total de palitos, no que seria a fase reduce.

--------------------------------------------------------------------------------

Sergio Barbosa Villas-Boas (sbVB)

software development, Big Data, cloud, mobile, IoT, HPC, optimization

sbvillasboas@gmail.com, sbvb@poli.ufrj.br

Skype: sbvbsbvb

http://www.sbVB.com.br

https://www.linkedin.com/in/sbvbsbvb

+55-21-97699-1337

3) Foco na Eficácia

#bigdata #hadoop #spark

Particularmente nos serviços de tecnologia de informação, é valorizado o “foco na eficácia”. Em outras palavras, “quem entrega o serviço feito ganha o jogo”. A medida e o julgamento de quais meios e recursos que se usou para entregar o serviço – desde que lícitos, disponíveis, dentro do orçamento e do prazo de entrega – não são a prioridade. Essa abordagem permite uma analogia com um ditado popular. O que importa não é “matar a cobra e mostrar o pau”, mas “matar a cobra e mostrar a cobra morta”. O primeiro caso consiste em “focar no recurso” que se usou para resolver o problema, e o segundo consiste em “focar na eficácia”, isso é, na confirmação de que o serviço foi efetivo.

Big Data é uma forma inovadora de se implementar a computação paralela. A computação, por ser paralela, faz aumentar em tese o poder computacional efetivo. Com a arquitetura Big Data - para uma classe de problemas - a efetividade é particularmente grande. Nesses casos, com muitos computadores worker no cluster, tem-se um enorme poder efetivo. Ou seja, resolve-se problemas computacionais gigantescos em tempo relativamente pequeno.

O leitor já deu-se conta de o quão grande é o problema que a Google resolve no seu site de busca? A Google recebe uma string como parâmetro, e em menos de 1 segundo produz uma lista de links ordenados por peso, a partir de varrer de toda a Internet (Very Big Data), cujo conteúdo foi previamente vasculhado e armazenado localmente no data center da Google. O sofisticado algoritmo de busca leva em conta também volumosos dados pessoais de cada indivíduo, o que faz a busca ficar personalizada e portanto muito mais útil. Segundo o próprio Google, o número de buscas em 2015 anda em torno de 40 mil por segundo ou 3,5 bilhões por dia. A Google chegou tarde no cenário de buscadores, que em 1998 era dominado por Yahoo e Altavista. Como sabemos, o Google cresceu e hoje seu sucesso é supremo, tendo tornado-se líder dos buscadores com larga diferença em relação aos concorrentes. O produto da Google é altamente eficaz. Pouco importa os recursos que a Google aloca para resolver o problema.

Um uso para a computação são as técnicas de “aprendizado de máquina” (machine learning) para efetuar predições. O comércio é uma das muitas atividades que podem beneficiar-se dessas técnicas. Algumas perguntas que interessam ao comerciante incluem: “quais produtos esse cliente provavelmente quer comprar?”, ou “qual a chance de esse cliente ser um bom (ou mau) pagador?”, ou “quantas unidades desse produto eu devo ter em estoque para a próxima temporada de vendas?”, ou “qual o nível de satisfação para os clientes produzido por cada departamento da minha empresa?”, ou ainda “qual o valor do preço desse produto de forma a otimizar o lucro?”. Numa época de competição extrema, e com a possibilidade de uso intensivo de tecnologia de informação para a apoio a negócios, observa-se que grandes empresas de comércio estão investindo para ter boas respostas para perguntas como essas. O que importa para o comerciante é a eficácia do serviço de produzir as tais respostas (basicamente respostas corretas, e entregues no tempo que se espera). Isso é: “a cobra morta”. O método e os recursos que se usam para produzir as respostas é um problema técnico de quem se apresenta como fornecedor do serviço de produzir as respostas. Isso é: “o pau que mata a cobra”. Pensemos num comerciante de alto volume, tal como Amazon. Uma busca no Google mostra que em 2013 a Amazon vendia 426 itens por segundo. O volume de dados a serem processados por um comerciante com essas proporções é evidentemente bem alto, e algumas das perguntas acima tem que ser respondidas com a mesma velocidade das vendas. Trata-se de um grande problema computacional. O enorme poder computacional provido pela arquitetura Big Data é uma excelente alternativa tecnológica para eficazmente resolver o problema. Se o problema está pesado demais para um cluster Big Data com n workers, pode-se aumentar o valor de n. Em muitos casos isso é suficiente.

Existem atualmente empresas que vendem serviços computacionais relacionados a machine learning por meio de API. Essa é uma forma de pronta entrega do serviço, num formato que permite ser integrado ao fluxo de informação de um cliente. Para usar outra expressão popular, um serviço assim é do tipo que “entra porco e sai linguiça”. No exemplo do comerciante, isso seria o comerciante entrar com a base de dados e demais parâmetros, e usar o serviço de machine learning para obter diretamente as respostas o comerciante que deseja, com pouca importância em saber o método e recursos que foram usados para a obtenção das mesmas. É transparente para o comerciante-cliente saber o número de workers do cluster Big Data, assim como é transparente para os usuários e clientes do Google saber quantos computadores eles tem em seu data center. Só se observa a eficácia do serviço.

Em resumo: Força bruta funciona. Big Data é uma tecnologia prática e eficaz de se implementar força bruta. O foco certo é na eficácia.

--------------------------------------------------------------------------------

Sergio Barbosa Villas-Boas (sbVB), Ph.D.

software development, Big Data, cloud, mobile, IoT, HPC, optimization

sbvillasboas@gmail.com, sbvb@poli.ufrj.br

Skype: sbvbsbvb

http://www.sbVB.com.br

https://www.linkedin.com/in/sbvbsbvb

+55-21-97699-1337

2) De Onde Vem a Força do Big Data?

#bigdata #hadoop #spark

Como já escrevi, Big Data é uma arquitetura software para computação paralela que contém uma inovação de ruptura em relação a outras arquiteturas que se conhece para essa finalidade. Mas qual é essa tal inovação? Uma pergunta semelhante seria: de onde vem a força do Big Data? A resposta é que ao contrário das outras tecnologias de computação paralela (e.g. OpenMP, MPI, CUDA, TBB), o Big Data é baseado em um sistema de arquivos (file system) distribuído, chamado HDFS. Esse sistema de arquivos foi proposto e implementado principalmente por Doug Cutting e Mike Cafarella em 2005. O Hadoop (primeira geração de Big Data) foi desenvolvido tirando proveito do HDFS. O Spark (segunda geração de Big Data) baseia-se também em HDFS.

O sistema de arquivos (file system) é um pedaço de um sistema operacional. É o sistema de arquivos que permite que possamos entender o que está em disco como “arquivos”, podendo criá-los, escrever neles, ler deles, renomeá-los, apagá-los. Quase sempre o sistema de arquivos é “concentrado”, o que quer dizer que um arquivo fica integralmente num mesmo disco. O leitor não deve confundir-se com o conceito de se mapear discos pela rede, usado em empresas ou em redes domésticas. Quando se mapeia um disco pela rede, o sistema operacional passa a enxergar um novo disco. Mas esse novo disco deve conter integralmente os arquivos que nele são gravados.

Imagine agora um grupo de computadores, que chamaremos de “cluster”. Queremos que o conjunto todo funcione como um bloco para realizar uma tarefa. Cada computador do cluster será chamado de “worker”, embora as vezes também chamado de “nó” [node] ou “escravo” [slave]. No HDFS, um sistema de arquivos distribuído, arquivos são divididos em blocos, e cada bloco é copiado para o disco de um dos computadores worker do cluster. Isso é particularmente conveniente no caso de os arquivos serem muito grandes. Há ainda um detalhe no HDFS: ao invés de haver apenas 1 cópia de cada bloco, há 3 cópias, em computadores diferentes. Esse detalhe produz o muito desejável efeito de robustez (também chamado de “resiliência”), pois no caso de um computador worker pifar, o sistema detecta a falha e a partir das outras 2 cópias recupera-se completamente. O Big Data é portanto uma arquitetura de software para uso em conjunto (cluster) de vários computadores (workers), que é capaz de trabalhar em paralelo para realizar uma tarefa, e que tem robustez para ser capaz de entregar o trabalho feito mesmo que um computador tenha um defeito no meio do processamento.

Outra vantagem fundamental do uso de sistema de arquivos distribuídos é que o software de Big Data realiza o processamento desejado executando simultaneamente uma parte do algoritmo (chamada de “map”) em que cada worker processa sobre o bloco do arquivo que está salvo no seu disco local. A escalabilidade dessa parte do algoritmo é particularmente alta. Numa fase posterior, os dados são consolidados (reduce) para produzir a saída.

Imagine que se deseje contar quantas vezes ocorre uma dada palavra (digamos “computador”) em um conjunto gigantesco de dados (digamos, o conjunto completo de matérias de um grande jornal). O Big Data trata esse problema particularmente bem, pois pode dividir o conjunto de dados por vários computadores worker, e fazer a busca pela palavra dada em paralelo, sem maiores problemas.

--------------------------------------------------------------------------------

Sergio Barbosa Villas-Boas (sbVB), Ph.D.

software development, Big Data, cloud, mobile, IoT, HPC, optimization

sbvillasboas@gmail.com, sbvb@poli.ufrj.br

Skype: sbvbsbvb

http://www.sbVB.com.br

https://www.linkedin.com/in/sbvbsbvb

+55-21-97699-1337

1) O Que é Big Data?

#bigdata #hadoop #spark

Muito se tem escrito sobre Big Data. Mas nesse mundo de Internet, muito do que se lê são cópias do que alguma outra pessoa escreveu, ou palpites que contém erros conceituais ou são obviedades. O assunto “Big Data” é ainda jovem, principalmente no Brasil. É merecido que se escreva algo didático e direto, por quem trabalha com o assunto, para que se melhore conhecimento sobre essa importante área do conhecimento.


A primeira coisa a se responder é: o que afinal é Big Data? Resposta: Big Data é uma arquitetura software para computação paralela (distribuída) que contém uma inovação de ruptura em relação a outras arquiteturas que se conhece para essa finalidade. Seja a seguinte metáfora: deseja-se mover uma carroça com uma carga. A carroça tradicionalmente era puxada por apenas 1 boi. Uma haste liga o boi à carroça. Quanto mais pesada a carga, mais difícil é de se puxar rapidamente a carroça. Sempre se pode reduzir a marcha (puxar mais lentamente e com mais força). Mas se reduzirmos muito a marcha, a lentidão com que se vai puxar a carroça pode tornar o serviço de mover a carroça insuportavelmente lento. O leitor possivelmente já entendeu que a carga da carroça é a carga computacional, e o boi é a CPU. Computação paralela é o uso de mais de um boi ao mesmo tempo para puxar a carroça. Big Data é um design inovador na haste que conecta os bois à carroça.


Antes do Big Data (isso é, com as tecnologias tradicionais de computação paralela tais como OpenMP, MPI, CUDA, TBB), a haste que conecta vários bois à carroça em muitos casos não permite que todos os bois efetivamente trabalhem para o transmitir sua força para puxar a carroça. O resultado é que muitos bois ficam ociosos, e não se consegue observar na conexão da haste com a carroça uma força equivalente a de um boi multiplicado por todos os bois usados. Com Big Data, aplicado a uma classe de problemas (não se pode aplicar Big Data para qualquer problema computacional !), consegue-se uma excelente escalabilidade. Na metáfora isso corresponde a dizer que posso colocar quantos bois existirem disponíveis, e graças ao design Big Data da haste, consegue-se que a força aplicada a carroça seja a força de um boi multiplicada pelo número de bois. Assim, alocando-se muitos bois conseguimos uma enorme força bruta, que move carroças muito pesadas.


Deve-se complementar definindo também o que Big Data NÃO é. Big Data não é a aplicação de um computador grandão e super poderoso para resolver um problema pesado de computação. Na metáfora isso seria usar bois super fortes. Big Data usa computadores comuns, com potência indistinguível dos que o leitor usa. São computadores ordinários. Além de não serem super fortes, os computadores também não são super confiáveis, isso é, a probabilidade de falha é a mesma dos computadores que o leitor usa. O design inovador da “haste Big Data” de puxar carroça garante robustez. No caso de um boi falhar, os demais seguem trabalhando e perde-se apenas a força do boi que falhou.

--------------------------------------------------------------------------------
Sergio Barbosa Villas-Boas (sbVB), Ph.D.
software development, Big Data, cloud, mobile, IoT, HPC, optimization 
sbvillasboas@gmail.com, sbvb@poli.ufrj.br
Skype: sbvbsbvb
http://www.sbVB.com.br
https://www.linkedin.com/in/sbvbsbvb
+55-21-97699-1337