Las empresas hoy en día, con el gran aumento de la información que se genera, se enfrentan a muchas dificultades para sacar el máximo partido a toda la información que tienen o podrían tener disponible para la toma de decisiones, y más importante aún, para hacerlo correctamente.
La mayoría de las empresas, en sus analíticas, utiliza un porcentaje de información muy bajo respecto al total que tienen disponible porque principalmente, está dispersa en diferentes ubicaciones, en diferentes formatos que no pueden explotar, e incluso información de la que no conocen su existencia. Este problema se está acentuando de forma considerable en los últimos años con la irrupción del Big Data y la generación de mucha más información de numerosos orígenes (Bases de Datos, ficheros, aplicaciones, sensores…)
Otro gran problema que afrontan las empresas en el análisis de la información es la fiabilidad del dato, puesto que encuentran información no certificada en diferentes ubicaciones, muchas veces información obsoleta, encontrando incluso información sobre las mismas métricas con diferente dato, lo cual genera una gran incertidumbre en las conclusiones que se puedan sacan analizando esta información, lo cual lleva muchas veces a tomar decisiones erróneas, teniendo un gran impacto negativo en la estrategia de la compañía. La centralización de la información nos va a permitir que nuestros datos sean consistentes, completos, fiables y enriquecidos.
Nosotros siempre recomendamos a nuestros clientes la centralización de su información porque, sin duda, los datos son los activos más valiosos de la empresa hoy en día, incluso se dice que “los datos son el nuevo petróleo”. Esta centralización de los datos es una inversión que traerá a la compañía muchos beneficios en el presente y futuro.
Entre las principales ventajas de la centralización de la información encontramos:
- Seguridad en la toma de decisiones. Cuando una empresa analiza sus datos, lo más importante es que tenga una gran seguridad de que las conclusiones que se están sacando sean fundamentadas usando la información correcta, los datos tienen que ser fiables para que las personas que tienen que tomar las decisiones se sientan seguros. Al clasificar y centralizar la información se consigue eliminar la incertidumbre, con datos certificados, validados y creíbles, lo cual es un seguro para que las decisiones tomadas tengan un impacto positivo para la compañía.
- Mayor organización. Cuando la información está centralizada, toda la actividad empresarial está más organizada. Con ello se consigue que la pérdida de datos sea realmente reducida, conseguir una información fiable y llegar el aprovechamiento de la totalidad de los datos que tiene la empresa.
- Mejora en la integración entre departamentos. La comunicación entre los distintos departamentos dentro de la empresa es fundamental en el funcionamiento de las compañías, la colaboración entre los departamentos es esencial por lo que una centralización de la información permite que todos estén interconectados y exploten la misma información.
- Mejor información sobre los clientes. Tener una información histórica y detallada de las operaciones de los clientes es importantísimo para poder trazar las mejores estrategias para la empresa. Conocer los tipos de perfiles de los clientes, operaciones realizadas y comportamiento en las compras ayudará a la compañía a trazar las mejores campañas de marketing y ventas y tomar las mejores decisiones para la prosperidad del negocio.
- Enriquecimiento de los datos. El aprovechamiento de una mayor cantidad de datos nos va a ayudar al enriquecimiento y corrección de información que ya teníamos disponible con lo que vamos teniendo unos datos más consistentes y valiosos en las decisiones de la empresa.
En este post vamos a ver un ejemplo práctico de como centralizar la información disponible para aprovecharnos de las grandes ventajas que nos da. En este ejemplo vamos a usar un conjunto de datos públicos del Ayuntamiento de Madrid en el que se muestran accidentes generales (todo tipo de vehículos), accidentes de bicicletas y activaciones ante llamadas al Samur. También vamos a usar una serie de datos inventados (como costes estimados, probabilidad de recuperación del accidentado, probabilidad de éxito…).
Caso práctico Ayuntamiento de Madrid
Una empresa colaboradora con el Ayuntamiento de Madrid es la encargada de dirigir la centralización de toda la información, en un principio, dispersa, errónea en algunos casos e incompleta en otros. Esta empresa también ayudará en el análisis de la información.
En esta empresa encontramos que la gestión y explotación de estos datos la llevan a cabo tres departamentos (Departamento Gestión, Departamento Transporte Sostenible y Departamento de Organización).
La información explotada por cada uno de los departamentos es:
Los tres departamentos se alimentan de la Base de Datos SQL Server On Premise, los departamentos de Organización y de Transporte Sostenible, además de usar datos de SQL, explotan datos que reciben de varios sistemas en formato Excel. Como vemos en la imagen superior, el Departamento de Gestión no tiene acceso a la información de los Departamentos de Organización y de Transporte Sostenible, mientras que el Departamento de Organización no tiene acceso a la información de Departamento de Transporte Sostenible y viceversa. Esta falta de comunicación supone una pérdida de datos inaceptable para la compañía, sabiendo la importancia de la información para conseguir la mejor toma de decisiones. Debemos centralizar la información.
En nuestro ejemplo, vamos a centralizar toda la información en un mismo lugar, de modo que toda la compañía tenga acceso a todos los datos. Además, vamos a aprovechar para enriquecer los datos juntando la información de todos los orígenes (hay información que tiene algún departamento, que no estaba disponible para el resto), vamos a corregir algunos errores en la información al unir los datos y, sobre todo, vamos a conseguir una información fiable, unificada y consistente que va a estar disponible para toda la empresa.
Nuestra arquitectura propuesta para centralizar los datos es la siguiente:
Nuestro proceso de centralización de los datos consta de los siguientes pasos:
- Acceso a los orígenes de datos y, orquestado por Azure Data Factory, llevamos toda nuestra información a un Data Lake, donde conseguiremos reunir toda la información en bruto (Sin transformaciones) de la compañía, en un mismo formato (en nuestro caso hemos elegido en formato JSON). A partir de aquí, ya tenemos toda la información organizada y clasificada en una estructura de carpetas dentro de nuestro Data Lake.
- En Snowflake vamos a tener 2 áreas, el área de staging y el área de dw, vamos a entender que es lo que se almacenará en cada una de estas áreas:
- En el área de staging vamos a cargar los datos de los ficheros JSON que tenemos en el Data Lake sin modificaciones ni transformaciones, pero ya en formato tabular.
- En el área de dw, vamos a crear las tablas de negocio y de dimensión que formarán nuestro modelo de datos, con la información total de la compañía, asegurando que los datos son certificados, confiables, completos y consistentes. En este área, los datos de origen serán limpiados, corregidos y enriquecidos, se optimizarán las tablas de hechos y se crearán dimensiones dinámicas que sean necesarias para nuestro modelo. Esta información será consumidos por los miembros de la compañía de distintas formas, en nuestro ejemplo serán visualizados mediante Power BI.
- Desde Power BI conectaremos al área de dw creado en Snowflake, crearemos nuestro modelo, aprovechando que en los pasos anteriores hemos preparado las tablas de negocio para su consumo y con esto, podremos fácilmente crear nuestros Reports y Dashboards para analizar toda la información relevante de la empresa y tomar las mejores decisiones para conseguir el éxito.
Tareas realizadas para centralizar los datos
Como vimos anteriormente, cuando hablamos de los departamentos de la empresa, nuestros datos de origen son:
- Información guardada en SQL (los 3 departamentos lo utilizan), que constan de 3 tablas. La información de estas tablas es la siguiente:
- Información proveniente de ficheros Excel. Cada departamento a día de hoy está recibiendo y explotando una serie de ficheros excel:
- Departamento de Organización
- Fichero de corrección de expedientes. Se recibe con información corregida de expedientes de accidentes de bicicletas que son erróneos en el sistema principal (BBDD SQL)
- Fichero con información de éxito y/o penalización en las actuaciones Samur. Se recibe información de un sistema externo, en el que dependiendo del tiempo que tarda el Samur, desde que recibe el aviso hasta que realiza la actuación, nos dará la estimación de su probabilidad de éxito y el coste estimado.
- Fichero con los datos de lesividad. Información completa de la gravedad de la lesión producida en el accidente. Clasificación de lesiones con una estimación de probabilidad de recuperación y el coste estimado.
- Fichero de mapeo hospitales. Este departamento recibe de un mapeo completo de los hospitales a que es trasladado cada herido en las actuaciones del Samur por código de expediente. Este mapeo, nos servirá, una vez realizada la centralización del dato, para rellenar el dato del hospital donde es ingresado cada accidentado ya que en el sistema central (BBDD SQL), no siempre aparece registrado.
- Departamento de Transporte Sostenible
- Fichero de accidentes en bicicleta del año actual. Información recibida de un nuevo sistema de los accidentes de bicicletas producidos en el año actual. Este fichero contiene correcciones de expedientes y nuevos expedientes que no se han incluido en el sistema principal (BBDD SQL).
- Departamento de Organización
Lo primero que hacemos es conectar con la base BBDD SQL y con los ficheros Excel de los 3 departamentos y llevar esa información sin ninguna transformación a nuestro Data Lake en ficheros con formato JSON. De este modo, ya tenemos toda la información en un único lugar con el mismo formato. Este trabajo lo orquestará Azure Data Factory.
Vamos a ver los principales pasos a hacer en Azure Data Factory.
- Creamos los conjuntos de datos de los distintos orígenes de datos.
Conjunto de datos SQL. Para configurar el conjunto de datos, antes tenemos que hacer dos pasos importantes:
- Instalamos en nuestro equipo un Integration Runtime (que hemos llamado integrationRuntime1) que sirve de pasarela entre la base de datos On Premise y Azure Data Factory. Como vemos en la imagen conecta Azure Data Factory con nuestro servidor de base de datos llamado LTKB239.
- Creamos el servicio vinculado que nos permite conectar a nuestra base de datos desde Azure Data Factory usando el integration runtime creado en el paso anterior.
Conjunto de datos Excel. Para conectar al Blob Storage donde están los excels y poder leer los datos, tenemos que crear un servicio vinculado para realizar esta conexión. La forma de configurarlo es muy similar al servicio vinculado que hemos visto anteriormente de SQL pero, al estar el Blob Storage en la nube, no es necesario utilizar el integration runtime que hemos creado, sino que se usa el integration runtime en la nuve que nos proporciona Data Factory por defecto (sin necesidad de instalación ni configuración).
2. Conjunto de datos receptor, que será nuestro Data Lake y lo configuramos para recibir la información en formato JSON.
Primero tenemos que crear un servicio vinculado (que hemos nombrado como DataLake_JSON) para poder guardar los ficheros en el DataLake. La configuración es similar al servicio que conectaba al Blob Storage, sólo que ahora conectamos al Data Lake donde vamos a depositar nuestra información.
3. Ahora creamos la pipeline en Azure Data Factory que va a copiar todos los datos desde los orígenes (Sql Server y Blob Storage donde guardan los departamentos sus excels) al Data Lake donde vamos a reunir toda la información en bruto, sin ningún tipo de transformación ni aplicación de lógica de negocio.
Lo más importante en cada tarea de copia es señalar correctamente los conjuntos de dato origen y destino. Para comprobar que hemos realizado correctamente los pasos anteriores, podemos hacer una visualización previa de los datos, sabiendo si conectamos correctamente.
Después de configurar y ejecutar la pipeline de Azure Data Factory, ya tenemos los datos organizados y centralizados en nuestro Azure Data Lake en formato JSON. Nuestra estructura de carpetas quedaría del siguiente modo:
Dentro de cada carpeta ya tenemos guardados los ficheros con la información en el formato elegido, nosotros nos hemos decantado por JSON, porque es un formato simple y con el que nos permite trabajar con una velocidad de procesamiento alta.
4. Es el momento de trabajar en Snowflake, donde vamos a explicar los pasos que hemos seguido.
- Creamos la base de datos en Snowflake, que va a contener toda la información de nuestra empresa.
- Configuramos el stage que nos va a permitir conectar con el Data Lake donde tenemos los datos en formato JSON, los cuales vamos a cargar en la capa de Staging de nuestro Snowflake. Para configurar este stage se necesita introducir la ruta del container del Data Lake donde están los ficheros que vamos a cargar, las credenciales del mismo y el formato de los ficheros que vamos a consumir (nosotros hemos creado un File Format de tipo JSON que hemos llamado «my_json_format»)
- Vamos a cargar nuestro área de Staging en dos pasos, primero vamos a cargar la información de nuestros ficheros JSON en unas tablas auxiliares que tienen un solo campo de tipo Variant, que contendrá toda la información del fichero. En el paso siguiente, vamos a pasar toda esta información a una forma tabular, nuestras tablas de staging. Se podría hacer en un solo paso y copiar la información de los ficheros directamente a las tablas de staging, nosotros hemos preferido hacerlo en dos pasos para tener las tablas auxiliares con la información en la columna de tipo Variant con el formato JSON para tener una mayor trazabilidad del dato.
Ya estamos en disposición de guardar la información de forma tabular cargando las tablas de Staging.
- Ahora viene la parte más importante, la carga de las tablas de negocio que son realmente las que van a consumir los miembros de la compañía para realizar sus análisis de datos y tomar decisiones importantes. En esta parte vamos a preparar nuestro modelo de datos con las siguientes tareas:
A. Desarrollo y carga de las dimensiones necesarias en nuestro modelo (vamos a crear dimensiones dinámicas que se cargarán con los distintos valores de nuestras tablas de Staging
Como vemos nuestras dimensiones va a estar compuestas de un código numérico (que se genera con el row_number) y una descripción. En este caso se van a almacenar en la dimensión todos los tipos de accidentes que tengamos en nuestras tablas.
Usando estas dimensiones, vamos a sustituir todas las descripciones que había en las tablas de hecho por su código numérico correspondiente en la dimensión, que será la foreign key usada para relacionar la tabla de hechos con la dimensión. Esta tarea nos va a permitir optimizar el modelo y reducir considerablemente el volumen de las tablas de hechos, ya que por redundancia, había muchas ocurrencias de textos que ocupan mucho más espacio que los campos de tipo numérico que los van a reemplazar.
En el siguiente ejemplo vemos como hemos transformado las descripciones de la tabla de accidentes (primera imagen) a códigos numéricos (segunda imagen). En la dimensión de Estado_Metereológica se ve la correspondencia del código numérico y su descripción (tercera imagen)
B. Desarrollo y carga de las tablas de hecho que van a contener los datos finales que la empresa va a utilizar en su toma de decisiones.
Al tener centralizada y controlada toda la información, al cargar las tablas de negocio, vamos a poder corregir y enriquecer los datos. Vamos a verlo con un ejemplo, la carga de la tabla de hechos de accidentes de bicicleta.
En esta primera carga, vemos que ha limpieza de datos (Por ejemplo el campo llamado Número) y conseguimos nuevos campos, como son la probabilidad de recuperación y el coste estimado que vienen de la tabla con los datos de lesividad que estaba en posesión del departamento de organización.
El departamento de transporte sostenible recibe por un sistema externo, una serie de expedientes que no están llegando al sistema principal (BBDD SQL), con el siguiente paso añadimos a las tablas finales estos datos, evitando la pérdida de información que se padecía antes.
En la siguiente imagen podemos ver un ejemplo de corrección de datos del sistema principal (BBDD SQL).
En el departamento de organización se reciben por un sistema externo correcciones sobre el sistema principal, informaión que, antes de esta centralización, no era accesible para todos los empleados. Gracias al trabajo realizado, podremos analizar la información consistente y fiable después de haber podido aplicar correcciones que nos proporciona el tener disponible los datos correctivos del departamento de organización.
Una vez que tenemos cargadas todas las tablas de negocio (dimensiones y tablas de hecho), ya estamos en disposición de su consumo.
En nuestro ejemplo vamos a usar Power BI. En nuestro fichero Pbix vamos a llevar a cabo las siguientes tareas
- crear un modelo tabular. Vemos que es un modelo en forma de copo de nieve sencillo con 3 tablas de hechos.
Desarrollo de dos reports con la información certificada, fiable y consistente que hemos unificado en Snowflake. Nosotros hemos creado dos reports que podrían ser un buen ejemplo de una análisis necesario para la empresa para entender mejor los datos y tomar importantes decisiones.
- Report sobre las actuaciones del Samur (Personas que han llevado a cada hospital y el Coste estimado de estos ingresos por hospital)
Report con datos de accidentes en bicicleta (Personas accidentadas en bicicleta por distrito y el número de accidentados por rango de edad).
Conclusión
En resumen, es este post hemos visto algunos problemas muy comunes que tienen muchas empresas como, tener muchos datos y no aprovecharlos al 100%, ver información incompleta o incoherente, desconocer información que tienen dentro de la compañía y por ello no explotarla, analítica de datos en distintos departamentos con orígenes diferentes y distinta información… y la solución a estos y otros problemas es tratar, limpiar, corregir y enriquecer los datos para después, almacenarlos en un único lugar donde tendrán acceso todas las personas que necesitan explotar la información consiguiéndose un único centro de verdad de la información, donde los datos son consistentes, coherentes, fiables, sin redundancia innecesaria y completos.
