SnowPro Advanced: Data Engineer (DEA-C02) — Übungsfragen und Probeprüfung

MATCH_BY_COLUMN_NAME (CASE_SENSITIVE oder CASE_INSENSITIVE) in COPY INTO <table> ordnet benannte Felder in semistrukturierten Daten (JSON, Avro, Parquet, ORC) den Spalten der Zieltabelle über den Namen statt über die Position zu. Nicht zugeordnete Quellschlüssel werden stillschweigend ignoriert; nicht zugeordnete Zielspalten erhalten NULL. Standard ist NONE (positionsbasierte Zuordnung). (Ref: docs.snowflake.com/en/sql-reference/sql/copy-into-table) Warum die anderen Optionen falsch sind: „Sie erzwingt eine strikte Schemavalidierung und weist Dateien …“) Zusätzliche Quellspalten werden stillschweigend ignoriert, nicht zurückgewiesen — eine strikte Schemavalidierung wird nicht erzwungen. „Sie legt in der Zieltabelle neue Spalten …“) Snowflake ändert das Schema der Zieltabelle während COPY-Operationen nie automatisch, um neue Spalten hinzuzufügen. „Sie benennt die Quellspalten um, damit sie zur Zieltabelle …“) Die Option gleicht die Namen so ab, wie sie sind; sie benennt keine Quellspalten um.

ACCESS_HISTORY in SNOWFLAKE.ACCOUNT_USAGE erfasst den Zugriff auf Spaltenebene für alle Abfragen. Die View hält direct_objects_accessed (Spalten in der SELECT-Ausgabe) und base_objects_accessed (alle Quellspalten, einschließlich der in JOINs/WHERE) fest. Außerdem verfolgt sie objects_modified für DML. Aufbewahrung: 365 Tage. Erfordert Enterprise Edition oder höher. (Ref: docs.snowflake.com/en/sql-reference/account-usage/access_history) Warum die anderen Optionen falsch sind: „QUERY_HISTORY“) QUERY_HISTORY verfolgt Metadaten zur Abfrageausführung (Dauer, Warehouse, Status), hält aber nicht fest, auf welche konkreten Spalten zugegriffen wurde. „LOGIN_HISTORY“) LOGIN_HISTORY erfasst Authentifizierungsereignisse (Logins, Fehlversuche, Client-Infos), keine Datenzugriffsmuster auf Abfrageebene. „COLUMNS“) COLUMNS ist eine View des Information Schema, die Spalten-Metadaten auflistet (Namen, Datentypen, Standardwerte) — Zugriffe verfolgt sie nicht.

UNDROP TABLE stellt eine gelöschte Tabelle innerhalb ihres Time-Travel-Aufbewahrungszeitraums wieder her. Existiert im Schema bereits eine Tabelle mit demselben Namen, gibt UNDROP einen Fehler zurück. Der Workaround: Benenne zuerst die kollidierende Tabelle um (ALTER TABLE ORDERS RENAME TO ORDERS_TEMP) und führe dann UNDROP TABLE ORDERS aus, um das Original wiederherzustellen. (Ref: docs.snowflake.com/en/sql-reference/sql/undrop-table) Warum die anderen Optionen falsch sind: „Nein, die ursprüngliche Tabelle ist endgültig verloren, sobald eine neue Tabelle mit demselben Namen angelegt wird“) Die ursprüngliche Tabelle ist NICHT endgültig verloren — Time Travel bewahrt die Daten gelöschter Tabellen für den konfigurierten Aufbewahrungszeitraum auf (bis zu 90 Tage ab Enterprise). „Ja, indem du UNDROP TABLE ORDERS mit einer Query-ID von vor dem Löschen verwendest“) UNDROP TABLE akzeptiert keinen Query-ID-Parameter — es arbeitet mit dem zuletzt gelöschten Objekt dieses Namens. „Ja, indem du UNDROP TABLE ORDERS verwendest, das die aktuelle Tabelle automatisch umbenennt“) UNDROP benennt die aktuelle Tabelle nicht automatisch um — es scheitert mit einem Namenskonflikt-Fehler, der manuell aufgelöst werden muss.

Eine UUID-Spalte ist der am WENIGSTEN wirksame Clustering-Key, weil ihre extrem hohe Kardinalität (pro Zeile eindeutig) sinnvolles Pruning von Micro-Partitions verhindert. Wirksame Clustering-Keys gruppieren Zeilen in überlappende Wertebereiche, sodass der Query-Optimizer irrelevante Partitionen überspringen kann. Bei UUIDs enthält jede Micro-Partition zufällige, eindeutige Werte, sodass keine Partitionen ausgeschlossen werden können — das Ergebnis sind Full Table Scans. Auch die Kosten für das Re-Clustering sind übermäßig hoch. Distraktor A (Datum mit Bereichsfiltern) sowie C/D (niedrige bis mittlere Kardinalität mit Gleichheitsfiltern) sind gute Kandidaten für Clustering-Keys und ermöglichen wirksames Partition-Pruning. Ideale Keys haben eine niedrige bis mittlere Kardinalität und tauchen häufig in WHERE- oder JOIN-Klauseln auf. Ref: docs.snowflake.com/en/user-guide/tables-clustering-keys.