Nota: El objetivo de esta entrada es explicar qué es un Data Warehouse y de paso la diferencia entre arquitectura y tecnología . Comenzaré hablando de una situación común que se da en las empresas, posteriormente revisaremos la historia de aceptación para finalmente cerrar con la utilidad que nos ofrece un Data Warehouse. De vez en cuando usaré indistintamente Almacén de Datos, Data Warehouse, Data Warehousing o DW.

En la medida que las empresas requieren ser más competitivas suelen incorporar Software (a la medida o empaquetado) que les permita gestionar sus procesos de negocios de forma tal que se vuelvan predecibles y optimizables. Cada proceso de negocio tiene su complejidad y vida propia, por lo que sin quererlo ni beberlo, las organizaciones comienzan adquirir más Software o Módulos encargados de administrar sus procesos de forma atómica, durable y concurrente. 

Con el paso del tiempo lo que era solo el módulo o sistema de ventas, se extiende a un módulo o sistema de comisiones, facturación, RRHH y así sucesivamente, generando un entorno conocido como “The Spider Web”:

Entorno Spider Web

Suele suceder que dichos sistemas no usan las mismas tecnologías, puede que no sean del mismo proveedor o sus arquitecturas sean incompatibles. Exigirles además cumplir con fines analíticos sin que merme la operación diaria de vender o facturar es complicado. Si bien, hay propuestas que prometen “all in one” (operación y predicción) suelen tener un problema fundamental: Son propuestas tecnológicas en vez de arquitectónicas.

Considerando este escenario, hace unos ya 30 años, una persona disruptiva propuso un nuevo enfoque encargado de cubrir el ciclo analítico de los datos. Fue entonces cuando nace la división entre el “mundo operacional” versus el “mundo analítico” o como se hablaba en aquella época: Sistemas para la toma de Decisiones – DSS. Esta división generó una serie de consecuencias entre ellas:

1. El almacenamiento de los datos es distinto.
2. El tipo de procesamiento de los datos es distinto.
3. La tecnología que soporta el procesamiento es distinta.
4. El patrón de uso del hardware es distinto.
5. El uso que le da la comunidad a los datos es distinto.
6. Las metodologías y la disciplina de administrar los datos son distintas.

Fue William H. Inmon (Padre del Data Warehouse) en aquel entonces quien propuso la arquitectura denominada Data Warehouse (DW). Su propuesta era que el DW estuviera al centro del entorno analítico. Sin embargo no estuvo exento de críticas, de hecho nos ha contado algunas reacciones que te comparto a continuación.

Primeras reacciones sobre Data Warehouse

Cuando Bill propuso el término de Data Warehouse hubo todo tipo de reacciones. Algunas personas se burlaron, otras incluso indicaron que la propuesta retrocedía la industria tecnológica en 20 años. Entre ellos había proveedores tecnológicos y consultores. 

Algunos académicos indicaban que un Data Warehouse no aportaba nada nuevo, y además que no era válido por carecer de referencias en libros, papers, clases o seminarios. Fue tanta la incomodidad que generó Bill, que incluso intentaron prohibirle hablar en público. 

A día de hoy, difícilmente se argumenta contra la utilidad de un Data Warehouse, podemos encontrar muchas consultoras que ofrecen servicios de Data Warehousing y en las universidades al menos se habla del tema. Irónicamente habrás escuchado la frase “una sola fuente de la verdad” acuñada por muchos gigantes tecnológicos, cuando en su momento no apoyaban el término. Las vueltas de la vida. 

Lo más insólito es que la historia se está volviendo a repetir, esta vez en text analytics. Bill lleva años proponiendo Textual ETL, te recomiendo leer estos artículos: Money and Smarts , Sill Me, The elusive 360 Degree View of Customer, A puzzlement, The Single Dumbest Thing I Ever Heard.

Data Scientist: Ok Lenin, pero ¿qué es un Data Warehouse?

¿Qué es un Data Warehouse?

Con mucho pesar noto que frecuentemente se suele etiquetar a un Data Warehouse como tecnología, principalmente por no distinguir la diferencia entre tecnología y arquitectura. Para ejemplificar, recurriré a mi amigos del programa City Tour:

Federico S: Si comparas el sur de Chile con Santiago, en ambos lugares se utilizan “ladrillos” (tecnología) para las construcciones, pero lo que les da el “toque especial a cada lugar” es su arquitectura Comparini. 

Comparini: Federico, ¿realmente es importante la arquitectura?

Federico S: Por supuesto, recordemos lo que pasó hace años con el caso “Puente Cau Cau” el cual fue desastrosamente armado. Si bien el puente puede que haya utilizado los mejores materiales (tecnología), su forma final, era inservible (arquitectura).

Federico S: Por cierto Comparini, Big Data es ¿una tecnología o arquitectura?

Comparini: Dejemos que la audiencia responda 🙂

Como podrás notar querido lector, la arquitectura necesita ladrillos (tecnologías) para ser construidas, pero no es lo mismo. Un Data Warehouse es una arquitectura.

Data Warehouse – La Memoria Corporativa de Nuestros Datos

Un Data Warehouse es un repositorio de datos integrado, orientado a temáticas de negocio, no volátil y encargado de preservar la historia de los datos en el tiempo, cuya misión final es ayudar o servir de base para el proceso de toma de decisiones. 

