As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

HBase no Amazon S3 (modo de armazenamento do Amazon S3)

Ao executar o HBase no Amazon EMR 5.2.0 ou versões posteriores, você pode habilitar o HBase no Amazon S3, que oferece as seguintes vantagens:

A ilustração a seguir mostra os componentes HBase relevantes para o HBase no Amazon S3.

Habilitar o HBase no Amazon S3

Você pode habilitar o HBase no Amazon S3 usando o console do Amazon EMR AWS CLI, o ou a API do Amazon EMR. A configuração é uma opção durante a criação do cluster. Ao usar o console, você escolhe a configuração usando Advanced options (Opções avançadas). Quando você usa a AWS CLI, use a opção --configurations para fornecer um objeto de configuração JSON. As propriedades do objeto de configuração especificam o modo de armazenamento e o local do diretório raiz no Amazon S3. O local do Amazon S3 que você especificar deve estar na mesma região que seu cluster do Amazon EMR. Apenas um cluster ativo de cada vez pode usar o mesmo diretório de raiz do HBase no Amazon S3. Para ver as etapas do console e um exemplo detalhado de criação de cluster usando o AWS CLI, consulte. Criar um cluster com o HBase Um objeto de configuração de exemplo é mostrado no seguinte trecho de código JSON.

{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.rootdir": "s3://amzn-s3-demo-bucket/my-hbase-rootdir"}
},
{
  "Classification": "hbase",
  "Properties": {
  "hbase.emr.storageMode":"s3"
  }
}
		

Usar um cluster de réplica de leitura

Depois de configurar um cluster primário usando o HBase no Amazon S3, você pode criar e configurar um cluster de réplica de leitura que fornece acesso somente leitura aos mesmos dados que o cluster primário. Isso é útil quando você precisa de acesso simultâneo para consultar dados ou de acesso ininterrupto caso o cluster primário se torne indisponível. O atributo de réplica de leitura está disponível no Amazon EMR 5.7.0 e versões posteriores.

O cluster primário e o cluster de réplica de leitura são configuradas da mesma maneira, com uma diferença importante. Ambos apontam para o mesmo local hbase.rootdir. No entanto, a classificação hbase para o cluster de réplica de leitura inclui a propriedade "hbase.emr.readreplica.enabled":"true".

O cluster de réplica de leitura foi projetado para operações somente leitura, e nenhuma ação manual de compactação ou gravação deve ser executada nele. Para versões do Amazon EMR anteriores a 7.4.0, é recomendável desabilitar a compactação no cluster de réplica de leitura ao habilitar o recurso de réplica de leitura. Essa precaução é necessária porque, com o recurso de rastreamento persistente do HFile ativado no cluster primário, é possível que o cluster de réplica de leitura compacte as tabelas do sistema, causando potencialmente uma FileNotFoundException no cluster primário. A ação de desabilitar a compactação no cluster de réplica de leitura evita inconsistências de dados entre os clusters primário e de réplica de leitura.

Por exemplo, dada a classificação JSON para o cluster primário, conforme mostrado anteriormente neste tópico, a configuração para um cluster de réplicas de leitura para versões do EMR anteriores à 7.4.0 é a seguinte:

{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.rootdir": "s3://amzn-s3-demo-bucket/my-hbase-rootdir",
    "hbase.regionserver.compaction.enabled": "false"			
  }
},
{
  "Classification": "hbase",
  "Properties": {
  "hbase.emr.storageMode":"s3",
  "hbase.emr.readreplica.enabled":"true"
  }
}
		

Para versões do Amazon EMR posteriores a 7.3.0, agora usamos o recurso e Acompanhamento de arquivos no armazenamento e, portanto, não há necessidade de desabilitar as compactações.

Sincronizar a réplica de leitura ao adicionar dados

Como a réplica de leitura usa o HBase StoreFiles e os metadados que o cluster primário grava no Amazon S3, a réplica de leitura é tão atual quanto o armazenamento de dados do Amazon S3. A orientação a seguir pode ajudar a minimizar o tempo de retardo entre o cluster primário e a réplica de leitura quando você grava dados.

Rastreamento persistente do HFile

O rastreamento persistente do HFile usa uma tabela do sistema HBase chamada hbase:storefile para rastrear diretamente os caminhos do HFile usados para operações de leitura. Adicionam-se novos caminhos do HFile à tabela à medida que outros dados são adicionados ao HBase. Isso elimina operações de renomeação como um mecanismo de confirmação nas operações essenciais do HBase do caminho de gravação e reduz o tempo de recuperação ao abrir uma região do HBase lendo a tabela do sistema hbase:storefile em vez da listagem de diretórios do sistema de arquivos. Esse recurso está habilitado por padrão no Amazon EMR versão 6.2.0 a 7.3.0 e não requer nenhuma etapa de migração manual.

Desabilitar o rastreamento persistente do HFile

O rastreamento persistente do HFile é habilitado por padrão a partir da versão 6.2.0 do Amazon EMR. Para desabilitar o rastreamento persistente do HFile, especifique a seguinte substituição de configuração ao iniciar um cluster:

{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.storefile.tracking.persist.enabled":"false",
    "hbase.hstore.engine.class":"org.apache.hadoop.hbase.regionserver.DefaultStoreEngine"
  }
}

Sincronizar a tabela Storefile manualmente

A tabela storefile é mantida atualizada à medida que novas instâncias de HFiles são criadas. No entanto, se a tabela storefile ficar fora de sincronia com os arquivos de dados por qualquer motivo, os comandos a seguir poderão ser usados para sincronizar os dados manualmente:

Sincronizar a tabela storefile em uma região on-line:

hbase org.apache.hadoop.hbase.client.example.RefreshHFilesClient <table>

Sincronizar a tabela do storefile em uma região off-line:

Escalar a tabela storefile

Por padrão, a tabela storefile é dividida em quatro regiões. Se a tabela storefile continuar sob carga de gravação pesada, a tabela ainda poderá ser dividida manualmente.

Para dividir uma região ativa específica, use o comando a seguir (executado em “hbase shell”).

hbase cli> split '<region name>'

Para dividir a tabela, use o comando a seguir (execute em “hbase shell”).

hbase cli> split 'hbase:storefile'

Acompanhamento de arquivos no armazenamento

Por padrão, usamos a FileBasedStoreFileTrackerimplementação. Essa implementação cria novos arquivos diretamente no diretório de armazenamento, evitando a necessidade de operações de renomeação. Ela mantém uma lista de instâncias de hfile com commit na memória, com o suporte de meta-arquivos em cada diretório de armazenamento. Sempre que um novo arquivo hfile recebe commit, a lista de arquivos rastreados no armazenamento fornecido é atualizada, e um novo meta-arquivo é gravado com o conteúdo da lista e descartando o meta-arquivo anterior, que contém uma lista desatualizada. Mais informações sobre o Rastreamento de arquivos no armazenamento podem ser encontradas em Rastreamento de arquivos no armazenamento, no Guia de referência do Apache HBase.

A implementação do FileBasedStoreFile rastreador é ativada por padrão, começando com a versão 7.4.0 do Amazon EMR:

{
  "Classification": "hbase-site",
  "Properties": {
    hbase.store.file-tracker.impl: "org.apache.hadoop.hbase.regionserver.storefiletracker.FileBasedStoreFileTracker"
   }
}

Para desativar a FileBasedStoreFileTracker implementação, especifique a seguinte substituição de configuração ao iniciar um cluster:

{
  "Classification": "hbase-site",
  "Properties": {
    hbase.store.file-tracker.impl: "org.apache.hadoop.hbase.regionserver.storefiletracker.DefaultStoreFileTracker"
   }
}

Configurando a política de leitura do S3A para o HBase

A partir da versão 7.10 do Amazon EMR, o HBase no Amazon S3 usa o cliente do sistema de arquivos S3A. Por padrão, a propriedade fs.s3a.experimental.input.fadvise é definida como normal. Nesse modo, o S3A se adapta automaticamente entre as políticas de leitura sequencial e aleatória com base no padrão de acesso observado do fluxo de entrada.

O HBase no Amazon S3 depende de leituras sequenciais para compactações, digitalizações e cargas em massa. Em alguns casos, o modo normal pode mudar para a política de leitura aleatória. Isso pode acontecer mesmo que as leituras subsequentes permaneçam sequenciais. Quando isso ocorre, o desempenho de leitura para compactações, digitalizações e cargas em massa pode diminuir significativamente.

Se você tiver algum dos seguintes sintomas, defina a política de leitura do S3A como: sequential

Especifique a seguinte configuração ao criar seu cluster:

[
  {
    "Classification": "hbase-site",
    "Properties": {
      "fs.s3a.experimental.input.fadvise": "sequential"
    }
  }
]

Aplique essa propriedade hbase-site.xml em todos os nós. A alteração entra em vigor após a reinicialização dos processos do servidor primário e regional do HBase.

Configurando a política de leitura para operações de carregamento em massa

Se você precisar melhorar somente o desempenho do carregamento em massa sem alterar a configuração de todo o cluster, poderá passar a propriedade diretamente para o comando. completebulkload

Para usar a política de leitura sequencial para uma única operação de carregamento em massa:

sudo -u hbase hbase completebulkload \
  -Dfs.s3a.experimental.input.fadvise=sequential \
  s3://amzn-s3-demo-bucket/path/to/hfiles table_name

Como alternativa, você pode usar o EMRFS para a operação de carregamento em massa:

sudo -u hbase hbase completebulkload \
  -Dfs.s3.impl=com.amazon.ws.emr.hadoop.fs.EmrFileSystem \
  s3://amzn-s3-demo-bucket/path/to/hfiles table_name

Considerações operacionais

