Nuevas funcionalidades de OBIEE 11.1.1.6 (1)

Como prometió, Oracle lanzó la semana pasada (concretamente el 22 de Febrero) la nueva versión de su suite de Business Intelligence a la que cariñosamente llamamos OBIEE. Esta nueva reléase es la versión 11.1.1.6.0 y viene cargada de novedades y mejoras.

Tiempo de lectura 5 minutos

Había mucha expectación en torno a esta nueva versión y tengo que deciros que de momento el sabor que me ha dejado es un poco agridulce. Veo buenos movimientos y mejoras, pero se han dejado algunas cosas en el tintero y además algunas de las nuevas funcionalidades no funcionan demasiado bien…

En este primer artículo me centraré en las mejoras y nuevas funcionalidades que podemos encontrar en el interfaz de la herramienta. En el segundo artículo echaré un vistazo a las mejoras desde el punto de vista administrativo y de repositorio.

Resumen de las mejoras introducidas en OBIEE 11.1.1.6 para usuarios

  • Autocompletar los prompts de los cuadros de mando

    Esta nueva característica (desactivada por defecto) nos permite que nuestros prompts de tipo textbox se autocompleten mientras escribimos (de la misma forma que hace google, por ejemplo). Es una función visualmente atractiva y útil para los usuarios. Sin embargo Oracle recomienda utilizarla con cuidado ya que si el sistema no cuenta con los recursos recomendados puede ralentizar la aplicación.

    Autocompletar nos muestra las coincidencias mientras escribimos

     

  • Mostrar u ocultar el botón de “Aplicar” en los prompts

    Una de las principales mejoras es que ahora podemos eliminar el botón de “Aplicar” de los prompts para que los cambios se apliquen inmediatamente. Esto, de nuevo, es un arma de doble filo y deberemos usarla cuando estemos seguros de que el sistema puede responder a las peticiones de forma rápida. Si es así obtendremos una muy mejorada experiencia de usuario que nos permitirá filtrar los cuadros de mando de forma más intuitiva.

Podemos elegir si mostrar o no el botón de Apply y el de Reset

 

  • Mejoras en el botón de “Reset” de los prompts en cuadros de mando

    Por fin, el botón de reset ya hace lo que todo el mundo espera (y antes no hacia) que es limpiar la actual selección de filtros. Por si alguna mente obtusa se había acostumbrado al anterior comportamiento del botón (que básicamente solo limpiaba los campos si aún no habíamos pulsado aplicar) han mantenido ese comportamiento también.  Además, como muestra la imagan anterior, el botón puede ser ocultado del prompt si no es necesario.

    ¡Por fin funciona como debería!

 

  • Nueva sección de favoritos en el menú principal

    Una de las novedades menores es que ahora los usuarios pueden marcar sus análisis más utilizados y crear así su lista de favoritos. Estos análisis son accesibles desde la barra principal de OBIEE que siempre es visible. Una limitación que he visto (y espero que corrijan) es que no puedes guardar como favorito un cuadro de mando con sus personalizaciones; Estas tienen que ser guardadas como “Saved Customizations” y luego aplicadas como tal una vez cargado el cuadro de mando.
    Por otra parte cada usuario puede crearse sus propias carpetas dentro de favoritos (se llaman secciones) para organizarse el contenido. No esta mal. 

    Podemos añadir, borrar o editar nuestros favoritos

 

  • Nueva información en la página Home

    Con esta nueva reléase se mejora la personalización de la (subestimada) pantalla home y del menú de navegación principal. La configuración no es muy intuitiva (es necesario modificar algunos xml) pero funciona bien. De esta forma podemos añadir links personalizados al menú principal o a la sección “Get Started”, pudiendo incluir nuestros propios iconos para una mejor integración.  La documentación de Oracle explica bien como hacer estos cambios, pero blogearé sobre el tema para mostraros como se hace.

    Gracias a los custom links podemos personalizar más la Home page

 

  • Posibilidad de descargar el Admin Tool desde la página de inicio

    En anteriores versiones ya podíamos descargar las herramientas para BI Publisher, pero en esta edición además podremos descargar el admin tool para 32 o 64 bits. No creo que sea algo que los usuarios vayan a querer hacer (de hecho miedo me da que lo hagan…). Creo que es controlable por permisos de todas formas.  Lo que sigue sin estar disponible es el admin tool para Linux :

Podemos descargar el admin tool desde la home page de OBIEE, pero sólo para windows

 

 

  • Posibilidad de entrar en modo accesible desde la pantalla de login

    Las mejoras en accesibilidad siempre son buenas, así que no vamos a quejarnos por que haya un checkbox nuevo en la página de login. Además, entrando en modo de accesibilidad podremos acceder a otras funcionalidades como el BI-Composer.

    Mejorar la accesibilidad de la aplicación siempre es algo positivo

 

  • Mejoras en las tablas y en las pivot-tables

    Esta es otra de las mejoras importantes de esta versión. Gracias a ella podemos hacer cosas verdaderamente interesantes sobre los datos de una tabla. Por ejemplo, sobre un conjunto de datos podemos:
    – Eliminar elementos
    – Mantener solo algunos elementos
    – Crear elementos calculados basados en agregaciones (sum, avg, count…) y añadirlos directamente en la tabla
    – Mantener solo los elementos que cumplan alguna condición basada en las medidas de la tabla 

    Esto es muy potente, ya que le da a los usuarios una nueva herramienta con la que analizar la información (que es de lo que se trata al fin y al cabo, no olvidarse…) y de esta manera serán un poco más independientes del equipo de desarrollo de informes y análisis.

De lo mejor de la nueva versión. Gracias a las nuevas funcionalidades en las tablas los usuarios podrán jugar más con sus datos

  • Nuevas vistas y mejoras en la vista de mapas

    Dado que los usuarios ahora pueden jugar con sus tablas, se ha incluido una nueva vista disponible llamada “Selection Steps View” que básicamente muestra los filtros y operaciones que se han realizado en la tabla en cuestión. Muy útil y sencilla de utilizar.
    Por otra parte se han introducido mejoras en las vistas de mapas, que para ser honesto todavía no he probado. Si me pongo con ello ya os contaré. 

    La vista de selection steps es muy útil ahora

 

  • Posibilidad de renombrar las vistas individuales y compuestas

    Una cosita que no viene mal, la posibilidad de poder renombrar nuestras vistas con algún nombre un poco más coherente que table, table(1), table(2)…
    Ojo que el botón nuevo de renombrar en la sección de vistas a mi no me funciona, para renombrarlas tengo que entrar en cada vista por separado y utilizar el nuevo botón que han colocado a tal efecto, como muestra la imagen siguiente 

    ¿Renombrar las vistas? ¡Genial! ¿Lo usaremos? Seguro que no...

 

  • Acceso al BI-Composer sin utilizar el modo de accesibilidad

    Algo bastante evidente es que el BI-Composer no está solo indicado para las personas que tienen algún tipo de impedimento y necesitan el modo accesible. Al fin y al cabo el BI-Composer es simplemente un asistente para ayudar a los usuarios a crear sus propios informes de una forma más guiada que usando el editor de informes habitual.  Si bien no tiene toda la funcionalidad, puede ser una alternativa interesante para esos usuarios a los que les cuesta hacerse con la herramienta.
    Con la nueva versión cada usuario puede elegir si desea utilizar el BI-Composer o el editor habitual a la hora de crear los informes. La opción se encuentra en las preferencias de la cuenta.
    Ojo, ten en cuenta que para que esta opción esté disponible es necesario haber instalado el BI-Composer, que no viene instalado por defecto.

Ahora podemos activar el BI-Composer bajo demanda (una vez instalado...)

 

Bueno, pues de momento vamos a dejarlo aquí. Son un puñado de nuevas funcionalidades, algunas más útiles que otras pero todas bienvenidas. En el siguiente artículo daremos un repaso a las mejoras desde el punto de vista de repositorio, que también hay tela que cortar :)

Cuadrante mágico de Gartner 2012

Un año más tenemos con nosotros el prestigioso análisis que realiza la consultora independiente Gartner sobre las más influyentes plataformas de Business Intelligence del mercado actual.

Tiempo de lectura: 5 minutos

El año pasado realicé un análisis exhaustivo del cuadrante de 2011, haciendo hincapié en detallar como debe de ser entendido el cuadrante y sus ejes y lo que significa estar en cada uno de los cuatro cuadrantes.  Por último también revisamos las “predicciones” que realizaba Gartner sobre el futuro del BI en 2011.

Dado que las dos primeras partes son comunes todos los años, no vamos a entrar en detalle al respecto. Directamente voy a presentaros como queda el cuadrante mágico este año y a repasar un poco lo que han visto los de Gartner en su bola de cristal.

Posicionamiento de los vendedores BI en el cuadrante

Pues ahí lo tenéis. A la izquierda tenemos el nuevo cuadrante y a la derecha el del año pasado. Pocos cambios, ¿verdad?