El detalle de la arquitectura propuesta por Bill se conoce como CIF (Corporate Information Factory) la cual veremos en otro artículo. Como adelanto podemos decir que CIF propone comenzar “mirando el todo” para luego bajar “a lo particular” de forma iterativa. Enfoque conocido como top down el cual comulga con el framework de Zachman. Una vez que los datos están en nuestro DW se pueden usar para múltiples propósitos a diferencia de cuando los datos residen en los sistemas operacionales cuyo enfoque es funcional.

Para qué sirve un Almacén de Datos

Un Data Warehouse enfrenta las falencias que se producen naturalmente en la arquitectura Spider Web. Entre ellas encontramos: poca credibilidad en los datos, baja productividad y la dificultad para lograr que los datos se conviertan en información.

Un ejemplo clásico que engloba los puntos anteriores es cuando distintos departamentos reportan el mismo KPI a la alta dirección pero con distintos valores. Usualmente esto se da porque obtienen los datos de forma distinta (extracción). Si a eso sumamos que las definiciones pueden ser distintas, no es solo un problema de credibilidad sino también de productividad. Finalmente el anhelo de obtener un reporte corporativo puede llevar al desafío de consolidar datos que están repartidos en más de un sistema o módulo complicando las extracciones y potenciando por doquier los Excel Spreadmarts. 

¿Qué nos puede aportar un Data Warehousing?

Un Data Warehouse nos puede aportar o facilitar:

1. Almacenar granularmente los datos corporativos.
2. Credibilidad de los datos al ser integrados en una sola fuente de la verdad.
   1. Aumenta el nivel de madurez analítico de una compañía. 
3. Preservación de la historia y particionamiento de los datos.
   1. Cuidado con estos Pecados Capitales
4. Metadatos, contexto y datos reconciliados.
5. Los datos están disponibles para más de un uso, incluso para usos nuevos o desconocidos.
6. Entregar datos limpios, organizados e integrados para iniciativas Data Science.
   1. La calidad de los datos es apoyada de procesos ETL que automatizan el trabajo.
7. Facilitar requerimientos regulatorios.
8. Permitir que el acceso a los datos sea rápido e independiente de los sistemas operacionales.
9. Drill Down sin tener que rehacer los programas que extraen los datos.
10. Facilitar el desarrollo de nuevas metodologías centradas en el negocio.

En la práctica se suele asociar a un Data Warehouse con datos estructurados principalmente porque los sistemas que administran las bases de datos (DBMS) permiten almacenar y procesar este tipo de datos con relativa flexibilidad. Sin embargo los datos estructurados representan a lo más un 15% de los datos de la organización. ¿Qué estamos haciendo con los datos no estructurados como email, PDF, WORD, encuestas, PPT, RRSS? ¿Son compatibles con un Data Warehouse?

Datos No Estructurados en un Data Warehouse

La respuesta es sí. De hecho cuando mezclamos ambos tipos, abrimos a las organizaciones a enormes posibilidades. ¿Cómo se puede establecer un puente entre el mundo no estructurado y estructurado? A través del Texto y en algunos casos incluyendo su Contexto.

Convertir datos No Estructurados a Texto genera confusión ya que las bases de datos actuales (SQL y NOSQL) permiten almacenar texto de forma variable. Bastaría crear un campo de tipo varchar o blob llamado “comentario”, “post”, “diagnóstico”, etc., donde almacenemos todo el contenido. En la práctica esto no aporta valor para el negocio porque no puedes hacer consultas directas sobre dicho campo. Sin mencionar que probablemente te topes con faltas de ortografías, diminutivos, nombres con distintos significados según el contexto y muchos más inconvenientes propios del lenguaje natural.

Por lo tanto es necesario transformar dicho texto (crudo) en una texto desambiguado y estructurado de forma tal que nos permita hacer consultas incluso en SQL. Repito incluso en SQL. Para esto puedes seguir el camino de NLP, ML o ver una alternativa interesante llamada Textual ETL.

Hasta aquí hemos visto cómo surgió el Data Warehouse, en las próximas entradas profundizaremos y veremos su versión DW 2.0, también veremos la propuesta Data Vault y en ambos casos la relación con Text Analytics.

Nota: Puede que estos artículos sean de tu interés: ¿Qué es un Data Lake, para que sirve y cuánto cuesta implementarlo en AWS, Azure y GCP? , La Metodología Kimball.

Difusión

Si crees que este contenido puede ser útil para otras personas no dudes en compartirlo. De igual forma te invitamos a seguirnos en LinkedIn, Facebook, Instagram y Youtube donde estamos publicando semanalmente tips relacionados con DW/BI, Data Science, Visualización y Software a la Medida que es justamente lo que más nos apasiona hacer en Explodat.

Fuentes:

1. Building the Data Warehouse, Fourth Edition. William H. Inmon.
2. DW 2.0: The Architecture for the Next Generation of Data Warehousing. William H. Inmon, Derek Strauss, Genia Neushloss.
3. Corporate Information Factory, Second Edition. William H. Inmon, Claudia Imhoff, Ryan Sousa.
4. Mastering Data Warehouse Design: Relational and Dimensional Techniques.Claudia Imhoff, Nicholas Galemmo, Jonathan G. Geiger.