Puntos de conocimiento HBase (3)

¿Cuáles son las características de HBase?

• Grande: una tabla puede tener miles de millones de filas y millones de columnas;
• Modeless: cada fila tiene una clave primaria ordenable y cualquier número de columnas. Las columnas se pueden agregar dinámicamente según sea necesario. Diferentes filas en la misma tabla pueden tener columnas completamente diferentes;
• Orientado a columnas: control de permisos y almacenamiento de columnas (familia), recuperación independiente de columnas (familia);
• Escasa: las columnas vacías (nulas) no ocupan espacio de almacenamiento, la tabla puede diseñarse para que sea muy escasa;
• Varias versiones de datos: los datos de cada celda pueden tener varias versiones. El número de versión se asigna automáticamente de forma predeterminada, que es la marca de tiempo cuando se inserta la celda;
  -Tipo de datos único: todos los datos en Hbase son una cadena sin un tipo.

¿La diferencia entre HBase y Hive?

Hive y Hbase son dos tecnologías diferentes basadas en Hadoop-Hive es un motor similar a SQL que ejecuta tareas de MapReduce, y Hbase es una base de datos NoSQL Key / vale sobre Hadoop. Por supuesto, estas dos herramientas se pueden utilizar al mismo tiempo. Al igual que usar Google para buscar y FaceBook para redes sociales, Hive se puede usar para consultas estadísticas, HBase se puede usar para consultas en tiempo real, los datos también se pueden escribir de Hive a Hbase, configuraciones y luego escribir desde Hbase de nuevo a Hive.

¿Para qué tipo de escenarios es adecuado HBase?

• ① Datos semiestructurados o no
  estructurados Los campos de estructura de datos no son lo suficientemente seguros o desordenados y es difícil extraer datos de acuerdo con un concepto adecuado para HBase. Tome el ejemplo anterior como ejemplo: cuando el desarrollo empresarial necesita almacenar el correo electrónico, el teléfono y la
  información de la dirección del autor , el RDBMS debe cerrarse para el mantenimiento, mientras que HBase admite el aumento dinámico.
• ② Registre
  cuántas columnas de una fila RDBMS muy dispersa son fijas, lo que desperdicia espacio de almacenamiento para columnas nulas. Como se mencionó anteriormente, las columnas cuyo HBase sea nulo no se almacenarán, lo que ahorra espacio y mejora el rendimiento de lectura.
• ③ Datos de múltiples versiones. Como se mencionó anteriormente, el valor ubicado según la clave de fila y la clave de columna
  puede tener cualquier número de valores de versión. Por lo tanto, es muy conveniente usar HBase para los datos que necesitan almacenar el historial de cambios.
  Por ejemplo, la dirección del autor en el ejemplo anterior cambiará. Generalmente, solo se necesita el valor más reciente en los negocios, pero a veces es posible que sea necesario consultar el valor histórico.
• ④ Gran cantidad de datos
  Cuando la cantidad de datos aumenta cada vez más, la base de datos RDBMS no puede admitirla y aparece una estrategia de separación de lectura y escritura. Un maestro se dedica a las operaciones de escritura y varios esclavos son responsables de las operaciones de lectura. El costo del servidor dobles.
  A medida que aumenta la presión, el Master no puede aguantar más. En este momento, es necesario dividir la base de datos. Separe los datos con poca correlación. Algunas consultas de unión ya no se pueden usar y se necesita la capa intermedia. A medida que aumenta la cantidad de datos, la
  cantidad de registros en una tabla se vuelve cada vez más grande y la consulta se vuelve muy lenta, por lo que debe dividir la tabla, como dividir la tabla en varias tablas según el ID para reducir el número de registros en una sola tabla. Cualquiera que haya experimentado estas cosas sabe lo arduo que es el proceso.
  Usar HBase es simple, simplemente agregue una máquina, HBase se dividirá y expandirá horizontalmente automáticamente, y la integración perfecta con Hadoop garantiza la confiabilidad de sus datos (HDFS) y el alto rendimiento de análisis de datos masivos (MapReduce).

Describe los principios de diseño de rowKey de HBase.

• (1) Principio de longitud de la clave de fila

