Flow Azkaban Parte 1

Start froom scratch

Hola a todos, hoy os quería enseñar una de las herramientas que me encontre por casaluidad y  que me ha solucionado muchos de los tipicos problemas que tenemos cuando vamos montando un sistema de ETL grande y con diversas fuentes independientes.

prisons-200412-azkaban-harry-potter-halloween-treat-reveals-secrets-of-umbridge-thestrals-ministers-and-azkaban-jpeg-165310Azkaban es un planificador de tareas de trabajo por lotes creado en LinkedIn para ejecutar trabajos .

Azkaban resuelve el pedido a través de las dependencias de trabajo y proporciona una interfaz  fácil de usar via  web para mantener y realizar un seguimiento de los flujos de trabajo.

  • Compatible con cualquier version de Hadoop
  • UI web de uso facil
  • Web Simple and Uploads
  • Project workspaces
  • Programar workflows
  • Modular y pluginable
  • Usuarios y Roles
  • Tracking de usuarios y acciones
  • Email de alerts o fallos y successes
  • SLA alerting y auto killing
  • Reintentos de trabajos fallidos

Vamos por partes Azkaban permite tener trabajos y hace flow s(flujos de trabajo) , que conseguimos con esto , poder  encadenar trabajos independientes de manera logica.

Yo tengo siempre el mismo problema, las empresas tiene procesos ajenos a las ETL pero que necesito poder controlar para que los datos de los procesos sean correctos ademas y es un problema que me he encontrado últimamente.

Este problema es que hay procesos que están controlados por el crontab y cuando alguno de los proceso tarda más de lo habitual el resto de los procesos se lanzan y salen datos erróneos, cosa que no es muy adecuado.

azkaban2overviewdesign
Arquitectura de Azkaban

 

Instalación

