pero en realidad, pequeños matices en el diseño de su arquitectura de datos pueden tener implicaciones costosas. Por lo tanto, en este artículo quería ofrecer un curso intensivo sobre las arquitecturas que dan forma a sus decisiones diarias, desde bases de datos relacionales hasta sistemas controlados por eventos.
La arquitectura de datos es el modelo que determina dónde residen sus datos, cómo se mueven entre sistemas, qué les sucede durante las transformaciones y quién tiene acceso a qué. Piense en ello como el diseño de una ciudad: áreas residenciales, distritos comerciales, zonas industriales y las redes de transporte que conectan todo.
Antes de comenzar, quiero que recuerdes esto: tu arquitectura determina si tu organización es como una ciudad bien planificada con carreteras eficientes y zonificación clara, o como una metrópolis que creció sin ninguna planificación y ahora tiene atascos de tráfico por todas partes.
He visto esto de primera mano. Una empresa que había crecido rápidamente a través de adquisiciones había heredado los sistemas de datos de cada empresa que compraba y nadie se había tomado el tiempo para pensar en cómo encajaban todos. Los datos de los clientes vivían en cinco sistemas CRM diferentes, los datos financieros se dividían entre tres ERP diferentes y cada sistema tenía su propia definición de conceptos básicos como cliente e ingresos. Su revisión comercial “semanal” tardó dos semanas en prepararse. Seis meses después, tras implementar una arquitectura de datos bien pensada, pudieron generar la misma reseña en menos de dos horas.
La diferencia no fue la última tecnología ni los enormes presupuestos. Se trataba simplemente de tener un enfoque reflexivo sobre cómo se deberían organizar y gestionar los datos.
En este artículo, lo guiaré a través de los tipos de arquitectura de datos principales, sus fortalezas, debilidades y dónde cada uno realmente brilla. ¡Abróchense los cinturones!
1. Base de datos relacional: el buen vino añejo
Las bases de datos relacionales se remontan a la década de 1970, cuando Edgar F. Codd propuso el modelo relacional. En esencia, una base de datos relacional es un archivador digital altamente organizado. Cada mesa es un cajón dedicado a una cosa, piensa en clientes, pedidos, productos. Cada fila es un registro único, cada columna un atributo específico.
La parte relacional es de donde proviene el poder. La base de datos comprende cómo se conectan las tablas. Sabe que el Cliente X en la tabla Clientes es el mismo Cliente X que realizó un pedido en la tabla Pedidos. Esta estructura es la que nos permite hacer preguntas complejas usando SQL.
Cuando trabaja con bases de datos relacionales, sigue una regla estricta llamada esquema en escritura. Piensa en construir una casa: debes tener un plano detallado antes de poder empezar a sentar las bases. Usted define cada habitación, cada ventana y cada puerta desde el principio. Los datos deben ajustarse perfectamente a este plano cuando los guarde. Este trabajo inicial garantiza que todo sea coherente y que los datos sean confiables.
El enfoque opuesto, llamado esquema en lectura, es como tirar todos los materiales de construcción en una gran pila. No hay ningún plan para empezar. Sólo decides cómo estructurarlo cuando necesitas construir algo. ¿Flexible? Absolutamente. Pero pone la carga de dar sentido al caos a quien analice los datos más tarde.
2. Almacén de datos relacional: el campo de juego del analista
Las bases de datos relacionales eran (y siguen siendo) fantásticas para ejecutar las operaciones diarias de una empresa: procesar pedidos, gestionar el inventario y actualizar los registros de los clientes. A estos los llamamos sistemas operativos (OLTP) y deben ser ultrarrápidos.
Pero esto creó un gran desafío: lo que me gusta llamar “¡No toques el sistema en vivo!”. problema. Los líderes empresariales necesitaban analizar datos. Pero ejecutar consultas analíticas complejas en la misma base de datos en vivo que procesa miles de transacciones por minuto paralizaría todo. Es como intentar hacer un recuento profundo del inventario en un supermercado concurrido durante las horas pico.
¿La solución? Cree un campo de juego separado para los analistas. Nació el almacén de datos relacional: una base de datos dedicada construida específicamente para el análisis, donde se centralizan copias de datos de varios sistemas operativos.
Dos escuelas de pensamiento: Inmon vs. Kimball
Hay dos enfoques fundamentales para construir un almacén de datos. El enfoque de arriba hacia abajo, introducido por Bill Inmon – “el padre del almacén de datos” – comienza diseñando primero el almacén de datos general y normalizado, y luego creando a partir de él data marts específicos para cada departamento. Le brinda una representación de datos consistente y una duplicación reducida, pero conlleva altos costos iniciales y complejidad.
El enfoque ascendente, defendido por Ralph Kimball, invierte esta situación. Empiece por crear mercados de datos individuales para departamentos específicos utilizando tablas de dimensiones y hechos desnormalizados. Con el tiempo, estos se conectan a través de dimensiones conformadas para formar una vista unificada. Es más rápido comenzar, más flexible y más barato, pero corre el riesgo de inconsistencias y silos de datos si no se administra con cuidado.
Ninguno de los dos enfoques es universalmente “mejor”. La estrategia de arriba hacia abajo funciona bien para organizaciones grandes que necesitan coherencia en toda la empresa. El enfoque ascendente brilla cuando se necesitan resultados rápidos y una entrega iterativa. La mayoría de las implementaciones del mundo real terminan siendo una combinación pragmática de ambos.
3. Lago de datos: la promesa y el pantano
Alrededor de 2010, surgió un nuevo concepto que prometía resolver todos nuestros problemas (¿te suena familiar?): el lago de datos. El argumento de venta era atractivo: a diferencia de un almacén de datos estructurado, un lago de datos era esencialmente un espacio de almacenamiento masivo y barato. No necesita un plan, simplemente coloque todo allí: datos estructurados, archivos de registro, archivos PDF, feeds de redes sociales e incluso imágenes y videos. Guarde todo ahora y averigüe qué hacer con él más tarde.
Este es el enfoque de esquema en lectura en la práctica. Y a diferencia de los almacenes de datos relacionales, que proporcionan almacenamiento y computación, un lago de datos es solo almacenamiento, no un motor de computación incluido. Se basa en el almacenamiento de objetos, que no requiere que los datos estén estructurados en forma de tabla.
Durante un tiempo, el revuelo fue real. Entonces la realidad golpeó. Almacenar datos en un lago fue fácil; sacarlos de una manera útil fue increíblemente difícil. A los usuarios empresariales se les dijo: “¡Oye, todos los datos están en el lago! Simplemente abre un cuaderno Jupyter y usa algo de Python para analizarlos”. La mayoría de los usuarios empresariales no tenían habilidades avanzadas de codificación. El lago cristalino rápidamente se convirtió en un pantano de datos turbio e inutilizable.
Pero el lago de datos no desapareció. La industria se dio cuenta de que la visión inicial era defectuosa, pero la tecnología central siguió siendo increíblemente útil. Hoy en día, el lago de datos ha encontrado su verdadera vocación: no como reemplazo del almacén, sino como área de preparación y preparación: el lugar perfecto para obtener datos sin procesar antes de decidir qué limpiar, transformar y promover para un análisis confiable.
4. Data Lakehouse: lo mejor de ambos mundos
Cuando combinas un almacén de datos y un lago de datos, ¿qué obtienes? Una casa de lago de datos. Databricks fue pionero en este término alrededor de 2020, y el concepto ha ido ganando terreno desde entonces.
Casi puedo oírte preguntar: “Espera, ¿no acabas de decir que los lagos de datos fallaron espectacularmente al tratar de satisfacer exactamente estos requisitos? ¿Por qué funcionaría esto ahora?”.
Pregunta justa. Hubo un único cambio en el enfoque clásico del lago de datos, pero fue lo suficientemente grande como para cambiar todo el paradigma: agregar una capa de almacenamiento transaccional sobre el almacenamiento del lago de datos existente. Esta capa, ejemplificada por Delta Lake, Apache Iceberg y Apache Hudi, permite que el lago de datos funcione más como un sistema de gestión de bases de datos relacional tradicional, con transacciones ACID, aplicación de esquemas y viajes en el tiempo.
Lakehouse promueve una idea convincente: eliminar la necesidad de un almacén de datos relacional separado y aprovechar solo un lago de datos para toda su arquitectura. Todos los formatos de datos: estructurados, semiestructurados y no estructurados, se almacenan en el lago y todos los análisis se realizan directamente desde allí. La capa transaccional es el ingrediente que falta para que esto sea factible.
5. Data Mesh: descentralización de la propiedad de los datos
Entonces, los data lakehouses resolvieron el problema de almacenamiento y análisis. Caso cerrado, ¿verdad? No exactamente. A medida que las empresas crecían, incluso una gran plataforma de datos centralizada creaba un nuevo cuello de botella.
Piense en su equipo de datos central como la cocina de un restaurante muy popular. Marketing, Ventas, Finanzas y Logística realizan “pedidos” complejos (solicitudes de datos). El personal de cocina (sus ingenieros de datos) está capacitado pero desbordado. No tienen una comprensión profunda y matizada de cada “plato”. El equipo de marketing pide una segmentación de clientes y la cocina primero tiene que preguntar: “¿Qué entiendes por cliente activo?” ¿El resultado? Una larga fila de “clientes” frustrados y un personal de cocina agotado.
La malla de datos plantea una pregunta radical: ¿qué pasaría si, en lugar de una cocina central, le diésemos a cada departamento su propia estación de cocina especializada? ¿Y qué pasaría si responsabilizaramos a los expertos en el dominio (las personas que realmente conocen sus propios datos) de preparar productos de datos de alta calidad para todos los demás?
La malla de datos se basa en cuatro principios clave: propiedad orientada al dominio (las personas más cercanas a los datos son propietarias), datos como un producto (tratados con el mismo cuidado que cualquier producto orientado al cliente), una plataforma de datos de autoservicio (el equipo central proporciona la infraestructura, los dominios construyen los productos) y gobernanza computacional federada (estándares globales aplicados a través de un consejo con representantes de los dominios).
Una advertencia: la malla de datos no es una tecnología que se compra e instala. Es un cambio sociotécnico, tanto de estructura organizacional y cultura como de tecnología. No es para todas las empresas, especialmente las más pequeñas. Los equipos de dominio necesitan experiencia técnica genuina y un compromiso a largo plazo, y el intercambio de datos puede convertirse fácilmente en una cuestión política.
6. Arquitectura basada en eventos: el vecino chismoso
Ahora cambiemos de tema. Piense en la arquitectura basada en eventos como el enfoque del vecino chismoso hacia los datos: sistemas que reaccionan instantáneamente a las cosas que suceden, en lugar de buscar actualizaciones constantemente. En lugar de que el Sistema B le pregunte al Sistema A cada cinco minutos “Oye, ¿ya pasó algo?” (como revisar su refrigerador con la esperanza de que la comida haya aparecido mágicamente), un sistema impulsado por eventos le toca el hombro en el momento en que ocurre algo importante.
¿Un cliente hace un pedido? Eso es un evento. El sistema que lo crea es el productor. Los sistemas que escuchan y reaccionan son los consumidores. Y el intermediario donde se publican los eventos es el corredor de eventos: piense en Apache Kafka, Azure Event Hubs o Eventstream en Microsoft Fabric.
La belleza reside en las palabras ligeramente acopladas. El equipo de marketing puede poner en marcha un nuevo servicio que escuche los eventos de “Cliente registrado” sin necesidad de que el equipo de ventas cambie una sola línea de código. Si el servicio de correo electrónico de bienvenida falla, los nuevos clientes aún se registran; los eventos simplemente se acumulan en el corredor, esperando que el servicio se recupere.
Pero este poder conlleva compensaciones. Ahora tiene una nueva infraestructura que administrar. La depuración se vuelve más difícil porque cuando algo sale mal, rastrear un solo evento en múltiples sistemas desacoplados puede ser un desafío serio. Y el corredor no siempre garantiza el orden de entrega: es posible que obtenga un evento “Pedido enviado” antes del evento “Pedido pagado”.
Cuándo usarlo: análisis en tiempo real (IoT, flujo de clics, detección de fraude), integración de microservicios y flujos de trabajo asincrónicos.
Cuándo NO usarlo: aplicaciones CRUD simples, flujos de trabajo estrechamente acoplados que requieren respuestas inmediatas garantizadas y sistemas estrictamente transaccionales donde los procesos de varios pasos deben tener éxito o fallar de forma atómica.
La hoja de trucos
No existe una fórmula mágica: cada arquitectura tiene su lugar. Aquí está la comparación rápida para ayudarle a decidir:
La conclusión clave
Comprender cuándo utilizar cuál es la habilidad crucial para cualquier ingeniero analítico. Todos los días tomas decisiones sobre cómo estructurar los datos, dónde almacenarlos, cómo transformarlos y cómo hacerlos accesibles. Estas decisiones pueden parecer menores en este momento: ¿debo crear esto como una vista o una tabla? ¿Dónde debería poner esta lógica de transformación? – pero se suman para crear la base sobre la que se asienta todo su ecosistema de análisis.
El panorama de la arquitectura de datos ha evolucionado desde bases de datos relacionales normalizadas hasta el sistema “¡no toques el sistema en vivo!”. era de los almacenes de datos, más allá del espectacular ascenso y caída (y redención) de los lagos de datos, hacia el paradigma de la casa del lago que nos brinda lo mejor de ambos mundos. Los enfoques modernos, como la malla de datos, hacen que la propiedad recaiga en las personas más cercanas a los datos, y las arquitecturas basadas en eventos permiten que los sistemas reaccionen instantáneamente en lugar de buscar actualizaciones constantemente.
¡Gracias por leer!