icemd

@icemd

linkd.in/ICEMD

CanalICEMD

icemd

HBase
Introducción a HBase

▪ Puntos principales
• Introducción a HDFS
HDFS

▪ HDFS es un filesystem escrito es Java

• Basado en GFS (Google FileSystem)

▪ Se ejecuta sobre el filesystem nativo de la máquina

• ext3, ext4, etc

▪ Proporciona almacenamiento masivo de datos con redundancia

• Usa HW estándar
HDFS

• HDFS funciona mejor con ficheros grandes y un número razonable de

ellos
• Mejor millones de ficheros antes que miles de millones
• Cada fichero idealmente es de unos 100MB

• Los ficheros en HDFS se escriben solo una vez

• No se permite escrituras aleatorias a ficheros

• HDFS está optimizado para hacer lecturas grandes de ficheros

• No está optimizado para hacer lecturas aleatorias de ficheros
Cómo se guardan los ficheros en HDFS

• Los ficheros se dividen en bloques

• Normalmente los bloques son de 64 o 128MB

• Los datos son distribuidos en muchas máquinas cuando se cargan

• Los bloques son replicados en varias máquinas

• Cada nodo sabe qué bloques forman un fichero y donde están los
bloques de ese fichero
• Estos datos son conocidos como Metadata
Como acceder a HDFS

• La manera de acceder a HDFS es similar a acceder a los ficheros del

sistema

• Para acceder se usa el comando “hadoop fs”

• Existen comandos como mkdir, cat, ls, put, get, text, etc..
INTRODUCCIÓN A HBASE
Introducción a HBase

▪ Puntos principales
• Qué es HBase
• Por qué usar HBase
• HBase y RBDMS
• Pros y contras
• Conclusión
Qué es HBase

• HBase es una base de datos NoSQL que corre sobre HDFS

• HBase nos ofrece
• Alta disponibilidad y tolerante a fallos
• Muy escalable
• El número de columnas puede crecer ilimitadamente
• Puede gestionar tablas muy grandes
• Proyecto open-source de Apache

• HDFS nos ofrece

• Tolerancia a fallos
• Escalabilidad
Google BigTable

• HBase está basado en Google BigTable

• Google usa BigTable para muchos casos de uso

• Google Maps
• Google Analytics
• Gmail
• ...
Escenarios de usos de HBase

• Alta capacidad
• Puede almacenar muchos datos
- Cientos de gigabytes, terabytes o incluso petabytes

• Alto rendimiento para lecturas y escrituras

• 1000s operaciones/segundo por nodo
• Ejemplo: Facebook Messages
- 75000 millones de operaciones por día
- Hay picos de 1.5 millones de operaciones por segundo
- Se usa sólo HBase
Qué diferencia a HBase

▪ Hbase ayuda a solucionar accesos de datos aleatorios

▪ Escala muy fácilmente solucionando problemas de procesamiento
(búsquedas) y almacenamiento
▪ Las columnas en Hbase se pueden definir dinámicamente
Escenarios de usos (cont.)

▪ Escalable in-memory caching

• La memoria de caché es escalable
o Añadiendo más nodos se añade más caché
• Muchos datos son almacenados, pero solo una pequeña parte es
consultada frecuentemente
o Los datos usados que se consultan son cacheados
o Los mecanismos de caché se ejecutan transparentemente
o La caché aumenta el rendimiento no teniendo que hacer operaciones
IO
▪ Tipo de datos
• No se penalizan columnas vacías
• Ejemplo
o Filas donde frecuentemente no hay algunas columnas
Cuándo usar HBase

▪ Usar cuando
• Necesitas random lecturas y escrituras o ambos
• Necesitas hacer miles de operaciones por segundo sobre terabytes
• Tus patrones de acceso son bien conocidos y simples

▪ No usar cuando
• Sólo añades datos y tiendes a leer toda la tabla cuando haces
procesamiento
• Principalmente se ejecutan ad-hot queries, no es un patrón de acceso
determinista
• Tu dataset entra en un solo nodo
HBase en producción

▪ Muchas compañías están usando HBase en producción

▪ Algunas compañías que usan HBase en producción son

• eBay
• Facebook
• StumbleUpon
• TrendMicro
• Twitter
• Etc..
HBase no es una RDBMS tradicional

