Big Data: HBase

6.1 Quién inventó HBase y por qué

En esta conferencia hablaremos de una herramienta tan maravillosa como Hbase, que recientemente ha ganado gran popularidad: por ejemplo, Facebook la usa como base de su sistema de mensajería, y eso ya dice mucho.

La conferencia hablará sobre el concepto de Big Table y su implementación gratuita, las características del trabajo y la diferencia con las bases de datos relacionales clásicas (como MySQL y Oracle) y los almacenamientos de valores clave como Redis, Aerospike y memcached. Como de costumbre, comencemos con la historia del problema. Como muchos otros proyectos de BigData, Hbase nació de un concepto desarrollado por Google. Los principios detrás de Hbase se describieron en el artículo Bigtable: un sistema de almacenamiento distribuido para datos estructurados .

Como discutimos en lecciones anteriores, los archivos ordinarios son bastante adecuados para el procesamiento de datos por lotes utilizando el paradigma MapReduce. Por otro lado, la información almacenada en archivos es bastante incómoda de actualizar; Los archivos también están privados de la posibilidad de acceso aleatorio. Para un trabajo rápido y conveniente con acceso aleatorio, existe una clase de sistemas nosql como el almacenamiento de valores clave, como Aerospike, Redis, Couchbase, Memcached. Sin embargo, el procesamiento por lotes suele ser muy inconveniente en estos sistemas. Hbase es un intento de combinar la comodidad del procesamiento por lotes con la comodidad de la actualización y el acceso aleatorio.

6.2 Modelo de datos

HBase es una base de datos clave-valor distribuida, orientada a columnas y multiversión.

• Los datos se organizan en tablas indexadas por una clave principal llamada RowKey en Hbase.
• Para cada clave RowKey, se puede almacenar un conjunto ilimitado de atributos (o columnas).
• Las columnas se organizan en grupos de columnas llamados Column Family. Como regla general, las columnas que tienen el mismo patrón de uso y almacenamiento se combinan en una familia de columnas.
• Para cada atributo, se pueden almacenar varias versiones diferentes. Las diferentes versiones tienen una marca de tiempo diferente.

Los registros se almacenan físicamente en el orden ordenado de RowKey. En este caso, los datos correspondientes a diferentes familias de columnas se almacenan por separado, lo que permite, si es necesario, leer datos solo de la familia de columnas deseada.

Cuando se elimina un determinado atributo, no se elimina físicamente de inmediato, sino que solo se marca con una bandera especial de lápida. La eliminación física de los datos ocurrirá más tarde, cuando se realice la operación de Compactación Mayor.

Los atributos que pertenecen al mismo grupo de columnas y que corresponden a la misma clave se almacenan físicamente como una lista ordenada. Cualquier atributo puede estar ausente o presente para cada clave, y si el atributo está ausente, esto no genera la sobrecarga de almacenamiento de valores vacíos.

Los nombres de la lista y el grupo de columnas son fijos y tienen un diseño claro. En el nivel de grupo de columnas, se establecen parámetros como el tiempo de vida (TTL) y el número máximo de versiones almacenadas. Si la diferencia entre la marca de tiempo de una versión en particular y la hora actual es mayor que TTL, la entrada se marca para su eliminación. Si el número de versiones de un determinado atributo supera el número máximo de versiones, el registro también se marca para su eliminación.

El modelo de datos de Hbase se puede recordar como una coincidencia de clave-valor:

<table, RowKey, Column Family, Column, timestamp> -> Value

6.3 Operaciones admitidas

La lista de operaciones admitidas en hbase es bastante simple. Se admiten 4 operaciones principales:

• Put : agrega una nueva entrada a hbase. La marca de tiempo de esta entrada se puede configurar a mano; de lo contrario, se configurará automáticamente a la hora actual.
• Obtener : Obtener datos para una RowKey específica. Puede especificar la Familia de columnas de la que tomaremos los datos y la cantidad de versiones que queremos leer.
• Escanear : leer registros uno por uno. Puede especificar el registro desde el que comenzamos a leer, el registro al que leer, el número de registros a leer, la Familia de Columnas desde la que se realizará la lectura y el número máximo de versiones para cada registro.
• Eliminar : marque una versión específica para su eliminación. No habrá eliminación física, se pospondrá hasta la siguiente Compactación Mayor (ver más abajo).

6.4 Arquitectura

HBase es una base de datos distribuida que puede ejecutarse en docenas o cientos de servidores físicos, lo que garantiza un funcionamiento ininterrumpido incluso si alguno de ellos falla. Por lo tanto, la arquitectura de HBase es bastante compleja en comparación con las bases de datos relacionales clásicas.

HBase utiliza dos procesos principales para su trabajo:

1. Servidor de región : sirve a una o más regiones. Una región es un rango de registros correspondientes a un rango específico de RowKeys consecutivas. Cada región contiene:

