Associate Data Practitioner Practice Test

El flujo de trabajo correcto y orientado a objetivos es: Primero, define el objetivo (Paso 2: Identifica el mensaje). No puedes elegir un gráfico o diseño de manera efectiva sin saber qué estás tratando de comunicar. A continuación, asegúrate de tener los datos adecuados (Paso 4: Limpia y prepara). La basura en, basura sale también se aplica a las visualizaciones. Luego, elige un tipo de gráfico que se adapte a la estructura de tus datos y al mensaje (Paso 3: Selecciona tipo de gráfico). Solo después de estos pasos implementas el diseño al codificar los datos visualmente (Paso 1: Codifica los datos) y finalmente lo refinas eliminando el chartjunk (Paso 5: Elimina el ruido) para mejorar la claridad. Comenzar con la preparación de datos (B, D) antes de definir el objetivo puede llevar a una limpieza irrelevante o gráficos engañosos. Elige un tipo de gráfico (C) antes de preparar los datos es prematuro.

Escenario: Pipeline de Ventas Minoristas

Una empresa de retail tiene un pipeline de datos que extrae datos de transacciones de ventas de sistemas de punto de venta (POS) cada noche, los transforma (por ejemplo, convierte monedas, agrega elementos de línea), y los carga en un almacén de datos central para informes. El pipeline está programado y orquestado por una herramienta de gestión de flujo de trabajo.

Este escenario describe un patrón clásico de ETL (Extract, Transform, Load) en lote. Los indicadores clave son el horario de extracción nocturna (intervalo de lote), los pasos de transformación explícitos (conversión de monedas, agregación), y la carga en un almacén de datos para informes. El procesamiento de eventos en streaming (A) procesaría los datos de manera continua a medida que ocurren los eventos, no en lotes nocturnos. El Captura de Datos de Cambio (C) es una técnica para identificar cambios incrementales, a menudo utilizada dentro de un pipeline, pero el escenario describe un extracto de lote completo. La arquitectura Lambda (D) combina caminos de lote y streaming para los mismos datos, lo cual no se menciona aquí. El ETL en lote sigue siendo fundamental para informes de confiabilidad programados en datos históricos donde no se requiere latencia sub-segundo.

Escenario: Análisis de Ventas Minoristas
Una empresa minorista quiere analizar datos de ventas semanales de sus 50 tiendas para identificar tendencias y predecir la demanda. El conjunto de datos incluye columnas para Store_ID, Week_Ending_Date, Total_Sales, Number_of_Transactions y Average_Transaction_Value. El análisis preliminar muestra que los datos de Total_Sales están desplazados hacia la derecha, con algunas semanas de ventas muy altas debido a promociones.

Basándonos en el escenario, qué DOS acciones debería tomar el profesional de datos para preparar mejor la variable Total_Sales para su uso en un modelo de regresión lineal que busque predecir las ventas? (Seleccione DOS).

La regresión lineal asume errores normalmente distribuidos y es sensible a valores extremos. La desviación hacia la derecha y 'ventas muy altas debido a promociones' indican una violación de estas suposiciones. Una transformación logarítmica (A) es una técnica estándar para reducir la desviación hacia la derecha, haciendo que los datos sean más simétricos y a menudo más adecuados para modelos lineales. La censura de Winsor (C) limita los valores extremos (por ejemplo, al 95% percentil) para reducir la influencia de los valores atípicos sin eliminar los datos, lo que también ayuda a estabilizar el modelo. La escala de Min-Max (B) cambia el rango de los datos pero no su distribución, por lo que no aborda el problema de la desviación o el valor atípico. La conversión a categorías (D) descarta información cuantitativa valiosa y reduce el poder estadístico del análisis, lo que lo convierte en una mala elección para un modelo de regresión de predicción. El profesional podría utilizar una o ambas técnicas (transformación logarítmica y censura de Winsor) y comparar el rendimiento del modelo.

La normalización adecuada hasta la Tercera Forma Normal (3NF) produce directamente los siguientes resultados: A) Eliminación de las dependencias transversales (donde un atributo no clave depende de otro atributo no clave), B) Cada atributo no clave está completamente funcionalmente dependiente de la clave primaria (esto es en realidad la definición de la Segunda Forma Normal (2NF), que es un requisito previo para la 3NF), y D) Cada tabla representa una sola entidad o concepto. La opción C, 'Se eliminan todas las dependencias de múltiples valores,' es el objetivo de la Cuarta Forma Normal (4NF), no la 3NF. La opción E, 'Cada determinante es una clave candidata,' es la definición de la Forma Normal de Boyce-Codd (BCNF), una forma más fuerte que la 3NF. En la práctica, la 3NF es a menudo el objetivo para los sistemas de procesamiento de transacciones en línea (OLTP) ya que reduce efectivamente la redundancia y las anomalías de inserción/actualización/eliminación mientras mantiene una complejidad manejable. Una ayuda de memoria útil para la 3NF es: 'Cada atributo no clave debe proporcionar un hecho sobre la clave, la clave entera y nada más que la clave (para que me ayude Codd).

Una pipeline de ETL mantenible exhibe idempotencia (A), tolerancia a fallos (C) y modularidad (E). La idempotencia garantiza la confiabilidad en las tareas programadas o re-runs, evitando registros duplicados. La tolerancia a fallos, a menudo implementada con bloques try-catch y colas de cartas muertas, permite un éxito parcial y un depurado más fácil. La modularidad separa las preocupaciones, permitiendo un desarrollo independiente, pruebas (por ejemplo, pruebas unitarias de una función de transformación), y reutilización. La opción B (diseño monolítico) es un anti-patrón; crea una 'gran bola de barro' que es difícil de depurar, probar y actualizar. La opción D (configuraciones codificadas) también es mala práctica; las configuraciones deben ser externalizadas (por ejemplo, en variables de entorno o archivos de configuración) para promover la seguridad y la flexibilidad en diferentes entornos (desarrollo, pruebas, producción). El uso de un orquestador como Airflow (mencionado en el escenario) promueve inherentemente la modularidad y la tolerancia a fallos a través de su modelo de ejecución de DAG basado en tareas.