▪ HBase es una base de datos pero no es una RDBMS tradicional

▪ Una RDBMS es una base de datos tradicional como MySQL, Oracle o

Microsoft SQL Server
• Hbase no soporta SQL
• No podemos tener varios índices sobre la misma tabla
• No soporta transacciones
▪ HBase requiere una manera de pensar diferente
HBase no es una RDBMS tradicional
(cont)
Comparación con el diseño de una
RDBMS
▪ Escalar tablas en sistemas tradicionales suele significar particionar o
sharing los datos
• HBase particiona automáticamente los datos en elementos más pequeños

▪ En sistemas tradicionales puedes normalizar las tablas y usar joins

para recuperar los datos
• HBase no soporta joins explícitos
• Una búsqueda de una row key implícitamente hace un join de las column
families
Reemplazando diseño de RDBMS

▪ Podrías necesitar reemplazar HBase por otro software que tenemos

funcionando

▪ HBase no se puede reemplazar directamente

• Desarrollar para HBase requiere una manera de pensar diferente a
RDBMS
• Requerirá una reimplementación de tu arquitectura
• Necesitarás muchos más recursos y tiempo que ir de un RDBMS a otro
HBase vs RDBMS, Diseño de Esquema

▪ Pasos para diseñar un esquema RDBMS

• Determinar todos los tipos de datos que almacenar
• Determinar relaciones entre los datos
• Crear tablas, columnas y claves que relacionan las tablas

▪ Pasos para diseñar un esquema en HBase

• Determinar las maneras en las que se va a acceder a los datos
• Determinar los datos que se van a almacenar
• Crear data layouts y claves

▪ El esquema en HBase es data-centric no relationship-centric

Pros y Contras

▪ Hay características que tiene HBase que no están en RDBMSs

• Muy escalable
• Almacenamiento masivo de datos
• Tratamiento de “missing” columnas

▪ Hay características que están en RDBMS y no están en HBase

• SQL
• Transacciones
• Índices
Cuando usar HBase

▪ HBase no resuelve todos los problemas

• HBase solo resolverá problemas de acceso a los datos

▪ HBase no funciona bien en todos los escenarios

• HBase funciona muy bien para lo que ha sido diseñado
• Pero, podría ser imposible usarlo eficientemente en otras tareas

▪ Hay que cambiar la manera de abordar el problema

• Tienes que cambiar la mentalidad de trabajar igual que con una RDBMS
• Si piensas solucionar el problema como con una RDBMS no va a
funcionar
Conclusiones

▪ HBase es una base de datos NoSQL que corre sobre HDFS

▪ HBase no es un RDBMS tradicional

▪ HBase requiere una aproximación diferente

▪ Trabajar con HBase o RDBMS es un give-and-take

▪ HBase te da alto rendimiento al trabajar con tablas muy grandes

CONCEPTOS DE HBASE
Conceptos de HBase

▪ Puntos principales
• Conceptos de HBase
• Trabajando con HBase
• Conclusión
HBase Overview

▪ Definiciones
• Node
o Una máquina
• Cluster
o Grupo de nodos conectados y coordinados por otros nodos para
realizar tareas
• Master Node
o Nodo que realiza tareas de coordinación
• Slave Node
o Worker Node que ejecuta tareas que se le han asignado
• Daemon
o Proceso o programa que se ejecuta en segundo plano
Conceptos Fundamentales de HBase

▪ HBase almacena los datos en tablas

• Similar a las tablas de RDBMS, pero con algunas diferencias

▪ Las tablas de HBase son ordenadas

• Parecido a hashes en otros lenguajes

▪ Los datos son almacenados en HDFS

• Datos son divididos dentro de los bloques de HDFS y almacenados en
diferentes nodos del cluster
HBase Regions

• Las tablas de HBase están divididas en Regions

• Secciones de una tabla
• Similar a sharding o partitioning in RDBMS
• Los Regions son devueltos a los clientes por RegionServer
• RegionServer corren en cada slave node dentro del cluster
• RegionServer servirán típicamente varias Regions de diferentes
tablas
• Muy raramente un RegionServer servirá todas las Regions de una
tabla
HBase Master

▪ HBase Master es el demonio que coordina a los RegionServers

