El modelo de compactaciones está cambiando drásticamente con CDH 5/HBase 0.96. Esto es lo que necesita saber.
Apache HBase es un almacén de datos distribuido basado en un árbol de combinación con estructura de registro, por lo que el rendimiento de lectura óptimo sería tener un solo archivo por almacén (familia de columnas). Sin embargo, ese ideal no es posible durante los períodos de muchas escrituras entrantes. En cambio, HBase intentará combinar HFiles para reducir la cantidad máxima de búsquedas de disco necesarias para una lectura. Este proceso se llama compactación .
Las compactaciones eligen algunos archivos de una sola tienda en una región y los combinan. Este proceso implica leer KeyValues en los archivos de entrada y escribir los KeyValues que no se eliminan, están dentro del tiempo de vida (TTL) y no violan la cantidad de versiones. El archivo combinado recién creado reemplaza los archivos de entrada en la región.
Ahora, cada vez que un cliente solicita datos, HBase sabe que los datos de los archivos de entrada se mantienen en un archivo contiguo en el disco; por lo tanto, solo se necesita una búsqueda, mientras que antes se podía requerir una para cada archivo. Pero el disco IO no es gratis, y sin una atención cuidadosa, la reescritura de datos una y otra vez puede conducir a una sobresuscripción grave de la red y del disco. En otras palabras, la compactación consiste en intercambiar algo de E/S de disco ahora por menos búsquedas más adelante.
En esta publicación, aprenderá más sobre el uso y las implicaciones de las compactaciones en CDH 4, así como los cambios en el modelo de compactación en CDH 5 (que se volverá a basar en HBase 0.96).
Compactación en CDH 4
La compactación ideal elegiría los archivos que reducirán la mayor cantidad de búsquedas en las próximas lecturas y, al mismo tiempo, elegiría los archivos que necesitarán la menor cantidad de IO. Desafortunadamente, ese problema no se puede resolver sin el conocimiento del futuro. Como tal, es solo un ideal por el que HBase debería esforzarse y no algo que sea realmente alcanzable.
En lugar del ideal imposible, HBase usa una heurística para probar y elegir qué archivos en una tienda probablemente sean buenos candidatos. Los archivos se eligen con la intuición de que los archivos similares deben combinarse con archivos similares, lo que significa que los archivos que tienen aproximadamente el mismo tamaño deben combinarse.
La política predeterminada en HBase 0.94 (envío en CDH 4) busca en la lista de HFiles, tratando de encontrar el primer archivo que tenga un tamaño menor que el total de todos los archivos multiplicado por hbase.store.compaction.ratio. Una vez que se encuentra ese archivo, el HFile y todos los archivos con identificadores de secuencia más pequeños se seleccionan para compactarlos.
Para el caso predeterminado de que los archivos más grandes sean los más antiguos, este enfoque funciona bien:
Sin embargo, esta suposición sobre la correlación entre la antigüedad y el tamaño de los archivos es errónea en algunos casos, lo que lleva al algoritmo actual a elegir de manera subóptima. Por el contrario, los archivos de carga masiva pueden clasificarse de manera muy diferente, y en ocasiones lo hacen, de los HFiles que normalmente se vacían, por lo que son excelentes ejemplos:
Cambios de compactación en CDH 5
Las compactaciones han cambiado de manera significativa recientemente. Para HBase 0.96 y CDH 5, el algoritmo de selección de archivos se hizo configurable a través de HBASE-7516, por lo que ahora es posible tener políticas de compactación proporcionadas por el usuario. Este cambio permite a los usuarios más experimentados probar e iterar sobre cómo quieren ejecutar las compactaciones.
El algoritmo de selección de compactación predeterminado también se cambió a ExploringCompactionPolicy. Esta política es diferente de la antigua predeterminada en que garantiza que cada archivo en una compactación propuesta esté dentro de la proporción dada. Además, no solo elige el primer conjunto de archivos que tienen tamaños dentro de la relación de compactación; en su lugar, analiza todos los conjuntos posibles que no violan ninguna regla y luego elige algo que parece tener el mayor impacto por la menor cantidad de IO esperada. Para hacer eso, ExploringCompactionPolicy elige una compactación que eliminará la mayoría de los archivos dentro de la proporción, y si hay un empate, se da preferencia al conjunto de archivos que son de menor tamaño:
Se planean más cambios para versiones futuras, incluida la compactación en niveles, la compactación en franjas y la compactación basada en niveles.
Conclusión
Para algunos casos de uso, este trabajo no tendrá ningún impacto. Eso es algo bueno, ya que las compactaciones ya estaban bastante bien estudiadas. Sin embargo, para los usuarios que tienen grandes picos de tráfico o que usan cargas masivas, este trabajo puede generar grandes mejoras en los tiempos de espera de IO y en la latencia de las solicitudes. Para un caso de uso específico de carga masiva, hemos visto una reducción del 90 % en la E/S del disco debido a las compactaciones.
Estos son los resultados de un caso de prueba en PerfTestCompactionPolicies de HBase:
Echa un vistazo a este trabajo en CDH 5 (en versión beta en el momento de escribir este artículo) cuando se trata de un clúster cerca de ti.
Lecturas adicionales:
- Explorando la política de compactación
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
