Muchas veces la construcción de un sistema de Data Warehousing / Business Intelligence (DW / BI) se realiza siguiendo el flujo de ingeniería tradicional: análisis, diseño, construcción, pruebas e implantación. La comunicación entre los desarrolladores y la gente interesada del negocio es casi nula, los desarrolladores están interesados en las tecnologías para trabajar con los datos pero descuidan lo más importante de este tipo de sistemas: ¿Qué preguntas del negocio queremos responder con los datos que se dispone para apoyar al proceso de toma de decisiones?
En este artículo hablaré sobre como construir sistemas de DW / BI siguiendo muchas de las prácticas y principios ágiles mencionados en el libro de Ken Collier: Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing.
Sistema de Data Warehousing / Business Intelligence (DW / BI)
Como es conocido un sistema tiene entradas, procesos y salidas.
Considerando este enfoque, las entradas constituyen todas las fuentes de las que requerimos extraer datos. En la gráfica se pueden observar: bases de datos relacionales (RDBMS), archivos CSV, archivos Excel, archivos planos y servicios web (REST/SOAP).
Los procesos de extracción de datos, transformación y carga en un repositorio se conocen como ETLs (Extract, Transform and Load). Permiten mover los datos a un repositorio temporal conocido como Staging y finalmente llevarlos al Data Warehouse.
Un Data Warehouse es un repositorio de datos históricos que constituye la principal fuente para hacer actividades de análisis de datos. El conjunto de actividades que se realizan para mover los datos desde las fuentes hasta el Data Warehouse se conoce como Data Warehousing.
Finalmente, la salida constituye toda la información que se puede obtener del Data Warehouse a través de las diferentes actividades de Business Intelligence.
Un sistema de DW / BI es el resultado de orquestar las actividades de Data Warehousing y Business Intelligence para responder preguntas del negocio y apoyar al proceso de toma de decisiones en una organización.
Manifiesto para Desarrollo de Sistemas de DW / BI
Estamos descubriendo mejores formas de construir sistemas de DW / BI, haciéndolo y ayudando a otros a hacerlo. A través de esto, hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
Sistemas de DW / BI funcionando sobre documentación exhaustiva
Colaboración con los usuarios finales y stakeholders sobre negociación de contratos
Respuesta al cambio sobre seguir un plan detallado
Aunque sabemos que los elementos de la derecha tienen valor, valoramos más los de la izquierda.
Las prácticas ágiles no son prescriptivas, deben ser adaptativas y nos ayudan a cumplir con el objetivo principal de construir sistemas de DW / BI que funcionen, agreguen valor a la organización y sean de alta calidad.
Individuos, interacciones y colaboración
En ocasiones el área de tecnología adquiere herramientas o plataformas para construir sistemas de DW / BI y decide sobre las tecnologías a utilizar, dejando de lado la comprensión del valor de negocio que se quiere conseguir con este tipo de sistemas por parte de los usuarios finales.
El agilismo hace énfasis en la estrecha colaboración entre todos los interesados: administradores, expertos del negocio, desarrolladores, gerentes de proyecto, auspiciantes, consultores, entre otros. Esto permite que se logre un entendimiento común entre todos los interesados, pero ¿cómo lo logramos cuando tenemos restricciones de tiempo y presupuesto?
El desarrollar una incepción antes de comenzar este tipo de proyectos nos puede ayudar a:
- Comprender las preguntas de negocio que se quieren responder con el sistema de DW / BI
- Descubrir las fuentes de datos con las que se cuenta
- Comprender los mecanismos de entrega de información esperados: reportes, tableros de mando, reporteo ad hoc, infografías, etc.
- Capacitar a los interesados del proyecto en fundamentos de ágil y la forma de trabajo
Con el entendimiento de lo que se busca en el sistema de DW / BI, el siguiente paso es priorizar para ajustarnos a las restricciones de tiempo y presupuesto.
Una técnica que se puede usar es escribir historias de usuario con las preguntas de negocio y usar un cuadrante de frecuencia vs. dificultad para priorizarlas.
El cuadrante de mayor frecuencia y mayor dificultad tendrá las historias de usuario con las preguntas de negocio más frecuentes y más complicadas de responder con los datos que se cuenta, éstas historias se las puede considerar como de mayor prioridad y se podrá comenzar a trabajar sobre estas.
El entendimiento común entre todos los involucrados del proyecto requiere de una continua interacción, una excelente comunicación, empoderamiento y sobre todo una estrecha colaboración.
Sistema de DW / BI funcionando
Dentro del agilismo la mejor medida de progreso es ver el sistema de DW / BI funcionando lo más temprano posible, esto se logra dividiendo el trabajo en iteraciones.
Las iteraciones suelen ser de 2 a 4 semanas, y al final de cada iteración se realiza una demostración con los resultados logrados conocida como showcase, pero ¿cómo construimos un sistema de DW / BI usando muchas de las prácticas ágiles?
Antes de comenzar a trabajar en las historias de usuario del sistema de DW / BI, resulta de mucha ayuda comenzar con lo que se conoce como la iteración 0. Esta iteración puede durar de 1 a 2 semanas y tiene como objetivo principal crear todo lo necesario desde el punto de vista técnico para comenzar a construir el sistema de DW / BI, esto incluye:
- Sistema de control de versiones (SCM)
- Aprovisionamiento de ambientes de trabajo: desarrollador (developer sandbox), staging, preproducción y producción con su respectiva instalación y configuración de software base, RDBMS, plataformas y herramientas con las que se trabajará
- Instalación y configuración de un servidor de integración continua
- Instalación y configuración de herramientas de gestión de proyectos ágiles y colaboración
Versionamiento
Es común que en los sistemas de DW / BI se versione muy poco o casi nada, es de muchísima importancia usar un sistema de control de versiones (SCM) para versionar todos los artefactos creados durante el proyecto. Algunos de los SCM Open Source más usados son git, SVN, CVS.
La siguiente estructura base, puede usarse como referencia para versionar los artefactos del proyecto:
Aprovisionamiento de Ambientes
Uno de los factores de éxito del agilismo consiste en la automatización de tareas repetitivas, para que los equipos de desarrollo puedan enfocarse en los temas que agregan valor al sistema de DW / BI.
Con respecto a los ambientes en donde se ejecutará el sistema de DW / BI, consiste en crear código que permite provisionar el sistema operativo, software base, servidor de base de datos, configuraciones, herramientas, etc. Esto usualmente se conoce como IAC (Infrastructure as Code). Ansible es una plataforma que permite crear código en YAML para provisionar los ambientes y trabaja en conjunto con Vagrant que es un gestor de ambientes virtuales.
Para un sistema de DW / BI se pueden manejar 4 ambientes:
- Ambiente del Desarrollador (Developer Sandbox): sobre este ambiente se hace el desarrollo del sistema de DW / BI
- Ambiente de Control de Calidad (QA): sobre este ambiente se integran todos los cambios de los desarrolladores y se hace control de calidad del sistema de DW / BI
- Ambiente de Pre-Producción (PRE-PROD): es un ambiente similar al de Producción, sobre este ambiente se hacen pruebas y demostraciones a los usuarios finales
- Ambiente de Producción (PROD): ambiente de producción del sistema de DW / BI
Una característica importante de Ansible es que el mismo código de infraestructura puede ser usado para provisionar cualquiera de los ambientes (DEV, QA, PRE-PROD, PROD). Además, se logra mantener consistencia de versiones del software usado en todos los ambientes.
El código de infraestructura se lo versiona en el directorio /provisioning mencionado en la sección de versionamiento.
En el siguiente repositorio de GitHub se puede encontrar el código de aprovisionamiento para la plataforma Pentaho CE v5.4 usando el RDBMS PostgreSQL v9.4 y corriendo sobre el sistema operativo CentOS v7.1.
Desarrollo Iterativo / Incremental
Modelamiento Dimensional Evolutivo
Una historia de usuario bien escrita constituye la unidad de trabajo para comenzar a construir y evolucionar el sistema de DW / BI. Suponiendo que se tiene la siguiente historia de usuario:
Como Analista Financiero
Necesito la capacidad de ver el margen de beneficio por año
Para identificar los años menos rentables
En la historia de usuario se puede identificar datos cuantitativos como el margen de beneficio y datos cualitativos como la fecha (año) y se podría tener una primera versión del modelo dimensional, como se muestra a continuación:
Cómo se puede observar, es importante construir el mínimo modelo que satisface la historia de usuario. Una segunda historia de usuario podría decir:
Como Analista Financiero
Necesito la capacidad de ver el margen de beneficio por sucursal y año
Para identificar las sucursales menos rentables
La segunda versión del modelo dimensional incluiría a la dimensión Sucursal, como se muestra a continuación:
Como se puede observar en cada historia de usuario que se trabaja el modelo dimensional evoluciona, ésto se lo conoce como Modelamiento Dimensional Evolutivo.
Para llevar un control de los cambios incrementales en la estructura del modelo dimensional es conveniente usar una herramienta de gestión de cambios de la base de datos. Algunas de las herramientas Open Source más conocidas son Flyway, Liquibase o DBDeploy.
Cada nuevo cambio en la estructura del modelo dimensional es versionado a través de lo que se conoce como un delta o migración, una migración es un archivo con instrucciones SQL nombrado en el formato requerido por la herramienta de gestión de cambios de la base de datos.
Los archivos de migraciones se los versiona en el directorio /db_migrations mencionado en la sección de versionamiento.
La principal ventaja de una herramienta de gestión de cambios de bases de datos es que permite versionar todos los cambios a nivel de estructura, algo que muy pocas veces o casi nunca se hace en este tipo de proyectos. Además, con las migraciones se puede crear el modelo dimensional hasta la última versión en cualquiera de los ambientes: DEV, QA, PRE-PROD, PROD.
Procesos de carga del modelo dimensional
Una vez que se tenga una primera versión del modelo dimensional e identificadas las fuentes de orígenes de datos, se comienza a construir los procesos para cargar el modelo dimensional. Estos procesos comúnmente se los conoce como ETL (Extracción, Transformación y Carga) o de ingesta de datos.
Los procesos ETLs permiten mover, transformar y cargar los datos hacia el repositorio temporal (Staging) y luego hacia el modelo dimensional. Estos procesos pueden ser programados usando algún lenguaje de programación o ser construidos en una herramienta de integración de datos. Algunas herramientas Open Source para construir procesos ETL y realizar actividades de Data Warehousing conocidas son: Pentaho Data Integration, Talend, Jaspersoft ETL.
Es importante que la metadata de los procesos ETLs que se construyan esté basada en archivos para poder versionarlos en el directorio /etls mencionado en la sección de versionamiento.
En los procesos ETL es importante realizar pruebas unitarias para garantizar que cumplan con su propósito y que los datos estén consistentes entre cada repositorio que se los va moviendo y transformando. Para generar datos de prueba (fake data) se puede usar herramientas como Mockaroo.
Integración Continua
La integración continua usada en el contexto de un sistema de DW / BI permite realizar dos actividades principales:
- Aprovisionamiento de ambientes
- Ejecución y calendarización de procesos de carga de datos (ETLs)
Existen varios servidores de integración continua, algunos Open Source conocidos son: go.cd, Jenkins, TravisCI. En la siguiente imagen muestro dos pipelines configurados en la herramienta go.cd para un sistema de DW / BI:
En el pipeline de Provisioning se puede lanzar la ejecución del código de aprovisionamiento y aprovisionar los ambientes de QA, PRE-PROD y PROD.
En el pipeline de Deployment se puede calendarizar la ejecución de los procesos ETL principales para que corran primero en el ambiente de QA, sí todo está exitoso se ejecuten en el ambiente de PRE-PROD y finalmente en el ambiente de PROD.
Mecanismos de entrega de información
Una vez que se tenga poblado de datos el modelo dimensional con los procesos ETLs, se construye las diferentes soluciones para realizar actividades de Business Intelligence. Estas soluciones se las puede categorizar en:
- Reporteo: reportes institucionales, reportes a demanda (ad hoc), tableros de mando
- Soluciones OLAP: cubos de análisis de datos y tablas pivot
- Personalizadas: portales web, aplicaciones de visualización, infografía
El mecanismo de entrega que decidan los usuarios del negocio tiene que agregar el máximo valor para responder a sus preguntas de negocio y apoyar a su proceso de toma de decisiones.
Pensamientos Finales
El construir un sistema de DW / BI usando las prácticas ágiles trae beneficios visibles en cada iteración. La estrecha interacción y colaboración con los usuarios de negocio, la priorización de las preguntas a responder y la aplicación correcta de las prácticas de ingeniería como automatización del aprovisionamiento de ambientes, modelamiento dimensional evolutivo e integración continua permiten entregar resultados tempranamente, minimizar los riesgos a través del aprendizaje continuo, evitar inversiones innecesarias, evolucionar y satisfacer los requerimientos cambiantes que toda organización posee.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.