No HDFS , sejam leituras locais ( DFSClient e Datanode estão no mesmo nó) ou leituras ( DFSClient e Datanode não estão no mesmo nó), o método de processamento subjacente é o mesmo e os dados são lidos primeiro pelo Datanode , e em seguida, por meio de RPC (baseado em TCP ), passe os dados para DFSClient . Esse processamento é relativamente simples, mas o desempenho será afetado, pois o Datanode precisa fazer uma transferência no meio.

Especialmente para leituras locais , como o DFSClient e os dados estão na mesma máquina, a ideia natural é deixar o DFSClient ignorar o Datanode para ler os dados sozinho . As chamadas leituras de "curto-circuito" ignoram o DataNode , permitindo que os clientes leiam o arquivo diretamente. Obviamente isso só funciona se o cliente estiver na mesma máquina que os dados. As leituras de curto-circuito proporcionam ganhos de desempenho significativos para muitas aplicações.

1.2 O design e implementação da versão antiga

HDFS-2246 Neste JIRA, a ideia dos engenheiros é que como os dados lidos do DFSClient e os dados estão na mesma máquina, o Datanode irá ler o caminho dos dados no sistema de arquivos, por onde iniciar a leitura (offset ) e quanto ler (comprimento) e outras informações para informar ao DFSClient e, em seguida , ao DFSClient para abrir o arquivo e lê-lo sozinho .

A ideia é boa, o problema está nas complexas questões de configuração e segurança.

A primeira é a questão da configuração, pois o DFSClient serve para abrir o arquivo para ler os dados sozinho, então é necessário configurar uma lista branca para definir quais usuários terão acesso ao diretório de dados do Datanode .

Se um novo usuário ingressar, a lista de permissões deverá ser modificada. Ressalta-se que este é o diretório de dados que permite ao cliente acessar o Datanode , o que significa que qualquer usuário com esta permissão pode acessar outros dados do diretório, o que leva a uma falha de segurança .

Portanto, esta implementação está obsoleta .

1.3 Projeto e implementação de versão de segurança aprimorada

No HDFS-347, uma nova solução é proposta para tornar a leitura local de dados em curto-circuito mais segura . No Linux , existe uma tecnologia chamada Unix Domain Socket . Unix Domain Socket é um método de comunicação entre processos , que permite que dois processos na mesma máquina se comuniquem na forma de Socket . Outro grande benefício que traz é que dois processos podem usá-lo para transferir descritores de arquivos entre processos , além de dados comuns .

Suponha que haja dois usuários A e B na máquina , A tenha permissão para acessar um determinado arquivo, mas B não, e B precise acessar esse arquivo . Com a ajuda do Unix Domain Socket , A pode abrir o arquivo para obter um descritor de arquivo e, em seguida, passar o descritor de arquivo para B , e B pode ler o conteúdo do arquivo mesmo que não tenha a permissão correspondente .

No cenário HDFS, A é Datanode , B é DFSClient e o arquivo a ser lido é um arquivo no diretório de dados Datanode .

1.4 Configuração de leitura local de curto-circuito

1.4.1 libhadoop.so

Como Java não pode operar diretamente o soquete de domínio Unix , o pacote nativo libhadoop.so do Hadoop precisa ser instalado . Ele pode ser obtido compilando o módulo nativo ao compilar o código-fonte do Hadoop . Você pode usar o seguinte comando para verificar se o pacote nativo está instalado .

1.4.2 hdfs-site.xml

[root@hadoop01 ~]# vim /bigdata/hadoop/server/hadoop-3.2.4/etc/hadoop/hdfs-site.xml 
<property>
  <name>dfs.client.read.shortcircuit</name>
  <value>true</value>
</property>
<property>
  <name>dfs.domain.socket.path</name>
  <value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>

dfs.client.read.shortcircuit é uma opção para ativar a função de leitura local de curto-circuito .
dfs.domain.socket.path é o caminho local do Socket comunicado entre Dtanode e DFSClient .

