 Antonio Rivas  29/04/12 Hace un par de semanas tuve la oportunidad de asistir a uno de los pocos eventos sobre Exalytics que Oracle realiza para partners. La formación duró tres días y tuvo lugar en Utrecht (Holanda) en el fabuloso edificio de Oracle a las afueras de la ciudad. Como es habitual, la organización y las facilidades que Oracle pone al servicio de sus partners para este tipo de acciones formativas fueron espectaculares. Gracias por hacerlo posible.
En esta entrada me gustaría comentar con todos vosotros los principales puntos que allí se trataron y algunas de las conclusiones a las que llegamos. Pero antes de empezar, voy a introduciros a este particular miembro de la familia EXA de Oracle, la máquina Exalytics.
Exalytics es el nombre de un sistema combinado de hardware y software desarrollado por ingenieros de Oracle y pensado para ejecutar sus aplicaciones analíticas (OBIEE) con muy bajos tiempos de latencia. Para lograrlo, se apoya fundamentalmente en el paradigma “in-memory” que consiste en almacenar grandes volúmenes de datos en RAM para evitar el acceso a los discos y ser capaz de esta forma de devolver muy rapidamente la información solicitada al usuario.
Evidentemente, el cacharro es mucho más complejo que esto que acabo de escribir, pero la idea fundamental es esa. Al final del artículo tenéis unos cuantos links para ampliar la información técnica sobre la máquina.
Tenía algunas esperanzas puestas en poder ver una de las máquinas en Utrecht, pero desgraciadamente no disponían del hardware allí, así que tuvimos que realizar todos los talleres en un entorno simulado utilizando una máquina virtual. De esta forma no pudimos hacernos una idea de la mejora real en velocidad que ofrece Exalytics, pero por lo menos si pudimos probar de primera mano algunas de las características que ofrece el sistema.
Para hacer esta entrada un poco más amena, voy a relatar lo aprendido y las conclusiones en siete puntos rapiditos, que si no sé que os aburrís.
1º – Exalytics no sólo es hardware, también es software
Lo primero que llama la atención de Exalytics es su potente hardware, sin embargo conviene recordar que existe un software especialmente diseñado para funcionar en esta máquina. Concretamente, tras conectar Exalytics a nuestra red podremos instalar el siguiente software:
- OBIEE Fundation 11.1.1.1.6 especial para exalytics
- TimesTen 11.1.2 con funciones especiales para Exalytics
- Una versión mejorada para la ocasión de Essbase
Como podéis ver, todo el software se ha diseñado (o más bien, retocado…) para poder ofrecer “nuevas funcionalidades” que “sólo funcionan” en Exalytics.
 - Software y hardware unidos!
Algunas de las nuevas características de estas nuevas versiones de Software que sólo deberías ejecutar junto a Exalytics son:
- Para OBIEE: Autocompletado de prompts mientras escribes (como cuando buscas en google), filtros go-less (auto refrescan la pantalla sin pulsar “Go”) y muchas otras cosas. Puedes echar un vistazo a mi post sobre novedades de la versión 11.1.1.6 ya que la mayoría están pensadas par Exalytics.
- Para TimesTen: Básicamente dos cosas. Nuevos operadores analíticos para poder realizar agregaciones complejas en memoria y la compresión columnar. Por la compresión ya merece la pena.
- Para Essbase no se trata tanto de nuevas funcionalidades, pero si un montón de optimizaciones para funcionar mejor con datos en memoria. También ha mejorado mucho el procesamiento el paralelo para aprovechar los 40 cores de Exalytics.
2º – TimesTen el gran protagonista
Cuando tienes entre manos lo que parece un terabyte de RAM, está claro que una base de datos “in-memory” es muy importante para poder aprovechar al máximo esa característica. Y aquí es donde TimesTen brilla con luz propia. Me atrevería a decir que Exalytics no tiene sentido sin TimesTen (pero no lo contrario, ojo) y por tanto saber configurar y administrar esta nueva base de datos es muy importante.
No obstante, TimesTen no es una tecnología nueva (ni mucho menos), así que para su “re estreno” en Exalytics Oracle le ha dotado de dos características nuevas que sólo funcionan para esta máquina. La primera es la habilidad de ejecutar operadores analíticos sobre los datos en memoria (CUBE, GROUPING, WITH..) y la segunda y también muy interesante es la posibilidad de la compresión de datos hasta un factor de 5x en escenarios un poco utópicos que se reduce a un 3x en la mayoría de los casos normales.
Para la ocasión, Oracle nos ha preparado también un nuevo asistente (como no) que nos permite de forma muy sencilla aprovechar la potencia de TimesTen y OBIEE al mismo tiempo. Más sobre esto en unas líneas ;)
3º – El terabyte de RAM más pequeño de la historia
Llega el momento de revelaros una amarga realidad. A pesar de que Exalytics viene con un terabyte de RAM (una cantidad respetable pero no desproporcionada) este ha de ser compartido entre varios tipos de aplicaciones, reduciéndose de esta forma la cantidad de memoria que tenemos para nuestros valiosos datos.
¿Y en cuanto se traduce este robo de bytes? Pues podéis verlo en la siguiente tabla…
 Al final, del tera de RAM solo son usables 400GB O sea, 400GB de RAM para vuestros datos… bien es cierto que como podemos comprimir los datos podríamos estirar estos 400GB hasta el tera de memoria, pero aun así estamos ante una cantidad de memoria no demasiado grande, ya que los DWH de algunas empresas superarán con creces esta cifra. En cualquier caso 400GB de memoria RAM siguen ofreciendo un montón de espacio y muchas empresas tendrán suficiente con eso. Y si te quedas corto siempre te puedes comprar otro Exalytics :P
