Cuadros de Mando Pentaho

Tomado de: Cuadro de Mando Pentaho

17.6. Cuadros de Mando en Pentaho con Community Dashboard Framework (CDF).

Posted by Roberto Espinosa en 20 julio 2010

CDF (Community Dashboard Framework) es un conjunto de tecnologías Open Source que permite a los desarrolladores BI construir cuadros de mando dinámicos y tableros (Dashboards) para la plataforma BI de Pentaho. Los dashboards CDF son paginas web que utilizan la tecnología Ajax para combinar informes, graficos, tablas Olap y mapas.
Pentaho no esta directamente involucrado en el desarrollo de este proyecto, pero incluye el plugin correspondiente tanto en la versión Community como en la Enterprise. Igualmente, desarrolladores de Pentaho son contribuyentes activos al proyecto.
El proyecto fue iniciado por Ingo Klose en 2007 y posteriormente potenciado por el trabajo de Pedro Alves, que además colabora en otros proyectos dentro del ambito de Pentaho, como CDA (Community Data Access), CBF (Community Build Framework) o CDE (Community Dashboard Editor).

Ejemplo CDF

Podeís acceder a la documentación existente sobre CDF en el portal de Pentaho.

Arquitectura de CDF.

Los dashboards CDF son paginas web que contienen areas llamadas componentes, donde se visualiza contenido BI (informes, gráficos, tablas Olap,etc). Cuando ejecutamos un dashboard en la plataforma BI, se produce la siguiente secuencias de acciones para ejecutarlo en el servidor:

1. El usuario utiliza el navegador en la plataforma BI para abrir un tablero. Esto genera una request HTTP que es enviada al servidor BI de Pentaho.
2. El servidor reconoce una petición de Dashboard e intenta localizar el fichero .xcdf asociado.
3. El fichero .xcdf determina el template o plantilla del dashboard. Es un fichero HTML parcial que contiene los huecos para los componentes y las instrucciones Javascript para llenar estos componentes. El dashboard template se combina con la plantilla del documento (outer template) para generar una página web (documento HTML). Este segundo template se especifica igualmente en el fichero .xcdf.

Arquitectura CDF

4. La página es recibida por el navegador para ser visualizada al usuario.  Como parte de este proceso, se inicializa el Dashboard y se ejecutan las instrucciones Javascript del documento, generandose el contenido de los componentes.
5. Despues de la inicialización, se lanza la actualización de los componentes para realizar su llenado. Esto se realiza a través de las correspondientes requests contra el servidor.
6. El servidor Pentaho recibe las solicitudes recibidas por los componentes, que normalmente corresponden a la ejecución de secuencias de acciones (action sequence).
7. El servidor ejecuta la secuencia de acciones.
8. El contenido generado por la secuencia de acciones es enviado como resultado, y es procesado para ser incluido en la pagina web. El resultado llena el correspondiente componente, lo que permite que el resultado sea visible en la página.

Además, en la configuración del plugin se determinan unos templates generales que determinan el marco en el que se visualizan los dashboards y que son totalmente personalizables.

Ejemplo práctico de CDF.

Para entender mejor los diferentes elementos que intervienen en la construcción de un dashboard CDF, vamos a ver un ejemplo práctico sencillo detallando todos los componentes que forman el tablero. Partiendo de uno de los ejemplos que se proporcionan en el portal de Pentaho, que tiene el siguiente aspecto:

CDF - Ejemplo gráfico interactivo

Es un tablero interactivo, de forma que podemos pulsar en cada una de las áreas del gráfico de la izquierda. Al pulsar cada sección, se actualiza de forma automática el gráfico de barras de la derecha, con los resultados de la región seleccionada. Para construir un tablero como el del ejemplo, en primer lugar construiremos el fichero .xcdf, donde estableceremos las propiedades generales, así como el nombre del fichero que contiene el outer template. Este será el fichero pentaho_sample.xcdf del tablero de la imagen:

<?xml version="1.0" encoding="UTF-8"?>
<cdf>
 <title>Pentaho Sample</title>
 <author>Webdetails</author>
 <description>Pentaho Sample</description>
 <icon></icon>
 <template>template.html</template>
</cdf>

En segundo lugar, construiremos el fichero template. html, que incluye la parte html y la parte Javascript que va a determinar como se llenan los diferentes componentes del tablero y como es el comportamiento dinámico de este al pulsar sobre las secciones del gráfico de tarta para ver el desglose de cada una de las zonas.

<SCRIPT LANGUAGE="JavaScript">

// This is a custom function that is fired when a user selects a productLine and then want to select a territory

// Its purpose is to reset the productLine variable back to null and pass the territory that has been selected

// The function is executed from the url-template tag in the territorySales.xaction

function clickOnRegion(value) {

 department = "null";

 Dashboards.fireChange('region',value);

}

</SCRIPT>

## PARTE HTML DONDE DEFINIMOS LAS SECCIONES Y LAS ETIQUETAS HTML QUE LUEGO SERAN SUSTITUIDAS POR LOS COMPONENTES CDF  ##

<!-- The page_title_object -->

<h1><span id=page_title_object></span></h1>

<!-- The dashboard layout table -->

<table align="center" cellpadding="3">

 <tr>

 <td align="center"><div id="RegionsPieChartObject"></div></td>

 <td align="center"><div id="RegionVarianceBarChartObject"></div></td>

 </tr>

 <tr>

 <td align="center"><div id="DepartmentDialChartObject"></div></td>

 <td align="center"><div id="EmbeddedReportObject"></div></td>

 </tr>

</table>

<script language="javascript" type="text/javascript">

// Define script variables before script execution

var region = "null";

var department = "null";

## DEFINICION DE LOS DIFERENTES COMPONENTES, CON SUS PROPIEDADES y FUNCIONES A EJECUTAR ANTES Y DESPUES DE LA EJECUCION DE CADA UNO

// pageTitleString component generates the page title with any other parameters is may need to construct the string

pageTitleString =

{

 name: "pageTitleString",

 type: "text",

 listeners:["region", "department"],

 htmlObject: "page_title_object",

 executeAtStart: true,

 expression: function(){return "title"},

 preExecution:function(){

 if(region == "null" && department == "null") {

 title="Select a region";

 }

 else if (region != "null" && department == "null") {

 title="This is headcount spending for " + region;

 }

 else if (region != "null" && department != "null") {

 title = "This is headcount spending for " + region + ", " + department;

 }

 },

 postExecution:function(){}

}

// RegionsPieChart component generates the

RegionsPieChart =

{

 name: "RegionsPieChart",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "RegionsPieChart.xaction",

 listeners:[],

 parameters: [],

 htmlObject: "RegionsPieChartObject",

 executeAtStart: true

}

// RegionVarianceBarChart component generates the

RegionVarianceBarChart =

{

 name: "RegionVarianceBarChart",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "RegionVarianceBarChart.xaction",

 listeners:["region"],

 parameters: [["REGION","region"]],

 htmlObject: "RegionVarianceBarChartObject",

 executeAtStart: false,

 preExecution:function(){document.getElementById('DepartmentDialChartObject').innerHTML="";document.getElementById('EmbeddedReportObject').innerHTML="";}

}

// DepartmentDialChart component generates the

DepartmentDialChart =

{

 name: "DepartmentDialChart",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "DepartmentDialChart.xaction",

 listeners:["department"],

 parameters: [["DEPARTMENT","department"],["REGION","region"]],

 htmlObject: "DepartmentDialChartObject",

 executeAtStart: false

}

// EmbeddedReport component generates the

EmbeddedReport =

{

 name: "EmbeddedReport",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "embedded_report.xaction",

 listeners:["department"],

 parameters: [["DEPARTMENT","department"],["REGION","region"]],

 htmlObject: "EmbeddedReportObject",

 executeAtStart: false

}

## DEFINICION DE LOS COMPONENTES A SER CARGADOS EN EL DASHBOARD Y LA FUNCION PRINCIPAL DE CARGA DEL TABLERO

// These are the components to be loaded into the dashboard withing the [] seperated by ,

var components = [pageTitleString, RegionsPieChart, RegionVarianceBarChart, DepartmentDialChart, EmbeddedReport];

</script>

<script language="javascript" type="text/javascript">

// The intial dashboard load function definition

function load(){

 Dashboards.init(components);

}

// The intial dashboard load function execution

load();

</script>

Como vemos, todo es programación y somos nosotros los que hemos de indicar el comportamiento de los diferentes elementos, compaginandolos con elementos de diseño HTML. En la documentación de CDF se enumeran las propiedades que se pueden definir y los componentes que podemos utilizar dentro de los tableros. Por ejemplo, podremos configurar los siguientes tipos de componentes:

check: crea una lista de casillas de seleccion etiquetadas con los resultados de una determinada secuencia de acciones (leyendo, por ejemplo, de la base de datos).

dateInput: crear un control de calendario para introducción de fechas.

radio: crea una lista de radiobuttons etiquetados con los resultados de una determinada secuencia de acciones.

select: crear una lista de selección simple, que esta llena con los valores recuperados por una determinada secuencia de acciones.

selectMulti: igual que el anterior, pero la lista permite selección multiple.

text: permite actualizar el texto de una cadena HTML.

textInput: crea un campo de entrada de texto.

xaction: ejecuta una secuencia de acciones y visualiza los resultados en una determinada etiqueta HTML.

jpivot: ejecuta una secuencia de acciones jpivot y visualiza los resultados en un frame donde la tabla jpivot es embebida.

map: componente para integrar mapas.

mapBubble: componente para integrar gráficos.

Con el componente jpivot podremos embeber una tabla de análisis dentro del tablero. Con xaction podremos definir una secuencia de acciones (como ejecutar un informe, por ejemplo). Aunque no la hemos analizado, Pentaho proporciona la herramienta llamada Design Studio (PDS), basada en el entorno Eclipse, que nos permite crear secuencias de acciones para integrar en el servidor BI. Por ejemplo, podremos crear secuencias de acciones para ejecutar informes o sentencias SQL, para enviar correos electrónicos, obtener datos desde Kettle, realizar acciones sobre el scheduler de la plataforma BI, etc. Podeís ver un resumen de las acciones mas usuales en este link. Los ficheros de secuencia de acciones tiene la extensión .xaction. Un ejemplo de fichero de este tipo para ejecutar un report de PRD es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<action-sequence>
 <title>JFreeReport HTML Example</title>
 <version>1</version>
 <logging-level>debug</logging-level>
 <documentation>
 <author>James Dixon</author>  
 <description><![CDATA[
 This is an example of an HTML report produced by JFreeReport.
 <p/>It shows the actual headcount cost, budgeted headcount
 cost, and variance for every position in the specified
 department and region
 ]]></description>  
 <icon>/style/icons/jfree1.png</icon>  
 <help/>
 <result-type>none</result-type>
 </documentation>

 <inputs>
 <REGION type="string">
 <sources>
 <request>REGION</request>
 </sources>  
 <default-value><![CDATA[Southern]]></default-value>
 </REGION>  
 <DEPARTMENT type="string">
 <sources>
 <request>DEPARTMENT</request>
 </sources>  
 <default-value><![CDATA[Sales]]></default-value>
 </DEPARTMENT>
 </inputs>

 <outputs>
 <report type="content">
 <destinations>
 <response>content</response>
 </destinations>
 </report>
 </outputs>

 <resources>
 <report-definition>
 <solution-file>
 <location>embedded_report.xml</location>  
 <mime-type>text/xml</mime-type>
 </solution-file>
 </report-definition>
 </resources>

 <actions>
 <action-definition>
 <component-name>SQLLookupRule</component-name>
 <action-type>Query For Report Data</action-type>
 <action-inputs>
 <REGION type="string"/>  
 <DEPARTMENT type="string"/>
 </action-inputs>
 <action-outputs>
 <query-result type="result-set" mapping="reportData"/>
 </action-outputs>
 <component-definition>
 <jndi>SampleData</jndi>  
 <query><![CDATA[select     QUADRANT_ACTUALS.REGION,
 QUADRANT_ACTUALS.DEPARTMENT,   
 QUADRANT_ACTUALS.POSITIONTITLE,   
 QUADRANT_ACTUALS.ACTUAL,   
 QUADRANT_ACTUALS.BUDGET,   
 QUADRANT_ACTUALS.VARIANCE  
 from QUADRANT_ACTUALS
 where QUADRANT_ACTUALS.REGION in ( {PREPARE:REGION} )
 and QUADRANT_ACTUALS.DEPARTMENT in ( {PREPARE:DEPARTMENT} )    
 order by QUADRANT_ACTUALS.REGION, QUADRANT_ACTUALS.DEPARTMENT]]></query>
 </component-definition>
 </action-definition>

 <action-definition>
 <component-name>JFreeReportComponent</component-name>
 <action-type>Pentaho Report</action-type>
 <action-inputs>
 <data type="result-set" mapping="reportData"/>
 </action-inputs>
 <action-resources>
 <report-definition type="resource"/>
 </action-resources>
 <action-outputs>
 <report-output type="content" mapping="report"/>
 </action-outputs>
 <component-definition>
 <output-type>html</output-type>
 </component-definition>
 </action-definition>

 </actions>
</action-sequence>

En la imagen podeis ver la interfaz de PDS, y un ejemplo de una secuencia de acciones, que se compone básicamente de inputs, acciones (como las que enumeramos anteriormente) y outputs. Los ficheros xaction son publicados en el portal para integrar las acciones descritas en él. Nos puede ser muy útil para automatizar procesos o para distribuir resultados de la ejecución de informes y graficos.

Pentaho Design Studio

Como os podeís imaginar, el diseño de los tableros con CDF es todo un reto donde hemos de tener conocimientos profundos en diseño Web, Javascript y además conocer de forma completa el funcionamiento del portal BI y la forma de diseñar secuencias de acciones con Pentaho Design Studio. Podremos construir casi todo lo que queramos, pero con un elevado componente de programación que exige un skill técnico muy elevado, en el que seguramente será necesaria la intervención de varias personas, además del conocimiento del negocio propio de un sistema BI.

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | 1 comentario

17.5. Cubos Olap y navegación dimensional con Mondrian y Jpivot.

Posted by Roberto Espinosa en 20 julio 2010

Pentaho Analysis Services es la parte de la plataforma BI de Pentaho que nos proporciona las funcionalidades Olap para el análisis de la información. Nos permite, de una forma interactiva, analizar los datos del Data Warehouse a traves de una interfaz de tabla cruzada donde podemos navegar por las diferentes dimensiones definidas en el modelo dimensional.
En una entrada anterior del blog, vimos la forma de definir nuestro modelo dimensional utilizando Pentaho Schema Workbench, aunque disponemos de otra herramienta adicional para la construcción de tablas agregadas, llamada Pentaho Agregation Designer (que permite mejorar la velocidad de ejecución de los análisis).
Una vez definidos los módelos dimensionales, podemos ejecutar nuestros análisis utilizando Jpivot a nivel de interfaz de usuario y Mondrian a nivel del servidor (es la parte que recibe las solicitudes de información de Jpivot, realiza las consultas contra la base de datos y devuelve la información en formato multidimensional).
Vamos a ver un poco como funciona la plataforma utilizando estos componentes y a continuación detallaremos las características mas importantes de Jpivot.

Arquitectura de PAS.

Cuando un usuario realiza un análisis a través de Pentaho Analysis Services, se realiza la siguiente secuencia de acciones entre los diferentes componentes que forman la plataforma:

1. Cuando estamos conectados a la plataforma BI y lanzamos la ejecución de un nuevo análisis, o interactuamos en un análisis ya visualizado (haciendo un drilldown por los datos, por ejemplo,  o modificando la vista de los datos o los filtros), se produce una request HTTP, que provoca una secuencia de acciones sobre Jpivot.
2. El servlet Jpivot recibe la solicitud y la traduce/transforma a una query en lenguaje multidimensional MDX, que es enviada a Mondrian (nuestro servidor ROLAP).
3. Mondrian interpreta la query MDX y la traduce en una o mas sentencias SQL, que son enviadas a la base de datos relacional.
4. La base de datos relacional ejecuta las sentencias SQL enviadas por Mondrian y le devuelve los resultados en forma de tabla (la forma tipica de visualizar resultados en cualquier motor de base de datos relacional utilizando el lenguaje de interrogación SQL).
5. Mondrian procesa los resultados y los traduce a un set de resultados multidimensional. Este set de datos sería la respuesta a la query MDX del punto 2.
6. Jpivot utiliza los resultados multidimensionales para construir una página HTML para visualizar la información, con la interfaz propia que veremos a continuación.

Arquitectura de Pentaho Analysis Services

La base para el correcto funcionamiento del sistema y de los diferentes componentes que lo forman, es la definición de los esquemas dimensionales y sus cubos, que habremos realizado previamente utilizando PWD. Mondrian viene instalado en la plataforma BI de Pentaho como un componente integrado. Si quereis profundizar en aspectos concretos de su funcionamiento y configuración, os recomiendo la lectura de la documentación que Pentaho proporciona en su portal.

Jpivot.

Jpivot es el cliente que vamos a utilizar para visualizar los resultados de los análisis. Para ejecutar un análisis, podemos utilizar uno ya existente que habremos guardado en la correspondiente carpeta de la plataforma, o bien crear uno nuevo desde la opción Nueva vista de análisis, momento en el que se nos pedirá el esquema y el cubo sobre el que queremos construirlo.

Seleccion esquema y cubo

A continuación, nos aparecerá una tabla de Jpivot por defecto, donde aparecerán todas las dimensiones de análisis definidas en el cubo y los indicadores por defecto, con una única linea de resultados totales. Este será el punto de partida sobre el que iremos puliendo nuestro análisis hasta dejarlo de la forma que cumpla nuestros requerimientos de información.

Esta tarea de modificación de los análisis no será siempre necesaria, pues una vez los tengamos preparados, los podremos guardar y reejecutar, manteniendo la configuración de dimensiones, jerarquías, filtros e indicadores de análisis que tuviera la tabla en el momento de ser guardada. Vamos a ver las diferentes opciones de la interfaz de usuario de Jpivot.
La interfaz de usuario de JPivot es muy sencilla. Básicamente, disponemos  de una barra de herramientas con botones donde podemos configurar las propiedades que va a tener la tabla donde visualizamos los resultados de los análisis. Veamos uno por uno cada botón (de izquierda a derecha) de la interfaz de usuario.

