2 Roles en el Equipo de Datos y Ciclo de Vida de los Datos
En organizaciones modernas, los proyectos analíticos raramente son desarrollados por una sola persona. A medida que el volumen de datos crece y las tecnologías se especializan, surge la necesidad de contar con equipos multidisciplinarios. De acuerdo con el marco de gobierno de datos DAMA-DMBOK (DAMA International 2017) y con la caracterización del rol del científico de datos hecha por Davenport y Patil (2012), existen cuatro perfiles principales, cada uno con responsabilidades, herramientas y productos específicos.
2.0.1 Comparativa de Roles en la Ingeniería y Ciencia de Datos
| Rol | Definición y Objetivos | Responsabilidades Principales | Herramientas Comunes |
|---|---|---|---|
| Data Engineer (Ingeniero de Datos) | Construye y mantiene la infraestructura física y lógica necesaria para que los datos fluyan de forma segura y eficiente en la empresa. | • Diseña tuberías de datos (pipelines ETL/ELT). • Administra el Data Warehouse y Data Lake. • Optimiza bases de datos. |
PySpark, SQL, dbt, Apache Airflow, Docker, Snowflake, BigQuery. |
| Data Analyst (Analista de Datos) | Limpia, organiza e interpreta datos históricos para extraer conclusiones operativas y apoyar la toma de decisiones del negocio. | • Diseña reportes y tableros interactivos (dashboards). • Realiza análisis exploratorios básicos. • Responde a solicitudes de datos operativas (tickets). |
SQL, Tableau, Power BI, Python (Pandas/Polars), Excel, BigQuery. |
| Data Scientist (Científico de Datos) | Utiliza matemáticas, estadística y algoritmos de Machine Learning para realizar predicciones o automatizar decisiones complejas basadas en datos. | • Desarrolla modelos de regresión, clasificación y clustering. • Realiza experimentos de validación estadística (Pruebas A/B). • Optimiza hiperparámetros. |
Python (Scikit-Learn, PyTorch, XGBoost), R, MLflow, Jupyter Notebooks. |
| Data Architect (Arquitecto de Datos) | Define la estructura de datos general de la organización, creando el mapa (blueprint) de integración de datos entre sistemas de la empresa. | • Diseña el esquema conceptual de la base de datos empresarial. • Define políticas de modelado dimensional y gobierno. • Alinea la infraestructura con la estrategia corporativa. |
Herramientas de modelado de datos (Erwin, dbdiagram.io), Cloud Architectures. |
Las prácticas de modelado dimensional que emplea el Arquitecto de Datos, y que retomaremos en la Parte I del curso, siguen la metodología clásica de Kimball y Ross (2013).
A continuación se detalla gráficamente el flujo de trabajo lógico entre los distintos perfiles de datos:
Fuentes Transaccionales (OLTP)
Bases de datos operacionales, logs de servidores, APIs de terceros.
Data Engineer (Ingeniero de Datos)
Construye y automatiza los flujos de extracción, transformación y carga (ETL) hacia el almacén de datos.
Data Warehouse / Lakehouse
Repositorio central de datos consolidados, limpios y optimizados para consultas multidimensionales.
Data Analyst
Extrae reportes, construye dashboards e interpreta datos históricos para responder preguntas de negocio.
Data Scientist
Desarrolla modelos predictivos de minería de datos y valida hipótesis estadísticas avanzadas.
2.1 El Ciclo de Vida de los Datos
El ciclo de vida de los datos describe la secuencia de fases por las que pasa la información dentro de una organización. Este ciclo es fundamental para estructurar el desarrollo del curso: la Parte I (Almacenes de Datos) abarca principalmente las fases de captura y almacenamiento, mientras que la Parte II (Minería de Datos) se enfoca en el análisis estratégico y predictivo.
Tanto la administración de la infraestructura (fase de almacenamiento) como la analítica aplicada (fase de exploración y modelado) no ocurren de manera aislada. Se integran dentro de un proceso secuencial e iterativo para proyectos de datos. Antes de construir cualquier modelo o base de datos, debemos pasar por etapas que nos ayudan a comprender la viabilidad del proyecto: el entendimiento del negocio, la recolección e inspección de datos, el preprocesamiento, y la posterior evaluación de resultados para garantizar el éxito de su despliegue real en producción. Esta aproximación estructurada es la que diferencia a los proyectos analíticos profesionales de las pruebas de concepto académicas.
El ciclo consta de seis etapas clave (Google 2022):
- Planificar (Plan): Determinar los requisitos de datos para resolver el problema de negocio, definir fuentes necesarias e identificar el equipo necesario.
- Capturar (Capture): Recolectar datos de fuentes internas y externas (bases de datos transaccionales, logs web, APIs). En esta fase los datos son extraídos y preparados.
- Gestionar (Manage): Almacenar los datos de manera estructurada en bases de datos relacionales o almacenes de datos analíticos. Aquí se aplican políticas de seguridad, limpieza inicial y linaje de datos.
- Analizar (Analyze): Explorar los datos mediante estadística y minería de datos (EDA), y entrenar modelos analíticos para responder preguntas clave o automatizar procesos.
- Archivar (Archive): Mover los datos históricos que ya no se consultan frecuentemente a sistemas de almacenamiento pasivos de bajo costo (ej. Glacier o Google Cloud Coldline Storage), protegiéndolos contra modificaciones accidentales.
- Destruir (Destroy): Eliminar de manera definitiva los datos una vez que ha expirado el periodo requerido de retención de datos, garantizando que no queden residuos ni copias inseguras de datos personales (PII) bajo políticas de borrado seguro.
2.2 Fases Críticas de la Gestión de Datos
Independientemente de en qué etapa del ciclo de vida nos encontremos, dos preguntas atraviesan todo el proceso: qué tan sensibles son los datos que estamos manejando y quién tiene permitido acceder a ellos. Ninguna de las dos se resuelve de forma improvisada; ambas se gobiernan mediante políticas explícitas que el equipo de datos debe conocer antes de tocar una sola tabla.
2.2.1 Datos que Requieren Tratamiento Especial
No todos los datos representan el mismo nivel de riesgo si se exponen o se usan indebidamente. Ciertas categorías —conocidas como datos sensibles o de categoría especial— exigen controles adicionales de recolección, almacenamiento y acceso:
- Información de identificación personal (PII): nombre, dirección, número de identificación oficial, correo electrónico o cualquier dato que permita identificar a una persona de forma directa o indirecta.
- Datos de salud: historiales clínicos, diagnósticos o resultados de laboratorio; en México, protegidos explícitamente como datos personales sensibles por la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (Congreso de los Estados Unidos Mexicanos 2010).
- Datos financieros y biométricos: números de tarjeta, historial crediticio, huellas dactilares o reconocimiento facial.
Por ello, antes de capturar cualquiera de estos tipos de datos se aplica el principio de minimización: recolectar únicamente lo estrictamente necesario para resolver la pregunta de negocio, en lugar de acumular información sensible “por si acaso” que solo incrementa el riesgo sin aportar valor analítico.
2.2.2 Gobernanza, Política de Uso y Control de Acceso
La forma más común de mitigar estos riesgos es trabajar con una política de uso de datos (data usage policy): un documento formal que define qué datos existen, quién puede consultarlos, bajo qué condiciones y con qué finalidad. En las empresas de hoy en día, esta política suele ser diseñada por el Data Architect en conjunto con las áreas legal y de seguridad, y se traduce operativamente en:
- Control de acceso de mínimo privilegio: cada usuario o rol recibe una capacidad de acceso específica, limitada únicamente a los datos indispensables para su función —un Data Analyst puede consultar ventas agregadas por región, pero no necesariamente el número de tarjeta de un cliente individual— implementado mediante políticas de Gestión de Identidad y Accesos (IAM) y control de acceso basado en roles (RBAC).
- Encriptación: de la información en reposo y en tránsito.
- Catálogo de datos: un inventario actualizado que documenta qué campos son sensibles, quién es su responsable (data owner) y qué reglas de retención les aplican, evitando interpretaciones erróneas entre equipos.
Este principio de mínimo privilegio —otorgar a cada usuario el acceso indispensable, ni uno más— es hoy el estándar de facto en la industria: es tan relevante para el Data Engineer que configura permisos en Snowflake o BigQuery como para el Data Analyst que solicita acceso a una tabla del Data Warehouse.
2.3 Actividad Guiada: Diseñar un Plan de Ciclo de Vida para TheLook eCommerce
Como actividad introductoria práctica para este curso, diseñarás el plan inicial de datos para la empresa ficticia TheLook eCommerce, basándote en la solicitud de requerimientos de la mesa directiva de los departamentos de Mercadotecnia y Ventas.
2.3.1 Escenario de Negocio
TheLook eCommerce ha crecido rápidamente gracias a su oferta multicanal. Sin embargo, su infraestructura de datos actual es caótica. El equipo de Mercadotecnia ha identificado cuatro preguntas de negocio principales que necesitan responder para lanzar campañas efectivas el próximo trimestre.
2.3.2 Ejercicio de Alineación de Objetivos y Planificación de Datos
Para cada pregunta del negocio, asociaremos su objetivo analítico e identificaremos los datos necesarios que deben capturarse y gestionarse en nuestro futuro Data Warehouse.
| # | Pregunta de Negocio (Stakeholder) | Objetivo Analítico | Datos Necesarios a Capturar |
|---|---|---|---|
| 1 | “¿Qué productos deberíamos promocionar juntos en nuestra página principal?” | Descubrir reglas de asociación entre categorías y productos comprados de forma conjunta por los usuarios. | • Historial de pedidos (orders y order_items).• Identificador de producto e historial de clics en la sesión de navegación. |
| 2 | “¿Cómo podemos optimizar los niveles de inventario de vestidos de mujer en cada bodega regional?” | Predecir la demanda futura semanal de productos específicos por ubicación geográfica. | • Registros de stock diario en almacén (inventory_items).• Dirección de entrega de compras históricas y códigos postales. |
| 3 | “¿Cuál es el valor acumulado a largo plazo de los clientes adquiridos a través de anuncios pagados en Google?” | Calcular el Valor de Vida del Cliente (Customer Lifetime Value - CLV) agrupado por canal de adquisición. | • Tablas de usuarios (users) con fecha de registro y canal de procedencia.• Transacciones históricas totales asociadas a cada identificador único de usuario. |
| 4 | “¿Cómo detectamos y prevenimos devoluciones fraudulentas de mercancía de alto costo?” | Desarrollar un clasificador de transacciones sospechosas antes del procesamiento de la devolución. | • Historial de devoluciones por usuario. • Métodos de pago y tiempos transcurridos entre entrega y solicitud de devolución. |