• Coordina qué Regions están gestionados por cada RegionServer
o Actualiza cuando se añaden o borran datos
• Gestiona la creación de nuevas tablas y otras operaciones de gestión
▪ En las nuevas versiones puede convivir un Master con un RegionServer
HBase y ZooKeeper

▪ Puedes tener varios HBase Master para conseguir alta disponibilidad

• Solo un Master controla el cluster
• Zookeeper gestiona la coordinación entre los Masters

▪ Los demonios de Zookeeper corren en los nodos maestros del cluster

• Cuando arrancan los maestros conectan con Zookeeper
• Compiten por quién va a gestionar el cluster
o El primero que conecta gana el control del cluster
• Si el actual Master falla, los Masters que queden compiten por gestionar
el cluster de nuevo
Localización de demonios en un cluster
Rows y Columns

▪ Tablas están compuestas por rows, columns y column families

▪ Cada row tiene una row key (similar a la clave en RDBMS)
• Rows son almacenadas ordenadamente para búsquedas eficientes

▪ Columns tienen los datos de la tabla

• Columnas puede creárse on the fly
o Una columna existe para una fila sólo si tiene datos
• Las celdas de las tablas son array de bytes

▪ Todas las columnas de una tabla pertenecen a una column family

• Colección de columnas

▪ Una tabla puede tener una o más column families

HBase Columns y Column Families

▪ Todas los miembros de una column family tienen el mismo prefijo

• Los “:” delimitan la column family del qualifier

▪ Tuning y manera de almacenamiento se puede definir a nivel de

column family
• Por ejemplo, número de versiones, compresión, etc

▪ Una column family puede tener cualquier número de columnas

• Columnas dentro de una column family están ordenadas y se almacenan
juntas
Ejemplo, Vista de una tabla

▪ Una columna consiste en una column family prefijo + qualifier

▪ Separar column families es útil cuando

• Datos son normalmente accedidos separadamente
• Cada column family tiene propiedades diferentes de almacenamiento
o Bloom filters, tamaño de bloque, etc
Almacenando datos en tablas

▪ Los datos en HBase se almacenan como array de bytes

• Cualquier cosa que se puede convertir en un array de bytes se puede
almacenar en HBase

▪ El tamaño de una celda no debería ser mayor de 10MB

▪ Las celdas que no contienen nada no son guardas y no ocupan

espacio

▪ Cada column family es almacenado en un fichero diferente

Tablas en HBase

▪ Un tabla de HBase es un distributed sorted map

• Row key + column key + timestamp → value
• Row key y values son solo bytes
• Se puede almacenar cualquier cosa que pueda ser serializable a un array
de bytes
Operaciones en HBase

▪ Todas las filas en HBase son identificadas por una row key
• Es como la clave principal en base de datos relacionales

▪ Get y Scan sirve para recuperar datos

• Get recupera un solo dato
• Scan recupera toda la tabla
• Scan puede recuperar un rango de la tabla

▪ Put inserta datos

• Put añade una nueva fila con un row key
Operaciones en HBase (cont.)

▪ Delete marca un dato para que sea borrado

• Delete borra una fila identificada por una row key
• Los datos no son borrados de HDFS, pero son marcados para que se
borren en el futuro
• El borrado se realiza en las compactaciones

▪ Increment permite operaciones atómicas

• Las celdas tienen un value almacenado como un “long”
• Increment permite inicializar ese valor o incrementarlo
• Increment permite acceso concurrente sin miedo a corromper los datos
Versiones

▪ Por defecto HBase guarda una versión por celda

▪ Las versiones son ordenadas descendentemente

Conclusión

• Las tablas de HBase son divididas en regiones que las devuelven

los Region Servers

• RegionServers son gestionados por el HBase Master

• HDFS y Zookeeper da alta disponibilidad a HBase

• Las tablas están compuestas por rows, columns y column families

• Cada fila tiene una sola row key

Título del Máster / Curso

API DE ADMINISTRACIÓN
Conceptos de HBase

▪ Puntos principales
• Como usar HBase Shell
• Cómo crear tablas
• Como usar Java API
• Métodos de Administración
• Conclusión
HBase Shell

▪ Es una shell interactiva para mandar comandos a HBase

▪ La shell está hecha en JRuby

