6. Proceso de escritura de HBase
1. Proceso de escritura de HBase
El servidor HBase no proporciona interfaces de actualización y eliminación. Las operaciones de actualización y eliminación de datos en HBase se consideran operaciones de escritura, y la operación de actualización escribirá. Ingrese una versión mínima de los datos y la operación de eliminación escribe un fragmento de datos KV marcado como eliminado
1.1 Descripción general de las tres etapas del proceso de escritura
1) Etapa de procesamiento del cliente: cliente Preprocese la solicitud del usuario, ubique el RegionServer donde se escriben los datos según los metadatos del clúster y envíe la solicitud a RS
2) Etapa de escritura de la región: después de recibir la solicitud, RS analiza los datos y primero escribe los datos Escribe en WAL y luego escribe en el MemStore correspondiente a la Región correspondiente
3) Etapa de descarga de MemStore: cuando la capacidad de MemStore en la Región alcanza un cierto umbral, el sistema realiza una operación de descarga de forma asincrónica y escribe la memoria en el archivo para formar HFile
1.2. Las solicitudes de escritura del usuario regresarán exitosamente después de completar la escritura en MemStore. MemStore Flush es un proceso de ejecución asincrónico.
1.3. Explicación detallada de los pasos de la etapa de procesamiento del cliente:
1) El cliente puede configurar el envío por lotes. Si se configura el envío por lotes (autoflush=false), el cliente escribirá el. datos primero El búfer local no se confirmará hasta que alcance un cierto umbral. De lo contrario, la solicitud de venta se enviará directamente al servidor para su procesamiento.
2) Direccionamiento RS, antes del envío, HBase encontrará el RS al que pertenecen según la clave de fila en la tabla de metadatos hbase:meta
2.1) El cliente buscará según el tabla escrita y la clave de fila se busca en los metadatos. Si se puede encontrar el RS y la región donde se encuentra la clave de fila, la solicitud de escritura se envía directamente
2.2) Si el cliente no encuentra la información de la clave de fila, primero debe encontrar hbase en zk: el RS donde se encuentra la metatabla envía una solicitud de consulta a ese RS para obtener los metadatos, luego busca el RS donde se encuentra la clave de fila en los metadatos y almacena en caché los metadatos localmente para el próximo uso. .
3) El cliente envía una solicitud RPC remota al RS y escribe los datos en el MemStore de la Región de destino
1.4 Explicación detallada de los pasos de la fase de escritura de la Región:
p>
1) Obtener un bloqueo de fila Los bloqueos de fila se utilizan en HBase para garantizar que las actualizaciones de la misma fila de datos sean operaciones mutuamente excluyentes para garantizar la atomicidad de la actualización, ya sea exitosa o fallida.
2) Actualice todos los valores clave que se escribirán. La marca de tiempo es la hora actual del sistema
3) Construya un registro WALEdit para uno o más valores clave escritos en la misma región al mismo tiempo. esto es para garantizar la atomicidad de escritura de las transacciones a nivel de región
p>4) Escribir WALEdit en HLog se almacena en HDFS y requiere una operación de sincronización para implementar HLog en HDFS. no es necesario ejecutar la sincronización por el momento. HBase utiliza un disruptor para implementar una cola de productor y consumidor eficiente para implementar de forma asincrónica operaciones de escritura adicionales de WAL
5) Escriba los datos en MemStore después de escribir en WAL. /p>
6) Liberar el bloqueo de fila
7 ) sincronizar WAL: sincronizar realmente el HLog con HDFS. Si la sincronización falla, realice una operación de reversión para eliminar los datos de MemStore.
8) Finalizar la transacción de escritura.
La actualización es visible para el mundo exterior y entra en vigor
1.5 Explicación detallada de la etapa MemStore Flush:
1.5.1 Activación de condiciones de descarga
1.5. .1.1. Restricciones de nivel de MemStore, cuando el tamaño de cualquier MemStore en Rgion alcanza el umbral (hbase.hrgion.memstore.flush.size El valor predeterminado es 128M
1.5.1.2. el tamaño de todos los MemStore en la región alcanza el límite superior (hbase.hregion. memstore.block.multiplier * hbase.hrgion.memstore.flush.size) Si el múltiplo del tamaño del memstore alcanza este valor, se bloquearán todas las solicitudes de escritura para descarga. La autoprotección predeterminada es 2.
1.5.1.3, restricción de nivel de RegionServer: cuando el tamaño total de MemStore en RS excede el umbral de nivel bajo de agua hbase.regionserver.global.memstore.size. lower.limit * hbase.reagionserver.global.memstore.size RS comenzará a forzar el lavado de acuerdo con el tamaño de MemStore en la Región. Flush de mayor a menor hasta que el tamaño total de MemStore caiga al nivel bajo de agua.
1.5.1.4 Cuando el número de HLogs en un RegionServer alcanza un cierto límite superior (hbase.regionserver.maxlogs), el sistema selecciona la región correspondiente al primer HLog para Flush
1.5.1.6 Vaciar manualmente, el usuario puede vaciar una tabla o región vaciando 'nombre de tabla' o vaciando 'nombre de región'. ' Realizar descarga
1.5.2. Pasos de ejecución de descarga
1.5.2.1 Fase de preparación
Recorre MemStore en la región actual para tomar una instantánea y luego cree un nuevo ConcurrentSkipListMap. Acepte nuevas solicitudes de datos. En esta fase, se requiere un bloqueo para bloquear la solicitud de escritura y el bloqueo se libera una vez finalizada. El tiempo de retención del bloqueo de este proceso es muy corto
1.5.2.2. >
Generar HFile de acuerdo con un formato específico para los datos de la instantánea. La persistencia es un archivo temporal ubicado en el directorio .tmp. Este proceso implica operaciones de E/S de disco, lo que lleva relativamente tiempo
1.5.2.3 Fase de confirmación
Mueva los archivos temporales al directorio CF especificado. Luego borre los datos de la instantánea.
1.5.3. Impacto de MemStore Flush en los negocios
1.5.3.1 La mayoría de las operaciones de MemStore Flush no tendrán mucho impacto en la lectura y escritura empresarial,
1.5.3.2 Una descarga lenta en el nivel del servidor de región tendrá un mayor impacto en las solicitudes de los usuarios y bloqueará las operaciones de escritura en el RS.
1.6. Modelo de escritura HLog
1.6.1 Nivel de persistencia de HLog
SKIP_WAL: Solo escribe caché, no escribe HLog, no recomendable
ASYNC_WAL: escritura asincrónica de HLog
SYNC_WAL: escritura sincrónica de archivos de registro, los datos solo se escriben en la memoria caché del sistema de archivos y en realidad no se escriben en el disco.
El valor predeterminado es este nivel
FSYNC_WAL: escribe sincrónicamente los datos en el archivo de registro y los fuerza al disco. Este es el nivel de escritura más estricto para garantizar que no se pierdan datos y que el rendimiento sea relativamente pobre
. p>
USER_DEFAULT: si el usuario no especifica el nivel de persistencia, de forma predeterminada HBase usa el nivel SYN_WAL para conservar los datos put.setDurability(Durability.SYNC_WAL);
1.6.2, modelo de escritura HLog
1. La escritura de HLog debe pasar por tres etapas: escribir manualmente los datos en el caché local, luego escribir el caché local en el sistema de archivos y, finalmente, realizar una operación de sincronización para sincronizar con el disco.
2. HBase utiliza el marco LMAX Disruptor para implementar la operación de cola limitada sin bloqueo, el modelo de escritura se muestra a continuación
2. Proceso BulkLoad
2.1. Escenario de uso: los datos del usuario se encuentran en HDFS y la empresa necesita transferir periódicamente estos datos masivos. Importar el sistema HBase.
2.2 El proceso principal se divide en dos pasos
2.2. .1.Fase de generación de HFile: ejecute una tarea MapReduce. El mapa debe implementarse por sí solo para leer los datos en el archivo HDFS y ensamblar un KV compuesto, donde la clave es una clave de fila y el valor puede ser un valor clave. objeto, un objeto Poner o incluso un objeto Eliminar; la reducción es manejada por HBase, que configurará un particionador ordenado globalmente según la información de la tabla y cargará el archivo del particionador al clúster HDFS. Establecerá el número de tareas de reducción en el número de. Regiones en la tabla de destino. Genere un archivo HFile correspondiente para cada región
2.2.2 Etapa de importación de HFile: una vez que el maestro y la copia de seguridad de HFile estén listos, cargue el HFile en el clúster en línea.
2.3. Algunos problemas comunes encontrados por Bulkload
2.3.1 Establecer permisos correctos
2.3.1 Usuarios involucrados en el proceso de operación de BulkLoad:
p>
El primer paso es generar HFile a través de la tarea MapReduce. Supongamos que la cuenta HDFS utilizada en este proceso es: u_mapreduce.
El segundo paso es cargar HFile en el clúster HBase. Supongamos que la cuenta utilizada en este paso es: u_load.
Generalmente: el clúster HBase utiliza una cuenta especial para administrar los datos de HBase. Esta cuenta tiene la máxima autoridad de todas las tablas en el clúster HBase.
Al mismo tiempo, puede leer y. escriba en el directorio raíz de HBase Todos los archivos, asumiendo que esta cuenta es: hbase_srv
2.3.2. Configuración de permisos
2.3.2.1 Generar HFile a través de la tarea MapReduce. El archivo HFile es u_mapreduce.
2.3.2.2. u_load requiere permisos de lectura y escritura para archivos y directorios HFile. El permiso de escritura se debe a que cuando el HFile abarca varias regiones, la operación de división debe realizarse en el HFile.
Además, la cuenta u_load requiere el permiso Crear de la tabla HBase
2.3.2.3 La cuenta hbase_srv cambia el nombre del archivo HFile del directorio de datos del usuario al directorio de datos de HBase. entonces hbase_sHrv necesita tener permisos de lectura de directorio y HFile, pero de hecho solo los permisos de lectura no son suficientes. Debería ser que el propietario del directorio HFile cargado en el directorio de datos de HBase sigue siendo u_mapreduce. . Una vez realizada la operación de compactación
, estos archivos no se pueden mover al directorio de archivo, lo que genera más y más archivos. Este problema se solucionó en HBase 2.x.
2.3.2. Impacto en la localidad
Si el clúster HDFS donde se genera HFile y el clúster HDFS donde se encuentra HBase son el mismo, MapReduce genera HFile, lo que puede garantizar que el HFile y la región de destino se encuentran en la misma máquina. Esto asegura la localidad. Toda la lógica está controlada por el parámetro hbase.bulkload.locality.SENSITIVE.ENABLED, cuyo valor predeterminado es verdadero. Por lo tanto, la localidad está garantizada de forma predeterminada.
Si el usuario MapReduce genera un HFile en el clúster A, cópielo en el clúster B a través de distcp. De esta manera, BulkLoad en los datos del clúster HBase no puede garantizar la localidad. Debe ejecutar manualmente el compact principal después de ejecutar BulkLoad para mejorar la loaclidad.
2.3.3. Replicación de datos de BulkLoad
En versiones anteriores a la 1.3, los datos de BulkLoad al clúster HBase no se copiarán al clúster en espera, lo que puede provocar el modo en espera sin querer. El clúster es más lento que el clúster principal. Al clúster le faltan muchos datos. La replicación de datos BulkLoad es compatible después de la versión 1.3 de HBase. Es necesario activar el interruptor: hbase.replicatition.bulkload.enabled=true.