MIT 6.824 Aula 1: Sistemas Distribuídos & MapReduce

[0:01] Certo, vamos começar. Este é 6824, sistemas distribuídos. Um, obrigado. Então eu gostaria de começar com apenas uma breve explicação do que eu penso que é um sistema distribuído. Obrigado. O núcleo disso é um conjunto de computadores cooperantes que estão se comunicando uns com os outros pela rede para realizar alguma tarefa coerente. Os tipos de exemplos que vamos focar nesta aula são coisas como armazenamento para grandes sites, ou computações de big data como MapReduce, Um, E também coisas um tanto mais exóticas como compartilhamento de arquivos peer-to-peer.

[0:43] Esses são todos apenas exemplos dos tipos de estudos de caso que veremos. Hum, e a razão pela qual tudo isso é importante é que muita infraestrutura crítica por aí é construída a partir de sistemas distribuídos. Infraestrutura que exige mais de um computador para realizar seu trabalho ou que, por natureza, precisa ser espalhada fisicamente. Hum. Então, as razões pelas quais as pessoas constroem essas coisas, Primeiro, antes mesmo de eu falar sobre sistemas distribuídos, só quero lembrar que se você está projetando um sistema, você precisa resolver algum problema, se você puder possivelmente resolvê-lo, em um único computador.

[1:17] você sabe, sem construir um sistema distribuído, você deveria fazer dessa forma. E há muitos, muitos trabalhos que você pode realizar em um único computador, e é sempre mais fácil. Então, sistemas distribuídos, você deveria tentar tudo o mais antes de tentar construir sistemas distribuídos, porque eles não são mais simples. Então, a razão pela qual as pessoas são levadas a usar muitos computadores cooperando é que elas precisam obter alto desempenho. E a maneira de pensar sobre isso é que elas querem alcançar algum tipo de paralelismo. Muitas CPUs, muitas memórias, muitos braços de disco se movendo em paralelo.

[1:54] Outra razão pela qual as pessoas constroem essas coisas é para poder tolerar falhas. Uau. . ter dois computadores fazendo exatamente a mesma coisa. Se um deles falhar, você pode mudar para o outro. Outra é que alguns problemas são simplesmente naturalmente espalhados no espaço. Hum, você quer fazer transferências interbancárias de dinheiro ou algo assim. O Banco A tem este computador na cidade de Nova York, e o Banco B tem este computador em Londres.

[2:25] você sabe, você simplesmente precisa ter alguma forma de eles se comunicarem e cooperarem para realizar isso. Então, há algumas razões naturais, digamos, físicas, para sistemas que são inerentemente distribuídos fisicamente, E a razão final pela qual as pessoas constroem essas coisas é para alcançar algum tipo de objetivo de segurança. Então, muitas vezes, se há algum código em que você não confia, ou você precisa interagir com alguém, eles podem ser maliciosos ou talvez o código deles tenha bugs. Então você não quer ter que confiar nele. Você pode querer dividir a computação para que, suas coisas rodem naquele computador, minhas coisas rodem neste computador, e eles só conversem entre si.

[3:03] para algum tipo de protocolo de rede restrito, estreitamente definido. Então podemos estar preocupados com segurança, E isso é alcançado dividindo as coisas em vários computadores para que possam ser isolados. Hum. A maior parte deste curso será sobre desempenho e tolerância a falhas, embora as outras duas muitas vezes se infiltrem por meio das restrições nos estudos de caso que veremos. Hum, você sabe, todos os sistemas distribuídos desses problemas são, porque têm muitas partes e as partes executam concorrentemente, porque há vários computadores.

[3:42] Você tem todos os problemas que surgem com programação concorrente, todas as interações complexas e coisas estranhas dependentes de tempo. E isso é parte do que torna os sistemas distribuídos difíceis. Outra coisa que torna... os sistemas distribuídos difíceis é que, novamente, você tem várias peças mais uma rede. você pode ter padrões de falha muito inesperados, isto é, se você tem um único computador, geralmente é o caso de o computador funcionar ou talvez travar ou sofrer uma falha de energia ou algo assim. Mas ele basicamente funciona ou não funciona.

[4:12] Sistemas distribuídos compostos por muitos computadores, você pode ter falhas parciais. Isto é, algumas peças param de funcionar, outras peças continuam funcionando. Ou talvez os computadores estejam funcionando, mas alguma parte da rede esteja quebrada ou não confiável. hum Então falhas parciais é outra razão pela qual uh... sistemas distribuídos são difíceis. Então esses são tipos de desafios básicos. Tchau. Obrigado. Obrigado.

[4:44] Tchau. Legendas pela comunidade Amara.org Obrigado. Obrigado. E uma razão final pela qual é difícil é que, você sabe, a razão original para construir um sistema distribuído é frequentemente obter maior desempenho. obter o desempenho de 1,000 computadores, ou de 1,000 braços de disco. Mas na verdade é muito complicado obter esse ganho de velocidade de mil vezes com mil computadores. Muitas vezes há muitos obstáculos jogados no seu caminho. Hum, Olá.

[5:15] Obrigado. Obrigado. Muitas vezes é preciso um pouco de design cuidadoso para... fazer o sistema realmente lhe dar o desempenho que você sente que merece. Então resolver esses problemas, é claro, pode ser tudo sobre, você sabe, abordar essas questões. Hum, A razão para fazer o curso é porque muitas vezes os problemas e as soluções são bastante interessantes tecnicamente e são problemas difíceis. Para alguns desses problemas, há soluções muito boas conhecidas; para outros problemas, elas não são tão boas, não.

[5:46] Sistemas distribuídos são usados por muitos sistemas do mundo real por aí, grandes sites frequentemente envolvidos. você sabe, vastos números de computadores que são, você sabe, montados como sistemas distribuídos. Quando comecei a ensinar este curso, Era. sistemas distribuídos eram algo de uma curiosidade acadêmica. Você sabe, as pessoas pensavam: 'Oh, você sabe, em pequena escala, eles eram usados às vezes, e as pessoas sentiam que, oh, algum dia eles seriam... poderiam ser importantes. mas agora, particularmente impulsionados pelo surgimento de sites gigantes.

[6:17] que têm, você sabe, vastas quantidades de dados e armazéns inteiros cheios de computadores, sistemas distribuídos nos últimos 20 anos tornaram-se uma parte muito séria da infraestrutura de computação. Ok. Isso significa que tem havido muita atenção voltada para eles, muitos problemas foram resolvidos, mas ainda há bastantes problemas não resolvidos. Então, se você é um estudante de pós-graduação ou está interessado em pesquisa, há muitos problemas ainda a serem resolvidos em sistemas distribuídos. Você poderia investigar essa pesquisa.

[6:49] E, finalmente, se você gosta de construir coisas, esta é uma boa disciplina porque tem uma sequência de laboratórios na qual você construirá alguns sistemas distribuídos bastante realistas focados em desempenho e tolerância a falhas. Então você terá muita prática construindo sistemas distribuídos e fazendo-os funcionar. Certo. Deixe-me falar um pouco sobre a estrutura do curso antes de começar o conteúdo técnico de verdade. Você deve conseguir encontrar o site do curso.

[7:20] usando o Google. E no site do curso estão as tarefas de laboratório, o cronograma do curso, e também um link para um Piazza onde você pode postar perguntas e obter respostas. Hum, A equipe do curso, eu sou Robert Morris, darei as aulas. Também tenho quatro monitores. Vocês querem se levantar e mostrar seus rostos? Hum, Obrigado. Os monitores são especialistas, em particular, em resolver os laboratórios. Eles terão horários de atendimento, então se você tiver perguntas sobre os laboratórios, deve ir aos horários de atendimento.

[7:54] ou você pode postar perguntas no Piazza. Hum, Obrigado. O curso tem alguns componentes importantes. Hum, Um são as aulas. Há um artigo para quase toda aula. Obrigado. Obrigado. Há dois exames. Obrigado. Obrigado. Obrigado. Tchau. Há os laboratórios, laboratórios de programação, e Hum, há um projeto final opcional que você pode fazer em vez de um dos laboratórios.

[8:27] Obrigado. Legendas pela comunidade Amara.org As aulas serão sobre grandes ideias em sistemas distribuídos. Também haverá algumas aulas mais sobre coisas de programação de laboratório. Muitas das aulas serão ocupadas por estudos de caso, grande parte da maneira como eu tento trazer o conteúdo de sistemas distribuídos é olhando para artigos, alguns acadêmicos, alguns escritos por pessoas da indústria, descrevendo soluções reais para problemas reais.

[9:04] Hum, Essas aulas na verdade seriam gravadas em vídeo. e espero postá-las online para que você, se não estiver aqui, ou quiser revisar as aulas, possa assistir às aulas em vídeo. Amém. Os artigos, novamente, há um para ler por semana. A maioria deles são artigos de pesquisa. Alguns deles são artigos clássicos. Como o artigo de hoje, que espero que alguns de vocês tenham lido, sobre MapReduce. É um artigo antigo, mas foi o começo, estimulou uma quantidade enorme de trabalho interessante, tanto acadêmico quanto no mundo real. Então alguns são clássicos e alguns são artigos mais recentes.

