Pentaho report designer: una solución para crear informes a partir de mongodb

Pentaho Report Designer(PRD) es una herramienta de reporting fácil de utilizar y con multitud de aplicaciones. Los informes que genera se dividen 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.

Pentaho Report Designer nos permite trabajar con múltiples orígenes de datos. (JDBC, Olap4J, Pentaho Analysis, Pentaho Data Integration, XML) incluido el metadata que tengamos definido en nuestro sistema. En particular y para este ejemplo vamos a utilizar una colección de MongoDB. El resultado de los informes que hemos 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.

Para realizar un informe necesitamos:

  • MongoDB: Necesitaremos que esté arrancada la base de datos y saber la dirección y el puerto.
  • Kettle: Una versión para usuario conocida como Spoon desde donde descargaremos la información de MongoDB.
  • Pentaho Report Designer: la herramienta para crear informes que vamos a mostrar en este post.

Primer paso: Generar una transformación en Kettle de una colección de MongoDB

En la entrada Cómo generar una transformación en Kettle de una colección de MongoDB hemos visto como crear un fichero de extensión .ktr desde el que enlazaremos la información recuperada de Mongo DB con nuestro informe.

Segundo paso: Generar un informe simple con PRD

Arrancamos la herramienta y seleccionamos Report Wizard, una versión más sencilla que luego se puede adaptar a nuestras necesidades y gustos.

Seguimos el asistente y seleccionamos el fichero .ktr que hemos generado con Spoon. Debemos indicar el último paso del proceso, en otro caso, no utilizaremos toda la información que hemos procesado. Informamos los campos que se van a utilizar en el report y elegimos el formato y el estilo con el que se van a mostrar.

Siguiendo el resto de los pasos se creará una plantilla que podremos editar a nuestro gusto y conveniencia. Además, tenemos muchas posibilidades para tratamiento de la información y su visualización.

Si pulsamos en el icono de previsualización podemos hacernos una idea de la forma que va adquiriendo nuestro informe. Incluimos un pie chart al final del informe que muestre la proporción de distintas calificaciones por provincia.

Tercer paso: Añadir un parámetro al informe

Necesitaremos un fichero XML con los distintos valores que puede adquirir el parámetro. Se puede realizar también desde Kettle (ver cómo).

Desde el menú lateral de la derecha en Data, seleccionamos el fichero XML. En este ejemplo utilizaremos este:

Incluimos la query /Rows/Row para seleccionar todos los valores del parámetro.

En el mismo menú lateral, pulsamos le icono para enlazar el parámetro con el fichero XML.

Enlazamos ahora el parámetro con el informe, seleccionando en nuestro Data Set la opción de editar parámetro.

Con este último paso tenemos terminado nuestro informe parametrizado. Podemos guardar el resultado en diferentes formatos como PDF, HTML, XLS, RTF y CSV.

Sulfato1 sulfato2

Para más información:

Pentaho:Create a Parameterized Report with MongoDB

Pentaho report designer: una solución para crear informes a partir de mongodb

Cómo generar una transformación en Kettle de una colección de MongoDB

Kettle, ahora conocido como PDI (Pentaho Data Integration) tiene una interfaz intuitiva y gráfica, de arrastrar y soltar. Por su facilidad de manejo para usuarios menos técnicos y una arquitectura probada, escalable y basada en estándares, es cada vez más una gran opción para las empresas de ETL tradicional que buscan herramientas de integración de datos.

A continuación vamos a crear una transformación a partir de una colección de datos de Mongo DB. Para ello vamos a utilizar:

  • MongoDB: Necesitaremos que esté arrancada la base de datos y saber la dirección y el puerto.
  • Kettle: Una versión para usuario conocida como Spoon desde donde descargaremos la información de MongoDB.

1. Insertamos una nueva transformación y arrastramos del menú lateral de Diseño la herramienta MongoDb Input

Pinchando dos veces en ella accedemos a las opciones de MongodB. Necesitaremos tener arrancada la base de datos y conocer la colección, el puerto y la dirección.

