SnowPro Advanced: Data Engineer (DEA-C02) — Questões de prática e simulado

MATCH_BY_COLUMN_NAME (CASE_SENSITIVE ou CASE_INSENSITIVE) em COPY INTO <table> mapeia os campos nomeados dos dados semiestruturados (JSON, Avro, Parquet, ORC) para as colunas da tabela de destino pelo nome, e não pela posição ordinal. Chaves de origem sem correspondência são ignoradas silenciosamente; colunas de destino sem correspondência recebem NULL. O padrão é NONE (mapeamento posicional). (Ref: docs.snowflake.com/en/sql-reference/sql/copy-into-table) Por que as outras opções estão erradas: “Impõe uma validação estrita de esquema e rejeita arquivos…”) Colunas de origem extras são ignoradas silenciosamente, não rejeitadas — não existe imposição de validação estrita de esquema. “Cria colunas novas na tabela de destino…”) O Snowflake nunca altera automaticamente o esquema da tabela de destino durante operações COPY para adicionar colunas novas. “Renomeia as colunas de origem para que fiquem iguais à tabela de destino…”) A opção faz a correspondência dos nomes como eles estão; não renomeia nenhuma coluna de origem.

A ACCESS_HISTORY, em SNOWFLAKE.ACCOUNT_USAGE, registra o acesso em nível de coluna de todas as consultas. Ela captura direct_objects_accessed (colunas na saída do SELECT) e base_objects_accessed (todas as colunas de origem, incluindo as usadas em JOINs e no WHERE). Também acompanha objects_modified para DML. Retém 365 dias. Exige Enterprise Edition ou superior. (Ref: docs.snowflake.com/en/sql-reference/account-usage/access_history) Por que as outras opções estão erradas: “QUERY_HISTORY”) A QUERY_HISTORY acompanha metadados de execução das consultas (duração, warehouse, status), mas não registra quais colunas específicas foram acessadas. “LOGIN_HISTORY”) A LOGIN_HISTORY registra eventos de autenticação (logins, falhas, informações do cliente), não padrões de acesso a dados em nível de consulta. “COLUMNS”) COLUMNS é uma view do Information Schema que lista metadados de colunas (nomes, tipos de dados, valores padrão) — ela não acompanha acessos.

O UNDROP TABLE restaura uma tabela excluída dentro do período de retenção do Time Travel dela. Se já existir no schema uma tabela com o mesmo nome, o UNDROP retorna erro. A solução alternativa: renomeie primeiro a tabela em conflito (ALTER TABLE ORDERS RENAME TO ORDERS_TEMP) e depois execute UNDROP TABLE ORDERS para restaurar a original. (Ref: docs.snowflake.com/en/sql-reference/sql/undrop-table) Por que as outras opções estão erradas: “Não, a tabela original é perdida em definitivo quando uma nova tabela com o mesmo nome é criada”) A tabela original NÃO é perdida em definitivo — o Time Travel mantém os dados das tabelas excluídas pelo período de retenção configurado (até 90 dias no Enterprise e superiores). “Sim, usando UNDROP TABLE ORDERS com um ID de consulta anterior à exclusão”) O UNDROP TABLE não aceita um parâmetro de ID de consulta — ele age sobre o objeto excluído mais recentemente com aquele nome. “Sim, usando UNDROP TABLE ORDERS, que renomeia automaticamente a tabela atual”) O UNDROP não renomeia automaticamente a tabela atual — ele falha com um erro de conflito de nome que precisa ser resolvido manualmente.

Uma coluna UUID é a chave de clustering MENOS eficaz porque sua cardinalidade altíssima (única por linha) impede qualquer pruning útil de micro-partições. Chaves de clustering eficazes agrupam as linhas em faixas sobrepostas, para que o otimizador de consultas consiga pular as partições irrelevantes. Com UUIDs, cada micro-partição contém valores únicos e aleatórios, ou seja, nenhuma partição pode ser descartada — o que resulta em varreduras completas da tabela. Os custos de re-clustering também são excessivos. O distrator A (data com filtros de intervalo) e C/D (cardinalidade de baixa a média com filtros de igualdade) são bons candidatos a chave de clustering e permitem um pruning de partições eficaz. Chaves ideais têm cardinalidade de baixa a média e aparecem com frequência em cláusulas WHERE ou JOIN. Ref: docs.snowflake.com/en/user-guide/tables-clustering-keys.