Dos cosas principales destacaría yo. El batacazo de Microsoft y también que las plataformas de data discovery como Tableau, Tibco Soft y Qlikview están funcionando muy bien.  El caso concreto de Tableau, la niña bonita del cuadrante, es particularmente interesante. A pesar de que la empresa ha tenido un espectacular crecimiento del 94% en 2011 sigue manteniendo las puntuaciones más altas en las categorías en facilidad de uso, funcionalidad, rendimiento, soporte y relación con el cliente. Ahí es nada.
Lo más curioso es que de alguna manera se están aprovechando del tirón de Qlikview, que siendo una empresa más grande están siendo los que están tirando del carro de las herramientas de data discovery. De esta manera, algunos clientes llegan a conocer esta tecnología  a través del marketing de Qlikview pero luego a raíz de lo visto descubren Tableau y… zas! Cliente robado.

Por lo demás, ahí están los megavendors sin cantearse. Oracle puntua alto en ability of execute y sigue comprando a diestro y siniestro (ojo con la adquisición de Endeca). MicroStrategy empieza a acusar el obligado crecimiento como empresa que les ha supuesto su éxito, pero quedan muy bien. IBM con Cognos 10 sigue firme como una roca y SAP gana unos puntillos en completeness of vision posiblemente gracias a HANA.

Y durante otro año más, el cuadrante de los visionarios está vacio. ¿Significa esto que no hay innovación en el campo del BI? Ni mucho menos señores. Business Intelligence es posiblemente el campo más caliente de la informática empresarial ahora mismo. Y Gartner prevé movimiento en este 2012, identificando seis principales tendencias que pueden impactar en las decisiones de los proveedores de BI de cara a sus productos.

Tendencias para el 2012 en Business Intelligence (según Gartner…)

1 – Se evidencian las discrepancias entre la gente de IT y los usuarios de negocio

Más o menos, de toda la gente que ha encuestado Gartner podemos decir que un 60% son IT y un 40% son usuarios de negocio (más o menos…) . Cuando se les preguntó sobre cuales son los factores más importantes a la hora de elegir un proveedor de BI los usuarios de negocio contestaron que lo más importante es la facilidad de uso y después la funcionalidad de la herramienta. La gente de IT, ante la misma pregunta, contestó que para ellos es más importante la funcionalidad y luego la facilidad de uso.

Esto es tremendamente evidente. El usuario de negocio quiere la herramienta más sencilla posible para capear sus carencias técnicas ya que al fin y al cabo su trabajo no consiste en pelearse con una herramienta informática “súper compleja”. Y por otra parte el personal de IT quiere que la herramienta cubra la mayor funcionalidad posible, por que lo que no cubra la herramienta se lo van a pedir de igual forma y va a tener que buscarse la vida para hacerlo funcionar.

¿Cómo solucionar esto? Difícil tarea. Posiblemente veremos en el futuro una tendencia a banalizar la inherente complejidad técnica de un proyecto BI en soluciones muy bonitas pero aisladas y poco integradas, aumentando así  la dependencia de IT que es precisamente lo que queremos minimizar. Gartner dice que al usuario de negocio no le importa tanto que la solución sea estándar o integrada con tal de que le sirva para resolver el trabajo que tiene que hacer ahora. Creo que tenemos que tener cuidado, ya que si al final los usuarios de negocio se convierten en dueños de las implantaciones de BI podemos terminar en una versión moderna del excel-hell…

2 – El momento del Data Discovery ha llegado.

Esto se venía venir desde el año pasado. ¿Pero a que nos referimos exactamente cuando hablamos de “data discovery”? Nos referimos a herramientas que ponen el acento en las capacidades de visualización de datos que ofrecen al usuario y en la velocidad de respuesta. Utilizando avanzados interfaces nos permiten con unos pocos clicks obtener representaciones visuales muy intuitivas de nuestros datos y nos dan la capacidad de ir profundizando en el análisis a la vez que vamos obteniendo conclusiones. La mejor manera de entendero es viendo este video de Tableau Software en el que podéis ver un ejemplo.

 

Pulsa para ver el video en la página de Tableau.

Posiblemente durante este año los pure-players enfocados a data discovery seguirán obteniendo buenos resultados mientras que los megavendors pondrán algún pegote a sus soluciones para intentar cubrir esta funcionalidad cada vez más demandada por lo que hemos comentado en el punto  1.

3 – Mobile BI, Mobile BI everywhere!

Otra perogrullada. “La tendencia a llevar el BI a los dispositivos móviles continuará este año”. Muy bien, como los 10 anteriores. Vale, es cierto que posiblemente ahora por primera vez convergen factores tecnológicos (redes de datos a tutiplén) con factores sociales (iPads a tutiplén) para posibilitar de una vez una amplia y exitosa solución móvil de BI en las empresas.

Cada casa está poniendo guapa su app para la app store de Apple y el Android Market. Posiblemente aún durante el 2012  veremos como los proveedores multiplican sus esfuerzos en desarrollar aplicaciones específicas para cada una de las plataformas con la intención de aprovechar a tope los dispositivos. Personalmente creo que en un futuro cercano se producirá el efecto contrario y que se tenderá a desarrollar bajo estándares (HTML5?) que funcionen en todos los gadgets. Pero eso para otro cuadrante.

4 – Un mayor enfoque en la toma de decisiones

Otro viejo conocido que repite en el cuadrante de este año. Parece que las cosas no cambian y la gran mayoría de sistemas BI acaban siendo  utilizados más para realizar reporting (datos pasados o presentes) que para soportar la toma de decisiones (futuro).  No olvidemos nuestro objetivo, mejorar la toma de decisiones a través del análisis de datos. En este sentido se ha venido trabajando desde hace tiempo (Oracle RTD por ejemplo) y los resultados no han sido todo lo buenos que cabía esperar.
Parece que ahora con las nuevas tendencias que están introduciendo los ya mencionados sistemas de data discovery y las velocidades que obtenemos con tecnología in-memory estamos en una mejor situación para ofrecer modelos que realmente ayuden a mejorar en la toma de decisiones y no sólo sirvan para los (muy necesarios también) escenarios analíticos.
Sin embargo no deja de ser motivo de reflexión como en un mercado tan maduro como el Business Intelligence seguimos “fallando” en conseguir de manera clara uno de sus objetivos capitales…

5 – Una avalancha de nuevos casos de uso y nuevos tipos de contenido

En los resultados obtenidos por Gartner, destacan como los sistemas de BI se están llevando a nuevas áreas de negocio distintas de las clásicas (finanzas, ventas y gestión), como puedan ser la gestión de riesgos financieros, el social media, gestión de calidad…  Evidentemente, cada nueva área objetivo de ser analizada puede plantear nuevos casos de uso y nuevos tipos de datos, planteando retos a las actuales aplicaciones de BI.

Por ejemplo, cuanto más operacional sea nuestro caso de uso, más tiempo real vamos a necesitar para satisfacerlo. En áreas como la gestión de riesgo se trabaja con información muy actualizada sobre las condiciones de compra o el estado de crédito de clientes. Sencillamente no podemos esperar 24h a que se refresquen los datos, ya que es posible que tengamos que tomar decisiones a raíz de una operación financiera que acaba de suceder.

Por otra parte, si pensamos en el análisis de sentimiento de marca a través de la valiosísima información que arrojan las plataformas de social media nos enfrentamos con tipos de datos no estructurados y en volúmenes no triviales. Ya hemos hablado un poco de Big-Data en este blog, y es un ejemplo perfecto de como las plataformas de BI tienen que ponerse las pilas para dar salidas a las nuevas funcionalidades que se les va a demandar en un futuro cercano.

6 – Hay que eliminar la complejidad de la ecuación

Y Gartner cierra el ataúd con el mismo clavo. El BI es difícil desde todos los puntos de vista. Es difícil para los usuarios, es difícil para IT, es difícil de vender, de comprar, de mantener…  Y a mi me parece que este mensaje es demasiado negativo y no hace justicia a las herramientas existentes. En un momento dicen:

Many innovations in the data discovery segment have had a direct impact on how easy these products are to use. But there are additional layers of analytic sophistication  (casual analysis, predictive modeling and so on) that also need to be simplified so they can be consumed by business users , no just analytic experts  –

Si algo que es complejo de por sí y lo simplificamos tanto como para que lo pueda entender cualquiera… ¿No estaremos perdiendo por el camino su valor?  ¿Si existe la figura del analytic expert en la organización no deberíamos confiar en sus capacidades y ofrecerle herramientas potentes aunque sean complejas?

Al final, hace falta inteligencia no sólo en la aplicación sino en quienes la usan...

Los grandes vendedores de BI hacen lo posible para mejorar la facilidad de uso de sus herramientas, y estamos viendo como casi todos empiezan a incluir tecnología in-memory e interfaces de visualización avanzados.  En este sentido Oracle ha preparado su máquina Exalytics para poder cargar todo un datawarehouse en memoria usando TimesTen 11.2 y realizar la explotación de datos usando el nuevo interfaz de OBIEE 11.1.1.6 y Endeca Latitude.

Mi conclusión

El análisis de Gartner de este año nos revela un panorama sin demasiados cambios. Las tendencias del año pasado se consolidan (data discovery, mobile…) y los defectos del año pasado siguen ahí. También vemos que hay margen para la esperanza, ya que tanto los megavendors como los pure-players están constantemente mejorando sus productos para cubrir las funcionalidades que el mercado va demandando.
Desde mi punto de vista y haciendo mi predicción particular, en 2012 lo más caliente van a ser las soluciones móviles de BI usando apps nativas para iOS y Android. Big Data también sonará mucho pero creo que tardará un año más en consolidarse.