• Recubre las llamadas de Java con Ruby
• Tiene sintaxis de Ruby
• Los parámetros se pasan diferente que la mayoría de las shells (se usan
comillas simples)
Ejecutando HBase Shell

▪ Ejecutar HBase shell

•
•
▪ Estado de HBase

•
•

▪ Para saber la versión de HBase podemos ejecutar el comando version

Sintaxis de Comandos

▪ Los comandos en la shell normalmente van seguidos de parámetros

▪ Otros parámetros más avanzados tienen la siguiente sintaxis

Shell Scripting

▪ HBase Shell soporta órdenes interactivas o en modo batch

• Puede ejecutar un script escrito en JRuby o Ruby y ese script pasárselo a
la shell

▪ Ejecutar script desde la shell

▪ Ejecutar script con parámetros desde la shell

Creación de Tablas

▪ Solo el nombre de la tabla y las column families necesitan ser

definidas a la hora de crear una tabla
• Se necesita definir los nombre de la tabla y column families
• Cada tabla debe de tener por lo menos una column family
• Todas las configuraciones pueden cambiar más tarde

▪ HBase no tiene el concepto de separar base de datos

• Todas las tablas están en el mismo namespace

▪ La creación de tablas es diferente de crear una tabla en una base de

datos relacional
• Las columnas no necesitan ser creadas
• El namespace no se necesita definir
 Creando tablas

▪ General

• Ejemplo
Creando NameSpaces

▪ Es posible crear namespaces para agrupar tablas

▪ Hbase tiene dos keyspaces
• hbase, donde se guardan tablas internas
• default, se usa para las tablas de usuario si no se especifica
ningún usuario
▪ Se usan las operaciones
• create_namespace
• drop_namespace
Java API

▪ HBase tiene un API en Java

• Es lo que se usa normalmente
• Otros lenguajes son soportados con otras aplicaciones

▪ Todas las tareas de administración se hacen llamando al API de Java

• Normalmente estas tareas se hacen desde la shell que llama al API de
Java

▪ Usar el API de Java es fácil

• Solo tienes que añadir los jars al classpath
• Instanciar los objetos pertinentes como cualquier otro proyecto.
Todo son array de bytes

▪ HBase almacena todo como arrays de bytes

▪ Muchos métodos del API de Java necesitan array de bytes como valor

▪ HBase tiene una clase llamada Bytes que te ayuda a convertir objetos
a array de bytes con métodos to
Usando al API de Administración
Listando Tablas

▪ Listar todas las tablas de HBase

▪ Shell

▪ Java API
Describir tablas

▪ Podemos obtener todos los detalles de una tabla

• Compresión, column families, etc

▪ Shell

▪ Java API
Disabling Tablas

▪ Cuando desactivas una tabla, se pone en modo mantenimiento

• Permite ejecutar varios comandos de mantenimiento
• Clientes no pueden acceder a la tabla mientras está en este estado
• Podría llegar a tardar varios minutos en desactivar una tabla

▪ Shell

▪ Java API
Enabling Tablas

▪ Cambia el estado de las tablas y la saca del modo de mantenimiento

▪ Shell

▪ Java API
Cambiar Características de las Tablas

▪ Las tablas pueden ser cambiadas después de su creación

• Toda la tabla puede ser cambiada
• Column families pueden ser creadas, añadidas o borradas

▪ Las tablas deben de estar en modo mantenimiento para hacer estos

cambios
• Se debe desactivar las tablas
• Activar después de haber hecho los cambios
Borrar un Tabla

▪ Borrar una tabla de HBase borra los ficheros de HDFS

• Se debe de desactivar primero la tabla

▪ Shell

▪ Truncar una tabla borrar todas las filas de una tabla

• Las características de la tabla no son afectadas
▪ Shell
Operaciones con Column Families

▪ Añadir una nueva column family

▪ Borrar una column family

▪ Modificar una column familiy con nuevos parámetros es también

posible
Conclusión

▪ La Shell de HBase nos permite realizar muchas tareas administrativas

▪ Todas las tareas administrativas se pueden realizar con la API de Java

▪ Las tablas deben ser desactivadas antes de poder realizar muchos de
los cambios y reactivadas después de realizarlos.
ACCEDIENDO A LOS DATOS DE HBASE
Consultar Datos en HBase

