Recursos de código aberto aprimorados do HDFS

Recurso de código aberto aprimorado: colocação de bloco de ficheiros

No cenário resumo de dados off-line e estatísticas, Join é uma função de computação usada com frequência e é implementada no MapReduce da seguinte maneira:

1. A tarefa Map processa os registros nos dois arquivos de tabela em Join Key e Value, executa o particionamento de hash por Join Key e envia os dados para diferentes tarefas Reduce para processamento.
2. As tarefas Reduce lêem dados na tabela à esquerda recursivamente no modo de loop aninhado e percorra cada linha da tabela à direita. Se os valores da chave de junção forem idênticos, os resultados da junção serão de saída.

   O método anterior reduz drasticamente o desempenho do cálculo da junção. Como uma grande quantidade de transferência de dados de rede é necessária quando os dados armazenados em nós diferentes são enviados do MAPA para Reduzir, como mostrado em Figura 1.

Figura 1 Transmissão de dados no cenário de não-colocação

As tabelas de dados são armazenadas no sistema de arquivos físico pelo bloco HDFS. Portanto, se dois blocos a serem juntados forem colocados no mesmo host de acordo depois que forem particionados pela chave de junção, você poderá obter os resultados diretamente da junção de Map no nó local sem qualquer transferência de dados no processo de redução do cálculo da junção. Isso vai melhorar muito o desempenho.

Com o mesmo recurso de distribuição dos dados do HDFS, um mesmo ID de distribuição é alocado para arquivos, FileA e FileB, nos quais os cálculos de associação e somatória precisam ser executados. Dessa forma, todos os blocos são distribuídos juntos e o cálculo pode ser feito sem recuperar dados entre nós, o que melhora muito o desempenho da junção de MapReduce.

Figura 2 Distribuição de blocos de dados em cenários de colocação e não-colocação

Recurso de código aberto aprimorado: configuração de volume de disco rígido danificado

Na versão de código aberto, se vários volumes de armazenamento de dados forem configurados para um DataNode o DataNode deixará de fornecer serviços por padrão se um dos volumes estiver danificado. Se o item de configuração dfs.datanode.failed.volumes.tolerated é definido para especificar o número de volumes danificados permitidos, o DataNode continua a fornecer serviços quando o número de volumes danificados não excede o limite.

O valor de dfs.datanode.failed.volumes.tolerated varia de -1 ao número de volumes de disco configurados no DataNode. O valor padrão é -1, como mostrado em Figura 3.

Figura 3 Item sendo definido como 0

Por exemplo, três volumes de armazenamento de dados são montados em um DataNode e dfs.datanode.failed.volumes.tolerated é definido como 1. Nesse caso, se um volume de armazenamento de dados do DataNode não estiver disponível, esse DataNode ainda poderá fornecer serviços, conforme mostrado em Figura 4.

Figura 4 Item sendo definido como 1

Este item de configuração nativa tem alguns defeitos. Quando o número de volumes de armazenamento de dados em cada DataNode é inconsistente, é necessário configurar cada DataNode independentemente em vez de gerar o arquivo de configuração unificado para todos os nós.

Suponha que existem três DataNodes em um cluster. O primeiro nó tem três diretórios de dados, o segundo nó tem quatro e o terceiro nó tem cinco. Se quiser garantir que os serviços de DataNode estejam disponíveis quando apenas um diretório de dados estiver disponível, você precisa executar a configuração conforme mostrado em Figura 5.

Figura 5 Configuração de atributos antes de ser aprimorada

No HDFS aprimorado auto-desenvolvido, esse item de configuração é aprimorado, com um valor -1 adicionado. Quando este item de configuração é definido como -1, todos os DataNodes podem fornecer serviços, desde que um volume de armazenamento de dados em todos os DataNodes esteja disponível.

Para resolver o problema no exemplo anterior, defina essa configuração como -1, conforme mostrado em Figura 6.

Figura 6 Configuração de atributo após ser aprimorada

Recurso de código aberto aprimorado: aceleração de inicialização do HDFS

No HDFS, quando o NameNodes é iniciado, o arquivo de metadados FsImage precisa ser carregado. Em seguida, o DataNodes reportará as informações do bloco de dados após a inicialização do DataNodes. Quando as informações do bloco de dados reportadas pelo DataNodes atingem a porcentagem predefinida, o NameNodes sai do modo de segurança para concluir o processo de inicialização. Se o número de arquivos armazenados no HDFS atingir o nível de milhões ou bilhões, os dois processos são demorados e levarão a um longo tempo de inicialização do NameNode. Portanto, esta versão otimiza o processo de carregamento de FsImage de arquivos de metadados.

No HDFS de código aberto, o FsImage armazena todos os tipos de informações de metadados. Cada tipo de informação de metadados (como informações de metadados de arquivo e informações de metadados de pasta) é armazenada em um bloco de seção, respectivamente. Esses blocos de seção são carregados no modo serial durante a inicialização. Se um grande número de arquivos e pastas estiverem armazenados no HDFS, o carregamento das duas seções é demorado, prolongando o tempo de inicialização do HDFS. O NameNode do HDFS divide cada tipo de metadados por segmentos e armazena os dados em várias seções ao gerar os arquivos FsImage. Quando o NameNodes é iniciado, as seções são carregadas no modo paralelo. Isso acelera a inicialização do HDFS.

