Princípios básicos do HDFS
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.
Tabela 1 descreve as funções de cada módulo mostrado em Figura 1.
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:
|
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.
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.
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/.