Más información y otros puntos de vista

Para terminar os dejo con otros estudios que han realizado webs amigas y compañeros sobre los resultados de Gartner. En el blog de Aníbal Goicochea tenéis un resumen de cuales han sido las principales fortalezas y debilidades de los proveedores este año. Por otra parte en el blog de BI Fácil se hace hincapié en el hecho de que el BI siga siendo tan complejo. ¡Ambas lecturas muy recomendables!

 

Un año aprendiendo Business Intelligence

¡Hola de nuevo! Mientras preparo el siguiente artículo (que ya adelanto que estará relacionado con Hadoop de nuevo) me gustaría compartir con la gente que lee el blog las estadísticas del año pasado.

Tiempo de lectura: 2 minutos

Si, ya hace un año que comencé a escribir este blog con la humilde idea compartir mi conocimiento sobre el mundo del Business Intelligence. La verdad es que si bien es cierto que llevar un blog conlleva cierto sacrificio también es cierto que la satisfacción del trabajo realizado y el feedback positivo de la gente a uno le animan a seguir con ello. Además gracias a este blog he podido contactar con gente del gremio muy interesante y que me han enseñado muchas más cosas, así que creo que desde todos los puntos de vista el trabajo invertido en este blog ha merecido la pena tanto profesional como personalmente.

Y sin más dilación vamos a ver un poco que ha pasado durante un año. En términos generales se observa una claro incremento de las visitas a lo largo del tiempo  y coincidiendo con la creación de contenido. Al final desde diciembre del año pasado hasta este diciembre se han superado las 10.000 visitas al blog, con más de un 30% de gente que repite. ¡Genial!
El tiempo promedio en el sitio es de 2 minutos 20 segundos, lo cual me parece bastante alto. Es cierto que los artículos son largos y a veces un poco pesados… pero me alegra saber que la gente dedica tiempo a leerlos. Un porcentaje de rebote (gente que llega a la página y se marcha sin hacer ningún clic) es un 70%, un poco alto, pero no escandaloso para tratarse de un blog, ya que mucha gente encuentra un artículo, lo lee, y cierra.

Estadíticas generales del sitio desde Dic 2011 a Dic 2012

 

Si echamos un vistazo a los datos demográficos es interesante ver como muchas visitas llegan de centro/sur América. Eso es algo que precisamente buscaba cuando decidí escribir este blog en castellano. Me alegro mucho de contar con lectores de diferentes lugares y colaborar con mi granito de arena a toda la comunidad hispano hablante que se dedica a llevar adelante proyectos de BI. Mexico, Colombia, Chile y Perú son los países latino americanos que más entran al blog, lo que también indica de alguna manera que el BI está pegando fuerte por aquellos lugares, y cuando el BI se demanda es por que hay negocio detrás.

 

Estadísticas demográficas. España y Mexico las que más visitan el blog

 

Por último, y para no ser cansino, vamos a revisar los datos de contenido. ¿Qué es lo que más le ha interesado a la gente durante el 2011? Pues si hacemos caso a las estadísticas que tan amablemente me proporciona google, tenemos que la página de entrada al blog (/) es la primera con más de 4300 visitas. Este tipo de tráfico viene generado normalmente por favoritos o búsquedas genéricas. Si miramos páginas concretas, el tema que más visitas ha generado es el análisis de Gartner para el 2011, uno de los primeros artículos que escribí en el blog. A continuación se encuentran dos artículos sobre instalación y arquitectura interna de OBIEE 11.1.1.5 que son bastante técnicos y elaborados. Espero que la gente encontrara útiles esos artículos, ya que en el futuro quiero seguir escribiendo ese tipo de entradas, bastante técnicas y detalladas, que nos permitan entender los entresijos de OBIEE.

Estadísiticas por contenido. Los artículos sobre OBIEE obtienen muchas visitas.

 

Hay muchas más estadísticas interesantes, pero no quiero extender el tema. El objetivo de este artículo era compartir con vosotros los números y además tenerlo aquí a modo de referencia para el año que viene poder comparar. Tengo la firme intención de seguir adelante con el blog, intentando actualizarlo más frecuentemente y con contenido actual e interesante. Para el futuro me gustaría seguir con el tema de Hadoop, comentar la adquisición de Endeca, seguir de cerca la evolución del maquinón Exalytics y el Big Data Appliance, comenzar con Essbase e interesarme por las bases de datos por columnas como TimesTen. Y seguro que entre tanto llega el nuevo informe de Gartner, la 11.1.1.6, fusion applications… y mucho más.

Se prevé un año muy interesante en el mundo del BI y me encantaría seguir compartiéndolo con todos vosotros. Espero que vosotros también sigáis pasando por aquí para leerme de vez en cuando.

Salud y os deseo un feliz 2012 lleno de éxitos.

Hadoop en proyectos de Business Intelligence

En los últimos meses el término “Hadoop” ha cobrado mucha fuerza en la escena de Business Intelligence. De repente todo el mundo habla de Hadoop y Big-Data, nuevos productos aparecen, viejos productos vuelven a estar de moda y en general la sensación es que es la pera. Sin embargo poca gente sabe realmente lo que es y lo que implica usarlo.

Tiempo de lectura: 5 minutos

¿Qué diantres es Hadoop? Esa es la pregunta que llevaba haciéndome desde hace un tiempo. Con la intención de despejar mis dudas no dudé en apuntarme a un webinar ofrecido por TDWI cuyo objetivo era precisamente aclarar qué es Hadoop y cuál es su aplicación en proyectos de BI y DW. El webinar en sí fue muy interesante, os presento a continuación algunos de los puntos que se cubrieron y mis conclusiones personales al final.

El logo no me acaba de convencer...

 

  • Hadoop son muchos productos. No uno sólo.
  • Hadoop como tal no existe… No puedes “descargar Hadoop”. Hadoop es un ecosistema de productos bajo el paraguas de la Apache Software Foundation.  De esta forma hay dos productos principales que conforman el nucleo de cualquier aplicación Hadoop. Estos son el HDFS y MapReduce. Pero además de estos productos básicos, existen multitud de productos o iniciativas opensource que modifican o complementan el nucleo de Hadoop. Los más utilizados en los proyectos de BI y BigData posiblemente serán Hive, HBase y Pig.

    Por lo tanto, cuando hablamos de Hadoop debemos dejar claro a que subconjunto de productos nos estamos refiriendo.

  • Hadoop se basa en un sistema de archivos. No es una base de datos.
  • Sorpresa en tu mesa. ¿Hadoop es un sistema de archivos? Bueno, seamos formales. Uno de los productos core de hadoop, HDFS, es un sistema de archivos. Y generalmente es la primera piedra de un proyecto Hadoop. HDFS es altamente distribuido y tolerante a fallos, y está especialmente pensado para correr clusters de pc’s de escritorio, ya que es super escalable.

    Pero claro, un sistema de archivos no es eficiente a la hora de recuperar información (no al menos al nivel de un RDBMS), es lento y proporciona pocas herramientas de búsqueda. Aquí es donde entran en juego otros de los productos Hadoop, como HBase (creado a partir de google’s BigTable), que nos ofrece una capa de acceso a la información en el HDFS mucho más eficiente. Si os dais cuenta ya se van dibujando las sinergias entre los componentes Hadoop.

  • MapReduce prepara los datos para ser analizados, pero no los analiza.
  • MapReduce corre encima del HDFS. Es un motor que diseñaron en Google antes de que existiera HDFS, por lo tanto puedes ejecutar MapReduce sobre otros sistemas de almacenamiento.  En realidad es como un framework de desarrollo de software que te permite escribir aplicaciones de acceso a datos con acceso en paralelo, tolerante a fallos y totalmente distribuido. Su funcionamiento se basa en trocear la información del HDFS (la parte “map”), dejar que cada nodo procese su parte , extraer y ordenar la información interesante de cada trozo y luego juntarlo todo en algo un poco más estructurado (la parte “reduce”).

    Cuidado porque MapReduce, tal cual, requiere que escribamos un montón de código (y no vale SQL), lo veremos en detalle en el siguiente punto.

  • Hadoop no entiende estándar SQL, pero todo se andará…
  • Decíamos que MapReduce no entiende SQL. ¿Cómo hablamos con él entonces? Hay muchas formas,  podemos escribir nuestras “consultas” en Java, C, C++, Python, Hive, R… Pero no en SQL, que es precisamente el lenguaje que más nos gusta a los frikis del BI. Lo más cercano que tenemos es Hive, que utiliza un lenguaje llamado QL que dicen que se parece bastante a SQL. Pero para el que no quiera liarse a aprender QL la mayoría de los vendedores de BI están preparando interfaces que trasladarán SQL al QL de Hive, que podrá ser ejecutado por MapReduce sobre HDFS… Vaya… parece que las piezas van encajando… :)

    Mi visión personal de como encajaría Hadoop en un proyecto BI

     

  • Hadoop se luce con datos no estructrados.
  • HDFS, al ser un sistema de archivos, básicamente se traga todo lo que le eches. Para cargar datos al HDFS necesitas utilizar un cargador, una API que puede coger desde ficheros de texto plano hasta JMS queues. Los datos no tienen que tener un orden o jerarquía, no tenemos que decirle a HDFS quién es quién o qué es qué. De eso ya se encargará MapReduce.

    ¿Y a qué tipo de datos nos referimos con datos no estructurados? Pues hay de diversos tipos. Información de sensores, registros de webs, texto a tutiplén, feeds de socialmedia… En general datos que se amontonan un poco sin orden ni concierto y que muchas veces dejamos fuera del DWH por que incorporarlos no es algo ni práctico (porque no es fácil entender los datos) ni posible (debido al enorme espacio que ocupan…)