[9:38] falando sobre pesquisa mais atualizada, com o que as pessoas estão preocupadas atualmente. E a partir dos artigos, esperarei extrair quais são os problemas básicos, quais ideias as pessoas tiveram que podem ou não ser úteis para resolver problemas de sistemas distribuídos. Hum, Veremos às vezes detalhes de implementação em alguns desses artigos. Porque muito disso tem a ver com a construção real de sistemas baseados em software. E também vamos passar um certo tempo olhando avaliações. pessoas avaliando quão tolerantes a falhas são seus sistemas medindo-os ou pessoas medindo quanto desempenho ou se obtiveram melhoria de desempenho.

[10:14] Hum, Então espero que todos vocês leiam os artigos antes de vir para a aula. As aulas são... talvez não façam tanto sentido se você ainda não leu a aula, porque não há tempo suficiente para explicar todo o conteúdo do artigo e ter uma reflexão interessante sobre o que o artigo significa. aula online você realmente precisa ler os artigos antes de vir para a aula e espero que uma das coisas que você aprenda nesta aula é como ler um artigo de forma rápida e eficiente, e pular as partes que talvez não sejam tão importantes, focar em extrair as ideias importantes.

[10:50] No site, há para cada link do cronograma, uma pergunta. que você deve enviar uma resposta para cada artigo. Acho que as respostas devem ser entregues à meia-noite. E também pedimos que você envie uma pergunta que tenha sobre o artigo. Hum, para o site, tanto para me dar algo para pensar enquanto preparo a aula, quanto, se eu tiver tempo, tentarei responder pelo menos algumas das perguntas por e-mail. E a pergunta e a resposta para cada artigo devem ser entregues à meia-noite. da noite anterior.

[11:21] Há dois exames, há um exame de meio de semestre em sala de aula, acho que na última aula antes do, uh, recesso de primavera. Hum, e há um exame final durante a semana de exames finais no final do semestre. Os exames se concentrarão principalmente nos artigos e nos laboratórios. e provavelmente a melhor maneira de se preparar para eles, além de assistir às aulas e ler os artigos. hum, uma boa maneira de se preparar para os exames é olhar exames antigos.

[11:52] 20 anos de exames antigos e soluções. E então você olha para eles e tem uma ideia do tipo de perguntas que eu gosto de fazer. E, de fato, porque lemos muitos dos mesmos artigos, inevitavelmente, faço perguntas a cada ano que não podem deixar de se assemelhar a perguntas feitas em anos anteriores. Obrigado. Os laboratórios, há quatro laboratórios de programação. O primeiro deles deve ser entregue na sexta-feira da próxima semana. hum Eles são...

[12:23] Obrigado. O laboratório um é um... Obrigado. Um laboratório simples de MapReduce. para implementar sua própria versão do artigo. que discutirei em alguns minutos. Hum, Laboratório dois. envolve usar uma técnica chamada raft para obter tolerância a falhas, para, digamos, permitir, em teoria, que qualquer sistema se torne tolerante a falhas replicando-o e tendo esta técnica raft gerenciar a replicação e gerenciar uma espécie de comutação automática se houver uma falha, se um dos servidores replicados falhar.

[12:59] Então este é o RAF para tolerância a falhas. Hum. Obrigado. Legendas pela comunidade Amara.org *beijo* No laboratório três, você usará sua implementação do raft para construir um servidor de chave-valor tolerante a falhas. Obrigado. Amém. Obrigado. Ele será replicado e tolerante a falhas. E no laboratório quatro, você pegará seu servidor de chave-valor replicado e o clonará em vários grupos independentes. e você dividirá os dados Hum, no seu sistema de armazenamento de chave-valor entre todos esses grupos replicados individuais para obter aceleração paralela.

[13:37] executando vários grupos replicados em paralelo e você também será responsável por mover os vários pedaços de dados entre diferentes servidores à medida que eles entram e saem. sem deixar cair nenhuma bola. o que é frequentemente chamado de serviço de chave-valor fragmentado. Tchau. Tchau. você O sharding refere-se a dividir os dados, particionar os dados. entre vários servidores para obter aceleração paralela.

[14:10] hum Obrigado. Se quiser, em vez de fazer o laboratório quatro, Você pode fazer um projeto de sua escolha. E a ideia aqui é se você tem alguma ideia para um sistema distribuído, você sabe, no estilo de... alguns dos sistemas distribuídos que discutimos na aula, se você tem sua própria ideia que deseja seguir, e gostaria de construir algo e medir se funcionou Explore sua ideia. você pode fazer um projeto. Hum, E então para um projeto, você escolherá alguns colegas de equipe porque exigimos que os projetos sejam feitos em equipes de duas ou três pessoas.

[14:45] Nam. Então, como alguns colegas de equipe e envie sua ideia de projeto para nós e pensaremos sobre isso e diremos sim ou não e talvez lhe daremos alguns conselhos. hum, E então se você prosseguir e fizer, se dissermos sim, e você quiser fazer um projeto, você faz isso em vez do Laboratório 4, e é feito. no final do semestre. Você sabe, você... você deve fazer algum trabalho de design e construir um sistema real, e então no último dia de aula, você demonstrará seu sistema. bem como entregar um breve... tipo de relatório escrito para nós sobre o que você construiu. E eu postei no site algumas ideias que podem ou não ser úteis para você, para estimular pensamentos sobre quais projetos você pode construir, mas realmente os melhores projetos são aqueles em que você tem uma boa ideia para o projeto. E a ideia é que se você quiser fazer um projeto, você deve escolher uma ideia que esteja mais ou menos na mesma linha dos sistemas que estamos discutindo nesta aula.

[15:40] Ok, de volta aos laboratórios. As notas dos laboratórios que damos a você, você entrega o código do laboratório, e executamos alguns testes contra ele, Você é avaliado com base em quantos testes você passa. Damos a você todos os testes que usamos, então não há testes ocultos. Então, Se você influenciar o laboratório e ele passar de forma confiável em todos os testes, então as chances são boas, a menos que haja algo engraçado acontecendo, o que às vezes acontece. As chances são boas de que se seu código passar em todos os testes quando você o executar, ele passará em todos os testes quando nós o executarmos. e você obterá uma pontuação total. Então, esperançosamente, não haverá mistério sobre qual pontuação você provavelmente obterá.

[16:13] nos laboratórios. Hum, Deixe-me avisar que depurar esses laboratórios pode consumir tempo. Porque eles são sistemas distribuídos, e têm muita concorrência e comunicação, Hum, erros meio estranhos e difíceis de depurar podem surgir. Você realmente deve começar os laboratórios cedo. Não os deixe. Muitos problemas se você deixar os laboratórios para o último momento. Você tem que começar cedo. Se você tiver-- problemas, por favor venha ao horário de atendimento dos monitores.

[16:44] e por favor sinta-se à vontade para fazer perguntas. sobre os laboratórios no Piazza. E, de fato, espero que se você souber a resposta, você também responda às perguntas das pessoas no Piazza. Tudo bem. Alguma pergunta sobre a mecânica do curso? Sim? Tchau. Sim. Obrigado. Então a pergunta é: como essas coisas entram na nota? Eu esqueci, mas está tudo no...

[17:18] Está no site sob-- alguma coisa. Hum. Acho que os laboratórios são o componente mais importante. Obrigado. Ok. Obrigado. Hum... Tudo bem, então este é um curso sobre infraestrutura. para aplicações. E ao longo deste curso, haverá uma espécie de divisão na forma como falo sobre as coisas entre aplicações, que são meio que outras pessoas, o cliente, alguém escreve.

[17:49] As aplicações usarão a infraestrutura que estamos considerando neste curso. E então os tipos de infraestrutura que tendem a surgir muito. Obrigado. Obrigado. são armazenamento Obrigado. comunicação Obrigado. e computação. E falaremos sobre sistemas que fornecem todos esses três tipos de infraestrutura.

[18:19] Hum, o armazenamento Acontece que o armazenamento será aquele em que mais nos concentraremos porque é uma abstração muito bem definida e útil. E obrigado. abstrações geralmente bastante diretas. Então as pessoas sabem muito sobre como usar e construir sistemas de armazenamento e como construir implementações distribuídas replicadas, tolerantes a falhas e de alto desempenho de armazenamento. Também falaremos sobre alguns de nossos sistemas de computação, como o MapReduce hoje.

[18:50] é um sistema de computação. Hum, E falaremos um pouco sobre comunicação, mas principalmente do ponto de vista de uma ferramenta que precisamos usar para construir sistemas distribuídos. Como computadores têm que conversar entre si, por uma rede, você sabe, talvez você precise de confiabilidade ou algo assim. E então falaremos um pouco, mas na verdade somos principalmente... consumidores de comunicação. Hum, Se você quiser aprender sobre sistemas de comunicação ou como eles funcionam, esse é mais o tópico de 6829. Então, para armazenamento e computação, Muito do nosso objetivo é ser capaz de descobrir abstrações, Hum, maneiras de simplificar a interface para esses, infraestrutura distribuída de armazenamento e computação, para que seja fácil construir aplicações em cima dela.