Jpivot - Barra Herramientas

Navegador Olap
El primer botón de la barra de herramientas es el navegador Olap que nos permite configurar como Jpivot muestra la información de los cubos en la tabla pivot. Con la herramienta podemos definir que dimension y jerarquia aparece en cada uno de los ejes (filas/columnas), los indicadores que visualizamos en el análisis, filtros, etc. Podemos ir moviendo los diferentes elementos de una sección a otra pulsando los correspondientes iconos a la izquierda de cada elemento hasta dejar el análisis personalizado a nuestra necesidades.

Jpivot - Navegador Olap

De esta forma, vamos configurando como será la visualización en la tabla. Ademas, podremos modificar la jerarquía visible en cada dimensión (en principio se verá la jerarquía por defecto, para el caso de tener varias jerarquías en la misma dimensión). También podemos seleccionar el nivel dentro de la jerarquía o los elementos a visualizar de todos los disponibles.

Jpivot - Selección miembros

Una vez realizadas las consiguientes modificaciones en el layout, pulsaremos el botón Aplicar y los cambios serán visibles en la tabla pivot.

Jpivot - Informe Modificado

Editor MDX.

Como hemos indicado antes, conforme vamos seleccionado las dimensiones e indicadores en el navegador olap, al actualizar la consulta, internamente se traduce a lenguaje MDX que es el que utiliza Mondrian para luego construir las sentencias SQL que se ejecutaran contra la base de datos relacional. Con este control, podemos visualizar la sentencia MDX que se ha construido de forma automática, e incluso, si dominamos este lenguaje, escribir directamente las consultas que darán como resultado la tabla pivot correspondiente.

Jpivot - Editor MDX

Habrá que tener en cuenta en la sintaxis de las sentencias MDX como hayamos llamado a las dimensiones, jerarquías e indicadores. Podeis consultar sobre la sintaxis del lenguaje MDX en la correspondiente página de Pentaho.

Propiedades de visualización.

El siguiente grupo de iconos nos permite establecer propiedades de visualización de la tabla de pivoteo sobre los datos.

• Mostrar padres: podemos forzar la visualización de los elementos padre conforme vayamos profundizando en los datos.

Jpivot - Mostrar Padres

• Ocultar repeticiones: con esta opción podemos ocultar repeticiones de los valores de los miembros de una jerarquía y asi hacer mas comprensible el análisis de los resultados.

Jpivot - Ocultar repeticiones

• Suprimir filas/columnas vacias: oculta las filas o columnas que no tuviesen valores.
• Intercambiar ejes: nos permite de una forma rápida pasar las filas a columnas y viceversa, y así cambiar la forma de ver la información.

Opciones de navegación.

Una opción muy interesante es determinar la forma en que se realiza la navegación por la tabla. Para ello, tenemos 3 posibles opciones.

• Detallar miembro: cuando navegamos por un miembro de una dimensión (por ejemplo, el mercado EMEA en la imagen anterior), independientemente de que estemos en un año u otro, se abre el desglose del miembro en todas las ocurrencias que tuviera en la tabla (en los diferentes años en el caso de nuestro ejemplo).
• Abrir detalle: en contraposición a Detallar miembro, con la opción Abrir detalle sobre se abre el nivel del miembro que hayamos seleccionado, no todas las ocurrencias.
• Entrar en detalle: cambiamos la forma de navegación, sustituyendo el icono + por una flecha, que nos permite ir bajando y subiendo por la información sin que se vaya realizando un desglose. Es una forma de navegación mucho más util para ir analizando aspectos concretos.

Las tres opciones de navegación descritas son excluyentes entre si (solo podremos tener seleccionada una de ellas a la vez).

Jpivot - Entrar en detalle

• Mostrar datos Origen: con esta opción mostramos en la parte inferior de la tabla pivote una tabla adicional donde se muestran los datos originales que dan lugar a los resultados mostrados en la tabla principal. Puede ser útil para buscar determinados valores en registros individuales de datos cuando se produzca una alarma visualizando los resultados de la tabla principal.

Modo gráfico y exportación PDF/Excel.

Finalmente, el ultimo set de botones de la barra de herramientas nos permiten configurar el gráfico que se muestra como complemento de la tabla pivot o realizar la exportación de los resultados en formato PDF o Excel.

• Mostrar gráficos: al seleccionar la opción, se visualiza adicionalmente un gráfico con los resultados de la tabla. Los tipos de gráfico que se pueden utilizar son de barras, de linea, de area o de tarta.

Jpivot - Tabla y grafico

• Configurar gráficos: en esta opción configuramos las propiedades del gráfico (tipo de gráfico, fuentes, titulos, color de fondo, etc).
• Configurar impresion: configuramos alguna de las propiedades que tendrá el PDF que se genere en la opción Exportar a PDF (titulo, tamaño de tabla, orientación del papel, etc).
• Exportar a PDF: genera un documento PDF con los resultados de la tabla pivot según la configuración indicada.
• Exportar a Excel: nos permite exportar la tabla de resultados visibles a un fichero con formato excel.

Otras alternativas. StPivot, Pat y Jrubic/La Azada.

Jpivot tiene una interfaz algo anticuada y no demasiado vistosa. Por este motivo, han surgido algunas alternativas que tratan de mejorar la experiencia de usuario al trabajar con Mondrian. Podemos destacar:

• Stpivot: como lo llaman en Stratebi, es Jpivot con esteroides. Es una mejora de la interfaz de usuario y algunas funcionalidades realizadas por ellos. Os dejo el link al blog de todobi.com donde podeis ampliar información y ver videos de como instalarlo y utilizarlo.
• Jrubik/ La Azada: una opción alternativa a la utilización de PAS es utilizar un cliente Olap que ejecutaremos en nuestro PC como un programa más de escritorio. Un ejemplo de este tipo de aplicación es Jrubik, proyecto desarrollado en su día por gente de la Agencia Tributaria en España o el más actual La Azada, del que podeis leer mas en este documento publicado por todobi.com. Estan totalmente integrados con Mondrian, y aunque tienen algunas limitaciones y bugs, pueden ser una opción interesante.

Interfaz gráfico de La Azada

• Pat (Pentaho Analysis Tool): es el nuevo proyecto que pretende crear la interfaz del futuro que sustituya a Jpivot. Esta todavía en una fase muy inicial y aun le queda un largo recorrido antes de ser una opción a considerar. Podeis ampliar información sobre el proyecto aquí.

Interfaz de usuario de PAT

En la próxima entrada del blog concluiremos el análisis de las herramientas de Pentaho en la parte referente a Cuadros de Mando y Dashboard a través del proyecto Community Dashboard Framework for the Pentaho BI Platform.

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | Deja un Comentario »

17.4. Reporting en Pentaho con Pentaho Report Designer. Otras posibilidades de reporting (Birt y JasperReports).

Posted by Roberto Espinosa en 15 julio 2010

La plataforma Pentaho nos proporciona dos formas integradas de realizar reporting, ademas de permitir la utilización e integración de otras herramientas (como JasperReports o Birt). Las herramientas propias de Pentaho, como ya vimos, son las siguientes:

• Web Ad Hoc Query and Reporting Client (WAQR): herramienta integrada en el portal que nos permite realizar querys y reporting adhoc de una forma intuitiva y sencilla, aunque con limitaciones.
• Pentaho Report Designer (PRD): a través de una herramienta de diseño desktop, que nos permite definir y construir nuestros informes, y luego publicarlos en el portal de BI para que puedan ser ejecutados por los usuarios.

Vamos a ver un poco mas en profundidad en que consisten estas herramientas.

Web Ad Hoc Query and Reporting Client (WAQR).

EL WAQR es la herramienta de reporting ad-hoc integrada en el portal BI de Pentaho. Accedemos a la herramienta desde la opción de menú Archivo –> Nuevo –> Nuevo report o pulsando el correspondiente Icono en la barra de la aplicación. En ese momento nos aparece un asistente que nos permitirá la construcción de los informes a partir de la información del metadata definida en el sistema (que habremos preparado previamente utilizando Pentaho Metadata Editor, como vimos en la correspondiente entrada del blog).
El asistente dispone de 4 etapas, en las que realizaremos las siguientes acciones:
1) Select Data Source: realizaremos la selección del origen de datos que queremos utilizar. Dispondremos de tantos origenes de datos como Business Model o Modelos de negocio hayamos generado en la definición del Metadata. Seleccionaremos uno de los modelos y tendremos disponibles para los siguientes pasos todas las vistas de negocio y sus correspondientes campos incluidas dentro del modelo de negocio seleccionado. Además, podremos indicar un template o plantilla que nos determinará el formato que va a tener nuestro informe.

Asistente de la creacion de un informe de WAQR

2) Make Selections: a continuación, de todas las vistas de negocio incluidas en el modelo de negocio seleccionado, configuraremos la disposición de los resultados del informe, seleccionamos los campos oportunos de cada una de las vistas de negocio disponibles. Seleccionaremos uno a uno los campos y lo llevaremos a las secciones del informe que se encuentran en la parte derecha de este. Tenemos 3 posibles secciones: Groups (campos con los que realizaremos grupos de valores, pudiendo configurar hasta 5 niveles de agrupación), Details (campos que formaran el cuerpo del informe o detalle) y Filters (campos que se utilizaran para restringir los valores devueltos en la ejecución).

Selección de campos y configuración de secciones

3) Customize Selections: en esta tercera pestaña configuraremos aspectos del formato de cada una de las secciones del informe. Por ejemplo, en lo referente a las agrupaciones (Groups), podremos indicar aspectos generales de como se realiza el agrupado (nombre de nivel, repetición de cabecera de grupo, mostrar sumario de grupo, etiqueta para el total por grupo, ruptura de pagina o no en el grupo, ruptura de pagina antes o despues del grupo, alineación, etc), tal y como podeís ver en la imagen siguiente.

Propiedades de campos y secciones

Ademas, podemos indicar aspectos de formateo, como mascaras de edición, alineación, forma de ordenación del grupo, condiciones del grupo, etc, tal y como veis en la imagen. Basicamente, tenemos los mismos componentes de formato si estuvieramos modificando los campos seleccionados en la sección Details (detalles).

Propiedades de campos y secciones

Para los campos insertados en la sección Filters, podremos indicar constraints que serán condiciones que limitaran los resultados devueltos por el informe.

4) Report Settings: este será el último paso en la preparación del reporte adhoc. En este paso final indicaremos la orientanción del informe, el tamaño de papel y la configuración de la cabecera y pie de pagina del informe. En este momento, el informe ya esta listo para su ejecución o para ser guardado y reutilizado posteriormente por los usuarios.

Configuracion del informe y de cabecera y pie de página

Hemos visto que es una herramienta muy fácil y sencilla de utilizar, y su potencia radica en que hayamos definido correctamente en el metadata los campos a utilizar con las relaciones definidas correctamente entre las tablas que son su origen. Aunque tiene muchas limitaciones, nos puede sacar de un apuro y puede ser sin duda facilmente utilizada por los usuarios finales. Ademas, los resultados del informe los pondremos tener en HTML, PDF, Excel o CSV.

Pentaho Report Designer (PRD).

Pentaho Report Designer es una herramienta de reporting que nos permite crear nuestros propios informes, bien para ejecutarlos directamente o para publicarlos en la plantaforma BI y que desde allí puedan ser utilizados por los usuarios. La herramienta es independiente de la plataforma y forma parte del conjunto de herramientas de la suite de Pentaho.
Antes de continuar, os hago una recopilación de la documentación que proporciona Pentaho en su portal Wiki con respecto al reporting.

User Guides

• Formula Syntax

Blogs, Articles, How-Tos

• Diethard Steiner: Using Parameters in queries and datasources in Pentaho Reporting 3.5
• Diethard Steiner: Setting up an “All” Parameter
• Bart Maertens: Crosstabs in PRD-3.5
• Michael Tarallo: Guided Ad-Hoc with PRD-3.5
• MDX PARAMETER function

Books

• Pentaho Reporting 3.5 for Java Developers
• Roland Bouman, Jos van Dongen: Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL

Developer Guides

A pentaho-reporting-sdk aimed at Java-Developers with simple demos, a detailed step-by-step guide and all the sources for all the libraries used in the demos is available from sourceforge.

• How to configure Logging in Pentaho Reporting
• Dependency documentation
• Pentaho Reporting’s Modular Design
• Using the DocumentBundle Reader and Writer
• Parameter Definitions
• Report Processing State Diagramm
• Code-style Definitions
• Functions And Expressions
• DataSource MetaData, User-friendly column names and formatting information
• Aggregate Fields
• Drill-Linking

Installation Guides

• Report configurations and the boot process
• Use of TrueType Fonts
• Define Selectable Report Encoding

User Guides

• URL Parameters for the Report Viewer Plugin
• Reserved Parameter Names
• Classic Engine Algorithm
• Layout Restrictions for Table-based and Plain-Text output
• Style-Keys Reference
• Subreport Guide
• Introduction to Report Pre-Processors
• Fonts: Export to PDF and missing Unicode characters
• Timeseries-Charting in Report-Designer
• Links and Drill-Down
• Using Self-Signed Certificates with SSL (HTTPS) Connections

Pentaho Report Designer nos permite trabajar con multiples origenes de datos (JDBC, Olap4J, Pentaho Analysis, Pentaho Data Integration, XML) incluido el metadata que tengamos definido en nuestro sistema. También nos permite modificar los informes ad-hoc que hayamos creado utilizando WAQR (de hecho es la única forma de modificarlos). El motor de reporting de Pentaho esta basado en JFreeReports y ha sido totalmente rediseñado en lo que llaman PRD (Pentaho Report Designer). PRD es un generador de informes del tipo Banded (en contraposición de los generadores orientados a flujo),  en los que un informe se divide en secciones o grupos de datos en los que los elementos del informe pueden ser posicionados. Esta forma de trabajar tiene algunas limitaciones, que se pueden superar con el uso de subinformes. El resultado de los informes que vamos diseñado se puede ver con las opciones de previsualización, y nos permite la salida de resultados en diferentes formatos como PDF, HTML, XLS, RTF y CSV.

Interfaz de usuario de PRD

A continuación vamos a realizar un ejemplo de utilización conectandonos a una base de datos Oracle para obtener diferentes informes de ventas, que nos permitira ver las funcionalidades básicas de PRD, así como todos los elementos que forman su interfaz de usuario.
Estructura de los informes.
Tal y como vemos en la imagen anterior, cuando creamos un informe partimos de una estructura estandar que incluye una serie de secciones que podremos utilizar o no. Las secciones mas habituales son las siguientes:

• Page Header/Page Footer: el contenido indicado en estas secciones sera visible en cada una de las páginas del informe, en cabecera o pie de página según la sección seleccionada.
• Report Header/ Report Footer: el contenido indicado será visible solo una vez, al principio del informe o al final de este. Puede ser utilizado para indicar un titulo o un resumen del informe (en la primera página) o para presentar totales o conclusiones en la última página.
• Group Header/ Group Footer: cuando estamos trabajando con grupos de información, disponemos de estas dos secciones para abrir o cerrar cada grupo de información (sacar titulo al inicio o al final, subtotales, etc).
• Details Body: es la seccion que contiene la información detallada (fila por fila) recuperada de la base de datos. Tambien incluye las secciones Details Header y Footer para incluir cabeceras o titulos y pies.
• No Data: es una sección especial que se visualizara en el informe en el caso de que el set de resultados del informe este vacio.
• Watermark: es una sección especial que nos permite definir una marca de agua (o fondo) que se imprimira como base del informe en cada página de este.

Ejemplo de informe donde podemos ver las secciones que lo forman

En la imagen podeis ver un ejemplo de informe donde se utilizan algunas de las secciones descritas anteriormente (Cabecera de página para incluir el log de una empresa, Report Footer para incluir un gráfico resumen de los datos, cabecera y pie de grupo, detalle, etc). Podeis igualmente ver en la parte derecha del informe la sección Data que veremos mas adelante para definir los origenes de datos, la query que utilizaremos para recuperar datos, así como las funciones y fórmulas para hacer cálculos.
Componentes.
En la parte izquierda de la pantalla, disponemos de una barra de herramienta en las que tenemos los diferentes componentes que podemos utilizar al definir un informe (tal y como vemos en la imagen siguiente). Vamos a ver en detalle cada uno de ellos (de derecha a izquierda según aparecen en la imagen):

Componentes de la barra de herramientas

• Etiqueta (label): elemento básico para añadir texto estático o etiquetas de columna en un informe.
• Campo Texto (text-field): para visualizar el contenido de campos de texto recuperados del dataset del informe.
• Campo Numérico ( number-field): para visualizar el contenido de campos numéricos recuperados del dataset del informe.
• Campo Fecha (date-field): para visualizar el contenido de campos de fecha recuperados del dataset del informe.
• Campo Mensaje (message-field): campo avanzado que nos permite combinar texto, referencias a campos y funciones en una única celda de datos. Por ejemplo, podremos definir un campo de este tipo con el contenido: “Cliente: $codigo_cliente domiciliado en: $poblacion”. Los campos precedidos por $ se refieren a campos del dataset.
• Etiqueta de recurso (resource-label): basandonos en un fichero de recursos, PRD puede traducir etiquetas de textos a otros idiomas.
• Campo de recurso (resource-field): idem que el anterior, pero para campos.
• Mensaje de recurso (resource-message): idem que el anterior, pero para mensajes.
• Campo Imagen (content-field): para visualizar campos del dataset que sean imagenes (recuperados, por ejemplo, de la base de datos).
• Imagen (image): visualiza una imagen proveniente de un archivo o de una URL.
• Elipse (ellipse): dibuja una elipse en el informe.
• Rectangulo (rectangle): dibuja un rectangulo en el informe.
• Linea horizontal (horizontal-line): dibuja una linea horizontal en el informe.
• Linea vertical (vertical-line): dibuja una linea vertical en el informe.
• Gráfico de escala (survey-scale): para dibujar un mini-grafico para representar una escala de 1 a 5.
• Grafico (char): inserta un gráfico de análisis, que se podrá editar mediante el correspondiente editor. Nos permite crear gráficos de barras, de área, de tarta, de lineas, de burbujas, de anillo, radar, etc.

