Thread de 向阳乔木 (@vista8)

O poema Claude 4.5, escrito por Sonnet, é muito bem escrito na minha opinião. (O texto completo contém 17.000 palavras; esta é a primeira parte.) O Deus do Código: Biografia de Jeff Dean Jeff Dean nasceu no Havaí em 23 de julho de 1968. Este arquipélago no Pacífico é conhecido por seus vulcões, praias e cultura diversificada, mas raramente é visto como um berço de gênios científicos. Mas a infância de Dean estava destinada a ser tudo menos comum. Seu pai, Andy, era pesquisador de doenças tropicais. Sua mãe, Virginia Lee, era uma antropóloga médica que falava seis idiomas. Essa origem familiar fez com que sua criação envolvesse migrações globais — do Havaí para os Centros de Controle e Prevenção de Doenças em Atlanta, para a Organização Mundial da Saúde em Genebra e, finalmente, estabelecendo-se em Minnesota. Aos treze anos, ele chegou a faltar aos últimos três meses do oitavo ano para ir a um campo de refugiados no oeste da Somália ajudar seus pais. Esse ambiente em constante mudança fomentou sua intuição precoce sobre sistemas complexos: **sejam os padrões de transmissão de doenças ou, mais tarde, o fluxo de dados em redes de computadores, todos seguiam certas regras que podiam ser compreendidas, modeladas e otimizadas.** Por diversão, pai e filho programaram juntos um computador da suíte IMSAI 8080. Eles soldaram peças de melhoria na máquina e aprenderam sobre cada um dos componentes. Essa experiência de compreender computadores a partir de uma perspectiva de hardware se tornará a pedra angular da carreira de Dean. Ele não só entende a lógica do código, como também compreende como a corrente elétrica flui na pastilha de silício. No ensino médio, Dean começou a escrever um programa de coleta de dados chamado Epi Info para epidemiologistas. Este programa tornou-se uma ferramenta padrão na área, sendo eventualmente distribuído em centenas de milhares de cópias e com suporte para mais de uma dúzia de idiomas. Um site chamado "The Story of Epi Info", mantido pelos Centros de Controle e Prevenção de Doenças dos EUA, ainda preserva uma foto de Jeff quando ele se formou no ensino médio. Mas ele nunca mencionou que essa conquista foi por iniciativa própria. Anos mais tarde, sua esposa Heidi percebeu a importância do programa. "Ele nunca se gaba dessas coisas", disse ela. "Você tem que arrancar isso dele." Na Universidade de Minnesota, Dean optou por uma dupla graduação em Ciência da Computação e Economia. Essa combinação aparentemente incomum revela, na verdade, as duas dimensões do seu pensamento: buscar a excelência tecnológica e, ao mesmo tempo, focar na eficiência de recursos. Ele conheceu Heidi na faculdade. O primeiro encontro deles foi para assistir a um jogo de basquete feminino. Jeff estava vestido de mascote de esquilo e torcendo muito. Em 1990, ele concluiu sua monografia de graduação sobre redes neurais. Esse detalhe pode ter parecido insignificante na época, mas, olhando para trás, vinte anos depois, parece ser um presságio do destino. Naquela época, a pesquisa em redes neurais estava no final do "inverno da IA", e a comunidade acadêmica estava geralmente pessimista quanto às suas perspectivas. Mas o jovem Dean já explorava os segredos de como as máquinas "aprendem" através dos dados. Após a formatura, Dean fez uma escolha incomum: em vez de ir diretamente para uma empresa de tecnologia, ele foi para Genebra trabalhar no Programa Global de AIDS da Organização Mundial da Saúde. Lá, ele desenvolveu um software de modelagem estatística para epidemias, usando código para ajudar os humanos a entender e combater a propagação de doenças mortais. Essa experiência moldou sua compreensão inicial de "escala" — não a escala de clusters de servidores, mas a escala de uma crise global de saúde pública. Quando seu software precisa processar dados que envolvem milhões de vidas, "falha" deixa de ser um termo técnico abstrato e se torna uma verdadeira tragédia humana. ## Ato Um: O Nascimento do Construtor de Sistemas ### Aprendizagem: A Magia do Compilador Em 1996, Dean recebeu seu doutorado em Ciência da Computação pela Universidade de Washington. Sua pesquisa de doutorado focou em compiladores. Software que traduz código escrito por humanos em instruções otimizadas em linguagem de máquina para que os computadores as executem. "Em termos de atratividade, os compiladores são quase as coisas mais entediantes." Seu empresário posterior, Alan Eustace, disse. Por outro lado, elas te aproximam "muito da máquina". Um compilador atua como um tradutor entre programadores e máquinas, e aqueles que otimizam compiladores devem ser proficientes tanto no pensamento humano abstrato quanto nas limitações físicas dos chips de silício. Essa "capacidade bilíngue" se tornará uma vantagem competitiva fundamental na carreira de Dean. Quando Sanjay descreveu Jeff mais tarde, ele fez um gesto circular com o dedo indicador perto da têmpora. "Enquanto você está escrevendo o código, ele já tem um modelo rodando na mente", disse ele. "'Qual será o desempenho deste código?' Ele considerou quase automaticamente todos os casos extremos." Após concluir seu doutorado, ele ingressou no lendário Laboratório de Pesquisa Ocidental da DEC (posteriormente adquirido pela Compaq). Lá, ele trabalhou com um grupo de engenheiros de ponta, concentrando-se em ferramentas de análise, arquitetura de microprocessadores e recuperação de informações. Esses três anos de experiência lançaram uma base sólida para seu trabalho posterior no Google: As ferramentas de análise o ensinaram a entender os gargalos do sistema, a arquitetura de microprocessadores lhe proporcionou uma compreensão profunda da essência do hardware, e a recuperação de informações é o problema central dos mecanismos de busca. Jeff certa vez distribuiu uma lista chamada "Números de Latência que Todo Programador Deveria Conhecer". Na verdade, esta é uma lista de números que quase nenhum programador conhece: **As referências ao cache L1 normalmente levam meio nanossegundo, enquanto a leitura sequencial de um megabyte da memória leva 250 microssegundos.** Esses números estão profundamente gravados em sua mente. ### Sanjay: A Outra Metade do Cérebro Em dezembro, Dean conheceu Sanjay Ghemawat. Sanjay nasceu em West Lafayette, Indiana, em 1966, mas cresceu em Kota, uma cidade industrial no norte da Índia. Seu pai, Mahipal, era professor de botânica. Sua mãe, Shanta, cuidava de Sanjay e de seus dois irmãos e irmãs mais velhos. O irmão de Sanjay, Pankai, foi o membro mais jovem do corpo docente da história da Harvard Business School a receber a titularidade. (Atualmente, ele é professor na Stern School of Business da NYU.) Pankai e Sanjay frequentaram a mesma escola e eram conhecidos por sua erudição. "Eu vivo, de certa forma, à sombra do meu irmão", disse Sanjay. Mesmo na idade adulta, ele manteve o dom da humildade. Quando foi aceito na Academia Americana de Artes e Ciências em 2016, ele não contou aos pais; foram os vizinhos que contaram. Sanjay só teve contato com computadores aos dezessete anos, quando ingressou na Universidade Cornell. Enquanto era estudante de pós-graduação no MIT, sua orientadora foi Barbara Liskov, uma influente cientista da computação cujas áreas de pesquisa incluíam o gerenciamento de bases de código complexas. Na visão dela, o melhor código é como um bom artigo. Requer uma estrutura bem pensada, onde cada palavra deve desempenhar um papel. Programar dessa forma exige empatia pelo leitor. Isso também significa encarar o código não apenas como um meio para um fim, mas como uma obra de arte em si. "Acho que seu maior ponto forte é projetar sistemas", disse Craig Silverstein, o primeiro funcionário do Google. "Se você observar um arquivo de código escrito por Sanjay, sua beleza se assemelha à de uma escultura bem proporcionada." Na DEC, Jeff caminhava dois quarteirões de seu laboratório de pesquisa até o laboratório de Sanjay. "Havia uma gelateria italiana no meio", lembrou Jeff. Sanjay exclamou, entusiasmado: "Então é por causa daquela sorveteria!" Eles começaram a programar juntos — em vez de trabalharem em seus próprios computadores, compartilhavam um computador, com uma pessoa operando o teclado e a outra orientando e corrigindo as informações. Esse tipo de colaboração não é comum no desenvolvimento de software. Em seu livro de 2001, *Collaboration Circles: The Dynamics of Friendships and Creative Work*, o sociólogo Michael P. Farrell destaca que: "A maioria das ideias iniciais que formam a base de novas perspectivas não surge quando todo o grupo se reúne, nem quando os membros trabalham sozinhos, mas sim quando colaboram em pares e respondem uns aos outros." Foi Monet e Renoir, trabalhando lado a lado no verão de 1869, que desenvolveram o estilo que mais tarde se tornaria o Impressionismo. Durante os seis anos de colaboração que deram origem ao Cubismo, Picasso e Braque frequentemente assinavam apenas o verso da tela para ocultar a autoria de cada pintor. "Não sei por que mais pessoas não fazem isso", disse Sanjay, referindo-se à programação com parceiros. "Você precisa encontrar alguém cujo modo de pensar seja compatível com o seu para fazer programação em dupla, para que vocês dois possam se complementar", disse Jeff. Em meados de 1999, a bolha da internet estava se aproximando do seu auge. Jeff saiu da DEC e entrou para uma pequena empresa chamada "Google". Naquela época, o Google tinha apenas algumas dezenas de funcionários, e seus escritórios estavam localizados em um prédio discreto em Mountain View, na Califórnia. Dez meses depois, Sanjay o seguiu. A colaboração lendária entre eles está prestes a mudar a história da internet. Março de 2000: Desastre e Renascimento Certo dia, em março de 2000, seis dos melhores engenheiros do Google se reuniram em uma sala de guerra improvisada. A empresa está enfrentando uma emergência sem precedentes. Em outubro passado, seu sistema principal — o sistema responsável por rastrear páginas da web para construir um "índice" — parou de funcionar. Embora os usuários ainda possam inserir consultas em https://t.co/cHDYnkjtpa, eles receberão dados antigos, de cinco meses atrás. Para piorar a situação, os cofundadores do Google, Larry Page e Sergey Brin, estavam negociando um acordo para fornecer suporte ao mecanismo de busca do Yahoo, prometendo entregar um índice dez vezes maior do que o existente na época. Se falharem, a https://t.co/cHDYnkjtpa ficará presa ao passado, o acordo com o Yahoo provavelmente fracassará e a empresa correrá o risco de ficar sem fundos e falir. Em uma sala de conferências perto da escada, os engenheiros colocaram painéis de porta na serraria e configuraram seus computadores. Craig Silverstein, o primeiro funcionário do Google, estava sentado perto da parede do fundo. Ele e um engenheiro de sistemas romeno chamado Bogdan Cocosel trabalharam durante quatro dias e quatro noites, mas sem sucesso. "Todas as nossas análises não faziam sentido", recordou Silverstein. "Tudo estava quebrado e não sabíamos porquê." Silverstein mal notou a presença de Sanjay Gomawater à sua esquerda, atrás dele. Sanjay havia ingressado na empresa apenas alguns meses antes, vindo da DEC com Jeff Dean. Na sala de operações, Jeff deslizou sua cadeira para perto da mesa de Sanjay, deixando um assento vazio para si. Sanjay operava o teclado, enquanto Jeff se inclinava perto dele, corrigindo e orientando-o como um produtor sussurrando no ouvido de um apresentador de telejornal. Jeff e Sanjay começaram a examinar o índice estagnado mais de perto. Descobriram que algumas palavras estavam faltando — a busca por "mailbox" não retornava resultados, enquanto outras palavras estavam fora de ordem. Durante dias, eles estiveram à procura de falhas no código, mergulhando em sua lógica. Após verificar cada seção, tudo parecia estar em ordem. Eles não conseguiram encontrar o bug. No quinto dia na sala de operações, Jeff e Sanjay começaram a suspeitar que o problema que procuravam não era lógico, mas físico. Eles converteram o arquivo de índice desorganizado em sua representação mais primitiva: **código binário.** Eles queriam ver o que a máquina deles estava vendo. No monitor de Sanjay, apareceu uma densa coluna de 1s e 0s, cada linha representando um termo de índice. Sanjay apontou para um número que deveria ser 0, mas que havia se tornado 1. Quando Jeff e Sanjay juntaram todas as palavras fora de ordem, perceberam um padrão: cada palavra tinha as mesmas pequenas falhas. O chip de memória da máquina deles estava danificado por algum motivo. Sanjay olhou para Jeff. O Google vem registrando um número crescente de falhas de hardware nos últimos meses. O problema é que, à medida que o Google cresce, sua infraestrutura de computação também se expande. O hardware de computador raramente falha, a menos que você tenha muitos componentes — nesse caso, ele falhará com frequência. Fios desgastados, falha no disco rígido, superaquecimento da placa-mãe. Muitas máquinas não funcionam desde o início; algumas inexplicavelmente ficam mais lentas. Estranhos fatores ambientais também começaram a surtir efeito. Quando uma supernova explode, a onda de choque produz partículas de alta energia que se dispersam em todas as direções; os cientistas acreditam que essas partículas dispersas, conhecidas como raios cósmicos, têm uma probabilidade muito pequena de atingir chips de computador na Terra e inverter os 0s para 1s. Os sistemas de computador mais robustos do mundo, como os usados ​​pela NASA e por empresas financeiras, utilizam hardware especial que tolera inversões de bits. Mas o Google, na época, ainda operava como uma startup, comprando computadores baratos que não possuíam esse recurso. Em um prédio em Santa Clara, na Califórnia, o Google empilhou 1.500 placas-mãe e discos rígidos como sanduíches em uma torre de quase dois metros de altura. Devido a uma falha de hardware, apenas 1.200 unidades estão operacionais. A empresa chegou a um ponto de virada. Seus clusters de computadores se tornaram tão grandes que até mesmo falhas raras de hardware se tornaram inevitáveis. Jeff e Sanjay escreveram juntos um código para compensar as máquinas com defeito. Pouco tempo depois, o novo índice foi concluído e a sala de operações foi desativada. ### Reescrita de Fim de Semana: O Nascimento dos Sistemas Elásticos Essa crise se tornou um ponto de virada. Jeff e Sanjay perceberam que, à medida que o Google crescia, as falhas de hardware não seriam acidentais, mas sim a norma. Quando se tem milhares ou dezenas de milhares de servidores, haverá falhas de máquinas, problemas de disco rígido e interrupções de rede todos os dias. Se o sistema não conseguir lidar com essas falhas, o Google não conseguirá escalar. Eles precisam construir uma infraestrutura completamente nova: **um sistema capaz de manter a ordem em meio ao caos.** A filosofia central do projeto de reescrita deste fim de semana é **esperar falhas**. Em vez de presumir que o hardware é perfeito, é melhor presumir que o hardware *irá* falhar. O sistema precisa ser capaz de detectar automaticamente dados corrompidos, sinalizar máquinas com defeito e ignorá-las para continuar operando. A ideia de "tolerância a falhas" é senso comum em sistemas distribuídos hoje em dia, mas era radical em 2000. Antes da falha do índice em março, o sistema do Google era baseado em código escrito por seus fundadores quando eles eram estudantes de pós-graduação na Universidade de Stanford. Page e Brin não são engenheiros de software profissionais. São acadêmicos que estão realizando experimentos com tecnologia de busca. Quando o rastreador da web deles travou, não havia nenhuma mensagem de diagnóstico que fornecesse qualquer informação — apenas a frase "Whoa, horsey!" Os primeiros funcionários se referiam a um software chamado BigFiles, escrito por Page e Brin, como BugFiles (arquivos cheios de erros). O código de indexação essencial leva dias para ser concluído e, se surgirem problemas, eles precisam começar do zero. Na linguagem do Vale do Silício, o Google, naquela época, carecia de "escalabilidade". Wayne Rosing trabalhou anteriormente na Apple no desenvolvimento do precursor do computador Macintosh, antes de ingressar no Google em novembro de 2000 para gerenciar sua equipe de 100 engenheiros. "Eles são os líderes", disse ele. Jeff e Sanjay trabalharam juntos para reconstruir a infraestrutura do Google. Eles trabalham 90 horas por semana escrevendo código para que uma única falha no disco rígido não cause a falha de todo o sistema. Eles adicionaram pontos de verificação durante o processo de rastreamento para que ele pudesse ser reiniciado no meio. Ao desenvolverem novos esquemas de codificação e compressão, eles efetivamente dobraram a capacidade do sistema. Eles são otimizadores implacáveis. Quando um carro faz uma curva, as rodas externas precisam cobrir uma área maior do chão. Da mesma forma, a borda externa de um disco rígido giratório se move mais rápido do que a borda interna. O Google moveu os dados acessados ​​com mais frequência para a parte externa para que os bits de dados possam fluir mais rapidamente sob a cabeça de leitura/gravação, mas a parte interna está meio vazia; Jeff e Sanjay usaram esse espaço para armazenar dados pré-processados ​​para consultas de pesquisa comuns. Em quatro dias, em 2001, eles provaram que o índice do Google podia ser armazenado usando memória de acesso aleatório (RAM) de alta velocidade, em vez do disco rígido, que era relativamente lento. Essa descoberta remodelou o modelo econômico da empresa. Page e Brin sabiam que os usuários recorreriam em massa a serviços que pudessem fornecer respostas instantaneamente. O problema é que a velocidade exige poder computacional, e poder computacional custa dinheiro. Jeff e Sanjay resolveram o problema de forma inteligente usando um software. Alan Eustace assumiu a chefia da equipe de engenharia após a saída de Rossin em 2005. "Para resolver o problema de escala, paradoxalmente, é preciso entender os mínimos detalhes", disse Eustace. Jeff e Sanjay entendem de computadores em nível de bits. Durante as diversas reformulações do software principal do Google, que eles ajudaram a liderar, a capacidade do sistema expandiu-se em várias ordens de magnitude. Enquanto isso, no enorme centro de dados da empresa, os técnicos agora percorrem rotas sinuosas, seguindo instruções geradas por software para substituir discos rígidos, fontes de alimentação e módulos de memória. Mesmo que seus componentes se desgastem e falhem, o sistema ainda pode operar normalmente. ### MapReduce: Simplificando o Caos Em 2004, Dean e Gemmawater publicaram um artigo intitulado "MapReduce: Processamento de Dados Simplificado em Grandes Clusters". Este artigo tem apenas dois autores, mas vai mudar toda a indústria. A ideia central do MapReduce é extremamente simples: **ele abstrai a computação distribuída complexa em duas funções — `Map` e `Reduce`.** A função `Map` processa os dados de entrada e gera pares intermediários de chave-valor. A função `Reduce` agrega valores com a mesma chave para gerar o resultado final. Os programadores só precisam definir essas duas funções, e o sistema lidará automaticamente com a paralelização, o agendamento de tarefas, a comunicação entre máquinas e a recuperação de falhas. O poder dessa abstração reside em sua **simplicidade**. Antes do MapReduce, escrever programas distribuídos exigia um conhecimento profundo de sistemas — era necessário gerenciar threads manualmente, lidar com a comunicação em rede e com falhas de máquinas. Essas complexidades afastam a maioria dos programadores. No entanto, o MapReduce oculta essas complexidades dentro do sistema, permitindo que engenheiros sem experiência em sistemas distribuídos lidem facilmente com terabytes de dados. Um exemplo apresentado no artigo é a contagem da ocorrência de cada palavra em um grande número de documentos. A função `Map` lê um documento e retorna pares chave-valor de `(palavra, 1)`. A função `Reduce` soma as contagens de palavras iguais. Todo o programa requer apenas algumas linhas de código, mas pode ser executado em paralelo em milhares de máquinas, processando páginas da web em toda a internet. Outra contribuição fundamental do MapReduce é a **tolerância a falhas**. O sistema monitorará continuamente a execução da tarefa e, se ela falhar em uma máquina, a executará novamente automaticamente em outra máquina. Essa estratégia de "reexecução" funciona porque as funções `Map` e `Reduce` são projetadas para serem "funcionais" — elas não modificam os dados de entrada, apenas produzem a saída. Isso significa que executar uma tarefa novamente não produzirá efeitos colaterais e o resultado será determinístico. Este projeto foi diretamente inspirado pelas lições da "crise de 2000": o hardware pode falhar, mas o sistema deve continuar funcionando. O MapReduce rapidamente ganhou popularidade dentro do Google. É utilizado para construir índices de pesquisa, processar dados de registro, gerar relatórios e treinar modelos de aprendizado de máquina. Quando o artigo foi publicado em 2004, centenas de programas MapReduce já estavam em execução no Google. Mais importante ainda, as ideias por trás do MapReduce se espalharam por toda a indústria. Com base nesse artigo, o Yahoo desenvolveu o Hadoop, uma implementação de código aberto do MapReduce, que se tornou a pedra angular da era do big data. ### Bigtable: A Arte do Armazenamento Se o MapReduce resolve o problema da computação em larga escala, então o Bigtable resolve o problema do armazenamento em larga escala. Em 2006, Dean e Gemmawater, juntamente com vários outros engenheiros do Google, publicaram "Bigtable: um sistema de armazenamento distribuído para dados estruturados". O Bigtable foi projetado para gerenciar petabytes de dados estruturados, oferecendo suporte a processamento em lote de alto desempenho e consultas em tempo real de baixa latência. Isso apresenta uma exigência aparentemente contraditória: **o processamento em lote precisa analisar grandes quantidades de dados, enquanto as consultas em tempo real precisam retornar rapidamente um único resultado.** Os bancos de dados relacionais tradicionais não conseguem atender a esses dois requisitos simultaneamente. A solução da Bigtable é um modelo de dados único: trata-se de um "mapa multidimensional esparso, distribuído e persistente, ordenado". Cada item de dados é indexado por três dimensões: chave da linha, chave da coluna e carimbo de data/hora. Este design oferece grande flexibilidade: - **Chave de linha**: Os dados são armazenados classificados por chave de linha, com chaves de linha adjacentes armazenadas na mesma máquina. Isso torna a varredura de um intervalo de dados muito eficiente. - **Famílias de colunas**: As colunas são organizadas em famílias de colunas, e cada família de colunas pode ter suas próprias políticas de controle de acesso e compressão. Isso permite que o sistema otimize o armazenamento com base em diferentes padrões de acesso. - **Carimbo de data/hora**: Cada item de dados pode ter várias versões, diferenciadas por um carimbo de data/hora. O sistema pode reter automaticamente as N versões mais recentes ou a versão dos T dias mais recentes; as versões mais antigas serão coletadas pelo coletor de lixo. Outra característica fundamental do design do Bigtable é que ele *não* é um banco de dados relacional. Não suporta consultas SQL complexas nem transações entre linhas. Essas limitações são intencionais — **elas permitem que o sistema seja dimensionado horizontalmente em milhares de máquinas sem ser prejudicado por protocolos de consistência complexos.** No Google, o Bigtable é usado para armazenar índices de páginas da web, dados geográficos do Google Earth, dados de comportamento do usuário do Google Analytics e muito mais. Sua influência também se estendeu a todo o setor: o DynamoDB da Amazon, o Cassandra do Facebook e o HBase da Apache foram todos inspirados pelo Bigtable. ### Spanner: O ápice da consistência global MapReduce e Bigtable lançaram as bases da infraestrutura do Google, mas ambos compartilham uma limitação comum: foram projetados principalmente para uso em um único centro de dados. À medida que o Google se expande globalmente, os dados precisam ser distribuídos por todos os continentes. Manter a consistência dos dados em nível global tornou-se o próximo desafio. Em 2012, Dean e Gemmawater, juntamente com outros engenheiros, publicaram "Spanner: o banco de dados distribuído globalmente do Google". Spanner é o primeiro banco de dados distribuído globalmente do mundo a oferecer suporte a "transações distribuídas externamente consistentes". A principal inovação do Spanner é a **API TrueTime**. Em sistemas distribuídos, o tempo é uma questão complexa. Os relógios em máquinas diferentes podem estar dessincronizados, e a latência da rede significa que você não pode ter certeza da ordem real de dois eventos. A solução da Spanner é aproveitar o GPS e os relógios atômicos para construir uma API que possa *expor as incertezas do relógio*. O TrueTime não dirá "São 12:00:00 agora", mas sim "São 12:00:00 agora, com uma margem de erro de ±7 milissegundos". Ao conhecer precisamente essa incerteza, o Spanner consegue atribuir timestamps de confirmação significativos às transações globais. Se a incerteza for muito grande, o sistema irá proativamente "esperar que a incerteza passe" — isso é chamado de "espera de confirmação". Essa espera normalmente leva apenas alguns milissegundos, mas garante a consistência externa da transação: se a transação T1 for confirmada antes da transação T2, o carimbo de data/hora de T1 deverá ser menor que o carimbo de data/hora de T2. A criação de Spanner marcou a conclusão da "Trilogia dos Sistemas" de Dean. De MapReduce (computação tolerante a falhas) para Bigtable (armazenamento tolerante a falhas) e, em seguida, para Spanner (consistência global). Esses três sistemas, juntos, formam a vantagem competitiva tecnológica do Google. Eles não apenas apoiaram os principais negócios do Google, como buscas, publicidade e Gmail, mas também forneceram a infraestrutura para a onda posterior de inteligência artificial. Em 2025, o Spanner recebeu o prêmio ACM SIGMOD System Award por "reimaginar o gerenciamento de dados relacionais para alcançar a serializabilidade com consistência externa em escala global". Este é o mais recente reconhecimento do trabalho que Dean e Gemmawater realizaram há mais de uma década. ### Efeitos de Cauda de Escala: O Ápice da Filosofia de Sistemas Em 2013, Dean e Gemmawater publicaram outro artigo influente: "A Cauda em Escala". Este artigo explora um problema que é comum em sistemas de grande escala, mas que muitas vezes é negligenciado: a **latência de cauda**. No sistema do Google, uma única solicitação de usuário pode exigir acesso a centenas de servidores. Mesmo que o tempo médio de resposta de cada servidor seja rápido, se apenas 1% dos servidores estiverem lentos (por exemplo, devido à coleta de lixo, E/S de disco ou congestionamento de rede), isso afetará negativamente a maioria das solicitações dos usuários. Isso ocorre porque as solicitações dos usuários precisam aguardar respostas de *todos* os servidores, e o servidor mais lento determina a latência geral. A grande sacada do artigo é que tentar eliminar todas as fontes de atraso é "irrealista". O hardware falhará, as redes ficarão congestionadas e os sistemas operacionais apresentarão instabilidades. Em vez de buscar a perfeição, é melhor construir um sistema "tolerante a falhas extremas" — um conceito que ecoa sua filosofia pós-crise de 2000 de construir sistemas "tolerantes a falhas". O artigo propõe uma série de técnicas para lidar com a latência de cauda: - **Solicitação de Hedge**: Envie a mesma solicitação para várias réplicas e use a resposta mais rápida. - **Solicitação de Vinculação**: Envia uma solicitação para várias réplicas, mas cancela as solicitações para outras réplicas assim que uma réplica inicia o processamento. - **Microparticionamento**: Divide os dados em partições menores, permitindo que a carga de trabalho seja migrada de forma mais flexível entre máquinas. - **Replicação seletiva**: Crie mais réplicas para os dados acessados ​​com frequência para distribuir a carga. A ideia central por trás dessas tecnologias é construir serviços elásticos e de alto desempenho em hardware não confiável e com velocidades variáveis, através de redundância e agendamento inteligente. Em 2025, "The Tail at Scale" recebeu o prêmio ACM SIGOPS Hall of Fame, em reconhecimento por "resistir ao teste do tempo". Este artigo não só influenciou o design do sistema do Google, como também se tornou um documento clássico em toda a indústria. ### Dean e Gemmawater: Uma Colaboração Lendária Ao contar a história de Dean, é impossível não mencionar sua colaboração com Sanjay Gormwalt. Eles são os *únicos* dois autores do artigo sobre MapReduce, os principais criadores do Bigtable e do Spanner, e coautores de "The Tail at Scale". Eles começaram a colaborar na DEC, superaram juntos a "crise de 2000" no Google e trabalharam juntos para construir a base tecnológica do Google pelas próximas duas décadas. Em 2012, eles receberam conjuntamente o Prêmio de Computação da ACM em reconhecimento à sua "concepção, projeto e implementação da revolucionária infraestrutura de software do Google". Em 2009, ambos foram eleitos membros da Academia Nacional de Engenharia. A colaboração entre eles foi descrita como "a amizade que salvou o Google e inventou a internet moderna". Mas essa parceria também deu origem a um interessante fenômeno cultural: os "Fatos sobre Jeff Dean". ### "Meme do Jeff Dean": Admiração e Arrependimento Por volta do Dia da Mentira de 2007, uma série de piadas sobre Jeff Dean começou a circular internamente no Google, imitando a "piada do Chuck Norris". Essas piadas exageravam as habilidades técnicas de Dean, por exemplo: - "Jeff Dean escreveu o código binário diretamente; o código-fonte era apenas documentação para outros lerem." — "O teclado do Jeff Dean não tem tecla Ctrl — porque ele está sempre no controle." — "O compilador não avisará Jeff Dean. Jeff Dean avisará o compilador." "A velocidade da luz no vácuo costumava ser muito lenta, mas Jeff Dean otimizou a física em um fim de semana." Esses memes se espalharam rapidamente dentro do Google e, posteriormente, permearam toda a indústria de tecnologia. Essas declarações refletem a admiração dos engenheiros por Dean — ele não era apenas um especialista técnico excepcional, mas também um "deus da programação" capaz de resolver qualquer problema. Mas esses memes também apresentam um problema: dão a impressão de que "Jeff é melhor que Sanjay". Na verdade, as contribuições de Dean e Gemmawater foram iguais, e a colaboração entre eles foi complementar. O criador do meme teria expressado arrependimento posteriormente, acreditando que "o único motivo era que o nome 'Jeff' parecia 'mais interessante'". Esse detalhe revela a discrepância entre a percepção pública e a história real. A lenda de Dean não é um feito de um homem só, mas sim uma colaboração que já dura mais de 20 anos.