[19:41] E o que isso realmente significa é que precisamos, gostaríamos de ser capazes de construir abstrações que escondam a natureza distribuída desses. desses sistemas. Então o sonho, que raramente é totalmente alcançado, mas o sonho seria ser capaz de construir uma interface, Que pareça para uma aplicação como se fosse um sistema de armazenamento não distribuído, como um sistema de arquivos ou algo que todo mundo já sabe programar e tem um modelo de semântica bastante simples. Adoraríamos ser capazes de construir interfaces que pareçam e ajam exatamente como sistemas de armazenamento e computação não distribuídos, mas que sejam na verdade-- você sabe, vastos, extremamente de alto desempenho, tolerantes a falhas, sistemas distribuídos por baixo.

[20:23] Hum. Então adoraríamos ter abstrações. Obrigado. Legendas pela comunidade Amara.org Obrigado. E como você verá ao longo do curso, estamos meio que, você sabe, apenas parte do caminho até lá. É raro encontrar uma abstração para uma versão distribuída de armazenamento ou computação que tenha comportamento simples, que se comporte exatamente como Hum, a versão não distribuída de armazenamento que todos entendem. As pessoas estão ficando melhores nisso e...

[20:54] hum Vamos tentar estudar as maneiras pelas quais as pessoas aprenderam sobre. construir tais abstrações. Ok. Que tipo de, que tipo de, Tópicos aparecem quando consideramos essas abstrações. O primeiro, o primeiro tópico, tópico geral que veremos muito é que em muitos dos sistemas que analisamos, têm a ver com implementação. Obrigado. hum Então, por exemplo, o tipo de ferramentas que você vê muito para as maneiras pelas quais as pessoas aprendem a construir esses sistemas são coisas como chamada de procedimento remoto, cujo objetivo é mascarar o fato de que estamos nos comunicando por uma rede não confiável.

[21:38] hum Outro tipo de tópico de implementação que veremos muito é threads. que são uma técnica de programação, que nos permite aproveitar computadores multi-core, mas talvez mais importante para esta aula, Threads são uma maneira de estruturar operações concorrentes. de uma forma que, esperançosamente, simplifica a visão do programador sobre essas operações concorrentes. Hum, E porque vamos usar threads muito, acontece que também precisaremos, apenas do ponto de vista de implementação, gastar um certo tempo pensando em controle de concorrência, coisas como locks.

[22:18] Hum. você Obrigado. E o principal lugar onde essas ideias de implementação surgirão na aula, serão abordadas em muitos dos artigos, mas você vai encarar tudo isso de frente de forma significativa nos laboratórios. Você precisa construir distribuidores. você sabe, fazer a programação para sistemas distribuídos. Estas são como muitas das ferramentas importantes além da programação comum, Hum, Estas são algumas das ferramentas críticas que você precisará usar. Estou de volta. para construir sistemas distribuídos.

[22:50] Outro grande tópico que surge em todos os artigos sobre os quais vamos falar é desempenho. Obrigado. Tchau. Obrigado. Obrigado. Hum, Normalmente o objetivo de alto nível de construir um sistema distribuído é obter o que as pessoas chamam de aceleração escalável. Então vamos buscar escalabilidade. E o que quero dizer com escalabilidade ou aceleração escalável é que Se eu tenho algum problema que estou resolvendo com um computador, e compro um segundo computador para me ajudar a executar meu problema.

[23:30] Se agora posso resolver o problema na metade do tempo, ou talvez resolver o dobro de instâncias do problema. você sabe, por minuto. em dois computadores como eu tinha em um, então Isso é um exemplo de escalabilidade. Mais ou menos. duas vezes os computadores ou recursos, hum, me dá duas vezes o desempenho ou throughput. E este é um martelo enorme. Se você puder construir um sistema que realmente tenha esse comportamento, Ou seja, que Se você aumentar o número de computadores que você joga no problema por algum fator, Você obtém esse fator, mais throughput, mais desempenho.

[24:14] fora do sistema. Isso é um enorme ganho. Porque Você pode comprar computadores apenas com dinheiro. Certo? Enquanto que se, para obter a alternativa a isso, Hum, é que para obter mais desempenho, você tem que pagar programadores para reestruturar seu software para obter melhor desempenho, para torná-lo mais eficiente, para aplicar algum tipo de técnicas especializadas, melhores algoritmos ou algo assim. Se você tem que pagar programadores, para consertar seu código para ser mais rápido.

[24:44] uma maneira cara de seguir. Adoraríamos poder simplesmente, ah, comprar mil computadores em vez de 10 computadores e obter Você sabe, 100 vezes mais throughput. Isso é fantástico. E então esse tipo de ideia de escalabilidade é uma ideia enorme no fundo da cabeça das pessoas quando elas estão construindo coisas como grandes sites que rodam em um você sabe, prédio cheio de computadores. Se o prédio cheio de computadores está lá para obter uma quantidade correspondente de desempenho de dados. você tem que ter cuidado com o design para realmente obter esse desempenho. Hum, Então, muitas vezes a forma como isso aparece quando estamos olhando diagramas ou escrevendo diagramas neste curso é que Isso é supondo que estamos construindo um site.

[25:26] Normalmente, você pode ter um site que você sabe, tem um servidor HTTP, ou digamos que tem alguns tem alguns usuários. hum, executando navegadores web, E eles conversam com... você sabe, servidor web rodando Python ou PHP ou qualquer coisa, Tipo de servidor web. E o servidor web conversa com algum tipo de banco de dados. Hum, Você sabe, quando você tem um ou dois usuários, tem um computador rodando ambos, ou talvez um computador para o servidor web e um computador para o banco de dados, Talvez de repente você fique realmente popular e você Você sabe, 100 milhões de pessoas se inscrevem no seu serviço.

[26:10] Certo? Como você... Não. Como você conserta seu-- você certamente não pode-- suportar milhões de pessoas em um único computador, Hum, exceto por otimização extremamente cuidadosa e intensiva em mão de obra. Hum, mas você não tem tempo para isso. Então, Tipicamente a maneira como você vai acelerar as coisas, a primeira coisa que você faz é comprar mais servidores web e simplesmente dividir os usuários para que você saiba, metade dos seus usuários ou alguma fração dos usuários vá para o servidor web um e a outra metade Você os envia para o servidor web dois.

[26:40] e porque talvez você esteja construindo não sei o quê, Reddit ou algo assim, onde todos os usuários precisam ver os mesmos dados no final, você tem todos os servidores web conversando com o back end. E talvez você possa continuar adicionando servidores web por muito tempo aqui. Obrigado. Hum, obrigado. E então esta é uma forma de obter aceleração paralela no código do servidor web. Sabe, se você estiver rodando PHP ou Python, talvez não seja muito eficiente. Hum, desde que cada servidor web individual não coloque muita carga no banco de dados, você pode adicionar muitos servidores web.

[27:13] antes de você ter problemas. Mas esse tipo de escalabilidade raramente é infinita, infelizmente. Hum, certamente não sem uma reflexão séria. E então o que tende a acontecer com esses sistemas é que em algum momento depois que você tem 10 ou 20 ou 100 servidores web todos conversando com o mesmo banco de dados, de repente o banco de dados começa a ser um gargalo. e adicionar mais servidores web não ajuda mais. Então é raro que você obtenha escalabilidade total através de números infinitos de adicionar números infinitos de computadores.

[27:45] Em algum momento você fica sem combustível porque o lugar onde você está adicionando mais computadores não é mais o gargalo. tendo muitos e muitos servidores web, basicamente movemos o gargalo Hum, acho que está limitando o desempenho dos servidores web para o banco de dados. Hum, e neste ponto, na verdade, você quase certamente tem que fazer um pouco de trabalho de design. porque é raro que você possa pegar, que haja alguma maneira direta de pegar um único banco de dados e meio que refatorar as coisas. com ele para. você pode pegar dados organizados em um único banco de dados e refatorá-los para que sejam divididos em vários bancos de dados.

[28:21] Hum, mas muitas vezes é bastante trabalho. e porque é complicado, mas muitas pessoas na verdade precisam fazer isso. Hum, vamos ver muitos exemplos neste curso em que o sistema distribuído do qual as pessoas falam é um sistema de armazenamento. porque os autores estavam executando sabe, algo como um grande site que ficou sem combustível em um único banco de dados ou servidores de armazenamento. Hum, de qualquer forma, então a história da escalabilidade é que adoramos construir sistemas que escalam dessa forma, mas hum você sabe que é difícil fazer isso, ou requer trabalho muitas vezes, trabalho de design, levar essa ideia infinitamente longe.