Editor de gráficos

• Código de barras (simple-barcodes): traduce el contenido de un campo a un código de barras que podrá ser leido por un lector apropiado.
• Bar-sparkline,Line-sparkline, Pie-sparkline: para crear mini gráficos de barras, lineas o tarta.
• Banda (band): elemento para agrupar varios elementos y facilitar su formato de forma conjunta.
• external-element-field: válido para cargar subreports externos, desde una URL o desde una ubicación de archivos.
• SubInforme (subreport): nos permite incluir un subinforme dentro de la ejecución de un informe (y al que podremos pasar también parámetros del propio informe padre).

Definición de datasets.
La parte más importante cuando estemos creando un informe es la definición del dataset, pues va a determinar los datos que vamos a poder utilizar dentro de nuestro informe. PRD nos deja trabajar con varios tipos de origenes de datos, como son JDBC, el Metadata de la plataforma BI,  Pentaho Data Integration, origen de datos OLAP, fichero XML, etc. Vamos a ver un ejemplo sencillo utilizando JDBC como origen de datos.

En primer lugar, configuraremos el origen de datos al que nos vamos a conectar utilizando JDBC. A continuación, definiremos las querys que van a determinar los datos devueltos desde el origen de datos, tal y como vemos en la imagen.

Configuración de Dataset - Origen JDBC

Para la construcción de las querys, tenemos un asistente que nos permite ver las tablas disponibles e ir construyendo las diferentes secciones de la sentencia SQL (Select, From, Where, Group By, Having, Order by). Disponemos la opción Preview para ir visualizando los resultados que devolvería la ejecución de la query.

Editor de querys

Una vez concluida la definición de la query, nos aparece en la parte derecha de la aplicación, en la sección Data (tal y como vemos en la imagen siguiente). Tendremos todas las querys que hayamos definido y la lista de campos que devuelve la query, para poder ser utilizados en las diferentes secciones y controles del informe.

Sección Data en PRD

Uso de parámetros y funciones.

Para poder definir restricciones a los datos que devuelvan los informes, PRD nos permite trabajar con parametros, que se nos pediran en el momento de ejecución del informe y que se podrán incluir en las condiciones de las querys definidas. Podremos definir diferentes tipos de parametros, desde lista simple, lista multiple, casilla de selección, radio button, etc. Los valores a mostrar en los filtros también se pueden hacer que sean determinados por el resultado de ejecución de una query contra base de datos (por ejemplo, una lista de provincias para determinar los resultados que queremos mostrar).

Editor de Parametros

Para incluir los parametros en la ejecución de las querys, utilizaremos la notación ${nombre_parametro} en el lugar apropiado. Por ejemplo:

SELECT DISTINCT
‘dim_date_en_us’.'year4′,
‘dim_date_en_us’.'quarter_name’,
‘dim_date_en_us’.'month_number’,
‘dim_date_en_us’.'month_name’
FROM
‘dim_date_en_us’
WHERE
‘dim_date_en_us’.'year4′ = ${param_year}
AND ‘dim_date_en_us’.'quarter_name’ IN (${param_quarter})

Observar el uso de un parametro que es una lista de valores en la ultima linea de la sentencia SQL, utilizando el operador IN para que un campo de una tabla se compare contra una lista de valores.
PRD también nos permite la utilización de funciones para realizar calculos y operaciones complejas (incluyendo la utilización de formulas al igual que vimos con PDI).

Editor de fórmulas

Uso de subinformes.
Otra característica interesante de PRD es la posiblidad de utilizar un informe dentro de otro informe (lo que llaman subinformes). Esto nos puede permitir superar las limitaciones que tiene un generador de informes del tipo Banded. Por ejemplo, lo podremos utilizar para mostrar diferentes vistas del mismo conjunto de datos. Cuando incluimos un subinforme dentro de otro, al hacer doble click accedemos al informe hijo para realizar su modificación y diseño.
Todos los elementos vistos hasta ahora tienen sus correspondientes tablas de propiedades donde podemos configurar su compartamiento, propiedades de formato y visualización, calculos, etc. Disponemos igualmente de una opción de previsualización para ver como quedaría el resultado del informe tras la fase de diseño.
Publicación y ejecución de informes.
Los informes que hayamos creado se pueden ejecutar directamente desde PRD o bien publicarlos en la plataforma BI, momento en el que ya estarán disponibles para ser usados por los usuarios (habrá que acordarse previamente de refrescar la cache del  metadata en la plataforma para que tenga en cuenta y sea accsesible el nuevo informe).

Otras alternativas. Birt y JasperReports.

Ademas de las herramientas propias de Pentaho, la plataforma nos permite integrar con otras de las herramientas de reporting Open Source mas conocidas, como son Birt y JasperReports. Os dejo algunos links donde se explica la forma de configurar y ejecutar informes de Birt y Jasper en la plataforma BI de Pentaho.

• Ejecución de informes BIRT en la plataforma de Pentaho: link.
• Ejecución de informes JASPER en la plataforma de Pentaho: link.

Igualmente, os dejo otros links interesantes donde hablan de la integración de Pentaho con estas herramientas y algunos posibles problemas o cosas a tener en cuenta:

• Todobi.com: Integrando BIRT con Pentaho.
• Eclipse BIRT 2.5 and Pentaho 3.5 Integration and Configuration: link.

Con el uso de PRD y estas dos herramientas alternativas de reporting quedan mas que cubiertas las necesidades de reporting en la plataforma.

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | 4 Comentarios »

17.3. Preparando el analisis dimensional. Definición de cubos utilizando Schema Workbench.

Posted by Roberto Espinosa en 4 julio 2010

En lo referente al análisis dimensional, Pentaho nos proporciona en su plataforma BI una solucion ROLAP a través de lo que llaman Pentaho Analysis Services. PAS esta basado en Mondrian, que es el corazon de este, y en Jpivot, que es la herramienta de análisis de usuario, con el que realizamos la navegación dimensional sobre los cubos desde la plataforma BI y visualizamos los resultados de las consultas. Estas son ejecutadas por Mondrian, que traduce los resultados relacionales a resultados dimensionales, que a su vez son mostrados al usuario en formato Html por Jpivot.

Arquitectura Pentaho Analysis Services

Tal y como vemos en la imagen, donde se representa la arquitectura de Pentaho Analysis Services, el elemento principal del sistema son los ficheros xml donde se representan los esquemas dimensionales. Para construir estos ficheros xml, podriamos utilizar cualquier editor de texto o xml, o bien la herramienta que nos ofrece Pentaho, que se llama Schema Workbench. Pentaho Schema Workbench es la herramienta gráfica que permite la construcción de los esquemas de Mondrian, y además permite publicarlos al servidor BI para que puedan ser utilizados en los analisis por los usuarios de la plataforma.
En los ficheros de esquema XML, se describen la relaciones entre las dimensiones y medidas del cubo (modelo multidimensional)  con las tablas y campos de la base de datos, a nivel relacional.Este mapeo se utiliza para ayudar la traducción de las querys MDX (que es el lenguaje con el que trabaja Mondrian), y para transformar los resultados recibidos de las consultas SQL a un formato dimensional. Vamos a ver a continuación como utilizar PSW para definir los esquemas de nuestro proyecto y publicar los resultados en el servidor BI. Más adelante veremos como funciona jpivot a nivel de frontend, para sacarle todo el partido a los análisis.

Pentaho Schema Workbench.

Como en todas las herramientas de Pentaho, en primer lugar hemos de definir las conexiones a base de datos como paso previo a la configuración de los esquemas. Además, hemos de colocar el driver jdbc en el directorio drivers que cuelga de la instalación de PSW. En nuestro caso, hemos configurado la conexión con Oracle de la siguiente manera:

Definición de la conexion a BD en PSW

Vamos a ver a continuación las tareas básicas para definir un esquema utilizando PSW. Os recomiendo la lectura de la documentación Online de Pentaho referente a este tema antes de continuar, pues en ella se explican los conceptos básicos que tendremos que conocer para realizar el diseño de forma correcta.
En primer lugar, procederemos a crear el Esquema. Un esquema es un contenedor de cubos (tendra un único fichero xml), donde podremos crear tantos cubos como deseemos. La propiedades que se pueden indicar al crear un esquema son un nombre, la descripción, un nombre para la dimensión que agrupara a las medidas y un rol por defecto para utilizar en las conexiones de base de datos. Como ayuda en este momento y en la creación del resto de elementos, podemos poner el ratón en el nombre del atributo a definir, y nos aparecera un texto explicativo de este (tal y como veis en la imagen siguiente).

Creacion esquema

Una vez creado el esquema, procederemos a la creación de los Cubos, aunque previamente hemos de hacer una consideración.  En cada cubo, podemos definir la estructura de tabla de hechos, medidas, miembros calculados y dimensiones. La dimensiones y sus jerarquias podemos definirlas dentro de cada cubo, o crearlas de una forma general dentro del esquema, y luego utilizarlas en los cubos que nos interesen. Esto nos evita tener que definir varias veces lo mismo para cada uno de los cubos, así como reutilizar elementos ya definidos que se tratan en varios cubos. Esta será mi elección de diseño. Por tanto, antes de crear los cubos vamos a crear las dimensiones compartidas con sus correspondientes jerarquías.

Creación de dimensiones compartidas.

Para añadir las dimensiones, seleccionaremos el esquema y pulsaremos la opción Add Dimension. Le daremos un nombre significativo a la dimensión, y seleccionaremos su tipo (TimeDimension en este caso) y una descripción.

Creacion dimension compartida

A continuación, iremos creando las diferentes jerarquias que tenga la dimensión. Por ejemplo, en nuestra dimensión tiempo tenemos la jerarquías: Año – Mes – Dia, Semana – Dia, Año – Trimestre – Mes – Dia, etc. Como veis, podemos tener tantas jerarquías como deseemos. Las jerarquías son los niveles de análisis y detalle de la información de nuestro modelo dimensional, que luego nos permitiran realizar el análisis y la navegación por los datos utilizando Mondrian. En cada jerarquía, indicaremos una serie de parámetros (importantes el hasAll, si queremos que haya un agrupador de todos los valores de la jerarquía, y su descripcion en el caso de que este marcado (allMemberName)). Igualmente importante la clave de la jerarquía y una descripción que luego nos aparecerá al configurar la ejecución del cubo.

Propiedades de la jerarquía de una dimension

Para cada jerarquía, indicaremos una tabla de la dimensión, y a continuación iremos creando los diferentes Niveles (levels) que componen la jerarquía.Para cada nivel, iremos indicando la columna de la base de datos que la describe, el tipo de datos, el tipo de nivel, la columna que contiene la descripción, etc. Esto lo realizaremos para cada uno de los niveles de la jerarquía. El orden con el que vamos creandolos determina la estructura de la jerarquía.

Creación de niveles dentro de la jerarquía

Podemos tener tantas jerarquías como sea necesario dentro de la dimensión. Luego podremos utilizar la que deseemos a la hora de realizar los análisis (la primera será la jerarquía por defecto). Una vez concluido el diseño de todas las dimensiones con sus correspondientes jerarquías, ya podemos proceder a la creación de los cubos.

Creación de Cubos.

Al crear el Cubo, le indicaremos un nombre y una descripción, pudiendo marcar ademas las opciones cache (para que Mondrian trabaje con cache en este cubo) y la opción enabled (para que el cubo sea visible. Sino esta marcada este flag, el cubo no aparecerá).

Creacion del Cubo

A continuación, seleccionaremos la Tabla de Hechos del cubo (a partir de la cual podremos calcular las medidas o indicadores). Antes de proceder a crear las medidas, seleccionaremos las dimensiones que queremos incluir en el cubo, con la opción Add Dimension Usage. Incluiremos todas las dimensiones necesarias(de las compartidas que hemos creado antes). El cubo hereda todas las características que hayamos incluido en la dimensión, incluyendo todas las jerarquías y sus correspondientes atributos.

Como ultimo paso en la creación del cubo, nos tocará definir las Medidas, que van a ser los valores de análisis. Tenemos aquellas que se calculan directamente con campos de la base de datos, y los Miembros Calculados, que son formulas en las que utilizamos otras medidas.  Los atributos que podemos indicar para las Medidas son su nombre, descripción, función de agregación (suma, media, valor máximo, valor mínimo, contador, etc), la columna que genera la medida, si es visible o no (puede interesar que campos intermedios que se utilizan para otras medidas no se vean), tipo de datos, formato y caption (nombre que aparecera cuando lo utilicemos).

Creacion Medida

En lo referente a los Miembros Calculados, los atributos están mas limitados. Podremos indicar su nombre, descripción, caption (nombre que aparecerá en los análisis), si es visible o no, y el atributo mas importante, la formula que genera el valor de la medida calculada. Para indicar los valores de otras medidas, utilizamos la notación [dimension_medidas].[medida]. Por ejemplo, para calcular el importe bruto de ventas, la formula, siguiendo esta notación sera la siguiente: [Measures].[Unidades]*[Measures].[Precio_Bruto]

Publicación del Esquema y utilización desde el portal BI.

Hemos visto los elementos básicos que podemos utilizar en la definición de un esquema de Mondrian y sus cubos. Disponemos de otros elementos, como los NS (Named Set) o los UDF (User Defined Functions), así como los elementos virtuales (Cubos, Dimensiones y Medidas), en los que no vamos a entrar en detalle. Tras construir el esquema, el paso final para poder utilizarlo en los análisis del portal BI de Pentaho es su publicación. Para ello, salvamos el cubo y seleccionamos la opción de menú File –> Publish. Se nos pide la dirección de publicación del servidor, la contraseña de publicación y los datos del usuario. Se realiza la conexión con el servidor y el esquema ya esta disponible para ser utilizado.

Publicacion de un esquema de Mondrian desde PSW

Accedemos al portal para ver si esto es asi. Al crear una nueva vista de análisis, nos aparecen los diferentes esquemas disponibles, y ya aparece el nuestro, ademas de los esquema de demostración que incluye el servidor. Tal y como veis en la imagen, disponemos de nuestro primer análisis. Aparecen todas las dimensiones (aunque solo se visualiza una jerarquía por dimensión) y solo se ve una medida de todas las que hayamos definido.

Aunque veremos más adelante todas las opciones que podremos utilizar con Mondrian y jpivot, rapidamente modificamos el análisis, modificando la configuración de las dimensiones y los indicadores de análisis, y nos queda algo así. Hemos dejado solo la dimensión tiempo, con la jerarquía Año-Mes-Dia partiendo del nivel de mes, y hemos modificado los indicadores (medidas) que se visualizan.

Ejemplo de análisis sencillo

Con la definición del metadatos que vimos en la entrada anterior del blog, y la creación y publicación de los esquema de Mondrian que hemos visto aquí, tenemos el portal de BI listo para profundizar en las herramientas de reporting y para sacar todo el partido de los análisis dimensionales. Estos son los aspectos que vamos a ver en profundidad en las próximas entradas del blog.

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | 3 Comentarios »

17.2. Preparando el reporting. Definición de metadatos con Metadata Editor.

Posted by Roberto Espinosa en 24 junio 2010

La plataforma Pentaho nos proporciona dos formas integradas de realizar reporting, ademas de permitir la utilización e integración de otras herramientas (como JasperReports o Birt). Las herramientas propias de Pentaho son las siguientes:

• Web Ad Hoc Query and Reporting Client (WAQR): herramienta integrada en el portal que nos permite realizar querys y reporting adhoc de una forma intuitiva y sencilla, aunque con limitaciones.
• Pentaho Report Designer (PRD): a través de una herramienta de diseño desktop, que nos permite definir y construir nuestros informes, y luego publicarlos en el portal de BI para que puedan ser ejecutados por los usuarios.

Para poder trabajar con WAQR, es indispensable tener definido el correspondiente metadatos con PME (Pentaho Metadata Editor), ya que es el único origen de datos permitido en la plataforma para ese componente. En cambio, con PRD podremos utilizar otros muchos origenes de datos, aunque también podremos utilizar el metadata definido con PME como origen de datos (y asi poner una capa lógica encima del modelo físico que va a facilitar con toda probabilidad el diseño de informes).
Veamos antes de entrar en detalle con Pentaho Metadata Editor cual es el planteamiento de Pentaho respecto a los metadatos.

¿Que son los metadatos?

