> For the complete documentation index, see [llms.txt](https://vitalino.gitbook.io/index-of/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vitalino.gitbook.io/index-of/bigdata/uma-brevissima-historia-do-hadoop-e-sua-relacao-com-o-google.md).
# Uma brevíssima história do Hadoop e sua relação com o Google
#### Como o Google funciona
Estima-se que em 1998 existiam mais de 2 milhões e 400 mil web sites (e com previsão para um crescimento explosivo para os próximos anos).
Para orientar os usuários a encontrar novos sites, catálogos de listas de sites e buscadores foram surgindo (como o Yahoo, AltaVista, Lycos, Infoseek, **Excite**, dentre outros).
Mas neste ano de 1998 surgiu uma startup de dados lançando um novo buscador que visava **enriquecer a experiência do usuário** trazendo resultados de maior **relevância** já na primeira página da busca.
A proposta simples escondia uma grande complexidade por trás.
Basicamente, a Google funcionava sobre três ações:
1. um *web crawler* (Googlebot) ficava 24/7 varrendo toda a web procurando por novas páginas de sites e as salvando em cache.
2. os dados em cache eram processados: um *parsing* era feito nas páginas onde todo o conteúdo era extraído e, baseado em uma lista de critérios internos da Google, um algoritmo de rankeamento chamado **PageRank** calculava o *score* dessa página (onde quanto maior o score, maior a relevância do site).
3. por fim, o link do site + o score dele + o conteúdo era gravado em uma estrutura de **índice invertido**.
Dessa forma, quando um usuário acessava o frontend do Google Search, a string de busca era passada para o backend e o backend iria consultar a string na estrutura de índice invertido, procurando por links de sites ordenando o resultado de forma decrescente de acordo com o score deles.
Fazendo uma busca no frontend do Google Search em 1998.
De uma forma extremamente simplificada, é como se o backend do Google fizesse essa consulta:
```sql
SELECT link FROM indexed_websites
WHERE content LIKE '%user_string%' ORDER BY score DESC;
```
####
#### As problemáticas enfrentadas pela Google
Fazendo uma estimativa bem superficial, só para termos uma ideia, 1 milhão de sites salvos em cache pode consumir mais ou menos **1 TiB de armazenamento**. No fim do ano 2000 já existiam mais de 40 milhões de sites. Hoje existem mais de 1 bilhão de sites.
É claro que a Google não consegue indexar todos, mas só uma pequena porcentagem deles já gera um grande volume de dados para ela lidar internamente.
Além de armazenar as cópias brutas dos sites, é importante ter alguma **redudância** no armazenamento delas (já que um disco ou um servidor inteiro pode falhar, por exemplo). E depois de processados, mais armazenamento será necessário para as bases de dados auxiliares e as bases finais onde estarão presentes os sites indexados.
Imagine quantos terabytes de dados iriam consumir ao indexar 10 milhões de sites? E 20 milhões?
Como resultado de tudo isso, a Google passou a enfrentar as seguintes problemáticas:
* como manter uma infraestrutura de armazenamento de grandes volumes de dados escalável e tolerante a falhas?
* como processar esses grandes volumes de dados em tempo hábil?
#### Soluções internas da Google
Como na época não existiam soluções prontas para estes problemas, então o jeito foi desenvolvê-las internamente.
Foi aí que, para resolver os problemas de armazenamento a Google criou o **GFS** (Google File System), e para resolver os problemas de processamento dos dados, ela criou o **MapReduce**.
O GFS armazena os arquivos distribuindo os **fragmentos** dele para os diferentes nós do **cluster**. Além disto, ele **replica** os fragmentos para outros nós. Com isto, é possível obter **escalabilidade** no armazenamento ao poder adicionar mais nós ao cluster (ou seja, aumentar o espaço de armazenamento), e também **tolerância a falhas** pela redundância dos dados (se um dos nós do cluster GFS falhar, os dados ainda estarão disponíveis).
O **MapReduce** é um *framework* de programação distribuída que permite que o **processamento de grandes volumes de dados** seja paralelizado através dos vários nós do cluster. O MapReduce pode trabalhar integrado ao GFS para que as subtarefas sejam executadas sobre cada fragmento do dado do GFS.
Em 2003 a Google publicou um paper descrevendo o funcionamento do GFS, e em 2004 publicou outro paper descrevendo o MapReduce.
Papers do Google que inspiraram o desenvolvimento do HDFS e do MapReduce do Hadoop.
#### E então surgiu o Hadoop
Em 2001, um programador chamado Doug Cutting (que já havia trabalhado em um serviço de busca chamado Excite), iniciou o projeto de um web crawler chamado Apache Nutch. A ideia do Apache Nutch era ser uma solução completa para quem quisesse subir seu próprio serviço de busca.
Mas com a publicação dos papers da Google, o Doug Cutting resolveu também desenvolver sua própria versão do GFS e do MapReduce, inicialmente, como componentes do Nutch.
Mas em 2005, o projeto ganhou brilho próprio desvinculando do Nutch e se tornando o: **Apache Hadoop**.
No Hadoop, o GFS passou a ser chamado de **HDFS** (Hadoop Distributed File System) e o MapReduce continou sendo chamado de MapReduce.