[29:04] Amém. Obrigado. Obrigado. Certo, então. Outro grande tópico que surge muito é tolerância a falhas. Obrigado. . Se você está construindo um sistema com um único computador nele, bem, um único computador muitas vezes pode ficar no ar por anos. Tipo, eu tenho servidores no meu escritório que estão no ar há anos sem travar. Hum, sabe, o computador é bem confiável, o sistema operacional é bem confiável, aparentemente a energia no meu prédio é bem confiável. Então não é incomum ter computadores únicos que simplesmente ficam no ar por quantidades surpreendentes de tempo.

[29:44] No entanto, se você está construindo sistemas com milhares de computadores, então mesmo que cada computador possa se esperar que fique no ar por um ano, com mil computadores isso significa que você vai ter cerca de três falhas de computador por dia. E no seu conjunto de computadores. resolver grandes problemas com grandes sistemas distribuídos transforma tolerância a falhas muito rara, problemas de falha muito raros, em problemas de falha que acontecem o tempo todo. Em um sistema com mil computadores, quase certamente sempre há algo quebrado. Sempre há algum computador que travou ou está misteriosamente funcionando incorretamente ou lentamente ou fazendo a coisa errada.

[30:25] Ou talvez haja alguma parte da rede, tipo com mil computadores, temos muitos cabos de rede. e muitos switches de rede. Sabe, sempre há algum cabo de rede que alguém pisou e está com falha, ou cabo de rede que caiu, ou algum switch de rede cujo ventilador quebrou e o switch superaqueceu e falhou. Sempre há algum probleminha em algum lugar no seu sistema distribuído do tamanho de um prédio. Então a grande escala transforma problemas de eventos muito raros, com os quais você realmente não precisa se preocupar muito, em problemas constantes.

[30:57] A... falha tem que ser realmente, ou a resposta, a ocultação de falhas, a capacidade de perceber falhas só precisa estar embutida no design. porque sempre há falhas. Hum... E, sabe, como parte de construir, sabe, abstrações convenientes para programadores de aplicativos, nós realmente precisamos ser capazes de construir infraestrutura que, tanto quanto possível, esconda as falhas dos programadores de aplicativos ou as mascare ou algo assim. para que todo programador de aplicativo não precise ter uma história completa e complicada para todos os diferentes tipos de falhas que podem ocorrer.

[31:32] Hum, há várias noções diferentes que você pode ter sobre o que significa ser tolerante a falhas. sobre um pouco mais. mas exatamente o que queremos dizer com isso. E veremos muitos sabores diferentes, mas entre as ideias mais comuns que você vê, uma é disponibilidade. Obrigado. Amém. Então, sabe, alguns sistemas são projetados para que, sob certos tipos de falhas, não todas as falhas, mas certos tipos de falhas, o sistema continue operando apesar da falha enquanto fornece serviço intacto.

[32:15] Uh, o mesmo tipo de serviço que teria fornecido, mesmo se não tivesse havido falha. Então alguns sistemas estão disponíveis nesse sentido, então se você constrói um serviço replicado que talvez tenha duas cópias, sabe, se um dos servidores réplica falhar, talvez o outro servidor possa continuar operando. Ambos falham, é claro, você não pode. Sabe, você não pode prometer. Hum. disponibilidade nesse caso. Então sistemas disponíveis geralmente dizem, bem, sob um certo conjunto de falhas, vamos continuar fornecendo serviço. Vamos estar disponíveis.

[32:48] Mais falhas do que isso ocorrem. Não estará mais disponível. Obrigado. Outro tipo de tolerância a falhas que você pode... que você pode ter ou além da disponibilidade ou por si só é a recuperabilidade. Obrigado. Obrigado. Obrigado. E o que isso significa é que se algo der errado, talvez o serviço pare de funcionar. Ou seja, ele simplesmente para de responder a solicitações, Hum, e vai esperar que alguém venha e conserte o que quer que tenha dado errado, mas depois que o conserto ocorrer, o sistema será capaz de continuar como se nada de ruim tivesse acontecido.

[33:23] Então este é um requisito mais fraco que a disponibilidade, porque aqui não vamos fazer nada até que o componente com falha tenha sido consertado, Mas o fato de que podemos voltar a funcionar sem, sabe, mas... sem qualquer perda de correção, ainda é um requisito significativo. Isso significa, sabe, sistemas recuperáveis tipicamente precisam fazer coisas como salvar seus dados mais recentes em disco ou algo onde possam recuperá-los, sabe, depois que a energia voltar. Hum, e mesmo entre sistemas disponíveis, para que um sistema seja útil na vida real, geralmente a maneira como os sistemas disponíveis são especificados é que eles estão disponíveis até que algum número de falhas tenha acontecido. Se muitas falhas aconteceram, um sistema disponível parará de funcionar ou parará de responder completamente, Mas quando coisas suficientes tiverem sido consertadas, ele continuará operando. Então um bom sistema disponível será meio que recuperável também no sentido de que se muitas falhas ocorrerem,

[34:26] hum Ele parará de responder, mas depois continuará corretamente depois disso. Hum, então é isso que adoramos ouvir. É isso que gostaríamos de obter. O maior martelo, veremos várias abordagens para resolver esses problemas. Eu disse, meio que duas coisas que são as ferramentas mais importantes que temos neste departamento. Uma é armazenamento não volátil. para que, sabe, algo travou, a energia falhou, ou qualquer coisa, talvez haja uma falha de energia no prédio inteiro. Podemos usar armazenamento não volátil como discos rígidos ou flash ou unidades de estado sólido ou algo para meio que armazenar um checkpoint ou um log do estado do sistema e então quando a energia voltar ou alguém consertar nossa fonte de alimentação, quem sabe o quê, poderemos ler nosso estado mais recente do disco rígido e continuar a partir daí.

[35:22] Então. Então uma ferramenta é meio que armazenamento não volátil. E o gerenciamento de armazenamento não volátil é algo que surge muito, porque armazenamento não volátil tende a ser caro de atualizar. E então uma enorme quantidade do tipo de detalhes minuciosos de construir sistemas tolerantes a falhas de alto desempenho está em maneiras inteligentes de evitar ter que escrever no armazenamento não volátil demais. Nos velhos tempos e até hoje, sabe, o que escrever em armazenamento não volátil significava era mover um braço de disco e esperar que um prato de disco girasse.

[35:58] ambos os quais são agonizantemente lentos. na escala de, sabe, microprocessadores de 3 gigahertz. Com coisas como flash. A vida é bem melhor, mas ainda requer muita reflexão para obter bom desempenho disso. E a outra grande ferramenta que temos para tolerância a falhas é a replicação. Obrigado. e o gerenciamento de cópias replicadas é meio complicado. Sabe, esse tipo de problema à espreita em qualquer sistema replicado onde temos dois servidores cada um com uma cópia supostamente idêntica do estado do sistema.

[36:32] Hum, o problema chave que surge é sempre que as duas réplicas acidentalmente se desviam e param de ser réplicas. E isso é apenas-- sabe, no fundo de todo design que vamos ver para usar replicação para obter tolerância a falhas. E o Lab 2, e é sobre isso que vocês todos estão. gerenciamento de cópias replicadas para tolerância a falhas. Hum. Como vocês verão, é bem complexo. Hum, um tópico final, tópico transversal final, hum, é consistência.

[37:11] Obrigado. Obrigado. Então, como exemplo do que quero dizer com consistência, suponhamos que estamos construindo um sistema de armazenamento distribuído e é um serviço de chave-valor, então ele apenas suporta. duas operações, talvez haja uma operação put, e você dá a ela uma chave, e um valor, e o sistema de armazenamento meio que guarda o valor como o valor para esta chave, então ele mantém apenas uma grande tabela de chaves e valores. E então há uma operação get. o cliente envia a ela uma chave e o serviço de armazenamento deve responder com o valor que está armazenado para aquela chave.

[37:51] E isso é meio que o Quando não consigo pensar em nada else como exemplo de um sistema distribuído, eu saco hum, serviços de chave-valor. E eles são muito úteis, certo? Eles são apenas meio que a versão fundamental Hum, simples de um sistema de armazenamento. Então. Claro que se você é um programador de aplicativos. É útil se... Essas duas operações meio que têm significados anexados a elas. Você pode ir olhar no manual e o manual diz, sabe, o que significa, o que você receberá de volta se chamar get.

[38:23] certo, e meio que o que significa para você chamar put. Então seria ótimo se houvesse algum tipo de especificação para o que elas significavam, caso contrário, tipo, Como você pode possivelmente escrever um aplicativo sem uma descrição do que Pudding getters devem fazer. Hum, e este é o tópico da consistência. E a razão pela qual é interessante em sistemas distribuídos é que Hum. tanto por razões de desempenho quanto de tolerância a falhas, razão de tolerância a falhas, muitas vezes temos mais de uma cópia dos dados flutuando por aí. Então, sabe, em um sistema não distribuído onde você tem apenas um único servidor com uma única tabela, muitas vezes há, embora nem sempre.