Como hemos visto en varias entradas del blog, los metadatos son información sobre los datos. Se utilizan en las herramientas ETL (como vimos al utilizar Talend), en las herramientas BI (como por ejemplo en Microstrategy) y Pentaho también tiene su propio enfoque.
El metadata de Pentaho esta basado en el estandar Common Warehouse Metamodel (CWM), que es una especificación creada y mantenida por el Object Management Group (OMG). Intenta ser un estandar abierto y neutral para permitir el intercambio y representación de metadatos en plataformas Business Intelligence (http://www.omg.org/technology/cwm).

Ventajas del nivel de metadatos.

El hecho de poner este nivel de metadatos por encima del nivel físico de las tablas nos proporciona algunas ventajas bastante evidentes a la hora de trabajar con nuestro sistema BI.

• Interfaz de usuario mas amigable: cuando trabajamos con bases de datos relacionales, se hace complejo la interrogación de la base de datos, pues hay que conocer en profundidad el lenguaje SQL (para sacarle todo el partido a las consultas) y también se hace necesario conocer la estructura física de las tablas. Al poner la capa de metadatos  por encima, describimos las tablas, los campos y sus relaciones, y los podemos presentar al usuario de una forma  mas comprensible para que construya sus  propios reports sin necesidad de conocer la “compleja” realidad que puede haber detras.

• Flexibilidad e independencia del esquema físico: si tenemos un gran número de informes definidos en nuestro sistema BI, y es necesario cambiar la estructura física de los datos, esto nos obligara a modificar todo los informes para adaptarlos a esta casuística. Al tener la capa de metadatos por enmedio, en un caso como este, modificaremos su esquema con los cambios realizados sin necesidad de modificar los informes. En estos casos, la capa de metadatos nos va a ayudar a absorver el impacto de los cambios en el esquema físico de la base de datos.

• Definición de privilegios de acceso: normalmente, las bases de datos nos permiten establecer privilegios de acceso sobre los objetos o sobre las operaciones que se realizan sobre ellos. Pero no nos  permiten establecer privilegios de acceso sobre la granuralidad de los datos (por ejemplo, limitaciones de lectura según las zonas geográficas, en un tipo ejemplo de informes para delegados regionales). Es decir, no tenemos un control de acceso a nivel de registro. A través de los metadatos, podemos establecer autorizaciones de este tipo bien a nivel de usuario o de rol (grupo de autorizaciones), para establecer politicas de acceso a los datos con alto nivel de detalle.

• Gestión de la localizacion (internacionalizacion): la definición de metadatos también nos  puede permitir gestionar la internacionalización de un sistema BI, definiendo propiedades como etiquetas o descripciones de las tablas y columnas a nivel de idioma. Cuando se utilizen esos elementos en los informes, aparecerán en el idioma del usuario, recuperando las descripciones (apropiadas a cada lenguaje) del metadatos.

• Homogeneización del formateo de datos: en un sistema de reporting de BI,  por ejemplo, puede ser aconsejable unificar la representación de los datos, especialmente en aquellos tipos de campos que necesita un formateo especial (importe monetarios, por ejemplo), con sus correspondientes indicadores de moneda, simbolo de decimales o de miles. Igual para el caso de links a otros informes o páginas (que se han de representar de una forma especial) o similares. El metadatos también nos puede ayudar en estos casos a definir un formato asociado a los campos, que luego se aplicara cuando sean utilizados en los informes.

Caracteristicas del metadatos de Pentaho.

Antes de ver como definir nuestro metadatos utilizando PME, vamos a ver como Pentaho utiliza esta capa en la práctica. Cuando definimos el metadatos, al terminar el proceso este queda archivado en un fichero .xmi (o a nivel de base datos, en el repositorio), y se exporta al servidor BI. En este momento ya puede ser utilizado por la herramienta de reporting Adhoc, o bien desde Pentaho Reporting Designer, para construir nuestro propios informes, utilizandolo como si fuese un origen de datos mas (como cualquier origen de base de datos relacional, por ejemplo).
La construcción de los informes se realiza sin necesidad de ver el esquema físico de los datos, sino que utilizamos la definición que se haya descrito en el metadatos. Al ejecutar uno de estos informes, la definición de las querys se guardan en un formato llamado Metadata Query Language (MQL), que se resuelve contra el metadatos, y se traduce a nivel SQL  para lanzar la consulta contra la base de datos en el lenguaje que esta entiende. Tenemos por tanto un motor MQL que se encarga de realizar este mapeo entre el esquema Lógico y el esquema Físico (tal y como podeis ver en la imagen anterior).
Podemos hablar de 3 niveles en la definición del metadatos: physical layer, logical layer y delivery layer.
En primer lugar, tenemos el physical layer, que conocen los consultores de BI en profundidad (pues lo han diseñado y construido según los requerimientos). Corresponde a los campos y tablas de la base de datos. Estos objetos son los componentes que nos van a permitir construir el logical layer (pues no tiene sentido que los usuarios finales tengan que conocer como esta creada realmente la base datos).
En el logical layer, las tablas del nivel físico son redefinidas, y enriquecidas con columnas adicionales construidas a partir de las campos de las tablas y operaciones o expresiones sobre ellas. Ademas establecemos relaciones entre las tablas, que serán la forma de extraer información de forma conjunta (joins). Ademas, podemos crear varias tablas lógicas sobre la misma tabla física, para el tratamiento,por ejemplo, de las dimensiones role-playing (la misma tabla de dimensión juega diferentes roles).

Layers en Pentaho Metadata Editor

En el delivery layer se realiza una selección de columnas de la capa lógica y se agrupan en unidades que tengan sentido para el usuario de negocio (Business View). Esta es la única parte del metadatos que es visible para los usuarios finales, y partir de ella se realizará la construcción de los informes.
En todos los niveles, podemos definir diferentes elementos, que son principalmente conceptos y propiedades. Ademas, se puede establecer como los conceptos pueden heredar propiedades de otros. Veamos un poco más en detalle en que consiste esto:
Propiedades
Los objetos en el metadata pueden tener un gran número de propiedades. Las propiedades son items con nombres que se usan para asociar diferentes tipos de información a los objetos. Las propiedades se pueden dividir en categorias:

• Propiedades generales: como el nombre y la descripción.
• Propiedades de visualización: como fuente de letra, color, etc.
• Descriptores de modelo: expresiones, tipo de datos, reglas de agregacion, etc.

Dependiendo del tipo de objeto con el que estemos  trabajando, habra propiedades que seran obligatorias y habrá que definir siempre. Otras estarán o no disponibles según el tipo de objeto.
Conceptos.
Ademas de las propiedades, en el metadata de Pentaho podemos trabajar con una colección de propiedades y agruparlas en lo que llaman Concepto. Un concepto se puede aplicar a un objeto del metadatos, y sus propiedades son heredadas por el objeto. Por ejemplo, para todos los importes monetarios (que vamos a mostrar con un formato determinado de numeros decimales) o tipo de letra, podemos crear un concepto y luego aplicarlo a todas las columnas que queremos que compartan propiedades comunes. De esta forma, en lugar de modificar las características  en los todos los objetos del metadata, lo haremos en los conceptos y asi nos aseguramos su consistencia y mantenerlo de una forma más fácil.
Herencia.
Las propiedades se pueden gestionar utilizando la herencia. La herencia ocurre basando un objeto (el objeto hijo) en otro objeto (el objeto padre). De esta forma, las propiedades del hijo y sus valores se construyen a partir de las del padre. Los cambios en las propiedades se transmiten en forma de cascada en la cadena de herencia.
Las propiedades que hereda un objeto se pueden quedar como las del padre, o bien ser modificadas y configuradas como una instanciacion propia de dichas propiedades. En ese momento se rompe la cadena de herencia de esa propiedad con respecto al padre. Cuando se modifique algo del padre, no se modificara la propiedad en el  hijo. En Pentaho tenemos dos niveles de herencia:

• Herencia de objetos derivados: los objetos del metadata heredan las propiedades de sus objetos padre. Por ejemplo, definimos una tabla en el nivel físico y configuramos sus propiedades. Al utilizarla en el logical layer, todas las propiedades de nombres de tabla, campos, formatos, autorizaciones que hubieramos definido antes se heredan en el nuevo objeto. Si la tabla fisica se utiliza en varios tablas lógicas, todas heredaran las  mismas propiedades. Puede ser util, pues seguramente para unas columnas  determinadas pondremos unas descripciones y un formato que nos interesan que se utilicen en todos los sitios de la misma manera. En ese caso, cualquier cambio en el modelo físico se transmitiran a los objetos “descendientes”.
• Herencia de conceptos: como hemos visto los conceptos son una forma de asignar propiedades a los objetos de una forma centralizada. Dentro de los conceptos, podemos establecer tambien jerarquía de propiedades, de forma que podemos tener un concepto general, y luego conceptos descendientes de este con propiedades especificas (que luego podremos también asignar a los objetos del metadatos).

Pentaho Metadata Editor.

Como paso final, vamos a ver como definir el metadatos para nuestro modelo (en una entrada anterior del blog vimo como quedaba la estructura física de nuestra base de datos), teniendo en cuenta todas las características de PME vistas hasta ahora.
Al trabajar con PME, podemos utilizar un repositorio local (a nivel de ficheros) o un repositorio de base de datos. El repositorio de PME es independiente del de la plataforma BI o el de Kettle, no tiene nada que ver. Se trabaja con el concepto de Dominio, que es un contenedor que incluye la definición del metadatos.
Los tres niveles que hemos indicado antes (physical layer, logical layer y delivery layer), se implementan de la siguiente manera.

Physical Layer

Contiene los objetos físicos que existen a nivel de base de datos. Es la parte básica de la definición del metadata. Podemos tener varios origenes de datos (varias conexiones), de las que seleccionaremos las tablas que nos interesen para nuestro modelo, y para cada tabla, los campos que la componen. Podemos seleccionar solo aquellos campos que nos interesen, o bien seleccionarlos y luego ocultarlos cuando pasemos al nivel lógico.

• Conexiones: definimos las conexiones de la forma habitual (es necesario tener el jdbc correspondiente y depositarlo en el directorio \libext\jdbc dentro de la carpeta donde tengamos instalado PMD).
• Tablas: desde la conexión, con el menú contextual podremos importar las tablas que queremos añadir a nuestro modelo (con la opción Import Tables o desde Import from explorer). Una vez las tablas estan importadas, podremos modificar sus propiedades, tales como su nombre (incluyendo la internacionalización), descripcion, tipo de tabla (Dimension, Hechos u Otros)

Database Explorer

• Campos: por defecto, se importan todos los campos de las tablas. Posteriormente podemos eliminar aquellos campos que no nos interese tener en el metadata, o bien incluir nuevos campos, como calculos de los existentes o iguales que los existentes pero cambiando determinadas propiedades (por ejemplo, el formato). Al igual que en las tablas, en los campos tenemos un conjunto de propiedades (Nombre, Descripción, Fuente, Color, Alineación del texto, Tipo de datos, forma de agregación). Si el campo es una formula, podremos indicar la composición de esta y también podremos indicar si el campo queremos que este oculto. Además de estas propiedades por defecto, podemos añadir otras, como temas de seguridad, mascaras de edición, ancho de columna, textos explicativos adicionales, etc.

Propiedades de metadata de los campos en una tabla física

A la hora de la construcción de los campos físicos, podemos definir campos que sean operaciones entre varios campos o formulas. Para ampliar la información sobre esta funcionalidad, podeís ver la documentación Online de Pentaho.

Logical Layer.

Una vez tenemos definidos todos los componentes del nivel físico (que van a ser las piezas básicas de nuestro metadatos), continuaremos con el segundo nivel, el nivel lógico.

• Business Models: es un contenedor que nos permite agrupar los objetos lógicos y sus relaciones, para disminuir de la mejor manera posible el impacto de los cambios a nivel físico. Podemos tener varios modelos de negocio dentro de un dominio de metadatos (aunque solo soporta una conexión a base de datos por cada uno de ellos).
• Business Tables y Columns: cuando creamos una nueva Business Table, nos aparece la lista de tablas físicas disponibles en nuestro dominio y seleccionamos las que nos interesan. En ese momento se crean la BT, como una abstracción de la tabla física. Como podeís ver en la imagen, cada tabla lógica (business table) tiene asociada su correspondiente tabla física, y hereda todas las propiedades que tuviera esta. Podemos dejar los atributos como estan o modificarlos en el caso de que nos interese. La tabla también hereda todos los campos que tuviera definidos la tabla física, aunque se pueden eliminar los que queramos. A la hora de añadir, solo se pueden utilizar los definidos en la tabla física, aunque podremos añadir cuantas veces deseemos campos que ya existen y modificar sus propiedades para crear nuevos campos.

Editor de propiedades de las Business Tables

• Relaciones: puede haber casos en que para hacer la lectura de datos, necesitemos juntar varias tablas. En la parte de relaciones, definimos como se va a realizar el join entre las diferentes tablas de nuestro modelo. En la imagen podeis ver el correspondiente editor donde vamos definiendo, en cada tupla de tablas, como va a ser la relación entre ellas.

Editor de relaciones entre Business Tables

Delivery Layer.

La parte final de la definición del metadata es decidir, de todos los elementos de los que disponemos en el modelo de negocio, cuales van a estar a disposición de los usuarios. Esto lo realizamos a traves de las Business Views y las Business Categories. Veamos en que consiste esto:

• Business Views: las vistas de negocio son los contenedores que visualizaran los usuarios, y que contendrán los elementos que van a poder utilizar en el reporting y análisis ad-hoc. Podremos tener varias vistas de negocio a través de lo que llamamos categorias. Las categorias pueden contener una tabla lógica completa o bien una lista de campos seleccionados de varias tablas lógicas. Las diferentes categorias apareceran luego en el reporting, con todos los elementos que hayamos incluido en su definición. Aquí también podremos incluir seguridad para determinar que usuarios pueden trabajar con ellas. Las propiedades de los elementos, igual que con las tablas de negocio, son heredadas de estas, aunque pueden ser modificadas (sobrescribiendo la herencia por defecto).

Gestión de categorias

Hemos realizado la definición del metadata de nuestro proyecto EnoBI para permitir el reporting sobre el.  Como paso final, nos quedaría publicar el metadatos en el portal de BI para poder utilizarlo en el reporting ad-hoc. Para ello, lo publicaremos en el portal (solo puede haber un fichero por solución). También podriamos haber hecho público el fichero ubicandolo en la correspondiente carpeta del servidor (colgando de pentaho-solutions). Igualmente, podemos exportar el fichero xmi para utilizarlo directamente con Pentaho Reporting Designer, como un origen de datos más a la hora de construir los informes.

Publicacion del metadata en el servidor BI

Para trabajar con PRD no hace falta publicar en el servidor BI, sino que accedemos directamente al fichero xmi como origen de datos. Para verificar que el metadata esta correctamente importado en el portal BI, nos conectamos con nuestro usuario de pruebas y realizamos nuestro primer informe Ad-hoc. Todo se ha configurado correctamente.

Informe Adhoc - Ejemplo sencillo de listado de clientes

Podeis ampliar información sobre todo lo visto en esta entrada del blog en la documentación online de Pentaho. A continuación vamos a ver como podemos definir nuestro esquema dimensional utilizando Pentaho Schema Workbench, lo que nos permitira posteriormente trabajar con los análisis sobre los cubos Olap.

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | Deja un Comentario »

17.1. Instalación y configuración de la plataforma BI de Pentaho.

Posted by Roberto Espinosa en 20 junio 2010

Con la ultima versión estable de la plataforma BI descargada de la web de Pentaho (la 3.5.2), y siguiendo las instrucciones de Prashant Raju para esta versión en la plataforma Windows utilizando MySql, realizamos la instalación y configuración de nuestro sistema realizando los siguientes pasos:
1) Requisitos previos: maquina virtual Java y la base de datos MySQL (u otra de las soportadas).
Para poder ejecutar la plataforma de BI de Pentaho es necesario disponer de una máquina virtual Java instalada en el equipo donde vamos a trabajar. Pentaho recomienda la versión 1.5 de Sun JRE. Con versiones anteriores no funciona y la 1.6 no esta oficialmente soportada (es la que tengo instalada yo), aunque si funciona.
Para ver la versión instalada, ejecutaremos el comando: java  -version. En el caso de no disponer de la máquina, podemos descargarla en la web de Sun.
A continuación comprobaremos que la variable de entorno JAVA_HOME apunte al directorio donde tenemos instalado Java. Igualmente, la variable PATH también debera apuntar al directorio de ejecutables de la instalación de Java. En mi caso, el valor de las variables será el siguiente:

JAVA_HOME   c:\Program Files\Java\jdk1.6.0_17
PATH        c:\Program Files\Java\jdk1.6.0_17\bin;.....

Para configurar las variables, lo realizaremos desde Propiedades del Sistema, Variables de Entorno.
Con respecto a MySQL, en el caso de que no lo tengamos instalado en nuestra máquina, lo descargaremos de la web y realizaremos la instalación según las instrucciones que nos proporcionan en su portal de documentación.
2) Descomprimir los ficheros de la plataforma.
Seleccionamos una carpeta (por ejemplo c:\pentaho), y en ella vamos a descomprimir el fichero Zip que nos hemos bajado de la web. Tras el proceso, tendremos dos carpetas diferenciadas, llamadas administration-console y biserver-ce. La primera carpeta alberga los ficheros de la plataforma de administración, que utilizamos para configurar y administrar el servidor BI (utiliza Jetty). La segunda, es la plataforma de BI propiamente dicha (la que utilizarán los usuarios), que utiliza tomcat.
En este momento, ya podriamos arrancar la plataforma desde los correspondientes scripts que se encuentran en la carpeta c:\pentaho\biserver-ce (start-pentaho.bat para iniciar el servidor y stop-pentaho.bat para pararlo). Este Script arranca en primer lugar la base de datos HSQLDB de ejemplo (donde residen las datos necesarios para el funcionamiento de la plataforma, junto con datos de pruebas para los ejemplos precargados). A continuación, arranca la plataforma de BI, a través del tomcat. Como no queremos trabajar con esa base de datos, sino con MySQL, vamos a proceder a realizar una serie de ajustes antes de arrancar la plataforma.
3) Creación de catalogos en base de datos necesarios para la plataforma.
La plataforma Pentaho necesita dos bases de datos para su funcionamiento (además de la base de datos de test para poder trabajar con el set de ejemplos). Las bases de datos y su cometido son las siguientes:

• hibernate: esta base de datos almacena la autentificación de usuarios y los datos de autorizaciones, el contenido BI (solution repository) y los origenes de datos disponibles en la plataforma.
• quartz: es el repositorio para el scheduler Quartz, que es uno de los componentes que forma la plataforma, que nos permite la planificación de procesos dentro del servidor BI.
• sampledate: contiene las tablas para ilustrar y hacer posible la ejecución de todos los ejemplos por defecto que proporciona la plataforma, para poder hacernos una idea de sus funcionalidades y sus posibilidades de análisis.

Por defecto, los catálogos de estas bases de datos estarán creados en la base de datos HSQLDB que se puede arrancar en la configuración del servidor por defecto.  Para crearlos en MySQL, como es nuestro caso, ejecutaremos los scripts que se encuentran en la carpeta c:\pentaho\biserver-ce\data o bien descargarlos de la web de Prashant Raju. Decido utilizar estos últimos, pues ademas de crear todos los catalogos de tablas, también incluye la carga de datos de ejemplo (paso 5), que es una opción que no incluye la instalación estandar. El orden de ejecución será el siguiente:

mysql> source 1_create_repository_mysql.sql;
 ...output
 mysql> source 2_create_quartz_mysql.sql;
 ...output
 mysql> source 3_create_sample_datasource_mysql.sql;
 ...output
 mysql> source 4_load_sample_users_mysql.sql;
 ...output
 mysql> source 5_sample_data_mysql.sql;
 ...output

La ejecución de los scripts sql la realizaremos desde MySQL Query Browser (la herramienta gráfica para ejecución de sentencias SQL) o bien desde linea de comandos con la utilidad mysql que llevar incluido el servidor MySQL para ejecutar scripts. Podiamos haber utilizado cualquier otro editor sql, como SQuirreL.
4) Configuracion JDBC, Hibernate and Quartz.
Todas las aplicaciones de Pentaho, incluyendo el Pentaho Server, utilizan la conectividad JDBC (Java Database Connectivity) para la comunicación con las bases de datos. Por tanto, será necesario disponer de los correspondientes conectores según la base de datos que vayamos a utilizar. En nuestro caso, vamos a dejar tanto el conector para MySQL (donde iran las bases de datos de Hibernate y Quartz), como el de Oracle (donde va la base de datos del DW). Las carpetas donde vamos a copiar serán las siguientes:

• C:\Pentaho\biserver-ce\tomcat\common\lib: ubicación de los drivers JDBC para poder utilizar en el servidor Pentaho la base de datos para la que el conector proporciona conectividad.
• C:\Pentaho\administration-console\jdbc: es necesario ponerlos aquí también para poder definir correctamente las conexiones a base de datos en la consola de administración.

A continuación, configuraremos los ficheros de parametrización del sistema para que Hibernate y Quartz lean de los catalogos de base de datos en Mysql que hemos creado en el punto 3, en lugar de la base de datos HSQLDB proporcionada por defecto.

• Configuracion de Hibernate (I): en el fichero applicationContext-spring-security-jdbc.xml (ubicado en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system), modificaremos la parte que veis subrayada a continuación, con los valores referidos para utilizar MySQL.

<!--  This is only for Hypersonic. Please  update this section for any other database you are using --> 

<bean id="dataSource"

class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName" value="com.mysql.jdbc.Driver" />

<property  name="url"

value="jdbc:mysql://localhost:3306/hibernate"  />

<property  name="username" value="hibuser" />

<property name="password" value="password" />

</bean>

• Configuracion de Hibernate (II): en el fichero applicationContext-spring-security-hibernate.xml (ubicado en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system), modificaremos la parte que veis subrayada a continuación, con los valores referidos para utilizar MySQL.

jdbc.driver=com.mysql.jdbc.Driver

jdbc.url=jdbc:mysql://localhost:3306/hibernate

jdbc.username=hibuser

jdbc.password=password

hibernate.dialect=org.hibernate.dialect.MySQLDialect

• Configuración de Hibernate (y III): en el fichero hibernate-settings.xml ( ubicado en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system\hibernate), modificaremos la parte que veis subrayada a continuación.

<config-file>system/hibernate/mysql5.hibernate.cfg.xml</config-file>

Con la configuración anterior, hemos configurado la seguridad JDBC de la plataforma. Ahora nos falta indicar en los contextos del servidor de aplicación, la ubicación de las bases de datos, para decirle al servidor que lea de las bases de datos en Mysql, utilizando los drivers y la configuración de seguridad realizada anteriormente. Para ello, modificamos el fichero contexts.xml (ubicado en C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\META-INF) de la siguiente manera:

<?xml version="1.0" encoding="UTF-8"?>
 <Context path="/pentaho" docbase="webapps/pentaho/">
 <Resource name="jdbc/Hibernate" auth="Container" type="javax.sql.DataSource"
 factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
 maxWait="10000" username="hibuser" password="password"
 driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/hibernate"
 validationQuery="select 1" />

<Resource name="jdbc/Quartz" auth="Container" type="javax.sql.DataSource"
 factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
 maxWait="10000" username="pentaho_user" password="password"
 driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/quartz"
 validationQuery="select 1"/>
 </Context>

Con esta configuración ya tendriamos lista la parte de conectividad con la base de datos. Solo en el caso de que no hubieramos utilizado los scripts de Prashant Raju, tendriamos que realizar un último paso, que sería ejecutar la siguiente sentencia SQL para indicarle al servidor que los datos de ejemplo los hemos cambiado de lugar:

UPDATE hibernate.DATASOURCE
 SET DRIVERCLASS = 'com.mysql.jdbc.Driver’,
 URL = 'jdbc:mysql://localhost:3306/sampledata’,
 QUERY = 'SELECT 1’
 WHERE NAME = 'SampleData’
 ;

5) Configuración Servidor Apache-Tomcat.
La plataforma Pentaho utiliza Apache-Tomcat como servidor de aplicaciones para desplegar los servicios que la componen. El servidor lleva una configuración por defecto que podemos modificar (por ejemplo, para variar el puerto donde nos conectamos, para el caso de que haya conflicto con otras aplicaciones instaladas en el servidor), la ubicación html, el lenguaje, etc. Para ello, modificaremos el fichero web.xml que se encuentra en la carpeta C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\WEB-INF. Veamos alguna de la cosas que podemos cambiar.
solution-path
Con este parámetro, le indicamos a la plataforma BI la ubicación de la carpeta pentaho-solutions. Por defecto, tiene el valor c:\biserver-ce\.

En nuestro caso, vamos a cambiar el valor para que apunte a la carpeta donde hemos instalado:

<context-param><param-name>solution-path</param-name>
 <param-value>C:\Pentaho\biserver-ce\pentaho-solutions</param-value>
 </context-param>

base-url
Al instalar, la ruta URL por defecto para acceder a la plataforma será la siguiente: http://localhost:8080/pentaho
Podemos cambiarla si lo desamos modificando el parmetro base_url dentro del mismo fichero. En nuestro caso, como vamos a cambiar el puerto por defecto, modificamos su valor indicando lo siguiente:

<context-param>
 <param-name>base-url</param-name>
 <param-value>http://localhost:9999/pentaho/</param-value>
 </context-param>

Esto nos obligará a cambiar tambien la configuración del fichero server.xml, que veremos mas adelante.
port
En la ruta C:\Pentaho\biserver-ce\tomcat\conf, tenemos el fichero server.xml, donde podemos modificar el puerto por defecto de nuestro servidor BI (que es el 8080).

<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
 <Connector port="9999" maxHttpHeaderSize="8192"
 maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
 enableLookups="false" redirectPort="8443" acceptCount="100"
 connectionTimeout="20000" disableUploadTimeout="true" />

Ahora pararemos el servidor tomcat y al arrancar la nueva URL de acceso será la siguiente: http://localhost:9999/pentaho
6) Otros elementos. Scripts arranque. Configuración de la publicación de contenidos y del correo SMTP.
Antes de continuar, vamos a ajustar el script de arranque de la plataforma BI, omitiendo la parte de arranque de la base de datos HSQLDB, que por defecto se arranca cuando lanzamos el script start-pentaho.bat (de la carpeta c:\pentaho\biserver-ce). Es tan sencillo como comentar la linea donde se arranca la base de datos. El script quedaría como sigue (la linea subrayada se ha comentado para que no se ejecute):

@echo off
setlocal
cscript promptuser.js //nologo //e:jscript
rem errorlevel 0 means user chose "no"
if %errorlevel%==0 goto quit
echo WScript.Quit(1); > promptuser.js

if exist "%~dp0jre" call "%~dp0set-pentaho-java.bat" "%~dp0jre"
if not exist "%~dp0jre" call "%~dp0set-pentaho-java.bat"

cd data
rem start start_hypersonic.bat
cd ..\tomcat\bin
set CATALINA_HOME=%~dp0tomcat
set CATALINA_OPTS=-Xms256m -Xmx768m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
set JAVA_HOME=%_PENTAHO_JAVA_HOME%
call startup
:quit
endlocal

Ademas de toda la configuración realizada hasta ahora, nos quedan por configurar dos aspectos importantes para el funcionamiento del sistema:

• Publicación de contenido: por defecto, la publicación de contenido en el servidor BI esta desactivada, por lo que para publicar los informes o análisis que vayamos realizando, lo deberiamos de hacer dejando los ficheros en la correspondientes carpetas del servidor. Pero es mas fácil hacerlo mediante lo que se llama publicación (que veremos en detalle mas adelante). Para habilitar la publicación, modificaremos el fichero publisher_config.xml, que se encuentra en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system. Ahí indicaremos la contraseña de publicación. Por defecto, no tiene ninguna contraseña, y por tanto, no esta habilitada la publicación.

<publisher-config>
 <publisher-password>passpublic</publisher-password>
</publisher-config>

• Servicio de correo SMTP: como ultimo paso, configuraremos la posibilidad de envio de correo electrónico, a través de un servidor externo (ya que la plataforma no dispone de un servidor de correo electrónico propio). Para ello, configuraremos el fichero email-config.xml en el directorio C:\Pentaho\biserver-ce\pentaho-solutions\system\smtp-email, de la siguiente manera:

<email-smtp>
 <properties>
 <mail.smtp.host>smtp.gmail.com</mail.smtp.host>
 <mail.smtp.port>587</mail.smtp.port>
 <mail.transport.protocol>smtps</mail.transport.protocol>
 <mail.smtp.starttls.enable>true</mail.smtp.starttls.enable>
 <mail.smtp.auth>true</mail.smtp.auth>
 <mail.smtp.ssl>true</mail.smtp.ssl>
 <mail.smtp.quitwait>false</mail.smtp.quitwait>
 </properties>
 <mail.pop3></mail.pop3>
 <mail.from.default>respinosamilla@gmail.com</mail.from.default>
 <mail.userid>respinosamilla@gmail.com</mail.userid>
 <mail.password>password</mail.password>
</email-smtp>

En este caso, estoy utilizando gmail para enviar los correos desde la plataforma. Los valores subrayados son los que yo he indicado. En el caso de estar utilizando otro servidor de correo, tendreís que modificar la configuración de servidor, puertos, tipo de conexión, ect, para que funcione según la configuración de este. Con esta funcionalidad habilitamos la distribución de contenido a través del correo electrónico (por ejemplo, para el envío de la ejecución de informes o análisis).
En este momento, ya podemos arrancar la plataforma. Al iniciarla, y conectarnos en el puerto http://localhost:9999, nos aparece la consola de usuario, con una configuración por defecto. Tendría el siguiente aspecto.

Consola de Usuario por defecto

Ya podemos conectarnos con alguno de los usuarios existentes y trastear con el proyecto de ejemplo Steel Wheels o la colección de muestras y ejemplos que incluye la plataforma. Con ellos nos podemos hacer una idea de las posibilidades de análisis de las que vamos a disponer.

Personalizando la plataforma de usuario.

Como queremos personalizar el portal, vamos a realizar algunos cambios en la consola de usuario (también llamada Mantle). Para ello, vamos a utilizar el blog de Prashant Raju donde nos explica muy bien los pasos a seguir para configurar nuestra plataforma. Esta personalización va a consistir en lo siguiente:

No queremos que aparezcan los usuarios de ejemplo al conectarnos al sistema.

Con la configuración por defecto del sistema, cuando entramos al portal de usuario, nos aparece la siguiente ventana:

Aparecen los usuarios de ejemplo, y al seleccionarlos podemos entrar directamente en la plataforma (sin necesidad de recordad su nombre de usuario o contraseña), ya que el sistema nos lo recuerda. Esto no es operativo para un sistema productivo, y por tanto, vamos a modificarlo. Para ello, modificaremos el fichero loginsettings.properties (ubicando en la carpeta C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantleLogin). La configuración por defecto del fichero es la siguiente:

# this file contains settings to configure the login dialog
# flag to turn on/off show users list (overrides pentaho.xml)
#showUsersList=true
# launch PUC in new window (default setting)
openInNewWindow=false
# sample users (be sure that each group has the same # of items as the rest)
userIds=joe, suzy, pat, tiffany
userDisplayNames=Joe (admin), Suzy, Pat, Tiffany
userPasswords=password, password, password, password

Vamos a modificar los valores de la siguiente manera:

# this file contains settings to configure the login dialog
# flag to  turn on/off show users list (overrides pentaho.xml)
showUsersList=false

Reiniciamos el servidor y al entrar en el portal, el aspecto de login habrá variado, apareciendo la siguiente pantalla:

Este login es mas acorde con un sistema donde hay que mantener la seguridad.

Ventana de conexión personalizada para nuestra empresa.

Para modificar el aspecto de la ventana de login, hemos de modificar el fichero PUC_login.jsp que se encuentra en la carpeta C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\jsp. En este fichero hemos modificado textos, alguna de las imagenes que aparecen, hasta conseguir el siguiente aspecto:

Esto es solo un ejemplo sencillo de como podemos ajustar el diseño de la página a las necesidades corporativas de una empresa (logos, infografia, etc). Os dejo el link al fichero PUC_login.jsp modificado.

Configuración de mensajes de login y de mensajes de error.

Para modificar los mensajes de usuario en el momento del login, habrá que modificar el fichero MantleLoginMessages_es.PROPERTIES (para el caso del idioma castellano, o el fichero MantleLoginMessages_en.PROPERTIES en el caso de estar trabajando con el ingles). El fichero se encuentra en dos ubicaciones distintas y habra que modificarlo en ambos casos para que siempre salgan los mismos mensajes. Las ubicaciones son las siguientes:

• C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantleLogin\messages
• C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantle\messages

Cambiaremos los textos de los mensajes, y al grabar el fichero automaticamente seran utilizados por el servidor con los nuevos valores.

Personalización del panel de control y del area de trabajo.

Se pueden personalizar muchisimos aspectos de la consola de usuario (area de trabajo), tal y como nos cuenta Prashant Raju en su blog, desde los logotipos, barras de menu, barra de herramientas, colores, etc. En nuestro ejemplo, vamos a modificar el fichero launch.jsp (ubicado en C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantle\launch). En el ejemplo, he modificado el fichero para que en la parte de la derecha aparezca mi blog a los usuarios de la plataforma, en el momento de conectarse. El resultado es el siguiente:

Workspace personalizado

Este es solo un ejemplo sencillo de lo que se puede personalizar, que puede ser casi todo (hasta el código fuente si fuese necesario).
Con todos los elementos que hemos configurado, la plataforma de BI de Pentaho esta preparada y lista para ser utilizada, y ademas personalizada a nuestro gusto o necesidades. A continuación vamos a ir viendo las diferentes herramientas que nos proporciona Pentaho para construir nuestros análisis y la forma de configurar su ejecución dentro de la plataforma BI de Pentaho. Además realizaremos la configuración del metadata y la definición de los cubos Olap que luego nos permitiran realizar los análisis dimensionales.

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | 10 Comentarios »

17. Implementando nuestro sistema BI con Pentaho.

Posted by Roberto Espinosa en 8 junio 2010

Durante los próximos días vamos a montar nuestro sistema de Business Intelligence utilizando la Community Editión de Pentaho. Hemos conseguido concluir el diseño de los procesos ETL que van a llenar nuestro Data Warehouse a partir de nuestros sistemas origen y ahora queremos explotar esta información en los diferentes ambitos de la inteligencia de negocio, pero con Pentaho CE. Para ello, configuraremos en primer lugar la plataforma de BI, realizando las siguientes tareas:

• Descarga del software necesario: nos descargamos la ultima versión estable de los diferentes elementos de la plataforma y del proyecto en la web de Pentaho.
• Instalación y configuración de la plataforma BI para utilizar con MySql y Windows 7. En esta base de datos tendremos el catalogo para el BI Server (aunque la base de datos del DW la tendremos en Oracle, como ya vimos).
• Personalización del portal: realizaremos un tuneado del portal para adaptarlo a los requerimientos del proyecto, personalizando logotipos, pantalla de inicio, menús, para ver las posibilidades de configurarlo según las necesidades del cliente. Prepararemos igualmente el metadata y los diferentes cubos de análisis antes de continuar con el resto de herramientas.

A continuación, una vez preparada la plataforma, iremos haciendo un recorrido por las diferentes soluciones de las que dispone Pentaho para abordar el análisis de nuestro datos:

• Reporting: Pentaho Report Designer. Otras posibilidades de reporting (Birt y JasperReports).
• Analisis Olap: Cubos Olap y navegación dimensional con Mondrian, jpivot y stpivot.
• Cuadros de mando y tableros en Pentaho con Community Dashboard Framework (CDF).
• DataMining con Weka.
• Integración de otros componentes: Design Studio.

Los materiales que vamos a utilizar para este cometido serán principalmente los siguientes:

• Libro Pentaho: como guia para el recorrido por todas las soluciones he elegido el libro Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL, escrito por Roland Bouman, Jos van Dongen.
• Documentación Web:  BI Server 2.x-3.x Community Documentation, Mondrian, Pentaho Reporting, Weka, Wiki de la comunidad Pentaho, Community Dashboard Framework, Demos y Videos, Youtube, etc.

• Prashant Raju: en su blog ha incluido una serie de articulos donde explica aspectos tan interantes como la personalización de la consola de Usuario de Pentaho (Mantle), guias de instalación y configuración para trabajar con diferentes bases de datos ( MySql, PostgreSQL y Oracle ), serie de tutoriales para trabar con Pentaho Report Designer, etc.
• Maquina Virtual: en dataprix.com, gracias al magnifico trabajo de Carlos Fernandez y Dario Bernabeu, teneis una máquina virtual de la plataforma Pentaho totalmente operativa, incluyendo ejemplos de todos los componentes listos para funcionar. Puede ser un punto de partida para ver una plataforma totalmente operativa, utilizando VMWare.

La arquitectura de nuestro sistema va a ser la siguiente:

Configuración de nuestro sistema BI