Mis conclusiones

En mi primera aproximación a Hadoop he descubierto que tiene un enorme potencial, pero sus usos ahora mismo son concretos y creo que es un error pensar que esta arquitectura puede reemplazar un sistema tradicional de BI. Pensad que hasta la consulta más sencilla que lancemos desde Hive hacia al HDFS puede tardar (como mínimo!) varios minutos. Vale, podemos poner HBase en medio y la cosa mejorará… pero vaya follón ¿no?

Sin embargo, y si bien es cierto que es complejo y que ahora mismo igual es un poco arriesgado lanzarse a la piscina, está claro que algunos vendedores de BI como Oracle están apostando duro por esta tecnología. Con herramientas como el Hadoop loader para ODI, la adquisición de Endeca y su sistema Big Data Appliance Oracle ha demostrado que van en serio con este tema. Veremos si no se equivocan…

¿Y tú? ¿Qué opinas de Hadoop? ¿Te convence? Venga, anímate y deja un comentario!

Si os ha interesado el tema os dejo con algunos enlaces:

Introducción a Oracle GoldenGate

Recientemente he asistido a uno de esos talleres que organiza Oracle para intentar dar a conocer algunos de sus productos. En esta ocasión se trata de Oracle GoldenGate, una herramienta de esas que la gente conoce pero en general nadie sabe muy bien que es lo que hace…

Había oído que GoldenGate (OGG) servía para escenarios de BI en los que se requiere un acceso en tiempo real a la información. Esto es muy interesante, así que cuando en la empresa ofrecieron ir a este taller me pareció una gran oportunidad para conocer de cerca la herramienta y ver realmente que puñetas hace.

¿Pero para qué sirve GoldenGate?

GoldenGate es una herramienta que Oracle compró (como no…) hace unos años. Básicamente podemos resumir su funcionalidad en la siguiente frase:

“Oracle GoldenGate permite capturar con muy bajo impacto, enrutar, transformar y enviar información entre sistemas heterogéneos en tiempo real

O lo que es lo mismo, OGG básicamente mueve información del sitio A al sitio B, pero lo hace con mucha clase, eso sí.  Repasemos sus funcionalidades principales

  • Muy bajo impacto – Esto quiere decir que no sobrecarga los sistemas origen de los que extrae la información. Para conseguirlo, OGG no lee  de la base de datos, si no que vigila los archivos tipo redo que están presentes en las diferentes bases de datos con las que opera para saber cuándo se ha confirmado una transacción.
  • Sistemas heterogéneos – Gracias a ODBC, ingeniería inversa y a unas cosas llamadas VAM, OGG es capaz de interconectar una barbaridad de sistemas diferentes. Hay más sistemas destino que origen, ya que no todas las bases de datos del mercado utilizan tecnología que permita garantizar una integridad referencial completa (y sin esto OGG no puede funcionar)
  • Tiempo real – En la publicidad de OGG uno puede leer que la replicación de la información sucede con una latencia inferior a un segundo, lo que es muy impresionante. Si bien esto es cierto, no lo es siempre. Depende del tipo de escenario, tecnologías implicadas y el factor de la distancia para conseguir esas latencias. Pero en cualquier caso, estaremos hablando siempre de segundos, nunca de minutos.

Escenarios de uso con GoldenGate

Dada la naturaleza de su propósito, OGG puede sernos útil en diferentes escenarios, como por ejemplo migraciones zero-downtime, query off-loading o disponibilidad continua de la información en sistemas geográficamente dispersos. Voy a centrarme sin embargo en los dos escenarios relacionados con los sistemas BI

Operational Reporting

Hay veces que es necesario disponer de determinados informes tácticos para toma de decisiones que utilicen información en tiempo real. Podemos decir “nuestro ETL corre cada hora… cada media hora… cada 10 minutos…!!” y no será suficiente.

Este tipo de reporting sobre la fuente de datos transaccional es costoso en términos de rendimiento, y suele penalizar gravemente al sistema OLTP origen.

Para este tipo de situaciones OGG puede ayudarnos descargando información en tiempo real a otra plataforma (hardware obsoleto, otro SO, otra base de datos más barata…) de manera que las peticiones de reporting sobre esta información caliente podamos mandarlas a ese nuevo sistema. De esta manera, el sistema origen no se verá impactado en absoluto (bueno, mínimamente por OGG) y habremos cumplido el objetivo de ofrecer reporting con datos en tiempo real.

Real Time – BI

Hemos hablado todo el rato de mover información entre bases de datos, pero OGG también nos permite alimentar a nuestra herramienta ETL con los datos que extrae en tiempo real. De hecho, OGG es capaz incluso de realizar transformaciones sencillas, convirtiéndose él mismo en una mini-aplicación ETL para casos simples.

¿Qué conseguimos con esto? Pues algo muy interesante. Nuestro datawarehouse puede contener información consolidada de diferentes fuentes alimentada de forma periódica (diaria, cada seis horas…) y gracias a OGG puede contener también una parte de información consolidada y actualizada al segundo sin apenas impactar al sistema origen. A partir de aquí OBIEE es capaz de decidir donde tiene que buscar la información. ¿Me pides datos de ayer?  Pues voy a buscarlos al datawarehouse, ¿Me pides datos de hace 10 minutos? Pues voy a pillarlos a mi minirepositorio de datos real-time alimentado por OGG.

En este  repositorio real time sólo tendremos que mantener la información durante el tiempo que no cubre mi ventana ETL. Es decir, si mi ETL funciona cada 6 horas, será necesario almacenar como mucho 6 horas de información proveniente del OLTP via OGG. A partir de ese momento la información ya será recogida por el ETL y pasará a estar disponible en el DWH.

Los puntos clave de esta solución son:

  • OGG puede obtener datos de diferentes fuentes (igual que nuestro ETL) pero en tiempo real.
  • El impacto en los sistemas origen es mínimo ya que no accede a los datos sino a los archivos redo log para reconstruir las tran
    sacciones confirmadas.

GoldenGate no tiene interfaz gráfica! WTF?

Pantallazo de Oracle ManagementPack

No puedo cerrar el artículo sin comentar una de las cosas que más me sorprendió de esta herramienta. No tiene una interfaz gráfica propiamente dicha. Utilizar GoldenGate se limita a descomprimir los binarios en un directorio (por cada una de las bases de datos involucradas en el proceso) y configurar una serie de archivos de parámetros utilizando tu editor de texto favorito. A partir de ahí se arrancan una serie de procesos o servicios y ya lo tenemos funcionando.

Bueno, para no mentir, que tiene interfaz gráfica. Pero es un producto licenciado por separado por Oracle (mucho más barato que OGG). Se trata de Oracle ManagementPack for GoldenGate que nos proporciona una interfaz web muy completa sobre todos los aspectos de esta herramienta. Desde aquí podremos realizar la configuración, acceder a informes sobre tiempos, configurar alertas… de todo.

Lo malo es que esta herramienta tiene que correr sobre un servidor de aplicaciones weblogic y necesita un repositorio en alguna base de datos. Si ya tienes un entorno con OBIEE u ODI entonces te viene genial, pero si no lo tienes posiblemente no merece la pena.

Conclusiones

La verdad es que con un taller uno no puede hacerse a la idea de lo que la herramienta es capaz de hacer,  y por otra parte tampoco debe de creer todas las maravillas que de ella se dicen sin haberlas probado primero.

Para el negocio del BI creo que es una herramienta a tener en cuenta. Muchos de los proveedores de herramientas ETL están comenzando a sacar sus herramientas “real time” (como Informatica). Sin embargo, con goldengate y una ETL tradicional podemos “teóricamente” tener un stream de datos actualizados. De esta forma nuestro tiempo real se redefine como el tiempo de ejecución de nuestra tarea ETL.

Posibles usos de Oracle GoldenGate

 

En resumen, seguiré investigando un poco sobre esta herramienta y haciendo algunas pruebas de concepto, a ver si podemos engancharla para que trabaje con Informática en un escenario real. Ya os contaré si merece la pena :)

 

Los errores que debes evitar al diseñar un datawarehouse (2 de 2)

Hola de nuevo, esta es la continuación del artículo anterior en donde repasábamos los diez errores que hay que evitar al diseñar un datawarehouse tal y como recoge el libro de diseño dimensional de Ralph Kimball.

Ya repasamos los cinco primeros, y aquí tenéis el resto. Recordad que se han presentado en orden de importancia, lo que significa que estos cinco son aún más peligrosos que los anteriores y les debemos prestar especial atención.

(Tiempo de lectura: 2 minutos)

Error nº 5: “Antes de comenzar la implantación del datawarehouse, realizar un sesudo análisis de todas las áreas clave de la empresa al máximo detalle. Eso del diseño iterativo es sólo una excusa para no hacerlo todo bien a la primera”

