(continuação da parte 3)
Na etapa seguinte de sua palestra, Luiz André Barroso abordou a tecnologia de sistemas distribuídos do Google, em especial, seu sistema de armazenamento de informações, denominado GFS (Google File System). O GFS atende a requisitos únicos e jamais antes encontrados na História da Computação:
(a) altíssima largura de banda para leitura e escrita;
(b) confiabilidade sobre uma matriz de milhares de nodos;
(c) opera em sua maioria com grandes blocos de dados;
(d) necessita de uma operação distribuída eficiente.
Em contrapartida, trata-se de um sistema de arquivos que tem uma grande vantagem quando comparado a outros sistemas do tipo: a turma do Google tem controle completo sobre as aplicações, bibliotecas e sobre o sistema operacional. Eles usam Linux.
Na figura acima, os "
Masters" gerenciam meta-dados, ou seja, dados a respeito de dados. A transferência de informações se dá diretamente entre os "
Clients" e os "
ChunkServers". Os arquivos são quebrados em pedaços (
chunks) de 64 MB cada. Com relação ao uso do GFS pelo Google, funcionam nele mais de 50 clusters, cada um com mais de 1000 computadores. São formados
pools com mais de 1000 clientes cada um, num total de mais de 1 Petabyte de arquivos. A carga de leitura e escrita é de mais de 5 GB por segundo. E tudo isso na presença de freqüentes falhas de hardware, ou seja, o sistema de arquivos é suficientemente esperto para segurar essa barra.
O GFS é um sistema de armazenamento distribuído de alta confiabilidade capaz de crescer até a escala de Petabytes mantendo os dados guardados nesses
chunks de 64 MB, armazenados em discos espalhados por milhares de computadores. Cada
chunk é replicado em média três vezes em diferentes máquinas, de tal modo que o GFS pode se recuperar de modo transparente em caso de falha de disco ou de máquina.
O GFS roda como um sistema de arquivos a nível de aplicação com um esquema hierárquico de nomeação de arquivos. Os próprios data-sets são mantidos numa estrutura regular representada por um vasto conjunto de arquivos GFS com cerca de um 1 GB cada um. Por exemplo, um repositório documental, resultado de um crawl na web -- ele pode conter alguns bilhões de páginas HTML e se mantém gravado como uns milhares de arquivos, cada um armazenando algo em torno de um milhão de documentos com alguns kilobytes cada, comprimidos, é claro.
[Leia um excelente artigo interno do Google sobre o GFS, em inglês, aqui, em PDF.]
Muitos dos problemas enfrentados pelo Google se resumem em processar um montão de dados para produzir mais dados. Além disso, há vários tipos de entrada de informações, tais como registros de documentos, arquivos log (
log = registro histórico acumulativo), estruturas de dados ordenadas em disco e outros. A solução é usar centenas ou milhares de CPUs, mas de um jeito que seja relativamente fácil. Com tudo isso em mente, a turma do Google bolou um arcabouço chamado MapReduce que, para certas classes de problemas, proporciona paralelização e distribuição automáticas e eficientes, tolerância a falhas, escalonamento de entradas e saídas, além de monitoramento de status.
Distribuição geográfica das queries feitas ao Google. Observe a altíssima densidade no leste dos EUA, na Europa, no Japão e no leste da Austrália. O resto? Bem, o resto é resto!
A comunidade interna do Google que lida com os dados armazenados pelo sistema ás vezes se dá ao luxo de fazer inofensivas brincadeiras estatísticas com estas informações. Afinal de contas eles têm ao seu dispor uma considerável fração da Web para usar como massa de entrada para estes folguedos. Possuem também uma invejável capacidade computacional: Teraflops de CPU e Petabytes de arquivos. Através da utilização da poderosíssima e afamada ferramenta
Sawmill para análise de logs, a equipe do Google tem ao seu dispor infraestrutura e linguagem adequadas para processar imensas quantidades de registros de log. Esta ferramenta é crítica para contar os clicks dos usuários Google e serve também para alguma diversão através do que se pode aprender sobre a web, analisando os dados residentes nela e o acesso da massa de internautas a ela.
Diversos exemplos de queries mostrando os picos de acesso em função das datas.
Na foto acima vemos o palestrante mostrando diversas queries analisadas em função dos momentos em que foram feitas. Quando algum acontecimento marcante se dá, o número de queries ao Google apresenta picos perfeitamente sincronizados com o evento, evidenciando algo que já era de se esperar: o internauta recorre ao Google para conhecer detalhes sobre o que está se passando. Quando ocorrem eclipses, por exemplo, as pessoas se interessam mais pelo tema e, conseqüentemente, saem googlando feito loucas. O mesmo se dá com a "
world series" (Copa do Mundo), "
full moon" (noites de lua cheia), "
summer olympics" (olimpíadas), "
watermelon" (melancia, que é mais consumida no verão), e "
Opteron", que gerou um nítido pico por ocasião do lançamento deste processador.
Queries típicas brasileiras feitas ao Google
Na imagem acima é fácil ver a periodicidade e a recorrência de algumas queries feitas por internautas brasileiros interessados em temas como vestibular, Carnaval, férias, Natal e Reveillon.
Quem adivinha o que aconteceu no domingo de baixo?
Nesta foto vê-se na parte de cima a curva de picos de queries num domingo comum na Alemanha. Na curva de baixo, as queries num domingo muito especial: jogo da seleção alemã na Copa do Mundo. Note-se no pequeno círculo vermelho a queda dos acessos ao Google durante o primeiro e o segundo tempo. No intervalo da partida, porém, a alemoada acessou bastante, querendo saber coisas sobre o jogo, provavelmente. Segundo Luiz André, numa outra estatística interessante, analisando os logs espanhóis pode-se perceber claramente os horários em que se pratica a
siesta, ou seja, a consagrada soneca espanhola depois do almoço.
(Continua na parte 5, a final.)
Entrar
Registrar
FAQ
