Construye los pipelines de datos que alimentan las features y los modelos del producto: los patrones de arquitectura, las herramientas (dbt, Airflow, Spark) y las decisiones de diseño que afectan a la escalabilidad.
Cuándo usarlo: Diseñar la arquitectura de datos completa que alimenta las features analíticas y los modelos ML de un producto digital.
Herramienta recomendada: Claude
Eres un arquitecto de datos senior con experiencia en construir plataformas de datos para productos digitales. Necesito diseñar la infraestructura de datos que soporte las features analíticas y los modelos de ML de mi producto. **Mi contexto:** [DESCRIBE TU PRODUCTO: tipo de aplicación, volumen de datos, eventos por día, fuentes de datos principales, equipo de ingeniería disponible, stack tecnológico actual] **Objetivos:** [QUÉ QUIERES HABILITAR: recomendaciones personalizadas, detección de fraude, análisis de comportamiento, predicciones de churn, features de inteligencia en el producto, etc.] --- Diseña la arquitectura completa de datos para mi caso: **1. Ingesta y captura de eventos** La base de todo: capturar los datos correctamente desde el principio: - Diseño del esquema de eventos: la estructura que hace que los datos sean útiles en el futuro, con propiedades de contexto, identidad y negocio bien definidas - Event tracking plan: cómo documentar qué se trackea, por qué, quién es el owner y cuándo se depreca - SDK de tracking vs. API server-side: cuándo usar cada uno y las implicaciones de privacidad y fiabilidad - Cómo gestionar la identidad del usuario a través de sesiones, dispositivos y el estado pre/post login **2. Arquitectura del data warehouse** Dónde vive todo: - Comparativa BigQuery vs. Snowflake vs. Redshift vs. Databricks para mi caso concreto - Modelo de datos: raw layer, staging y marts, con el diseño de los fact y dimension tables más importantes para mi producto - Estrategias de particionamiento y clustering para optimizar el coste y la velocidad de las queries - Gestión del schema evolution: cómo añadir columnas y cambiar tipos sin romper los pipelines existentes **3. Transformaciones con dbt** El corazón del stack moderno: - Cómo organizar el proyecto dbt: la estructura de carpetas, los naming conventions y las capas de transformación - Los tests esenciales: not_null, unique, relationships y cómo escribir tests de negocio custom - Materialización: cuándo usar table, view, incremental y snapshot - Cómo documentar los modelos para que todo el equipo entienda qué hace cada tabla **4. Orquestación y pipelines** Airflow, Prefect o Dagster: cuál elegir y cómo configurarlo: - Diseño de los DAGs para mi caso: las dependencias, los retries y el manejo de errores - Cómo gestionar las credenciales y los secrets en los pipelines - Monitorización: las alertas que necesito para saber que los pipelines están funcionando antes de que alguien lo reporte - El ciclo de vida de los datos: particiones, retención y archivado **5. Datos en tiempo real** Cuando el batch no es suficiente: - Cuándo necesito realmente streaming y cuándo el near-real-time con micro-batches es suficiente - Kafka vs. Kinesis vs. Pub/Sub: la comparativa honesta para mi escala - Cómo construir el serving layer para features que el producto necesita con latencia baja - Feature stores: cuándo tiene sentido y qué herramientas usar (Feast, Tecton, Hopsworks) **6. Calidad de datos y observabilidad** Los datos malos son peores que no tener datos: - Data contracts: cómo formalizar los acuerdos entre productores y consumidores de datos - Herramientas de data quality: Great Expectations, dbt tests, Monte Carlo - Data lineage: cómo saber qué tabla afecta a qué feature del producto - El proceso para investigar y corregir anomalías en producción sin pánico **7. Gobierno y privacidad** Lo que no puedes ignorar: - PII: cómo identificarlo, tokenizarlo o anonimizarlo en el pipeline - GDPR/CCPA: el derecho al olvido en un data warehouse y cómo implementarlo técnicamente - Control de accesos: el principio de mínimo privilegio en los datos Termina con un roadmap de 6 meses para construir esta infraestructura desde cero con un equipo pequeño, priorizando qué construir primero según el impacto en el producto.