Balanceo en Impala para conseguir la Alta Disponibilidad (HA)

Etiquetas

, ,

Normalmente las aplicaciones clientes de Impala se conectan a un único host y puerto donde se está escuchando el demonio de impala (21050).

Una vez que le llega la petición al servidor receptor este se encarga de distribuir el trabajo entre los distintos nodos impala que tenga el cluster. Pero en caso de una caída del servidor donde se conecta el cliente nos quedaríamos sin servicio hasta que volviese a estar operativo, aunque hubiese otros nodos impala operativos.

La forma habitual de conseguir el HA en impala es configurando un balanceador que distribuya las peticiones entre los distintos nodos impala y que en caso de indisponibilidad de un servicio reenvíe la petición a otro nodo.

Habría otra opción en Sofia2 para conseguir la alta disponibilidad sin utilizar un balanceador y sería modificando el cliente de manera que si no se puede conectar a un servidor Impala lo intentase con otro (al estilo de como se hace con MongoDB).

Página de Cloudera, “Using Impala through a Proxy for High Availability” donde especifica como configurar el software HAproxy para funcionar como balanceador Impala.

Anuncios

Hablando de la suma infinita de los números naturales 1+2+3… = -1/12

Etiquetas

Ayer vi este vídeo ASTOUNDING: 1 + 2 + 3 + 4 + 5 + … = -1/12 y teniendo claro que no soy ningún experto en esos temas y que la distancia que me separa de los máquinas en matemáticas es abismal, me lanzo al abismo (cual tertuliano de la tele) y digo que no esa demostración no me convence.

Por

La primera suma hasta el infinito S1 = 1 – 1 + 1 – 1 … = ½

Creo que la explicación que da es demasiado ligera valdría si estuviésemos hablando de un sumatorio finito, pero estamos hablando que nos vamos al infinito… pero entiendo yo que habrá demostraciones más robustas de esto

Luego tenemos la siguiente suma: S2 = 1 – 2 + 3 – 4 + 5 – 6….

La jugada que hace para multiplicarla por 2 de “desplazar” una e ir sumando a trozos no me convence

Si fuese una suma que no divergiera y que no fuese al infinito lo veo totalmente correcto pero no es el caso porque con esa estrategia de sumas agrupadas se puede conseguir los valores que se quieran (cuando diverge y va al infinito), me explico con un ejemplo:

Tengo la suma S1 = 1 + 2 + 3 + 4 + 5 ….. y si la resto a si misma utilizando ese sistema me encuentro con 3 resultados distintos:

Cero (sin desplazamiento)

Cero

 

 

 

 

Infinito (desplazando un puesto el segundo sumando)

Infinito

 

 

 

 

– Infinito (desplazando un puesto el primer sumando)

infinitoMenos

 

 

 

 

Resumiendo, que no sé qué dirá la matemática formal de la suma de series infinitas divergentes, pero realizar la suma por distintas agrupaciones puede llevar distintos resultados. Como la serie no tiene fin y diverge y al elegir la agrupación de la suma estoy priorizando unos sumandos frente a otros.

Balanceo de carga con HAProxy

Etiquetas

, , ,

HAProxy es un balanceador de carga TCP Open Source de uso general para mejorar el rendimiento de los sitios y servicios TCP mediante la difusión de las solicitudes a través de múltiples servidores.

HAProxy es utilizado en múltiples sitios muy populares en Internet como Reddit, Tumblr, Twitter y se utiliza en el producto OpsWorks de Amazon Web Services

La configuración de HAProxy es muy sencilla y tiene una opción de “stats” que habilita la generación de estadísticas. Y a parte permite utilizar parámetro cookie para conseguir el mantenimiento de sesión por host.

Un ejemplo de uso de HAProxy sería el siguiente:

Instalamos socat para ver el balanceo de las conexiones

    yum install socat

Instalamos HAProxy

    yum install haproxy

Arrancamos HAProxy

    /etc/init.d/haproxy start

En una consola arrancamos un proceso que escuche en el puerto 5001

    socat – TCP4-LISTEN:5001,reuseaddr,fork