En nuestro ejemplo hemos incluido una query en formato json para la extracción de datos que está parametrizada por Provincia. Este parámetro lo utilizaremos en el informe para filtrar la información.

2. Definimos el parámetro de la transformación en ‘Editar’->’Configuración’ e indicamos el valor por defecto:

3. Editamos la información la herramienta Json Input  

Informamos los campos que queremos recuperar para realizar el informe indicando el formato y el nombre.

Unimos los dos iconos y podemos previsualizar el contenido

Con esta transformación sería suficiente para generar el informe. No obstante, realizaremos tres pasos más para conseguir más información de valor.

4. Utilizamos la calculadora   para definir los campos Año, Mes y Día, a partir de la Fecha

5. Realizamos el promedio del campo Resultado con la herramienta agrupar por , que para utilizarla deberemos haber ordenado previamente por la clave.

Ejecutamos la transformación y la guardamos.

Hemos realizado un breve incursión por algunas de las herramientas de Kettle, pero podríamos realizar cálculos más complejos porque ofrece son muchísimas posibilidades.

Para más información:

Spoon User Guide: Transformation Steps

Pentaho:Create a Parameterized Report with MongoDB

Cómo generar una transformación en Kettle de una colección de MongoDB

Sofia2 y Google App Inventor: Introducción.

En Sofia2, queremos acercar la plataforma a todo el mundo, desde programadores experimentados hasta personas con un perfil no técnico. Todos los días nos escribe gente con ideas realmente buenas que implementar en nuestra plataforma, pero a veces no tienen los conocimientos IT necesarios para implementarlas. Por eso hemos decidido buscar una herramienta o plataforma mediante la cual las personas con una formación menos técnica puedan hacerse una idea más clara de las capacidades de Sofia2 y, tal vez en un futuro, se animen a aprender un poco de Android para llevar a buen puerto sus ideas. Tras valorar el abanico de posibilidades que existe en el mercado, nos decantamos por utilizar la herramienta Google App Inventor 2 dado que combina la simplicidad para el usuario sin limitar las capacidades técnicas de la solución a construir. Este es el primero de una serie de posts que pretenden explicar el funcionamiento de esta herramienta y su comunicación con la plataforma Sofia2, a través del desarrollo de una aplicación móvil que contiene funcionalidades básicas que podrán ser extrapolables para la realización de otros proyectos.

Google App inventor es una plataforma de Google Labs para desarrollo sencillo de aplicaciones Android. Como todo en la vida, tiene partes buenas y partes no tan buenas:

– Por un lado permite desarrollar fácilmente aplicaciones que Android, de una manera visual y sin tener que escribir líneas de código.

– Por otro lado, a día de hoy, la potencia y capacidad de personalización son algo limitadas. Además hay que tener nociones básicas de lógica.

Google App Inventor se basa en dos vistas:

– La vista diseñador: para diseñar la interfaz, y añadir elementos como botones, cajas de texto, áreas… Todo esto de una manera muy intuitiva, mediante el método “drag and drop” (arrastrar y soltar).

– La vista de bloques: con esta vista podemos acceder a las funcionalidades de los elementos que hemos añadido con la vista de diseñador: poner eventos, configurar alertas, cambiar propiedades… además de poder añadir procesos lógicos: si ocurre X hacer Y, para cada elemento de la lista hacer Z…

Los desarrolladores de aplicaciones pueden generar el fichero .apk (fichero necesario para instalar la aplicación en un sistema Android), ejecutar la aplicación en el móvil conectado por USB al ordenador o ver la aplicación funcionando en un emulador dentro del PC cómo si fuera un dispositivo Android cualquiera…

La aplicación que desarrollaremos a lo largo de esta serie de posts será una aplicación muy básica que permite leer una serie de datos de temperaturas almacenadas en la plataforma Sofia2 y enviar registros de temperaturas desde nuestro teléfono.

