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: + O diretório raiz HBase é armazenado no Amazon S3, incluindo arquivos de armazenamento e metadados de tabela do HBase. Esses dados são persistentes fora do cluster, disponíveis em zonas de disponibilidade do Amazon EC2, e você não precisa recuperar usando snapshots ou outros métodos. + Com arquivos de armazenamento no Amazon S3, você pode dimensionar seu cluster do Amazon EMR para suas necessidades de computação em vez de requisitos de dados, com replicação de 3x no HDFS. + Usando o Amazon EMR versão 5.7.0 ou posterior, você pode configurar um cluster de réplica de leitura, que permite manter cópias somente leitura dos dados no Amazon S3. Você pode acessar os dados do cluster de réplica de leitura para realizar operações de leitura simultaneamente e no evento de o cluster primário se tornar indisponível. + No Amazon EMR 6.2.0 a 7.3.0, 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. Esse atributo é habilitado por padrão e não exige que a migração manual seja executada. Nas versões superiores à 7.3.0, caminhos HFile são rastreados com um rastreador de arquivos, armazenando caminhos HFile diretamente em um meta-arquivo, dentro do diretório de armazenamento. **nota** Usuários que estão usando uma versão do Amazon EMR anterior à 7.4.0 e estão migrando para EMR-7.4.0 e versões posteriores, consulte [Migração de versões anteriores do HBase e sigam](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-migrate.html) a documentação de atualização disponível para garantir uma transição tranquila. A ilustração a seguir mostra os componentes HBase relevantes para o HBase no Amazon S3. ![Arquitetura do HBase no Amazon S3.](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/images/hbase_s3.png) ## Habilitar o HBase no Amazon S3 Você pode habilitar o HBase no Amazon S3 usando o console do Amazon EMRAWS 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 oAWS CLI, consulte. [Criar um cluster com o HBase](emr-hbase-create.md) 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}}" } } ``` **nota** Ao usar um bucket do Amazon S3 como `rootdir` para o HBase, é necessário adicionar uma barra no final do URI do Amazon S3. Por exemplo, é necessário usar `"hbase.rootdir: s3://amzn-s3-demo-bucket/"`, em vez de `"hbase.rootdir: s3://amzn-s3-demo-bucket"`, para evitar problemas. ## 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](#emr-hbase-store-file-tracking) 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. + Carregue os dados em massa no cluster primário sempre que possível. Para obter mais informações, consulte [Bulk loading](http://hbase.apache.org/0.94/book/arch.bulk.load.html) na documentação do Apache HBase. + Uma liberação que grava arquivos de armazenamento no Amazon S3 deve ocorrer logo que possível após a adição dos dados. Faça a liberação manualmente ou ajuste configurações de liberação para minimizar o tempo de retardo. + Se compactações puderem ser executadas automaticamente, execute uma compactação manual para evitar inconsistências quando compactações forem acionadas. + No cluster de réplica de leitura, quando metadados forem alterados (por exemplo, quando ocorrem compactações ou uma divisão de regiões do HBase, ou quando as tabelas são adicionadas ou removidas) execute o comando `refresh_meta`. + No cluster de réplica de leitura, execute o comando `refresh_hfiles` quando registros forem adicionados ou alterados em uma tabela. ![Sincronizando dados com uma réplica de leitura do HBase](http://docs.aws.amazon.com/pt_br/emr/latest/ReleaseGuide/images/hbase-read-replica.png) ## 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. **nota** O rastreamento persistente do HFile que usa a tabela do sistema storefile do HBase não é compatível com o recurso de replicação da região do HBase. Para obter mais informações sobre a replicação da região do HBase, consulte [Timeline-consistent Alta disponibilidade de leituras](http://hbase.apache.org/book.html#arch.timelineconsistent.reads). **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" } } ``` **nota** Ao reconfigurar o cluster do Amazon EMR, todos os grupos de instâncias deverão ser atualizados. **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 ` **Sincronizar a tabela do storefile em uma região off-line:** + Remova o znode da tabela storefile. ``` echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [, hbase:namespace] # The TableName exists in the list echo "delete /hbase/storefile/loaded/" | sudo -u hbase hbase zkcli # Delete the Table ZNode echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [hbase:namespace] ``` + Atribua a região (execute em “hbase shell”). ``` hbase cli> assign '' ``` + Se a tarefa falhar. ``` hbase cli> disable '
' hbase cli> enable '
' ``` **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 '' ``` 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 **FileBasedStoreFileTracker**implementaçã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](https://hbase.apache.org/book.html#storefiletracking), 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" } } ``` **nota** Ao reconfigurar o cluster do Amazon EMR, todos os grupos de instâncias deverão ser atualizados. ## 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PerformanceOptimization.html), 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](emr-hdfs-config.md). 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. | Propriedade de configuração | Valor padrão | Description | | --- | --- | --- | | `hbase.regionserver.hfilecleaner.large.thread.count` | 1 | O número de threads alocados para limpar HFiles grandes expirados. | | `hbase.regionserver.hfilecleaner.small.thread.count` | 1 | O número de threads alocados para limpar HFiles pequenos expirados. | | `hbase.cleaner.scan.dir.concurrent.size` | Defina como um quarto de todos os núcleos disponíveis. | O número de threads para verificar diretórios oldWALs. | | `hbase.oldwals.cleaner.thread.size` | 2 | O número de threads para limpar os WALs no diretório oldWals. | 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: + `cleaner_chore_enabled` consulta se o agente de limpeza está habilitado. + `cleaner_chore_run` executa manualmente o agente de limpeza para remover arquivos. + `cleaner_chore_switch` habilita ou desabilita o agente de limpeza e retorna ao seu estado anterior. Por exemplo, `cleaner_chore_switch true` habilita o agente de limpeza. ### 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. | Propriedade de configuração | Valor padrão | Description | | --- | --- | --- | | `hbase.bucketcache.size` | 8,192 | A quantidade de espaço em disco, em MB, reservada nos armazenamentos de instâncias Amazon EC2 do servidor regional e nos volumes do EBS para armazenamento. BucketCache A configuração se aplica a todas as instâncias do servidor de regiões. BucketCache Tamanhos maiores geralmente correspondem a um melhor desempenho | | `hbase.hregion.memstore.flush.size` | 134217728 | O limite de dados, em bytes, no qual uma liberação de memstore para o Amazon S3 é acionada. | | `hbase.hregion.memstore.block.multiplier` | 4 | Um multiplicador que determina o limite MemStore superior no qual as atualizações são bloqueadas. Se os MemStore excedentes forem `hbase.hregion.memstore.flush.size` multiplicados por esse valor, as atualizações serão bloqueadas. MemStore descargas e compactação podem ocorrer para desbloquear as atualizações. | | `hbase.hstore.blockingStoreFiles` | 10 | O número máximo StoreFiles que pode existir em uma loja antes que as atualizações sejam bloqueadas. | | `hbase.hregion.max.filesize` | 10737418240 | O tamanho máximo de uma região antes que ela seja dividida. | ### 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-work-with-steps.html) 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.