Certifique-se também de que o caminho local do Socket seja criado antecipadamente (cada nó do cluster precisa ser criado):

[root@hadoop01 ~]# mkdir -p /var/lib/hadoop-hdfs

Nota: A pasta hadoop -hdfs é criada aqui , e o dn_socket na configuração acima é criado pelo próprio datanode , não por uma pasta.

Por fim, envie o arquivo de configuração para outros nós e reinicie o cluster HDFS.

1.4.3 Visualizar logs do Datanode

No log de inicialização do Datanode , os seguintes logs relacionados mostram que o Unix Domain Socket está habilitado e confirmam que a configuração entrou em vigor.

[root@hadoop01 ~]# cd /bigdata/hadoop/server/hadoop-3.2.4/logs/
[root@hadoop01 /bigdata/hadoop/server/hadoop-3.2.4/logs]# tail -100 hadoop-root-datanode-hadoop01.log

2. Balanceador de carga de bloco HDFS : Balanceador

2.1 Antecedentes

Os dados do HDFS nem sempre podem ser distribuídos uniformemente entre os DataNodes. Uma causa comum é adicionar novos DataNodes a um cluster existente . O HDFS fornece um programa Balanceador que analisa as informações de posicionamento do bloco e equilibra os dados entre os DataNodes até que sejam considerados balanceados .

O chamado equilíbrio significa que a diferença entre a taxa de utilização de cada DataNode ( a proporção entre o espaço usado da máquina e a capacidade total da máquina ) e a taxa de utilização do cluster ( a proporção do espaço total usado de HDFS para a capacidade total do cluster HDFS ) não é superior à porcentagem do limite determinado . Um balanceador não pode equilibrar volumes individuais (discos) em um único DataNode .

2.2 Configuração da linha de comando

[root@hadoop01 ~]# hdfs balancer --help
Usage: hdfs balancer
	[-policy <policy>]	the balancing policy: datanode or blockpool
	[-threshold <threshold>]	Percentage of disk capacity
	[-exclude [-f <hosts-file> | <comma-separated list of hosts>]]	Excludes the specified datanodes.
	[-include [-f <hosts-file> | <comma-separated list of hosts>]]	Includes only the specified datanodes.
	[-source [-f <hosts-file> | <comma-separated list of hosts>]]	Pick only the specified datanodes as source nodes.
	[-blockpools <comma-separated list of blockpool ids>]	The balancer will only run on blockpools included in this list.
	[-idleiterations <idleiterations>]	Number of consecutive idle iterations (-1 for Infinite) before exit.
	[-runDuringUpgrade]	Whether to run the balancer during an ongoing HDFS upgrade.This is usually not desired since it will not affect used space on over-utilized machines.

-threshold 10 A condição de equilíbrio do cluster , o limite da diferença de uso do disco entre datanodes , seleção de intervalo : 0 ~ 100
-policy datanode balance policy , o padrão é datanode, se o datanode estiver balanceado , o cluster será balanceado .
-exclude -f /tmp/ip1.txt está vazio por padrão , especifica que esta parte do ip não participa do equilíbrio e -f especifica que a entrada é um arquivo
-include -f /tmp/ip2.txt está vazio por padrão , apenas permite que esta parte do ip participe do equilíbrio, -f especifica a entrada como um arquivo
-idleiterações 5 iterações 5

2.3 Como executar o Balanceador

2.3.1 Configurando uma correia de transferência de dados balanceada

hdfs dfsadmin -setBalancerBandwidth newbandwidth

onde newbandwidth é a quantidade máxima de largura de banda de rede que cada DataNode pode usar durante uma operação de balanceamento, em bytes por segundo .

Por exemplo: hdfs dfsadmin - setBalancerBandwidth 104857600 ( 100M )

2.3.2 executar balanceador

Execute com parâmetros padrão: balanceador hdfs