Para los impacientes que no puedan esperar al siguiente post, donde comenzaremos a desarrollar la app, se puede echar un vistazo a la app mediante la descarga el fichero .aia (para importar en Google App Inventor 2) o el fichero apk (para instalar y ejecutar la app en un dispositivo Android).

Además, para tener claros algunos conceptos importantes, recomendamos echarle un vistazo a los conceptos Ontología y API Manager, ya que serán utilizados durante los siguientes posts.

Sofia2 y Google App Inventor: Introducción.

Tipos de Índices en BDTR Sofia2 (MongoDB)

Los índices son un factor de tuning de rendimiento fundamental en cualquier base de datos, y también en la BDTR de Sofia2.

Sofia2 usa en su implementación de referencia MongoDB como BDTR

Los índices en MongoDB tienen una correspondencia con índices de una base de datos relacional por lo que resultan familiares a los que vienen de SQL.

El tipo y frecuencia de las queries deben tenerse en cuenta a la hora de seleccionar los índices, ya que estos imponen un overhead en las escrituras y en el uso de recursos (disco y memoria).

Tipos de índices

MongoDB tiene un modelo de consultas rico que permite acceder de forma sensible a los datos. Por defecto MongoDB crea un índice sobre el campo _id del documento.

Todos los índices creados por el usuario son índices secundarios, cualquier campo puede usarse como índice secundario, incluyendo campos con arrays.

Las opciones de indices incluyen:

· Indices compuestos : permite usar más de un índice para una consulta. Esta capacidad es útil cuando se ejecutan consultas ad-hoc y los patrones de acceso de datos no son conocidos de antemano.

· Índices únicods: MongoDB rechazará inserciones de nuevos documentos o actualización de un documento con un valor existente para el field para el que se ha creado el índice único. Por defecto todos los índices se establecen como NO únicos.

· Índices de array: índices para campos de tipo array, cada valor del array se almacena como una entrada de índice separada.

· Índices TTL: índices Tiempo de vida (TTL) permiten al usuario especificar un período de tiempo después del cual la base de datos elimina automáticamente los datos. Un uso común de TTL es en aplicaciones que mantienen una ventana de historial para las acciones del usuario tales como clickstreams.

· Índices geospaciales: para optimizar consultas relativas a la ubicación dentro de un espacio de dos dimensiones. la tierra. Estos índices permiten lanzar consultas de documentos que contienen un polígono o puntos, los más cercanos a un punto o línea, que están dentro de un círculo, rectángulo o polígono; o que cruzan un círculo, rectángulo o polígono.

· Índices Sparse: estos índices sólo contienen entradas para los documentos que contienen la el campo especificado. Como MongoDB permite que el modelo de datos varíe de un documento a otro, es común para algunos campos estén sólo en un subconjunto de todos los documentos. Permite índices más pequeños y eficientes.

· Índices Hash: permite calcular un hash del valor de una campo e indexar el valor. Se usan para permitir sharding basado en hash haciendo una distribución simple y uniforme de los documentos a través de fragmentos.

· Índices de búsqueda de texto: MongoDB ofrece un servicio de búsqueda de texto, permite añadir uno o varios atributos.

El Motor de almacenamiento de MongoDB soporta todos los tipos de índices, a diferencia de algunas bases de datos relacionales, donde según el motor pueden usarse uno o otros índices.

Optimización del rendimiento con indices

El optimizaador de consultas de MongoDB selecciona el índice de forma automática ejecutando planes de queries y seleccionado el plan que da mejor tiempo de respuesta.

El optimizador puede sobreescribirse con el método cursor.hint().

Como en las bd relacionales el DBA puede revisar los planes de consultas y asegurarse de que las consultas se ejecutan con el índice correcto.

La función explain() da informes sobre tiempos, documentos, índices usados, memoria,…

El Profiler de Mongo se usa durante depuración para por ejempll logear operaciones cuyo tiempo duran más de 100 ms (por defecto).

Una vez conocemos los índices soportados por la BDTR de Sofia2 podemos ver cómo crearlos de forma sencilla en esta entrada del Blog: https://about.sofia2.com/2014/12/15/soporte-creacion-de-indices-desde-la-consola/