▪ Puntos principales
• Uso del API
• Getting datos
• Añadir y actualizar datos desde la Shell
• Deleting datos
• Scanning datos
• Coprocesadores
• Filtros
• Conclusión
Acceso a Datos de HBase

▪ Hay varias maneras de acceder a los datos de HBase dependiendo

del lenguaje que se use

▪ La principal manera es con el API de Java

▪ Para otros lenguajes se puede usar Thrift y REST

• Thrift se usa para lenguajes diferentes de Java
• REST se usa para acceder a través de llamadas HTTP

▪ La Shell puede ser usada también para acceder

• Normalmente es usada para pequeñas queries
Conectando con HBase

▪ Todas las conexiones usan la clase HTableInterface para conectarse

con una tabla de HBase
• Cada conexión sólo sirve para una única tabla
• Se deben de cerrar las conexiones después de realizar las operaciones
▪ HTableInterface da total acceso para interactuar con una tabla de
HBase
▪ Para conectarse se usa el siguiente código
Arrays de bytes

▪ HBase representa todos los datos en array de bytes

• Permite representar cualquier tipo de datos
• Las parámetros y datos devueltos vienen como array de bytes

▪ La clase Bytes permite convertir en los dos sentidos los datos que
necesitemos
Getting Data

▪ Los datos pueden ser accedidos desde HBase Shell, Java API o
usando Thrift

▪ La manera más común es a través del API de Java

▪ La Shell es usada normalmente para hacer tests.

▪ Get
• Usado para recuperar una sola fila
• Debes de saber exactamente la row key que quieres recuperar
Get desde la Consola

▪ La forma general

▪ Ejemplos
Get Java API
Recuperar sólo lo que necesitamos

▪ Hay que tratar de poner tantas restricciones como sea posible al

recuperar una fila
• Se transmiten menos datos por la red
• Una column family puede ser muy grande

▪ Se puede especificar recuperar toda una column family o un qualifier

específico desde la API de Java o la shell
• Usar addFamily o addColumn desde Java
Get Batching

▪ Permite ejecutar varias acciones del mismo tipo en una única llamada
• Ejecuta múltiples Gets dentro de una sola llamada
Get, recuperar más versiones

▪ Es posible recuperar las versiones previas también

Añadiendo o actualizando datos

▪ HBase no distingue entre actualizar o añadir nuevos datos

• Put inserta una row que no existe
• Put actualiza una row que existe

▪ Updates se pueden ejecutar sobre columnas concretas, no

modificando las otras
Insertando Nuevos Datos

▪ General

▪ Ejemplos
Insertando Nuevos Datos desde Java
Put Batching

▪ Batching permite ejecutar varios Puts para ser ejecutados como una
sola llamada
• Mejora el rendimiento y minimiza las llamadas a los RegionServers
• Es una buena práctica cuando realizamos muchos Puts
Borrando Datos

▪ Las rows pueden ser borradas a través de la Shell, el API de Java o

Thrift
▪
▪ HBase no borra físicamente las rows cuando ejecutamos la operación
• La fila se marca como borrada
• El borrado ocurre más tarde

▪ Las rows son borradas por la row key

▪ Delete puede ser ejecutado sobre una column family o columnas y el

resto de los datos permanecen intactos

▪ Se pueden lanzar operaciones de borrados con batching

Borrando Filas con delete y deleteAll

▪ General

▪ Delete

▪ Truncate
Delete con el API de Java

▪ Se puede borrar una fila entera o partes de una fila con el API de Java.
Scans

▪ Un Scan es usado cuando

• No conocemos la row key exacta
• Queremos recuperar un conjunto de row keys

▪ Scans puede ser limitados con una start y stop row key
• La start key es incluida en el resultado
• La stop key no es incluida en el resultado

▪ Scans puede ser configurados para recuperar solo ciertas columnas o

column families.

▪ Un Scan sin start ni stop key hará un scan sobre toda la tabla
Scans Caching

▪ Se puede configurar el número de filas que queremos recuperar como

si fuera un batch para mejorar el rendimiento
• Mejora el rendimiento
• Consume más memoria
 Scans (cont.)

• Ejemplo
•startRow jordena
•stopRow turnerb
Scan con la Shell