Os adelanto que nos va a tocar modificar bastantes ficheros de configuración para que todo funcione correctamente y para personalizar tanto el portal como el funcionamiento de las herramientas, lo cual resulta un poco farragoso en ocasiones. Por ejemplo, para las conexiones a Base de Datos, hay que configurar lo mismo en un montón de sitios, echandose de menos una especie de repositorio común.  Empezemos…

Compartelo:

• Share
• 
  

Publicado en Business Intelligence, OpenSource, Pentaho | Deja un Comentario »

16.4. Comparativa ETL Talend vs Pentaho Data Integration (Kettle).

Posted by Roberto Espinosa en 1 junio 2010

(Read in English language here)

Vamos a intentar en esta ultima entrada de la serie de procesos ETL realizar una comparativa lo mas completa posible de las herramientas Talend Open Studio y Pentaho Data Integration (Kettle), que hemos estado utilizando en los últimos meses. Para que este estudio sea lo mas completo y riguroso posible, vamos a dividir esta tarea en 5 secciones:

Ejemplo de proceso ETL utilizando Talend

• Tabla de características.
• Ejemplos de Uso.
• Cuadro de puntos fuertes/puntos debiles.
• Links de recursos (comparativas e informacion adicional).
• Conclusiones.

Tabla de Características.

Producto	TALEND OPEN STUDIO ver.4.0	PENTAHO DATA INTEGRACION CE (KETTLE) ver 3.2
Fabricante	Talend – Francia	Pentaho – Estados Unidos
Web	www.talend.com	www.pentaho.com
Licencia	GNU Lesser General Public License Version 2.1 (LGPLv2.1)	GNU Lesser General Public License Version 2.1 (LGPLv2.1)
Lenguaje de desarrollo	Java	Java
Año de lanzamiento	2006	2000
Entorno gráfico	Herramienta gráfica basada en Eclipse	Herramienta de diseño (Spoon) basada en SWT
Entorno de ejecución	Desde la herramienta de diseño, o a nivel de línea de comandos con Java o Perl (independiente de la herramienta)	Desde la herramienta de diseño, o desde línea de comandos con las utilidades Pan y Kitchen.
Características	Con la herramienta de diseño construimos los Jobs, utilizando el set de componentes disponibles.Trabaja además con el concepto de proyecto, que es un contenedor de los diferentes Jobs que lo forman y sus metadatos y contextos.Talend es un generador de código, de forma que los Jobs definidos son traducidos al correspondiente lenguaje (podemos elegir Java o Perl al crear un proyecto), compilados y ejecutados.Los componentes se enlazan entre si con diferentes tipos de conexiones. Una son de paso de información (que pueden ser del tipo Row o Iterate, segun la forma de pasar los datos). Ademas, se pueden conectar unos con otros con conexiones disparadoras (Run If, If Component Ok, If Component Error), que nos permiten articular la secuencia de ejecución y su control.Una vez se termina el diseño de los trabajos, se exportan a nivel de SO, y se pueden ejecutar independientemente de la herramienta de diseño en cualquier plataforma que permita la ejecución del lenguaje seleccionado. Además, todo el código generado es visible y modificable (aunque lo modifica la herramienta al realizar cualquier cambio en los Jobs).	Con la herramienta de diseño Spoon construimos las transformaciones (mínimo nivel de diseño) utilizando los pasos o steps. En un nivel superior tenemos los Jobs, que permiten ejecutar las transformaciones y otros componentes, y orquestar los procesos.PDI no es un generador de código, es un motor de transformación, donde los datos y sus transformaciones están separadas.Las Transformaciones y Jobs son almacenadas en formato XML, donde se especifican las acciones a realizar en los datos.Para construir las transformaciones, se utilizan los pasos o componentes, que se enlazan entre si mediante saltos o steps, que determinan el flujo de datos entre los diferentes componentes.Para los jobs, tenemos otro set de pasos, en los que podemos realizar diferentes acciones (o ejecutar transformaciones). Los steps o saltos en este caso determinan el orden de ejecución o la ejecución condicional.
Componentes	Talend tiene una gran cantidad de componentes. El enfoque es tener un componente distinto según la acción a realizar, y para el acceso a   base de datos u otro sistemas, hay componentes diferentes según el motor de base de datos al que vayamos a atacar. Por ejemplo, tenemos un table input para cada fabricante (Oracle, MySQL, Informix, Ingres) o uno para la gestión de SCD para cada SGBDR. Podeis ver la lista de componentes disponibles aquí.	Set mas reducido de componentes, pero muy orientados a integración de datos. Para acciones similares (por ejemplo, lectura de tablas de BD), un único paso (no uno por cada fabricante), y el comportamiento según la base de datos lo define la conexión. Los elementos disponibles son: para las transformaciones ver aquí y para los jobs aquí.
Plataforma	Windows, Unix y Linux.	Windows, Unix y Linux.
Repositorio	Trabaja con el concepto de workspace, a nivel de sistema de ficheros. En ese lugar se almacenan todos los componentes de un proyecto (todos los Jobs, su definición de metadatos, código personalizado y contextos). El repositorio se actualiza con las dependencias de objetos al ser modificados (se expanden a todo el proyecto los cambios). Si modificamos el repositorio de una tabla, por ejemplo,  se actualiza en todos los Jobs donde se utiliza.	Los Jobs y transformaciones son almacenados en formato xml. Podemos elegir almacenar a nivel de sistema de fichero o en el repositorio de base de datos (para trabajo en equipo). No se actualizan las dependencias si modificamos una transformación llamada desde otra, por ejemplo. Si a nivel de componentes dentro de una misma transformación o job.
Metadatos	Completo metadata que incluye las conexiones a base de datos y los objetos de esta (tablas, vistas, querys). Al traer el metadata de los objetos de BD deseados, no se vuelve a acceder al sistema origen o destino, lo que agiliza los procesos. Además, podemos definir metadatos de estructuras de ficheros (delimitados, posicionales, Excel, xml, etc), que luego pueden ser reutilizados en cualquier componente. Se almacenan de forma centralizada en el repositorio (workspace)	EL metadata se limita a las conexiónes de base de datos, que si pueden ser compartidas por diferentes transformaciones y jobs.La información de metadata de base de datos (catalogo de tablas/campos) o de ficheros esta en los pasos y no se puede reutilizar. Además se lee en el momento de diseño.
Contextos	Set de Variables que se configuran en el proyecto y que se pueden utilizar luego en los Jobs para personalizar su comportamiento (por ejemplo para definir entorno de desarrollo y productivo).	Uso de variables en fichero de parámetros de la herramienta (fichero kettle. Properties). Paso de parámetros y argumentos a los procesos (similar a los contextos).
Versiones	Nos permite realizar una completa gestión del versionado de objetos (pudiendo recuperar versiones anteriores)	Funcionalidad prevista en la versión 4.0.
Lenguajes para definir componentes propios (scripting)	Talend nos permite introducir nuestro código personalizado utilizando Java y Groovy.Además podemos realizar scripting en SQL y Shell.	PDI utiliza JavaScript para los cálculos y formulas.Ademas podemos realizar scripting con SQL, Java, Shell y formulas Open Office.
Herramientas complementarias	Talend dispone de herramientas complementarias para Data Profiling y Gestión de Datos Maestros (MDM). En Open Studio tenemos una herramienta de modelado sencilla para dibujar procesos y modelos lógicos.	PDI ofrece en la versión 4.0 la funcionalidad Agile para modelado dimensional y su publicación en Pentaho BI.
Plugins	Descarga de nuevos componentes a través de Talend Exchange.	Incorporación de plugins adicionales en la web.
Soporte	Un completa comunidad online con Talend’s wiki, Talend Forum y bugtracker, para la gestión de incidencias y Bugs.	Incluye el Pentaho forum, Issue Tracking y la Pentaho Community.
Documentación	Completa documentación en pdf que incluye: Manual de Instalación, Manual de Usuario y Documentación de componentes.	Documentación Online en la web. Libros: Data Integration-Pentaho 3.2 Beginner’s Guide(M.C.Roldan), Pentaho Kettle Solutions (M.Casters, R.Bouman, J.van Dongen).

Ejemplos de Uso.

EJEMPLO	TALEND OPEN STUDIO	PENTAHO DATA INTEGRATION (KETTLE)
Carga de dimensión tiempo de un DW	Proceso ETL para la carga de la Dimensión Tiempo. Ejemplo de uso de la ETL Talend.	ETL Dimensión Tiempo con PDI.
Ejecución de sentencias sql dinámicas	Mas ejemplos de Talend. Ejecución de sentencias SQL construidas en tiempo ejecución.	Paso de parametros y operaciones dinamicas en una transformación de PDI.
Carga de dimensión producto de un DW	ETL para carga Dimension Producto. Mas ejemplos de Talend. Uso de logs, metricas y estadisticas.	ETL Dimensión Producto con PDI (I). Extraccion a Stage Area.ETL Dimensión Producto con PDI (II). Carga al DW.
Carga de dimensión cliente de un DW	ETL Talend Dimension Cliente.Tipos de Mapeo para lookup.	ETL Dimensión Cliente con PDI.
Tratamiento de dimensiones lentamente cambiantes	Gestión de SCD (Dimensiones lentamente cambiantes).	Tratamiento de Dimensiones Lentamente Cambiantes (SCD) con PDI.
Conexión al ERP Sap	Ejemplo Talend para conectarnos a Sap	Ejemplo Kettle para conectarnos a Sap (con el plugin ProERPConn)
Carga de tablas de hechos de ventas en un DW	Tabla Hechos Venta. Ajuste diseño fisico y procesos carga ETL. Contextos en Talend.	ETL Carga de hechos de ventas con PDI.ETL Carga de hechos de presupuestos con PDI.
Exportación de Jobs y planificación procesos	Exportación jobs en Talend.Planificacion procesos ETL.
Tratamiento de datos públicos	Modelo de Datos y Procesos de Carga del DW de datos públicos de Londres.
Explicación de la interfaz de usuario		Construccion procesos ETL utilizando Kettle (Pentaho Data Integration)
Proyecto de Grado (comparativa Pentaho/JasperETL). Realizado por Rodrigo Almeida y Mariano Heredia	Proyecto fin de carrera donde se detalla un proyecto de Business Intelligence, utilizando las herramientas de Pentaho y Jasper. En la parte de ETL´s, se compara Kettle con JasperETL (basado en Talend).	Descarga del libro en la web: http://sites.google.com/site/magm33332/bifloss. Incluye un magnifico detalle de las características de cada herramienta.

Como ejemplos adicionales, podeis consultar igualmente:

• Tutorial de Talend Open Studio 4 realizado por Victor Javier Madrid en la web adictosaltrabajo.com. Incluye otro ejemplo para procesar un fichero EDI con Talend.
• Libro blanco de las heramientas ETL Open Source, realizado en frances por Atol. Incluye una serie de ejemplos prácticos muy completos.

Ejemplo de proceso ETL utilizando Pentaho Data Integration

Cuadro de puntos fuertes/puntos debiles.

Desde mi punto de vista, con la experiencia de utilización de las dos herramientas y la información recopilada sobre las herramientas y la experiencia de usuarios, puedo destacar los siguientes aspectos:

TALEND OPEN STUDIO	PENTAHO DATA INTEGRATION (KETTLE)
Es un generador de código, y este aspecto hace que tenga una gran dependencia del lenguaje elegido en los proyectos (Java en mi caso). Al elegir Java, tenemos todas las ventajas e inconvenientes de este lenguaje. Se necesita tener un nivel alto de este lenguaje para sacarle el máximo partido a la aplicación.	Es un motor de transformación, y desde el principio se observa que ha sido diseñado por gente que necesitaba cubrir sus necesidades en la integración de datos, con gran experiencia en ese ámbito. Igualmente, es mas fácil gestionar los tipos de datos con PDI, pues no es tan riguroso como Java.
Herramienta poco intuitiva y difícil de entender, pero una vez superada esta dificultad inicial se observan las grandísimas posibilidades y la potencia de la aplicación.	La herramienta es muy intuitiva, y con unos conceptos básicos te puedes poner a hacer cosas. Conceptualmente muy sencilla y potente.
Interfaz de usuario unificada en todos los componentes. Basada en Eclipse, el conocimiento de la herramienta nos facilita el uso de la interfaz.	El diseño de la interfaz puede resultar un poco pobre, y no hay una interfaz unificada en todos los componentes, siendo en ocasiones la interfaz de los componentes confusa.
La empresa Talend esta invirtiendo gran cantidad de recursos en su desarrollo (gracias a aportaciones de capital de varios fondos de inversión), lo que esta produciendo una evolución muy rápida de la herramienta. Se observa un gran potencial de futuro. El producto además se esta complementando con otras herramientas para Data Profiling y MDM.	Evolución mucho más lenta de la herramienta e incierta, pues Pentaho tiende a abandonar la parte Open.
Gran disponibilidad de componentes para conectarnos a múltiples sistemas y orígenes de datos, y en continua evolución.	Disponibilidad de componentes más limitada, aunque más que suficiente para la mayoría de procesos ETL o de integración de datos.
Aunque no disponemos de un repositorio en base de datos para trabajo en equipo (si en las versiones de pago), el trabajo con el Workspace nos da muchas posibilidades, al trabajar con el concepto de proyecto. Muy útil el análisis y actualización de dependencias cuando se modifican elementos (que son distribuidos a todos los Jobs de un proyecto).	El repositorio en base de datos nos da muchas posibilidades para el trabajo en equipo. En este repositorio se almacenan los xml que contienen las acciones que realizan sobre los datos las transformaciones y los Jobs.
Enfoque un componente por cada fabricante en los elementos para trabajar con bases de datos.	Enfoque un único componente por tipo de acción sobre la base de datos (y las características de la conexión utilizada son las que determinan su comportamiento).
Ayuda contextual en la aplicación. Completa ayuda online de los componentes. Cuando diseñamos nuestros propios controles en Java, tenemos la ayuda contextual del lenguaje proporcionada por Eclipse.	Ayuda muy pobre, casi inexistente en la aplicación. La ayuda online en la web de Pentaho no es especialmente completa, y en algunos componentes es muy reducida, de forma que la única forma de averiguar el funcionamiento del componente es probándolo.
Logs: podemos configurarlos a nivel de proyecto o en cada uno de los Jobs. Indicando si queremos sobrescribir la configuración del proyecto en ese aspecto. El log se puede enviar a base de datos, a consola o a ficheros. La funcionalidad esta muy desarrollada, distinguiendo logs de estadísticas, de métricas de procesos y de los logs propiamente dichos (para gestionar los errores).	Logs: diferentes niveles de logs (desde el más básico, hasta el nivel de cada registro). Suficiente para analizar las ejecuciones de las transformaciones y jobs. Posiblidad de registrar log en base de datos, aunque muy limitado. Los logs se configuran a nivel de transformaciones y Jobs.
Debug: con la perspectiva Debug de Eclipse, podemos seguir la traza de la ejecución (viendo el código fuente) tal y como si estuviéramos programando en Eclipse. También se puede incluir visualización de estadísticas y datos de traza o tiempos de respuesta en la ejecución de la herramienta gráfica.	Debug: contiene una sencilla herramienta de debug, muy básica.
Versionado de objetos: en el Workspace tenemos una completa gestión de versionado de Jobs (con minus y major number). Nos permite recuperar las versiones anteriores en caso de problemas. Dispone de una herramienta para modificación masiva de versiones de objetos (puede ser muy util para realizar el versionado de distribuciones).	El versionado de objetos esta previsto que se incluya en la versión 4.0.
Paralelismo: muy reducido en las versiones Open. Funcionalidad avanzada en las versiones de pago (Integration Suite).	Paralelismo: es muy sencillo realizar paralelismo de procesos con la opcion Distribute Data en la configuración del paso de información entre pasos, aunque habrá que llevar cuidado con las incosistentencias según el tipo de proceso.
Generación de documentación automática en HTML de los Jobs. Incluye visualización gráfica de los diseños, tablas de propiedades, documentación adicional o textos explicativos que hayamos introducido en los componentes, etc. Podéis ver un ejemplo aquí.	No se puede generar documentación de las transformaciones y Jobs. A nivel gráfico, podemos incluir notas con comentarios en el dibujo de los procesos. Con el proyecto kettle-cookbook se puede generar documentacion en html.
Herramienta sencilla para modelado gráfico. En ella podemos dibujar de forma conceptual los diseños de nuestras Jobs y procesos.
Generación continúa de nuevas versiones, que incorporan mejoras y arreglo de Bugs.	La generación de nuevas versiones no es muy frecuente, y tenemos que generarnos nosotros mismos las versiones actualizadas con los últimos fuentes disponibles: Ver entrada del Blog de Fabian Schladitz.
Talend Exchange: lugar donde la comunidad elaborar sus propios componentes y los comparte con el resto de usuarios.	Pentaho también dispone de colaboradores que desarrollan y liberan plugins en su web, aunque con menos actividad que Talend.
Como punto negativo, en ocasiones se nota en demasía la lentitud ocasionada por el uso de Java.	Como punto negativo, algunos componentes no se han comportando de la forma esperada, al realizar transformaciones muy complejas o al enlazar llamadas entre diferentes transformaciones a Jobs. Los problemas se pudieron superar cambiando el diseño de las transformaciones.
Es una ventaja tener un repositorio en local, donde nos guardamos en local la parte que nos interesa de la información de bases de datos, tablas, vistas, estructuras de ficheros (texto, Excel, xml). Al estar en el repositorio, se pueden reutilizar en los componentes asociados y no se tiene que volver a leer de los orígenes de datos su metadata cada vez que se usa (para el caso de las bases de datos, por ejemplo). Dispone de un asistente de construcción de querys (SQL Builder) muy potente y con muchas funcionalidades.	Cuando trabajamos con bases de datos con catálogos muy grandes, es incomodo tener que recuperarlo entero para poder construir, por ejemplo, una sentencia sql para leer de una tabla (cuando utilizamos la opción de navegación por el catalogo).
Reutilización de código: podemos incluir nuestras propias librerías, que son visibles en todos los Jobs de un proyecto. Esto nos permite de alguna manera diseñar nuestros propios componentes.	El código escrito en JavaScript dentro de los componentes no se puede reutilizar en otros componentes. Bastante limitado para añadir nuevas funcionalidades o modificar las existentes.
Control del flujo en los procesos: tenemos por un lado flujo  de datos (row, iterate o row lookup) y por otro lado disparadores para control de ejecución y orquestación de procesos. La combinación row e iterate es muy útil para orquestar procesos del tipo bucle, con el objetivo de repetir tareas. Hay un inconveniente importante que nos puede complicar el diseño de los jobs, y es que no se pueden juntar varios flujos de datos que provengan del mismo origen (han de tener un diferente punto de partida), nunca se han de cruzar en un elemento padre común.	Control del flujo en los procesos: se pasa la información entre componentes (pasos) con los saltos, de una forma única, y el flujo resultante varía según el tipo de control. Esta forma de interactuar tiene limitaciones para el control de procesos iterativos. Como característica interesante, la encapsulación de transformaciones a traves de los mappings, que nos permite definir transformaciones para procesos repetitivos (similar a una funcion).
Gestión de errores: cuando se producen errores, podemos gestionar el log, pero perdemos el control.	Gestión de errores: con la gestión de errores en los pasos que lo permiten, podemos interactuar con esos errores y solucionarlos sin terminar el proceso (no es siempre posible).
Ejecución: bien desde la herramienta (que a veces es muy lenta, sobre todo si incluimos estadísticas y trazas de ejecución). Para ejecutar a nivel de línea de comandos, se exportan los Jobs. La exportación genera todos los objetos (librerias jar) necesarias para poder ejecutar el trabajo, incluyendo un .bat o .sh para ejecutarlo. Esta forma de exportar los Jobs nos permite llevarlos a cualquier plataforma donde se pueda ejecutar el lenguaje java o perl, sin necesidad de tener instalado Talend.	Ejecución: bien desde la herramienta (tiempos de respuesta bastante buenos) o bien a nivel de comandos con Pan (para las transformacionse) y Kitchen( para los jobs). Son dos utilidades muy sencillas y funcionales que nos permiten ejecutar los xmls de los diseños (bien desde fichero o desde el repositorio). Siempre es necesario tener instalado PDI para poder ejecutar las herramientas. También disponemos de la herramienta Carte, que es un sencillo servidor web que permite la ejecución remota de jobs y transformaciones.