Seamos sinceros, si pretendemos dar en el clavo a la primera nos vamos a equivocar. Sencillamente las casuísticas de las organizaciones son demasiado complejas para intentar entenderlas de forma global en una primera aproximación. La experiencia de los que llevan muchos años en esto nos dice que es mejor empezar con algo más humilde, centrándonos en realizar unas buenas dimensiones consolidadas y unas tablas de hechos iniciales que nos permitan ir diseñando el datawarehouse de forma iterativa a partir de una base ligera pero sólida.

Error nº 4: “No involucres  a los directivos de la empresa hasta que tengas el datawarehouse implementado y puedas enseñar algo tangible. Tu astuto plan será convencerlos cuando vean las maravillas que un datawarehouse ya montado puede proporcionarles”

¿Por qué no haría caso al bueno de Kimball?

Este es uno de mis favoritos. Uno de  los objetivo de un datawarehouse es alimentar una herramienta de BI, la cual se supone que permitirá analizar la información de la empresa para una mejor toma de decisiones por parte de unos fulanos que precisamente son los deberían brindar su apoyo incondicional al proyecto. No hay que lanzar un proyecto de datawarehouse únicamente desde el departamento IT.

Por mucho que tú y tu panda de colegas frikis de IT estéis seguros de que es imprescindible organizar un datawarehouse, NO os lancéis sin el apoyo de la dirección, porque fracasaréis. Si tu CIO no es capaz de convencer del valor estratégico de un proyecto así a la dirección de la empresa, mejor dedicaros a otra cosa. Un proyecto de este estilo va a necesitar de la coordinación de muchos departamentos diferentes, y la definición formal de entidades que en la empresa pueden tener diferentes puntos de vista. Es algo complicado, así que hay que estar seguros de que cuando lleguen los gritos haya una voz que los haga callar.

 

Error nº 3: “Anima a los usuarios de negocio a que estén constantemente dando feedback sobre el desarrollo e informando de nuevas métricas y fuentes de datos que añadir a las inicialmente analizadas”

Bueno, aquí Kimball y su gente se refieren a que el proyecto de implantación de un datawarehouse no es diferente a otros proyectos de desarrollo de software en lo que respecta a las fases de análisis y caputura de requisitos, desarrollo e implantación. Durante la segunda fase se podrían añadir nuevas funcionalidades a costa de retrasar plazos de entrega, y durante la tercera fase no se puede incluir ningún tipo de funcionalidad nueva.
En la fecha en la que se escribió este libro (2002) el concepto de desarrollo  ágil aún no estaba muy de moda, pero en los últimos años hay determinados sectores que afirman que los conceptos que defiende el manifiesto ágil podrían aplicarse al diseño de proyectos BI. Si fuera así, obtendríamos más flexibilidad a la hora de incorporar nuevas funcionalidades, pero estas no podrían ser introducidas en las fases iterativas de desarrollo. La verdad es que es una metodología muy interesante que comentaré en otro post.

Error nº 2: “Aceptar como primer entregable un datamart clave basado en clientes, como el de rentabilidad por ser uno de los más atractivos y deseados por los usuarios”

Este es un clásico. Una de las metodologías más seguidas a la hora de implementar un datawarehouse es la de abordar un área de negocio de la empresa, modelarla e implementarla para luego pasar a otra, etc. En este supuesto, es de suma importancia elegir bien nuestro primer objetivo.
Podemos estar tentados de empezar un datamart complejo pero de gran utilidad, como el de rentabilidad, ya que por si sólo representa una fuente de información poderosísima para la empresa. Sin embargo, este tipo de datamarts son muy complejos, y abordarlos de primeras suele ser garantía de fracaso. Es mucho mejor comenzar a estudiar la organización desde otros puntos de vista más abarcables, como la parte de ventas, compras, o almacenaje, y sobre ellos (y las dimensiones consolidadas que generen) montar el de rentabilidad más adelante.

Y llegamos al top 1 de los errores en el diseño de datawarehouses según Ralph Kimball:

Error nº 1: “En vez de hablar con los usuarios de negocio finales eliges interlocutores de alto nivel, expertos o consultores que te resumen las necesidades de los usuarios.”

Podemos resumirlo con un “que no te lo cuenten”. Una de las habilidades que tienen que tener los que se dedican a diseñar datawarehouses es la de saber escuchar a los usuarios finales, a los que trabajan con la información y toman decisiones, sean directivos o no. Estos siempre tienen razón, ya que son el músculo que hace avanzar a esa parte de la empresa. Nuestro éxito está directamente ligado a que ellos puedan usar de manera eficiente el modelo de información que les estamos desarrollando. No ignores a los usuarios finales, ábrete paso entre supuestos expertos o jefecillos y lábrate una buena relación con los currelas, verás como merece la pena.

Y con esto termina la serie de los diez errores que recoge el libro de Kimball sobre diseño de datawarehouse. La verdad es que hay algunos obvios, pero otros no tanto, que seguro que merecen una reflexión.

Espero que os hayan servido y os animo a aportar vuestra visión del tema dejando un comentario.

 

Los 10 errores que debes evitar al diseñar un datawarehouse (1 de 2)

Este libro es un must-read

Durante las vacaciones estoy releyendo a “los clásicos” de los cuales mi favorito es el por todos conocido libro de Ralph Kimball “The Datawarehouse Toolkit (2nd edition)” el cual sinceramente es una joya para todos a los que nos gusta el tema del datawarehousing y el diseño dimensional.

(Tiempo de lectura: 2 minutos)

En una parte de este libro se enumeran los 10 errores garrafales que debemos evitar a la hora de planear y diseñar un datawarehouse.  Hay algunos que los he podido comprobar en proyectos, y ciertamente si te encuentras con uno de estos merece la pena parar las máquinas, echar un paso atrás, y replantearse la situación.

Recojo en esta entrada del blog los 10 errores que no deben cometerse al diseñar un datawarehouse, en el orden propuesto, con la intención de, por una parte traducirlos al español y por otra parte comentarlos un poco.

P.S. Una vez terminado el artículo me he dado cuenta de que es demasiado largo (otra vez), así que voy partirlo en dos para hacerlo más digerible. Por lo tanto aquí van los cinco primeros errores y en el siguiente post terminaremos con los cinco últimos :)

De menor a mayor importancia:

Error nº 10:Aceptar la premisa de que aquellos quienes son responsables de los principales sistemas operacionales son muy importantes y están muy ocupados para pasar tiempo con el equipo del datawarehouse.  Seguramente ellos no van a querer modificar sus procedimientos operacionales para que la información trascienda al datawarehouse”.

Efectivamente, es un error cometer dicha suposición. Si la organización entiende y valora el papel que desempeñará el datawarehouse, los sistemas operacionales y sus responsables deberán cooperar con el equipo de datawarehouse. Desde luego si encontramos problemas en la relación con el actual equipo de IT de la empresa y estos problemas no son atajados de raíz por parte de la dirección, mal empezamos.

Error nº 9: “Una vez se ha desplegado el datawarehouse, sólo se realizarán comunicaciones a los usuarios finales si el presupuesto aún alcanza”.

Si hemos conseguido llegar hasta aquí,  ignorar a los usuarios finales (que son a quienes les hemos montado el tinglado) sería un gran error. De hecho, no sólo hay que “comunicarlo” si no que debemos realizar talleres, demostraciones, proporcionarles documentación, soporte… lo que sea necesario para una mejor aceptación del proyecto.

Error nº 8: “Llevar al equipo de datawarehouse a unas oficinas separadas de los usuarios de negocio y limitar su interacción con ellos a través de un número de teléfono de soporte”

Mientras dure el proyecto de implantación del datawarehouse, los técnicos deben trabajar físicamente junto a los usuarios de negocio. Durante esos días el equipo de datawarehouse deberá ganarse la credibilidad de los usuarios para lograr la máxima cooperación. Cuanto más inmersivo sea el trabajo del equipo técnico, más fácil será que comprendan los entresijos de esa actividad empresarial.  Y desde luego esto no se consigue apartándolos y minimizando el contacto con los usuarios.

Error nº 7: “Entrenar a los usuarios en todas las funcionalidades de la herramienta de acceso a datos con información de prueba (la información productiva aún no está lista) y declarar que ha sido un éxito pues el datawarehouse ya está desplegado”

Realizar formaciones tempranas es tentador, ya que da la sensación de que el proyecto está muy avanzado. De hecho, una vez la estructura de la información está lista ya podríamos comenzar a entrenar a los usuarios utilizando información “de mentira” mientras se terminan de poner en marcha los complicados procesos ETL que cargarán el datawarehouse.  Esto es un error. Debemos entrenar a los usuarios con clases frecuentes pero cortas, centrándonos no sólo en la herramienta de acceso a datos (que al final se aprende por costumbre) sino en la semántica de la información que alberga el datawarehouse. El libro de Kimball dice que podremos apuntarnos el tanto si seis meses después de que el datawarehouse ha sido desplegado los usuarios lo siguen utilizando.

Error nº 6: “Asumir que los usuarios de negocio comenzarán a desarrollar sus propias aplicaciones analíticas en cuanto el datawarehouse esté en marcha”