▪ Scan desde la shell

Scan con el API de Java
Coprocesadores

▪ HBase tiene algo parecido a los procedimientos almacenados de las

base de datos relacionales.

▪ Hay dos tipos de coprocesadores: Endpoints y Observers

▪ Endpoints permiten añadir nueva funcionalidad a HBase como si

fueran nuevos métodos
• Similares a los procedimientos de RDBMS

▪ Observers se ejecutan dentro de HBase

• Similares a los triggers en RDBMS
Endpoints

▪ Endpoints dan la posibilidad de añadir nuevos métodos a los

RegionServers

▪ Algunos algoritmos se pueden hacer en los RegionServers

• Algoritmos para realizar sumas, conteos, medias se pueden hacer con
endpoints
• Group by puede ser implementado con un endpoint

▪ Los endpoints puedes reducir el ancho de banda usado para devolver

el resultado al cliente
• De otra manera se tienen que pasar todos los datos al cliente y este debe
de realizar la operación.
Observers

▪ Observers se ejecutan dentro de los RegionSevers y se lanzan cuando

algo sucede

▪ Pre y post permiten a ejecutar un acción antes de que se realiza una

llamada.
• Operaciones como Get, Put, Scan tienen estas propiedades y se puede
ejecutar algo antes y después de realizarlas

▪ Permiten realizar una operación automáticamente cuando algo

sucede, por ejemplo
• Índices secundarios pueden ser implementados con observers
• Chequeos sobre seguridad antes de realizar una operación
Coprocesadores

▪ El uso de coprocesadores puede ser igual de útil como peligroso y

puede causar problemas en la estabilidad y rendimiento de HBase

▪ Los coprocesadores se ejecutan en el mismo proceso que los

RegionServers
• Un bug en un coprocesador puede hacer que todo el RegionServer se
caiga
• Un fallo en cascada podría hacer que todo el cluster falle

▪ Depurar coprocesadores puede ser muy difícil

Conclusión

▪ Get y Scan nos permite acceder a las filas de HBase

▪ Update nos permite actualizar los datos

▪ Delete nos permite borrar datos

▪ Usar coprocesadores para dar mayor funcionalidad a HBase

DISEÑO DE LA ROW KEY DE HBASE
Arquitectura de HBase

▪ Puntos principales
• Del esquema de RDBMS al de HBase
• Diseño de las Row Keys
• Conclusiones
HBase vs RDBMS

▪ HBase no es una base de datos relacional

▪ El diseño de las base de datos generalmente va hacia la normalización

• Cuando se normalizan los datos, no existe apenas redundancia

▪ En RDBMS normalmente hay muchas tablas pequeñas

• Lo que favorece la normalización

▪ HBase típicamente sólo tiene unas pocas tablas, pero muy grandes
• Estas tablas están desnormalizadas para evitar tener que hacer joins
HBase vs RDBMS (cont.)

▪ Las tablas de HBase tienen un número pequeño de column families

• Dentro de cada column family puedes tener miles de columnas
• Normalmente en las tablas de RBDMS hay pocas columnas

▪ HBase solo tiene una row key

• RDBMS puede tener muchos índices definidos por cada columna

▪ El diseño del esquema de HBase es muy diferente al de RBDMS

• Hay que fijarse muy bien en como definir la row key

▪ Cambiar RDBMS a HBase no es algo trivial

Aplicación No Centrada en el Dato

▪ Cuando se diseña una aplicación que usa RDBMS, normalmente se

mira las relaciones entre los datos
• Se dividen los datos en tablas con columnas
• Se crean relaciones entre las diferentes tablas

▪ Cuando se diseña una aplicación que usa HBase nos preocupamos de

cómo se va a acceder al dato
• Qué información queremos tener cuando hagamos un Get
• Qué información se accede conjuntamente
• Cómo distribuimos los datos en todos los RegionServers
Patrones de Acceso

▪ El patrón de acceso es algo muy importante en el diseño de una

aplicación con HBase
• Hay que descubrir cómo vamos a acceder a los datos

▪ La aplicación puede ser diferente si tenemos muchas lecturas o

muchas escrituras
• Algunas aplicaciones podrían centrarse en escrituras mientras otras en
lecturas
Patrón basado en Lecturas

