MC714A - 2º Semestre 2015 Nomes: Roberto Hayasida Mariane Previde Cibelle Begalli RAs:103984 121192 135334
Introdução Os 4 grandes tipos de sistemas de armazenamento utilizados no Facebook: OLTP (Online Transaction Processing Databases): Social Graph SLTP (Semi-Online Light Transaction Processing Database): Messages Immutable DataStore: Photos, Vídeos Analytics DataStore: Data Warehouse, Logs 3
Escala Tamanho Tecnologia Gargalo Social Graph Unidades Petabytes MySQL, TAO Random Read IOPS Messages Dezenas Petabytes HBase, HDFS Write IOPS, Storage Photos Altas Dezenas Petabytes Haystack Storage Data Warehouse Centenas Petabytes Hive, HDFS, Hadoop Storage 4
Características Latência (consultas) Consistência Durabilidade Social Graph < poucos milisegundos rapidamente consistente Sem perdas Messages < 200 ms consistente dentro do data center Sem perdas Photos < 250 ms imutável Sem perdas Data Warehouse < 1min não consistente entre data centers Sem perdas 5
TAO Facebook s Distributed Data Store for the Social Graph
Introdução TAO: The Associations and Objects É um sistema geograficamente distribuído de armazenamento de dados que provê acesso eficiente ao Social Graph do Facebook. É implantado como uma única instância distribuída geograficamente. Tem uma API mínima que explicitamente favorece disponibilidade e eficiência por-máquina sobre consistência forte. 7
História (1) Em 2007, um grupo de engenheiros começou um projeto para definir uma nova abstração para armazenamento de dados que se adequasse as necessidades mais exigentes do site e que ao mesmo tempo escondesse a complexidade do armazenamento distribuído subjacente. A TAO API criada era baseada em grafos e era inicialmente implementada em PHP, rodando nos servidores web do site. 8
História (2) Com o crescimento do uso da API, várias limitações da implementação no lado cliente surgiram, entre elas, problemas com a manutenção de consistência e desperdícios de recursos de rede e CPU. Todos esses problemas poderiam ser resolvidos com a criação de um serviço distribuído concebido em torno de objetos e associações. 9
História (3) Em 2009, um grupo de engenheiros de infraestrutura da empresa começou a trabalhar no TAO, que está atualmente em produção há anos, rodando em um conjunto vasto de clusters distribuídos, lidando com bilhões de requisições de leituras e milhões de requisições de escrita por segundo. 10
Motivação e Objetivo (1) Páginas do site agregam e filtram centenas de itens do Social Graph, customizados para cada usuário de acordo com regras de privacidade. Isso torna impraticável realizar a maior parte dessa agregação e filtragem quando o conteúdo é criado. A alternativa é aplicá-los quando o conteúdo é visualizado. Mas essa estratégia cria altas demandas de leitura no armazenamento do Social Graph, que deve ser eficiente, ter alta disponibilidade e ser escalável para altas taxas de consultas. 11
Motivação e Objetivo (2) 12
Arquitetura (1) Separação em duas camadas de cache e uma camada de armazenamento. 13
Arquitetura (2) Armazenamento: Dado que o volume de dados é maior do que pode ser armazenado em um único servido, ele é dividido em fragmentos lógicos (shards). Cada fragmento é contido em um banco de dados. Servidores são responsáveis por um ou mais fragmentos. O mapeamento fragmento-servidor é optimizado para dividir a carga entre os servidores. 14
Arquitetura (3) Cache: Provê a API completa aos clientes, lidando com toda a comunicação com os bancos de dados. Utiliza um sistema de fragmentos similar ao armazenamento. Consiste de conjuntos de servidores que formam uma camada (tier). Em teoria, uma camada pode ser escalável para operar com qualquer taxa de requisições. Mas na prática, camadas amplas são problemáticas. 15
Arquitetura (4) Cache: Para poder adicionar servidores e ao mesmo tempo limitar o tamanho máximo da camada, o cache é dividido em dois níveis: uma camada líder e múltiplos seguidores. Clientes comunicam-se com o seguidor mais próximo, e nunca diretamente com o líder. Para manter consistência, todos as operações de escritas passam pelo líder. Seguidores são explicitamente notificados sobre mudanças feitas por outros seguidores. 16
Arquitetura (5) Cache: TAO provê consistência eventual, através de mensagens assíncronas de manutenção de cache enviadas pelo líder aos seguidores. O seguidor que enviou uma requisição de atualização ao líder é atualizado de modo síncrono com uma resposta do líder. Números de versões nas mensagens de atualização são utilizados para evitar que a mesma operação seja efetuada mais de uma vez. 17
Arquitetura (6) Cache: Cada região geográfica tem um conjunto completo de bancos, uma camada líder e pelo menos duas camadas de seguidores. De acordo com o Facebook, TAO é o primeiro sistema distribuído a explorar simultaneamente consistência eventual, bancos de dados baseados em grafos e optimização de leitura em um único sistema de grande escala. 18
Arquitetura (7) 19
Escalabilidade Geográfica (1) A configuração líder-seguidor permite que o TAO escale para lidar com uma carga alta de requisições, já que a taxa de leitura escala com o número total de seguidores em todos os tiers. Implicitamente, espera-se que a latência entre líder e seguidores seja baixa, o que é razoável se clientes estão restritos a um único data center ou a um conjunto de data centers próximos uns aos outros. Porém, no ambiente de produção do Facebook, seguidores podem estar a quilômetros de distância e, portanto, RTTs (round trip times) podem ser tornar gargalos na arquitetura. 20
Escalabilidade Geográfica (2) Como a frequência de read misses é 25 vezes maior que de write misses, a arquitetura atual requer que requisições de escritas sejam enviadas ao líder, mas requisições de leituras são respondidas localmente pelos seguidores. Assim, dá-se prioridade a performance e disponibilidade ao custo de nem sempre poder disponibilizar os dados mais atuais. 21
Consistência e Tolerância a Erros (1) Disponibilidade e performance são dois dos requisitos mais importantes do TAO. Quando uma falha ocorre, é desejável que ainda seja possível renderizar a aplicação, mesmo que com dados antigos. 22
Consistência e Tolerância a Erros (2) Consistência: Em operação normal, TAO garante consistência eventual. Depois de uma alteração, é garantida a entrega de mensagens de invalidação e atualização a todas as camadas. A consistência leitura-após-escrita é garantida dentro de uma camada. Dado um período de tempo em que o input pare, todas as cópias serão consistentes. 23
Consistência e Tolerância a Erros (3) Consistência: O atraso de replicação é normalmente de menos de um segundo. Requisições de leituras podem ser marcadas como críticas, e serão redirecionadas para o líder (por exemplo, no caso de autenticação). Detecção de erros e tratamento: Como TAO escala para milhares de máquinas distribuídas geograficamente, falhas momentâneas e permanentes são comuns. 24
Consistência e Tolerância a Erros (4) Detecção de erros e tratamento: Servidores utilizam timeouts agressivos. Cada servidor mantém timeouts por destino, e caso ocorram vários consecutivos, um destino pode ser marcado como inativo. Bancos de dados são marcados como inativos em uma configuração global quando eles falham, são retirados do ar para manutenção ou estão replicando dados do líder há muito tempo. Quando um banco mestre é inativado, um banco escravo é promovido a mestre automaticamente. 25
Performance Rodar uma única instância do TAO para todo o Facebook permite colher benefícios de economia de escala, e torna mais fácil a integração de novos produtos ao Social Graph. Disponibilidade: em um período de 90 dias, a fração de requisições que falharam nos servidores web foi 4.8 x 10-6. 26
HBase Storage Infrastructure Behind Facebook Messages: Using HBase at Scale HydraBase The evolution of HBase@Facebook
Introdução HBase é um banco de dados distribuído de larga escala, que tem como base o Sistema Distribuído de Arquivos Hadoop (HDFS). Inicialmente utilizado no Messages, atualmente é também usado em outras aplicações da empresa. Extensões e melhorias são aplicadas pelo Facebook para que o sistema atenda a todas as necessidades da rede social. 28
Motivação Razões para escolha do HBase: Alta taxa de transferência de escrita. Baixa latência para leituras randômicas. Elasticidade. Hardware barato e tolerância a erros. Forte consistência. 29
Conceitos básicos Dados são fragmentados fisicamente em regiões, contidas em um único servidor de região, que pode servir um ou mais regiões. Dados são primeiramente escritos em um Write-Ahead Log chamado HLog, e depois, em memória (MemStore). Quando eles excedem um certo limite, eles são gravados em um HFile no disco. Conforme o número de arquivos aumenta, o sistema os compacta, para reduzir o overhead de leitura. Quando um servidor de região falha, todas as regiões servidas por ele migram para outro servidor. Devido a arquitetura do sistema, isso aumenta o tempo de recuperação. 30
31
HydraBase (1) Criada pelo Facebook, tendo como principal motivação melhorar o tempo de recuperação quando um servidor de região falha. Diferentemente de HBase, uma região é hospedada em um conjunto de servidores. Quando ocorre uma falha, há servidores em standby prontos para servir essas regiões. O conjunto de servidores que hospedam uma região se chama quorum. Cada quorum tem um líder, que trata as requisições de leitura e escrita do cliente. Dentro de um quorum, um membro pode estar ativo (escrevendo no HDFS e fazendo compactações) ou em modo espectador (replicando o WAL). Com um quorum de 2F+1 servidores, pode-se tolerar até F falhas. 32
HydraBase (2) O objetivo foi do HydraBase é desacoplar a replicação lógica da física. Assim, com HydraBase, a granularidade de falha pode ser de uma única região e o tempo de recuperação é menor. Portanto, é possível aumentar a confiabilidade do HBase de 99.99% para 99.999% se implementada em múltiplos data centers, conforme o exemplo. Isso significa menos de 5min de downtime por ano. 33
Exemplo Implementação em 3 data centers, com quorum de tamanho 5. 34
Exemplo Caso o Active Leader falhe, o Witness Follower do mesmo data center assume o papel de líder. 35
Exemplo Se todo o data center D-1 torna-se indisponível, o Active Follower do segundo data center torna-se líder, já que esse data center também está escrevendo dados no HDFS. 36
Armazenamento fotos do Facebook 2009 2012 Tamanho 15 bilhões de fotos 1.5 Petabyte Dezenas Petabytes Upload 30 milhões fotos por dia 3 TB/dia 300 milhões fotos por dia 30 TB/dia 37
Photo Caching An analysis of Facebook photo caching
Funcionamento Sistema de cache geograficamente distribuído 3 camadas de cache até servidores de armazenamento Todos componentes são capazes de responder qualquer requisição - afim de manter disponibilidade do serviço 39
Camadas Camada Browser Cache Localizada junto ao cliente/usuário LRU - fila de prioridade ordenada pela data último acesso Camada Edge Cache Proposta: reduzir latência e acesso Data Center Política de substituição de conteúdo: FIFO Tabela hash guarda metadados das fotos armazenadas no momento 40
Camadas Camada Origin Cache Proposta: minimizar operações I/O nos servidores de armazenamento Também usa FIFO e tem tabela de hash dos metadados Camada Backend (Haystack) Geralmente Origin servers são colocados juntamente com servidores de armazenamento Ao ocorrer cache miss em Origin Cache, busca é feita em servidor de armazenamento local - caso esteja indisponível, servidor remoto é contatado 41
Haystack Sistema de armazenamento otimizado para fotos do Facebook Eficiente no armazenamento e recuperação dos bilhões de fotos Modelo tradicional realiza um número expressivo de operações de disco na pesquisa de metadados Reduzido quantidade de metadados por fotos de maneira que pesquisa seja realizada na memória Operações de disco são realizadas para leitura de conteúdo efetivamente 42
Resultados 43
Análise rede social Padrão de comportamento considerando idade do conteúdo e popularidade do proprietário 44
Melhorias Algoritmo de substituição de conteúdo nas camadas Edge Cache e Origin Atualmente implementa com FIFO Aumento na taxa de hits de 8,5% usando S4LRU Colaboração entre componentes da camada Edge Cache Aumento na taxa de hits de 18% Aumentar tamanho cache 45
Estudo de caso Facebook Distributed System Case Study For Distributed System Inside Facebook Datacenters
Introdução Hadoop: Processamento paralelo de dados em grande escala Map/Reduce: Modelo de programação para processar grandes volumes de dados em paralelo HDFS: Sistema de arquivos do Hadoop Hive: Manipulador e armazenador dados 47
Motivação Lidar com grande massa de dados acumulada de dados de forma escalável Processar tal massa de dados para Melhoria da experiência do usuário e melhorias para o produto Gerar estatísticas sobre a utilização do site. Gerar relatórios para desenvolvedores de terceiros e anunciantes Performance / Custo-Benefício 48
Hadoop Fornece estrutura para processamento paralelo de dados em grande escala usando um sistema de arquivo distribuídos (HDFS) e o paradigma de programação Map/Reduce Open Source Com o Hadoop é possível obter resultados muito mais rápidos e com menos necessidades computacionais O Facebook possui diversos Clusters Hadoop Os trabalhos que levavam um dia para serem completados com modelo de banco de dados relacional (RDBMS), com o Hadoop podem ser concluídos dentro de horas 49
Componentes do Hadoop 50
Map/Reduce (1) Paradigma de programação, implementado dentro do Hadoop Permite que os dados sejam manipulados por diversas tarefas independentes em paralelo, garantindo eficiência e um processamento das informações de forma distribuída. Ambas as tarefas (Map e Reduce) rodam paralelamente no cluster 51
Map/Reduce (2) Os principais componentes do Map-Reduce: Job Tracker: tarefas de Map-Reduce são submetidas ao Job Tracker. Ele precisa falar com o Namenode para conseguir os dados. O Job Tracker submete a tarefa para os nós task trackers. Esses task tracker precisam se reportar ao Job Tracker em intervalos regulares, especificando que estão vivos e efetuando suas tarefas. Se o task tracker não se reportar a eles, então o nó é considerado morto e seu trabalho é redesignado para outro task tracker. O Job tracker é novamente um ponto crucial de falha. Se o Job Tracker falhar, não poderemos rastrear as tarefas. Task Tracker: O Task Tracker cria um processo JVM separado para cada tarefa a fim de se certificar de que uma falha no processo não resulte em uma falha de Task Tracker. Task trackers também se reportam ao Job Tracker continuamente para que este possa manter o registro de tarefas bem ou mal sucedidas. 52
HDFS (1) Sistema de arquivos escalonável e distribuído Armazena todos os arquivos em blocos O modelo WORM (write-once-read-many) tal modelo simplifica exigencias de consistencia de dados, habilitando maior rendimento. 53
HDFS (2) Os clusters HDFS possuem dois tipos de nós primeiro um NameNode, que é um Master, e múltiplos DataNodes, que são nós slave. Namenode: administra o namespace do sistema de arquivos. Ele gerencia todos os arquivos e diretórios. Namenodes possuem o mapeamento entre arquivos e os blocos nos quais estes estão armazenados. Todos os arquivos são acessados usando esses namenodes e datanodes. Datanode: armazena os dados em forma de blocos. Datanodes se reportam a namenodes sobre os arquivos que possuem armazenados para que o namenode esteja ciente e os dados possam ser processados. Namenode é talvez o principal ponto crucial de falha do sistema, sem o qual os dados não podem ser acessados. Namenodes secundários: esse node é responsável por checar a informação do namenode. No caso de falha, podemos usar esse nó para reiniciar o sistema. 54
Componentes do Hadoop 55
Hive (1) Hive foi concebido com a ideia de construir uma aplicação de Data Warehouse open source, que utilizasse conceitos do Hadoop, como Map/Reduce e HDFS, para manipular e armazenar dados. Data Warehouse : depósito de dados digitais que serve para armazenar informações detalhadas relativamente a uma empresa, criando e organizando relatórios através de históricos que são depois usados pela empresa para ajudar a tomar decisões importantes com base nos fatos apresentados. Cada um desses sistemas apresenta soluções mais customizadas para determinadas situações, porém tentam sempre manter o foco em alguns pontos principais como escalabilidade, performance, usabilidade e confiabilidade. Ex. : Bancos de dados relacionais, Banco de dados não relacionais. 56
Hive (2) O Hive diminui complexidade e a curva de aprendizado da utilização das funcionalidades do Hadoop através da linguagem HiveQL, permitindo seu uso por desenvolvedores que não possuem conhecimento extenso da plataforma de Map/Reduce, com um código intuitivo e mais próximo do SQL. 57
Bibliografia (1) Petabyte Scale Data at Facebook https://www-conf.slac.stanford.edu/xldb2012/talks/xldb2012_wed_1105_dhrubaborthakur.pdf TAO: Facebook's Distributed Data Store for the Social Graph https://research.facebook. com/publications/161988287341248/tao-facebook-s-distributed-data-store-for-the-social-graph/ HydraBase The evolution of HBase@Facebook https://code.facebook.com/posts/321111638043166/hydrabase-the-evolution-of-hbase-facebook Storage Infrastructure Behind Facebook Messages: Using HBase at Scale https://research.facebook.com/publications/1379193088985155/storage-infrastructure-behind-facebook-messages-using-hbase-at-scale/ 58
Bibliografia (2) Facebook Distributed System Case Study For Distributed System Inside Facebook Datacenters http: //www.ijteee.org/final-print/july2014/facebook-distributed-system-case-study-for-distributed-system-inside-facebook-datacenters.pdf An Analysis of Facebook Photo Caching https://research.facebook.com/publications/363689800436703/an-analysis-of-facebook-photo-caching/ Finding a needle in Haystack: Facebook's photo storage https://research.facebook.com/publications/510108032399801/finding-a-needle-in-haystack-facebook-s-photo-storage/ Notes: Facebook Engineering https://www.facebook.com/engineering/notes 59
Obrigado! Dúvidas? 60