Si bien es cierto que uno de los objetivos de implantar un datawarehouse es que los usuarios tengan la oportunidad de desarrollar (mediante herramientas de acceso a los datos) sus propios análisis, esto no es algo que pase de la noche a la mañana. Los usuarios tienen primero que ver demostrado el potencial de la información que tienen a su disposición a través de análisis realizados previamente por el equipo de datawarehouse. Si estos primeros informes dan en el clavo (son relevantes, interesantes, fáciles de entender…) despertarán automáticamente en los usuarios su inagotable sed de “dame más información”. Ese es un gran momento para introducir formación sobre la herramienta de acceso a datos y esperar a que nuestros usuarios no sean unos negados con los ordenadores.

Y de momento, para no hacerlo muy pesado, lo dejamos aquí. En la próxima entrada terminaremos con los cinco errores que faltan. Os animo a comentar lo dicho hasta ahora usando los comentarios :)

 

Modelando dimensiones lentamente cambiantes con Oracle Data Integrator

En el post anterior vimos una introducción a las dimensiones lentamente cambiantes (SCD) y una forma de implementarlas en la herramienta OBIEE utilizando timestamps.

Si echamos un paso atrás, antes de preparar un modelo de datos en OBIEE posiblemente habremos tenido que preparar un modelo dimensional y alimentarlo desde los sistemas transacionales.

En esta entrada vamos a ver un caso de estudio muy muy simple sobre como modelar una dimensión de empleados con un atributo SCD tipo 2 utilizando la herramienta Oracle Data Integrator.

(Tiempo de lectura: 10 minutos)

Caso de estudio – Crear la dimensión de empleados

Supongamos que nuestro origen de datos es la clásica tabla EMPLOYEES que viene en el esquema HR en cualquier instalación de una base de datos de Oracle. A continuación tenéis la estructura de la tabla.

Nuestro origen de datos

Nuestro origen de datos

Para simplificar, vamos a suponer que en nuestra dimensión lo que nos interesa es tener el identificador del empleado (EMPLOYEE_ID), su nombre (FIRST_NAME), su apellido (LAST_NAME) y para darle un poco más de gracia, el nombre completo de su manager (FIRST_NAME + LAST_NAME a partir de MANAGER_ID).

De los tres atributos que tenemos en la dimensión, supondremos que el nombre y el apellido son considerados SCD de tipo 1, es decir, que si se produce un cambio en la tabla transaccional sobrescribiremos el dato en el modelo dimensional.

Por otra parte, consideramos el manager como SCD de tipo 2. Es más que posible que si un empleado cambia de manager nos interese guardar este cambio en nuestro datawarehouse. En el sistema transaccional los compañeros de RRHH simplemente actualizarán el campo MANAGER_ID para que apunte al nuevo manager, pero es tarea de los procesos de carga de datos al datawarehouse percatarse de este cambio y actuar en consecuencia para poder reflejar la historia de ese empleado de forma fidedigna.

Por lo tanto, y siguiendo las enseñanzas de Ralph Kimball, sabemos que necesitamos una serie de atributos adicionales en nuestra tabla dimensional si queremos modelar la SCD de tipo 2.

Añadiremos pues:

  • Una clave subrogada que nos permitirá tener varias versiones para la clave natural que en este caso es EMPLOYEE_ID
  • Un par de campos fecha para marcar la validez temporal de cada versión de un empleado
  • Un campo numérico (1/0) que marque el último registro modificado.

Efectivamente, únicamente con la clave subrogada es suficiente para modelar un SCD de tipo 2. Pero la herramienta ODI necesita que existan tanto las fechas como el registro de validez para poder funcionar (al menos usando el KM por defecto para SCD).

En la siguiente imagen podéis ver como queda nuestra tabla dimensional que será el destino de nuestro proceso de carga de datos.

Destino de datos

En azul se muestra la clave subrogada y en rojo el atributo que consideramos tipo 2

De esta forma, nuestro interfaz ODI se encargará de realizar dos tareas:

  • Realizar la primera carga de datos que mueva los empleados desde la tabla EMPLOYEE a DIM_EMPLOYEE, asignando la clave subrogada de forma secuencial. La fecha de validez inicial recibirá el valor de tiempo actual y la fecha de fin de validez la pondrá en enero del 2400.
  • Cada ejecución posterior después de la primera buscará cambios en el campo MANAGER_ID, y en el caso de encontrarlos creará una nueva versión de ese empleado en DIM_EMPLOYEE gestionando la clave subrogada, las fechas de inicio y fin y el campo de validez.

A partir de aquí describimos como realizar este interfaz con ODI 11g. Si no has trabajado con la herramienta te sonará a chino, pero si te has acercado alguna vez a ella verás que es muy sencillo modelar SCD de tipo 2 utilizando los KM necesarios.

Creación de un Interfaz que gestione SCD tipo 2 con ODI 11g

Voy a suponer que ya tenemos creadas nuestras conexiones al repositorio de trabajo y que nuestro entorno ODI está funcionando.

Crearemos un nuevo proyecto y preparamos la topología física y lógica en tecnología Oracle, ya que tanto nuestro origen como nuestro destino de datos son tablas en esta base de datos. En este caso hay que crear las conexiones al esquema HR, no creamos ningún agente standalone ya que únicamente vamos a realizar una prueba de concepto, usaremos el agente local.

Antes de continuar importaremos los KM necesarios, en nuestro caso necesitaremos dos:

  • Módulo de integración – IKM Oracle slowly changing dimension
  • Módulo de comprobación – CKM Oracle

El módulo de comprobación es necesario para evitar algunos errores en la ejecución del interfaz, pero realmente no vamos a realizar control de flujo.

Una vez creadas las tipologías e importados los KM, crearemos el modelo de datos mediante la opción de ingeniería inversa sobre el esquema HR. Esto debería de traernos tanto nuestra tabla de origen (EMPLOYEE) como nuestra tabla de destino de datos (DIM_EMPLOYEE) y también el resto de tablas del esquema HR (que podemos suprimir del modelo).

En este punto tendremos que configurar el comportamiento de las columnas de nuestra tabla destino para que ODI sepa modelar el comportamiento de la SCD. Para eso, haremos doble clic en una columna, y en su pestaña “Descripción” elegiremos la opción adecuada tal y como muestra esta tabla:

SCD2

Asociamos a cada columna su comportamiento SCD según la tabla de al lado.

Campo Comportamiento SCD
EMPLOYEE_SUB_KEY Clave de substitución
EMPLOYEE_ID Clave natural
FIRST_NAME Sobrescribir en caso de cambios
LAST_NAME Sobrescribir en caso de cambios
MANAGER_NAME Añadir nueva fila en caso de cambios
START_DATE Registro hora de comienzo
END_DATE Registro hora de finalización
CURRENT_VALID Indicador de registro actual

No hay sorpresas aquí, cada uno de los campos tiene una misión. En el caso de los atributos de nuestra dimensión elegimos los de tipo 1 con la opción de sobrescribir y los de tipo 2 con la opción de añadir una nueva fila.

Como en su momento creamos la tabla DIM_EMPLOYEES sin una clave, vamos a crear ahora una constraint lógica en el modelo de ODI. Para ello en la sección correspondiente creamos una nueva clave y la asociamos a la columna de la clave subrogada (que es nuestra PK real para la tabla dimensional).

creación clave primaria

Creamos una nueva restricción como clave primaria, en las columnas seleccionamos la clave subrogada de nuestra tabla destino

Antes de comenzar con el interfaz necesitaremos crear en ODI una secuencia para nuestra clave subrogada. La secuencia ya la hemos generado antes en la base de datos, así que sólo tenemos que crear una secuencia y configurarla como nativa y seleccionarla en el esquema HR.

Creación secuencia

Definimos una secuencia a nivel de proyecto que mapeamos a una secuencia nativa de base de datos

Pues ahora si que lo tenemos todo, estamos listos para crear un nuevo interfaz y realizar los mapeos necesarios. Veamos como hacerlo.

Primero creamos el interfaz y le damos un nombre

 

El interfaz es el objeto ODI que se ejecuta para realizar los movimientos de datos

En la pantalla de edición arrastramos como origen de datos la tabla EMPLOYEE, pero ojo, como necesitamos obtener el nombre del manager para un usuario dado, necesitaremos arrastrarla dos veces para modelar el outer join. Automáticamente nos creará un par de uniones (imagino que derivadas del sufijo ID). En nuestro caso necesitamos únicamente la relación MANAGER_ID = EMPLOYEE_ID y además de forma que se obtengan todas las filas de la primera tabla (left outer join) ya que de lo contrario nos dejaremos fuera al CEO de la empresa que tiene el campo MANAGER_ID = NULL. Tiene que quedar de la siguiente manera

 

origen de datos

Fijaros como marcamos la unión como left-outer para recuperar las filas con MANAGER_ID = NULL

Una vez creado nuestro origen de datos, vamos a añadir el almacén de destino, arrastrando a la parte derecha la tabla DIM_EMPLOYEE, cuando nos pregunte si queremos realizar un mapeo por defecto le decimos que no.

El mapeo de los campos es bastante directo, sólo hay que tener en cuenta lo siguiente:

  • La clave subrogada EMPLOYEE_SUB_KEY ha de mapearse a la secuencia que hemos creado antes.
  • Los campos de START_DATE, END_DATE, y CURRENT_VALID han de tener un valor inicia, pero este valor será ignorado por el KM que gestiona las SCD, así que a las fechas les asignamos SYSDATE y al campo CURRENT_VALID un “1”, por ejemplo.