Especifique o limite para execução: hdfs balancer -threshold 5 O balanceador será executado a 5 % do limite ( padrão 10% ) .

Isso significa que o programa garantirá que o uso do disco em cada DataNode não difira em mais de 5 % do uso geral no cluster . Por exemplo, se o uso agregado de todos os DataNodes no cluster for 40 % da capacidade total de armazenamento em disco do cluster , o programa garantirá que o uso de disco de cada DataNode esteja entre 35 % e 45 % da capacidade de armazenamento em disco desse DataNode . .

3. Balanceador de disco: Balanceador de disco HDFS

3.1 Antecedentes

Em comparação com os PCs pessoais, os servidores geralmente podem expandir a capacidade de armazenamento de uma única máquina montando vários discos. No Hadoop HDFS , o DataNode é responsável pelo armazenamento do bloco de dados final e distribui os blocos de dados entre os discos da máquina host. Ao escrever um novo bloco , DataNodes escolherá o disco (volume) do bloco de acordo com a política de seleção ( política round-robin ou política de espaço livre ) .

Estratégia round robin : distribui novos blocos uniformemente pelos discos disponíveis. Esta política é o padrão.
Política de Espaço Livre : Esta política grava dados em discos que possuem mais espaço livre (por porcentagem).

Mas com uma estratégia round-robin em um cluster de longa execução , os DataNodes às vezes preenchem seus diretórios de armazenamento (discos / volumes) de maneira desigual , levando a situações em que alguns discos ficam cheios e outros raramente são usados. Isso pode acontecer devido a operações pesadas de gravação e exclusão ou devido a uma substituição de disco.

Além disso, se usarmos uma estratégia de seleção baseada em espaço livre , cada nova gravação irá para o disco vazio recém-adicionado, deixando outros discos livres durante esse período. Isto criará um gargalo no novo disco . Portanto, um balanceamento Intra DataNode ( distribuição uniforme de blocos de dados dentro de um DataNode ) é necessário para resolver a distorção Intra-DataNode (distribuição desigual de blocos no disco), que ocorre devido à substituição do disco ou gravações e exclusões aleatórias.

Portanto, uma ferramenta chamada Disk Balancer foi introduzida no Hadoop 3.0 , que se concentra na distribuição de dados dentro de DataNodes .

3.2 Introdução ao balanceador de disco HDFS

O balanceador de disco HDFS é uma ferramenta de linha de comando introduzida no Hadoop 3 , que é usada para equilibrar a distribuição desigual de dados em DataNodes entre discos . Preste atenção especial aqui, o balanceador de disco HDFS é diferente do HDFS Balancer :

O balanceador de disco HDFS opera em um determinado DataNode e move blocos de um disco para outro , ou seja, os dados internos do DataNode são balanceados entre diferentes discos;
O HDFS Balancer equilibra a distribuição entre os nós DataNode .

3.3 Função de balanceador de disco HDFS

3.3.1 Relatório de divulgação de dados

Para medir quais computadores do cluster sofrem com distribuição desigual de dados , o Disk Balancer define a métrica Volume Data Density ( métrica de densidade de dados de volume / disco) e a métrica Node Data Density (métrica de densidade de dados do nó) .

Densidade de dados do volume (disco): compare a distribuição de dados em diferentes volumes na mesma máquina .
Densidade de dados do nó : a comparação é entre máquinas diferentes.

3.3.1.1 Cálculo da métrica de densidade de dados de volume (densidade de dados de volume)

Um valor positivo para a densidade de dados do volume indica que o disco está subutilizado , enquanto um valor negativo indica que o disco está superutilizado .

Supondo um computador com quatro volumes / discos - Disk1 , Disk2 , Disk3 , Disk4 , uso de disco individual:

Capacidade total de capacidade = 200 + 300 + 350 + 500 = 1350 GB

Total usado = 100 + 76 + 300 + 475 = 951 GB

Portanto, o armazenamento ideal em cada volume / disco seria :

