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á.
# Configure HBase
Embora as HBase configurações padrão devam funcionar para a maioria dos aplicativos, você pode modificá-las. HBase Para fazer isso, use as propriedades das classificações de HBase configuração. Para obter mais informações, consulte [Configurar aplicações](emr-configure-apps.md).
O exemplo a seguir cria um cluster com um diretório HBase raiz alternativo baseado em um arquivo de configuração,`myConfig.json`, armazenado no Amazon S3.
**nota**
Os caracteres de continuação de linha do Linux (\$1) são incluídos para facilitar a leitura. Eles podem ser removidos ou usados em comandos do Linux. No Windows, remova-os ou substitua-os por um sinal de interpolação (^).
```
aws emr create-cluster --release-label emr-7.12.0 --applications Name=HBase \
--instance-type m5.xlarge --instance-count 3 --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
```
O arquivo `myConfig.json` especifica a propriedade `hbase.rootdir` para a classificação de configuração `hbase-site`, conforme mostrado no exemplo a seguir. *ip-XXX-XX-XX-XXX.ec2.internal*Substitua pelo nome de host DNS interno do nó primário do cluster.
```
[
{
"Classification":"hbase-site",
"Properties": {
"hbase.rootdir": "hdfs://ip-XXX-XX-XX-XXX.ec2.internal:8020/user/myCustomHBaseDir"
}
}
]
```
**nota**
Com as versões 5.21.0 e posteriores do Amazon EMR, você pode substituir as configurações de cluster e especificar classificações de configuração adicionais para cada grupo de instâncias em um cluster em execução. Você faz isso usando o console do Amazon EMR, o AWS Command Line Interface (AWS CLI) ou o AWS SDK. Para obter mais informações, consulte [Supplying a Configuration for an Instance Group in a Running Cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
## Alterações na alocação de memória do YARN
HBase não está sendo executado como um aplicativo YARN, portanto, é necessário recalcular a memória alocada para o YARN e seus aplicativos, o que resulta em uma redução na memória geral disponível para o YARN se estiver instalado. HBase Você deve levar isso em consideração ao planejar a co-localização de aplicativos YARN e HBase nos mesmos clusters. Os tipos de instância com menos de 64 GB de memória têm metade da memória disponível paraNodeManager, que é então alocada para o. HBase RegionServer Por exemplo, tipos com memória maior que 64 GB, a HBase RegionServer memória é limitada a 32 GB. Como regra geral, a memória de configuração do YARN é um múltiplo da memória de tarefas do MapReduce redutor.
As tabelas em [Valores padrão para definições de configuração de tarefa](emr-hadoop-task-config.md#emr-hadoop-task-jvm) mostram as alterações nas configurações do YARN com base na memória necessária para HBase.
## HBase números de porta
Alguns números de porta escolhidos HBase são diferentes do padrão. A seguir estão as interfaces e portas para o HBase Amazon EMR.
**HBase portas**
| Interface | Porta | Protocolo |
| --- | --- | --- |
| HMaster | 16000 | TCP |
| HMaster UI | 16010 | HTTP |
| RegionServer | 16020 | TCP |
| RegionServer Informações | 16030 | HTTP |
| Servidor REST | 8070 | HTTP |
| INTERFACE DO USUÁRIO REST | 8085 | HTTP |
| Servidor Thrift | 9090 | TCP |
| Interface do usuário do servidor Thrift | 9095 | HTTP |
**Importante**
O `kms-http-port` é 9700 e o `kms-admin-port` é 9701 no Amazon EMR 4.6.0 e versões posteriores.
## HBase configurações do site para otimizar
Você pode definir qualquer uma ou todas as configurações do HBase site para otimizar o HBase cluster para a carga de trabalho do seu aplicativo. Recomendamos as seguintes configurações como ponto de partida na sua investigação.
### zookeeper.session.timeout
O tempo limite padrão é de 40 segundos (40.000 ms). Se um servidor de regiões travar, este será o tempo necessário para o servidor mestre notar a ausência do servidor de regiões e iniciar a recuperação. Para ajudar o servidor mestre a se recuperar com mais rapidez, você pode reduzir esse valor para um período mais curto. O exemplo a seguir usa 30 segundos ou 30.000 ms:
```
[
{
"Classification":"hbase-site",
"Properties": {
"zookeeper.session.timeout": "30000"
}
}
]
```
### hbase.regionserver.handler.count
Define o número de threads que o servidor de regiões mantém abertos para atender às solicitações de tabelas. O padrão de 10 é baixo, a fim de impedir que os usuários eliminem seus servidores de regiões ao usarem buffers de gravação grandes com um alto número de clientes simultâneos. A regra geral é manter esse número baixo quando a carga útil por solicitação se aproxima da faixa de MB (grandes entradas, digitalizações usando um cache grande) e alto quando a carga útil é pequena (obtenções, pequenas entradas, ICVs exclusões). O exemplo a seguir aumenta o número de threads abertos para 30:
```
[
{
"Classification":"hbase-site",
"Properties": {
"hbase.regionserver.handler.count": "30"
}
}
]
```
### hbase.hregion.max.filesize
Esse parâmetro determina o tamanho, em bytes, das regiões individuais. Por padrão, ele é definido como `1073741824`. Se você estiver gravando muitos dados em seu HBase cluster e isso estiver causando divisões frequentes, você pode aumentar esse tamanho para aumentar as regiões individuais. Isso reduz as divisões, mas exige mais tempo para fazer o balanceamento de carga de regiões de um servidor para outro.
```
[
{
"Classification":"hbase-site",
"Properties": {
"hbase.hregion.max.filesize": "1073741824"
}
}
]
```
### hbase.hregion.memstore.flush.size
Esse parâmetro determina o tamanho máximo de memstore, em bytes, antes que ele seja liberado no disco. O padrão é `134217728`. Se a sua workload é formada por curtos disparos contínuos de operações de gravação, convém aumentar esse limite para que todas as gravações permaneçam na memória durante o disparo contínuo e sejam liberadas no disco mais tarde. Isso pode aumentar o desempenho durante disparos contínuos.
```
[
{
"Classification":"hbase-site",
"Properties": {
"hbase.hregion.memstore.flush.size": "134217728"
}
}
]
```
## Considerações sobre a performance
### Habilitando um coletor de lixo (ZGC) para HBase
Com o Amazon EMR versão 7.10.0 e posterior, os usuários podem configurar facilmente as configurações de coleta de lixo (GC) para seu cluster. HBase Recomendamos habilitar o Z Garbage Collector (ZGC) para obter baixa latência e tempos de pausa GC inferiores a milissegundos.
Aqui está uma configuração para habilitar o ZGC para HBase RegionServer (s):
```
[
{
"Classification": "hbase-env",
"Properties": {},
"Configurations": [
{
"Classification": "export",
"Properties": {
"JAVA_HOME": "/usr/lib/jvm/jre-21",
"HBASE_REGIONSERVER_GC_OPTS": "\"-XX:+UseZGC -XX:+ZGenerational\""
}
}
]
}
]
```
**nota**
A variável de ambiente **JAVA\$1HOME** deve ser definida ao usar o ZGC geracional (recomendado) porque foi introduzida no JDK 21. Se quiser usar o modo não geracional (sem `-XX:+ZGenerational`) do ZGC, não há necessidade de definir **JAVA\$1HOME**. No JDK 24, o modo não geracional do ZGC foi removido.
#### Ajuste do ZGC
1. **Habilitar pilha fixa da JVM**
O Z Garbage Collector (ZGC) tem performance mais eficiente quando configurado com memória heap fixa, eliminando a sobrecarga de devolver memória ao sistema operacional. Para configurar a memória de pilha fixa para seu HBase cluster, use a seguinte configuração:
```
[
{
"Classification": "hbase",
"Properties": {
"hbase.regionserver.fixed.heap.enabled": "true"
}
}
]
```
1. **Habilitar pré-toque**
Habilitar o pré-toque melhora a performance da coleta de resíduos (GC) ao reduzir a latência inicial e fornecer uma performance mais previsível. Para habilitar o pré-toque para seu HBase cluster, use a seguinte configuração:
```
[
{
"Classification": "hbase-env",
"Properties": {},
"Configurations": [
{
"Classification": "export",
"Properties": {
"JAVA_HOME": "/usr/lib/jvm/jre-21",
"HBASE_REGIONSERVER_GC_OPTS": "\"-XX:+UseZGC -XX:+ZGenerational -XX:+AlwaysPreTouch\""
}
}
]
}
]
```