Comparativas e Información adicional.

Benchmark entre Pentaho Data Integration y Talend realizado por Matt Caster.	http://www.ibridge.be/?p=150. Opiniones sobre la prueba en el blog de Gobán Saor y Nicholas Goodman
Comparativa entre Kettle y Talend, realizada por Vicent McBurnety (año 2007)	http://it.toolbox.com/blogs/infosphere/wiki-wednesday-comparing-talend-and-pentaho-kettle-open-source-etl-tools-16294
Comparativa entre Kettle, Talend y CloverETL.	http://www.cloveretl.org/_upload/clover-etl/Comparison%20CloverETL%20vs%20Talend%20and%20Pentaho.pdf
Benchmark entre PDI, Talend, Datastage e Informatica	http://it.toolbox.com/blogs/infosphere/etl-benchmark-favours-datastage-and-talend-28695
Comparativa de funcionalidades y benchmark entre Talend y PDI	http://www.atolcd.com/fileadmin/Publications/Atol_CD_Livre_Blanc_ETL_Open_Source.pdf
Comparativa entre PDI e Informatica	http://www.jonathanlevin.co.uk/2008/03/pentaho-kettle-vs-informatica.html
Tabla comparada de características en la web Openmethodology.org	Talend vs PDI (Kettle).
Ejemplo sencillo comparado Kettle y Talend	http://forums.pentaho.org/showthread.php?t=57305
Comparativa de herramientas ETL realizada por la empresa Adeptia.	http://www.adeptia.com/products/etl_vendor_comparison.html
Pentaho Kettle Open Source Review	http://www.datawg.com/pentaho-kettle-open-source-etl-tool-review.html
Benchmark entre Pentaho Data Integration y Talend realizado por Marc Russel.	http://marcrussel.files.wordpress.com/2007/08/benchmark-tos-vs-kettle.pdf
Comparativa entre Datastage, Talend, Informatica y PDI (Manapps).	http://marcrussel.files.wordpress.com/2009/02/etlbenchmarks_manapps_090127.pdf
Presentación PowerPoint comparativa Kettle vs Talend	http://svn2.assembla.com/svn/bbdd_dd/Presentaciones/Kettle%20Vs%20Talend.pptx
EOS: Open Source Directory.	http://www.eosdirectory.com/project/397/Talend+Open+Studio.html vs http://www.eosdirectory.com/project/202/KETTLE++pentaho+data+integration+.html

Conclusiones.

Desde mi punta de vista, creo que ambas herramientas son complementarias. Cada una con un enfoque, pero permiten realizar las mismas tareas de transformación e integración de datos. El producto Talend tiene para mi mas recorrido, pues se estan poniendo muchos recursos en su desarrollo, y se esta complementando con otras herramientas para crear una verdadera suite de integración de datos. También se utiliza en el proyecto de Jaspersoft. Igualmente, el hecho de ser mas abierto y poder ser complementado con el uso del lenguaje Java también le da ciertas ventajas con respecto a Pentaho.
Por otro lado, Pentaho Data Integration es una herramienta muy intuitiva y facil de utilizar. Se nota desde el principio cuando se empieza a usar, como ya mencione, que esta desarrollada bajo el prisma de las problematicas de procesos ETL y transformación de datos. En algunas aspectos se le ve más rápida y ágil que Talend, al no tener que estar moviendo generación de código Java en todo momento. Aunque si se echa de menos la gestión de un repositorio de proyectos verdaderamente integrado, como en Talend, y con un metadatos independiente de los origenes/destinos de datos.
A nivel de rendimiento, y revisando las diferentes comparativas, tampoco se ve un claro ganador. Una herramienta es mas rapida en algunas cosas (Talend en calculo de agregaciones o Lookups), mientras Pentaho es mas rápido, por ejemplo en el tratamiento de SCD o con los procesos de paralelización. En mis procesos ETL tampoco ha habido unas grandes diferencias de rendimiento, aunque si me ha parecido ligeramente más ágil Pentaho a la hora de realizar los procesos masivos.
Teniendo en cuenta todo lo visto (y todo lo detallado en los puntos anteriores), yo me decanto ligeramente a favor de Talend, aunque antes de elegir una herramienta para un proyecto, yo realizaría un estudio profundo del tipo de trabajos y casuisticas a las que nos vamos a enfrentar en el diseño de nuestros procesos antes de decantarme por una u otra herramienta. Seguramente habrá factores especificos que pueden recomendar el uso de una u otra (como la necesidad de conectarnos a determinada aplicación o las plataformas donde ejecutar los procesos). Y lo que esta claro en ambos casos, es que cualquiera de las dos nos podría valer para los procesos de construcción de un DW en un entorno real (como he demostrado en este blog con toda la serie de ejemplos publicados).
Si habeis trabajado con alguna de las herramientas, o ambas, quizas tengais algo que añadir a esta comparativa. Espero vuestras opiniones.

Actualización 18.06.10

Os dejo el link al ultimo estudio de Gartner sobre Integración de Datos, publicado en noviembre de 2009:
Magic Quadrant for Data Integration Tools.
En el ultimo estudio se ha incluido a Talend como un proveedor emergente de herramientas de Integración de Datos. Si estáis pensando en trabajar con Talend, se dicen cosas interesantes (tanto Pro´s como contras) sobre la evolución del producto y su futuro:
Puntos Fuertes:

• Dos niveles: nivel de entrada con herramienta Open Source gratuita (Talend Open Studio) y nivel superior con herramienta de pago con mas funcionalidades y soporte (Talend Integration Suite).
• Talend esta consiguiendo casi por unanimidad resultados positivos en las empresas. Aunque el factor determinante inicial puede ser su precio, sus características y funcionalidades son el segundo factor determinante de su exito.
• Buena conectividad en general. Complementada con las herramientas de Data Profiling y Data Quality. El paso de las versiones Open a las de pago no requiere curva de aprendizaje adicional.

Precauciones:

• Hay escasez de expertos en la herramienta, aunque se esta desarrollando una red de alianzas con otras empresas y desarrollando su red comercial (aunque no estan en todas las regiones).
• Existen algunos problemas en las herramientas de pago con el repositorio central (que no esta en la versión  Open), cuando se trabaja para coordinar trabajos de desarrollo. Parece que lo estan intentando solucionar en las nuevas versiones.
• Algunos clientes han reportado que la documentación es errónea y algún problema en la gestión de los metadatos. Igualmente, es necesario disponer de un experto en Java o Perl para sacarle todo el partido a la herramienta (como indicamos en la comparativo con Pentaho).

Os recomiendo la lectura del informe, se dicen cosas muy interesantes en general sobre las herramientas de integración de datos y en particular si estais buscando información de alguna en concreto (como es Talend, el objeto de esta comparativa de productos).

Compartelo:

• Share
• 
  

Publicado en ETL, Kettle, Pentaho, Talend | 8 Comentarios »

ETL´s: Talend Open Studio vs Pentaho Data Integration (Kettle). Comparative.

Posted by Roberto Espinosa en 1 junio 2010

(Read in Spanish language here)

Let’s try in this latest entry of the ETL processes series to make a comparison as complete as possible of Tools Talend Open Studio and Pentaho Data Integration (Kettle), which we have been using in last months. For this study to be as comprehensive and rigorous as possible, we will divide the task in 5 sections:

Using Talend Open Studio in ETL Process Design

• Property table.
• Examples of Use
• Strengths / weaknesses table.
• Resource Links (comparative and additional information.)
• Final opinion.

Property table.

