Cassandra: Requisições de clientes e integração com Hadoop. Jorge Faria Fernandes Mycke Richard Guntijo

Transcrição

1 Cassandra: Requisições de clientes e integração com Hadoop Jorge Faria Fernandes Mycke Richard Guntijo

2 Sumário Requisições de Clientes Coordinator Requisições de Leitura Requisições de Leitura em Múltiplos Data Centers Requisições de Escrita

3 Sumário Hadoop HDFS MapReduce Pig Hive Mahout Sqoop Cassandra File System

4 Requisições de Clientes Todos os nós no Cassandra são peers. Uma requisição de leitura ou de escrita pode ser destinada a qualquer nó do cluster. Quando um cliente se conecta a um nó do cluster, o respectivo nó se torna o coordinator para tal operação.

5 Coordinator O papel do nó coordinator é atuar como um proxy entre a aplicação cliente e os nós que possuem os dados requisitados.

6 Coordinator

7 Coordinator O nó coordinator determina quais nós do anel devem atender a requisição do cliente baseado em dois parâmetros: Estratégia de replicação de dados; Configuração de particionamento.

8 Coordinator Estratégia de replicação de dados SimpleStrategy Utilizada em ambientes de single Data Center. Insere a primeira réplica em um nó determinado pelo particionador e as demais são inseridas nos nós do anel que forem mais próximos, no sentido horário.

9 Coordinator Estratégia de replicação de dados NetworkTopologyStrategy Utilizada em ambientes de múltiplos Data Centers. Determina quantas réplicas haverão em cada Data Center, sendo que elas podem ser em racks diferentes: Duas réplicas por Data Center. Três réplicas por Data Center.

10 Coordinator Estratégia de replicação de dados

11 Coordinator Configuração de particionamento Murmur3Partitioner (default) Distribui uniformemente os dados ao longo do cluster de acordo com os valores de hash do MurmurHash. RandomPartitioner Distribui uniformemente os dados ao longo do cluster de acordo com os valores de hash do MD5. ByteOrderedPartitioner Mantém uma distribuição ordenada lexicalmente por chaves de bytes.

12 Requisições de Escrita O nó coordinator envia uma requisição de escrita para todas as réplicas que contém a row que será gravada. Se todos os nós réplicas estiverem ativos e disponíveis, eles começarão a escrever, independente do nível de consistência especificado pelo cliente. O nível de consistência de escrita determina quantos nós réplicas devem responder com um ack de sucesso para que a gravação seja cosiderada bem sucedida.

13 Requisições de Escrita "Sucesso" significa que os dados foram escritos no commit log e na memtable.

14 Requisições de Escrita Níveis de consistência de escrita: ANY: a escrita é realizada com sucesso em pelo menos um nó, incluindo os nós com hinted Handoff. ONE: a escrita é realizada com sucesso no commit log e na memtable de pelo menos um nó réplica. TWO: a escrita é realizada com sucesso no commit log e na memtable de pelo menos dois nós réplicas. THREE: a escrita é realizada com sucesso no commit log e na memtable de pelo menos três nós réplicas. QUORUM: a escrita é realizada com sucesso em um quorum de nós. Quorum = (replication_factor / 2) + 1 *rounded down.

15 Requisições de Escrita Níveis de consistência de escrita: LOCAL_QUORUM: a escrita é realizada com sucesso em um quorum de nós no mesmo Data Center do nó coordinator. EACH_QUORUM: a escrita é realizada com sucesso em um quorum de nós em cada Data Center. ALL: a escrita é realizada com sucesso em todos os nós réplicas. Se uma das réplicas não responder a operação de escrita é bloqueada ou falha.

16 Requisições de Escrita Hinted Handoff Para reduzir o tempo de restauração da consistência de um nó que falha após ele retornar ao cluster. Para garantir absoluta disponibilidade de escrita para aplicações não toleráveis a falha de escrita, mas toleráveis a inconsistência de leituras. Quando um réplica está indisponível no momento da escrita, uma réplica ativa armazena uma hint. Hints: A posição da réplica que está indisponível. A chave da row que será inserida posteriormente.

17 Requisições de Escrita Hinted Handoff Se o nível de consistência de escrita for ANY e todas as réplicas estiverem indisponíveis, a escrita pode ser executada com sucesso. Nesse caso as hints são armazenadas no nó coordinator, mas ficam indisponíveis para leitura até que as réplicas se tornem disponíveis e a escrita seja realizada nelas. O nó coordinator pode armazenar hints independente do nível de consistência, mas caso ele não consiga enviar a hint para as réplicas, caso elas demorem a ficar disponíveis, um TimeOutException é gerado, porém, para o Cassandra um timeout não é considerado falha para

18 Requisições de Escrita Hinted Handoff Por padrão as hints são armazenadas por uma hora, uma vez que se o tempo for maior que este o nó é considerado morto e nesse caso é necessário utilizar um repair para re-replicar os dados antes da falha ocorrer. Este tempo pode ser configurado através do parâmetro max_hint_window_in_ms no arquivo cassandra.yaml.

19 Requisições de Escrita

20 Requisições de Escrita em Múltiplos Data Centers