cd /tmp
curl -O https://s3.amazonaws.com/azkaban2/azkaban2/2.5.0/azkaban-solo-server-2.5.0.tar.gz
tar -zxvf azkaban-solo-server-2.5.0.tar.gz
mv azkaban-solo-server-2.5.0 /opt/
chmod +x /opt/azkaban-solo-server-2.5.0/*
mv azkaban-solo-server-2.5.0 azkaban-server
./bin/azkaban-solo-start

Una vez que tenemos esto instalado lo que hacemos es arrancar el servicio y ya podemos entrar via web.

En proximos post os ire comentado como hacer para añadir un trabajo/flujo o un SLA a un servicio , etc…. Pero es una herramienta muy buena  que nos ayuda en los típicos casos en los que tengamos un hadoop un hive etc…

 

 

Todos a Galera !!!

Buenas a todos,

Os traigo una de las herramientas que mas me han gustado en el año 2015. Todagaleracluster_logo la gente de BI tiene siempre un cierto cariño a MySQL ya sea por que nos gusta, por que nos hemos acostumbrado a ella o por que es la base de datos Open Source mas extendida.

Yo cada vez mas estoy mas cerca de posgreSQL que de MySQL ya que tiene mejor rendimiento para el DWH.

Bueno vamos al tema. Galera que tiene de bueno esta herramienta.

Galera Cluster es una verdadero sistema Cluster Multimaster basado en replicación asíncrona.

Galera es una solución fácil de usar, de alta disponibilidad, sin pérdida de datos y escalabilidad.

Features

  • Replicaciòn Asincrona.
  • Active-active multi-master topology
  • Lectura y Escritura en cualquier cluster
  • Control automaticos de los nodos, cuando un nodo cae se le saca del cluster
  • Añadir un nodo en caliente
  • Replicaciòn paralela a nivel de row
  • Conexiones a cliete de manera nativa

Beneficios Ocultos

  • Sin latencia de esclavos
  • Sin perdidas de transacciones
  • Escalabilidad en lectura y escritura

La replicación de Galera es asíncrona , multi-master y tiene un plug-in para InnoDB. Es muy diferente de la replicación normal de MySQL, y aborda una serie de temas, incluyendo los conflictos de escritura al escribir en varios Masters, retraso de replicación y esclavos están fuera de sincronía con el maestro.

Los usuarios no tienen que saber qué servidor puede escribir en (el maestro) y que los escalvos se pueden leer (los esclavos).

galera_replication1Una aplicación puede escribir en cualquier nodo de replicación del clúster Galera y la transacción se compromete (eventos RBR) a continuación, se aplica en todos los servidores, a través de una replicación basada en la certificación.

Replicación basada en certificación es un enfoque alternativo para la replicación de bases de datos sincrónizada utilizando la comunicación de grupo y técnicas de transacción .

Un grupo mínimo de 3 nodos de Galera. La razón es que, debería haber un problema al aplicar una transacción en un nodo (por ejemplo, un problema de red o la máquina no responde), los otros dos nodos tendrán un quórum (es decir, una mayoría) y serán capaces de proceder ha cometer la transacción.

La replicaciòn de MySQL es parte de la base de datos estándar de MySQL, y es principalmente de naturaleza asíncrona. Las actualizaciones siempre se realizan en un maestro y éstos se propagan a los esclavos. Es posible crear una topología de anillo con múltiples maestros, sin embargo esto no es recomendable ya que es muy fácil para los servidores salir de la sincronización en caso de una fallo principal. No hay conmutación automática por error  o resincronización en estos casos.

La replicación es un plug-in de MySQL, y permite una configuración maestro-maestro para InnoDB. En una clúster de replicación todos los nodos son maestros y las aplicaciones pueden leer y escribir desde cualquier nodo. Las transacciones se han comprometido de forma sincrónica en todos los nodos. En caso de fallo de un nodo, los demás nodos seguirán funcionando y se mantiene hasta la fecha. Cuando el nodo que ha fallado vuelve a aparecer, se sincroniza automáticamente con los otros nodos antes de que se le permita añadirse de nuevo en el clúster, es decir,no se pierden datos cuando falla un nodo.

Aunque la  replicación es sincróna, es posible implementar una replicación a través de los centros de datos. La replicación síncrona se implementa tradicionalmente a través de 2-fase de confirmación, donde los mensajes se envían a todos los nodos de un clúster en una fase de ‘preparar’, y otro conjunto de mensajes se envían en una fase de “comprometerse”. Este enfoque es por lo general no es bueno para los nodos geográficamente lejanos o en distintos CPDS, debido a las latencias en el envío de mensajes entre los nodos.

Para recordar un poco las diferencias entre los motores

Funcionalidades específicas de InnoDB

  • transacciones ACID
  • bloqueo a nivel de registro (MyISAM sólo ofrece bloqueo a nivel de tabla)
  • restricciones de clave externa (foreign key constraints)
  • recuperación automática en caso de crash
  • compresión de tablas con posibilidad de lectura/escritura
  • tipos de datos espaciales(pero no índices espaciales)
  • Los datos son guardados en páginas en orden de clave primaria

Funcionalidades específicas de MyISAM

  • ejecución rápida de COUNT(*)s (cuando no se utilizan WHERE, GROUP BY, o JOIN)
  • indexación “full text”
  • ocupan menos espacio en disco que las tablas InnoDB
  • compresión elevada de tablas, pero las tablas comprimidas son de sólo lectura
  • tipos de datos e índices espaciales (R-tree)

Para los que la tengais que usar en pentaho os recomiendo  que mireis el driver jdbc que vais a usar, yo he tenido problemas con estos. Pero tengo que decir que con este sistema la (HA+Galera+MySQL 5.6) hemos sido capaces de mover una catidad muy grande de datos con un rendimiento aceptable.

[instalaciòn]

HellKichen

Hola a todos,

Os presento uno de los proyectos en los que estoy trabajando  y es un wrapper a kichen, pan y espero que en poco tiempo a carter.

¿Pero para que sirve?

600x380_hells_kitchen_logo-bigNormalmente lanzo mucho procesos diferentes algunos son job otras son transformaciones y es un poco coñazo el tema de configurar la ruta donde esta pdi además del nivel del login así como la  ruta donde queremos guardar ese log,etc.. .

Por eso he creado este programa simple y facil [link] like a water.

Al arrancar este programa crea un fichero junto a .kettle.properties  que se llama hellkichen.properties donde ponemos la ruta a pdi y la ruta donde se van a guardar los logs asi de simple.

Además los log se van a ir rotando  con el formato  nombre_de_transformacion_%d%m%Y_%H%M%S.log.

Toda ayuda es bien recibida dentro de poco habra una version en python.

GC overhead limit exceeded (Parte 2)

Hola a todos,

Vamos por la segunda parte del post que empece ayer sobre problemas de GC.

Configuraciòn del Garbage Collection

Añadir la siguiente opción en el BA-Server java:

-XX:+UseConcMarkSweepGC

Example:

JAVA_OPTS="-Xms3072m -Xmx4096m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.awt.headless=true"

Modificamos:

JAVA_OPTS=".....-Xms3072m -Xmx4096m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.awt.headless=true"

 

El recolector  lanzará un OutOfMemoryError  si el tarda mucho tiempo. Si es más de 98% del tiempo total que tarda  recolección de basura y menos del 2% del heap, será lanzado un OutOfMemoryError.

Esta función está diseñada para evitar que las aplicaciones se ejecuten durante un período prolongado de tiempo mientras el heap es muy pequeñas.

GC overhead limit exceeded

Hola a todos,

Una vez mas os traigo otro post relacionado con el tema de los tipicos problemas de pentaho.

Problema

Nuestro servidor de pentaho y nos saca  el siguiente mensaje java.lang.OutOfMemoryError: GC overhead limit exceeded , en el log

Solución

Normalmente este problema afecta al incrementar la memoria del BI server. Ahora os voy a mostrar algunas soluciones.

Decrementar el  MaxPermSize

Si bien el aumento de los valores XMS y XMX. También se incrementa de alguna manera el valor MaxPermSize.

export CATALINA_OPTS="Xms8192m -Xmx10240m -XX:MaxPermSize=8192m"
  • FIX
    • Detenga el servidor de BI
    • Busque y abra el archivo que se utiliza para iniciar el servidor de BI con un editor de texto. (Por ejemplo la puesta en pentaho.bat, start-pentaho.sh o una ctl.sh)
    • Cambie el valor MaxPermSize de nuevo a su valor predeterminado de 256 (Por favor, consulte el ejemplo siguiente)
export CATALINA_OPTS="Xms8192m -Xmx10240m -XX:MaxPermSize=256m"
  • Restart el BI Server

El MaxPermSize siempre puede permanecer en el valor predeterminado de 256, porque eso es todo lo que se necesita para Pentaho en el arranque. El aumento del valor MaxPermSize causará problemas de inestabilidad en el servidor de BI.

Cómo habilitar el almacenamiento en caché de contenido estático de rendimiento en el navegador

Buenas a todos,
Otro post de temas relacionado con los ficheros estáticos. Cómo habilitar el almacenamiento en caché de contenido estático / Archivos de rendimiento en el navegador.

Reporting

Vamos al fichero situado

pentaho-solutions\system\reporting\settings.xml

Añadimos el tag

 <max-age>3600</max-age>

y quedaria más o menos así:

<cache-messages>true</cache-messages>
<max-age>2628001</max-age>

Analyzer Solo para los que usan EE

Vamos al fichero situado en

pentaho-solutions\system\analyzer\settings.xml

<max-age>3600</max-age>

To

<max-age>2628001</max-age>

Dashboards

Vamos al fichero situado en

pentaho-solutions\system\dashboards\settings.xml

y cambiamos los  siguientes tags

<cache>false</cache>
<max-age>0</max-age>

To

<cache>true</cache>
<max-age>2628001</max-age>

Una vez tengais los cambios que necesitas vas a

Tools > Refresh > System Settings

Por el almacenamiento en caché de contenido estático por defecto está activada por hacer solamente durante 1 hora; usted puede cambiar esta configuración en cada plugin independiente para mejorar el rendimiento