SnowPro Advanced: Data Engineer (DEA-C02) — Questions d'entraînement et examen blanc

MATCH_BY_COLUMN_NAME (CASE_SENSITIVE ou CASE_INSENSITIVE) dans COPY INTO <table> associe les champs nommés des données semi-structurées (JSON, Avro, Parquet, ORC) aux colonnes de la table cible par leur nom plutôt que par leur position ordinale. Les clés source sans correspondance sont ignorées silencieusement ; les colonnes cibles sans correspondance reçoivent NULL. La valeur par défaut est NONE (association positionnelle). (Ref: docs.snowflake.com/en/sql-reference/sql/copy-into-table) Pourquoi les autres options sont fausses : « Elle impose une validation stricte du schéma et rejette les fichiers… ») Les colonnes source supplémentaires sont ignorées silencieusement, pas rejetées — aucune validation stricte du schéma n'est imposée. « Elle crée de nouvelles colonnes dans la table cible… ») Snowflake ne modifie jamais automatiquement le schéma de la table cible pendant les opérations COPY pour y ajouter des colonnes. « Elle renomme les colonnes source pour qu'elles correspondent à la table cible… ») L'option fait correspondre les noms tels quels ; elle ne renomme aucune colonne source.

ACCESS_HISTORY, dans SNOWFLAKE.ACCOUNT_USAGE, enregistre les accès au niveau des colonnes pour toutes les requêtes. Elle capture direct_objects_accessed (colonnes présentes dans la sortie du SELECT) et base_objects_accessed (toutes les colonnes source, y compris celles des JOIN et du WHERE). Elle suit aussi objects_modified pour le DML. Rétention de 365 jours. Nécessite Enterprise Edition ou supérieur. (Ref: docs.snowflake.com/en/sql-reference/account-usage/access_history) Pourquoi les autres options sont fausses : « QUERY_HISTORY ») QUERY_HISTORY suit les métadonnées d'exécution des requêtes (durée, warehouse, statut) mais n'enregistre pas les colonnes précises qui ont été consultées. « LOGIN_HISTORY ») LOGIN_HISTORY enregistre les événements d'authentification (connexions, échecs, informations client), pas les schémas d'accès aux données au niveau des requêtes. « COLUMNS ») COLUMNS est une vue de l'Information Schema qui liste les métadonnées des colonnes (noms, types de données, valeurs par défaut) — elle ne suit aucun accès.

UNDROP TABLE restaure une table supprimée pendant sa période de rétention Time Travel. Si une table du même nom existe déjà dans le schéma, UNDROP renvoie une erreur. La solution de contournement : renomme d'abord la table en conflit (ALTER TABLE ORDERS RENAME TO ORDERS_TEMP), puis exécute UNDROP TABLE ORDERS pour restaurer l'originale. (Ref: docs.snowflake.com/en/sql-reference/sql/undrop-table) Pourquoi les autres options sont fausses : « Non, la table d'origine est définitivement perdue dès qu'une nouvelle table portant le même nom est créée ») La table d'origine n'est PAS définitivement perdue — Time Travel conserve les données des tables supprimées pendant la période de rétention configurée (jusqu'à 90 jours à partir d'Enterprise). « Oui, en utilisant UNDROP TABLE ORDERS avec un ID de requête antérieur à la suppression ») UNDROP TABLE n'accepte pas de paramètre d'ID de requête — il agit sur l'objet portant ce nom supprimé le plus récemment. « Oui, en utilisant UNDROP TABLE ORDERS, qui renomme automatiquement la table actuelle ») UNDROP ne renomme pas automatiquement la table actuelle — il échoue avec une erreur de conflit de nom qu'il faut résoudre manuellement.

Une colonne UUID est la clé de clustering la MOINS efficace, car sa cardinalité extrêmement élevée (unique par ligne) empêche tout pruning utile des micro-partitions. Des clés de clustering efficaces regroupent les lignes dans des plages qui se chevauchent, ce qui permet à l'optimiseur de requêtes d'ignorer les partitions non pertinentes. Avec des UUID, chaque micro-partition contient des valeurs uniques et aléatoires : aucune partition ne peut être éliminée, d'où des scans complets de la table. Les coûts de re-clustering sont eux aussi excessifs. Le distracteur A (date avec filtres de plage) et C/D (cardinalité faible à moyenne avec filtres d'égalité) sont de bons candidats comme clés de clustering et permettent un pruning de partitions efficace. Les clés idéales ont une cardinalité faible à moyenne et apparaissent souvent dans les clauses WHERE ou JOIN. Ref: docs.snowflake.com/en/user-guide/tables-clustering-keys.