21 Requisições de Leitura Existem dois tipos de leituras que um nó coordinator pode enviar para uma réplica: Requisição direta de leitura A quantidade de réplicas contactadas por este tipo de leitura é determinada pelo nível de consistência especificado pelo cliente. Solicitação de repair de leitura em background Tais requisições são enviadas para quaisquer réplicas adicionais que não receberam uma requisição direta, elas garantem que a row requisitada se tornará consistente em todas as réplicas.

22 Requisições de Leitura Níveis de consistência de leitura: ONE: Retorna uma resposta da réplica mais próxima (determinada pelo snitch). Por padrão, um repair de leitura roda em background para tornar as outras réplicas consistentes.. TWO: Retorna o dado mais recente de duas das réplicas mais próximas. THREE: Retorna o dado mais recente de três das réplicas mais próximas. QUORUM: Retorna o registro com o timestamp mais recente, uma vez que um quorum de réplicas atendeu à solicitação.

23 Requisições de Leitura Níveis de consistência de leitura: LOCAL_QUORUM: Retorna o registro com o timestamp mais recente, uma vez que um quorum de réplicas do mesmo Data Center que o nó coordinator atendeu à solicitação. Evita a latência de comunicação entre os Data Centers. EACH_QUORUM: Retorna o registro com o timestamp mais recente, uma vez que um quorum de réplicas em cada Data Center do cluster atendeu à solicitação. ALL: Retorna o registro com o timestamp mais recente, uma vez que todas as réplicas atenderam à solicitação. A operação de leitura falhará se uma réplica não responder.

24 Requisições de Leitura

25 Hadoop Implementação do algorítmo MapReduce; Alta latência de análise e baixa latência de acesso em tempo real são necessárias; Limitações: Pesquisas repetitivas; Falta de controle de mapeamento e redução.

26 Hadoop Hadoop Distributed File System; Tolerância a falhas; Reiniciando tarefas; Replicação de dados. Não usado para leituras e escritas randômicas; Execução especulativa.

27 Hadoop

28 Hadoop Distributed File System (HDFS) Baseado no Google File System (GFS); Design: Falhas vão ocorrer; Arquivos serão grandes; Uma vez escritos e fechados, serão apenas lidos; Apenas um leitor por vez; Acesso garantido à banda para operações de baixa latência.

29 Hadoop Distributed File System (HDFS) Arquivos HDFS são unidos em blocos; Dois tipo de nó: NameNode, único, gerencia o namespace: caminho dos mapas de arquivo e nomes com blocos e suas localizações; DataNode, mantém blocos de dados e servidores de requisições r/w de clientes. Decide onde cada bloco de dado replicado é armazenado.

30 Hadoop Distributed File System (HDFS)

31 MapReduce Map; Transformar uma entrada de dados em uma saída chave/valor; Reduce; map(key1,value1) -> list<key2,value2> Pega todos os valores de uma chave específica e gera uma nova lista reducida como saída. reduce(key2, list<value2>) -> list<value3>

32 MapReduce Usualmente HDFS e MapReduce rodam no mesmo datacenter.

33 HBase Modelado a partir do Google BigTable; Roda em cima do HDFS sanando as mesmas necessidades do uso de BigTable pra Hadoop.

34 Pig Plataforma para análise de grandes blocos de dados; Linguagem de fluxo de dados orientado a "Pig Latin"; Funções de transformação de dados; Linguagem de alto nível para serialização de dados. Desenvolvido pelo Yahoo!

35 Pig Operações básicas; LOAD; FOREACH..GENERATE; GROUP; JOIN; DUMP/STORE.

36 Pig

37 Hive Baseado em SQL; Análise de grandes quantidades de dados; Processamento de log, mineração de textos, indexação de documentos... Desenvolvido pelo Facebook.

38 Mahout Componente do Hadoop; Oferece aprendizado; Exemplo: Recomendação de produtos. Gera um.txt da análise.

39 Sqoop Auxília a transferência de dados entre RDBMS, Hadoop e entre outros, como NoSQL.

40 Cassandra File System Compressão de blocos com google snappy (Zippy, compressão 250MB/s descompressão 500MB/s); Construido em ColumnFamilies inode e blocks. Dados gravados como ByteBuffer internamente.

41 HDFS vs CFS Cassandra File System provê uma armazenamento que torna Hadoopmais fácil e rápido de ser aplicado; Baseado em P2P, sem mestre; Completamente transparente, MapReduce, Hive, Pig, Mahout.

42 HDFS vs CFS Serviços do Hadoop são substituídos, (NameNode, SecundaryNameNode e DataNode); Armazenamento compartilhado não é mais necessário; Performance igual.

43 Referências 1. Cassandra 1.2 Documentation. com/docs/1.2/ 2. Cassandra Consistency level on Write and Read Cassandra integration with Hadoop. datastax.com/docs/datastax_enterprise2.2/solutions/hadoop_index 4. DataStax Combines Hadoop, Cassandra, Hive into One Happy Big Data Family. http: //

44 Referências 5. Cassandra The Definitive Guide - O' Reilly. 6. Artigos do DataStax.