Esta publicación se publicó originalmente a través de blogs.apache.org, la volvemos a publicar aquí en una forma ligeramente modificada para su conveniencia:
A primera vista, la arquitectura Apache HBase parece seguir un modelo maestro/esclavo en el que el maestro recibe todas las solicitudes, pero el trabajo real lo realizan los esclavos. Este no es realmente el caso, y en este artículo describiré qué tareas son manejadas por el maestro y los esclavos.
Regiones y servidores de regiones
HBase es el administrador de almacenamiento de Hadoop que proporciona lecturas y escrituras aleatorias de baja latencia sobre HDFS y puede manejar petabytes de datos. Una de las capacidades interesantes de HBase es la fragmentación automática, lo que simplemente significa que el sistema distribuye dinámicamente las tablas cuando se vuelven demasiado grandes.
La unidad básica de escalabilidad horizontal en HBase se denomina Región . Las regiones son un subconjunto de los datos de la tabla y son esencialmente un rango ordenado y contiguo de filas que se almacenan juntas.
Inicialmente, solo hay una región para una tabla. Como se muestra a continuación, cuando las regiones se vuelven demasiado grandes después de agregar más filas, la región se divide en dos en la clave central, creando dos mitades aproximadamente iguales.
En HBase, los esclavos se denominan Servidores de región . Cada servidor de región es responsable de servir un conjunto de regiones, y una región (es decir, un rango de filas) solo puede ser atendida por un servidor de región.
La arquitectura HBase tiene dos servicios principales:HMaster que es responsable de coordinar el clúster y ejecutar operaciones administrativas, y el HRegionServer responsable de manejar un subconjunto de los datos de la tabla.
HMaster, asignación de regiones y equilibrio
Como se mencionó anteriormente, HBase Master coordina el HBase Cluster y es responsable de las operaciones administrativas.
Un servidor de región puede servir a una o más regiones. Cada región se asigna a un servidor de región al inicio y el maestro puede decidir mover una región de un servidor de región a otro como resultado de una operación de equilibrio de carga. El maestro también maneja las fallas del servidor de región asignando la región a otro servidor de región.
La asignación de regiones y servidores de regiones se mantiene en una tabla del sistema denominada META. Al leer META, puede identificar qué región es responsable de su clave. Esto significa que para las operaciones de lectura y escritura, el maestro no está involucrado en absoluto y los clientes pueden ir directamente al servidor de región responsable de servir los datos solicitados.
Ubicar una clave de fila:¿Qué servidor de región es responsable?
Para colocar u obtener una fila, los clientes no tienen que comunicarse con el maestro, los clientes pueden comunicarse directamente con el servidor de región que maneja la fila especificada o, en el caso de un escaneo de cliente, pueden comunicarse directamente con el conjunto de servidores de región responsables de manejar el conjunto. de llaves:
Para identificar el Servidor de Región, el cliente realiza una consulta en la tabla META.
META es una tabla de sistema utilizada para realizar un seguimiento de las regiones. Contiene el nombre del servidor y un identificador de región que comprende un nombre de tabla y la clave de fila de inicio. Al observar la clave de inicio y la siguiente clave de inicio de la región, los clientes pueden identificar el rango de filas contenidas en una región en particular.
El cliente mantiene un caché para las ubicaciones de la región. Esto evita que los clientes accedan a la tabla META cada vez que se emite una operación en la misma región. En caso de que una región se divida o se mueva a otro servidor de región (debido a políticas de equilibrio o asignación), el cliente recibirá una excepción como respuesta y la memoria caché se actualizará obteniendo la información actualizada de la tabla META:
Como META es una tabla como las demás, el cliente tiene que identificar en qué servidor se encuentra META. Las ubicaciones de META se almacenan en un nodo de ZooKeeper cuando el maestro las asigna, y el cliente lee directamente el nodo para obtener la dirección del servidor de región que contiene META.
El diseño original de HBase se basó en BigTable, con otra tabla llamada -ROOT- que contenía las ubicaciones META y Apache ZooKeeper apuntándola. HBase 0.96 eliminó ese arreglo a favor de ZooKeeper únicamente, ya que META no se puede dividir y, por lo tanto, consta de una sola región.
API de cliente:responsabilidades principales y regionales
La API del cliente HBase Java tiene dos interfaces principales:
- Administrador de HBase permite la interacción con el "esquema de tabla" mediante la creación/eliminación/modificación de tablas, y permite la interacción con el clúster mediante la asignación/desasignación de regiones, la fusión de regiones, la solicitud de un vaciado, etc. Esta interfaz se comunica con el Maestro.
- HTable permite al cliente manipular los datos de una tabla específica mediante el uso de obtener, poner, eliminar y todas las demás operaciones de datos. Esta interfaz se comunica directamente con los servidores regionales responsables de manejar el conjunto de claves solicitado.
Esas dos interfaces tienen responsabilidades separadas:HBaseAdmin solo se usa para ejecutar operaciones de administración y comunicarse con el maestro, mientras que HTable se usa para manipular datos y comunicarse con las regiones.
Conclusión
Como hemos visto aquí, tener una arquitectura Maestro/Esclavo no significa que cada operación pase por el maestro. Para leer y escribir datos, el cliente HBase, de hecho, va directamente al servidor de región específico responsable de manejar las claves de fila para todas las operaciones de datos (HTable). El maestro es utilizado por el cliente solo para operaciones de creación, modificación y eliminación de tablas (HBaseAdmin).
Aunque existe el concepto de maestro, el cliente de HBase no depende de él para las operaciones de datos y el clúster puede seguir sirviendo datos incluso si el maestro deja de funcionar.
Matteo Bertozzi es ingeniero de software en el equipo de la plataforma y miembro de HBase Committer.
Si está interesado en HBase, asegúrese de registrarse en HBaseCon 2013 (13 de junio, San Francisco):EL evento comunitario para colaboradores, desarrolladores, administradores y usuarios de HBase. ¡El espacio es limitado!
