La semana pasada vimos la Receta: quién la escribe, en qué idioma, y por qué cambia las reglas del juego. Terminamos diciendo que una buena receta sin ingredientes no sirve de nada.
Pues vamos a hablar de los ingredientes.
Pero antes, dejadme que os cuente algo que viví en un proyecto y que me cambió la forma de pensar sobre cómo se almacenan los datos.
“Enséñame el dato original del día 15 de marzo”
Estábamos en un proyecto donde el modelo llevaba meses en producción. Todo funcionaba. Los informes cuadraban. Los usuarios estaban contentos. Hasta que llegó una revisión de auditoría.
El auditor pidió algo que parecía simple: “Quiero ver el dato original, tal cual llegó del sistema fuente, del día 15 de marzo. Sin transformar. Sin limpiar. El dato crudo.”
Y ahí se hizo el silencio.
Porque no lo teníamos.
El pipeline cogía los datos del sistema origen, los transformaba y los cargaba en el modelo. El dato original se sobreescribía con cada carga. Lo que había en el data warehouse era el resultado de la transformación, no el ingrediente original.
“Vale, ¿y podéis pedir al sistema origen que os reenvíe la extracción del 15 de marzo?”
Otro silencio. El sistema origen no guardaba históricos de extracciones. Lo que tenía era el estado actual. El dato del 15 de marzo, tal cual era el 15 de marzo, ya no existía en ningún sitio. Ni en el origen, ni en el warehouse. Se había perdido.
¿Sabéis lo que hicimos? Reconstruirlo. A mano. Cruzando logs de carga, backups parciales del sistema origen, y la memoria de un DBA que “creía recordar” que aquel día había habido una incidencia con los tipos de cambio. Tardamos tres semanas. Tres semanas para responder una pregunta que, con una arquitectura correcta, se responde en tres minutos.
Y lo peor no fue el tiempo. Lo peor fue la duda. Cuando finalmente entregamos el dato “reconstruido”, nadie podía garantizar al 100% que fuera exactamente lo que llegó aquel día. Era una aproximación. Un “creemos que era esto.” Ante un auditor, eso no vale.
Pero la historia no acaba ahí. Dos meses después, el auditor pidió otro dato de otra fecha. Y vuelta a empezar. El mismo equipo, las mismas tres semanas, la misma incertidumbre. Porque el problema no era aquel dato concreto del 15 de marzo. El problema era que la arquitectura no estaba diseñada para guardar el dato original. Cada vez que alguien preguntaba “¿qué había aquí hace un mes?”, la respuesta era “no lo sabemos con certeza.”
Y esto no es un caso extremo. Habla con cualquier equipo de datos de una empresa de cierto tamaño y pregúntales: “Si mañana te pido el dato crudo que llegó del sistema de contratos el día 15 del mes pasado, ¿lo tienes?” La mayoría dirá que no. O dirá “depende.” Y ese “depende” es un riesgo regulatorio que muchas empresas asumen sin ser conscientes de ello.
Ahí aprendí algo fundamental: el dato más importante de tu data warehouse es el que no tocas.
La cocina que tira los albaranes
Volvamos a nuestra metáfora.
Imagina un restaurante que recibe un envío del proveedor: cajas de verduras, carne, pescado. El cocinero abre las cajas, coge los ingredientes y se pone a cocinar directamente. Las cajas, los albaranes, las etiquetas con la fecha de envasado, el lote, el proveedor… todo va a la basura. “Total, ya tenemos los ingredientes, ¿para qué guardar el papel?”
Todo va bien. Los platos salen. Los clientes están contentos.
Hasta que un cliente se intoxica.
Llega Sanidad y pregunta: “¿De dónde vino el pollo que usasteis ayer? ¿De qué granja? ¿Qué lote? ¿Cuándo llegó? ¿A qué temperatura se almacenó?”
Y el restaurante no puede responder. Tiraron los albaranes. No apuntaron los lotes. No saben de qué proveedor era el pollo de ayer porque reciben de tres distintos y no etiquetaron nada.
Esto no es una metáfora exagerada. En la Unión Europea, la trazabilidad alimentaria es una obligación legal (Reglamento CE 178/2002). Cada restaurante debe poder rastrear cualquier ingrediente hasta su origen: proveedor, lote, fecha de recepción. Si no puedes, cierra el inspector.
¿Sabéis qué exigen DORA, BCBS 239 y el AI Act europeo para los datos? Exactamente lo mismo.
Trazabilidad completa desde el dato en el informe final hasta el dato original del sistema fuente. Cada transformación documentada. Cada origen identificado. Cada fecha registrada.
DORA, que entró en vigor en enero de 2025, exige a las entidades financieras demostrar que pueden rastrear cualquier dato de un informe regulatorio hasta su sistema fuente. No “creemos que viene de aquí.” Sino “este dato llegó del sistema X, el día Y, en el lote Z, y esta es la transformación que se le aplicó.” Si no puedes demostrar eso, tienes un hallazgo de auditoría. Y los hallazgos de auditoría en el sector financiero tienen consecuencias reales: planes de remediación, seguimiento regulatorio, y en casos graves, sanciones.
Y no es solo el sector financiero. El AI Act europeo va a exigir exactamente lo mismo para cualquier dato que alimente un modelo de inteligencia artificial. Si no puedes demostrar la procedencia y la calidad de los datos con los que entrenas tu modelo, no puedes desplegar ese modelo en la UE.
Y la mayoría de empresas “data-centric” están cocinando directamente desde el camión de reparto. Sin despensa. Sin albaranes. Sin etiquetas.
Tu data warehouse es el restaurante que tira los albaranes. Todo va bien hasta que llama Sanidad.
Qué es la Despensa (y por qué no es un simple almacén temporal)
Hay un error muy habitual cuando se diseña un data warehouse: crear una zona de “staging” — un área temporal donde los datos aterrizan del sistema origen — y tratarla como si fuera la despensa.
No lo es.
La staging es el muelle de descarga. Es donde el camión del proveedor deja las cajas. Las abres, las inspeccionas, y las mueves a la despensa. Después, el muelle se vacía para el siguiente envío. Si mañana necesitas algo de la entrega de ayer, en el muelle ya no está. Se fue.
La despensa es otra cosa. Es permanente. Cada envío se registra como un lote con su fecha, su origen, y su contenido exacto. Qué llegó, cuándo, de dónde, y en qué estado. Si dentro de tres meses necesitas saber qué llegó el 15 de marzo, abres la despensa, buscas el lote del 15 de marzo, y ahí está el registro completo.
Y aquí es donde el Shared Kernel de la Semana 1 cobra todo su sentido. Las entidades de negocio — Cliente, Producto, Mediador, Sucursal — existen en el catálogo compartido independientemente de cualquier fuente. Son el idioma común de la empresa. La despensa se organiza alrededor de esas entidades: cada una tiene su zona, su estantería.
La Receta de la Semana 2 es la que conecta cada fuente con ese idioma común. Dice: “En esta tabla, este campo corresponde a la entidad Cliente del catálogo, y este otro a Producto.” Es el mapeo entre el lenguaje del sistema origen y el lenguaje compartido de la empresa. Gracias a ese mapeo, la despensa sabe dónde colocar cada cosa que llega.
Pero — y aquí viene lo que diferencia una buena despensa de un simple cajón de sastre — los ingredientes no se apilan en un montón. Se organizan.
Pensad en una despensa profesional de verdad. Las verduras no están mezcladas con la carne. Los lácteos no están junto al pescado. Cada tipo de ingrediente tiene su zona. Y cada ingrediente tiene su etiqueta.
En un data warehouse, esta organización sigue una lógica fundamental: separar lo que un dato ES de lo que un dato TIENE en un momento dado.
Lo que un dato ES es su identidad.
Un cliente es siempre el mismo cliente, da igual cuándo lo mires o desde qué sistema llegue. Un producto es siempre el mismo producto. Un mediador es siempre el mismo mediador. Estas identidades son estables. Se registran una vez en la despensa. Si el mismo cliente llega desde otro sistema con otro nombre de campo, la despensa lo reconoce como la misma persona gracias al mapeo de la Receta. No lo duplica. Lo integra.
Lo que un dato TIENE es su estado en un momento concreto.
El mismo cliente puede vivir en una ciudad en enero y en otra en junio. Su perfil de riesgo puede cambiar de un trimestre al siguiente. Cada cambio se guarda como una foto fechada. Las fotos anteriores no desaparecen: coexisten. Puedes ver cómo era ese cliente en cualquier momento del tiempo.
Esto parece un detalle menor pero tiene consecuencias enormes. ¿Recordáis la auditoría del principio? “Enséñame el dato del 15 de marzo.” Si cada foto de estado está fechada y coexiste con las anteriores, la respuesta es inmediata: abres la foto del 15 de marzo y ahí está.
Y luego están las relaciones: qué conecta con qué.
Este cliente contrató este producto a través de este mediador en esta sucursal. Si mañana contrata otro producto, es otra relación. La primera sigue ahí. Las relaciones son el pegamento entre las identidades.
En el sistema origen, todo esto viene mezclado en una sola fila de una tabla plana. Identidades, estados y relaciones revueltos en 200 campos. Pero en la despensa, se separa. Cada cosa en su sitio. Y esa separación es la que lo cambia todo.
¿Por qué esta separación importa tanto?
Porque resuelve tres problemas de golpe:
Primero, la trazabilidad.
¿Quieres saber qué dirección tenía el cliente el 15 de marzo? No necesitas reconstruir nada. Buscas la foto de estado del 15 de marzo y ahí está. Sin arqueología. Sin “creemos que era esto.”
Segundo, el reproceso quirúrgico.
Descubres un bug en una transformación que lleva tres semanas en producción. Necesitas regenerar los datos desde el 1 de marzo. Sin despensa, esto es una pesadilla: necesitas pedirle al sistema origen que te reenvíe los datos. Si es que puede. Si es que los datos de hace tres semanas no han sido purgados. Con la despensa, todo está ahí. Corriges la transformación, la relanzas sobre los datos de la despensa, y en horas tienes los informes corregidos.
No tiras toda la nevera: sacas solo la bandeja del martes.
Esto parece un matiz menor pero en la práctica es enorme. Sin despensa, un reproceso típico implica: llamar al equipo de sistemas, pedir una reextracción, esperar a que la programen, comprobar que los datos son los mismos que llegaron originalmente (cosa que no puedes garantizar), recargar, retransformar y rezar para que no haya efectos colaterales. He visto reprocesos que han tardado dos semanas solo en conseguir que el sistema origen volviera a enviar los datos. Con la despensa, abres el lote, relanzas y listo. La diferencia entre apagar un incendio con una manguera y apagarlo con un extintor.
Tercero, el paralelismo. ¿Recordáis los 15 equipos de la Semana 1 que necesitaban trabajar sin pisarse? Esta separación es la que lo permite. Si la identidad está separada del estado, Riesgos y Marketing cargan sus atributos del mismo cliente en paralelo. Cada uno añade sus fotos de estado a la misma identidad. Sin conflictos. Sin esperas. ¿Y el proyecto regulatorio de la Semana 2, donde IT hacía de detective buscando dónde estaba “Producto” en cada sistema? Con la despensa, Producto ya está en su estantería de identidades, con todos los mapeos declarados en las recetas. No hay que adivinar nada.
“¿Quién cambió el formato de esta columna sin avisar?”
Hay un problema que todo ingeniero de datos ha vivido al menos una vez.
Un lunes por la mañana, el pipeline que lleva funcionando seis meses sin problemas falla. El error: un campo que antes era numérico ahora llega como texto. O una columna que antes tenía 8 posiciones ahora tiene 10. O un campo que siempre tenía valor ahora viene vacío en el 40% de los registros.
¿Qué pasó?
Alguien en el sistema origen hizo un cambio. Una migración, una actualización, un “ajuste menor” que nadie comunicó al equipo de datos. Porque en muchas empresas, los equipos que gestionan los sistemas origen ni siquiera saben que hay un data warehouse downstream que depende de sus datos.
Y ahora empieza el ejercicio detectivesco. ¿Quién hizo el cambio? ¿Cuándo? ¿Fue intencionado o es un bug? ¿Afecta a todos los registros o solo a los nuevos? ¿Desde qué fecha están los datos mal?
Si tu despensa es un muelle de descarga temporal, estas preguntas son un calvario. No puedes comparar “cómo llegaba antes” con “cómo llega ahora” porque no guardaste el “antes.”
Pero si tienes una despensa permanente, la respuesta es inmediata:
- ¿Cuándo cambió? Abres la despensa, comparas el lote de ayer con el de hoy. El campo cambió de formato entre la carga del viernes y la del lunes.
- ¿Afecta a los datos anteriores? No. Los lotes anteriores están intactos en la despensa. Puedes verificar que los datos de la semana pasada siguen siendo correctos.
- ¿A quién pregunto? Y aquí viene la pieza que casi nadie tiene.
La etiqueta del proveedor: quién es el dueño de cada ingrediente
En un restaurante profesional, cada caja que llega a la despensa tiene la etiqueta del proveedor. Si el pollo huele raro, no llamas al chef. Llamas al proveedor. Directamente. Sin intermediarios.
En un data warehouse tradicional, esta etiqueta no existe. Los datos llegan al equipo central y nadie sabe quién es responsable de qué. ¿Qué significa este campo? ¿Por qué cambió el formato? ¿Este nulo es correcto? Todas las preguntas van al equipo central, que no conoce el significado de negocio de cada dato. Y empieza la cadena de correos, reuniones y semanas de investigación.
Pero si habéis seguido la lógica de las semanas anteriores, la respuesta ya está ahí.
En la Semana 2 dijimos que empoderamos al usuario de negocio. Le damos herramientas. Le dejamos que sea él quien define la receta de sus datos: qué entidades contiene, cómo se mapean, qué reglas aplican. Le damos el poder de construir sus propios productos de datos.
Pero como diría cierto tío de cierto superhéroe: un gran poder conlleva una gran responsabilidad.
Si tú defines la receta de tus datos, tú eres el dueño de esos datos. No porque alguien te haya asignado un campo “owner” en un formulario de gobernanza. Sino porque tú los has definido, tú los has mapeado, tú los has cargado. Son tuyos. Cuando algo falla, la pregunta llega a ti. Porque tú eres el que sabe.
La propiedad del dato no es un acto administrativo. Es la consecuencia natural de empoderar al que conoce el dato.
Y en la práctica, esto cambia todo:
- Un campo cambió de formato → la despensa sabe que esa fuente la cargó el equipo de Producto (porque ellos definieron la receta) → la pregunta va directamente a ellos.
- Un campo tiene un 40% de nulos inesperados → la despensa sabe que esa fuente es del equipo de Clientes → la pregunta va a ellos.
- Una tabla dejó de llegar → la despensa sabe que el responsable es Operaciones → le llamas.
Sin pasar por IT. Sin correo masivo a 15 personas. Sin semanas de investigación.
Cuando el pipeline no falla… pero los datos sí
Dejadme que os cuente qué pasó un lunes real en uno de mis proyectos. El pipeline nocturno cargó los datos del fin de semana sin errores. No falló ningún proceso. No saltó ninguna alerta. Todo verde.
Pero el martes, un usuario abrió su informe y los números no cuadraban. Un indicador clave había bajado un 35% de la noche a la mañana. Imposible.
Investigamos. El problema: el sistema origen había cambiado el formato de un campo numérico el viernes por la tarde. Un campo que antes venía como “1234.56” ahora llegaba como “1.234,56” — el separador de miles y decimales se habían invertido. Los datos se cargaron, se transformaron, todo sin errores técnicos. El pipeline hizo exactamente lo que le pidieron. Pero el resultado era basura, porque el ingrediente estaba malo y nadie lo inspeccionó al llegar.
¿Sabéis cuánto tardó la investigación? Dos días. Dos días para descubrir que el problema no estaba en la transformación, ni en la lógica de negocio, ni en el modelo. Estaba en el ingrediente.
El pipeline no falló. Hizo exactamente lo que le pidieron: cocinar con un ingrediente en mal estado.
Si alguien hubiera comparado el envío del viernes con el del jueves y hubiera dicho “ojo, este campo tiene un patrón distinto”, lo habríamos detectado antes de cargar. En minutos, no en días.
Eso es exactamente lo que permite una despensa permanente: como tienes todos los lotes anteriores, puedes comparar. Sin histórico, no hay referencia. Sin referencia, no hay inspección posible. La despensa no solo guarda — es la base sobre la que se construye la calidad.
Cómo funciona ese inspector, qué detecta exactamente y cómo certifica los datos antes de que lleguen al plato… eso lo veremos más adelante cuando hablemos del emplatado.
Los números
Para los que necesitan justificarlo ante un comité:
Sin despensa (staging temporal, datos sobreescritos): - Tiempo medio de respuesta a auditoría sobre datos históricos: 2-4 semanas (reconstrucción manual, backups parciales, “creemos que era esto”). - Coste de un reproceso: días a semanas (dependes del sistema origen para reenviar datos, si es que puede, si es que alguien sabe cómo hacer una extracción histórica). - Incidencias por cambios no comunicados en origen: descubiertas en producción (cuando el informe ya sale mal), resolución lenta (¿quién hizo el cambio? ¿cuándo? ¿a quién pregunto?). - Capacidad de trabajo en paralelo: limitada (todos comparten las mismas tablas, los cambios de uno pueden pisar al otro).
Con despensa (permanente, organizada, con owners): - Tiempo medio de respuesta a auditoría: minutos (el dato original está ahí, inmutable, con fecha y lote). - Coste de un reproceso: horas (relanzas la transformación sobre los datos de la despensa, sin depender de nadie). - Incidencias por cambios en origen: detectadas en la carga (antes de que afecten al modelo), resolución directa (el owner está declarado, la alerta va al que puede resolver). - Capacidad de trabajo en paralelo: total (las identidades son compartidas, cada equipo añade sus atributos sin conflictos).
Pensad en lo que esto significa para una empresa con 200 tablas fuente y un regulador que cada año pide más datos, más rápido, con más trazabilidad. Sin despensa, cada auditoría es una crisis. Cada reproceso es una negociación con el equipo de sistemas. Cada cambio en origen es una bomba de relojería que puede explotar en producción semanas después.
Con despensa, la auditoría es rutinaria. El reproceso es un botón. El cambio en origen se detecta antes de que haga daño. Y los 15 dominios trabajan en paralelo sin pisarse.
Y si diriges un equipo de datos y estás pensando “vale, pero ¿cuánto cuesta mantener una despensa permanente?”, la respuesta es contraintuitiva: la despensa es más barata que no tenerla. Un terabyte en la nube cuesta entre 20 y 25 euros al mes. Una sola auditoría mal respondida — tres semanas de un equipo de 4 personas reconstruyendo datos — cuesta entre 15.000 y 25.000 euros en horas de trabajo. Añadid los reprocesos, las incidencias detectadas tarde, y la pérdida de confianza de Negocio cada vez que el equipo de datos dice “no lo sé con certeza.”
La despensa no es un gasto. Es un seguro. Y como todo buen seguro, esperas no necesitarlo. Pero el día que lo necesitas, vale cien veces lo que costó.
Además, la despensa habilita algo que sin ella es imposible: la automatización real. Si los datos crudos están organizados con identidades separadas y con responsables declarados, el 80% del trabajo que hoy hacen tus ingenieros de datos de forma manual (investigar incidencias, reconstruir históricos, buscar a quién preguntar) desaparece. Tu equipo deja de apagar fuegos y empieza a construir valor.
La despensa no es un lujo técnico. Es la base sobre la que se construye todo lo demás. Sin ella, estás cocinando desde el camión de reparto y tirando los albaranes. Funciona hasta que deja de funcionar.
Lo que viene: la mise en place
Hoy hemos abierto la despensa. Hemos visto por qué guardar el dato de forma permanente y organizada es la decisión más importante que puedes tomar en una arquitectura de datos. Y hemos visto que organizar la despensa significa separar lo que un dato ES de lo que un dato TIENE, para que cada equipo pueda trabajar en paralelo sin pisarse.
Pero los ingredientes en la despensa están organizados, sí, pero crudos. Sin procesar. Sin aplicar reglas de negocio. El tomate está en la estantería de verduras, etiquetado y fechado. Pero nadie lo ha lavado, pelado, cortado ni sazonado.
La semana que viene entramos en la mise en place: donde los ingredientes crudos se transforman en información de negocio. Donde se aplican las reglas de cálculo (“Prima Neta = Prima Bruta − Reaseguro Cedido”), las derivaciones, las agregaciones. Donde el dato crudo se convierte en algo que Negocio puede usar para tomar decisiones.
Y veremos por qué, si la despensa está bien organizada, la mise en place es sorprendentemente sencilla. Y si no lo está… bueno, ya sabéis lo que pasa.
Pero antes de entrar en la mise en place: