Apache HBase es la base de datos de Hadoop y se basa en el sistema de archivos distribuidos de Hadoop (HDFS ). HBase permite acceder y actualizar aleatoriamente los datos almacenados en HDFS, pero los archivos en HDFS solo se pueden agregar y son inmutables una vez creados. Así que puede preguntarse, ¿cómo proporciona HBase lecturas y escrituras de baja latencia? En esta publicación de blog, explicamos esto describiendo la ruta de escritura de HBase:cómo se actualizan los datos en HBase.
La ruta de escritura es cómo un HBase completa las operaciones de poner o eliminar. Esta ruta comienza en un cliente, se mueve a un servidor de región y finaliza cuando los datos finalmente se escriben en un archivo de datos HBase llamado HFile. . En el diseño de la ruta de escritura se incluyen funciones que utiliza HBase para evitar la pérdida de datos en caso de que falle el servidor de la región. Por lo tanto, comprender la ruta de escritura puede proporcionar información sobre el mecanismo de prevención de pérdida de datos nativo de HBase.
Cada tabla de HBase está alojada y administrada por conjuntos de servidores que se dividen en tres categorías:
- Un servidor maestro activo
- Uno o más servidores maestros de respaldo
- Muchos servidores regionales
Los servidores de región contribuyen a manejar las tablas de HBase. Dado que las tablas de HBase pueden ser grandes, se dividen en particiones denominadas regiones. Cada servidor de región maneja una o más de estas regiones. Tenga en cuenta que debido a que los servidores regionales son los únicos servidores que sirven datos de tablas HBase, un bloqueo del servidor maestro no puede causar la pérdida de datos.
Los datos de HBase se organizan de manera similar a un mapa ordenado, con el espacio de claves ordenado dividido en diferentes fragmentos o regiones. Un cliente de HBase actualiza una tabla invocando comandos de colocación o eliminación. Cuando un cliente solicita un cambio, esa solicitud se enruta a un servidor regional de forma predeterminada. Sin embargo, mediante programación, un cliente puede almacenar en caché los cambios en el lado del cliente y descargar estos cambios en los servidores de la región en un lote, desactivando el autodescarga. Si la descarga automática está desactivada, los cambios se almacenan en caché hasta que se invoca la confirmación de descarga, o el búfer está lleno según el tamaño del búfer establecido mediante programación o configurado con el parámetro "hbase.client.write.buffer".
Dado que la clave de fila está ordenada, es fácil determinar qué servidor de región administra qué clave. Una solicitud de cambio es para una fila específica. Cada clave de fila pertenece a una región específica que es atendida por un servidor de región. Entonces, según la clave de poner o eliminar, un cliente HBase puede ubicar un servidor de región adecuado. En primer lugar, localiza la dirección del servidor de la región que aloja la región -ROOT- del quórum de ZooKeeper. Desde el servidor de la región raíz, el cliente averigua la ubicación del servidor de la región que aloja la región -META-. Desde el servidor de la región meta, finalmente localizamos el servidor de la región real que sirve a la región solicitada. Este es un proceso de tres pasos, por lo que la ubicación de la región se almacena en caché para evitar esta costosa serie de operaciones. Si la ubicación almacenada en caché no es válida (por ejemplo, obtenemos alguna excepción de región desconocida), es hora de reubicar la región y actualizar el caché.
Una vez que el servidor de la región correcta recibe la solicitud, el cambio no se puede escribir en un HFile inmediatamente porque los datos en un HFile deben ordenarse por clave de fila. Esto permite buscar filas aleatorias de manera eficiente al leer los datos. Los datos no se pueden insertar aleatoriamente en el HFile. En su lugar, el cambio debe escribirse en un archivo nuevo. Si cada actualización se escribiera en un archivo, se crearían muchos archivos pequeños. Tal solución no sería escalable ni eficiente para fusionar o leer en un momento posterior. Por lo tanto, los cambios no se escriben inmediatamente en un nuevo HFile.
En su lugar, cada cambio se almacena en un lugar de la memoria llamado memstore. , que admite escrituras aleatorias de manera económica y eficiente. Los datos en el memstore se ordenan de la misma manera que los datos en un HFile. Cuando el memstore acumula suficientes datos, todo el conjunto ordenado se escribe en un nuevo HFile en HDFS. Completar una tarea de escritura grande es eficiente y aprovecha las fortalezas de HDFS.
Aunque escribir datos en el memstore es eficiente, también presenta un elemento de riesgo:la información almacenada en el memstore se almacena en una memoria volátil, por lo que si el sistema falla, toda la información del memstore se pierde. Para ayudar a mitigar este riesgo, HBase guarda las actualizaciones en un registro de escritura anticipada (WAL ) antes de escribir la información en memstore. De esta forma, si un servidor de región falla, la información que estaba almacenada en el memstore de ese servidor se puede recuperar de su WAL.
Nota:De manera predeterminada, WAL está habilitado, pero el proceso de escribir el archivo WAL en el disco consume algunos recursos. WAL puede deshabilitarse, pero esto solo debe hacerse si el riesgo de pérdida de datos no es una preocupación. Si elige deshabilitar WAL, considere implementar su propia solución de recuperación ante desastres o prepárese para la posibilidad de pérdida de datos.
Los datos en un archivo WAL están organizados de manera diferente a HFile. Los archivos WAL contienen una lista de ediciones, con una edición que representa una sola colocación o eliminación. La edición incluye información sobre el cambio y la región a la que se aplica el cambio. Las ediciones se escriben cronológicamente, por lo que, para persistencia, las adiciones se agregan al final del archivo WAL que se almacena en el disco. Debido a que los archivos WAL están ordenados cronológicamente, nunca es necesario escribir en un lugar aleatorio dentro del archivo.
A medida que crecen los WAL, finalmente se cierran y se crea un nuevo archivo WAL activo para aceptar ediciones adicionales. Esto se denomina "desplazamiento" del archivo WAL. Una vez que se transfiere un archivo WAL, no se realizan cambios adicionales en el archivo anterior.
De forma predeterminada, el archivo WAL se ejecuta cuando su tamaño es aproximadamente el 95 % del tamaño del bloque HDFS. Puede configurar el multiplicador usando el parámetro:“hbase.regionserver.logroll.multiplier”, y el tamaño del bloque usando el parámetro:“hbase.regionserver.hlog.blocksize”. El archivo WAL también se ejecuta periódicamente según el intervalo configurado "hbase.regionserver.logroll.period", una hora de forma predeterminada, incluso el tamaño del archivo WAL es menor que el límite configurado.
Restringir el tamaño del archivo WAL facilita la reproducción eficiente del archivo si se requiere una recuperación. Esto es especialmente importante durante la reproducción del archivo WAL de una región porque mientras se reproduce un archivo, la región correspondiente no está disponible. La intención es eventualmente escribir todos los cambios de cada archivo WAL en el disco y conservar ese contenido en un HFile. Una vez hecho esto, el archivo WAL se puede archivar y, finalmente, el subproceso del demonio LogCleaner lo elimina. Tenga en cuenta que los archivos WAL sirven como medida de protección. Los archivos WAL solo necesitan reproducirse para recuperar las actualizaciones que, de lo contrario, se perderían después de un bloqueo del servidor regional.
Un servidor de región sirve a muchas regiones, pero no tiene un archivo WAL para cada región. En su lugar, un archivo WAL activo se comparte entre todas las regiones atendidas por el servidor de región. Debido a que los archivos WAL se transfieren periódicamente, un servidor de región puede tener muchos archivos WAL. Tenga en cuenta que solo hay un WAL activo por servidor de región en un momento dado.
Suponiendo que la raíz HBase predeterminada de "/hbase", todos los archivos WAL para una instancia de servidor de región se almacenan en la misma carpeta raíz, que es la siguiente:
/hbase/.logs/<host>, <port>,<startcode>
Por ejemplo:
/hbase/.logs/srv.example.com,60020,1254173957298
Los archivos de registro WAL se nombran de la siguiente manera:
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
Por ejemplo:
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Cada edición en el archivo WAL tiene una identificación de secuencia única. Esta identificación aumenta para preservar el orden de las ediciones. Cada vez que se transfiere un archivo de registro, la identificación de la siguiente secuencia y el nombre del archivo anterior se colocan en un mapa en memoria. Esta información se usa para rastrear la identificación de secuencia máxima de cada archivo WAL para que podamos determinar fácilmente si un archivo se puede archivar en un momento posterior cuando algún memstore se vacía en el disco.
Las ediciones y sus ID de secuencia son únicos dentro de una región. Cada vez que se agrega una edición al registro WAL, la identificación de secuencia de la edición también se registra como la última identificación de secuencia escrita. Cuando el almacén de memoria se vacía en el disco, se borra la última identificación de secuencia escrita para esta región. Si la última ID de secuencia escrita en el disco es la misma que la ID de secuencia máxima de un archivo WAL, se puede concluir que todas las ediciones en un archivo WAL para esta región se han escrito en el disco. Si todas las ediciones de todas las regiones en un archivo WAL se han escrito en el disco, está claro que no será necesario dividir ni reproducir, y el archivo WAL se puede archivar.
El balanceo de archivos WAL y el vaciado de memstore son dos acciones separadas y no tienen que ocurrir juntas. Sin embargo, no queremos mantener demasiados archivos WAL por servidor de región para evitar una recuperación que consume mucho tiempo en caso de que falle un servidor de región. Por lo tanto, cuando se transfiere un archivo WAL, HBase verifica si hay demasiados archivos WAL y decide qué regiones se deben vaciar para que algunos archivos WAL se puedan archivar.
En esta publicación, explicamos la ruta de escritura de HBase, que es cómo se crean y/o actualizan los datos en HBase. Algunas partes importantes son:
- Cómo un cliente localiza un servidor de región,
- Memstore que admite escrituras aleatorias rápidas,
- Archivos WAL como forma de evitar la pérdida de datos en caso de que falle el servidor de la región.
Hablaremos sobre formatos HFile, división de archivos WAL, etc. en publicaciones posteriores.