Quedaría tal y como muestra la siguiente imagen

almacen_destino

Fíjate como utilizamos la función NVL2 para tratar el caso del empleado que tiene MANAGER_ID = NULL. En ese caso le asignamos la cadena 'CEO'

Si pulsamos la pestaña “Flujo” veremos una representación de nuestro proceso de carga de datos. En caso de que no se haya seleccionado fijaremos el IKM del interfaz. Los valores del IKM los podemos tunear un poco para evitar truncates y comprobaciones varias. El dibujo para esta carga tan sencilla queda así:

En la pestaña de “Controles” seleccionaremos el CKM que hemos importado al principio, por defecto realizará comprobaciones basadas en la PK que creamos para la columna EMPLOYEE_SUB_KEY. Podemos desactivarla si queremos para ahorrarnos pasos de ejecución.

Guardamos todo y ejecutamos, si todo va ok, podremos observar que nuestra tabla de destino se ha cargado con 107 filas (las mismas que tenía la tabla origen) y que todos los empleados tienen el nombre de su manager bien colocado.

También observamos como la secuencia ha generado ID’s correlativos para la clave subrogada y como ha rellenado las fechas y el registro de validez. Genial no? :)

select_sobre_dim_employee

El proceso funciona estupendamente en la primera carga.

Ahora la prueba de fuego. ¿Qué pasa si realizamos un update sobre el campo MANAGER_ID en la tabla origen de datos? El manager del empleado 103 era el 102. Vamos a cambiarlo al 101, o sea Neena Kotchhar.

UPDATE EMPLOYEE SET MANAGER_ID = 101 WHERE EMPLOYEE_ID = 103;
1 ROW updated

Si volvemos a ejecutar el interfaz y consultamos la tabla para el usuario que acabamos de modificar, nos encontramos que ODI ha gestionado correctamente la dimensión, creando una nueva fila con un nuevo valor para su clave subrogada y asignando correctamente el nuevo manager. ¡Prueba superada!

Comportamiento correcto de una SCD tipo 2

Hemos visto como modelar satisfactoriamente el comportamiento de las dimensiones lentamente cambiantes de tipo 2 utilizando ODI. Tengo que decir que es la primera vez que usaba esta herramienta y puede ser un poco compleja de poner en marcha, pero me ha gustado mucho y creo que tiene un gran potencial, seguiré leyendo documentación y probando cosas con ella.

Si estás interesado en comenzar a utilizar ODI te recomiendo que realices la serie de OBE para ODI 11g (aquí), que sin duda te ayudarán a comenzar con la herramienta :)

Dimensiones lentamente cambiantes en OBIEE

chuck_norris

Chuck Norris hace que las dimensiones lentamente cambiantes dejen de cambiar

La propia naturaleza del modelado dimensional hace que necesitemos las medidas para dar sentido a los hechos . Un dato de ventas no significa nada si no podemos ponerlo en el contexto del tiempo,  de los productos, o de las delegaciones.

Sin embargo, hay un enemigo que acecha entre las sombras y que si no es tratado con antelación puede provocar más de un quebradero de cabeza en los desarrolladores. Son las dimensiones lentamente cambiantes (SCD) de las cuales hablaremos hoy.

(tiempo de lectura: 4 minutos)

Para centrarnos, pongamos un ejemplo sencillo.

Una empresa tiene una estructura comercial en la que los clientes tienen asociado un representante que se encarga de visitarlos y comerles el tarro para que compren. Dicho así podríamos ver las ventas de la empresa como una tabla de hechos (facts) y los clientes como una de las dimensiones (measures) en la que el representante comercial es un atributo del cliente.

El representante comercial, aunque no de forma frecuente, puede cambiar por varios motivos (el cliente se marcha a otro lugar, el actual representante causa baja en la empresa…) y la pregunta es clara. ¿Qué hacemos con el atributo “representante” de la tabla de clientes? Las diferentes opciones que se plantean definen los tipos de dimensiones lentamente cambiantes.

  • Tipo 1: Sobrescribimos y aquí no ha pasado nada. Este tipo de SCD es la más sencilla pero no siempre puede utilizarse. Si no es necesario mantener una historia del atributo entonces hablamos de una SCD tipo 1.
  • Tipo 2: De alguna manera hay que conservar una relación histórica de los cambios para este atributo ya que es importante para el análisis de la información.

En este ejemplo, el “representante comercial” de un cliente es una clara SCD de tipo 2, ya que si no mantuviéramos una historia de los cambios en este atributo, nuestra información de “ventas por representante” no sería fidedigna, al asociar todas las ventas históricas al último representante vigente (cosa que al resto de representantes no les iba a gustar…)

Tenemos varias formas de lidiar con este tipo de dimensiones lentamente cambiantes.

Método 1 

Usar timestamps

Modificamos la tabla de dimensión con un par de campos fecha (start y end). De manera que cada vez que cambia la información de una entidad de esa dimensión, añadimos un nuevo registro a la tabla con las fechas adecuadas. Estas fechas pasaran a formar parte de la clave única de la tabla para poder diferenciar los registros. A la hora de consultar la información, cada registro de hechos habrá de tener su campo de fecha de realización, que lo usaremos en el join para poder delimitar a que versión de la entidad pertenece esa información.
Método 2 

Usar claves subrogadas (SK)

En este método nos olvidamos de las fechas y lo que hacemos es añadir una nueva clave artificial o subrogada en la tabla de dimensiones. Esta clave es una secuencia sin significado generada por el sistema y nos sirve para determinar registros de forma única. En nuestra tabla de hechos tendremos que añadir una nueva columna para guardar el mismo valor de secuencia como FK de la tabla de dimensión. 

Generalmente esta aproximación es realizada de forma interna por las herramientas que realizan los procesos ETL en nuestros datos, de forma que ellas mismas detectan cambios en las dimensiones y se encargan de general estas claves subrogadas tanto en dimensiones como en hechos. ¿Mola verdad?

 

Ejemplo – Implementar SCD tipo 2 (método 1) en OBIEE

Vamos a ver rápidamente como implementaríamos el ejemplo anterior usando el método 1 en OBIEE.

Supongamos la siguiente estructura de tablas en nuestro modelo físico de información. Fijaos en que ya hemos definido las columnas fecha para el cliente y para los registros de las ventas. Estas columnas nos permitirán implementar la lógica de una SCD tipo 2.

 

modelo físico de la información

Importamos las tablas y creamos las uniones

Al pasar al modelado lógico aprovecharemos la capacidad de crear LTS para obtener un esquema estrella de nuestro modelo en 3NF. En este caso es muy sencillo ya que únicamente convertiremos las entidades de CLIENTES y REPRESENTANTES en una única dimensión de las ventas que contendrá toda la información.

modelo lógico de la información

Fusionamos representantes y clientes en una única tabla lógica

Para modelar la lógica de la SCD haremos un nuevo origen de datos lógico en la tabla ventas y añadiremos la tabla de clientes, que automáticamente se unirá a la de ventas a través del join que definimos en la parte física.

A continuación iremos a la pestaña “Contenido” y en la parte del where modelaremos la condición de las fechas utilizando el operador BETWEEN y las fechas de venta y de clientes. De esta forma, cada vez que se recupere un registro de ventas, el motor de OBIEE le asignará su correspondiente registro en la dimensión de clientes, y por tanto el representante correcto.

lógica SCD tipo 2

Añadimos la tabla de clientes y en la pestaña de contenido modelamos la condición del where para filtrar por la fecha de venta

Conclusión – No ignores a las SCD.

Hay varias formas de gestionar las dimensiones lentamente cambiantes, lo importante es que desde el principio se identifiquen aquellos atributos susceptibles de ser tratados como SCD. El verdadero riesgo reside en no tener en cuenta este tipo de comportamientos hasta que el sistema está funcionando, ya que requerirán modificaciones estructurales de las tablas y cambios en los procesos ETL.

En próximos post analizaremos como utilizar el método 2  (usar claves subrogadas) utilizando la herramienta Oracle Data Integrator de manera transparente al desarrollador.

Una historia sobre el origen de OBIEE

OBIEE_timeline

Chuleta para no perderse en el juego de tronos de Oracle

Hace no mucho tiempo encontré una entrada muy interesante en el blog de Rittman Mead Consulting que todo buen aficionado a OBIEE debería conocer. En esta entrada el señor Mark Rittman repasa los orígenes de la plataforma Oracle Business Intelligence. Todos sabemos que Oracle va comprando a diestro y siniestro compañías y absorbiendo sus productos, pero… ¿Cómo llegaron a crear OBI?

He pedido permiso al autor de esta entrada para traducirla al castellano y reproducirla en mi blog, así que un pequeño disclaimer y empezamos ;)

Disclaimer
Los contenidos de esta entrada han sido traducidos al castellano a partir de esta otra entrada que fue escrita por Mark Rittman para el blog de Rittman Mead Consulting y toda la información que se presenta a continuación debe se atribuida exclusivamente a él.
The contents of this post have been translated into spanish from another original post written by mr Mark Rittman from Rittman Mead Consulting and all the following information should be atributed exclusively to him.

Vamos con el artículo :) (tiempo de lectura 5 minutos)