• El almacenamiento persistente es el principal almacenamiento de datos en HBase. Los datos se almacenan físicamente en HDFS, en un formato HFile especial. Los datos en HFile se almacenan en el orden ordenado de RowKey. Un par (región, familia de columnas) corresponde al menos a un HFIle.
• MemStore : búfer de escritura. Dado que los datos se almacenan en HFile d en orden, es bastante costoso actualizar el HFile por registro. En cambio, al escribir, los datos ingresan a un área de memoria especial de MemStore, donde se acumulan durante algún tiempo. Cuando MemStore se llena hasta un valor crítico, los datos se escriben en un nuevo HFile.
• BlockCache - caché para lectura. Le permite ahorrar significativamente tiempo en datos que se leen con frecuencia.
• Registro de escritura anticipada (WAL) . Dado que los datos se escriben en el memstore, existe cierto riesgo de pérdida de datos debido a un bloqueo. Para evitar que esto suceda, todas las operaciones antes de la implementación real de las manipulaciones caen en un archivo de registro especial. Esto le permite recuperar datos después de cualquier falla.

2. Servidor maestro : el servidor principal en el clúster de HBase. El maestro administra la distribución de regiones entre los servidores de regiones, mantiene un registro de regiones, administra el lanzamiento de tareas regulares y realiza otros trabajos útiles.

Para coordinar acciones entre servicios, HBase usa Apache ZooKeeper, un servicio especial diseñado para administrar configuraciones y sincronizar servicios.

Cuando la cantidad de datos en la región aumenta y alcanza un cierto tamaño, Hbase comienza a dividirse, una operación que divide la región en 2. Para evitar divisiones constantes de regiones, puede preestablecer los límites de las regiones y aumentar su máximo tamaño.

Dado que los datos de una región se pueden almacenar en varios HFiles, Hbase los fusiona periódicamente para acelerar el trabajo. Esta operación se llama compactación en Hbase. Las compactaciones son de dos tipos:

• Pequeña compactación . Se inicia automáticamente, se ejecuta en segundo plano. Tiene una prioridad baja en comparación con otras operaciones de Hbase.
• Compactación importante . Se lanza manualmente o cuando se producen ciertos desencadenantes (por ejemplo, mediante un temporizador). Tiene una alta prioridad y puede ralentizar significativamente el clúster. Las compactaciones mayores se realizan mejor en un momento en que la carga en el clúster es pequeña. Major Compaction también elimina físicamente los datos previamente marcados con tombstone.

6.5 Formas de trabajar con HBase

Carcasa HBase

La forma más fácil de comenzar con Hbase es usar la utilidad de shell hbase. Está disponible inmediatamente después de instalar hbase en cualquier nodo de clúster de hbase.

Hbase shell es una consola jruby con soporte integrado para todas las operaciones básicas de Hbase. El siguiente es un ejemplo de cómo crear una tabla de usuarios con dos familias de columnas, realizar algunas manipulaciones y colocar la tabla al final en el shell de hbase:

create 'users', {NAME => 'user_profile', VERSIONS => 5}, {NAME => 'user_posts', VERSIONS => 1231231231} 
put 'users', 'id1', 'user_profile:name', 'alexander' 
put 'users', 'id1', 'user_profile:second_name', 'alexander' 
get 'users', 'id1' 
put 'users', 'id1', 'user_profile:second_name', 'kuznetsov' 
get 'users', 'id1' 
get 'users', 'id1', {COLUMN => 'user_profile:second_name', VERSIONS => 5} 
put 'users', 'id2', 'user_profile:name', 'vasiliy' 
put 'users', 'id2', 'user_profile:second_name', 'ivanov' 
scan 'users', {COLUMN => 'user_profile:second_name', VERSIONS => 5} 
delete 'users', 'id1', 'user_profile:second_name' 
get 'users', 'id1' 
disable 'users' 
drop 'users'

API nativa

Como la mayoría de los otros proyectos relacionados con Hadoop, hbase se implementa en Java, por lo que la API nativa está disponible en Java. La API nativa está bastante bien documentada en el sitio web oficial. Aquí hay un ejemplo del uso de la API de Hbase tomado de allí:

import java.io.IOException;

import org.apache.hadoop.hbase.*;
import org.apache.hadoop.hbase.client.*;
import org.apache.hadoop.hbase.util.Bytes;