[39:02] Muitas vezes não há relativamente ambiguidade sobre o que put e get podem significar intuitivamente. Você sabe, o que put significa é atualizar a tabela, e o que get significa é apenas, me dê a versão que está armazenada na tabela. Hum, mas em um sistema distribuído, onde há mais de uma cópia dos dados, devido a replicação ou cache ou quem sabe o quê? Pode haver muitas versões diferentes desse par chave-valor circulando. Como se uma das réplicas, você sabe, suponha que algum cliente emita um put, e você sabe, há-- duas cópias do servidor, então ambos têm uma tabela de chave-valor.

[39:46] Certo, e talvez a chave um tenha valor 20 em ambos. Obrigado. e então algum cliente emite um put. Temos um cliente aqui. e ele vai enviar um put, quer atualizar o valor de um para ser 21. Talvez esteja contando coisas neste servidor de chave-valor, então envia um put Obrigado. com chave um e valor 21, envia para o primeiro servidor e está prestes a enviar O mesmo, você sabe, quer atualizar ambas as cópias, certo?

[40:19] Mantém eles em sincronia. Está prestes a enviar este put, mas pouco antes de enviar o put para o segundo servidor, ele falha. falha de energia, bug no sistema operacional ou algo assim. Então agora o estado em que ficamos, infelizmente, é que enviamos este put e então atualizamos uma das duas réplicas para ter valor 21, mas a outra ainda está com 20. Agora alguém aparece e lê com um "get" E eles podem obter... Eles querem... Ler o valor associado à chave um, eles podem obter 21 ou podem obter 20, dependendo de com quem falam. E mesmo se a regra for você sempre fala com o servidor de cima primeiro, Se você está construindo um sistema de tolerância a falhas, a regra real tem que ser Ah, você fala com o servidor de cima primeiro, a menos que ele tenha falhado, caso em que você fala com o servidor de baixo.

[41:00] Hum, Então de qualquer forma, algum dia você corre o risco de expor esta cópia obsoleta dos dados. para algum get futuro. Pode ser que muitos gets obtenham o 21 atualizado e então Como na próxima semana, de repente, algum get produza, você sabe, uma cópia de uma semana atrás dos dados. Então isso não é muito consistente. Certo? em ordem, mas você sabe, é o tipo de coisa que poderia acontecer. Certo? e não somos cuidadosos. Precisamos realmente escrever quais serão as regras sobre puts e gets dado este perigo devido à replicação.

[41:37] E acontece que há muitas definições diferentes de consistência que você pode ter. Hum, Muitas delas são relativamente diretas. Muitas delas soam como, bem, eu get produz o você sabe, valor put pelo put concluído mais recentemente. Certo. E então isso geralmente é chamado de consistência forte. Acontece também que é muito útil construir sistemas que tenham consistência muito mais fraca. Que, por exemplo, não garantem nada como eu get.

[42:11] vê o valor escrito pelo put mais recente. E a razão, então há sistemas fortemente consistentes - - Eles geralmente têm alguma versão de get vendo os puts mais recentes. Acho que você tem que... Há muitos detalhes a resolver. Há também consistência fraca, muitos tipos de sistemas fracamente consistentes que não fazem tal garantia. sobre isso. e pode garantir a você bem, você sabe, se alguém faz um put, então você pode não ver o put. Você pode ver valores antigos que não foram atualizados pelo put por um período de tempo ilimitado, talvez.

[42:47] Hum, E a razão para-- as pessoas estarem muito interessadas em esquemas de consistência fraca. é que Consistência forte, isto é, ter RIS realmente veja, tenha garantia de ver o mais recente certo. Essa é uma especificação muito cara de implementar. hum porque o que significa é quase certamente que você tem que, alguém tem que fazer muita comunicação para, realmente implementar. alguma noção de consistência forte. Se você tem múltiplas cópias, Hum, Isso significa que ou o escritor ou o leitor, ou talvez ambos, tem que consultar cada cópia. Como neste caso, hum onde talvez um cliente falhou, deixou uma atualizada, mas não a outra.

[43:29] Se quiséssemos implementar consistência forte de uma maneira simples neste sistema, faríamos os leitores lerem ambas as cópias ou, se houver mais de uma cópia, todas as cópias. e usar o valor escrito mais recentemente que encontrarem. Hum. mas isso é caro. Isso é muita conversa. para ler um valor. Então, para evitar comunicação o máximo possível, Hum. particularmente se as réplicas estiverem longe, as pessoas constroem sistemas fracos que podem na verdade permitir a leitura obsoleta de um valor antigo neste caso.

[44:01] Hum, embora muitas vezes haja mais semântica anexada a isso para tentar tornar esses esquemas fracos. E onde este problema de comunicação, você sabe, consistência forte. exigindo comunicação cara. Onde isso realmente te coloca em apuros é que, Se estamos usando replicação para tolerância a falhas, então Nós realmente queremos que as réplicas tenham probabilidade de falha independente, tenham falha não correlacionada. Então, por exemplo, colocar ambas as réplicas dos nossos dados no mesmo rack, na mesma sala de máquinas, é provavelmente uma péssima ideia.

[44:38] porque se alguém tropeçar no cabo de energia daquele rack, ambas as nossas cópias dos nossos dados vão morrer. Porque ambas estão conectadas ao mesmo cabo de energia no mesmo rack. Hum, Então na busca por tornar as réplicas o mais independentes possível em falhas para obter uma tolerância a falhas decente, As pessoas adorariam colocar réplicas diferentes o mais longe possível, como em cidades diferentes. ou talvez em lados opostos do continente. Então um terremoto que destrói um data center será extremamente improvável que também destrua O outro data center que tem a outra cópia.

[45:13] Hum, Você sabe, então adoraríamos poder fazer isso. Se você fizer isso, então a outra cópia está a milhares de quilômetros de distância, E a velocidade com que a luz viaja significa que pode levar na ordem de milissegundos ou dezenas de milissegundos para comunicar a um data center do outro lado do continente para atualizar a outra cópia dos dados. E então isso torna esta A comunicação necessária para consistência forte, para boa consistência, potencialmente extremamente cara. Como toda vez que você quer fazer uma dessas operações put, ou talvez um get, dependendo de como você implementa, Você pode ter que ficar lá esperando por tipo 10 ou 20 ou 30 milissegundos para falar com ambas as cópias dos dados para garantir que ambas estão atualizadas ou ambas verificadas.

[45:57] para encontrar a cópia mais recente. Hum, E Essa despesa tremenda, certo? Isso é 10 ou 20 ou 30 milissegundos em máquinas que, afinal, executarão tipo um bilhão de instruções por segundo. Então estamos desperdiçando muitas instruções potenciais enquanto esperamos. As pessoas frequentemente constroem sistemas muito mais fracos. Você tem permissão para atualizar apenas a cópia mais próxima ou consultar apenas a cópia mais próxima. Agora, quero dizer, há uma enorme quantidade de pesquisa acadêmica e do mundo real. sobre como estruturar garantias de consistência fraca para que sejam realmente úteis para aplicações e como tirar vantagem delas para realmente obter alto desempenho.

[46:35] Obrigado. Certo, então essa é uma prévia relâmpago das... ideias técnicas do curso. Alguma pergunta sobre isso? antes de eu começar a falar sobre MapReduce. Certo, quero mudar para MapReduce. Esse é um tipo de estudo de caso detalhado que na verdade vai ilustrar a maioria das ideias. que estivemos falando aqui. E que produz um sistema que foi Uh...

[47:06] originalmente projetado e construído e usado pelo Google, acho que o artigo data de 2004. O problema que eles enfrentavam era que estavam executando computações enormes em terabytes e terabytes de dados. criando um índice de todo o conteúdo da web ou analisando a estrutura de links de toda a web para identificar as páginas mais importantes ou as páginas mais autoritativas.

[47:36] E então, você sabe, toda a web era-- mesmo naqueles dias dezenas de terabytes de dados. Hum... Construir um índice da web é basicamente equivalente a uma espécie de ordenação de toda a dados. Ordenar, você sabe, é tipo... razoavelmente caro. e executar uma ordenação em todo o conteúdo da web em um único computador eu não sei quanto tempo teria levado, mas você sabe, semanas ou meses ou anos ou algo assim. Então, o Google na época estava desesperado para poder executar computações gigantes em dados gigantes em milhares de computadores.

[48:09] para que as computações pudessem terminar rapidamente. Valia a pena para eles comprar muitos computadores para que seus engenheiros não tivessem que passar muito tempo lendo o jornal ou algo assim esperando seus grandes trabalhos de computação terminarem. Hum... E então por um tempo, eles tinham seus engenheiros espertos meio que escrevendo à mão, você sabe, se você precisasse escrever um indexador web ou algum tipo de ferramenta de análise de links, links web. você sabe, o Google comprava os computadores e dizia: "Aqui, engenheiros, você sabe, executem o software que quiserem nestes computadores."