En otra consola arrancamos otro proceso que escucha en el puerto 5002

    socat – TCP4-LISTEN:5002,reuseaddr,fork

Y utilizamos la “navaja suiza” netcat para abrir y cerrar conexiones TCP al puerto 5000 que es el que está escuchando HAProxy y ver como van de un nodo a otro

echo “vale” | nc localhost 5000

echo “venga” | nc localhost 5000

HAProxy4

HAProxy2

HAProxy5

El ejemplo mostrado funciona con la configuración por defecto de HAProxy aun así copio el fichero de configuración /etc/haproxy/haproxy.cfg que hemos utilizado:

#———————————————————————
# Las opciones globales
#———————————————————————

log 127.0.0.1 local2

chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon

# turn on stats unix socket
stats socket /var/lib/haproxy/stats

#———————————————————————
# Valores comunes para todas las secciones
#———————————————————————

defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

#———————————————————————
# Algoritmo round robin para el balanceo entre los backends
#———————————————————————
backend app
balance roundrobin
server app1 127.0.0.1:5001 check
server app2 127.0.0.1:5002 check

Monitorización en MongoDB

Etiquetas

, ,

MongoDB es una base de datos NoSQL orientada a documentos. Almacena una estructura de datos de tipo JSON con un esquema dinámico.

Los productos que menciona MongoDB en su Web para monitorizar son los siguientes:

http://docs.mongodb.org/manual/administration/monitoring/#third-party-tools

 

Imagen

 

1.1         Ganglia

http://sourceforge.net/apps/trac/ganglia/wiki

Script de Python que reporta operaciones por segundo, como el uso de memoria, las estadísticas btree, estado del master / slave y las conexiones actuales.

Es un sistema de control distribuido escalable para sistemas de computación de alto rendimiento, tales como clusters y Grids. Se basa en un diseño jerárquico dirigido a las federaciones de agrupaciones. Aprovecha las tecnologías utilizadas como XML para la representación de datos, XDR para compacto, transporte de datos portátil y RRDtool para el almacenamiento de datos y visualización. Utiliza las estructuras de datos y algoritmos cuidadosamente diseñados para lograr los gastos generales por nodo muy bajos y alta concurrencia

 

1.2         mikoomi-mongodb

https://code.google.com/p/mikoomi/wiki/03

Este plugin monitoriza la disponibilidad, utilización de recursos, el estado, el rendimiento y otros parámetros importantes de un entorno de MongoDB. Se integra con Zabbix

 

1.3         nagios-plugin-mongodb

https://github.com/mzupan/nagios-plugin-mongodb

Plugin para monitorizar MongoDB que se integra con Nagios

Chequea entre otros los siguientes parámetros:

  • Memoria usada
  • Conexiones abiertas
  • Porcentaje del tiempo de bloqueos
  • Promedio de tiempo de los flush
  • Tamaño de la base de datos…

Hadoop y Machine Learning

Etiquetas

, ,

Hadoop

Framework open-source que permite el tratamiento distribuido de grandes cantidades de datos mediante clusters de máquinas

  • La tecnología Big Data cubre tres dimensiones: Volumen, Velocidad y Variedad
  • Y Hadoop es Big Data por ser: Económico, Escalable, Eficiente y Confiable

Ecosistema Hadoop

HDFS: Hadoop Distributed File System

• Sistema de ficheros distribuido que se abstrae del almacenamiento físico y ofrece una visión única de todos los recursos de almacenamiento del cluster

• Ofrece las capacidades de tolerancia a fallos y capacidades de almacenamiento masivo, redundando entre distintas máquinas la información

MapReduce

• Framework para construir fácilmente aplicaciones distribuidas que procesan grandes volúmenes de información en paralelo, tanto datos estructurados como desestructurados

• El framework maneja transparentemente los fallos de hardware

El proceso Map transforma pares de datos de un determinado dominio en una lista de pares de un dominio diferente

El proceso Reduce transforma la lista de pares en colecciones de valores

Mahout