Armazenamento Ideal = Total Usado ÷ Capacidade Total = 951÷1350 = 0,70

Ou seja, cada disco deve ser mantido em 70 % da capacidade ideal de armazenamento.

Densidade de volume de dados = armazenamento ideal – proporção dfs usada

Por exemplo, a densidade de dados do volume do Disco1 = 0,70 - 0,50 = 0,20 . Outros e assim por diante .

3.3.1.2 Processo de cálculo da densidade de dados do nó

Densidade de dados do nó (densidade de dados do nó) = a soma do valor absoluto da densidade de dados de todos os volumes de densidade de dados de volume (discos ) no nó .

Densidade de dados do nó no exemplo acima =|0,20|+|0,45|+|-0,15|+|-0,24| =1,04

Um valor mais baixo de densidade de dados do nó indica que o nó da máquina tem melhor escalabilidade, enquanto um valor mais alto indica que o nó tem uma distribuição de dados mais distorcida.

Depois de ter o volume Data Density e o nó Data Density , você pode encontrar os nós onde a distribuição de dados no cluster é distorcida e os discos onde os dados são distorcidos passo a passo na máquina.

3.3.2 Balanceamento de disco

Quando um nó DataNode é designado para equilíbrio de dados do disco , a densidade de dados do volume atual ( densidade de dados do volume do disco ) pode ser calculada ou lida primeiro . Com essas informações, podemos determinar facilmente quais volumes estão superprovisionados e quais estão sub-provisionados .

Para mover dados de um volume para outro no DataNode , o desenvolvimento do Hadoop implementa o Disk Balancer baseado no protocolo RPC .

3.4 Abra o balanceador de disco HDFS

O HDFS Disk Balancer opera criando um plano, que é um conjunto de instruções que descreve quantos dados devem ser movidos entre dois discos e, em seguida, executando esse conjunto de instruções nos DataNodes. O plano contém várias etapas móveis. Cada etapa de movimentação no plano possui o disco de destino, o endereço do disco de origem. A etapa de movimentação também possui o número de bytes a serem movidos. O plano é executado em DataNodes operacionais .

Por padrão, o recurso Disk Balancer está habilitado em clusters Hadoop . Ao ajustar o valor do parâmetro dfs.disk.balancer.enabled em hdfs-site.xml , escolha se deseja ativar o balanceador de disco no Hadoop .

3.5 Comandos relacionados ao HDFS Disk Balancer

3.5.1 plano plano

Comando: hdfs diskbalancer -plan <datanode>

-out controla o local de saída do arquivo de plano
-bandwidth define a largura de banda máxima para executar o Disk Balancer , a largura de banda padrão é 10 MB/s.
-thresholdPercentage define o valor no qual o disco começa a participar de operações de redistribuição ou equilíbrio de dados . O valor limitePercentage padrão é 10 %, o que significa que o disco só será usado para operações de balanceamento se contiver 10 % ou menos dados do que os armazenados idealmente .
-maxerror que permite ao usuário especificar o número de erros a serem ignorados em uma operação de movimentação entre dois discos antes de abortar a etapa de movimentação .
-v Modo detalhado .
-fs Esta opção especifica o NameNode a ser usado . Se não for especificado, o Disk Balancer usará o NameNode padrão da configuração .

3.5.2 Executar _

Exemplo: hdfs diskbalancer -execute <caminho do arquivo JSON>

O comando execute executa o plano no DataNode para o qual o plano foi gerado.

3.5.3 Consulta de consulta

Comando: hdfs diskbalancer -query <datanode>

O comando de consulta obtém o estado atual do balanceador de disco HDFS do DataNode que executa o agendamento

3.5.4 Cancelar _

Instrução: hdfs diskbalancer -cancel <caminho do arquivo JSON>

hdfs diskbalancer -cancel planID node <nome do nó>

O comando cancel cancela um plano de execução.

3.5.5 Relatório _