Rowkey es un flujo de código binario. Muchos desarrolladores sugieren que la longitud de Rowkey debe ser de 10 ~ 100 bytes. Sin embargo, se recomienda que la longitud sea lo más corta posible y no exceda los 16 bytes.
Las razones son las siguientes:
① El archivo persistente de datos HFile se almacena de acuerdo con KeyValue. Si la clave de fila es demasiado larga, como 100 bytes, 10 millones de columnas de datos ocuparán 100 * 10 millones = mil millones de bytes, que es casi 1G Esto afectará en gran medida la eficiencia de almacenamiento de
HFile ; ② MemStore almacenará en caché parte de los datos en la memoria. Si el campo Rowkey es demasiado largo, la utilización efectiva de la memoria se reducirá y el sistema no podrá almacenar en caché más datos, lo que reducirá la eficiencia de recuperación. Por lo tanto, cuanto más corta sea la longitud de bytes de Rowkey, mejor.
③ Los sistemas operativos actuales son todos sistemas de 64 bits y la memoria está alineada a 8 bytes. El control es de 16 bytes y los múltiplos enteros de 8 bytes utilizan las mejores características del sistema operativo.

• (2) Principio de hash de clave de fila

Si Rowkey se incrementa por la marca de tiempo, no coloque la hora delante del código binario. Se recomienda usar el bit alto de Rowkey como un campo hash, generado por el ciclo del programa, y ​​poner el campo de tiempo en el bit bajo, lo que mejorará la distribución equilibrada de datos en cada servidor de regiones La probabilidad de lograr el equilibrio de carga. Si no hay un campo hash, el primer campo es la información de tiempo directamente, lo que generará un fenómeno candente de que todos los datos nuevos se acumulen en un RegionServer. De esta manera, la carga se concentrará en los RegionServers individuales cuando se realice la recuperación de datos. reduciendo la eficiencia de las consultas.

• (3) El principio único de Rowkey

La singularidad debe estar garantizada en el diseño.

Describe las funciones, similitudes y diferencias de escaneo y obtén HBase.

La implementación de consultas de HBase solo proporciona dos formas:
1) Obtener el único registro de acuerdo con la RowKey especificada, el método get (org.apache.hadoop.hbase.client.Get) El método Get se puede procesar de dos maneras: ClosestRowBefore se establece y ClosestRowBefore no está establecido en Rowlock. Se utiliza principalmente para garantizar la naturaleza transaccional de la fila, es decir, cada get está marcado con una fila. Puede haber muchas familias y columnas seguidas.
2) Obtener un lote de registros de acuerdo con las condiciones especificadas El método de escaneo (org.apache.Hadoop.hbase.client.Scan) realiza la función de consulta condicional usando el método de escaneo.
(1) Scan puede usar los métodos setCaching y setBatch para aumentar la velocidad (cambiar el espacio por tiempo);
(2) Scan puede usar setStartRow y setEndRow para limitar el rango ([start, end) start es un intervalo cerrado, end es un open intervalo). Cuanto menor sea el rango, mayor será el rendimiento.
(3) Scan puede agregar filtros a través del método setFilter, que también es la base para las consultas de paginación y de múltiples condiciones.

Describa en detalle la estructura de una célula en HBase.

Una unidad de almacenamiento determinada por filas y columnas en HBase se llama celda.
Celda: la celda determinada únicamente por {clave de fila, columna (= +), versión}. Los datos de la celda no tienen ningún tipo y están todos almacenados en formato de código de bytes.

Describa brevemente cuál es el propósito de compact en HBase, cuándo se activa, en qué dos se dividen, cuáles son las diferencias y cuáles son los parámetros de configuración relevantes.

En hbase, cada vez que los datos del almacén de memoria se descargan en el disco, se forma un archivo de almacenamiento.Cuando el número de archivos de tienda alcanza un cierto nivel, el archivo de archivo de almacenamiento debe compactarse.

El papel de Compact:

• ① Combinar archivos
• ② Borrar datos de versión obsoletos y redundantes
• ③ Mejorar la eficiencia de lectura y escritura de datos.

Se implementan dos métodos de compactación en HBase: minory major. La diferencia entre estos dos métodos de compactación es:

• La operación menor solo se usa para fusionar algunos archivos y limpiar versiones caducadas, incluidas minVersion = 0 y establecer ttl, y no realiza ninguna limpieza de datos eliminados y datos de versiones múltiples.
• La operación principal es realizar una operación de combinación en todos los StoreFiles en HStore en la Región, y el resultado final es ordenar y combinar un archivo.

Cada día se almacenan decenas de miles de millones de datos en HBase ¿Cómo garantizar que los datos se almacenen correctamente y que todos los datos se ingresen dentro del tiempo especificado sin datos residuales?

Análisis de demanda:
1) Diez mil millones de datos: demuestre que la cantidad de datos es muy grande;
2) Almacene en HBase: Demuestre que está relacionado con los datos escritos por HBase;
3) Asegure la exactitud de los datos: Diseñe la estructura de datos correcta para asegurar la exactitud;
4) Completado dentro del tiempo especificado: Existe un requisito para la velocidad del depósito.

Soluciones:
1) ¿Cuál es el concepto de decenas de miles de millones de datos? Suponiendo que los datos se escriben en 60 x 60 x 24 = 86400 segundos a lo largo del día, entonces la cantidad de escrituras por segundo es tan alta como 1 millón. Por supuesto, HBase no puede admitir millones de datos por segundo, por lo que estas decenas de miles de millones de datos pueden no ser en tiempo real. Escriba localmente, pero impórtelos en lotes. Se recomienda BulkLoad para la importación masiva (lectura recomendada: lectura y escritura HBase de Spark), y el rendimiento es varias veces mayor que el de la escritura ordinaria;

2) Almacenar en HBase: JavaAPI put realiza la escritura normal y se recomienda BulkLoad para la importación masiva;

3) Asegurar la exactitud de los datos: Aquí es necesario considerar el diseño de RowKey, la partición preconstruida y el diseño de la familia de columnas y otras cuestiones;

4) Se completa dentro del tiempo especificado, es decir, la velocidad de depósito no puede ser demasiado lenta y, por supuesto, cuanto más rápido mejor, use BulkLoad.

¿Cómo preconstruir regiones en regiones?

El propósito de la prepartición es principalmente especificar el número de particiones al crear la tabla. Planifique con anticipación que la tabla tenga múltiples particiones y el rango de intervalo de cada partición. De esta manera, la clave de fila se almacena de acuerdo con el intervalo de la partición al almacenar, lo que puede evitar el problema del punto de acceso de la región.

Por lo general, hay dos esquemas:
esquema 1: método de shell
create'tb_splits ', {NAME =>' cf ', VERSIONS => 3}, {SPLITS => [' 10 ',' 20 ',' 30 ']}
esquema 2 : Control del programa JAVA
① Muestreo, primero genere aleatoriamente un cierto número de claves de fila y clasifique los datos muestreados en una colección en orden ascendente;
② De acuerdo con el número de regiones particionadas previamente, divida toda la colección en partes iguales, es decir, las splitKeys;
③ HBaseAdmin .createTable (HTableDescriptor tableDescriptor, bytesplitkeys) puede especificar el splitKey de la pre-partición, es decir, el valor crítico de rowkey entre las regiones especificadas.

¿Cómo lidiar con el tiempo de inactividad de HRegionServer?

1) ZooKeeper monitoreará el estado en línea y fuera de línea de HRegionServer, y cuando ZK encuentre que un determinado HRegionServer está inactivo, notificará a HMaster para la conmutación por error;

2) El HRegionServer dejará de brindar servicios externos, es decir, la región de la que es responsable de suspender temporalmente los servicios externos;

3) HMaster transferirá la región responsable del HRegionServer a otros HRegionServers y restaurará los datos almacenados en el memstore del HRegionServer que no se hayan conservado en el disco;

4) Esta restauración se realiza mediante la reproducción WAL, el proceso es el siguiente:
① wal es en realidad un archivo, que existe en la ruta de / hbase / WAL / correspondiente al RegionServer.
② Cuando ocurre un tiempo de inactividad, lea el archivo wal en la ruta correspondiente al RegionServer, y luego divídalo en diferentes archivos temporales recovery.edits según las diferentes regiones.
③ Cuando la región se asigna al nuevo RegionServer, RegionServer verificará si hay recovery.edits al leer la región, y si hay recovery.edits, se restaurará.

