SnowPro Advanced: Data Engineer (DEA-C02) — Preguntas de práctica y simulacro de examen

MATCH_BY_COLUMN_NAME (CASE_SENSITIVE o CASE_INSENSITIVE) en COPY INTO <table> asigna los campos con nombre de los datos semiestructurados (JSON, Avro, Parquet, ORC) a las columnas de la tabla de destino por nombre y no por posición ordinal. Las claves de origen que no coinciden se ignoran en silencio; las columnas de destino sin correspondencia reciben NULL. El valor predeterminado es NONE (asignación posicional). (Ref: docs.snowflake.com/en/sql-reference/sql/copy-into-table) Por qué las otras opciones son incorrectas: “Aplica una validación estricta del esquema y rechaza los archivos…”) Las columnas de origen adicionales se ignoran en silencio, no se rechazan: no se aplica ninguna validación estricta del esquema. “Crea columnas nuevas en la tabla de destino…”) Snowflake nunca altera automáticamente el esquema de la tabla de destino durante las operaciones COPY para agregar columnas nuevas. “Renombra las columnas de origen para que coincidan con la tabla de destino…”) La opción hace coincidir los nombres tal como están; no renombra ninguna columna de origen.

ACCESS_HISTORY, en SNOWFLAKE.ACCOUNT_USAGE, registra el acceso a nivel de columna de todas las consultas. Captura direct_objects_accessed (columnas en la salida del SELECT) y base_objects_accessed (todas las columnas de origen, incluidas las de los JOIN y el WHERE). También rastrea objects_modified para DML. Conserva 365 días. Requiere Enterprise Edition o superior. (Ref: docs.snowflake.com/en/sql-reference/account-usage/access_history) Por qué las otras opciones son incorrectas: “QUERY_HISTORY”) QUERY_HISTORY rastrea metadatos de ejecución de consultas (duración, warehouse, estado), pero no registra a qué columnas concretas se accedió. “LOGIN_HISTORY”) LOGIN_HISTORY registra eventos de autenticación (inicios de sesión, fallos, información del cliente), no patrones de acceso a datos a nivel de consulta. “COLUMNS”) COLUMNS es una vista del Information Schema que lista metadatos de columnas (nombres, tipos de datos, valores predeterminados): no rastrea accesos.

UNDROP TABLE restaura una tabla eliminada dentro de su periodo de retención de Time Travel. Si en el esquema ya existe una tabla con el mismo nombre, UNDROP devuelve un error. La solución alternativa: renombra primero la tabla que provoca el conflicto (ALTER TABLE ORDERS RENAME TO ORDERS_TEMP) y ejecuta después UNDROP TABLE ORDERS para restaurar la original. (Ref: docs.snowflake.com/en/sql-reference/sql/undrop-table) Por qué las otras opciones son incorrectas: “No, la tabla original se pierde de forma permanente cuando se crea una tabla nueva con el mismo nombre”) La tabla original NO se pierde de forma permanente: Time Travel conserva los datos de las tablas eliminadas durante el periodo de retención configurado (hasta 90 días en Enterprise y superiores). “Sí, usando UNDROP TABLE ORDERS con un ID de consulta anterior a la eliminación”) UNDROP TABLE no acepta un parámetro de ID de consulta: actúa sobre el objeto eliminado más recientemente con ese nombre. “Sí, usando UNDROP TABLE ORDERS, que renombra automáticamente la tabla actual”) UNDROP no renombra automáticamente la tabla actual: falla con un error de conflicto de nombres que hay que resolver a mano.

Una columna UUID es la clave de clustering MENOS efectiva porque su cardinalidad extremadamente alta (única por fila) impide un pruning útil de las micro-particiones. Las claves de clustering efectivas agrupan las filas en rangos superpuestos para que el optimizador de consultas pueda saltarse las particiones irrelevantes. Con UUID, cada micro-partición contiene valores únicos y aleatorios, así que no se puede descartar ninguna partición, lo que provoca escaneos completos de la tabla. Además, los costos de re-clustering son excesivos. El distractor A (fecha con filtros de rango) y C/D (cardinalidad de baja a media con filtros de igualdad) son buenos candidatos a clave de clustering y permiten un pruning de particiones efectivo. Las claves ideales tienen una cardinalidad de baja a media y aparecen con frecuencia en cláusulas WHERE o JOIN. Ref: docs.snowflake.com/en/user-guide/tables-clustering-keys.