flowchart LR
source1["ERP empresarial"]
source2["Base de datos Logistica"]
etl1["ETL"]
dw[("Sistema informacional")]
etl2["ETL"]
datamart1["Data Mart Finanzas"]
datamart2["Data Mart Operaciones"]
source1 --- etl1
source2 --- etl1
etl1 --- dw
dw --- etl2
etl2 --- datamart1
etl2 --- datamart2
%% Paleta por bloque del libro
classDef origen fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
classDef carga fill:#fae3c8,stroke:#bf7f28,stroke-width:1.5px,color:#573809
classDef almacen fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
classDef explotacion fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
class source1,source2 origen
class etl1,etl2 carga
class dw almacen
class datamart1,datamart2 explotacion
9 Elección de arquitecturas
Es una fuente constante de debate pensar en si existe una mejor manera de hacer lo que hacemos, y cómo movemos los datos de un extremo al otro. Y siempre habrá nuevas piezas técnicas a descubrir que nos permitirán hacer las cosas mejor, pero la base, el servicio que ofrecemos a los consumidores de datos y la lógica tras nuestro modelo de datos debe perdurar ya que es un fiel reflejo de nuestra organización y esto no cambia tan frecuentemente. Ya lo decía Conway
Las organizaciones que diseñan sistemas son un fiel reflejo de la comunicación en la misma.
9.1 Top-down o bottom-up
Quizás con un foco más operativo debido a los sistemas existentes, tanto Bill Inmon (Inmon 2005) como Ralph Kimball (Kimball y Ross 2013) se enfrentaron al reto de almacenar de forma efectiva toda la información que contiene una organización, pero a su vez presentar vistas específicas y cohesionadas que permitieran a los usuarios entender lo que los datos reflejaban sobre el funcionamiento de la empresa en áreas concretas.
El enfoque de Inmon abogaba por fijarnos en las fuentes y generar un sistema centralizado de datos al que luego poder destilar los recursos necesarios.
Mientras que la colección de Data Marts representan para Kimball el Data Warehouse, la pieza central. Desde las unidades de negocio podemos indicar las dimensiones y hechos a agregar que deberemos materializar en visiones concretas para cada unidad donde, entendemos, las dimensiones serán comunes dado que trabajamos en unidades de una empresa en una misma industria.
flowchart LR
source1["ERP empresarial"]
source2["Base de datos Logistica"]
etl1["ETL"]
subgraph dw ["Sistema informacional"]
datamart1["Data Mart Finanzas"]
datamart2["Data Mart Operaciones"]
end
source1 --- etl1
source2 --- etl1
etl1 --- dw
%% Paleta por bloque del libro
classDef origen fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
classDef carga fill:#fae3c8,stroke:#bf7f28,stroke-width:1.5px,color:#573809
classDef explotacion fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
class source1,source2 origen
class etl1 carga
class datamart1,datamart2 explotacion
Estas dos aproximaciones han sentado la base de lo que es necesario en un warehouse, tanto para el equipo que lo mantiene y quieren dar un buen servicio como paras los consumidores de datos que los necesitan para tener una operativa inteligente.
9.2 La caja fuerte
El Data Vault (Linstedt y Olschimke 2015), se plateó como una metodología más allá del propio sistema de modelado intermedio. Habíamos aprendido mucho sobre cómo nos comunicamos con los negocios y sus necesidades. Pero esto también nos daba una perspectiva de cómo la información debía ser promocionada hacia las capas de consumo.
Sabemos que debemos recibir información cruda de las fuentes, y esta información debe reposar al menos por un tiempo para poder ser entendida y gestionada. En el mejor caso, simplemente se integrará con las estructuras existentes. En el peor, deberemos alterar nuestro modelo para albergar estos nuevos datos e informar de su existencia a capas superiores. Es el área de aterrizaje de los datos o staging.
Una vez entendidos los datos y su cohesión en los conceptos de negocio, formarán parte de la estructura base de nuestro sistema informacional. Quizás podamos aplicar algunas restricciones de negocio o validar la bondad de los datos recibidos. Todas estas fases son parte de una etapa intermedia que en el caso de data vault, forman el raw vault, con la información cruda ya estructurada; y el business vault donde ciertas reglas de negocio puedan ser aplicadas.
Finalmente, el usuario debe ser abstraído de toda esta complejidad técnica. Una última capa pensada para la extracción de información, en un modelado en estrella o de tabla única, es donde la información resulta sencilla de consumir y con suerte disponemos de información adicional sobre cuándo fue actualizada por última vez, si algo ha cambiado en los datos, etc. Es la capa de consumo o business intelligence.
9.3 La era Big Data
Para principios de los 2000s, varias empresas se enfrentaban a problemas relativos a la velocidad y variabilidad de los datos que venían de procedencias ajenas a la red empresarial: internet. El volumen 1 que debían de procesar bien al vuelo como en reposo, crecía exponencialmente. Y si añadimos a esto la necesidad de modelar al mismo ritmo debido a la variabilidad de los formatos (XML en gran medida en aquella época). Recordemos que los sistemas tabulares requerían de informar del esquema de la tabla incluyendo el tipo de dato de antemano, y cada cambio supone un quebradero de cabeza de gestión.
Ya en 1998, Carlo Strozzi había sugerido el uso de sistemas que no solo soportarán SQL. Es decir, que permitieran lo que conocemos como schema-on-read trasladando el problema de modelado a capas posteriores del sistema de forma que al menos, no perdiéramos información. En la misma medida, los equipos de Google y Yahoo! se encontraban en su pelea particular de cómo almacenar y procesar la información disponible en internet de manera económica y efectiva.
El equipo de Google publicó dos trabajos que formaban parte de los sistemas internos que hacían que Google funcionara como lo hacía y pudieran analizar volúmenes como el que ocupaba la información en internet sin quebrar la compañía: Google File System (Ghemawat et al. 2003) y Map Reduce (Dean y Ghemawat 2004). Estas publicaciones motivaron la implementación de Mike Cafarella y Doug Cutting, Apache Hadoop un sistema que tuvo una adopción vertiginosa en la década de 2010, algo antes de que se desencadenara el movimiento a la nube.
Este sistema fue de los primeros que ofrecía a las empresas un sistema desacoplado entre almacenamiento y computación, con un sistema de código abierto, lo cual lo hacía accesible a todo el mundo al coste de ser uno mismo quien mantiene este sistema organizado.
9.4 La casa del lago
Hadoop estaba basado en un sistema de ficheros, lo cual daba la versatilidad de almacenar lo que fuera necesario, sin embargo, consumir datos de esta fuente se volvía engorroso. Dado que los conocimientos de los equipos seguían centrándose en SQL y herramientas que podían realizar este tipo de consultas, los ingenieros de Facebook tomaron como referencia el trabajo del equipo de Google Dremel (Melnik et al. 2010) y crearon un sistema que permitía consultar información tabular en el sistema, Apache Hive. Simplemente catalogando cómo realizar la traducción tabla a fichero, estos sistemas abstraían a los usuarios de las complejidades del lago de datos empezando a vislumbrar lo que años más tarde el equipo de Databricks denominaría la casa del lago (o Data Lakehouse) (Armbrust et al. 2021).
9.5 Ordenando el lago
Tras la polvareda generada por la tumultuosa era de los clústeres Hadoop, la nube se abrió camino y con ello soluciones que haciendo uso de las tecnologías abiertas disponibles ofrecieron soluciones renovadas a las empresas. En cierta forma es como si hubiéramos reinventado los sistemas de gestión de base de datos cayendo en los mismos problemas que presentaban los sistemas originales, un ciclo que Stonebraker y Pavlo llevan documentando desde hace dos décadas (Stonebraker y Pavlo 2024). No es que no hubiera almacenamiento columnar antes de Apache Parquet o computación distribuida en memoria antes de Apache Spark, pero a veces tenemos que romper el status quo para apreciar el trabajo existente.
Dos grandes empresas salieron de esta época, Snowflake con su sistema de gestión de bases de datos tabulares que permitía una gestión desacoplada de almacenamiento y computo. Y Databricks, cuyo co-fundador es Matei Zaharia, autor principal del trabajo en Apache Spark (Zaharia et al. 2012, 2016)2.
Estas dos soluciones de algún modo han vuelto a enfocarse en ofrecer rendimiento y estructura a los sistemas de datos. Han incorporado necesidades como las de lanzar procesos de bajo nivel o permitir flexibilizar los tipos de datos (VARIANT o JSON) para albergar estructuras anidadas de datos
{
"persona": {
"nombre": "Iraitz",
"appelido": "Montalban",
"empresas":
[
"SDG Group"
"Iberdrola",
"Panda Security",
"Tecnalia"
]
}
}
}pero se centran en disponer la información de forma tabular a sus consumidores. Databricks se ha encargado de acuñar varios términos como el Lakehouse para este tipo de flexibilización de la base de datos tradicional que incluye además capacidades operacionales; o incluso la arquitectura medallón3
Que de algún modo, reinventa las tres capas base que ya veníamos empleando con otro nombre. Podríamos llamarlo la arquitectura del sentido común ya que sabemos que nuestras fuentes y nuestros consumidores van a tener distintas necesidades y únicamente nos estamos concediendo un hueco entre ambos para poder realizar nuestro trabajo y consolidar toda la información de la empresa de forma que sea manejable.
Es curioso cómo estos sistemas han evolucionado precisamente ofreciendo capacidades operacionales en las modalidades de arquitecturas mixtas gracias a los formatos abiertos de nueva generación.
Con esta tercera V es como conocemos las tres Vs del Big Data.↩︎
Junto con nombres como Ion Stoica↩︎
De su fuente oficial https://www.databricks.com/glossary/medallion-architecture↩︎