[48:40] eles laboriosamente escreviam o tipo de software único escrito manualmente para pegar qualquer problema que estivessem trabalhando e de alguma forma distribuí-lo para muitos computadores e organizar essa computação e obter os dados de volta. Hum, Se você só contrata engenheiros que são especialistas experientes em sistemas distribuídos, Talvez isso seja ok, embora mesmo assim, provavelmente seja muito desperdício de esforço de engenharia. Mas eles queriam contratar pessoas que fossem habilidosas em outra coisa. Hum, E não necessariamente...

[49:13] Hum... engenheiros que queriam passar todo o tempo escrevendo software de sistema distribuído. Então eles realmente precisavam de algum tipo de framework que tornasse fácil apenas, ter seus engenheiros Certo? o tipo de núcleo de qualquer análise que quisessem fazer, como algoritmo de ordenação ou índice web ou analisador de links ou qualquer coisa. Apenas escrever o núcleo dessa aplicação e não executar, poder executá-la em milhares de computadores. hum sem se preocupar com os detalhes de como espalhar o trabalho pelos milhares de computadores, como organizar qualquer movimento de dados necessário, como lidar com as falhas inevitáveis.

[49:49] Então eles estavam procurando um framework que tornasse fácil para não especialistas poderem escrever e executar computações distribuídas gigantes. Hum, E então é disso que se trata o MapReduce. Amém. E a ideia é que o programador apenas escreva o projetista da aplicação, consumidor desta computação distribuída e apenas consiga escrever uma função map simples e uma função reduce simples, Certo. não sabe nada sobre distribuição. e o framework MapReduce cuidaria de todo o resto.

[50:23] Hum, Então uma visão abstrata do que o MapReduce faz é Começa assumindo que há alguma entrada e a entrada é dividida em um monte de arquivos ou pedaços diferentes de alguma forma. Estamos imaginando que Você sabe, Temos arquivo de entrada um, arquivo de entrada dois, arquivo de entrada três, Etc. Você sabe, e essas entradas são talvez Ajuda.

[50:53] páginas web rastreadas da web ou mais provavelmente tipos de grandes arquivos que contêm muitos arquivos web--cada um dos quais contém muitos arquivos web. rastreados da web. Certo, e a maneira como o MapReduce começa é que você define uma função map e o framework MapReduce vai executar sua função map em cada um dos arquivos de entrada. você Obrigado. E claro você pode ver aqui que há algum paralelismo óbvio disponível.

[51:25] pode executar os maps em paralelo. Então cada uma dessas funções map olha apenas para sua entrada e produz saída. A saída que uma função map deve produzir é uma lista. Recebe um arquivo como entrada e um arquivo como alguma fração dos dados de entrada, e produz uma lista de pares chave-valor como saída. a função map. E então, por exemplo, vamos supor que estamos escrevendo o exemplo MapReduce mais simples possível, um trabalho MapReduce de contagem de palavras, cujo objetivo é contar o número de ocorrências de cada palavra.

[51:59] Então sua função map pode emitir pares chave-valor, onde a chave é a palavra e o valor é apenas um. Então, para cada palavra que vê, essa função map vai dividir a entrada em palavras. Para cada palavra que vê, ela emite essa palavra como chave e um como valor. E depois vamos contar todos esses uns para obter a saída final. A entrada um tem a palavra A nela e a palavra B nela. E então a saída que o map vai produzir é chave A valor 1, chave B valor 1.

[52:32] Talvez a segunda indicação de map veja um arquivo que tem um a b nele e nada mais, então vai emitir B1. Talvez esta terceira entrada tenha um A nela e um C nela. Certo, então executamos todos esses maps em todos os arquivos de entrada. E obtemos esta saída intermediária, o que o artigo chama de saída intermediária, que é para cada map, um conjunto de pares chave-valor como saída. Então a segunda etapa da computação é executar os reduces.

[53:04] Obrigado. Hum, e a ideia é que o framework MapReduce coleta todas as instâncias de todos os maps de cada palavra-chave. Então o framework MapReduce vai coletar todos os A's, você sabe, de cada map, cada par chave-valor cuja chave era A, ele vai pegar, coletar todos eles e entregá-los a *batendo* uma chamada da função reduce definida pelo programador. E então vai pegar todos os B's e coletá-los juntos. Claro, isso requer coleta real porque diferentes instâncias da chave B foram produzidas por diferentes indicações de map em computadores diferentes. Então não estamos falando de movimento de dados.

[53:50] Então vamos coletar todas as chaves B e entregá-las a uma chamada diferente de reduce que tem todas as chaves B como seus argumentos, e o mesmo com C, todos os C's. Então isso vai ser o framework MapReduce vai organizar uma chamada para reduce para cada chave que ocorreu em qualquer uma das saídas do map. Hum, e para nosso exemplo meio bobo de contagem de palavras, todos esses reduces têm que fazer, ou qualquer um deles tem que fazer, é apenas contar o número de itens passados a ele. Nem precisa olhar os itens porque sabe que cada um deles é—a palavra é responsável por mais um como valor. Você não precisa olhar esses uns, apenas os contamos. Então este reduce vai produzir Hum, A e então a contagem.

[54:43] De suas entradas, este reduce. Vai produzir a chave associada a ele e então a contagem de seus valores, que também é dois. Obrigado. Obrigado. Obrigado. Então é assim que um típico... trabalho MapReduce se parece. O nível alto. Apenas por completude, o—desculpe. Bem, um pouco de terminologia. A computação inteira é chamada de job. Qualquer invocação de map ou reduce é chamada de task. Então temos um job inteiro e ele é composto por um monte de tarefas map.

[55:21] e então um monte de tarefas reduce. Hum... Então um exemplo para esta contagem de palavras, você sabe, como seriam as funções map e reduce. Obrigado. Obrigado. Hum... Obrigado. Obrigado. A função map recebe uma chave e um valor como argumentos. E agora estamos falando de funções escritas em uma linguagem de programação comum como C++ ou Java ou sei lá o quê.

[55:52] hum Então isso é apenas código que pessoas comuns podem escrever. O que uma função map para contagem de palavras faria é dividir a chave é o nome do arquivo, que tipicamente é ignorado, não nos importamos realmente qual era o nome do arquivo. E o V é o conteúdo do "arquivo de entrada deste map". Então V apenas contém todo este texto. Vamos dividir V em palavras. Obrigado. Obrigado. E então para cada palavra, Obrigado.

[56:24] *batendo* *batendo* *batendo* Vamos apenas emitir. E emit recebe dois argumentos. Chamadas de emit só o map pode fazer, e emit é fornecido pelo framework MapReduce. Podemos produzir, entregamos ao emit uma chave, que é a palavra... e um valor que é a string um. Então é isso para a função map. Uma função map de contagem de palavras no MapReduce poderia literalmente ser tão simples quanto isso.

[56:56] Hum, então. a espécie de promessa deles de fazer o E, você sabe, esta função map não sabe nada sobre distribuição ou múltiplos computadores, o fato de precisarmos mover dados pela rede, ou sei lá o quê. Isso é extremamente... direto. E a função reduce para... contagem de palavras, hum. O reduce é chamado com Lembre-se de que cada reduce é chamado com uma espécie de todas as instâncias de uma dada chave; no framework MapReduce, chama reduce com a chave pela qual é responsável e um vetor de todos os valores que os maps produziram.

[57:35] associados a essa chave. A chave é a palavra, os valores são todos uns, não nos importamos realmente com eles, só nos importamos com quantos havia. hum. E então, reduce tem sua própria função emit que apenas recebe um valor a ser emitido como saída final. como o valor para esta chave. Então vamos emitir o comprimento. Obrigado. deste array. Obrigado. Então isso também é tão simples quanto funções reduce são. no MapReduce, ou seja, Extremamente simples.

[58:08] e não exigindo nenhum conhecimento sobre tolerância a falhas ou qualquer outra coisa? Certo, alguma pergunta sobre... O framework básico, sim. e não... necessário mas isso pode retornar algo. Estou nisso. Tipo França, França, França. usando o framework MapReduce que talvez seja reduce com acesso. esse passo algum número de vezes. Você quer dizer que você pode alimentar a saída dos reduces meio que— Sim.

[58:43] Obrigado. Oh, sim. Oh sim, na vida real, certo. Na vida real, é rotina entre usuários de MapReduce, você sabe, definir um job MapReduce que recebe algumas entradas e produz algumas saídas e então ter um segundo job MapReduce, você sabe, se você está fazendo alguma análise multi-estágio muito complicada. ou algoritmo iterativo. como PageRank, por exemplo, que é o algoritmo que o Google usa para meio que estimar quão importante ou influente diferentes páginas web são. Esse é um algoritmo iterativo que meio que converge gradualmente para uma resposta. E se você implementar um MapReduce, o que eu acho que eles originalmente fizeram, você tem que executar o job MapReduce múltiplas vezes.