Comando: hdfs diskbalancer -fs hdfs://nn_host:8020 -report

4. Tecnologia de codificação de apagamento: Codificação de apagamento

4.1 Antecedentes: 3 desvantagens da estratégia de cópia

Para fornecer tolerância a falhas, o HDFS replicará blocos de arquivos em diferentes DataNodes de acordo com o fator de replicação (fator de replicação) .

O fator de replicação padrão é 3 (observe que 3 aqui se refere a 1+2=3 , não a um 3 adicional ), portanto, haverá duas cópias adicionais, exceto o bloco original. Cada cópia utiliza 100 % da sobrecarga de armazenamento, resultando assim em uma sobrecarga de armazenamento de 200 %. Essas cópias também consomem outros recursos, como largura de banda da rede .

Quando o fator de replicação é N , há capacidades de tolerância a falhas N-1 , mas a eficiência de armazenamento é de apenas 1/N .

4.2 Introdução à Codificação de Eliminação ( EC )

A tecnologia de codificação de eliminação ( EC , para abreviar) , é uma tecnologia de codificação tolerante a erros. Foi usado pela primeira vez na indústria de comunicação e recuperação de dados na transmissão de dados. Ele divide os dados em blocos e depois calcula os dados de verificação, para que os dados de cada parte sejam correlacionados . Quando uma parte dos blocos de dados é perdida, os blocos de dados perdidos podem ser calculados através dos blocos de dados restantes e dos blocos de verificação .

Após o Hadoop 3.0, foi introduzida a tecnologia de codificação de eliminação (Erasure Coding ), que pode aumentar a utilização do armazenamento em mais de 50% e garantir a confiabilidade dos dados.

4.3 Código Reed-Solomon ( RS )

O código Reed-Solomon ( RS ) é um código de apagamento comumente usado, possui dois parâmetros k e m , registrados como RS(k , m) .

Um vetor composto por k blocos de dados é multiplicado por uma matriz geradora (Generator Matrix ) GT para obter um vetor de palavra-código ( codeword ), que consiste em k blocos de dados ( d0,d1..d3 ) e m blocos de verificação ( c0,c1 ) forma.

Se o bloco de dados for perdido, o bloco de dados perdido pode ser recuperado multiplicando a matriz inversa GT pelo vetor de palavra de código.

Por exemplo, existem três dados originais de 7 , 8 e 9 , e dois dados de verificação 50 e 122 são calculados através da multiplicação de matrizes .

Neste momento, os dados originais mais os dados de verificação, um total de cinco dados: 7 , 8 , 9 , 50 , 122 , dois dos quais podem ser perdidos arbitrariamente e depois recuperados pelo algoritmo.

4.4 Arquitetura Hadoop EC

Para suportar a codificação de eliminação, a arquitetura HDFS passou por algumas alterações e ajustes.

Extensões de namenode

Um arquivo HDFS distribuído é logicamente composto de grupos de blocos (grupos de blocos) e cada grupo de blocos contém um certo número de blocos internos. Isso permite o gerenciamento de arquivos no nível do grupo de blocos, e não no nível do bloco.

extensão do cliente

Os caminhos de leitura e gravação do cliente foram aprimorados para processar vários blocos internos dentro de um grupo de blocos em paralelo.

Extensão de nó de dados

DataNodes executa uma tarefa adicional ErasureCodingWorker ( ECWorker ) para recuperação em segundo plano de blocos de codificação de eliminação com falha . O NameNode detecta o bloco EC com falha e, em seguida, o NameNode escolhe um DataNode para fazer o trabalho de recuperação.

Estratégia de codificação de eliminação

Para acomodar cargas de trabalho heterogêneas, os arquivos e diretórios em clusters HDFS podem ter diferentes políticas de replicação e codificação de eliminação. As políticas de codificação de eliminação encapsulam como os arquivos são codificados / decodificados. Por padrão , a política RS-6-3-1024k está habilitada, RS representa o algoritmo do codificador Reed-Solomon , 6 e 3 representam o número de blocos de dados e blocos de paridade e 1024k representa o tamanho da unidade de distribuição.