4º – Rápido y fácil de poner en marcha
Una de las mejores cosas que ofrece Exalytics es su facilidad de puesta en marcha. Una vez compramos la máquina la gente de Oracle vendrá a nuestra empresa y la enchufarán. En función de si hemos comprado el starter pack o no, nos instalarán el software (parcheado) y arrancarán el sistema. Si no tenemos el starter pack tendremos que hacerlo nosotros mismos o contratar los servicios de un Integrador (como ClearPeaks) para instalen y de paso nos migren el repositorio. En cualquier caso estamos hablando de horas/días cuando antes el despliegue de un hardware semejante costaría días/meses.
Piensa que si quieres montar un sistema similar tienes que comprar por una parte los discos, por otra parte los nodos (cpus), por otra parte la refrigeración, estudiar el cableado, montarlo todo en una (o varias) unidades del rack, asegurarte de que tienes todos los interfaces de red… Asegurarte de que todos los componentes están certificados para funcionar conjuntamente… Es un follón.
Con Exalytics lo tienes todo en una unidad que ya tiene todo lo necesario para funcionar y además sabes que todos los componentes han sido elegidos para funcionar conjuntamente, asegurándote una compatibilidad total desde el primer momento.
5º – Mejora en el rendimiento desde el primer día
La forma principal en la que Exalytics mejora el rendimiento de nuestra aplicación de BI es a través de TimesTen. Y lo hace de la siguiente manera:
Una vez que tengamos el nuevo sistema funcionando, podremos ejecutar un nuevo asistente (llamado Summary Advisor) que echará mano de las estadísticas de uso de la aplicación para sugerirnos cuales son las agregaciones más usadas. A continuación, nos generará una serie de scripts que crearán estas agregaciones directamente en TimesTen (es decir, en la memoria RAM) y modificará la estructura del repositorio para que cuando el usuario solicite los datos a esos niveles de agregación se acceda a TimesTen en vez de a la fuente de datos relacional (en disco). De esta forma mejoraremos mucho el rendimiento de la aplicación, pero lo más importante es que esta operación es muy sencilla de realizar (next next next…) y no requiere conocimientos especiales de TimesTen.
Por supuesto, si conocemos nuestro sistema y conocemos TimesTen podemos obviar el asistente y crear nuestros propios cache groups con las tablas a cualquier nivel de agregación que queramos (incluso al detalle) y subirlas a memoria. Luego es cuestión de modificar el RPD y listo. Esta opción posiblemente nos llevará bastante más tiempo que la primera, pero nos dará más control sobre lo que queremos poner en TimesTen.
Lo importante aquí es la capacidad de elección. Podemos utilizar el asistente para poder aprovechar el sistema lo antes posible y a partir de ahí ir mejorando manualmente las agregaciones para ir afinando el rendimiento del sistema.
6º – Entre licencias anda el juego
Uno de los temas que más interesaba a la gente que asistimos al curso fue el tema de las licencias. ¿Cómo se licencia Exalytics? El tema no es muy complicado, pero enseguida veréis que tiene algunas aristas.
Para empezar, si pensamos en adquirir una máquina Exalytics lo primero que tendremos que pagar es el hardware, la máquina en si. Eso son unos 160K $ precio de lista. A partir de aquí hay que licenciar el software, que se divide en dos partes, las licencias de OBIEE Foundation Suite y las de TimesTen. A pesar de que podemos utilizar Exalytics sin tener que utilizar TimesTen, es obligatorio licenciar tantas licencias de TimesTen como las que hayamos licenciado de OBIEE Foundation, y el mínimo de usuarios es 100.
¿Echamos las cuentas? Venga, sobre precios de lista de Marzo de 2012.
|
Elemento
|
Precio Unitario
|
Soporte Unitario
|
Mínimo usuarios
|
Total
|
| Exalytics Box |
135.000$
|
27.000$
|
1
|
162.000$
|
|
OBIEE Foundation suite
|
3.675$
|
808.5$
|
100
|
448.350$
|
| TimesTen |
300$
|
66$
|
100
|
33.600$
|
|
|
|
|
643.950$
|
(Fuente de datos: Lista de precios Oracle Marzo 2012 – Technology & Engineered Systems)
Si alguno está pensando en como queda la tabla licenciando por CPU mejor que se le quite de la cabeza… Da miedo.
Hombre, tened en cuenta que eso son precios DE LISTA, que luego se pueden sacar descuentos muy importantes al hablar con vuestro representante Oracle, así que tampoco se tomen la tabla de arriba como algo definitivo, ni mucho menos. Los precios pueden cambiar sin previo aviso, y lo arriba citado sólo debe de entenderse como una referencia.
¿Caro o barato? Pues imagino que depende de para que lo vayan a usar. Exalytics es una máquina muy potente, y que puede incrementar en varios órdenes de magnitud vuestra actual solución de BI. Si actualmente ya tenéis licencias de OBIEE foundation suite se pueden migrar para ser utilizadas con Exalytics, lo que es bastante interesante.
7º – Pensando a lo grande
Exalytics forma parte de la familia EXA de máquinas de Oracle. Eso significa que ha sido diseñada para funcionar de manera conjunta con sus hermanos mayores, Exadata, Exalogic y el Big Data Appliance. No en vano, Exalytics cuenta con las habituales conexiones de red Infiniband (amen de las ethernet) que permiten tasas de transferencia de 40Gb/s entre máquinas EXA.
Claro, si nos ponemos a añadir máquinas de estas al carro podemos terminar con combinaciones realmente espectaculares. Una de las que más me gustan es la que muestra el siguiente esquema.
¿Impresionante verdad? Todos nuestros datos provenientes de fuentes desectructuradas son capturados y procesados por un bonito array de BigData Appliances que cargan la información ya refinada en Exadata configurado para datawarehousing, y de ahí de nuevo usando infiniband pasamos los datos a la velocidad del sonido para que Exalytics los analice a la velocidad de la luz.
Sobre el papel es precioso. Eso si, ya puedes ir preparando la chequera… :P
Conclusiones
Bueno, no quiero alargarme mucho más. Mi opinión personal tras conocer un poco más de cerca este sistema es que tiene potencial. Nos ofrece una clara mejora del rendimiento a base de juntar un hardware cuidadosamente estudiado con un software que ha sido adaptado para exprimirlo al 150%. En cualquier caso el tiempo nos dirá si este camino que ha tomado Oracle de ofrecer a sus clientes una combinación de hardware y software es una genial idea o una apuesta arriesgada.
Como siempre, estaré encantado de leer vuestros comentarios sobre el tema :)
Antonio Rivas 28/02/12 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 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 :)
Antonio Rivas 19/02/12 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!
Antonio Rivas 27/12/11 ¡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.
Antonio Rivas 17/12/11 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:
Antonio Rivas 08/10/11  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, sí 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 :)
Antonio Rivas 11/09/11 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.
Antonio Rivas 27/08/11  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 :)
Antonio Rivas 19/08/11 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 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.
 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:
 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).
 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.
 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
 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
 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? :)
 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 :)
Antonio Rivas 10/07/11  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.
 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.
 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.
 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.
|
|