Recurso de código aberto aprimorado: políticas de colocação de blocos baseadas em rótulo (HDFS Nodelabel)

Você precisa configurar os nós para armazenar blocos de dados de arquivos do HDFS com base em recursos de dados. É possível configurar uma expressão de rótulo para um diretório ou arquivo do HDFS e atribuir um ou mais rótulos a um DataNode para que os blocos de dados do arquivo sejam armazenados em DataNodes especificados. Se a política de posicionamento de bloco de dados baseada em rótulo for usada para selecionar DataNodes para armazenar os arquivos especificados, o intervalo do DataNode será especificado com base na expressão de rótulo. Em seguida, os nós adequados são selecionados a partir do intervalo especificado.

• Você pode armazenar as réplicas de blocos de dados nos nós com rótulos diferentes de acordo. Por exemplo, armazene duas réplicas do bloco de dados para o nó rotulado com L1 e armazene outras réplicas do bloco de dados para os nós rotulados com L2.
• Você pode definir a política em caso de falha de posicionamento de bloco, por exemplo, selecione um nó de todos os nós aleatoriamente.

Figura 7 dá um exemplo:

• Os dados em /HBase são armazenados em A, B e D.
• Os dados em /Spark são armazenados em A, B, D, E e F.
• Os dados em /user são armazenados em C, D e F.
• Os dados em /user/shl são armazenados em A, E e F.

Figura 7 Exemplo de política de posicionamento de bloco baseada em rótulo

Recurso de código aberto aprimorado: HDFS Load Balance

As políticas atuais de leitura e gravação do HDFS são principalmente para otimização local sem considerar a carga real de nós ou discos. Com base nas cargas de I/O de diferentes nós, o balanceamento de carga do HDFS garante que, quando as operações de leitura e gravação forem executadas no cliente HDFS, o nó com baixa carga de I/O é selecionado para executar tais operações para equilibrar a carga de I/O e utilizar totalmente a taxa de transferência geral do cluster.

Se o HDFS Load Balance estiver ativado durante a gravação do arquivo, o NameNode selecionará um DataNode (na ordem de nó local, rack local e rack remoto). Se a carga de I/O do nó selecionado for pesada, o NameNode escolherá outro DataNode com carga mais leve.

Se o HDFS Load Balance estiver ativado durante a leitura do arquivo, um cliente de HDFS enviará uma solicitação ao NameNode para fornecer a lista de DataNodes que armazenam o bloco a ser lido. O NameNode retorna uma lista de DataNodes ordenados por distância na topologia de rede. Com o recurso de HDFS Load Balance, os DataNodes na lista também são classificados por sua carga de I/O. Os DataNodes com carga pesada estão na parte inferior da lista.

Caraterísticas de código aberto aprimoradas: movimentação automática de dados do HDFS

O Hadoop tem sido usado para processamento em lote de imensos dados há muito tempo. O modelo do HDFS existente é usado para atender muito bem às necessidades das aplicações de processamento em lote, porque essas aplicações se concentram mais na taxa de transferência do que no atraso.

No entanto, como o Hadoop é cada vez mais usado para aplicações de camada superior que exigem acesso aleatório frequente de I/O, como Hive e HBase, discos de baixa latência, como discos de estado sólido (SSD), são favorecidos em cenários sensíveis a atrasos. Para atender à tendência, o HDFS suporta uma variedade de tipos de armazenamento. Os usuários podem escolher um tipo de armazenamento de acordo com suas necessidades.

As políticas de armazenamento variam dependendo da frequência com que os dados são usados. Por exemplo, se os dados acessados com frequência no HDFS forem marcados como ALL_SSD ou HOT, os dados acessados várias vezes poderão ser marcados como WARM e os dados raramente acessados (apenas acesso uma ou duas vezes) poderão ser marcados como COLD. Você pode selecionar diferentes políticas de armazenamento de dados com base na frequência de acesso aos dados.

No entanto, os discos de baixa latência são muito mais caros do que os discos giratórios. Os dados geralmente apresentam um uso inicial intenso com declínio no uso ao longo de um período de tempo. Portanto, pode ser útil se os dados que não são mais usados forem movidos de discos caros para mídias de armazenamento mais baratas.

Um exemplo típico é o armazenamento de registros detalhados. Novos registros de detalhes são importados para o SSD porque são frequentemente consultados por aplicações de camada superior. À medida que a frequência de acesso a esses registros detalhados diminui, eles são movidos para um armazenamento mais barato.

Antes que a movimentação automática de dados seja alcançada, você precisa determinar manualmente por tipo de serviço se os dados são usados com frequência, definir manualmente uma política de armazenamento de dados e acionar manualmente a ferramenta HDFS Auto Data Movement, conforme mostrado na figura abaixo.

Se os dados envelhecidos puderem ser identificados automaticamente e transferidos para armazenamento mais barato (como disco/arquivamento), você verá cortes significativos de custos e melhoria da eficiência do gerenciamento de dados.

Com o recurso de movimentação automática de dados do HDFS, você só precisa definir a idade com base nas regras de tempo de acesso. A ferramenta HDFS Auto Data Movement combina dados de acordo com regras baseadas em idade, define políticas de armazenamento e move dados. Dessa forma, a eficiência do gerenciamento de dados e a eficiência dos recursos do cluster são aprimoradas.