O esquema REPLICATION padrão também é suportado em diretórios. Ele só pode ser definido em diretórios para forçar o diretório a adotar um esquema de replicação 3x e não herdar a política de codificação de eliminação de seus ancestrais. Esta estratégia permite que diretórios de esquema de replicação 3x sejam intercalados com diretórios codificados para eliminação. A REPLICAÇÃO está sempre habilitada.

Além disso, os usuários também têm suporte para definir suas próprias políticas EC por meio de arquivos XML . Há um arquivo XML de política EC de amostra chamado user_ec_policies.xml.template no diretório conf do Hadoop . Os usuários podem consultar esse arquivo.

Intel ISA-L

Intel ISA-L significa Biblioteca de aceleração de armazenamento inteligente Intel . ISA-L é uma coleção de código aberto de funções de baixo nível otimizadas para aplicativos de armazenamento. Inclui código de apagamento do tipo Reed-Solomon de bloco rápido otimizado para os conjuntos de instruções Intel AVX e AVX2 . Os códigos de eliminação HDFS podem usar ISA-L para acelerar os cálculos de codificação e decodificação.

4.5 Método de implantação do Erasure Coding

4.5.1 Cluster e configuração de hardware

O trabalho de codificação e decodificação consome CPU adicional em clientes HDFS e DataNodes .

Os arquivos codificados para eliminação também são distribuídos pelo rack para tolerância a falhas do rack. Isso significa que ao ler e gravar arquivos distribuídos, a maioria das operações é realizada no rack. Portanto, a largura de banda da rede também é muito importante.

Para tolerância a falhas de rack, também é importante ter um número suficiente de racks , cada rack não contendo mais blocos do que o número de blocos de paridade EC . Número de racks = (bloco de dados + bloco de paridade) / bloco de paridade após arredondamento .

Digamos que para a estratégia EC RS ( 6,3 ), isso significa um mínimo de 3 racks (calculado por ( 6+3 ) /3=3 ), idealmente 9 ou mais, para lidar com o tempo de inatividade planejado e não planejado. Para clusters com menos racks do que unidades de paridade, o HDFS não pode manter a tolerância a falhas de rack, mas ainda tentará distribuir arquivos distribuídos entre vários nós para preservar a tolerância a falhas no nível do nó. Portanto, recomenda-se montar racks com número semelhante de DataNodes .

4.5.2 Configurações de política de código de apagamento

A política de código de eliminação é especificada pelo parâmetro dfs.namenode.ec.system.default.policy , o padrão é RS-6-3-1024k e outras políticas são desabilitadas por padrão .

Um conjunto de políticas pode ser ativado pelo comando hdfs ec [-enablePolicy -policy <policyName>] .

4.5.3 Habilitar Intel ISA-L (biblioteca de aceleração de armazenamento inteligente)

A implementação nativa HDFS do codec RS padrão utiliza a biblioteca Intel ISA-L para melhorar os cálculos de codificação e decodificação. Para ativar e usar o Intel ISA-L , são necessárias três etapas.

Construir a biblioteca ISA-L ;
Construa Hadoop com suporte ISA-L ;
Use -Dbundle.isal para copiar o conteúdo do diretório isal.lib para o arquivo tar final . Implante o Hadoop usando um arquivo tar . Certifique-se de que o ISA-L esteja disponível em clientes HDFS e DataNodes .

Software necessário:

Programas	Versão
Hadoop	3.2.4
um-l	2.28.0
nome	14.2.02
sim	1.2.0

4.5.3.1 Instalar yasm e nasm

# 在Hadoop集群所有节点上安装yasm和nasm。
yum install -y yasm
yum install -y nasm

# 注意：isa-l-2.28.0 对 nasm 和 yasm 有版本要求，低版本在安装时会报错。