Os servidores da região HBase são usados BlockCache para armazenar leituras de dados na memória e BucketCache armazenar leituras de dados no disco local. Além disso, os servidores regionais usam MemStore para armazenar gravações de dados na memória e usam registros de gravação antecipada para armazenar gravações de dados no HDFS antes que os dados sejam gravados no HBase no StoreFiles Amazon S3. O desempenho de leitura do seu cluster estão relacionado à frequência com a qual um registro pode ser recuperado dos caches na memória ou no disco. Uma perda de cache resulta na leitura do registro StoreFile no Amazon S3, que tem latência e desvio padrão significativamente maiores do que a leitura do HDFS. Além disso, as taxas máximas de solicitações para o Amazon S3 são menores do que as que podem ser obtidas no cache local e, portanto, o armazenamento de dados no cache pode ser importante para workload com uso intensivo de leitura. Para obter mais informações sobre a performance do Amazon S3, consulte Performance optimization, no Guia do usuário do Amazon Simple Storage Service.

Para melhorar o desempenho, recomendamos que você armazene em cache o máximo possível do seu conjunto de dados no armazenamento de instâncias do EC2. Como BucketCache usa o armazenamento de instância EC2 do servidor regional, você pode escolher um tipo de instância EC2 com um armazenamento de instâncias suficiente e adicionar armazenamento Amazon EBS para acomodar o tamanho de cache necessário. Você também pode aumentar o BucketCache tamanho dos armazenamentos de instâncias anexados e dos volumes do EBS usando a hbase.bucketcache.size propriedade. A configuração padrão é 8.192 MB.

Para gravações, a frequência de MemStore descargas e o número de StoreFiles presentes durante compactações menores e maiores podem contribuir significativamente para um aumento nos tempos de resposta do servidor regional. Para um desempenho ideal, considere aumentar o tamanho do multiplicador de blocos MemStore flush e hRegion, o que aumenta o tempo decorrido entre as principais compactações, mas também aumenta o atraso na consistência se você usar uma réplica de leitura. Em alguns casos, você pode obter melhor performance usando tamanhos de blocos de arquivos maiores (porém inferiores a 5 GB) para acionar a funcionalidade do carregamento multiparte do Amazon S3 no EMRFS. O tamanho padrão do bloco do Amazon EMR é 128 MB. Para obter mais informações, consulte Configuração do HDFS. Raramente há clientes que excedem 1 GB de tamanho de bloco ao fazer a comparação do desempenho com liberações e compactações. Além disso, as compactações do HBase e os servidores regionais funcionam de maneira ideal quando menos StoreFiles precisam ser compactados.

Tabelas podem demorar um tempo significativo para serem descartadas no Amazon S3, pois diretórios grandes precisam ser renomeados. Considere desabilitar tabelas em vez de as descartar.

Há um processo de agente de limpeza do HBase que limpa os arquivos WAL antigos e arquivos de armazenamento. Com o Amazon EMR versão 5.17.0 e posterior, o agente de limpeza está habilitado globalmente, e as seguintes propriedades de configuração podem ser usadas para controlar o comportamento do agente de limpeza.

Com o Amazon EMR 5.17.0 e versões anteriores, a operação do agente de limpeza pode afetar a performance de consultas ao executar workloads pesadas. Por isso, recomendamos que você ative o agente de limpeza apenas fora de horários de pico. O agente de limpeza têm os seguintes comandos shell do HBase:

Propriedades para o ajuste do performance do HBase no Amazon S3

Os seguintes parâmetros podem ser adaptados para ajustar a performance da workload quando você usa o HBase no Amazon S3.

Desativar e restaurar um cluster sem perda de dados

Para desligar um cluster do Amazon EMR sem perder dados que não foram gravados no Amazon S3, você deve liberar seu cache no Amazon S3 MemStore para gravar novos arquivos de armazenamento. Primeiro, é necessário desabilitar todas as tabelas. A seguinte configuração de etapas pode ser usada quando você adiciona uma etapa ao cluster. Para obter mais informações, consulte Work with steps using the AWS CLI and console no Guia de gerenciamento do Amazon EMR.

Name="Disable all tables",Jar="command-runner.jar",Args=["/bin/bash","/usr/lib/hbase/bin/disable_all_tables.sh"]	

Como alternativa, você pode executar o seguinte comando bash diretamente.

bash /usr/lib/hbase/bin/disable_all_tables.sh

Após desabilitar todas as tabelas, libere a tabela hbase:meta usando o shell do HBase e o comando a seguir.

flush 'hbase:meta'

Em seguida, você pode executar um script de shell fornecido no cluster do Amazon EMR para limpar o cache. MemStore Você pode adicioná-lo como uma etapa ou executá-lo diretamente, usando a AWS CLI no cluster. O script desativa todas as tabelas do HBase, o que faz com que o servidor de cada MemStore região seja transferido para o Amazon S3. Se o script for concluído com êxito, os dados persistirão no Amazon S3, e o cluster poderá ser terminado.

Para reiniciar um cluster com os mesmos dados do HBase, especifique a mesma localização do Amazon S3 do cluster anterior na propriedade de configuração ou usando Console de gerenciamento da AWS hbase.rootdir a propriedade de configuração.