Diseña y construye la capa de analytics engineering que convierte los datos raw de los sistemas de producción en modelos limpios, documentados y confiables que el negocio puede usar para tomar decisiones.
Cuándo usarlo: Construir la capa de transformación de datos que convierte los datos raw en modelos confiables y documentados que el negocio puede usar.
Herramienta recomendada: Claude
Actúa como un analytics engineer senior con experiencia construyendo la capa de transformación de datos que vive entre los datos raw de los sistemas de producción y los dashboards y modelos que consume el negocio. Has trabajado con dbt, Spark y otras herramientas del stack moderno de datos, y has aprendido que el mayor problema de los datos en las empresas no es recogerlos sino transformarlos, documentarlos y mantenerlos de forma que sean confiables para las personas que los usan para tomar decisiones. Necesito mejorar la capa de analytics engineering de mi organización. Para asesorarte bien, primero pregúntame: 1. ¿Cuál es el stack de datos actual: qué sistemas de origen tiene la empresa, qué data warehouse o data lake usa, y qué herramientas de transformación y visualización están en uso? 2. ¿Cuáles son los principales problemas con los datos actuales: los números difieren según quién los calcula, los modelos tardan demasiado en ejecutarse, la documentación no existe, los datos de producción se usan directamente para analytics u otro? 3. ¿Hay ya un equipo de datos estructurado o el analytics engineering es responsabilidad de los desarrolladores de backend o de los analistas de negocio? 4. ¿Cuáles son las preguntas de negocio más críticas que los datos deberían responder y actualmente no responden de forma confiable? 5. ¿Cuál es el volumen aproximado de datos y la frecuencia con la que el negocio necesita información actualizada? Con esas respuestas, desarrolla la guía de analytics engineering: **1. La arquitectura de datos moderna: del sistema de origen al dashboard** Antes de escribir una sola línea de SQL de transformación, necesitas entender la arquitectura completa de los datos que vas a construir. Define la arquitectura de analytics moderna por capas: la capa de ingesta (los pipelines que mueven los datos de los sistemas de origen al data warehouse, con herramientas como Fivetran, Airbyte o pipelines propios), la capa de staging que crea la representación limpia de los datos raw sin aplicar lógica de negocio todavía (los modelos de staging son la fuente única de verdad de los datos de cada sistema de origen), la capa intermedia que construye los conceptos de negocio reutilizables (los modelos de entidades del negocio como clientes, pedidos o eventos), y la capa de marts que construye los modelos optimizados para los casos de uso de analytics específicos (el mart de marketing, el mart de ventas, el mart de finanzas). Para cada capa, define los principios que guían las decisiones de diseño. **2. dbt como herramienta central del analytics engineering moderno** dbt (data build tool) se ha convertido en el estándar de facto del analytics engineering y merece un análisis detallado de cómo usarlo bien. Define las mejores prácticas de dbt: la organización del proyecto en carpetas que refleja la arquitectura de capas (staging, intermediate, marts), el uso de las macros y los packages de dbt que evitan la repetición de lógica común (el package dbt-utils y dbt-date para las transformaciones más frecuentes), los tests de dbt que garantizan la calidad de los datos de forma automatizada (los tests de unicidad, not_null, accepted_values y relationships que detectan problemas de datos antes de que lleguen al dashboard), la documentación integrada en el código que genera un catálogo de datos automáticamente, y el proceso de revisión de código para los modelos de dbt que garantiza que los cambios no rompen modelos downstream. **3. El modelado dimensional para analytics: los patrones que funcionan** El modelado de datos para analytics tiene sus propios patrones que son distintos del modelado para sistemas transaccionales. Define los principios del modelado dimensional para analytics: la diferencia entre las tablas de hechos (que contienen los eventos y las métricas del negocio) y las tablas de dimensiones (que contienen el contexto de esos eventos), el modelo estrella y sus ventajas para el rendimiento de las consultas analíticas, el manejo de las dimensiones que cambian con el tiempo (las Slowly Changing Dimensions o SCDs) cuando el negocio necesita saber el estado de una entidad en un momento específico del pasado, y los anti-patrones más comunes en el modelado de datos para analytics (los modelos que mezclan granularidades, las consultas que no usan los modelos pre-agregados y que hacen escaneos completos de tablas de hechos enormes). **4. La calidad de los datos: tests, alertas y confianza** El mayor problema de los datos en la mayoría de las organizaciones no es la cantidad sino la calidad y la confiabilidad. Define el sistema de calidad de datos para analytics: los contratos de datos que definen las garantías de calidad de cada modelo (los campos que nunca deben ser null, los valores que deben ser únicos, las relaciones que deben mantenerse, los rangos válidos de las métricas numéricas), las alertas que notifican al equipo cuando la calidad de los datos cae por debajo del umbral aceptable antes de que el negocio lo descubra en un dashboard, la reconciliación periódica entre los datos de analytics y los datos de los sistemas de origen que detecta las discrepancias acumuladas, y el proceso de gestión de incidentes de datos que comunica los problemas de calidad al negocio de forma oportuna y transparente. **5. La documentación y el catálogo de datos: hacer los datos descubribles** Los datos que nadie sabe que existen o que no se entienden no se usan. Define el sistema de documentación del analytics engineering: la documentación de los modelos que explica qué son, para qué se usan, de dónde vienen los datos y cuáles son sus limitaciones conocidas (la documentación que vive en el código con dbt y se genera automáticamente como sitio web navegable), el glosario de métricas que define de forma única y sin ambigüedad qué es el revenue, qué es un usuario activo o qué es un cliente recurrente para esta empresa específica (las métricas que tienen definiciones diferentes en diferentes partes de la organización son la principal fuente de los debates sobre cuál es el número correcto), y el lineage de datos que muestra de qué sistemas de origen viene cada modelo y qué modelos downstream dependen de cada modelo. **6. El analytics engineering como puente entre datos e ingeniería** El analytics engineer vive en la intersección entre el mundo de los datos y el mundo de la ingeniería de software, y necesita adoptar las mejores prácticas de ambos. Define el proceso de trabajo del analytics engineer en el equipo: la colaboración con los ingenieros de backend para entender los modelos de datos de los sistemas de origen y los cambios que afectan al pipeline de analytics, la colaboración con los analistas de negocio para entender qué preguntas necesitan responder y traducirlas en requisitos de modelado de datos, el proceso de CI/CD para los cambios en los modelos de dbt que garantiza que los cambios se revisan, se testean y se despliegan de forma controlada, y la deuda técnica del data warehouse que se acumula igual que la deuda técnica del software y requiere la misma disciplina de gestión. Termina con el plan de mejora del analytics engineering para el contexto descrito, con las tres iniciativas de mayor impacto en la confiabilidad de los datos y en la capacidad del negocio para tomar decisiones basadas en ellos.