public class MyLittleHBaseClient {
  public static void main(String[] args) throws IOException {
	Configuration config = HBaseConfiguration.create();
	Connection connection = ConnectionFactory.createConnection(config);
	try {
  	Table table = connection.getTable(TableName.valueOf("myLittleHBaseTable"));
  	try {
    	Put p = new Put(Bytes.toBytes("myLittleRow"));
    	p.add(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"),
    	Bytes.toBytes("Some Value"));
    	table.put(p);

    	Get g = new Get(Bytes.toBytes("myLittleRow"));
    	Result r = table.get(g);
    	byte [] value = r.getValue(Bytes.toBytes("myLittleFamily"),
      	Bytes.toBytes("someQualifier"));

    	String valueStr = Bytes.toString(value);
    	System.out.println("GET: " + valueStr);

    	Scan s = new Scan();
    	s.addColumn(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"));
    	ResultScanner scanner = table.getScanner(s);
    	try {
       	for (Result rr = scanner.next(); rr != null; rr = scanner.next()) {
         	System.out.println("Found row: " + rr);
       	}
     	} finally {
       	scanner.close();
     	}
   	} finally {
     	if (table != null) table.close();
   	}
 	} finally {
   	connection.close();
 	}
  }
}

Thrift, REST y soporte para otros lenguajes de programación

Para trabajar desde otros lenguajes de programación, Hbase proporciona Thrift API y Rest API. En base a ellos, los clientes se construyen para los principales lenguajes de programación: python, PHP, Java Script, etc.

6.6 Algunas características de trabajar con HBase

1. Hbase se integra desde el primer momento con MapReduce, y se puede usar como entrada y salida usando TableInputFormat y TableOutputFormat especiales.

2. Es muy importante elegir la RowKey correcta. RowKey debe proporcionar una buena distribución uniforme entre las regiones, de lo contrario, existe el riesgo de las llamadas "regiones calientes", regiones que se usan con mucha más frecuencia que otras, lo que conduce a un uso ineficiente de los recursos del sistema.

3. Si los datos no se cargan de forma individual, sino inmediatamente en grandes lotes, Hbase admite un mecanismo especial de carga masiva que le permite cargar datos mucho más rápido que con puts individuales. BulkLoad es esencialmente una operación de dos pasos:

   • Formación de HFile sin la participación de puestos usando un trabajo especial de MapReduce
   • Insertar estos archivos directamente en Hbase

4. Hbase admite la salida de sus métricas al servidor de monitoreo de Ganglia. Esto puede ser muy útil al administrar Hbase para llegar al fondo de los problemas de hbase.

clave de fila

RowKey es el ID de usuario, que es un GUUID, una cadena especialmente generada para ser única en todo el mundo. Los GUUID se distribuyen uniformemente, lo que proporciona una buena distribución de datos entre servidores.

Familia de columnas

Nuestro almacenamiento utiliza dos familias de columnas:

• datos. Este grupo de columnas almacena datos que ya no son relevantes para fines publicitarios, como el hecho de que un usuario haya visitado ciertas URL. El TTL para esta familia de columnas se establece en 2 meses, el límite en el número de versiones es 2000.
• datos largos Este grupo de columnas almacena datos que no pierden su relevancia con el tiempo, como el sexo, la fecha de nacimiento y otras características del usuario “eterno”.

Altavoces

Cada tipo de datos de usuario se almacena en una columna separada. Por ejemplo, la columna Data:_v almacena las URL visitadas por el usuario y la columna LongData:gender almacena el sexo del usuario.

La marca de tiempo de este hecho se almacena como una marca de tiempo. Por ejemplo, en la columna Datos:_v, la marca de tiempo es la hora en que el usuario visitó una URL específica.

Esta estructura de almacenamiento de datos de usuario encaja muy bien con nuestro patrón de uso y le permite actualizar rápidamente los datos de usuario, obtener rápidamente toda la información necesaria sobre los usuarios y, utilizando MapReduce, procesar rápidamente los datos de todos los usuarios a la vez.

6.7 Alternativas

HBase es bastante complejo de administrar y usar, por lo que antes de usar HBase tiene sentido ver las alternativas:

• Bases de datos relacionales . Una muy buena alternativa, especialmente en el caso de que los datos quepan en una sola máquina. Además, en primer lugar, debe pensar en las bases de datos relacionales en el caso de que las transacciones de índices que no sean el primario sean importantes.

• Almacenamiento de valores clave . Los almacenamientos como Redis y Aerospike son más adecuados cuando se necesita latencia y el procesamiento por lotes es menos importante.

• Archivos y su procesamiento con MapReduce . Si los datos solo se agregan y rara vez se actualizan/cambian, entonces es mejor no usar HBase, sino simplemente almacenar los datos en archivos. Para simplificar el trabajo con archivos, puede usar herramientas como Hive, Pig e Impala.

El uso de HBase está justificado cuando:

• Hay muchos datos y no caben en una computadora/servidor
• Los datos se actualizan y eliminan con frecuencia.
• Existe una “clave” explícita en los datos, a la que conviene ligar todo lo demás
• Necesita procesamiento por lotes
• Necesita acceso aleatorio a los datos mediante claves específicas