Una historia sobre Oracle Bi Suite Enterprise Edition (fecha de publicación 18 Septiembre 2007) por Mark Rittman

He estado investigando un poco sobre la historia de las herramientas de BI de Oracle y en particular cual es la historia de OBIEE, previamente conocida como Siebel Analytics. Os voy a contar lo que he averiguado, aunque obviamente hay que entender que yo no estaba por aquí en aquel tiempo, y no trabajé para nQquire, Siebel u Oracle, así que cualquier colaboración que pueda ayudar a ampliar la información es bienvenida.

La mayoría de la gente sabe que OBIEE era originalmente conocida como Siebel Analytics, y fue adquirida por Oracle como parte de la compra de Siebel al final de 2005. A principios de 2006 Oracle celebró una rueda de prensa en Nueva York y afirmó que su futura estrategia en lo que a herramientas de BI se refiere iba a girar en torno a una aplicación que denominaron ya Oracle BI Suite Enterprise Edition, que inicialmente era más o menos Siebel Analytics en su versión 7.8 y que en futuras versiones irían completando con cada vez más tecnología Oracle. Por ejemplo, OBIEE 10.1.3.2 incluyó OC4J como el servidor de aplicaciones por defecto y BI Publisher como reemplazo de Actuate y en la versión 10.1.3.3 ya podemos ver una interfaz entre BI Publisher y Discover y nuevos plugins de conexión con Microsft Office. Y se dice que la siguiente versión 10.1.3.3.1 habrá una integración entre BI Server y Essbase, el servidor OLAP que es parte de Hyperion System 9 (N d T. Efectivamente así fue, en 10.1.3.3.1 se ofreció la posibilidad de conectar Essbase con OBIEE)

Sin embargo, Siebel no desarrolló su producto Siebel Analytics, ese honor recaería en otra compañía llamada nQuire, quienes desarrollaron la tecnología que al final llegaría componer Siebel Analytics a finales de los 90.

nQuire se montó por parte de un número de ex-trabajadores y jefes de producto de Platinum, liderados por Larry Barbetta, quien se unió a Platinum cuando su compañía Prodea fue comprada en 1995 y dejó Platinum cuando esta fue a su vez comprada por Computer Associates. La gente de nQuire, siguiendo las tendencias del momento, se centro en una línea de producto (el nQuire Server Suite 1.0) con la que pretendían crear un “buscador universal para información estructurada” emulando otras compañías como Iktomi, que fueron los que crearon los motores de búsqueda da la propia Yahoo (N d T. nota de presa de Networld World del 30 de Agosto de 1999 anunciando nQuire Server Suite)

La versión inicial de nQuire Server  Suite 1.0, aunque efectivamente se centraba en búsquedas, ya tenía muchas funcionalidades que ahora reconoceríamos en OBIEE. Por ejemplo, nQuire Server sería el predecesor del componente BI Server, y ya proporcionaba una capa de metadatos sobre fuentes de datos dispersas junto con un sistema de caché, cálculos agregados, etc. Sus adaptadores de datos ya incluían a Oracle , SQL Server, otras bases de datos relacionales y documentos XML. En realidad, aunque en su fachada era un buscador de información, no dejaba de ser un servidor ROLAP contra diversas fuentes de datos. (N d T. Hablamos de la primera mitad de 1999 y este software ya costaba 125,000$, ojo con el tema…)

No será hasta la versión 2.0 de nQuire Server cuando veamos verdaderas capacidades de consulta y reporting. En aquel momento nQuire consideraba ya a empresas como Microstrategy, Documentum y Cohera como su competencia, reflejando el interés que había en esos tiempos en torno a las búsquedas sobre datos estructurados y desestructurados. Sin embargo la posibilidad de tener ya esa capa de metadatos unificada sobre todas las fuentes de datos estructuradas de una organización otorgaban una ventaja competitiva al producto de nQuire, y lo hacía tan sencillo de usar como lo eran Yahoo o Ask Jeeves.

A continuación podemos ver un pantallazo de como lucía la versión 1.0 de nQuire Portal Templates con datos obtenidos por el nQuire Server.

nquire_portal_templates

nQuire Suite con portal templates

 

En la versión 2.0 de nQuire Suite (del año 2000) se introdujo como novedad nQuire Answers, que efectivamente fue el predecesor de Oracle Answers, con muchas de las funcionalidades con las que hoy estamos familiarizados y manteniendo un gran énfasis en poder responder consultas en inglés. Por lo que parece, en su versión inicial podías proponer preguntas en inglés normal, como por ejemplo “What were the sales for the eastern region in the first quarter” y Answers devolvería una tabla con esos datos (no es algo que yo haya visto, y posiblemente esa funcionalidad se perdería cuando Siebel compró nQuire). Tanto la versión 2.0 como la 1.0 corrían exclusivamente en servidores windows NT y windows 2000. Su precio era de $125K por una licencia o $8K de subscripción mensual y por lo que hemos visto en la captura de pantalla tenía la posibilidad de crear dashboards  y portales en función a unas plantillas de datos que procedían de nQuire Answers, un claro predecesor de lo que más tarde sería Oracle Interactive Dashboards.

En febrero de 2001 aparece la versión 3.0 de nQuire Suite, que introduce nQuire Delivers (predecesor de Oracle Delivers) que proporcionaba la posibilidad de crear alertas, iBots, distribución de informes y con una asombrosa funcionalidad que permitía a la versión 3.0 de Answers con un interfaz de voz, permitiendo obtener datos y respuestas a partir de consultas efectuadas por teléfono (y presumiblemente esta funcionalidad también se perdió cuando Siebel compró nQuire) (N d T. ¡Se cargaron todo lo bueno!) . Por último, en el nQuire Server se añadieron características dinámicas y segmentación en base a hechos (Siebel Marketing?), operaciones analíticas basadas en conjuntos de datos y métricas operacionales. Esta versión del servidor se ofrecía en dos versiones, Data Warehouse o Real-Time.

La siguiente captura de pantalla muestra lo que creemos que es nQuire Answers 3.0 embebido en lo que se denominaba un “Intelligence Portal”. En esta ocasión ya se ve claramente que es el predecesor de Oracle Interactiva Dashboards.

nquire_answers

nQuire 3.0 con nQuire Answers

En Octubre de 2001, Siebel compró nQuire (N d T. por una cantidad desconocida), y lanzó la nQuire Suite como Siebel Analytics, posicionándolo como la tecnología BI que había que utilizar junto a Siebel CRM 7 y cambiando ese punto de vista original de herramienta para búsqueda a herramienta para análisis pero manteniendo como núcleo el avanzado (y visionario) sistema del nQuire Analytic Server. A partir de ahí el equipo de Siebel trabajó junto a el equipo de nQuire para mejorar el producto y completarlo con Siebel Financial Analytics, Siebel Workforce Analytics, etc…

siebel_callcentre_analytics

Siebel Analytics ya se parece mucho al actual OBIEE

Es interesante el hecho de que este paquete de Siebel Analytics usara una plataforma data warehouse cuyo proveedor era Informatica, de ahí que Informática fuera la solución ETL que servía Siebel con sus aplicaciones. Más tarde Oracle y Siebel fusionarían la tecnología CRM data warehouse para producir una versión unificada que se convertiría en lo que ahora llamamos Oracle BI Applications.

Aquí termina el artículo de Mark Rittman, voy a completar un poco la historia en base a una pequeña investigación que he realizado.

Nos quedamos en que Siebel termina comprando nQuire en 2001 y saca al mercado su versión Siebel Analytics, ¿Qué paso a continuación?

El 12 de Septiembre de 2005 Oracle compra Siebel Systems por $5.8 billion. Su objetivo es claro, tras la marcha del CEO de Siebel Mike Lawrie en abril de ese mismo año, Oracle quiere eliminar competencia y adquirir de golpe una tecnología CRM que se convertirá en uno de los ejes centrales en su estrategia Business Intelligence.

A pesar de que estemos hablando todo el rato de Siebel, no hay que perder de vista que en Enero de 2005 (antes de comprar Siebel) Oracle saco de la billetera $10.3 billions para comprar PeopleSoft en una batalla de negociaciones que duró 18 meses en la que por el camino la gente de PeopleSoft compró J.D. Edwards, de forma que Oracle finalmente se quedó con los dos mercados.

PeopleSoft-Logo

Oracle compra Peoplesoft por 10 billones de dolares

PeopleSoft tenía su propio producto de CRM, el cual se complementó con funcionalidad ERP de JD Edwards (derivando en el JD Edwards EnterpriseOne), y toda esta tecnología combinada que se quedó Oracle fue a parar a una nueva línea de negocio, llamada Fusion Applications. Lo de fusión es muy acertado…

Y si, desde 2005 hasta 2010 Oracle estuvo “fusionando” esa amalgama de tecnologías que había comprado a precio de oro para dar a luz a sus famosas BI apps, cuyo porfolio de aplicaciones cubren el sector financiero, recursos humanos, CRM, cadena de suministro, compras, gestión y administración, etc…

Y de momento hasta ahí llega la historia, la próxima vez que inicies sesión en OBIEE acuérdate de los ingenieros de nQuire, Siebel, PeopleSoft y JD Edwards, por que estás usando sus ideas, a pesar de que ponga “Powered by Oracle” en el pie de página.