▪ Evitar join tablas

• Colocar todos los datos que se van a leer juntos en una misma fila
• Desnormalizar las tablas que sea necesario para que podamos acceder a
todo de una vez

▪ Optimizar las row keys y las column families

• Las row keys necesitan ser optimizadas para los Gets
• Las column families necesitan ser optimizadas para un uso eficiente del
Block Cache. ¿Razón?
Patrón basado en Escrituras

▪ Optimizar las row key para que se distribuyan lo mejor posible entre
todos los RegionServers
• Usar solo un RegionServer es ineficiente

▪ Decidir cuando hacer join tiene sentido dependiendo de cuantas veces

se van a realizar en nuestra aplicación
Tipos de Datos

▪ Series temporales no funcionan bien para la distribución de datos

• Muchas datos se aglutinan en el mismo RegionServer

▪ Redes Sociales
• Qué ocurre si una persona famosa se introduce como clave. Algunos
RegionServer tienen mucha más carga que otros
Row Keys

▪ HBase solo tiene una row key

• Es mucho más importante la definición de una buena row key en HBase
que los índices en las RDBMS

▪ Muchas veces las row keys son claves compuestas

• La row key está generada a partir de varios datos
• Por ejemplo en lugar de solo <timestamp> podemos crear una row key
que sea <timestamp><source>
• Todas los datos son combinados para generar una sola row key
• Cada uno de los datos que añadimos a la row key nos da mayor
flexibilidad a la hora de hacer un Scan
Diseño de Row Keys

▪ Las row keys no pueden ser cambiadas

• Si queremos cambiarla tenemos que borrar e insertar la fila de nuevo

▪ Las filas se guardan ordenadas dentro de la tabla

▪ Las claves se ordenan lexicográficamente

• Por ejemplo, 1, 10, 100, 11, 12, ..
• Si quieres mantener un orden normal tiene que rellenar de ceros

▪ Elegir una buena row key es la clave para tener un buen rendimiento
en tu aplicación
Rendimiento, Row Keys

▪ Hacer una búsqueda directamente por una row key es lo que te va a

dar el mayor rendimiento

▪ Hacer una búsqueda por una columna es lo que peor rendimiento

tiene
• Cada valor de la columna tiene que ser comprobado durante el scan

▪ Si quieres el acceso más rápido debes de consultar por la row key

Row Keys Secuenciales

▪ Secuencias
• Tipo de row keys que incrementan secuencialmente como fechas, ids
• Se obtiene muy buenos rendimientos leyendo
• Escribir obtiene muy malos rendimientos porque todos los datos están en
el mismo RegionServer
Salted Row Keys

▪ Salted
• Se coloca un hash precalculado delante de tu clave original
• Por ejemplo <salt><timestamp> en lugar de solo el timestamp
• Mejora el rendimiento a la hora de hacer escrituras
• Empero las lecturas
Promoted Row Keys

▪ Uno de los campos de la tabla se coloca delante de la clave

▪ Por ejemplo <source><timestamp> en lugar de <timestamp><source>
▪ Mejora las escrituras porque se distribuye a lo largo de los
RegionServers
Random Row Key

▪ Random
• Se puede convertir tu clave usando MD5 u otro algoritmo
• Es el peor caso para lecturas
• Mejor caso para escrituras
Conclusión

▪ HBase no es una base de datos relacional

▪ Primar desnormalización en HBase para evitar joins

▪ El desarrollo de HBase no es centrado en el dato

▪ Debes de pensar mucho el diseño de tu row key

DISEÑO DEL ESQUEMA EN HBASE
Arquitectura de HBase

▪ Puntos principales
• Column Families
• Consideraciones en el diseño del esquema
• Hotspotting
• Conclusiones
Diseño de Column Families

▪ Se deben de usar nombre con caracteres normales

▪ Procura usar nombre cortos

• Nombres largos pueden suponer mucho espacio gastado

▪ Se recomienda no más de tres caracteres

▪ Column families permiten la separación de los datos

• Pon los datos en la misma column family si se van a acceder juntos
Consideraciones de las Column Families

▪ Flushing y compactaciones ocurren en las regiones

• Las compactaciones se ejecutan dependiendo del número de ficheros de
una column family
• A mayor número de column families, mayor va a ser la carga de IO

