Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.

Nesta página

Mostrar todos

Central de ajuda/ MapReduce Service/ Visão geral de serviço/ Componentes/ HDFS/ Princípios básicos do HDFS

Princípios básicos do HDFS

Atualizado em 2023-05-19 GMT+08:00

Ver PDF

O Hadoop Distributed File System (HDFS) implementa leitura/gravação confiável e distribuída de grandes quantidades de dados. O HDFS é aplicável ao cenário em que os recursos de leitura/gravação de dados "gravar uma vez e ler várias vezes". No entanto, a operação de gravação é executada em sequência, ou seja, é uma operação de gravação realizada durante a criação do arquivo ou uma operação de adição realizada por trás do arquivo existente. O HDFS garante que apenas um chamador possa executar a operação de gravação em um arquivo, mas vários chamadores possam executar a operação de leitura no arquivo ao mesmo tempo.

Arquitetura

O HDFS consiste em NameNodes ativos e em espera e vários DataNodes como mostrado em Figura 1.

O HDFS funciona em arquitetura principal/secundário. O NameNodes é executado no nó principal (ativo) e o DataNodes é executado no nó secundário (em espera). O ZKFC deve ser executado junto com o NameNodes.

A comunicação entre NameNodes e DataNodes é baseada no Protocolo de Controle de Transmissão (TCP)/Protocolo de Internet (IP). O NameNode, DataNode, ZKFC e JournalNode podem ser implantados em servidores do Linux.

Figura 1 Arquitetura do HDFS de HA
Clique para ampliar

Tabela 1 descreve as funções de cada módulo mostrado em Figura 1.

**Tabela 1** Descrição de módulo
Módulo	Descrição
NameNode	Um NameNode é usado para gerenciar o namespace, estrutura de diretórios e informações de metadados de um sistema de arquivos e fornecer o mecanismo de backup. O NameNode é classificado nos dois tipos seguintes: NameNode ativo: gerencia o namespace, mantém a estrutura de diretórios e metadados dos sistemas de arquivos e registra as relações de mapeamento entre blocos de dados e arquivos aos quais os blocos de dados pertencem. NameNode em espera: sincroniza com os dados no NameNode ativo e assume os serviços do NameNode ativo quando o NameNode ativo está com defeito. NameNode de observador: sincroniza com os dados no NameNode ativo e processa solicitações de leitura do cliente.
DataNode	Um DataNode é usado para armazenar blocos de dados de cada arquivo e relatar periodicamente o status de armazenamento para o NameNode.
JournalNode	No cluster de HA, sincroniza metadados entre os NameNodes ativos e em espera.
ZKFC	ZKFC deve ser implantado para cada NameNode. Ele monitora o status do NameNode e grava informações de status em ZooKeeper. ZKFC também tem permissões para selecionar o NameNode ativo.
ZK Cluster	ZooKeeper é um serviço de coordenação que ajuda o ZKFC a eleger o NameNode ativo.
HttpFS gateway	HttpFS é um processo de gateway sem estado único que fornece a API REST WebHDFS para processos externos e a API de FileSystem para o HDFS. HttpFS é usado para transmissão de dados entre diferentes versões do Hadoop. Ele também é usado como um gateway para acessar o HDFS por trás de um firewall.

Arquitetura do HDFS de HA
HA é usado para resolver o problema SPOF do NameNode. Este recurso fornece um NameNode em espera para o NameNode ativo. Quando o NameNode ativo está com defeito, o NameNode em espera pode rapidamente assumir o fornecimento contínuo de serviços para sistemas externos.

Em um cenário típico de HA do HDFS, geralmente há dois NameNodes. Um está no estado ativo e o outro no estado de espera.

Um sistema de armazenamento compartilhado é necessário para suportar a sincronização de metadados dos NameNodes ativa e em espera. Esta versão fornece a solução de HA do Quorum Journal Manager (QJM), conforme mostrado em Figura 2. Um grupo de JournalNodes é usado para sincronizar metadados entre os NameNodes ativos e em espera.

Geralmente, um número ímpar (2N+1) de JournalNodes é configurado e pelo menos três JournalNodes são necessários. Para uma mensagem de atualização de metadados, a gravação de dados é considerada bem-sucedida desde que a gravação de dados seja bem-sucedida no JournalNodes N+1. Neste caso, é permitida uma falha de gravação de dados de no máximo N JournalNodes. Por exemplo, quando há três JournalNodes, a falha de gravação de dados de um JournalNode é permitida; quando há cinco JournalNodes, a falha de gravação de dados de dois JournalNodes é permitida.

O JournalNode é um processo de daemon leve e compartilha um host com outros serviços do Hadoop. Recomenda-se que o JournalNode seja implementado no nó de controle para evitar falhas na gravação de dados no JournalNode.

Figura 2 Arquitetura do HDFS baseada em QJM

Princípio

O MRS usa o mecanismo de cópia do HDFS para garantir a confiabilidade dos dados. Um arquivo de backup é gerado automaticamente para cada arquivo salvo no HDFS, ou seja, duas cópias são geradas no total. O número de cópias do HDFS pode ser consultado usando o parâmetro dfs.replication.

Quando a especificação de nó central do cluster de MRS está definida como unidade de disco rígido não local (HDD) e o cluster tem apenas um nó central, o número padrão de cópias de HDFS é 1. Se o número de nós centrais no cluster for maior ou igual a 2, o número padrão de cópias de HDFS será 2.
Quando a especificação do nó central do cluster do MRS é definida como disco local e o cluster tem apenas um nó central, o número padrão de cópias de HDFS é 1. Se houver dois nós centrais no cluster, o número padrão de cópias do HDFS é 2. Se o número de nós centrais no cluster for maior ou igual a 3, o número padrão de cópias HDFS será 3.

Figura 3 Arquitetura do HDFS
Clique para ampliar

O componente do HDFS do MRS suporta os seguintes recursos:

Suporta código de eliminação, reduzindo a redundância de dados para 50% e melhorando a confiabilidade. Além disso, a estrutura de armazenamento de blocos distribuídos é introduzida para maximizar o uso da capacidade de um único nó e vários discos em um cluster existente. Depois que o processo de codificação é introduzido, o desempenho de gravação de dados é melhorado e o desempenho é próximo ao da redundância de multi-cópias.
Suporta programação balanceada de nó em HDFS e programação balanceada de disco em um único nó, melhorando o desempenho do armazenamento do HDFS após escalabilidade de nó ou disco.

Para obter detalhes sobre a arquitetura e os princípios do Hadoop, consulte https://hadoop.apache.org/.

Tópico principal: HDFS

Tópico anterior: HDFS

Próximo tópico: Solução HA do HDFS

Feedback

Esta página foi útil?

Sim Não

Deixar um comentário

Obrigado por seus comentários. Estamos trabalhando para melhorar a documentação.

O sistema está ocupado. Tente novamente mais tarde.

Quais dos seguintes problemas você encontrou?

O conteúdo é inconsistente com a UI do produto

Descrições pouco claras

Falta de exemplos ou código

Passos incorretos

Não encontro o que preciso

Falta de melhores práticas

Feedback (opcional)

0/500

Selecione pelo menos um tipo de problema e insira seus comentários ou sugestões.

Insira um máximo de 500 caracteres.

Enviar Cancelar