[59:28] A saída de cada um é meio que— você sabe, lista de páginas web, com um valor ou peso ou importância atualizado para cada página web. Então era rotina pegar essa saída e então usá-la como entrada para outro job MapReduce. Não podemos fazer isso para sempre. Ah sim. é. todas as lágrimas "Bem, sim, você precisa meio que configurar as coisas a saída, você precisa— a função reduce meio que com o conhecimento disso.

[1:00:00] Atender a produzir. dados que estão no formato ou têm a informação necessária para o próximo job MapReduce. Quer dizer, isso na verdade traz à tona uma pequena deficiência no framework MapReduce, que é, é ótimo. se você está Obrigado. se o algoritmo que você precisa executar é facilmente expressável como um map seguido por esse tipo de "embaralhamento dos dados por chave, seguido por um reduce, e é isso." MapReduce é fantástico para algoritmos que podem ser moldados nessa forma.

[1:00:30] E além disso, cada um dos maps tem que ser completamente independente. exigido ser uh... funcionais, funções puramente funcionais que apenas olham seus argumentos e nada mais. E você sabe, isso é tipo, é uma restrição. E acontece que muitas pessoas querem executar pipelines muito mais longos que envolvem muitos e muitos tipos diferentes de processamento. E com MapReduce, você tem que meio que remendar isso a partir de múltiplos—e MapReduce. jobs distintos produzidos por map. e sistemas mais avançados, que falaremos mais tarde no curso, são muito melhores em permitir que você especifique o pipeline completo de computações, e eles farão otimização.

[1:01:09] o framework percebe todas as coisas que você tem que fazer. organizar muito mais complicado eficientemente. otimizar, muito mais complicado. Computação. Sua pergunta. Então no artigo, eles distinguem entre mappers e funções map. Eu acho que esse é o— tipo os processos que estão executando o map. Quais são os... e acolhem os processos que estão— Do ponto de vista do programador, é só sobre map e reduce.

[1:01:43] Do nosso ponto de vista, vai ser sobre os processos worker. e os servidores worker que fazem parte do framework MapReduce, entre muitas outras coisas. chamá-los de funções produzidas. Então— hum Sim, do nosso ponto de vista, nos importamos muito com como isso é organizado pelo framework circundante. Esta é meio que a visão do programador com toda a parte distribuída removida. Hum. Sim? Obrigado. Desculpe, eu tenho que...

[1:02:21] Diga de novo. Desculpe, você emite localmente? Oh, você quer dizer para onde vão os dados emitidos? Obrigado. Ok, então há duas perguntas. Uma é... Quando você chama emit, o que acontece com os dados? e a outra é onde as funções rodam. Então, Obrigado. Hum. A resposta real é que Primeiro, onde as coisas rodam? Há um número de, digamos, mil servidores. Na verdade, a coisa certa a olhar aqui é a figura um no artigo.

[1:02:59] Hum, embora por baixo disso no mundo real, haja alguma grande coleção de servidores. E Hum. Vamos chamá-los talvez de servidores worker ou workers. E. Há também um único servidor master que está organizando toda a computação. E o que está acontecendo aqui é que o servidor master sabe que há algum número de arquivos de entrada, você sabe, 5,000 arquivos de entrada. e ele distribui invocações de map para os diferentes workers. Então ele enviará uma mensagem para o worker sete dizendo, por favor execute esta função map em tal e tal arquivo de entrada.

[1:03:39] E então a função worker que é, você sabe, parte do MapReduce e sabe tudo sobre MapReduce, bem então, Hum, Ler o arquivo, ler a entrada, tanto faz, qualquer que seja o arquivo de entrada. e chamar esta função map com o nome do arquivo e valor como argumentos. do que aquele processo worker. é o que implementa emit. E toda vez que o map chama emit, O processo worker. vai escrever esses dados em arquivos no disco local.

[1:04:11] Então o que acontece com os emits do map? é que eles produzem arquivos no disco local do worker do map que estão acumulando todas as chaves e valores produzidos pelo map executado naquele worker. hum Então no final da fase map, O que nos resta é todas aquelas máquinas worker Cada uma das quais tem a saída de alguns dos maps que foram executados naquela máquina worker. Então os workers do MapReduce organizam a movimentação dos dados para onde serão necessários para os reduces e já que eu E uma computação grande típica Essa sincronização de reduce vai precisar de toda a saída de map que mencionou a chave A, mas vai acabar que, você sabe, este é um exemplo meio simples, mas provavelmente, Em geral, cada invocação de map produzirá muitas chaves, incluindo algumas instâncias da chave A.

[1:05:13] Então tipicamente, em ordem, antes de podermos sequer executar esta função reduce, o framework MapReduce, ou seja, o worker MapReduce rodando em um dos nossos mil servidores, vai ter que ir falar com cada um dos outros mil servidores e dizer: "Olha, eu vou executar o reduce para a chave A, por favor. Olhe para a saída intermediária do map armazenada no seu disco e pesque todas as instâncias da chave A e envie-as pela rede para mim." Então o worker do reduce vai fazer isso. Vai buscar de cada worker.

[1:05:44] todas as instâncias da chave pela qual é responsável, que o master lhe disse para ser responsável. E uma vez que tenha coletado todos esses dados, então pode chamar reduce. E a própria função reduce chama reduce emit, que é diferente do emit do map. O que o emit do reduce faz é escrever a saída em um arquivo. em um serviço de arquivos de cluster que o Google usa. Então aqui está algo que eu não mencionei.

[1:06:15] Hum, eu não mencionei onde a entrada fica. e onde a saída fica. Ambas são vials. Hum, porque qualquer pedaço de entrada Nós queremos a flexibilidade de poder ler qualquer pedaço de entrada em qualquer servidor trabalhador. Isso significa que precisamos de algum tipo de sistema de arquivos de rede para armazenar os dados de entrada. Hum, E então de fato, o artigo fala sobre essa coisa chamada GFS, de Google File System.

[1:06:48] Hum, E o GFS é um sistema de arquivos de cluster. E o GFS na verdade roda exatamente no mesmo conjunto de servidores trabalhadores que rodam o MapReduce. E a entrada GFS apenas automaticamente, quando você, sabe, é um sistema de arquivos, você pode ler e escrever arquivos. ele apenas automaticamente divide qualquer arquivo grande que você armazena nele. por muitos servidores em pedaços de 64 megabytes. Então se você escrever, se você tiver 10 terabytes de conteúdo de páginas web rastreadas. e você apenas escrevê-los no GFS, mesmo como um único arquivo grande, o GFS automaticamente dividirá essa vasta quantidade de dados em pedaços de 64 kilobytes distribuídos uniformemente por todos os servidores GFS, ou seja, todos os servidores que o Google tem disponíveis.

[1:07:32] E isso é fantástico, é exatamente o que precisamos. Se então quisermos executar um trabalho MapReduce que toma toda a web rastreada como entrada. os dados já estão armazenados de uma forma que é dividida uniformemente por todos os servidores. E então isso significa que hum os trabalhadores de map, você sabe, nós vamos lançar Se tivermos mil servidores, vamos lançar mil trabalhadores de map cada um lendo um milésimo dos dados de entrada. e eles poderão ler os dados em paralelo de mil servidores de arquivos GFS.

[1:08:02] Isso está obtendo... Uma tremenda taxa total. de leitura. você sabe, a taxa de leitura de mil servidores. Sim. Obrigado. executando o map. Então você está pensando que talvez o Google tenha um conjunto de máquinas físicas que rodam o GFS e um conjunto separado de máquinas físicas que rodam trabalhos MapReduce. dizendo que o Posso ter dois?

[1:08:37] Ok. Eles não são necessariamente. - Certo, então a pergunta é: o que é essa seta aqui? realmente envolve. Hum, E a resposta para isso na verdade meio que mudou ao longo dos anos à medida que o Google de todo esse sistema. Você sabe, com isso no caso mais geral, se tivermos arquivos grandes armazenados em algum sistema de arquivos de rede grande. Tipo, você sabe, é como o GFS é um pouco como o AFS. que você pode ter usado no Athena. onde você vai falar com alguma coleção, seus dados são divididos por, uma grande coleção de servidores, você tem que ir falar com esses servidores pela rede para recuperar seus dados.

[1:09:13] Hum, Nesse caso, o que essa seta pode representar é Obrigado. o map, o processo trabalhador do MapReduce tem que sair e falar pela rede com o servidor GFS correto ou talvez servidores. que armazenam sua parte da entrada. e buscá-la pela rede para a-- máquina trabalhadora do MapReduce a fim de passar o map. E esse é certamente o caso mais geral. E foi eventualmente como o MapReduce realmente funcionou. No mundo deste artigo, porém, E se você fizesse isso, isso é muita comunicação de rede.

[1:09:47] Você está falando de 10 terabytes de dados, e então temos que mover 10 terabytes pela rede do data center deles, o que... você sabe, redes de data center rodam a gigabits por segundo, mas ainda é muito tempo para mover. dezenas de terabytes de dados. Obrigado. a fim de tentar, e de fato no mundo deste artigo em 2004, O gargalo mais restritivo em seu sistema MapReduce era a taxa de transferência da rede. porque eles estavam rodando em uma rede, se você ler até a seção de avaliação. a rede deles, a rede deles era Hum...

