En resumen
Un data mart es un subconjunto del data warehouse dedicado a un área funcional específica — ventas, finanzas, marketing — modelado para las necesidades de reporte de ese equipo. Los marts surgieron para escalar el acceso analítico sin exponer la complejidad del modelo dimensional completo. El patrón Inmon construye el warehouse primero y deriva los marts; Kimball construye los marts primero y el warehouse emerge de la integración. En la práctica moderna (dbt + warehouse cloud), los marts son típicamente lógicos — carpetas de modelos, proyectos de capa semántica — no bases de datos físicas separadas. Las dimensiones conformadas entre marts son no negociables: sin ellas, cada área tiene su propio "número de clientes" y la organización pierde la capacidad de responder preguntas cross-funcionales con consistencia.
Definición
Un data mart es un subconjunto del data warehouse organizacional, diseñado para servir las necesidades analíticas de una función de negocio específica — un equipo, un departamento, o un dominio operacional. El mart de ventas contiene los datos que el equipo comercial necesita para analizar pipeline, win rates, rendimiento por representante y cumplimiento de cuota. El mart de finanzas contiene los datos que el CFO necesita para analizar P&L, flujo de caja, presupuesto versus actuals y márgenes. El mart de marketing contiene los datos del equipo de demanda para analizar fuentes de pipeline, eficiencia de canales pagados y atribución.
La distinción entre el warehouse central y sus marts es principalmente organizacional y de acceso, no técnica. El warehouse central integra datos de todas las fuentes y contiene el modelo dimensional completo de la organización — con conformed dimensions que permiten responder preguntas que cruzan múltiples áreas funcionales. Los marts simplifican ese modelo al exponer solo los datos relevantes para un dominio, con los nombres y estructuras que ese equipo reconoce. Esta simplificación es relevante porque un modelo dimensional completo para una empresa de tamaño medio puede incluir decenas de tablas de hechos y cientos de atributos de dimensiones — una complejidad innecesaria para el analista de ventas que solo necesita responder preguntas sobre su pipeline.
Cómo se estructura un data mart
Los data marts se estructuran típicamente con un modelo dimensional (star schema o snowflake schema): una o varias tablas de hechos centrales que contienen los eventos medibles del dominio, rodeadas de tablas de dimensiones que aportan el contexto descriptivo. El mart de ventas tiene como tabla de hechos central la tabla de oportunidades o transacciones cerradas, con dimensiones de cliente, vendedor, producto, geografía y período. El mart de marketing tiene como hechos las conversiones y los gastos de canal, con dimensiones de fuente, campaña, segmento de audiencia y período.
Componentes de un data mart típico de ventas B2B:
- Hecho central: fct_opportunities — una fila por oportunidad con ARR, etapa, probabilidad, fechas de apertura y cierre.
- Dimensión Cliente: dim_customers — nombre, industria, tamaño, segmento ICP, país.
- Dimensión Vendedor: dim_reps — nombre, región, manager, cuota asignada.
- Dimensión Período: dim_date — año, trimestre, mes, semana fiscal.
- Hecho secundario: fct_activities — llamadas, reuniones, emails por oportunidad para análisis de actividad.
Ejemplo práctico
Una empresa de SaaS B2B en Bogotá con MXN $45 millones (equivalente a aproximadamente COP $12,000 millones) de ARR tiene tres equipos analíticos diferenciados: el equipo de ventas (8 representantes, 2 managers de ventas, un director comercial), el equipo de finanzas (CFO y dos analistas financieros) y el equipo de marketing (tres personas focalizadas en demanda y contenido). El equipo de datos tiene dos ingenieros que mantienen el stack de datos sobre BigQuery con dbt.
El equipo de datos decidió organizar sus modelos dbt en tres carpetas de marts: marts/sales, marts/finance y marts/marketing. El mart de ventas expone modelos como rep_performance (rendimiento por representante), pipeline_snapshot (estado del pipeline al cierre de cada semana) y win_loss_by_source (análisis de oportunidades ganadas y perdidas por fuente de lead). El mart de finanzas expone modelos como arr_movements (movimientos de ARR: nuevos, expansión, contracción, cancelación), mrr_by_segment (MRR por segmento de cliente) y budget_vs_actuals (ejecución presupuestaria mensual). El mart de marketing expone modelos como channel_efficiency (costo por lead calificado por canal) y pipeline_contribution (pipeline generado por fuente).
Análisis en profundidad
La historia de los data marts está íntimamente ligada a los dos enfoques arquitecturales que dividieron el campo de la inteligencia de negocio durante dos décadas: el enfoque de Bill Inmon y el enfoque de Ralph Kimball. Inmon, considerado el padre del data warehousing, propuso un enfoque top-down: primero se construye la corporate information factory — un warehouse centralizado con datos normalizados en tercera forma normal (3NF) — y los data marts son vistas o subconjuntos derivados de ese repositorio central. La ventaja del enfoque Inmon es que garantiza consistencia desde el centro: hay una sola fuente de verdad que todos los marts consumen.
Kimball propuso el enfoque opuesto, bottom-up: los equipos construyen data marts dimensionales para sus casos de uso específicos primero, y el warehouse emerge de la federación de múltiples marts con dimensiones conformadas. La ventaja del enfoque Kimball es la velocidad de entrega: el equipo de ventas puede tener su mart funcionando en semanas sin esperar que el warehouse central esté completo. El riesgo es la fragmentación: si los marts se construyen de forma independiente sin dimensiones conformadas, eventualmente cada área tiene su propia definición de "cliente", "ingreso" y "período", y la organización pierde la capacidad de responder preguntas cross-funcionales con consistencia.
En la práctica de 2025, la distinción física entre warehouse central y data mart se ha vuelto en gran parte irrelevante. Con herramientas como dbt corriendo sobre Snowflake, BigQuery o Redshift, un "data mart" es simplemente una carpeta de modelos — una organización lógica dentro del mismo warehouse físico. El mart de ventas no es una base de datos separada con su propio servidor: es un conjunto de vistas y tablas materializadas en el mismo warehouse, accesibles a través de la misma herramienta de BI, pero organizadas semánticamente para el equipo de ventas. Esta evolución elimina la mayoría de las complejidades operacionales del patrón de mart físico — sincronización de datos entre sistemas, latencia adicional, costos de infraestructura duplicados — mientras preserva los beneficios organizacionales.
El concepto de dimensiones conformadas sigue siendo el elemento más crítico del patrón de data mart, independientemente de si los marts son físicos o lógicos. Una dimensión conformada es aquella que tiene exactamente la misma definición, los mismos atributos y los mismos valores clave en todos los marts que la utilizan. La dimensión Cliente en el mart de ventas debe tener el mismo customer_id, los mismos atributos de segmentación y la misma lógica de actualización que la dimensión Cliente en el mart de finanzas y en el mart de soporte. Si el mart de ventas define "cliente activo" como cualquier cuenta con al menos un contrato vigente, y el mart de finanzas define "cliente activo" como cualquier cuenta con al menos un pago recibido en los últimos 90 días, el CEO que pregunta cuántos clientes activos tiene la empresa obtendrá dos números diferentes según a quién le pregunte.
En el contexto LATAM, el patrón de data mart tiene relevancia particular para empresas en crecimiento que operan en múltiples países — México, Colombia, Chile, Argentina — con diferentes monedas, diferentes regulaciones fiscales y diferentes equipos locales. Un mart de finanzas para una empresa multi-país en LATAM necesita manejar conversión de moneda a MXN o USD como moneda de reporte, reconocimiento de ingresos según las normas locales (IFRS en Colombia, NIIF en México), y segmentación de clientes que respete las particularidades del mercado local. La dimensión conformada de moneda y la dimensión conformada de período fiscal son no negociables en este contexto para asegurar comparabilidad entre países.
Errores frecuentes
- ✗
Construir marts sin dimensiones conformadas entre ellos. El error más costoso en implementaciones de data mart es dejar que cada equipo defina sus propias dimensiones de forma independiente. El equipo de ventas define la dimensión Cliente con su taxonomía de CRM; el equipo de finanzas la define con su taxonomía de billing; el equipo de soporte la define con su taxonomía de tickets. El resultado es que la organización no puede responder preguntas cross-funcionales — "¿cuál es el LTV de los clientes que usan la funcionalidad X?" — sin trabajo manual de reconciliación. Las dimensiones conformadas son la infraestructura de integridad analítica de la organización y deben diseñarse centralmente desde el inicio.
- ✗
Construir marts físicos separados cuando un mart lógico es suficiente. En el contexto de stacks de datos modernos sobre cloud warehouses, construir marts como bases de datos físicas separadas añade complejidad sin beneficio real en la mayoría de los casos. Se crean pipelines de sincronización adicionales, se introduce latencia entre el warehouse central y el mart, y se duplican los costos de almacenamiento. Los marts lógicos — carpetas de modelos en dbt, proyectos en la capa semántica — ofrecen el mismo beneficio organizacional (datos orientados al dominio, control de acceso por área) con mucho menor complejidad operacional.
- ✗
Tratar el data mart como el destino final de la analítica sin añadir una capa de presentación. Un data mart con modelos dimensionales bien construidos es una base excelente para la analítica, pero no es por sí solo accesible para los usuarios de negocio. Sin una capa semántica que traduzca los nombres técnicos de tablas y columnas a términos de negocio, o sin dashboards preconstruidos que respondan las preguntas más frecuentes, los usuarios de negocio terminan dependiendo del equipo de datos para cada consulta. El mart resuelve el problema de organización de datos; la capa de presentación resuelve el problema de acceso para los usuarios no técnicos.
Cómo lo rastrea Fairview
Fairview actúa como la capa de operating intelligence sobre la arquitectura de datos existente de la empresa — incluyendo data marts ya construidos o en construcción. Cuando una empresa tiene un mart de ventas en BigQuery con dbt y un mart de finanzas en Snowflake, Fairview se conecta a ambas fuentes y genera una visión integrada de las métricas operacionales que cruzan los dos dominios: el costo de adquisición de clientes (que requiere datos de marketing y ventas), el LTV neto (que requiere datos de ventas, finanzas y soporte), y el análisis de margen por segmento (que requiere datos de ventas y de costos financieros). En lugar de requerir que el equipo de datos construya modelos cross-mart adicionales, Fairview realiza esa integración en su propia capa y la expone como métricas operacionales listos para decisión. Para equipos que están diseñando su primera arquitectura de marts o que tienen marts existentes pero inconsistencias de definición entre áreas, Fairview puede evaluar el estado actual e identificar qué gaps de datos impiden tener visibilidad operacional completa.
Preguntas frecuentes
¿Cuál es la diferencia entre un data mart y un data warehouse?
El data warehouse es el repositorio analítico central de la organización — contiene todos los datos históricos de todas las áreas funcionales, modelados con dimensiones conformadas y hechos integrados. El data mart es un subconjunto del warehouse enfocado en un área específica: el mart de ventas solo contiene datos relevantes para el equipo comercial; el mart de finanzas solo contiene los datos que necesita el CFO. Un mart puede ser físico (base de datos separada) o lógico (carpeta de modelos o proyecto en la capa semántica). El warehouse integra; el mart simplifica y enfoca.
¿Qué son las dimensiones conformadas y por qué son críticas entre data marts?
Las dimensiones conformadas son dimensiones compartidas que tienen la misma definición y claves en todos los data marts de la organización. Por ejemplo, la dimensión Cliente debe tener los mismos atributos e identificadores tanto en el mart de ventas como en el mart de finanzas. Sin dimensiones conformadas, cada mart desarrolla su propia definición de Cliente, y cuando el CEO pregunta cuántos clientes tiene la empresa, ventas, soporte y finanzas responden con números distintos porque están contando definiciones diferentes.
¿Cuándo conviene un data mart físico versus uno lógico?
Un data mart físico (base de datos separada) conviene cuando el equipo del dominio necesita máxima velocidad de consulta independiente, cuando hay restricciones de acceso muy estrictas que requieren separación de almacenamiento, o cuando se trabaja con herramientas de BI heredadas que no soportan acceso federado. Un data mart lógico (carpeta de modelos dbt o proyecto en la capa semántica) es la opción moderna preferida porque elimina redundancia de datos, reduce costos de almacenamiento y mantiene una fuente de verdad única.
¿Cuál es la diferencia entre el enfoque Inmon y el enfoque Kimball para data marts?
Inmon propuso el enfoque top-down: primero se construye el warehouse centralizado normalizado, y los data marts son subconjuntos derivados. Kimball propuso el enfoque bottom-up: los marts dimensionales se construyen primero para casos de uso específicos, y el warehouse emerge de su integración. En la práctica moderna con stacks como dbt + BigQuery o Snowflake, la distinción se vuelve más lógica que física: los data marts son capas de modelos organizadas por dominio sobre un warehouse único.