Diseño técnico
Arquitectura del sistema
El Data Warehouse sigue el patrón estándar moderno de Data Engineering: los datos llegan de cada fuente,
se almacenan en bruto, se transforman en modelos limpios y se exponen a través de una interfaz departamental.
Cada capa es independiente y puede evolucionar sin romper las demás.
Fuentes
a3ERP · SQL
Shopify API
HubSpot API
Excel · OneDrive
Ficheros dept.
Ingesta
Conectores Python custom
Airbyte OSS
Airflow (scheduling)
Almacén raw
PostgreSQL · schema raw_*
Datos sin transformar · histórico completo
Transformación
dbt Core · staging_*
dbt · mart_* (modelos de negocio)
Tests de calidad de datos
Visualización
Metabase · dashboards dept.
Acceso por rol · actualización diaria
Warehouse local. Misma estructura que producción. Datos reales de prueba.
Desarrollo y prueba de DAGs en local antes de desplegar.
Modelos y tests desarrollados y validados en local.
Warehouse productivo. Acceso solo interno. Backup diario automático.
Pipelines corriendo automáticamente cada noche. Solo accesible por túnel SSH.
Ejecutado por Airflow tras cada carga. Tests automáticos de calidad.
Reverse proxy. HTTPS con Let's Encrypt. Único punto de entrada externo.
Local validado
──────→
git push
──────→
docker compose up (Hetzner)
Herramientas
Stack tecnológico
Todo el stack es open source, autoalojado y sin dependencia de Microsoft ni de ningún proveedor de licencias. Los costes de infraestructura son predecibles y controlados.
🗄
PostgreSQL 16
Warehouse · almacenamiento
Base de datos relacional probada para cargas analíticas. Gratuita, sin límite de filas, excelente ecosistema.
🔧
dbt Core
Transformación · modelado
Estándar de la industria para transformaciones SQL. Tests de calidad, documentación y linaje de datos incluidos.
⚙️
Apache Airflow
Orquestación · scheduling
Gestiona cuándo y en qué orden se ejecutan todos los pipelines. Reintentos automáticos y alertas en caso de error.
📊
Metabase Community
Visualización · interfaz
Business Intelligence autoalojado. UX intuitiva para usuarios no técnicos. Dashboards, filtros y exploración libre.
🔌
Python + Airbyte OSS
Ingesta · conectores
Scripts Python para a3ERP (SQL directo) y fuentes custom. Airbyte para Shopify y HubSpot (conectores preconstruidos).
🐳
Docker Compose
Contenedores · despliegue
Todo el stack se gestiona con un único archivo de configuración. Reproducible, portable y fácil de actualizar.
Plan de trabajo
Fases del proyecto
El proyecto se ejecuta en cuatro fases solapadas. Las fases 0 y 1 se desarrollan en paralelo desde la primera semana. El primer entregable visible para el cliente llega al final de la Fase 3.
La fase más crítica del proyecto. No se escribe código hasta entender exactamente de dónde sale cada número que aparece en los informes actuales. Se realizan sesiones de shadowing profundo con cada departamento para mapear el linaje real de los datos: dato final → transformación manual → fuente original.
- Sesiones de shadowing con Operaciones, Comercial, Finanzas y Marketing: "muéstrame el último informe que preparaste, campo por campo"
- Catálogo de informes por departamento: nombre, frecuencia, audiencia, tiempo de preparación actual
- Mapeo del schema de a3ERP: exploración del modelo de base de datos, identificación de tablas clave (pedidos, facturas, clientes, artículos, movimientos)
- Inventario de Excels activos: cuáles son fuente real de datos y cuáles son solo reportes intermedios
- Prioridad de informes: ranking de los 3-5 informes más urgentes para la Fase 3
Estructura de cada sesión de shadowing
1
"Muéstrame el último informe que preparaste para la reunión de dirección" — partimos del informe final, no de sistemas abstractos
2
"¿De dónde sacaste cada número?" — trazamos el origen de cada dato hasta su fuente primaria
3
"¿Qué pasos manuales hiciste para construirlo?" — cada paso manual es un candidato a automatizar
4
"¿Qué dato necesitas y nunca tienes cuando lo necesitas?" — identifica las oportunidades más valiosas
Entregable
Mapa de linaje completo por departamento · Catálogo de informes priorizado · Schema de a3ERP documentado · Inventario de fuentes validado
Todo el desarrollo ocurre en local con Docker Desktop. El stack completo (PostgreSQL, Airflow, dbt, Metabase) corre en la máquina del desarrollador, lo que permite iterar rápido sin costes de servidor ni dependencia de conexión. El entorno de producción en Hetzner se crea solo cuando la Fase 3 está validada.
- Setup local con Docker Desktop: docker-compose.yml con PostgreSQL, Airflow, Metabase · volúmenes persistentes · proyecto listo para desarrollar
- Schema base del warehouse: tres schemas en PostgreSQL (
raw, staging, mart) · proyecto dbt inicializado en git
- Conector a3ERP: extracción SQL de tablas clave · carga inicial completa (bulk) · lógica incremental por timestamp · DAG en Airflow
- Conector Shopify: pedidos, líneas de pedido, productos, clientes · extracción incremental via API · DAG en Airflow
- Conector Excel / OneDrive: ficheros identificados en discovery con acceso vía Graph API o carga programada
Entregable
Stack operativo en local · Datos de ERP y Shopify fluyendo hacia PostgreSQL raw_* · Pipeline ejecutándose en local sin errores
Con los datos en bruto fluyendo, se construyen las capas de transformación con dbt. Los datos pasan de estar en bruto (tal como salen del ERP o de Shopify) a estar limpios, documentados y listos para responder preguntas de negocio.
- Capa staging: un modelo por fuente · limpieza de tipos y nombres · tests de not_null, unique y accepted_values · documentación de cada campo
- Mart de pedidos: modelo consolidado ERP + Shopify · estado, importe, canal, cliente, fechas · fuente única de verdad para pedidos
- Mart de facturación: datos de facturación desde ERP cruzados con pedidos de Shopify
- Tests de integridad: validación de que los totales del warehouse coinciden con los totales del ERP original
- DAG de transformación: Airflow ejecuta
dbt run + dbt test tras cada carga · si los tests fallan, el pipeline se detiene y notifica
Entregable
Modelos staging_* y mart_* operativos · Tests de calidad automáticos · Pipeline completo extracción → transformación ejecutándose diariamente
El cliente ve el valor aquí. Metabase se conecta a los marts y se construyen los dashboards exactamente a partir de los informes identificados en el discovery. La validación es directa: si el número del dashboard coincide con el del ERP, el sistema funciona.
- Conexión Metabase → PostgreSQL: usuario de solo lectura sobre schema
mart_* · el cliente nunca ve tablas raw o staging
- Dashboards de Operaciones: construidos sobre los 3-5 informes priorizados en el discovery · misma lógica que antes, automática
- Validación con el cliente: sesión de revisión de datos · cada número del DWH se contrasta con el informe manual equivalente
- Gestión de accesos: usuarios en Metabase por departamento · permisos por colección · cada área ve sus datos, no los del resto
- Documentación y formación: sesión de formación con usuarios de Operaciones · runbook técnico para administración del sistema
Entregable final
Dashboards validados en local · Deploy en Hetzner · Cliente accede a Metabase vía HTTPS · Pipeline corriendo autónomamente cada noche · Usuarios formados · Documentación técnica entregada
Cronograma
Vista temporal del proyecto
Las fases se solapan por diseño. El discovery alimenta directamente el desarrollo de conectores y modelos sin esperar a que termine.
| Fase / Actividad |
S1 | S2 | S3 | S4 |
S5 | S6 | S7 | S8 |
S9 | S10 | S11 | S12 |
| F0 · Discovery y mapeo |
|
|
|
|
|
|
|
|
|
|
|
|
| F1 · Infraestructura y conectores |
|
|
|
|
|
|
|
|
|
|
|
|
| F2 · Transformaciones dbt |
|
|
|
|
|
|
|
|
|
|
|
|
| F3 · Interfaz y dashboards |
|
|
|
|
|
|
|
|
|
|
|
|
Primer paso
Por dónde empezamos
Antes de tomar ninguna decisión técnica, necesitamos entender qué hay realmente. Los primeros pasos son de escucha y exploración, no de construcción.
📋
Confirmación de accesos existentes
Verificar qué accesos están realmente operativos hoy: conexión SQL a a3ERP, credenciales de Shopify y HubSpot. Sin acceso confirmado no hay datos, y sin datos no hay proyecto.
🔍
Primera sesión de shadowing
Una sola sesión, un solo departamento, un solo informe real. El objetivo no es entender todo, sino entender una cosa bien: de dónde sale un número concreto que alguien usa hoy.
🗄
Exploración inicial del schema de a3ERP
Conectarse y listar tablas. Nada más. Ver qué hay, cuántas filas, qué columnas. Antes de asumir qué datos existen, hay que comprobar que existen y que son utilizables.
📁
Inventario de Excels activos
Pedir a cada departamento los ficheros que usan de verdad cada semana. Sin este paso es fácil construir conectores para ficheros que nadie usa o que cambian de formato constantemente.
⚠️
Identificación de riesgos de datos
Detectar inconsistencias evidentes antes de empezar: campos nulos donde no deberían, fechas sin sentido, registros duplicados. Mejor saberlo ahora que descubrirlo en la Fase 2.
🎯
Definición del primer entregable concreto
Al terminar el discovery, acordar un único informe como objetivo de la Fase 1. No "tener los datos de Operaciones", sino algo medible: "este informe, con estos campos, actualizado cada día".