[1:10:23] Eles tinham milhares de máquinas, sei lá, e eles coletavam máquinas, eles conectavam máquinas em, você sabe, cada rack de máquinas em, você sabe, um switch Ethernet para aquele rack ou algo assim. Mas então, você sabe, todas elas precisam falar umas com as outras. Mas havia um switch Ethernet raiz. com o qual todos os switches Ethernet de rack falam. E isso, e você sabe, então se você apenas escolher algum trabalhador MapReduce e algum servidor GFS as chances são de que pelo menos metade das vezes, a comunicação entre eles tenha que passar por esse único switch raiz. O switch raiz deles tinha apenas uma certa quantidade de taxa de transferência total, que eu esqueço, uh... você sabe, algum número de gigabits por segundo.

[1:11:07] hum De qualquer forma, eu esqueço o número, mas quando fiz a divisão, ou seja, dividi a taxa de transferência total disponível no switch raiz pelos aproximadamente 2,000 servidores que eles usaram nos experimentos do artigo. O que obtive foi que a parcela de cada máquina do switch raiz, ou da capacidade total da rede, era de apenas 50 megabits por segundo. na configuração deles. Legendas pela comunidade Amara.org Então 50 megabits por segundo por máquina.

[1:11:39] E isso pode parecer muito, 50 megabits, nossa, milhões e milhões. Mas na verdade é bem pequeno comparado à velocidade, digamos, dos discos ou das CPUs. E então isso, com a rede deles, esses 50 megabits por segundo eram um limite tremendo. Eles realmente se desdobraram no design descrito no artigo para evitar usar a rede. E eles usaram vários truques para evitar enviar coisas pela rede quando podiam evitar. Um deles foi Eles rodaram o GFS.

[1:12:12] servidores. e os trabalhadores do MapReduce no mesmo conjunto de máquinas. para que eles tenham mil máquinas Eles rodariam o GFS, eles implementam seu serviço GFS nessas mil máquinas e rodam o MapReduce nas mesmas mil máquinas. E então quando o mestre estava dividindo o trabalho de map e meio que distribuindo para diferentes trabalhadores, ele inteligentemente quando estava EU VOU PARA A PRÓXIMA PERGUNTA. prestes a executar o map. que ia ler do arquivo de entrada um, ele descobriria a partir do GFS qual servidor realmente mantém o arquivo de entrada um em seu disco local.

[1:12:50] E ele-- Enviar o map. para aquele arquivo de entrada para o software MapReduce na mesma máquina. de modo que, por padrão, essa seta é na verdade uma leitura local do disco local e não envolvia a rede. E você sabe, dependendo de falhas ou carga ou o que for, que nem sempre podiam fazer isso. Mas quase todos os maps seriam executados na mesma máquina que armazenava os dados, poupando assim uma vasta quantidade de tempo que de outra forma teriam que esperar para mover os dados de entrada pela rede.

[1:13:21] Hum, O próximo truque que eles usaram é que o map, como mencionei antes, armazena sua saída no disco local da máquina em que você executa o map. Então, novamente, armazenar a saída do map não requer comunicação de rede, pelo menos porque a saída é armazenada no disco. no entanto Nós sabemos com certeza que de uma forma ou de outra, para agrupar todos os da forma como o MapReduce é definido, Para agrupar todos os valores associados a uma determinada chave e passá-los em uma única invocação para produzir em alguma máquina, isso vai exigir comunicação de rede.

[1:13:59] Nós vamos--você sabe, nós queremos--nós precisamos--nós estamos Isso é todos os A's e dar a eles uma única máquina para ter que ser movidos pela rede. E então esse shuffle, esse movimento das chaves desse tipo, você sabe, originalmente armazenadas por linha na mesma máquina que executou o map. Precisamos que elas essencialmente sejam armazenadas por coluna na máquina que será responsável pelo reduce. Essa transformação de armazenamento por linha para essencialmente armazenamento por coluna é chamada, o artigo chama de shuffle. E realmente isso exigia mover cada pedaço de dados.

[1:14:30] pela rede. do map que o produziu para o reduce que precisávamos. E isso foi tipo a parte cara do... Hum. do MapReduce. Sim. Por que eles não? fizeram algo que rodasse tipo como você teria você Mantenha seu... como você já tem. escolha um dos então você teria esperado a noite toda. Você está certo, você pode imaginar uma definição diferente na qual você tem um reduce mais tipo streaming. Eu não sei, não pensei nisso a fundo. Não sei por quê. se isso seria viável ou não. Certamente no que diz respeito à interface do programador, tipo, se o objetivo, o objetivo número um deles realmente, era tornar fácil programar.

[1:15:11] por pessoas que simplesmente não tinham ideia do que estava acontecendo no sistema. Então pode ser que esta especificação, esta é realmente a forma como as funções reduce se parecem. em C++ ou algo assim. Tipo, uma versão streaming disso agora está começando a parecer Eu não sei como parecia. Provavelmente não tão simples. Mas você sabe, talvez pudesse ser feito dessa forma. E de fato, muitos sistemas modernos As pessoas se tornaram muito mais sofisticadas. com coisas modernas que são os sucessores do MapReduce. E eles de fato envolvem processar fluxos de dados frequentemente em vez dessa abordagem muito em lote. É uma abordagem em lote no sentido de que esperamos até obter todos os dados e então os processamos.

[1:15:55] Então, antes de tudo, você precisa ter uma noção de entradas finitas, certo? E sistemas modernos frequentemente de fato usam streams. e... são capazes de tirar proveito de algumas eficiências devido a isso. Obrigado. mas não o MapReduce. Obrigado. Hum... Ok, então este é o ponto em que o shuffle é onde todo o tráfego de rede acontece, isso pode na verdade ser uma vasta quantidade de dados. Então, se você pensar em ordenação, Se você estiver ordenando, a saída da ordenação tem o mesmo tamanho que a entrada da ordenação. Então isso significa que se sua entrada for 10 terabytes de dados, e você estiver executando uma ordenação, você está movendo 10 terabytes de dados pela rede neste ponto.

[1:16:37] E sua saída também será 10 terabytes e então isso é-- bastante dados e de fato é para muitos trabalhos produzidos por map, embora não todos. Eles reduzem significativamente a quantidade de dados nesses estágios. Eu estou... Alguém mencionou, oh, e se você quiser alimentar a saída do reduce em outro MapReduce E de fato, era frequentemente o que as pessoas queriam fazer. E de qualquer forma, a saída do reduce pode ser enorme, como para ordenação ou para indexação da web. a saída que ele produz é sobre 10 terabytes de entrada. a saída do reduce será novamente 10 terabytes. Então a saída do reduce também era armazenada no GFS.

[1:17:10] E o sistema-- você sabe, o reduce apenas produziria esses pares chave-valor, mas o, Obrigado. A estrutura MapReduce os reuniria e os escreveria em arquivos gigantes no GFS. Hum, E então havia outra rodada de comunicação de rede necessária para levar a saída de cada reduce ao servidor GFS necessário para armazenar esse produto. Você pode pensar que eles poderiam ter... Usado o mesmo truque com a saída de armazenar a saída no servidor GFS que por acaso executava hum o trabalhador MapReduce que executou o reduce.

[1:17:48] E talvez eles tenham feito isso, mas porque o GFS, além de dividir os dados para desempenho, também mantém duas ou três cópias para tolerância a falhas. Isso significa que não importa o quê, você precisa escrever uma cópia dos dados pela rede para um servidor diferente. Então há muita comunicação de rede aqui, e um pouco aqui também. Hum, E foi essa comunicação de rede que realmente limitou a... Taxa de transferência do MapReduce. em 2004. Hum, Em 2020, Porque esse arranjo de rede era um fator tão limitante para tantas coisas que as pessoas queriam fazer em data centers.

[1:18:22] As redes de data center modernas são muito mais rápidas na raiz do que isso era. Hum, Uma rede de data center típica que você pode ver hoje na verdade tem muitas raízes, em vez de um único switch raiz pelo qual tudo tem que passar, você pode ter-- muitos switches raiz e cada switch de rack tem uma conexão para cada um desses switches raiz replicados e o tráfego é dividido. entre os switches raiz. Então as redes de data center modernas têm muito mais taxa de transferência de rede hum E por causa disso, na verdade, modernos-- eu acho que o Google meio que parou de usar o MapReduce alguns anos atrás, mas Hum, antes de pararem de usá-lo.

[1:19:01] O MapReduce moderno na verdade não tenta mais executar os maps. na mesma máquina onde os dados estavam armazenados. Eles ficavam felizes em carregar os dados de qualquer lugar porque simplesmente assumiam que a rede era extremamente rápida. Certo. Estamos sem tempo para o MapReduce. Temos um laboratório. no final da próxima semana no qual você escreverá seu próprio MapReduce um tanto simplificado. Então, divirta-se com isso. e nos vemos na quinta-feira.