¿Proceso de lectura y escritura de HBase?

• leer:

① HRegionServer almacena metatabla y datos de la tabla. Para acceder a los datos de la tabla, el Cliente primero accede a zookeeper y obtiene la información de ubicación de la metatabla de zookeeper, es decir, encuentra en qué HRegionServer está almacenada la metatabla.

② Luego el Cliente accede al HRegionServer donde se encuentra la Metatabla a través de la IP del HRegionServer recién obtenida, para leer la Meta, y luego obtener los metadatos almacenados en la Metatabla.

③ El Cliente accede al HRegionServer correspondiente a través de la información almacenada en los metadatos, y luego escanea el Memstore y Storefile del HRegionServer para consultar los datos.

④ Finalmente, HRegionServer responde al cliente con los datos consultados.

• escribir:

① El cliente primero visita el guardián del zoológico, encuentra la metatabla y obtiene los metadatos de la metatabla.

② Determine los servidores HRegion y HRegionServer correspondientes a los datos que se van a escribir actualmente.

③ El Cliente inicia una solicitud de escritura de datos al servidor HRegionServer, y luego el HRegionServer recibe la solicitud y responde.

④ El cliente escribe datos en HLog primero para evitar la pérdida de datos.

⑤ Luego escriba los datos en Memstore.

⑥ Si tanto HLog como Memstore se escriben correctamente, los datos se escriben correctamente.

⑦ Si Memstore alcanza el umbral, los datos de Memstore se descargarán en Storefile.

⑧ Cuando haya más y más Storefiles, se activará la operación de fusión compacta para fusionar demasiados Storefiles en un Storefile grande.

⑨ Cuando el Storefile se hace cada vez más grande, la Región se hará cada vez más grande.Cuando se alcanza el umbral, se activará la operación Split para dividir la Región en dos.

¿Cuál es el mecanismo interno de HBase?

Hbase es un sistema de base de datos que puede adaptarse a los negocios en línea.

• Almacenamiento físico: los datos persistentes de Hbase almacenan datos en HDFS.
• Gestión de almacenamiento: una tabla se divide en muchas regiones. Estas regiones se almacenan en muchos servidores de regiones de forma distribuida. Las regiones también se pueden dividir en tiendas. Hay memstore y storefile en la tienda.
• Gestión de versiones: la actualización de datos en hbase es esencialmente la adición continua de nuevas versiones, y la división de la región de fusión de archivos entre versiones se realiza mediante la operación compacta.
• Gestión de clústeres: ZooKeeper + HMaster + HRegionServer.

¿Para qué se utiliza el memstore en Hbase?

Para garantizar el rendimiento de la lectura aleatoria, se ordenan las teclas de fila en hfile.

Después de que la solicitud del cliente llega al servidor de regiones, para garantizar el orden de la clave de fila de escritura, los datos no se pueden escribir en el archivo h inmediatamente, pero cada operación de cambio se almacena en la memoria, es decir, en el almacén de memorias.

Memstore puede admitir fácilmente la inserción aleatoria de operaciones y garantizar que todas las operaciones se ordenen en la memoria.

Cuando el memstore alcanza una cierta cantidad, los datos del memstore se vacían en el archivo hfile, que puede aprovechar al máximo las ventajas de rendimiento de hadoop para escribir archivos grandes y mejorar el rendimiento de escritura.

Dado que el memstore se almacena en la memoria, si el servidor de regiones muere por algún motivo, se perderán los datos de la memoria.

Todo para garantizar que los datos no se pierdan, hbase escribirá la operación de actualización en un registro de escritura anticipada (WAL) antes de escribir en el memstore.

Los archivos WAL se agregan y escriben secuencialmente. Solo hay un WAL por servidor de regiones, y todas las regiones del mismo servidor de regiones se escriben en el mismo archivo WAL.

De esta manera, cuando falla un servidor de regiones, todas las operaciones se pueden volver a cargar en el memstore a través del archivo WAL.

¿Cuál es el enfoque de HBase en el diseño de modelos? ¿Cuántas familias de columnas es más apropiado definir en una tabla? ¿Por qué?