Tipos de Índices en BDTR Sofia2 (MongoDB)

Soporte a MongoDB como Base Datos Histórica Sofia2

Hasta ahora el motor por defecto de la BDH era Hadoop (+HIVE+Impala). Esta funcionalidad permite que la BDH sea una instancia de Mongo dedicada, esto permite el despliegue de la Plataforma en organizaciones en los que el uso de Hadoop pueda no ser apropiado

Para configurar el paso de la BDTR a la BDH siendo esta última una instancia de MongoDB, hay que añadir las propiedades necesarias que indican la instalación y propiedades de conexión de la  BDH MongoDB. Estas propiedades se encuentran en el fichero database.properties del módulo process.

properties

Además el proceso debe activarse mediante la propiedad

rtdb2hdb.mongodb.enabled=true

Finalmente hay que indicar en que momento desea lanzarse el paso mediante una expresión cron del estilo:

rtdb2hbd.mongodb.cron=0 06 08 1/1 * ? *

Estas propiedades se encuentran en el fichero rtdb2hdb.properties ubicado en el módulo process.

El proceso es exactamente igual que en el caso de Hadoop, es decir, se configura para una determinada Ontología mediante la consola web de Sofia2. Para ello a la hora de crear/modificar una ontología debemos indicar si queremos que los datos sean almacenados en una base de datos histórica, mediante el combo que indica si los datos a pasar son anteriores a uno, dos o tres días. Además podemos agruparlos mediante un script de agregación que deberá dar de alta un administrador de sistema. Por el contrario podemos indicar si simplemente queremos eliminarnos de la BDTR sin pasar a la BDH.

configuracionconsola

Una vez configurado el paso a la BDH, un proceso que se ejecuta de acuerdo a una expresión cron, lanza un comando de exportación de Mongo que almacenará en un fichero temporal los datos que queremos pasar.

mongoexport –db <base_de_datos> -h <host> –port <port> -c <ontologia> -o “<path><nombre_fichero>.json.tmp” -q {‘contextData.timestamp’:{‘$lt’:{‘$date’:<fecha_configurada>}}}

Una vez realizado el export es necesario realizar un import de estos datos en la BDH, mediante el comando “mongoimport” de Mongo.

mongoimport –db <base_de_datos> –host <host> –port <port> –collection <ontologia>  –file “<path><nombre_fichero>.json.tmp”

Soporte a MongoDB como Base Datos Histórica Sofia2

Conversión entidad (colección) MongoDB a ontología

La versión 2.16 de Sofia2 incorpora una nueva funcionalidad mediante la que se permitirá gestionar entidades (colecciones de datos) importadas en la BDTR.

Como primer paso, deberá importarse la colección en la base de datos de tiempo real. Una vez importada, se accederá a la consola de la plataforma.

Esta funcionalidad sólo está disponibles para usuarios con perfil Administrador.

Se selecciona la opción de menú Crear Ontología desde Colección.

Aparecerá la pantalla que se muestra a continuación.

En el primer componente se incluyen todas las colecciones existentes en la BDTR que no están asociadas a una Ontología existente en la plataforma.

Tras pulsar sobre una de ellas, se cargará un registro de la colección en el panel desplegable Registro de la Colección.

Una vez revisada la instancia y comprobado que es la colección que se desea importar, se pulsa sobre el botón Generar Esquema.

Si la instancia es correcta, se generará un esquema que representará a los registros de la colección. Este esquema será editable, y se permitirá introducir modificaciones sobre el mismo.

Una vez se haya comprobado que el esquema es correcto, se incluirán el resto de parámetros asociados a la Ontología que se desea generar en el tercer y último panel de la pantalla.

Tras comprobar todos los datos, se pulsará sobre crear. Se creará una Ontología asociada a la colección seleccionada con la configuración que se haya incluido, gestionable por la plataforma.

Conversión entidad (colección) MongoDB a ontología