Introdução ao HDFS
HDFS é um sistema de arquivos distribuído de alto rendimento, altamente tolerante a falhas, adequado para implantação em máquinas baratas.
Conceito de design HDFS
Suporte para conjuntos de dados muito grandes
Os aplicativos em execução no HDFS têm grandes conjuntos de dados. Um tamanho de arquivo típico em HDFS é geralmente entre G bytes e T bytes. Portanto, o HDFS foi projetado para oferecer suporte ao armazenamento de arquivos grandes, pode ser expandido para centenas de nós em um cluster e pode armazenar grandes quantidades de dados.
Por exemplo, você ainda usa o MySQL para armazenar 10 bilhões de dados em uma determinada tabela? Qual é a sua configuração para uma máquina e, em seguida, considere a eficiência da consulta. Se for utilizado armazenamento distribuído, ou seja, esses dados são armazenados em mais de N máquinas, e cada máquina armazena apenas parte desses 10 bilhões de dados, por exemplo, uma máquina armazena 5 milhões de dados, o posicionamento do HDFS é para este enorme armazenamento de conjunto de dados.
Erro de hardware
O HDFS pode consistir em centenas ou milhares de servidores, cada um dos quais armazena parte dos dados do sistema de arquivos. A probabilidade de falha da máquina que armazena esses dados ainda é bastante alta. Por exemplo, o disco está danificado, não pode ser lido ou gravado e a rede falha. Esta máquina não pode funcionar normalmente.
Portanto, a detecção de erros e a recuperação rápida e automática são os principais objetivos arquitetônicos do HDFS. Depois que o HDFS detecta um problema com uma máquina no cluster, ele pode se recuperar da falha.
Processamento de dados de streaming
Os aplicativos em execução no HDFS são diferentes dos aplicativos comuns que normalmente escrevemos. Quando o HDFS lê e grava dados no sistema de arquivos, é baseado no conceito de um fluxo. O chamado processamento de fluxo é para ler arquivos em lotes. Grave para garantir leitura e gravação de arquivo de alto rendimento, não leitura e gravação de arquivo de baixa latência.
O HDFS é usado em cenários de processamento em lote offline, especialmente o data warehouse offline atual, que é usado para análise de dados. Nossa análise offline atual é extrair os dados do sistema de origem para o HDFS no início desta manhã e, em seguida, o processamento envolve o processamento deste lote de dados por lote, em vez de calcular um por um.
Modelo de consistência de dados simplificado
Ao mesmo tempo, ele suporta a leitura e gravação de arquivos e precisa lidar com um grande número de conflitos de simultaneidade. Pense sobre os bloqueios de leitura e gravação adicionados ao conjunto de leitura e gravação ao escrever o código. t adicionar, haverá mais problemas. Para armazenamento distribuído de conjuntos de dados em grande escala, como HDFS, seu modelo deve ser simplificado. Seus arquivos podem ser gravados apenas uma vez e, em seguida, só podem ser anexados, e os dados anteriores não podem ser modificados casualmente.
Portanto, sua filosofia é: gravar uma vez, preparar várias vezes, gravar uma vez e, em seguida, ler várias vezes, de modo que não haja conflito de simultaneidade de leitura e gravação de dados e como manter a consistência dos dados.
Esse modelo de gravação única e leitura múltipla também pode melhorar muito a taxa de transferência do HDFS.
Computação móvel, não mova dados
Pense nisso, quando lemos dados, é mais rápido ler dados do disco local ou de outras máquinas da rede? Se os dados estiverem mais próximos da máquina, maior será a velocidade e maior será a eficiência.
Portanto, nos dados distribuídos em várias máquinas, para computação distribuída, você precisa tornar suas tarefas de computação mais próximas desses dados, em vez de transferir dados pela rede no cluster.
Arquitetura distribuída do modo mestre-escravo
NameNode soma DataNode
A arquitetura clássica em sistemas distribuídos é mestre-escravo. O HDFS usa essa arquitetura mestre-escravo. Um cluster HDFS é composto por um NameNode e vários DataNodes.
NameNode é um processo, processo JVM e também um sistema. Podemos pensar em NameNode como esse mestre (pode ser entendido como um grande administrador). Em um cluster HDFS comum, há apenas um NameNode. É responsável por gerenciar o namespace do sistema de arquivos e o acesso do cliente aos arquivos.
DataNode também é um processo.Cada máquina do cluster possui um processo DataNode, que é o principal responsável pelo armazenamento dos dados na máquina.
Namespace do sistema de arquivos
Namespace, como entender? No que diz respeito à pasta do nosso computador, os dados armazenados estão neste diretório -> método de arquivo, e o diretório pode ser o próximo nível do diretório.
Por exemplo, a seguinte estrutura de diretório em meu computador, / documents / data warehouse / Este diretório tem o método de construção de arquivo de data warehouse xxx.doc e o diretório / 12_data, diretório / 12_data tem 04_big estrutura técnica do sistema de dados xxx .doc Esses documentos.
Portanto, o relacionamento correspondente entre a estrutura hierárquica do sistema de arquivos e os arquivos é o denominado Filesystem Namspace, que é armazenado no NameNode.
bloco bloco de arquivo
Em um cluster HDFS, um arquivo grande será dividido em N blocos múltiplos para divisão e armazenado em máquinas diferentes. Por exemplo, se houver um arquivo grande de 1G, o HDFS irá dividi-lo, por exemplo, 128M, então ele será dividido em 8 blocos de arquivos, e depois colocado em uma máquina diferente, ou seja, o DataNode, o DataNode é o responsável Store esses blocos de arquivo.
O NameNode sabe em quantos blocos de arquivo um arquivo está dividido e em qual DataNode cada bloco de arquivo está armazenado, portanto, o NameNode é o administrador mestre de um cluster HDFS.
Quando você quiser ler o arquivo grande acima, você primeiro perguntará ao gerenciador do NameNode, a qual bloco de arquivo o arquivo corresponde e onde cada bloco de arquivo está localizado, e então o NameNode informa quais DataNodes estão ativados, então você pode ir para o DataNode correspondente.
Mecanismo de gerenciamento de persistência de metadados do sistema de arquivos
Editlog e FsImage
O HDFS é armazenado no NameNode. Para qualquer operação de modificação nos metadados do sistema de arquivos, o NameNode gravará as operações uma a uma em um log de operação chamado EditsLog.
Por exemplo, se um arquivo for criado no HDFS, Namenode irá inserir um registro no Editlog para indicá-lo; da mesma forma, modificar o coeficiente de cópia do arquivo também irá inserir um registro no Editlog. Namenode armazena este Editlog no sistema de arquivos do sistema operacional local. Crie um diretório em hdfs, hadoop fs -mkdir -p / usr / dir1, crie uma hierarquia de diretório
Em seguida, toda a estrutura de organização do sistema de arquivos, incluindo bloco de dados para mapeamento de arquivo, atributos de arquivo, etc., são armazenados em um arquivo chamado FsImage, que também é colocado no sistema de arquivos local onde o Namenode está localizado.
Antes que o NameNode armazene os metadados no arquivo FsImage, eles serão armazenados na memória por um período de tempo.Se o arquivo for gravado toda vez que os metadados forem alterados, o desempenho será muito ruim. Portanto, o NameNode lerá o arquivo Editlog no disco de vez em quando, aplicará tudo isso ao cache fsimage na memória e, em seguida, despejará o fsimage no disco novamente e salvará o arquivo Editlog aplicado anteriormente Esvaziar .
operação de checkpoint
Acima, o editlog é lido do disco e aplicado ao FsImage, e então o FsImage é salvo no disco e, finalmente, o Editslog é excluído. Esta operação é chamada de ponto de verificação. Podemos configurar o intervalo do ponto de verificação por nós mesmos e iniciar no NameNode No momento, ele também lerá primeiro o log de edições e Fsimage do disco para construir dados em cache na memória.
dfs.namenode.checkpoint.period：这个参数配置几秒钟执行一次checkpoint
dfs.namenode.checkpoint.txns：这个参数配置当edits log里有多少条数据的时候，就执行一次checkpoint
复制代码
SecondaryNameNode e BackupNode na era hadoop 1.x
SecondaryNameNode
Na era do Hadoop 1.x, quando NameNode foi iniciado, FsImage foi lido na memória e, em seguida, o conteúdo do log de EditsLog foi restaurado para fsimgae, mantendo os metadados na memória atualizados e, em seguida, gravando o último fsimage. Vá para o disco e, finalmente, limpe o arquivo Editlog.
Em seguida, o cliente está operando continuamente o cluster HDFS, e os metadados do NameNode serão continuamente modificados. Essas modificações são para modificar diretamente o cache FsImage na memória, e o arquivo de log para modificar os metadados será anexado ao log de edições arquivo.
Há um problema. O registro de modificação de metadados sempre será anexado ao arquivo de registro de edições. Se for anexado o tempo todo, ficará cada vez maior. Não estará disponível até a próxima reinicialização do NameNode e o registro de edições mesclar com fsimage. Vazio. Se o registro de edições for grande, levará muito tempo para mesclar, o que pode fazer com que a inicialização do NameNode se torne cada vez mais lenta.
Portanto, uma maneira de pensar é mesclar o log de edições e fsimage regularmente. Após a mesclagem, grave o novo fsimage no disco e limpe o log de edições ao mesmo tempo, para que o log de edições não fique muito grande.
Portanto, hdfs tem outra função como NameNode Secundário, ele será implantado em outra máquina, será dedicado a mesclar o log de edições e fsimage, execute-o toda vez, quando for executado, diga ao NameNode para não gravar o log de edições atual Agora, abra um novo registro de edições para escrever. Em seguida, extraia o arquivo fsimage e edita o log do NameNode para o local, mescle-os na memória e envie-os para o NameNode após a conclusão da mesclagem.
Esta operação é chamada de operação de ponto de verificação, para que o registro de edições não seja muito grande.
BackupNode
BackupNode também é um mecanismo fornecido no Hadoop 1.x. Sua ideia é otimizar e substituir a ideia mesclada do ponto de verificação de baixar o log de edições e fsimage.
A ideia do nó de backup é armazenar uma cópia dos dados fsimage da mesma forma que o namenode na memória e, ao mesmo tempo, receber o fluxo de dados do log de edições enviado pelo NameNode e gravar um em seu próprio log de edições local após obter o fluxo de dados do log de edições.
Ao mesmo tempo, o log de edições será reproduzido na imagem da imagem na memória do usuário, de forma que a imagem na memória seja igual à imagem na memória do namenode.
O nó de backup também executará periodicamente uma operação de ponto de verificação, gravará o fsimage em sua memória, desta vez em seu próprio disco, substituirá o arquivo fsimage antigo e, em seguida, limpará o log de edições.
Um NameNode só pode ser vinculado a um nó de backup. A vantagem de usar um nó de backup é que você não precisa permitir que o namenode mantenha esse arquivo de log de edições e não precisa gravar no disco sozinho. Basta manter o fsimage em sua própria memória e recebê-lo todas as vezes. Quando você precisar de uma operação para modificar os metadados, aplique-o ao fsimage em sua memória e, ao mesmo tempo, envie o fluxo de dados do log de edição para o nó de backup.
Cada vez que o namenode é reiniciado, você precisa usar -importCheckpoint para carregar fsimage de outros lugares em seu próprio desta vez, e esses dados -importCheckpoint são obtidos do nó de backup.
Acima está o gerenciamento de metadados no Hadoop 1.x. O Hadoop 2.x não é mais tão divertido.
Mecanismo de alta disponibilidade HA de instância dupla na era hadoop 2.x
Defeitos de gerenciamento de metadados do Hadoop 1.x
Na era do Hadoop 1.x, NameNode vinculado a um NameNode secundário para gerenciar metadados causará perda de metadados e problemas de alta disponibilidade.
Problemas de alta disponibilidade. Assim que o NameNode falhar ou cair, todo o cluster ficará indisponível. Problema de perda de dados. Se o disco do NamaNode estiver danificado, isso causará uma certa perda de dados. O registro de edições após o último ponto de verificação será perdido.
No Hadoop 2.x, o problema de perda de metadados e alta disponibilidade foi resolvido.
Então NameNode
O cluster do Hadoop 2.x iniciará dois NameNodes, um no estado ativo e outro no estado de espera. Podemos entender que o estado ativo é o mestre e o estado de espera é o modo de espera. Todas as operações do cliente são enviadas para o NameNode no estado ativo e o NameNode no estado de espera será usado como um modo de espera ativo para o NameNode ativo para sincronizar continuamente os metadados.
Nó de diário
O NameNode no estado de espera não solicita metadados diretamente do NameNode. Há também um intermediário, o Journal Node, que armazena o log de edições. Geralmente, o Journal Node também é um cluster, começando com três.
Quando o NameNode tiver alterações de metadados, ele gravará o log de edições na maioria dos nós no cluster de nós do Diário. Por exemplo, agora existem 3 clusters de Journal Node e a maioria dos nós é 3/2 + 1 = 2. Ou seja, se o NameNode grava o log de edições em 2 clusters, a gravação é considerada bem-sucedida.
Em seguida, StandbyNameNode sempre monitorará as alterações do log de edições no JournalNode. Enquanto houver alterações, ele puxará o novo log de edições para o local e, em seguida, aplicará em sua própria memória, mantendo-o consistente com o NameNode ativo.
Quando o NameNode ativo desliga, o NameNode em espera o perceberá imediatamente e, em seguida, certifique-se de que lê todos os logs de edição do nó de diário, e o fsimage na memória também é os dados mais recentes e, em seguida, muda para o ativo NameNode.
Desta forma, o problema de perda de dados é resolvido: uma máquina fica inativa e a outra máquina é imediatamente alternada para o namenode ativo para continuar a fornecer serviços para o mundo exterior, e o problema de alta disponibilidade também é resolvido.
ZKFC (ZKFailoverController)
Então, como dois NameNodes mudam automaticamente depois que um falha.
Ele se baseia no processo ZKFailoverController, abreviado ZKFC. Cada NameNode terá um processo ZKFC. Eles monitorarão constantemente o status dos dois NameNodes e manterão o status dos dois NameNodes no Zookeeper.
Se o NameNode ativo estiver inativo, o HealthMonitor no ZKFC irá monitorá-lo e, em seguida, o FailoverController no ZKFC notificará o NameNode que ele está inativo e, em seguida, o FailoverController encontrará um componente ActiveStandbyElector para reeleição.
ActiveStandbyElector irá reeleger um NameNode em espera como o NameNode principal baseado em zk.
Em seguida, zk notificará o componente ActiveStandbyElector em ZKFC no NameNode em espera, notificará o FailoverController para alternar o estado de espera para o estado ativo e, em seguida, o FailoverController para notificar o NameNode para alternar para o NameNode ativo.
Desta forma, é possível alternar entre ativo e standby, e HA é realizado.
Como a instância dupla HA do Hadoop 2.x gerencia metadados
No Hadoop 1.x, o nó de backup executará periodicamente uma operação de ponto de verificação, gravará o fsimage em sua memória desta vez em seu próprio disco, substituirá o arquivo fsimage antigo e, em seguida, limpará o log de edições.
No Hadoop 2.x, o Standby NameNode é realmente semelhante ao nó de backup no 1.x e executará uma operação de ponto de verificação regularmente.
O Standby NameNode executará um thread de segundo plano chamado CheckpointerThread, que é uma vez por hora por padrão, ou se 1 milhão de logs de edição não forem mesclados em fsimage, uma operação de ponto de verificação será executada.
Grave o fsimage mais recente na memória no disco, limpe o log de edições e, finalmente, envie o arquivo fsimage mais recente para o NameNode ativo, substituindo o antigo fsimage do NameNode ativo e também limpe o arquivo de log de edições antigo no NameNode ativo.
Mecanismo de armazenamento distribuído para dados de arquivos grandes
Se você precisar fazer upload de um arquivo muito grande, quando o cliente hdfs enviar o comando de upload, o NameNode primeiro dividirá o arquivo em vários blocos de acordo com o tamanho do arquivo. 2.x padrão é 128 M, 1.x 64 M.
O NameNode planejará em qual DataNode cada arquivo de bloco será armazenado. Ele distribuirá os dados o máximo possível de acordo com a situação de armazenamento de dados de cada DataNode, e então o cliente hdfs fará o upload do bloco de arquivo para cada DataNode. Após o DataNode recebe os dados, armazenará esses blocos de arquivos em diferentes diretórios de arquivos, estabelecerá uma certa estrutura hierárquica para armazenar esses blocos de arquivos e não os colocará em uma pasta.
Quando o DataNode é iniciado, ele também verifica seu diretório de dados de arquivo local e relata ao NameNode a lista de bloqueio de arquivos que ele mantém.
Mecanismo de tolerância a falhas baseado em cópia
Para armazenar um arquivo grande com base na divisão de blocos, o problema de armazenamento está resolvido e não há nada de errado com ele. Mas há outro problema. Se uma máquina ficar inativa, como consumo excessivo de recursos, tempo de inatividade ou reinicialização, o bloco armazenado nesta máquina não pode ser acessado. Originalmente, um arquivo é dividido em Existem 10 blocos, e agora um é defeituoso e há apenas 9 blocos normais. Então, quando o cliente lê, seus dados estão incompletos.
Mecanismo de cópia
Então, como resolver as várias falhas de máquina entre os clusters acima para tolerância a falhas, a resposta é o mecanismo de cópia.
Existe um parâmetro no HDFS chamado fator de replicação, o que significa que cada bloco será copiado para você e colocado em máquinas diferentes. O tempo de inatividade de uma máquina não afetará e a outra máquina terá exatamente o mesmo backup.
Quando o HDFS grava um arquivo, cada bloco tem 3 cópias por padrão. O NameNode selecionará primeiro 3 DataNodes. Cada DataNode colocará um bloco e o retornará ao cliente. Em seguida, o cliente transmitirá o bloco para o primeiro DataNode. Após um DataNode grava este bloco no local, este DataNode irá copiar o bloco para o segundo DataNode. Depois que o segundo DataNode gravar no local, ele copiará o bloco para o terceiro DataNode.
Conscientização de Rack
A comunicação entre as máquinas no cluster HDFS é para comunicar. As máquinas e as máquinas podem existir em racks diferentes. A transmissão de dados entre as máquinas no mesmo rack é definitivamente mais rápida do que as máquinas em racks diferentes.
Um bloco geralmente tem 3 cópias por padrão, então o NameNode colocará 2 cópias em uma máquina em um rack e uma cópia em uma máquina em outro rack.
A transmissão de dados em um mesmo rack é muito rápida.Outro ponto é que mesmo que todas as máquinas do seu rack estejam desligadas, as máquinas do outro rack terão uma cópia deste bloco, que pode atender normalmente.
Modo de segurança
Quando o NameNode é iniciado, ele entrará em um modo denominado modo seguro, modo seguro, neste modo, o cluster hdfs não executará a replicação de bloco
Neste momento, o NameNode aguardará para obter o relatório de pulsação e bloqueio de cada DataNode e, em seguida, examinará a situação geral do bloco no cluster e quantas cópias de cada bloco, o padrão é ter 3 cópias, se um bloco tem 3 cópias, então está tudo bem, seguro
Se uma certa porcentagem (80%) do bloco tiver 3 cópias suficientes, o namenode sairá do modo de segurança.
NameNode sempre esteve em modo de segurança porque não atingiu uma determinada proporção. Por exemplo, apenas 50% dos blocos têm 3 cópias.
Neste momento, se for descoberto que o número de cópias de um determinado bloco não é suficiente (por exemplo, existem apenas 2 cópias), instrua o DataNode a replicar cópias suficientes
Mecanismo federal
Todos os arquivos, diretórios e informações de configuração no HDFS são armazenados no NameNode. Quando o cluster HDFS tem dezenas de milhares e centenas de milhares de unidades, a quantidade de dados é extremamente grande e o tamanho dos seus metadados pode ser de centenas de gigabytes Obviamente, não é viável em um NameNode.
Para resolver este problema, o HDFS desenvolveu um mecanismo de federação, ou seja, existem vários NameNodes em um cluster, e cada NameNode armazena uma parte dos metadados. Não importa como os metadados aumentam, a máquina NameNode pode ser dimensionada horizontalmente para resolver o problema. A situação é que muitas empresas simplesmente não usam esse mecanismo federal e não têm esse tamanho.
No mecanismo de federação, cada NameNode ativo armazena parte dos metadados e, em seguida, um NameNode em espera é anexado a cada NameNode ativo.Assim, os problemas de expansão horizontal e alta disponibilidade são resolvidos.
Embora existam vários NameNodes, ainda há um conjunto de DataNodes e os blocos são armazenados em um cluster DataNode.Isso significa apenas que cada DataNode relatará sua pulsação e relatório de bloco para todos os NameNodes.
hdfs-11.png
me siga
** Que você experimente os fogos de artifício e ainda acredite que o mundo vale a pena! **
Link original: https://juejin.cn/post/6915947365648039950
Se você acha que este artigo é útil para você, pode seguir minha conta oficial e responder à palavra-chave [Entrevista] para obter uma compilação de pontos de conhecimento do núcleo de Java e um pacote de presente para entrevista! Existem mais artigos técnicos e materiais relacionados para compartilhar. Deixe que todos aprendam e progridam juntos!