El número de familias de columnas depende de los datos de la tabla. En términos generales, el estándar de clasificación se basa en la frecuencia de acceso a los datos. Por ejemplo, se accede a algunas columnas de una tabla con relativa frecuencia, mientras que a otras se accede raramente. En este tiempo, esta tabla se puede dividir en Las dos familias de columnas se almacenan por separado para mejorar la eficiencia del acceso.

¿Cómo mejorar el rendimiento de lectura y escritura del cliente HBase? Por favor da un ejemplo

① Encienda el filtro bloomfilter. Encender bloomfilter es 3 o 4 veces más rápido que no encenderlo.
② Hbase tiene requisitos especiales de memoria. Si el hardware lo permite, asigne suficiente memoria para ello.
③ Modificando la exportación en hbase- env.sh HBASE_HEAPSIZE = 3000 # El valor predeterminado aquí es 1000m
④ Aumentar el número de RPC
Al modificar el atributo hbase.regionserver.handler.count en hbase-site.xml, el número de RPC se puede ampliar adecuadamente. El valor predeterminado de 10 es un poco pequeño.

¿Cuáles son las precauciones para la instalación del clúster HBase?

① HBase necesita compatibilidad con HDFS, así que asegúrese de que el clúster de Hadoop esté instalado antes de instalar HBase;
② HBase necesita compatibilidad con el clúster de ZooKeeper, así que asegúrese de que el clúster de ZooKeeper esté instalado antes de instalar HBase;
③ Preste atención a la compatibilidad de versiones de HBase y Hadoop ;
④ Preste atención a hbase-env La configuración correcta del archivo de configuración .sh y el archivo de configuración hbase-site.xml;
⑤ Preste atención a la modificación del archivo de configuración de los servidores de regiones;
⑥ Tenga en cuenta que la hora de cada nodo en el clúster debe sincronizarse; de ​​lo contrario, se informará un error al iniciar el clúster de HBase.

Al usar la marca de tiempo directamente como clave de fila, se producirán problemas importantes al escribir en una sola región, ¿por qué?

La clave de fila en la región se almacena de manera ordenada, si el tiempo está concentrado. Se almacenará en una región, dicha región tiene más datos y otras regiones tienen muy pocos datos, y los datos se cargarán muy lentamente. Este problema no se aliviará hasta que la región se divida.

Describa cómo resolver el conflicto causado por regiones demasiado pequeñas y demasiado grandes en HBase.

Se producen múltiples compactaciones cuando la región termina, lea los datos una vez y vuelva a escribirlos en hdfs, ocupando io, una región demasiado pequeña causará múltiples divisiones y la región se desconectará, lo que afectará los servicios de acceso. La mejor solución es ajustar hbase.hregion. max.filesizea 256 m .

¿Por qué no se recomienda utilizar demasiadas familias de columnas en HBase?

(Es una abreviatura CFde ColumnFamilyfamilia de columnas)

En la tabla Hbase, cada familia de columnas corresponde a una Tienda en la Región. Cuando el tamaño de la Región alcanza el umbral, se dividirá. Por lo tanto, si hay varias familias de columnas en la tabla, pueden ocurrir los siguientes fenómenos:

1. Hay varias tiendas en una región. Si el volumen de datos de cada CF está distribuido de manera desigual, por ejemplo, CF1 es 1 millón y CF2 es 10,000, el volumen de datos de CF2 en cada región es demasiado pequeño cuando se divide la región. Al consultar CF2, abarcará varias regiones, lo que reducirá la eficiencia.

2. Si los datos de cada CF se distribuyen uniformemente, como CF1 tiene 500,000, CF2 tiene 500,000 y CF3 tiene 500,000, el volumen de datos de cada CF en la Región será menor cuando la Región se divide, y se causará cuando se consulta un CF La probabilidad de cruzar varias regiones aumenta.

3. Múltiples CF representan múltiples Tiendas, lo que significa que hay múltiples MemStores (2MB), lo que conduce a un mayor consumo de memoria y una menor eficiencia de uso.

4. La actualización y compresión de la caché en la región son operaciones básicas, es decir, si una CF tiene una operación de actualización o compresión de la caché, otras CF también harán la misma operación al mismo tiempo. Cuando hay demasiadas familias de columnas, se producirá frecuentes problemas de IO.