Obtenga más información sobre las decisiones de diseño detrás del nuevo soporte de HBase para MOB.
Apache HBase es una base de datos de valores clave distribuida, escalable, eficaz y consistente que puede almacenar una variedad de tipos de datos binarios. Sobresale en el almacenamiento de muchos valores relativamente pequeños (<10K) y proporciona lecturas y escrituras de baja latencia.
Sin embargo, existe una creciente demanda de almacenamiento de documentos, imágenes y otros objetos moderados (MOB) en HBase mientras se mantiene una latencia baja para lecturas y escrituras. Uno de esos casos de uso es un banco que almacena documentos de clientes firmados y escaneados. Como otro ejemplo, es posible que las agencias de transporte deseen almacenar instantáneas del tráfico y los automóviles en movimiento. Estos MOB generalmente se escriben una vez.
Lamentablemente, el rendimiento puede degradarse en situaciones en las que se almacenan muchos valores de tamaño moderado (100 000 a 10 MB) debido a la presión de E/S cada vez mayor creada por las compactaciones. Considere el caso en el que 1 TB de fotos de las cámaras de tráfico, cada una de 1 MB de tamaño, se almacena en HBase diariamente. Partes de los archivos almacenados se compactan varias veces mediante compactaciones menores y, finalmente, los datos se reescriben mediante compactaciones mayores. Junto con la acumulación de estos MOB, la E/S creada por las compactaciones ralentizará las compactaciones, bloqueará aún más el vaciado del almacén de memoria y, finalmente, bloqueará las actualizaciones. Una gran tienda MOB desencadenará divisiones regionales frecuentes, lo que reducirá la disponibilidad de las regiones afectadas.
Para abordar estos inconvenientes, los ingenieros de Cloudera e Intel implementaron la compatibilidad con MOB en una rama de HBase (hbase-11339:HBase MOB). Esta rama se fusionará con el maestro en HBase 1.1 o 1.2, y ya está presente y es compatible con CDH 5.4.x también.
Las operaciones en MOB suelen ser de escritura intensiva, con actualizaciones o eliminaciones raras y lecturas relativamente infrecuentes. Los MOB generalmente se almacenan junto con sus metadatos. Los metadatos relacionados con los MOB pueden incluir, por ejemplo, el número de automóvil, la velocidad y el color. Los metadatos son muy pequeños en relación con los MOB. Por lo general, se accede a los metadatos para el análisis, mientras que a los MOB generalmente se accede aleatoriamente solo cuando se solicitan explícitamente con claves de fila.
Los usuarios quieren leer y escribir los MOB en HBase con baja latencia en las mismas API, y quieren una coherencia sólida, seguridad, instantáneas y replicación de HBase entre clústeres, etc. Para cumplir con estos objetivos, los MOB se sacaron de la ruta de E/S principal de HBase y se colocaron en una nueva ruta de E/S.
En esta publicación, aprenderá sobre este enfoque de diseño y por qué se seleccionó.
Posibles enfoques
Había algunos enfoques posibles para este problema. El primer enfoque que consideramos fue almacenar los MOB en HBase con políticas ajustadas de división y compactación:un MaxFileSize deseado más grande disminuye la frecuencia de la división de la región, y menos o ninguna compactación puede evitar la penalización por amplificación de escritura. Ese enfoque mejoraría considerablemente la latencia de escritura y el rendimiento. Sin embargo, junto con el número creciente de archivos almacenados, habría demasiados lectores abiertos en una sola tienda, incluso más de lo que permite el sistema operativo. Como resultado, se consumiría mucha memoria y se degradaría el rendimiento de lectura.
Otro enfoque fue utilizar un modelo HBase + HDFS para almacenar los metadatos y los MOB por separado. En este modelo, un solo archivo está vinculado por una entrada en HBase. Esta es una solución de cliente, y la transacción está controlada por el cliente; los MOB no consumen memorias del lado HBase. Este enfoque funcionaría para objetos de más de 50 MB, pero para MOB, muchos archivos pequeños conducen a un uso ineficiente de HDFS, ya que el tamaño de bloque predeterminado en HDFS es de 128 MB.
Por ejemplo, supongamos que un NameNode tiene 48 GB de memoria y cada archivo tiene 100 KB con tres réplicas. Cada archivo ocupa más de 300 bytes en la memoria, por lo que un NameNode con 48 GB de memoria puede almacenar alrededor de 160 millones de archivos, lo que nos limitaría a almacenar solo archivos MOB de 16 TB en total.
Como mejora, podríamos haber ensamblado los archivos MOB pequeños en archivos más grandes, es decir, un archivo podría tener múltiples entradas MOB, y almacenar el desplazamiento y la longitud en la tabla HBase para una lectura rápida. Sin embargo, mantener la consistencia de los datos y administrar los MOB eliminados y los archivos MOB pequeños en compactaciones es difícil.
Además, si utilizáramos este enfoque, tendríamos que considerar nuevas políticas de seguridad, perder las propiedades de atomicidad de las escrituras y, potencialmente, perder la copia de seguridad y la recuperación ante desastres proporcionada por la replicación y las instantáneas.
Diseño HBase MOB
Al final, debido a que la mayoría de las preocupaciones sobre el almacenamiento de MOB en HBase involucran la E/S creada por las compactaciones, la clave fue mover los MOB fuera de la administración por regiones normales para evitar divisiones de regiones y compactaciones allí.
El diseño HBase MOB es similar al enfoque HBase + HDFS porque almacenamos los metadatos y los MOB por separado. Sin embargo, la diferencia radica en un diseño del lado del servidor:memstore almacena en caché los MOB antes de que se vacíen en el disco, los MOB se escriben en un HFile llamado "archivo MOB" en cada descarga, y cada archivo MOB tiene varias entradas en lugar de un solo archivo. en HDFS para cada MOB. Este archivo MOB se almacena en una región especial. Toda la lectura y escritura puede ser utilizada por las API de HBase actuales.
Escribir y leer
Cada MOB tiene un umbral:si la longitud del valor de una celda es mayor que este umbral, esta celda se considera una celda MOB.
Cuando las celdas MOB se actualizan en las regiones, se escriben en WAL y memstore, al igual que las celdas normales. En el vaciado, los MOB se vacían en los archivos MOB y los metadatos y las rutas de los archivos MOB se vacían en los archivos de almacenamiento. Las funciones de coherencia de datos y replicación de HBase son nativas de este diseño.
Las ediciones MOB son más grandes de lo habitual. En la sincronización, la E/S correspondiente también es más grande, lo que puede ralentizar las operaciones de sincronización de WAL. Si hay otras regiones que comparten la misma WAL, la latencia de escritura de estas regiones puede verse afectada. Sin embargo, si se necesita la consistencia y la no volatilidad de los datos, WAL es imprescindible.
Las celdas pueden moverse entre archivos almacenados y archivos MOB en las compactaciones cambiando el umbral. El umbral predeterminado es 100 KB.
Como se ilustra a continuación, las celdas que contienen las rutas de los archivos MOB se denominan celdas de referencia . Las etiquetas se conservan en las celdas, por lo que podemos seguir confiando en el mecanismo de seguridad de HBase.
Las celdas de referencia tienen etiquetas de referencia que las diferencian de las celdas normales. Una etiqueta de referencia implica una celda MOB en un archivo MOB y, por lo tanto, se necesita una mayor resolución en la lectura.
En la lectura, el escáner de la tienda abre escáneres en la memoria y almacena archivos. Si se encuentra una celda de referencia, el escáner lee la ruta del archivo desde el valor de la celda y busca la misma clave de fila de ese archivo. La caché de bloques se puede habilitar para los archivos MOB en el análisis, lo que puede acelerar la búsqueda.
No es necesario abrir lectores a todos los archivos MOB; solo se necesita uno cuando se requiere. Esta lectura aleatoria no se ve afectada por la cantidad de archivos MOB. Por lo tanto, no necesitamos compactar los archivos MOB una y otra vez cuando son lo suficientemente grandes.
El nombre del archivo MOB es legible y consta de tres partes:el MD5 de la tecla de inicio, la fecha más reciente de las celdas en este archivo MOB y un UUID. La primera parte es la clave de inicio de la región desde donde se vacía este archivo MOB. Por lo general, los MOB tienen un TTL definido por el usuario, por lo que puede buscar y eliminar archivos MOB caducados comparando la segunda parte con el TTL.
Instantánea
Para ser más amigable con la instantánea, los archivos MOB se almacenan en una región ficticia especial, por lo que la instantánea, la exportación/clonación de tablas y el archivo funcionan como se espera.
Al almacenar una instantánea en una tabla, se crea la región MOB en la instantánea y se agregan los archivos MOB existentes al manifiesto. Al restaurar la instantánea, cree enlaces de archivo en la región MOB.
Limpiezas y compactaciones
Hay dos situaciones en las que se deben eliminar los archivos MOB:cuando el archivo MOB caduca y cuando el archivo MOB es demasiado pequeño y debe fusionarse con otros más grandes para mejorar la eficiencia de HDFS.
HBase MOB tiene una tarea en el maestro:escanea los archivos MOB, encuentra los caducados determinados por la fecha en el nombre del archivo y los elimina. Por lo tanto, el espacio en disco se recupera periódicamente mediante la antigüedad de los archivos MOB caducados.
Los archivos MOB pueden ser relativamente pequeños en comparación con un bloque HDFS si escribe filas en las que solo unas pocas entradas califican como MOB; además, puede haber celdas eliminadas. Debe eliminar las celdas eliminadas y fusionar los archivos pequeños en archivos más grandes para mejorar la utilización de HDFS. Las compactaciones MOB solo compactan los archivos pequeños y los archivos grandes no se tocan, lo que evita la compactación repetida en archivos grandes.
Algunas otras cosas a tener en cuenta:
- Sepa qué celdas se eliminan. En cada compactación principal de HBase, los marcadores de eliminación se escriben en un archivo del antes de que se eliminen.
- En el primer paso de las compactaciones MOB, estos archivos del se fusionan en otros más grandes.
- Se seleccionan todos los archivos MOB pequeños. Si la cantidad de archivos pequeños es igual a la cantidad de archivos MOB existentes, esta compactación se considera importante y se denomina compactación ALL_FILES.
- Estos archivos seleccionados se dividen por la clave de inicio y la fecha en el nombre del archivo. Los archivos pequeños en cada partición se compactan con archivos del para que las celdas eliminadas puedan eliminarse; mientras tanto, se genera un nuevo HFile con nuevas celdas de referencia, el compactador confirma el nuevo archivo MOB y luego carga de forma masiva este HFile en HBase.
- Después de que finalicen las compactaciones en todas las particiones, si se trata de una compactación de ALL_FILES, se archivan los archivos del.
El ciclo de vida de los archivos MOB se ilustra a continuación. Básicamente, se crean cuando se vacía el memstore y HFileCleaner los elimina del sistema de archivos cuando la instantánea no hace referencia a ellos o expiran en el archivo.
Conclusión
En resumen, el nuevo diseño MOB de HBase saca los MOB de la ruta principal de E/S de HBase y conserva la mayoría de las funciones de seguridad, compactación y creación de instantáneas. Se adapta a las características de las operaciones en MOB, hace que la amplificación de escritura de MOB sea más predecible y mantiene latencias bajas tanto en lectura como en escritura.
Jincheng Du es ingeniero de software en Intel y colaborador de HBase.
Jon Hsieh es ingeniero de software en Cloudera y miembro de PMC/confirmador de HBase. También es el fundador de Apache Flume y un committer en Apache Sqoop.