Product	TALEND OPEN STUDIO ver.4.0	PENTAHO DATA INTEGRACION CE (KETTLE) ver 3.2
Manufacturer	Talend – France	Pentaho – United States
Web	www.talend.com	www.pentaho.com
License	GNU Lesser General Public License Version 2.1 (LGPLv2.1)	GNU Lesser General Public License Version 2.1 (LGPLv2.1
Development Language	Java	Java
Release Year	2006	2000
GUI	Graphical tool based on Eclipse	Design Tool (Spoon) based on SWT
Runtime Environment	From design tool, or command line with Java or Perl language (independent of the tool)	From design tool, or command line with utilities  Pan and Kitchen .
Features	With the design tool build the Jobs, using the set of components available.Work with project concept, which is a container of different Jobs with metadata and contexts. Talend is a code generator, so Jobs are translated into corresponding defined language (Java or Perl can choose when create a new project), compiled and executed .Components bind to each other with different types of connections.  One is to pass information (which may be of Row or Iterate, as how to move the data).  Also, you can connect with each other triggering connections (Run If, If Component Ok, If Component Error) that allow us to articulate the sequence of execution and ending time control.Jobs are exported at SO, and can run independently of the design tool on any platform that allows the execution of the selected language.  In addition, all generated code is visible and modifiable (although you modify the tool to make any changes to the Jobs).	With the design tool built Spoon transformations (minimum design level) using the steps. At a higher level we have the Jobs that let you run the transformations and other components, and orchestrate process. PDI is not a code generator, is a transformation engine, where data and its transformations are separated.The transformations and Jobs are stored in XML format, which specifies the actions to take in data processing. In transformations use steps, which are linked to each other by jumps, which determine the flow of data between different components. For the jobs, we have another set of steps, which can perform different actions (or run transformations). The jumps in this case determine the execution order or conditional execution.
Components	Talend has a large number of components. The approach is to have a separate component as the action to take, and access to databases or other systems, there are different components according to the database engine that we will attack. For example, we have an input table component for each manufacturer (Oracle, MySQL, Informix, Ingres), or one for the SCD management  for each RDBMS. You can see available components list here.	Smallest components set, but very much oriented towards data integration. For similar actions (eg reading database tables), a single step (no one from each manufacturer), and behavior according to the database defined by the connection. You can see available elements for transformations here and for jobs here.
Platform	Windows, Unix and Linux.	Windows, Unix and Linux.
Repository	Works with the workspace concept, at filesystem level.  In this place you store all the components of a project (all Jobs, metadata definitions, custom code and contexts). The repository is updated with the dependencies of changend objects (expand to all project changes.) If we change the table definition in repository, for example, is updated in all the Jobs where it is used.	The Jobs and transformations are stored in XML format. We can choose to store at  file system level or in the database repository (for teamwork). Dependencies are not updated if you change a transformation who is called from another. If the level of components within a single transformation or job.
Metadata	Full metadata that includes links to databases and the objects (tables, views, querys).  Metadata info is centrally stored in workspace and its not necesary to read again from source or destination system, which streamlines the process. In addition, we can define metadata file structures (delimited, positional, Excel, xml, etc), which can then be reused in any component.	The metadata is limited to database connections, which metadata can be shared by different transformations and  jobs.Database information (catalog tables / fields) or files specifications (structure) is stored in steps and can not be reused. This info is read in design time.
Contexts	Set of variables that are configured in the project and that can be used later in the Jobs for your behavior (for example to define productive and development environment).	Using Variables in tool parameters file (file kettle.properties). Passing parameters and arguments to the process (similar to the contexts), both in jobs and transformations.
Versions	It allows us to perform a complete management of objects versions (can recover previous versions)	Functionality provided in version 4.0.
Languages to define their own components (scripting)	Talend allows us to introduce our custom code using Java and Groovy.Additional custom SQL and Shell.	JavaScript used for the calculations and formulas.Aditional custom SQL, Java, Shell and open office formulas.
Additional tools	Talend offers additional tools for Data Profiling and Master Data Management (MDM). Open Studio have too a simple modeling tool to draw logical processes and models.	PDI 4.0 offers Agile functionality  for dimensional modeling and models publication in Pentaho BI.
Plugins	Download new components through Talend Exchange .	Incorporation of additional plugins in the web .
Support	An complete online community with Talend’s wiki , Talend Forum and bugtracker for the management of incidents and Bugs.	Includes forum Pentaho , Issue Tracking and Pentaho Community .
Documentation	Complete documentation in pdf format that includes: Installation, User Manual and Documentation of components.	Online Documentation  on the web. Books: Data Integration-Pentaho 3.2 Beginner’s Guide(M.C.Roldan), Pentaho Kettle Solutions (M.Casters, R.Bouman, J.van Dongen).

Examples of Use (in Spanish)

EXAMPLE	TALEND OPEN STUDIO	PENTAHO DATA INTEGRATION (KETTLE)
Charging time dimension of a DW	ETL process to load the time dimension. Example use of the ETL Talend.	Time Dimension ETL with PDI.
Implementation of dynamic sql statements	More examples of Talend. Execution of SQL statements constructed in execution time.	Passing parameters and dynamic operations in a transformation of PDI.
Loading a product dimension DW	Product Dimension ETL load. More examples of Talend. Using logs, metrics and statistics.	Product Dimension ETL with PDI (I).Extraccion to Stage Area. ETL Product Dimension with PDI (II). Loading to DW.
Charging a customer dimension DW	Talend ETL Mapping Types. Customer Dimension ETL.	Customer Dimension ETL with PDI.
Treatment of slowly changing dimensions	Management of SCD (slowly changing dimensions.)	Treatment Slowly Changing Dimensions (SCD) with PDI.
Connecting to ERP Sap	Connecting to Sap with Talend	Connecting to Sap with Kettle (plugin ProERPConn)
Charging sales fact tables in a DW	Sales Facts table. Talend contexts.	Loading ETL sales made with PDI. ETL load PDI budgeting facts.
Exporting Jobs and planning processes	Export Talend.Planification jobs in ETL processes.
Treatment of public data	Data Model and Process Load DW London’s public data.
Understanding the user interface		Building ETL processes using Kettle (Pentaho Data Integration)
Graduation Project (comparative Pentaho / JasperETL). Developed by Rodrigo Almeida, Mariano Heredia.	Thesis which details a Business Intelligence project using the tools of Pentaho and Jasper.  In the ETL’s, compared Kettle with JasperETL  (based on Talend).	Download the book on the web: http://sites.google.com/site/magm33332/bifloss. It includes a magnificent detail of the features of each tool.

As further examples, you can also consult:

• Tutorial Talend Open Studio 4 by Victor Javier Madrid on the web adictosaltrabajo.com. Includes another example to process an EDI file with Talend.
• White Paper on Open Source ETL tools conducted in French by Atol. It includes a series of practical examples very complete.

Using Pentaho Data Integration (Kettle) in ETL Process Design

Table of strengths / weaknesses.

From my point of view, with the user experience of the two tools and the information collected about tools and others user experience, I can highlight the following aspects:

TALEND OPEN STUDIO	PENTAHO DATA INTEGRATION (KETTLE)
It is a code generator and this issue implies a heavy dependence of the project chosen language (Java in my case). By choosing java, we have all the advantages and disadvantages of this language. You need a high level of this language to get the most out of the application.	It is a transformation engine, and notes from the outset has been designed by people who needed to meet their needs in data integration, with great experience in this field. It is also easier to manage the datatypes with PDI, it is not as rigorous as Java.
Tool unintuitive and difficult to understand, but once you overcome this initial difficulty, we observe the very great potential and power of the application.	Very intuitive tool,  with some basic concepts can make it works. Conceptually very simple and powerful.
Unified user interface across all components. Based on Eclipse, the knowledge of the tool enables us to use the interface.	The design of the interface can be a bit poor and there is no unified interface for all components, being sometimes confusing.
Talend is investing significant resources in its development (through capital injections from various funds), which is producing a very rapid development of the tool. With a great potential, the product also is being supplemented with other tools for MDM and Data Profiling.	Much slower tool evolution and uncertain because Pentaho tends to leave the OpenSource focus.
Greater availability of components to connect to multiple systems and data sources, and constantly evolving.	Limited availability of components, but more than enough for most ETL or data integration process.
There is not a database repository (only in paid versions),but work with Workspace and the project concept gives us many opportunities. Very useful dependency analysis and update when elements are modified (which is distributed to all the Jobs of a project).	Database repository gives us many opportunities for teamwork. In this repository is stored xml, containing the actions that Transformations and Jobs take on the data.
A separated component by each database vendor.	A single component by database action type (and the characteristics of the connection used are those that determine their behavior).
Help shortcut in the application. Comprehensive online help components. When we designed our own code in Java, we have the context assistance of language  provided by Eclipse.	Help poor, almost nonexistent in the application.  The online help in the Pentaho website is not particularly full, and in some parts is very small, so that the only way to determine the functioning of the component is test it.
Logs: We can configure at project level or in each Job, indicating if we want to overwrite the configuration of the project in this regard.  Log can be sent to database,  console or file.  The functionality is very developed, distinguishing logs of statistics, metrics and process logs (to handle errors).	Logs: different logs levels (from the most basic to the row detail in data flow). Sufficient to analyze the execution of the transformations and jobs. Possibility of record logs in database, but very limited. Log configuration is set at the level of transformations and Jobs.
Debug: Debug perspective in Eclipse, we can keep track of implementation (see the source code) as if we were programming in Eclipse.  You can also include statistics and data display trace or response times in the execution of jobs using the graphical tool.	Debug: Contains a simple debug tool, very basic.
Versioning of objects: in the Workspace we can manage a complete versioning of the Jobs (with minus and major number). It enables us to recover earlier versions if problems occur.  It has a massive tool to change versions of lots of objects (can be very useful for versioning of distributions).	Object versioning is scheduled to be included in version 4.0.
Parallelism: very small in Open version. Advanced functionality in paid versions (Integration Suite).	Parallelism: parallelism is very easy to make,using the Distribute Data option in the configuration of the information exchange between steps, but will have to take care with not consistent, depending type of process.
Automatic generation of HTML jobs documentation. Includes graphical display of the designs, tables of properties, additional documentation or explanatory texts that we have introduced in the components, etc.  You can see an example here .	Unable to generate documentation of changes and Jobs. Using the graphics tool, we can include notes with comments on the drawing process. With project kettle-cookbook you can generate html documentation.
Simple tool for modeling chart. With it  we can conceptually draw our Jobs designs and processes.
Continuous generation of new versions, incorporating improvements and bug fixes.	The generation of new versions is not very common and we need to generate versions ourseles updated with the latest available sources: see blog entry of Fabin Schladitz .
Talend Exchange : place where the community develop their own components and share them with other users.	Pentaho also offers fans who develop and release plugins on their website , with less activity than Talend.
As a negative point, sometimes excessively slow caused by the use of Java language.	As a downside, some components are not behaving as expected, to perform complex transformations or by linking calls between different transformations in Jobs. The problems could be overcome by changing the design of transformations.
It is an advantage to have a local repository where we store locally  information about database, tables, views, structures, files (text, Excel, xml). Being in the repository can be reused and associated components not need to re-read of the  data source metadata every time (for the case of databases, for example).  It has a query assistant (SQL Builder) with many powerful features.	When working with databases with very large catalogs, it is inconvenient to have to recover the entire building, for example, a sql statement to read from a table (when we use the option of browsing the catalog).
Code reuse: we can include our own libraries, which are visible in all Jobs in a project.  This allows us a way to design our own components.	JavaScript code written in the step components can not be reused in other components. Fairly limited to adding new functionality or modify existing ones.
Control of flow processes: on the one hand we have the data flow (row, iterate or lookup) and on the other triggers for control execution and orchestration of processes. The row and iterate combination is useful to orchestrate the  loop process, with the aim of repetitive process.  There is a major inconvenience we may complicate the process: you can not collect several data streams coming from the same origin (must have a different point of departure).	Flow control processes: passing information between components (steps) with jumps, in a unique manner, and the resulting flow varies with the type of control used.  This approach has limitations with the control of iterative processes.  As an interesting feature, encapsulation of transformations through the mappings, which allows us to define transformations for repetitive processes (similar to a function in a programming language).
Handling errors: when errors occur, we can manage the log, but we lose control. We cant reprocess rows.	Error management: errors management in the steps allow us to interact with those mistakes and fix them without completing the process (not always possible, only in some steps).
Execution: either from the tool (which is sometimes very slow, especially if you include statistics and execution traces). To run at command line level, is necesary to export Jobs. The export generates all objects (jar libraries) necessary to perform the job, including a .bat or .sh file to execute it. This way allow us to execute the job in any platform where you can run java or perl language, without needing to install Talend.	Execution: either from the tool (pretty good response times) or at command level with Pan (for transformations) and Kitchen(for jobs) . They are two very simple and functional utilities that allow us to execute XMLs  specifications of jobs or transformations (either from file or from the repository). It is always necessary to run the process have installed the PDI tool. We have also Carte tool, a simple web server that allows you to execute transformations and jobs remotely.

Comparatives and additional information.

Benchmark between Talend and Pentaho Data Integration by Matt Caster.	http://www.ibridge.be/?p=150. Reviews about in Goban Saor and Nicholas Goodman blogs.
Comparison between Kettle and Talend, by Vicent McBurnety (2007)	http://it.toolbox.com/blogs/infosphere/wiki-wednesday-comparing-talend-and-pentaho-kettle-open-source-etl-tools-16294
Comparison between Kettle, Talend and CloverETL.	http://www.cloveretl.org/_upload/clover-etl/Comparison% 20CloverETL 20vs%%%% 20and 20Talend 20Pentaho.pdf
Benchmark between PDI, Talend, Datastage e Informatica	http://it.toolbox.com/blogs/infosphere/etl-benchmark-favours-datastage-and-talend-28695
Compare features and benchmark between Talend and PDI	http://www.atolcd.com/fileadmin/Publications/Atol_CD_Livre_Blanc_ETL_Open_Source.pdf
Comparison between PDI and Informatica	http://www.jonathanlevin.co.uk/2008/03/pentaho-kettle-vs-informatica.html
Comparative table of features on the web Openmethodology.org	Talend vs PDI (Kettle).
Simple example comparing Kettle and Talend	http://forums.pentaho.org/showthread.php?t=57305
Comparison of ETL tools Adepti made by Adeptia company.	http://www.adeptia.com/products/etl_vendor_comparison.html
Pentaho Kettle Open Source Review	http://www.datawg.com/pentaho-kettle-open-source-etl-tool-review.html
Benchmark between Talend and Pentaho Data Integration by Marc Russel.	http://marcrussel.files.wordpress.com/2007/08/benchmark-tos-vs-kettle.pdf
Comparison between Datastage, Talend, Informatica and PDI (Manapps).	http://marcrussel.files.wordpress.com/2009/02/etlbenchmarks_manapps_090127.pdf
PowerPoint Presentation comparative Talend vs. Kettle	http://svn2.assembla.com/svn/bbdd_dd/Presentaciones/Kettle%
EOS: Open Source Directory. EOS: Open Source Directory.	http://www.eosdirectory.com/project/397/Talend+Open+Studio.html vs http://www.eosdirectory.com/project/202/KETTLE++pentaho+data+integration+.html

Summary (final opinion).

From my point of view, I think both tools are complementary. Each one with a focus, but allow the same tasks of transformation and data integration. The product Talend has more future, since they are putting many resources in its development, and is being supplemented with other tools to create a true data integration suite. Also used in the  Jaspersoft project, the fact of being more open and can be complemented with the use of Java gives certain advantages over Pentaho.
By the other hand, Pentaho Data Integration is a very intuitive and easy to use. You can see from the beginning when you start to use, as I mentioned, which is developed through the prism of the problems of ETL processes and data transformation. In some aspects it is faster and more agile than Talend, not having to be moving Java code generation all the time. We misses the management of a truly integrated project repository, such as Talend, and an independent metadata of source/target systems.
A level of performance, and reviewing the different comparations and benchmarks, not see a clear winner. A tool is faster in some things (Talend in calculating  additions or Lookups), while Pentaho is faster, for example in the treatment of SCD or the parallelization process. In my ETL processes there have been no large differences in performance, although I found slightly more agile Pentaho when performing mass processes.
Taking into account all seen (and everything detailed in the above), I opted for Talend slightly, but before choosing a tool for a project, I conduct a thorough study of the type of work and casuistic to which we will face in the design of our processes before opting for one or other tool. You may have specific factors that may recommend the use of one or another (such as the need to connect to a particular application or platform in which to run the process). What is clear in both cases, is that either we could hold for the processes of construction of a DW in a real environment (as I have shown in this blog with the whole series of published examples.)
If you have worked with some of the tools, or both, maybe have to add something to this comparison. I hope your opinions.

Updated 18/06/10

I leave the link to the last Gartner study about Data Integration Tools, published in November 2009:
Magic Quadrant for Data Integration Tools.
In the latter study was included Talend  as a emerging provider of data integration tools. If you are considering working with Talend, they say interesting things (both Strengths and Cautions) on the evolution of the product and its future:
Strong Points:

• Two levels: entry-level Open Source tool free (Talend Open Studio) and higher with a payment tool with more features and support (Talend Integration Suite).
• Talend is getting almost unanimously positive results in business. Although the initial factor may be its price, its features and functionality are the second factor in its success.
• Good connectivity in general. Complemented with the tools of Data Profiling and Data Quality. The passage of the versions to pay Open requires no extra learning curve.

Precautions:

• There is a shortage of experts in the tool, although it is developing a network of alliances with other companies and develop its commercial network (although they are not in all regions).
• There are some problems with the central repository (which is not in the Open version), when working to coordinate development works. Looks like they are trying to solve in the new versions.
• Some customers have reported that the documentation is wrong and some problems in  metadata management. It is also necessary to have an expert in Java or Perl to take full advantage of the tool (such as indicated in comparison with Pentaho).

I recommend reading the report, there is a lot of information about data integration tools and particularly if you are looking for information on any individual (such as Talend, the purpose of this comparative product).

Compartelo:

• Share
• 
  

Publicado en ETL, Kettle, Pentaho, Talend | 18 Comentarios »

16.3.5. ETL Carga de hechos de presupuestos con PDI.

Posted by Roberto Espinosa en 30 mayo 2010

En esta ultima entrada de la serie construiremos el proceso ETL para la carga de la tabla de hechos de presupuestos. Vamos a simular que los datos no están en el ERP, sino en unas hojas excel de usuario, que ademas van a tener una estructura un tanto peculiar para introducir el uso de otros pasos de Kettle. Las tablas de hechos a llenar son las siguientes:

Para llenar estas tablas, disponemos de unos ficheros en formato Excel (uno para cada año de presupuesto). Por ejemplo, para la carga de la Previsión de Ventas por Tipo Cliente, el fichero se llamara tipoclienteYYYY.xls, donde YYYY será el año de presupuesto que incluye el fichero. Vamos a dividir el job en tres etapas, que realizaran las siguientes acciones:

• Pre proceso de carga: leemos los ficheros (para uno o varios años), depositados en un directorio. Para cada fichero, recuperamos de su nombre el año y borramos de la tabla de hechos los registros existentes en ese periodo.
• Proceso ETL: leemos el contenido de cada fichero, hacemos el tratamiento de la casuistica de su estructura, y denormalizamos, dejando al final una estructura como la de la tabla, realizando los procesos de inserción en la base de datos.
• Post proceso: movemos todos los ficheros tratados a un directorio de procesados (para que no se vuelvan a tratar).

Teniendo en cuenta todo esto, tendremos el siguiente diseño de job:

Job carga presupuestos

Vamos a ver en detalle cada una de las transformaciones, pues hemos incluidos elementos nuevos no vistos hasta ahora y que os pueden resultar interesantes:

Transformación para borrado de datos anteriores.

En esta transformación hemos incluido el uso del paso Get File Names (categoría Input). Con este control podemos recuperar una lista de ficheros, para poder realizar posteriormente un tratamiento sobre ellos (pues recuperamos su nombre, directorio y características). Ademas, el control nos permite utilizar expresiones regulares para determinar que regla han de cumplir los nombres de los ficheros.

Configuracion del Get File Names

A partir de cada nombre de fichero, obtenemos mediante una formula el año, y realizamos el borrado de los registros de ese año, utilizando el paso Delete y enviando información al log (como vimos en los ejemplos anteriores). El diseño de la transformación teniendo en cuenta todo lo visto, sería el siguiente:Transformacion para procesado de fichero, transformación y carga.

Esta transformación es la principal de este Job, y antes de verla en detalle, vamos a hacer algunas consideraciones sobre la estructura del fichero que vamos a procesar, pues ello va a determinar que problemática vamos a tener que abordar para su procesamiento.

Estructura Hoja Excel

Como vemos, tenemos dos lineas en la hoja excel para cada tupla mes/tipo cliente. Además, el mes y el tipo de cliente solo se indican en la primera linea de cada grupo. Esto nos va a obligar a procesar cada linea del fichero por un lado para que todos los registros tengan valor en el mes y tipo de cliente, y por otro lado, tendremos que desnormalizar el contenido del fichero, para generar un único registro por mes y tipo de cliente (en lugar de los 2 que llegan en el fichero). Vamos a ver en detalle cada uno de los pasos de la transformación y la manera en que hemos solucionado la problemática descrita:

• Excel Input: es un paso de la categoría Input que nos permite recuperar el contenido de una o varias hojas excel (o de sus libros), y pasar su contenido al flujo de datos de las transformaciones. Ademas, igual que en el Text File Input que ya vimos, podemos utilizar expresiones regulares para indicar los patrones que han de seguir los nombres de los ficheros que queremos recuperar.

Configuración del Excel Input

• Proceso Campos Blanco: como hemos visto antes, esta casuística es un tanto especial y para tratarla, no nos queda mas remedio que utilizar código Javascript utilizando el control Modified Java Script Value. Con una pocas lineas de código solucionamos el problema, tal y como podeís ver. Hemos utilizado una variable auxiliar, que llenamos en la primera linea ( sentencia getProcessCount(‘r’) == 1 ), y luego la vamos llenando conforme nos llegan las siguientes lineas. Si el campo esta en blanco, utilizamos el valor de la variable auxiliar (en caso contrario, nos guardamos en la variable el valor). Asi evitamos dejar los campos en blanco:

//Script here

var mes_aux;
if (getProcessCount('r') == 1) mes_aux = Mes;
if (Mes == null)
mes_aux = mes_aux;
else
mes_aux = Mes;

var tipo_aux;
if (getProcessCount('r') == 1) tipo_aux = Tipo_Cliente;
if (Tipo_Cliente == null)
tipo_aux = tipo_aux;
else
tipo_aux = Tipo_Cliente;

• Denormalizo Registros: el otro problema de nuestro ejemplo es que tenemos dos lineas para cada mes y tipo de cliente. Para juntarlas, PDI nos ofrece un paso para el tratamiento de este tipo de casuisticas (Row De-normaliser). Para poder utilizarlo, es necesario que los registros se pasen ordenados por las claves de grupos, pues en caso contrario no funciona correctamente. Podeis ver en la imagen como se configura el paso y la explicación de cada una de las secciones.

Configuracion del step Denormaliser

En el caso de querer generar varios registros a partir de uno único, utilizaremos el step Row Normaliser, definido en PDI para ese tipo de cometidos. Para entender mejor el ejemplo, podemos ver como queda el flujo de datos despues de pasar por el step. De cada dos lineas de la hoja excel, hemos pasado a una unica linea, y han aparecido dos nuevas columnas (VENTAS_PREV Y MARGEN_PREV), que antes teniamos en el campo Valor en cada una de las líneas:

Datos tras utilizar el Denormaliser

• Preparo Campos e Inserto DW: una vez tenemos desnormalizados los registros, ya solo nos queda preparar los campos que queremos mandar al Table Output, utilizando para el ello el Select Values que tanto hemos utilizando en nuestros anteriores ejemplos.

La estructura completa de la transformación sería esta:Transformación para mover ficheros.

Para terminar, volvemos a recorrer la lista de ficheros, construimos el nombre del fichero destino con una Formula, y lo movemos utilizando el step Process files (categoría Utility). De esta forma, movemos todos los ficheros que hemos tratado a otro directorio donde ya no se tendrán en cuenta. El diseño de la transformación será el siguiente:Con el paso Process files podemos básicamente realizar tres tipos de acciones sobre los ficheros: Mover, Copiar o Borrar. Para las dos primeras acciones, será necesario indicar el nombre de fichero origen, y el destino, que determinara igualmente el directorio o carpeta destino. Ademas, tenemos disponibles otros flags para crear el directorio destino en el caso que no exista, sobrescribir el fichero destino o la posibilidad de utilizar el control en modo test.

Configuracion del Process Files

Os dejo el link a todos los ficheros utilizados en el ejemplo aquí.
Job final para la ejecución de todos los procesos de carga de nuestro DW.
Para terminar, podriamos haber construido un job que realizara la ejecución de forma secuencial de todos los jobs definidos hasta ahora. Con su lanzamiento realizariamos la actualización periódica y completa de nuestro DW. El fichero del job lo ejecutaremos utilizando la herramienta Kitchen y lo planificaremos en nuestro sistema con la cadencia deseada para su automatización (utilizando cron o at, según estemos en Unix/Linux o Windows, o bien utilizando cualquier otra herramienta que nos permita planificar la ejecución de procesos).
Conclusiones.
Hemos terminado el diseño de los procesos de carga de nuestro DW. En este ultimo ejemplo hemos visto la forma de tratar uno o multiples ficheros, y que pasos tiene PDI para desnormalizar (o normalizar) el contenido de estos. Ahora toca hacer un poco reflexión y recopilación, y resumir todo lo visto hasta ahora sobre Talend Open Studio y Pentaho Data Integration para preparar la comparativa. Hemos intentado construir ejemplos completos y complejos para intentar sacar todo el partido a la herramienta, a la vez que hemos ofrecido ideas y técnicas para diseñar los procesos de carga de un DW. Todo lo visto es simulado y corresponde a un entorno figurado, pero que hemos intentado que se acerque lo más posible a las problemáticas reales que nos podemos encontrar en cualquier organización