Bienvenidos al video dedicado a Business Intelligence. En esta sesión partiremos de lo anteriormente expuesto sobre bases de datos analíticas, y recuperaremos lo explicado hace un par de semanas para profundizar un poco más en el concepto de Business Intelligence y los principales componentes que lo integran. Recordando lo que comentamos hace unas semanas, las bases de datos analíticas surgen de la necesidad de realizar un análisis efectivo y eficiente de una gran cantidad, una masiva cantidad de datos. Como recordaremos vimos que, el hecho de realizar determinadas operaciones sobre las bases de datos operacionales, las que la empresa utiliza día a día para su funcionamiento, presentan una serie de inconvenientes muy importantes como era la propia interferencia con este sistema, que es un sistema dinámico, que esta interferencia producía una ralentización de todos los procesos y aumentaba la latencia de todos éstos. Además, estábamos obligados a tratar con una fuerte heterogeneidad de fuentes de datos, y esto repercutía en la fiabilidad de estos datos y, además, tenemos que durante el día a día, en un sistema operacional, los datos son volátiles y pueden ser modificados, pueden ser incluso eliminados y esto, obviamente, iba en detrimento de la información que podríamos extraer. Entonces, a partir de esto definimos el Data Warehouse como un gran almacén de datos donde lo que primaba era que los datos que contuviesen, tuvieran una estructura nítida y que, a su vez, este sistema respondiera a cuatro características muy claras. En primer lugar, que fuera un sistema integrado, es decir que tuviera una estructura consistente y homogénea. En segundo lugar, los datos han de estar correctamente categorizados, es decir, el Data Warehouse es una estructura de almacenamiento de datos temática. Los datos también guardan una relación histórica, guardan lo que es la evolución temporal y las tendencias de éstos y, además, el Data Warehouse contiene los datos de manera no volátil, es decir, los datos que han sido introducidos tan sólo serán utilizados para leer, para consultarse, pero jamás serán modificados. De esta manera, también conservaremos la tendencia de la que hablábamos hace un momento. El esquema simple que vimos hace dos semanas, que es este, como es normal en realidad es más complejo y ha ido evolucionando. Aquí, en la posición central, tenemos nuestro Data Warehouse y podíamos observar que este componente tenía una entrada proveniente de lo que denominamos el proceso ETL, y una salida que era la explotación de la propia información. En realidad, muchas organizaciones dividen lo que es el área que ocupa el Data Warehouse en otros componentes, como son en primer lugar los Data Mart. Los Data Mart no son más que subdivisiones del Data Warehouse que pretenden seguir la estrategia de divide y vencerás. De manera que, todos los datos almacenados en el Data Warehouse, son subdivididos en distintos Data Mart, de manera que estos datos contenidos, son más apropiados para atender a líneas de negocios específicas, o a necesidades de departamentos más específicos y diferenciados dentro de un mismo business. Por otro lado, tenemos también el Operational Data Store. El Operational Data Store está al mismo nivel que el Data Warehouse, pero se diferencia en que contiene información que se actualiza de manera mucho más rápida. De hecho, el hecho de que se actualice ya es una diferencia con el propio Data Warehouse, y tampoco mantiene la temporalidad de los datos, no mantiene un histórico. Este Operational Data Store está pensado, en las organizaciones que lo implementan, está pensado para poder tener la capacidad de tomar decisiones tácticas en tiempo casi real. Es decir, ofrece una cierta flexibilidad para poder tomar decisiones cortoplacistas. Finalmente, en este esquema con la agregación de más componentes, al final obtenemos una arquitectura que es conocida como Corporate Information Factory que, como veis, es un poco más compleja y envuelve distintos componentes y pensar también que, dentro de estos componentes, tienen sus propios procesos. En este caso, nos vamos a fijar en dos áreas concretas, una es la de ETL que es un área en la que hemos ido haciendo insistencia cada vez que nos hemos referido a las bases de datos analíticas, y luego nos fijaremos en lo que es conocido como OLAP u On Line Analytical Processing. El proceso ETL, como ya comentamos hace un par de semanas, son la columna vertebral de un sistema de Business Intelligence, sin ellos no existe el Business Intelligence. Como ya vimos, ETL son las siglas de Extract, Transform y Load. Por Extract entendemos todos los procesos relacionados con la obtención de los datos, a partir de las distintas y heterogéneas fuentes. Por Transform entendemos la homogeneización, el filtrado, la categorización, etcétera. Y por Load entendemos el volcado final de los datos en el propio Data Warehouse. Como cada negocio tiene sus particularidades, no existe una única manera concreta de proceder que sea estándar para todos los casos. Lo que sí que generalmente comparten todos los procesos de ETL, es que cada una de estas etapas se ejecutan en modo de pipeline, de manera que cada etapa acostumbra procesar la información que ya había procesado su etapa predecesora en un periodo anterior. De esta manera, aprovechamos al máximo la capacidad de paralización de estas tareas y, también, podemos identificar cuándo es el mejor momento de ejecutarlas, que normalmente viene a ser los periodos de baja actividad de la empresa, si existen. En algunos casos, el orden de este procedimiento es alterado, realizando primero una carga bruta de los datos que han sido extraídos. En este caso, lo que denominábamos Data Warehouse ahora se denomina Data Lake. Esto viene habilitado, principalmente, por las mejoras en los motores de los sistemas gestores de bases de datos. Dado que, actualmente, estos motores nos permiten hacer varias operaciones complejas In Data Base. Estas operaciones involucran transformaciones complejas, podemos hacer minería de datos antes incluso de extraerlos, limpieza automática e, incluso, la aplicación algorítmica de distintas funciones. Esto, lo que nos permite, es no tener que esperar a todo el proceso de transformación que, generalmente, es muy costoso para volcar y disponer de los datos y, de este modo, la transformación se divide en procesos más ligeros y mucho más adaptados a las necesidades de nuestra empresa. Por ejemplo, cada uno de estos procesos podría dar lugar a un diferente Data Mart. Además, el hecho de aplicar la transformación a un solo sistema gestor de base de datos, como sería el que está gestionando el Data Lake, acelera y permite realizar estas funciones de manera óptima. Estos esquemas, obviamente, son dinámicos, no existe un estándar como vengo diciendo y, de hecho, actualmente se están empezando a aplicar metodologías híbridas que combinan ETL con ELT. Esto formaría parte de arquitecturas más complejas denominadas ETLT. El concepto de OLAP que responde a On Line Analytical Processing, está fundamentado en la multidimensionalidad inherente que tienen los datos. Muchos de los inconvenientes a la hora de extraer y analizar la información a partir de bases de datos relacionales, era que los datos en sí presentan una multidimensionalidad muy grande, y la estructura, y la manera en cómo están implementadas las bases de datos relacionales no encaja, precisamente, en esta gran dimensionalidad que nos podemos encontrar, sobre todo cuando hablamos de Big Data. De este modo, el procedimiento de análisis multidimensional de los datos es lo que se conoce como OLAP, como acabo de decir, y una manera de representarlo, gráfica, es lo que se conoce como el El Cubo OLAP. Obviamente, por cuestiones prácticas tan solo a nivel visual, tan sólo podemos representar tres dimensiones. Así que, en realidad, lo que se conoce como cubo OLAP, en realidad es un hipercubo OLAP. Pero bueno ya nos sirve para entender el concepto. Aquí podemos ver este cubo en el que, en cada dimensión, nosotros podemos definir distintas métricas de interés para nuestro negocio. Podemos tener, por ejemplo, en uno de los ejes podemos definir los clientes, el beneficio, unidades vendidas de un producto. En otro eje podemos representar los componentes de este producto, el coste de cada uno de ellos. En otro eje podemos utilizar una métrica por excelencia, que sería el tiempo para darnos ideas sobre las tendencias en nuestro negocio, el precio de venta al público, las zonas geográficas, etcétera. Con el paso de los últimos años, es evidente que el desarrollo de los distintos motores de bases de datos que han tenido en cuenta esta multidimensionalidad y, por lo tanto, la gran mayoría de bases de datos están optimizadas para tratar con nuestros datos. La idea del análisis multidimensional es que a partir de este cubo o hipercubo, nosotros podamos jugar como si se tratase de un cubo de Rubik, de manera que podamos encontrar la combinación de dimensiones, que esto es jugar con los planos o hiperplanos, hasta que demos con la combinación adecuada que nos dé un conjunto de datos que, específicamente nos interesa para un fin concreto. Esto, finalmente, deriva en lo que serían los procesos de planificación, de análisis y de presentación de resultados. Por ejemplo, en este caso en este cubo observamos que queremos obtener los datos relativos al cliente dos durante el mes de agosto, para el producto B. Evidentemente, en este caso este tipo de consultas no nos va a devolver un solo dato, sino un subconjunto de datos con el que trabajaremos y, es por ello, que consideramos que cada consulta en realidad nos devuelve un microcubo dentro de lo que es el hipercubo OLAP. Finalmente, pasamos a la última etapa de lo que sería el Business Intelligence. Esta última etapa es la del análisis y presentación. Como en todo, y como vengo diciendo hasta ahora, cada negocio tiene sus peculiaridades, sus particularidades y, por lo tanto, no hay una manera estándar ni un conjunto de herramientas que se tengan que utilizar sí o sí. Pero, lo importante de esta fase es que tengamos en cuenta que existen tres tipos de analíticas que son la analítica descriptiva, la predictiva y la prescriptiva, que vienen a responder a las preguntas de ¿qué ha sucedido hasta ahora?, ¿qué sucederá? y ¿qué debería hacer?, ¿cómo debería actuar con mi negocio? Esto nos permite, obviamente, extraer una información muy valiosa y, de hecho, la parte final que es con la que trabajaremos, nos permitirá realizar unos informes que sean entendibles por la mayor parte de la audiencia, y todo esto en función de las necesidades y características de nuestro negocio y de nuestros departamentos pues lo podremos realizar, bien con herramientas propias del ecosistema Hadoop como podría ser Spark, o bien con distintas librerías de Machine Learning o Frameworks para el análisis de datos o la visualización de éstos. Con esta sesión hemos realizado un breve recorrido por los componentes del Business Intelligence. Como hemos visto, este concepto engloba todo lo relacionado a la adquisición, manipulación y extracción del conocimiento a partir de los datos para mejorar nuestro negocio, o controlar los procesos de los que se compone. Y, como he acabado de comentar, a partir de las herramientas ya vistas durante el curso, veremos algunas más durante estas próximas semanas, y podremos observar cómo muchas de ellas son aplicables en las distintas fases y etapas de esta arquitectura. Hasta aquí el video de hoy, nos vemos pronto.