▪ Características como Bloom Filters, replicación, etc, se definen a nivel

de column family
Atributos para las Column Families
Compresión

▪ Compresión es recomendado para la mayoría de las column families

• No es recomendado para columnas que contienen datos ya comprimidos
como JPG, etc

▪ Se incluyen varios codecs como GZIP, LZO, Snnapy, etc

• Debes de elegir el codec apropiado según tus necesidades

▪ Se puede activar a nivel de colum family

Versiones, TTL, MIN_VERSIONS

• VERSIONS define cuantas versiones queremos guardar para una celda

determinada

• TTL especifica el tiempo de vida de una celda

• Una vez ese tiempo haya pasado, la celda será borrada automáticamente

• MIN_VERSIONS especifica el número mínimo de versiones que

queremos guardar
• Por defecto esta característica está desactivada
• Debe ser menor que el número de versiones
BLOCKSIZE

▪ BLOCKSIZE especifica el número mínimo de datos que va a ser leído

cuando el cliente solicite datos
• Mayores tamaños de BLOCKSIZE mejoran el rendimiento de scans
• Menores tamaños de BLOCKSIZE mejoran el rendimientos de accesos
aleatorios
BLOCKCACHE, IN_MEMORY

• La Block Cache es una caché en memoria para lecturas

• Usa LRU (least recently used) algoritmo para descartar datos cuando la
caché está llena

• Se puede configurar la BLOCKCACHE para evitar guardar los datos

que sean leídos a nivel de column family

• Se puede configurar IN_MEMORY para evitar que un bloque sea

descartado de caché sólo cuando sea necesario
BLOOMFILTER

• BloomFilter es una estructura de datos que permite saber si tenemos un

dato
• El resultado que devuelve es “no” o “podría”

• HBase soporta el uso de BloomFilters para mejorar el rendimiento de

lecturas
• Permite a los RegionServer saltar la lectura de muchos ficheros
• Ocupa cierto espacio en la cabecera de los HFile
Consideraciones del Esquema

• Diseñar el esquema en HBase requiere saber como funciona

internamente HBase
• Diseño de claves
• Como se dividen los datos en column families
• Elegir la apropiada configuración para cada column family

• Normalmente se hace lo mismo para todos los sistemas

• Optimizar índices, particionar datos, etc.
Consideraciones del Esquema (cont.)

▪ Debes de tener en cuenta las limitaciones de HBase

▪ Joins son muy costosos

• Ejecutarse en el lado del cliente
• Evitar cuando sea posible
• Los datos deberían estar desnormalizados para evitar hacer joins

▪ Las row keys deben de ser inteligente

• Aproveche que los datos se guardan ordenadamente
Índices Secundarios

▪ Qué ocurre si queremos realizar una consulta por algo diferente a la

row key

▪ Si necesitas hacer ad-hoc consultas, puede ser que necesitas un

RDBMS

▪ RDBMS vs HBase
• Ambas requieren espacio y procesamiento adicional
• RDBMS da más facilidad en la gestión de índices
• HBase escala mejor bajo gran cantidad de datos
Índices Secundarios en HBase

▪ Ejecutar filtros usando el API

• No hay un índice secundario creado
• No es una buena opción si vamos a realizar un scan de toda la tabla

▪ Crear un índice secundario

• Crear un índice secundario en otra tabla
• Periódicamente actualizar la tabla con MapReduce
Hotspotting

▪ Hotspotting ocurre cuando un pequeño número de RegionServer

gestionan la mayor parte de las peticiones

▪ Puede ocurrir por varias razones

• El pre-split o el split que se ha hecho automáticamente no es el óptimo
• Las regiones de una tabla no están distribuidos eficientemente a través
del cluster
Conclusión

▪ Comprimir y el uso de BloomFilters puede optimizar HBase sin una

línea de código

▪ Tablas suelen ser Tall-Narrow o Flat-Narrow

▪ Se pueden usar índices secundarios en HBase

▪ Hotspotting puede afectar al rendimiento de HBase

Bibliografia
▪HBase in Action

122
 icemd

@icemd

linkd.in/ICEMD

CanalICEMD

¡Gracias! icemd

Nombre ponente, puesto y empresa

contacto si procede