HBase en Amazon S3 (modo de almacenamiento de Amazon S3)
Si ejecuta HBase en la versión 5.2.0 de Amazon EMR o posteriores, puede habilitar HBase en Amazon S3, que ofrece las siguientes ventajas:
El directorio raíz de HBase se almacena en Amazon S3, incluidos los metadatos de tabla y los archivos de almacén de HBase. Estos datos son persistentes fuera del clúster, están disponibles a través de las zonas de disponibilidad de Amazon EC2 y no tiene que recuperar mediante instantáneas u otros métodos.
Con los archivos de almacén en Amazon S3, puede dimensionar el clúster de Amazon EMR en función de sus requisitos informáticos en lugar de sus requisitos de datos, con una replicación 3x en HDFS.
Mediante la versión 5.7.0 de Amazon EMR o posteriores, puede configurar un clúster de réplicas de lectura, lo que le permite mantener copias de solo lectura de los datos en Amazon S3. Puede acceder a los datos desde el clúster de réplicas de lectura para realizar operaciones de lectura de forma simultánea y en caso de que el clúster principal deje de estar disponible.
En la versión 6.2.0 y posteriores de Amazon EMR, el seguimiento persistente de HFile utiliza una tabla del sistema HBase llamada
hbase:storefilepara rastrear directamente las rutas de HFile utilizadas para las operaciones de lectura. Esta característica está habilitada de forma predeterminada y no requiere ninguna migración manual.
La siguiente ilustración muestra los componentes de HBase relevantes para HBase en Amazon S3.
Habilitar HBase en Amazon S3
Puede habilitar HBase en Amazon S3 mediante la consola de Amazon EMR, la AWS CLI o la API de Amazon EMR. La configuración es una opción durante la creación del clúster. Al utilizar la consola, elija la configuración mediante las Advanced options (Opciones avanzadas). Al utilizar la AWS CLI, utilice la opción --configurations para proporcionar un objeto de configuración JSON. Las propiedades del objeto de configuración especifican el modo de almacenamiento y la ubicación del directorio raíz en Amazon S3. La ubicación de Amazon S3 que especifique debe estar en la misma región que el clúster de Amazon EMR. Solo un clúster activo a la vez puede utilizar el mismo directorio raíz de HBase en Amazon S3. Para ver los pasos de la consola y un ejemplo detallado de create-cluster utilizando la AWS CLI, consulte Creación de un clúster con HBase. Un objeto de configuración de ejemplo se muestra en el siguiente fragmento de JSON.
{ "Classification": "hbase-site", "Properties": { "hbase.rootdir": "s3://amzn-s3-demo-bucket/my-hbase-rootdir"} }, { "Classification": "hbase", "Properties": { "hbase.emr.storageMode":"s3" } }
nota
Si utiliza un bucket de Amazon S3 como rootdir para HBase, debe agregar una barra al final del URI de Amazon S3. Por ejemplo, debe utilizar "hbase.rootdir: s3://amzn-s3-demo-bucket/", en lugar de "hbase.rootdir: s3://amzn-s3-demo-bucket", para evitar problemas.
Uso de un clúster de réplicas de lectura
Después de configurar un clúster principal mediante HBase en Amazon S3, puede crear y configurar un clúster de réplicas de lectura que proporcione acceso de solo lectura a los mismos datos que el clúster principal. Esto resulta útil cuando se necesita acceso simultáneo a datos de consulta o acceso ininterrumpido si el clúster principal deja de estar disponible. La característica de réplica de lectura está disponible en la versión 5.7.0 de Amazon EMR y posteriores.
El clúster principal y el clúster de réplicas de lectura se configuran de la misma forma con una importante diferencia. Ambos apuntan a la misma ubicación hbase.rootdir. Sin embargo, la clasificación hbase del clúster de réplicas de lectura incluye la propiedad "hbase.emr.readreplica.enabled":"true".
Por ejemplo, dada la clasificación JSON del clúster principal, tal y como se ha mostrado anteriormente en el tema, la configuración de un clúster de réplicas de lectura es la siguiente:
{ "Classification": "hbase-site", "Properties": { "hbase.rootdir": "s3://amzn-s3-demo-bucket/my-hbase-rootdir"} }, { "Classification": "hbase", "Properties": { "hbase.emr.storageMode":"s3", "hbase.emr.readreplica.enabled":"true" } }
Sincronización de la réplica de lectura al agregar datos
Dado que la réplica de lectura utiliza StoreFiles y metadatos de HBase que el clúster principal escribe en Amazon S3, la réplica de lectura es tan actual como el almacén de datos de Amazon S3. Las siguientes directrices pueden ayudarle a minimizar el retardo entre el clúster principal y la réplica de lectura al escribir datos.
Cargue los datos de forma masiva en el clúster principal siempre que sea posible. Para obtener más información, consulte Carga en bloque
en la documentación de Apache HBase. Debe llevarse a cabo un vaciado que escriba archivos de almacén en Amazon S3 tan pronto como sea posible después de agregar los datos. Realice el vaciado manualmente o bien ajuste la configuración de vaciado para minimizar el retardo.
Si las compactaciones se pudieran ejecutar automáticamente, ejecute una compactación manual para evitar incoherencias cuando se activen las compactaciones.
En el clúster de réplicas de lectura, cuando haya cambiado algún metadato; por ejemplo, cuando se producen compactaciones o división de región HBase o cuando las tablas se agregan o se borran, ejecute el comando
refresh_meta.En el clúster de réplicas de lectura, ejecute el comando
refresh_hfilescuando se añadan registros o se cambien en una tabla.
Seguimiento persistente de HFile
El seguimiento persistente de HFile utiliza una tabla del sistema HBase llamada hbase:storefile para rastrear directamente las rutas de HFile utilizadas para las operaciones de lectura. Las nuevas rutas de HFile se agregan a la tabla a medida que se agregan datos adicionales a HBase. Esto elimina las operaciones de cambio de nombre como mecanismo de confirmación en la ruta de escritura crítica de las operaciones de HBase y mejora el tiempo de recuperación al abrir una región de HBase al leer la tabla del sistema en lugar de la lista de directorios del sistema de archivos de hbase:storefile. Esta característica está habilitada de forma predeterminada en la versión 6.2.0 y posteriores de Amazon EMR y no requiere ningún paso de migración manual.
nota
El seguimiento persistente de HFile mediante la tabla del sistema de archivos de almacenamiento de HBase no admite la característica de replicación regional de HBase. Para más información sobre la replicación regional de HBase, consulte Timeline-consistent high available reads
Deshabilitar el seguimiento persistente de archivos HFile
El seguimiento persistente de archivos HFile está habilitado de forma predeterminada a partir de la versión 6.2.0 de Amazon EMR. Para deshabilitar el seguimiento persistente de HFile, especifique la siguiente anulación de configuración al lanzar un clúster:
{ "Classification": "hbase-site", "Properties": { "hbase.storefile.tracking.persist.enabled":"false", "hbase.hstore.engine.class":"org.apache.hadoop.hbase.regionserver.DefaultStoreEngine" } }
nota
Al volver a configurar el clúster de Amazon EMR, se deben actualizar todos los grupos de instancias.
Sincronización manual de la tabla de archivos de almacenamiento
La tabla de archivos de almacenamiento se mantiene actualizada a medida que se crean nuevos archivos HFiles. Sin embargo, si la tabla de archivos de almacenamiento no está sincronizada con los archivos de datos por algún motivo, se pueden usar los siguientes comandos para sincronizar los datos manualmente:
Sincronice la tabla de archivos de almacenamiento en una región en línea:
hbase org.apache.hadoop.hbase.client.example.RefreshHFilesClient <table>
Sincronice la tabla de archivos de almacenamiento en una región sin conexión:
Elimine la tabla de archivos de almacenamiento znode.
echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [<tableName>, hbase:namespace] # The TableName exists in the list echo "delete /hbase/storefile/loaded/<tableName>" | sudo -u hbase hbase zkcli # Delete the Table ZNode echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [hbase:namespace]Asigne la región (ejecute en el intérprete de comandos de HBase).
hbase cli> assign '<region name>'Si se produce un error en la asignación.
hbase cli> disable '<table name>' hbase cli> enable '<table name>'
Escalar la tabla de archivos de almacenamiento
La tabla de archivos de almacenamiento se divide en cuatro regiones de forma predeterminada. Si la tabla de archivos de almacenamiento aún tiene una gran carga de escritura, se puede dividir aún más manualmente.
Para dividir una región activa específica, utilice el siguiente comando (ejecute en el intérprete de comandos de HBase).
hbase cli> split '<region name>'
Para dividir la tabla, utilice el siguiente comando (ejecute en el intérprete de comandos de HBase).
hbase cli> split 'hbase:storefile'
Consideraciones operativas
Los servidores de región de HBase utilizan BlockCache para almacenar lecturas de datos en memoria y BucketCache para almacenar lecturas de datos en el disco local. Además, los servidores de región utilizan MemStore para almacenar escrituras de datos en la memoria y utilizan los registros de escritura previa en HDFS antes de que los datos se escriban en HBase StoreFiles en Amazon S3. El rendimiento de lectura del clúster se refiere a la frecuencia con la que un registro puede recuperarse en memoria o en las cachés de disco. Un error de caché da lugar a que el registro se lea desde el StoreFile en Amazon S3, que tiene una latencia notablemente superior y la desviación estándar más alta que la lectura desde HDFS. Además, las velocidades de solicitud máximas en Amazon S3 son más bajas que las que se pueden conseguir en la caché local, por lo que el almacenamiento de datos en caché podría ser importante para cargas de trabajo con lectura intensiva. Para obtener más información, consulte Optimizar el rendimiento de Amazon S3 en la Guía del usuario de Amazon Simple Storage Service.
Para mejorar el rendimiento, le recomendamos que almacene en caché el máximo posible del conjunto de datos en el almacenamiento de instancias EC2. Dado que BucketCache utiliza el almacenamiento de instancias de EC2 del servidor de región, puede elegir un tipo de instancia de EC2 con un almacén de instancias suficiente y agregar el almacenamiento de Amazon EBS para acomodar el tamaño en caché requerido. También puede aumentar el tamaño de BucketCache en los almacenes de instancias y los volúmenes de EBS asociados utilizando la propiedad hbase.bucketcache.size. La configuración predeterminada es 8 192 MB.
Para escrituras, la frecuencia de vaciados de MemStore y el número de StoreFiles presentes durante las compactaciones menores y mayores puede contribuir significativamente a un aumento de los tiempos de respuesta del servidor de región. Para un rendimiento óptimo, considere la posibilidad de aumentar el tamaño del vaciado de MemStore y el multiplicador de bloques de HRegion, que incrementa el tiempo transcurrido entre las compactaciones mayores, pero además incrementa el retardo en consistencia si utiliza una réplica de lectura. En algunos casos, es posible obtener un mejor rendimiento mediante tamaños de bloque de archivo más grandes (pero inferiores a 5 GB) para activar la funcionalidad de carga multiparte de Amazon S3 en EMRFS. El tamaño de bloque predeterminado de Amazon EMR es de 128 MB. Para obtener más información, consulte Configuración de HDFS. No son frecuentes los clientes que superen un tamaño de bloque de 1 GB al realizar un análisis comparativo del rendimiento con vaciados y compactaciones. Además, las compactaciones de HBase y los servidores de región tienen un rendimiento óptimo cuando se tienen que compactar menos archivos StoreFiles.
Las tablas pueden tardar mucho en eliminarse en Amazon S3, ya que es necesario cambiar de nombre directorios grandes. Considere la posibilidad de deshabilitar las tablas en lugar de eliminarlas.
Existe un proceso limpiador de HBase que limpia los archivos de almacén y los archivos WAL antiguos. En la versión 5.17.0 de Amazon EMR y posteriores, el limpiador está habilitado de forma global y se pueden utilizar las siguientes propiedades de configuración para controlar su comportamiento.
| Propiedad de configuración | Valor predeterminado | Descripción |
|---|---|---|
|
|
1 |
El número de subprocesos asignados para limpiar los HFiles grandes que han caducado. |
|
|
1 |
El número de subprocesos asignados para limpiar los HFiles pequeños que han caducado. |
|
|
Se establece en la cuarta parte de los núcleos disponibles. |
El número de subprocesos para analizar los directorios oldWALs. |
|
|
2 |
El número de subprocesos para limpiar los WAL del directorio oldWALs. |
En Amazon EMR 5.17.0 y versiones anteriores, el funcionamiento del limpiador puede afectar al rendimiento de las consultas cuando se ejecutan cargas de trabajo pesadas, por lo que le recomendamos que únicamente habilite el limpiador fuera de las horas punta. El limpiador tiene los siguientes comandos shell de HBase:
cleaner_chore_enabledconsulta si el limpiador está habilitado.cleaner_chore_runejecuta manualmente el limpiador para eliminar archivos.cleaner_chore_switchhabilita o deshabilita el limpiador y devuelve el estado anterior del limpiador. Por ejemplo,cleaner_chore_switch truehabilita el limpiador.
Propiedades para ajuste de rendimiento de HBase en Amazon S3
Los siguientes parámetros se pueden modificar para ajustar el rendimiento de la carga de trabajo cuando utilice HBase en Amazon S3.
| Propiedad de configuración | Valor predeterminado | Descripción |
|---|---|---|
|
|
8 192 |
La cantidad de espacio en disco, en MB, reservada en los almacenes de instancias de Amazon EC2 del servidor de región y volúmenes de EBS para almacenamiento de BucketCache. La configuración se aplica a todas las instancias de servidor de región. Los tamaños de BucketCache más grandes, por lo general, corresponden a un mejor rendimiento |
|
|
134217728 |
El límite de datos, en bytes, a partir del cual el vaciado de memstore en Amazon S3 se activa. |
|
|
4 |
Un multiplicador determina el límite superior de MemStore en el que se bloquean las actualizaciones. Si MemStore supera |
|
|
10 |
El número máximo de StoreFiles que puede existir en un almacén antes de que se bloqueen las actualizaciones. |
|
|
10737418240 |
El tamaño máximo de una región antes de que la región se divida. |
Cierre y restauración de un clúster sin pérdida de datos
Para cerrar un clúster de Amazon EMR sin perder los datos que no se hayan escrito en Amazon S3, la caché de MemStore tiene que vaciarse en Amazon S3 para escribir archivos de almacén nuevos. En primer lugar, tendrá que deshabilitar todas las tablas. La siguiente configuración de paso puede utilizarse al añadir un paso al clúster. Para obtener más información, consulte Uso de pasos con la AWS CLI y la consola en la Guía de administración de Amazon EMR.
Name="Disable all tables",Jar="command-runner.jar",Args=["/bin/bash","/usr/lib/hbase/bin/disable_all_tables.sh"]
De forma alternativa, puede ejecutar el siguiente comando bash directamente.
bash /usr/lib/hbase/bin/disable_all_tables.sh
Después de deshabilitar todas las tablas, vacíe la tabla de hbase:meta con el intérprete de comandos de HBase y el siguiente comando.
flush 'hbase:meta'
A continuación, puede ejecutar un script del intérprete de comandos incluido en el clúster de Amazon EMR para vaciar la caché de MemStore. Puede agregarlo como un paso o ejecutarlo directamente a través de la AWS CLI en el clúster. El script deshabilita todas las tablas de HBase, lo que hace que MemStore en cada servidor de región se vacíe en Amazon S3. Si el script se completa de forma satisfactoria, los datos persisten en Amazon S3 y el clúster puede terminarse.
Para reiniciar un clúster con los mismos datos de HBase, especifique la misma ubicación de Amazon S3 que el clúster anterior en la AWS Management Console o mediante la propiedad de configuración hbase.rootdir.