Tiene algoritmos de recomendación, clustering y clasificación

Algoritmo Descripción breve Caso de uso
Regresión logística, resuelta por gradiente estocástico descendiente (SGD) Clasificador brillante, rápido, simple y secuencial, capaz de aprendizaje on-line en entornos exigentes Recomienda publicidad a los usuarios, clasifica texto en categorías
Modelos ocultos de Markov (HMM) Implementaciones secuenciales y paralelas del algoritmo clásico de clasificación diseñado para modelar procesos del mundo real cuando el proceso de generación subyacente es desconocido Etiquetado de texto a parir de una parte del discurso. Reconocimiento del discurso
Descomposición de valor singular (SVD) Diseñado para reducir el ruido en matrices grandes, haciendo con esto que sean más pequeñas y que sea más fácil trabajar con ellas Precursor del almacenamiento en clúster, los recomendadores y la clasificación. Su usa para realizar selección de recursos automáticamente
Algoritmo Descripción breve Caso de uso
Almacenamiento en clúster Dirichlet Enfoque de almacenamiento en clúster basado en modelo, que determina la propiedad con base en si los datos se ajustan al modelo subyacente Útil cuando los datos tienen sobreposición o jerarquía
Almacenamiento en clúster espectral Es una familia de enfoques similares que usa un enfoque basado en gráficas para determinar la membresía a clúster Como el resto de los algoritmos de almacenamiento en clúster, es útil para explorar conjuntos de datos grandes y sacar información de esos conjuntos de datos
Almacenamiento en clúster Minhash Utiliza una estrategia de hash para agrupar elementos similares, produciendo así clústeres Igual a los otros enfoques de clúster
Numerosas mejoras de recomendador Co-ocurrencia distribuida, SVD, mínimos cuadrados alternantes Sitios de citas, e-commerce. Recomendaciones de películas, libros, productos…
Colocaciones Implementación de colocación reducida por correlacionamiento Encontrar frases estadísticamente interesantes en texto

Integración de R en Hadoop

• R es un lenguaje de programación estadística para realizar análisis de datos y poder representar gráficamente los resultados

• Las capacidades de R permiten realizar análisis estadísticos y predictivo, minería de datos y funciones de visualización de los datos

• Aplica en múltiples ámbitos como: finanzas, ventas, fabricación, mundo académico…

R + Streaming: Se utiliza para ejecutar scritps de R utilizando la tecnología MapReducede Hadoop

Rhipe: es un proyecto de código abierto que permite integrar MapReduce con R en el cliente

Rhadoop: Proporciona una wrapper sobre R para facilitar la integación con MapReduce

Criterios R + Streaming Rhipe RHadoop
Instalación Fácil. El paquete de Rnecesita ser instalado encada DataNode, pero los paquetesestán disponibles en los repositorios de

Yum

Alta. R debe estar instalado en cada unoDataNode, junto con el Protocol Buffers y Rhipe. La instalación conjunta no es automática Moderada. R debe ser instaladoen cada DataNode y Rhadoop tiene dependencias enotros paquetes R. Pero estospaquetes se pueden instalar con CRAN
Integración Cliente con R Ninguna. Hay que utilizar la consola con Hadoop para ejecutar un trabajo de Streaming,Especificando los argumentos Alta. Rhipe es una biblioteca de R que ejecuta los trabajos en MapReduce cuandola función correspondiente se llama. La librería se encarga de la logística de transporteellos y invocarlosdel mapa y reducir las tareas Alta. RHadoop es también un Rbiblioteca, donde los usuarios definen sus funciones de mapeo y de reducción en R
Tecnologías subyacentes Streaming Rhipe utiliza su propias funciones java para realizar el MapReduce y transmite los datos en el protocolo Protocol Buffers RHadoop es una capa de recubrimiento sobre Hadoop y Streaming. No implementa su propio MapReduce si no que recubre R y ejecuta los comandos con Streaming.
Opciones Cuando aplica A tener en cuenta
R y Streaming Cuando se quiere un control avanzado sobre las funciones MapReduce como en las particiones y en las clasificaciones Difícil de invocar directamente desde otros Scritps R en comparación con las otras opcioens
Rhipe Para poder ejecutar R y MaprReduce sin tener que salir del proceso R Requiere de entrada y salida propia.El formato con los que trabaja es Protocol Buffers
RHadoop Permite tener acceso a R y a MapReduce desde un proceso R. También permite trabajar con un proceso MapReduce existente y con un formato de clases de salida Es necesario que haya suficiente memoriapara almacenar todos los valores necesarios para la reducción