4.5.3.2 Compilar e instalar isa-l-2.28.0

# 在 Hadoop集群所有节点上编译安装 isa-l-2.28.0。
tar -zxvf isa-l-2.28.0.tar.gz
cd isa-l-2.28.0
./autogen.sh
./configure --prefix=/usr --libdir=/usr/lib64
make
make install
 
make -f Makefile.unx

# 检查 libisal.so* 是否成功
ll /lib64/libisal.so*
 
############如果有，则跳过##############
############如果没有有，则复制##############
cp bin/libisal.so bin/libisal.so.2 /lib64

4.5.3.3 Verifique se isa-l está habilitado no Hadoop

[root@hadoop01 ~]# hadoop checknative
Native library checking:
hadoop:  true /usr/hdp/3.0.0.0-1634/hadoop/lib/native/libhadoop.so.1.0.0
zlib:    true /lib64/libz.so.1
zstd  :  false
snappy:  true /usr/hdp/3.0.0.0-1634/hadoop/lib/native/libsnappy.so.1
lz4:     true revision:10301
bzip2:   true /lib64/libbz2.so.1
openssl: true /lib64/libcrypto.so
ISA-L:   true /lib64/libisal.so.2     ------------->  Shows that ISA-L is loaded.

4.5.4 Comandos EC

[root@hadoop01 ~]# hdfs ec
Usage: bin/hdfs ec [COMMAND]
          [-listPolicies]
          [-addPolicies -policyFile <file>]
          [-getPolicy -path <path>]
          [-removePolicy -policy <policy>]
          [-setPolicy -path <path> [-policy <policy>] [-replicate]]
          [-unsetPolicy -path <path>]
          [-listCodecs]
          [-enablePolicy -policy <policy>]
          [-disablePolicy -policy <policy>]
          [-verifyClusterSetup [-policy <policy>...<policy>]]
          [-help <command-name>]

[-setPolicy -path < caminho > [-policy < política > ] [-replicate ]]

Define a política de codificação de eliminação no diretório no caminho especificado.
caminho : diretório no HDFS . Este é um parâmetro obrigatório. A definição de uma política afeta apenas os arquivos recém-criados, não os arquivos existentes.
política : a política de codificação de eliminação a ser usada para arquivos neste diretório. A política RS-6-3-1024k padrão .
-replicate aplica o esquema REPLICATION padrão no diretório, forçando o diretório a adotar um esquema de replicação 3x . replicate e -policy <policy> são parâmetros opcionais . Eles não podem ser especificados ao mesmo tempo.

[ -getPolicy -caminho <caminho> ]

Obtenha os detalhes da política de codificação de eliminação para o arquivo ou diretório no caminho especificado.

[-unsetPolicy -path <path> ] Desconfigura a política de codificação de eliminação definida por uma chamada anterior para setPolicy no diretório . unsetPolicy será autônomo se o diretório herdar uma política de codificação de eliminação de um diretório ancestral . Cancelar uma política em um diretório sem um conjunto de políticas explícitas não retornará um erro.

[-listPolicies]
Lista todas as políticas de codificação de eliminação (ativar, desativar e excluir) registradas no HDFS. Somente políticas ativadas são adequadas para uso com o comando setPolicy .
[-addPolicies -policyFile <file> ] Adiciona uma lista de políticas de codificação de eliminação definidas pelo usuário. [-listCodecs] Obtenha uma lista de codecs e codificadores de codificação de eliminação suportados no sistema. [-removePolicy -policy < policyName > ] Remove uma política de codificação de eliminação definida pelo usuário. [-enablePolicy -policy <policyName> ] Habilita a política de codificação de eliminação . [ -disablePolicy -policy <policyName> ] Desativa a política de codificação de eliminação .

Esquema de otimização de alto nível do Hadoop HDFS

1. Leituras locais de curto-circuito : leituras locais de curto-circuito

1.1 Antecedentes