Caso práctico: Recomendación de productos

Copia de los ficheros de usuarios y de las opiniones en HDFS

hadoop fs -put user-ids.txt ratings.csv .

Ejecutar el algoritmo de recomendación de items de Mahout

mahout recommenditembased -Dmapred.reduce.tasks=3 –similarityClassname SIMILARITY_PEARSON_CORRELATION –input ratings.csv –output item-rec-output — tempDir item-rec-tmp –usersFile user-ids.txt

Mostrar el resultado

hadoop fs -cat item-rec-output/part*

Caso práctico: La media diaria del stock

Copia de los datos del almacén en HDFS

hadoop fs -put test-data/stocks.txt stocks.txt

Ejecución del Script de R en Hadoop

hadoop jar /home/gpadmin/.m2/repository/org/apache/hadoop/hadoop-streaming/2.0.2-alpha-gphd-2.0.1.0/*.jar -D mapreduce.job.reduces=0 -inputformat org.apache.hadoop.mapred.TextInputFormat -input stocks.txt -output output -mapper stock_day_avg.R -file stock_day_avg.R

Mostrar el resultado

hadoop fs -cat output/part*

Loggeo JavaScript en el servidor mediante GET

Etiquetas

Hace un tiempo se comentaba en este blog el framework Javascript log4javascript para el loggeo de eventos Javascript en el servidor

El framework tiene todo lo que se le puede pedir a un log de eventos JavaScript no basado en Aspectos:

· Que funcione en todos los navegadores modernos: Internet Explorer > 6, Firefox > 9, Chrome en sus distintas versiones, Safari…

· Distintas categorías de traceo:

o FATAL: se utiliza para mensajes críticos del sistema, generalmente después de guardar el mensaje el programa abortará.

o ERROR: se utiliza en mensajes de error de la aplicación que se desea guardar, estos eventos afectan al programa pero lo dejan seguir funcionando, como por ejemplo que algún parámetro de configuración no es correcto y se carga el parámetro por defecto.

o WARN: se utiliza para mensajes de alerta sobre eventos que se desea mantener constancia, pero que no afectan al correcto funcionamiento del programa.

o INFO: se utiliza para mensajes similares al modo “verbose” en otras aplicaciones.

o DEBUG: se utiliza para escribir mensajes de depuración, este log no debe estar activado cuando la aplicación se encuentre en producción.

o TRACE: se utiliza para mostrar mensajes con un mayor nivel de detalle que debug.

· Uso de Appenders

Si interesa que las peticiones Ajax de los eventos JavaScript que aterrizan en el servidor no vaya van vía POST si no vía GET, por eso de tener también una traza del log en el Servidor Web basta con modificar una línea de la librería javaScript

La línea en cuestión está en el fichero /js/log4javascript.js

xmlHttp.open(“POST”,url,true);

Y hay que sustituirla por esta otra

xmlHttp.open(“GET”,url + “?”+ postData,true);

Hay que tener en cuenta que no es conveniente mandar mensajes muy grandes a través del GET ya que los navegadores e incluso los servidores web tienen limitado la cantidad de caracteres que se pueden enviar por GET aunque el protocolo HTTP no lo restringe (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15)

Limitaciones del tamaño de la petición web mediante GET:

  • Microsoft Internet Explorer (Browser): 2,083 caracteres
  • Firefox 1.5.x : No se muestra en la caja de la URL por encima de los 65536 caracteres aunque permite más
  • Safari (Browser): Al menos permite 80000 caracteres
  • El Servidor Web de Apache limita a 8192 byte el tamaño del campo en una request
  • Y el servidor Microsoft Internet Information Server tiene una limitación de 16384 aunque es configurable

Juntos, en un ejemplo simple, Kafka, Storm y HDFS

Etiquetas

Vamos a mostrar una especie de Hello World de comunicación entre Kafka (0.8.0), Storm (0.9.0-wip21) y Hadoop (2.0.2-alpha-gphd).

Para ello vamos a utilizar la distribución de Hadoop PivotalHD y enviaremos un mensaje JSON a Kafka, lo fecharemos en Storm y lo almacenaremos en HDFS

Lo primero es hacerse con las últimas versiones de cada uno e instalarlos en uno o varios servidores (este paso lo omitiremos).

Luego:

· Arrancar Kafka

bin/kafka-server-start.sh config/server.properties

· Crear el tópico y enviar el mensaje JSON

echo “{“name”:”testFetchJSON”,”type”:”7″}” | bin/kafka-console-producer.sh –broker-list localhost:9092 –topic jsonTopic

· Crear la topología Storm.

No es propiamente una topología si no que actuaremos directamente sobre el Stream ya que es un ejemplo muy simple

· La clase que se encarga de la lectura del mensaje del Broker Kafka desde Storm es esta:

· La clase que se encarga de la modificación del mensaje es la siguiente:

La persistencia en HDFS se realiza desde esta clase:

· Una vez compilado se puede ejecutar en el modo LocalCluster de Storn con maven:

mvn exec:java -Dexec.mainClass=”openbus.processor.topology.OpenbusJSONTopology”

· Y el comando para comprobar que se ha creado el fichero correspondiente

hadoop fs -cat hdfs://192.168.20.135:8020/user/gpadmin/openbus/json*

{“name”:”testFetchJSON”,”date”:”2013/10/07 04:36:33″,”type”:7}

Monitorización en Hadoop

Hadoop es un sistema distribuido a gran escala de almacenamiento de datos y provee la infraestructura para el procesamiento distribuido utilizando grupos de hosts conectados en red. El Seguimiento y gestión de este tipo de sistemas distribuidos complejos es costosa.

1.1 Apache Ambari

http://incubator.apache.org/ambari/

Proyecto para facilitar la gestión de Hadoop. Para ello provee un interfaz gráfico intuitivo y fácil de usar.

1.1.1 Características de Ambari

· Provisión para clústeres Hadoop

Ambari proporciona un asistente paso a paso para la instalación de servicios de Hadoop a través de cualquier número de equipos e incluye una interfaz Web intuitiva que le permite fácilmente disposición, configurar y probar todos los servicios de Hadoop y componentes básicos.

· Administrar un clúster Hadoop

Ambari proporciona gestión central para iniciar, detener y volver a configurar los servicios de Hadoop en todo el clúster.

Los servicios se dividen en estas siete secciones:

1. Servicios de navegación

2. Resumen

3. Configuración para la actualización

4. Enlaces rápidos

5. Alertas y controles de estado

6. Gestión de cabeceras

7. Métricas

· Monitorizar el clúster Hadoop

Ofrece un panel de control para conocer el estado del clúster. Y tiene la posibilidad de definir alertas para los servicios de Hadoop.

Utiliza Ganglia (http://ganglia.sourceforge.net/) para la recolección métricas.

Se integra con Nagios para el sistema de alertas y de notificaciones

· Ambari también incluye herramientas de diagnóstico de trabajo para visualizar las interdependencias de los Jobs y ver cronogramas de tareas como una forma de solucionar los problemas de ejecución

.

· Expone un API de REST para poder utilizar su funcionalidad desde aplicaciones externas

1.1.2 Arquitectura

Ambari sirve como punto central de recogida de los datos de todo el clúster. Cada host tiene un Agente Ambari – ya sea instalado automáticamente por el asistente de instalación o manual – que permite que al servidor Ambari controlar cada host. Además, cada equipo tiene un proceso Ganglia Monitor (gmond), que recoge la información métrica que se pasa al conector de Ganglia, y luego en el servidor Ambari.

1.2 Cloudera Manager

http://www.cloudera.com/content/cloudera/en/products/cloudera-manager.html

1.2.1 Características

Es el producto de Cloudera para la administración de Hadoop y tiene dos versiones: una para Cloudera Standard y otra para Cloudera Entreprise.

Permite la gestión de los nodos desde una única consola y facilita su instalación y replicado. Desde allí se controlan los cambios en la configuración de todo el clúster, e incorpora un completo gama de herramientas de diagnóstico y presentación de informes para ayudar a optimizar el rendimiento y la utilización. Se integra con la herramientas de monitorización de red SNMP.

Cloudera Standard soporta el despliegue, la configuración, administración, supervisión, diagnóstico y la ampliación sencilla del clúster.

Cloudera Entreprise tiene capacidades adicionales para la integración, automatización de procesos y recuperación de caídas.

1.2.2 Arquitectura

1.3 mikoomi

https://code.google.com/p/mikoomi/

Mikoomi es un proyecto dedicado al desarrollo de plugins de monitorización para Zabbix . Entre otros existe uno para Apache Hadoop (https://code.google.com/p/mikoomi/wiki/05) y para HBase (https://code.google.com/p/mikoomi/wiki/06)

1.3.1 Plugin Apache Hadoop

Permite la monitorización del NameNode y del JobTracker de un cluster Hadoop.

Las métricas de monitorización para el NameNode son las siguientes:

  • Configured Cluster Storage
  • Configured Max. Heap Size (GB)
  • Hadoop Version
  • NameNode Process Heap Size (GB)
  • NameNode Start Time
  • Number of Dead Nodes
  • Number of Decommissioned Nodes
  • Number of Files and Directories in HDFS
  • Number of HDFS Blocks Used
  • Number of Live Nodes
  • Number of Under-Replicated Blocks
  • Ping Check
  • Storage Unit
  • Total % of Storage Available
  • Total % of Storage Used
  • Total Storage Available
  • Total Storage Used by DFS
  • Total Storage Used by non-DFS
  • Least (min) Node-level non-DFS Storage Used
  • Least (min) Node-level Storage Configured
  • Least (min) Node-level Storage Free
  • Least (min) Node-level Storage Free %
  • Least (min) Node-level Storage Used
  • Least (min) Node-level Storage Used %
  • Most (max) Node-level non-DFS Storage Used
  • Most (max) Node-level Storage Configured
  • Most (max) Node-level Storage Free
  • Most (max) Node-level Storage Free %
  • Most (max) Node-level Storage Used
  • Most (max) Node-level Storage Used %
  • Node-level Storage Unit of Measure
  • Node with Least (min) Node-level non-DFS Storage Used
  • Node with Least (min) Node-level Storage Configured
  • Node with Least (min) Node-level Storage Free
  • Node with Least (min) Node-level Storage Free %
  • Node with Least (min) Node-level Storage Used
  • Node with Least (min) Node-level Storage Used %
  • Node with Most (max) Node-level non-DFS Storage Used
  • Node with Most (max) Node-level Storage Configured
  • Node with Most (max) Node-level Storage Free
  • Node with Most (max) Node-level Storage Free %
  • Node with Most (max) Node-level Storage Used
  • Node with Most (max) Node-level Storage Used %

Las métricas de monitorización para el JobTracker son las siguientes:

  • Average Task Capacity Per Node
  • Hadoop Version
  • JobTracker Start Time
  • JobTracker State
  • Map Task Capacity
  • Number of Blacklisted Nodes
  • Number of Excluded Nodes
  • Number of Jobs Completed
  • Number of Jobs Failed
  • Number of Jobs Retired
  • Number of Jobs Running
  • Number of Jobs Submitted
  • Number of Map Tasks Running
  • Number of Nodes in Hadoop Cluster
  • Number of Reduce Tasks Running
  • Occupied Map Slots
  • Occupied Reduce Slots
  • Reduce Task Capacity
  • Reserved Map Slots
  • Reserved Reduce Slots

Los posibles triggers a configurar para el NameNode son:

  • Less than 20% free space available on the cluster
  • NameNode was restarted
  • No monitoring data received for the last 10 minutes
  • One or more nodes have become alive or restarted
  • One or more nodes have become dead
  • One or more nodes have been added to the decommissioned list
  • One or more nodes have been removed from the decommissioned list
  • The number of live nodes has been reduced
  • The number of live nodes has increased
  • There has been a reduction in the number of under-replicated blocks
  • There has been an increase in the number of under-replicated blocks
  • Less than 20% free space available on one or more nodes in the cluster

Los posibles triggers a configurar para el JobTracker son:

  • No monitoring data received for the last 10 minutes
  • One or more jobs have failed
  • One or more nodes have become blacklisted
  • One or more nodes have been added to the exclude list
  • One or more nodes have been added to the Hadoop cluster
  • One or more nodes have been removed from the blacklisted nodes
  • One or more nodes have been removed from the exclude list
  • One or more nodes have been removed from the Hadoop cluster
  • The JobTracker was restarted

Cómo OpenTSDB almacena las series temporales en HBase

Etiquetas

,

En la entrada Un poco de OpenTSDB (y de StatusWolf) se comentan las bondades de OpenTSDB una base de datos temporal escalable y distribuida. Y una de sus principales virtudes es la forma de almacenar los datos de las series temporales de forma eficiente y compacta.

Para ello utiliza HBase que es la base de datos por defecto de Hadoop: distribuible, escalable y preparada para almacenar grandes volúmenes de datos, pero orientada a columnas por lo que es importante la forma en que almacenemos la información para luego no tener problemas con la extracción.

  • Lo primero un diseño simple

Sólo se almacenan series de tiempo. Una fila con un solo KeyValue por datapoint
En el campo clave se almacena primero el nombre de la métrica y luego el tiempo

OpenTSDB TimeSeries1

  • Uso del campo clave

Como en el campo clave no puede ir texto se almacena una referencia (lo mismo se hace con los tags) es decir que utiliza tablas separadas para asignar Ids únicos a los nombre de las métricas y los tags y añade esa referencia en el campo clave.

OpenTSDB TimeSeries2

OpenTSDB TimeSeries3

  • Reducción del número de filas 

Almacena los datos de forma consecutiva en la misma fila. Al tener menos filas consigue mayor velocidad a la hora de buscar una fila específica

OpenTSDB TimeSeries4

  • Creación de las filas

El problema es decidir cuando crear una nueva fila y esto se hace en los siguientes casos:
– Cuando se inicia una serie
– Cuando se sobrepasa un límite temporal, por ejemplo 10 minutos

En las reconexiones los datos se añaden en la fila de su rango temporal

OpenTSDB TimeSeries5

  • Reducción del espacio en disco 

Para optimizar el espacion en disco utiliza la compactación de columnas

OpenTSDB TimeSeries7

La presentación original se encuentra aquí

OpenTSDB TimeSeries8

Apache Ambari – Haciendo fácil operar con Hadoop

Etiquetas

Apache Ambari es un proyecto que facilita la gestión de Hadoop.

Ofrece una interfaz web intuitiva y fácil de usar para la gestión de Hadoop y además proporciona una API REST.

Ambari permite a los administradores del sistema:

  • Administrar y provisionar el cluster Hadoop
  • Un asistente paso a paso para la instalación de servicios de Hadoop a través de múltiples equipos
  • Proporciona  la forma de gestionar gestión central para iniciar, detener y volver a configurar los servicios de Hadoop en todo el clúster.
  • Monitoriza el clúster Hadoop
  • Ofrece un panel de control para vigilancia de la salud y el estado del cluster Hadoop.
  • Se encarga de la instalación de los paquetes de Hadoop en el clúster
  • Ambari aprovecha Nagios para el sistema de alerta y enviará mensajes de correo electrónico cuando se requiere su atención (por ejemplo, un nodo se cae, el espacio en disco restante es baja, etc).

Ambari