Neu in Snowflake: Sommer 2025

Neue Seitenleiste (Preview, Rollout läuft)

Snowflake rollt eine neu strukturierte linke Navigationsleiste aus. Einige Accounts haben sie bereits, andere werden schrittweise umgestellt. Nach meiner Erfahrung haben die meisten Accounts sie inzwischen. Die Menügruppen sind übersichtlicher und passen besser zur Arbeitsweise der Teams. Ich musste mich zwar erst daran gewöhnen – es hat ein paar Sekunden gedauert, bis ich "Databases" und "Query History" gefunden hatte –, aber insgesamt gefällt mir das neue Layout sehr gut!

Layout:

• Shortcuts: bis zu drei Seiten für den Schnellzugriff anpinnen. Per Drag-and-drop neu anordnen.
• Work with data: Projects, Ingestion, Transformation (dbt, Task History, Dynamic Tables), AI & ML, Monitoring (Query History! Auch die GUI-Ansicht Ihrer Event Table finden Sie hier), Marketplace.
• Horizon Catalog: Catalog (Databases sind hier!), Data sharing, Governance & security.
• Manage: Compute und Admin.

So pinnen Sie Shortcuts an bzw. lösen sie wieder:

Dieser Screenshot aus der Snowflake-Dokumentation zeigt die neue und die alte Seitenleiste im direkten Vergleich.

Übrigens: Falls Sie die neue globale Suche noch nicht ausprobiert haben – unbedingt nachholen! Sie durchsucht Databases, Marketplace, Dokumentation, eigentlich alles in Snowflake, nach Ihren Stichwörtern. Ich finde damit blitzschnell, wonach ich suche.

Semantic View über Snowsight anlegen (Public Preview)

Sie können Semantic Views direkt in Snowsight über den Database Object Explorer oder die Cortex-Analyst-Seite erstellen und verwalten. Dafür stehen ein Wizard und ein YAML-Upload zur Verfügung.

• Einstiegspunkte:
  • Alte Seitenleiste: Data → Databases → Schema auswählen → Create → Semantic View, oder AI & ML → Cortex Analyst → Create / Upload YAML.
  • Neue Seitenleiste: Horizon Catalog → Catalog → Database → Schema auswählen → Create, Semantic View
  • Oder über AI & ML → Cortex Analyst

Eine neue Semantic View ist sehr einfach angelegt. Die folgenden Screenshots zeigen den Ablauf.

Schritt 1: Zu einem Schema navigieren und auf "Create" klicken. Unten sehen Sie die neue Seitenleiste – Databases und Schemas finden Sie jetzt unter "Horizon Catalog".

Schritt 2: Die Formularseiten ausfüllen

So funktioniert dasselbe über das Cortex-Analyst-Menü:

Hinweis: Auch das Abfragen von Semantic Views per SQL befindet sich in der Preview. Mehr dazu in den Docs.

Dynamic Tables: Lesen aus extern verwalteten Iceberg-Tabellen (GA)

Dynamic Tables können nun direkt aus Iceberg-Tabellen lesen, die über einen externen Katalog verwaltet werden. Das ist eine deutliche Verbesserung der Snowflake-Pipeline-Features für Kunden, die auf Iceberg setzen. Weitere Infos finden Sie in den Docs.

Structured Types für Standard-Tabellen (GA)

Andere Datenplattformen wie BigQuery und Databricks bieten seit Langem strukturierte Datentypen (struct, array, record), während Snowflake bislang nur den Datentyp variant für diese Anwendungsfälle bereitstellte.

Jetzt können Sie ARRAY, OBJECT und MAP als strukturierte Spalten in regulären Snowflake-Tabellen definieren – mit bis zu 1.000 Unterspalten pro Spalte. Strukturierte Typen werden derzeit nicht für Dynamic, Hybrid oder External Tables unterstützt. Weitere Details finden Sie in den Docs.

Pre-Clustering für Snowpipe Streaming (Preview)

Snowpipe Streaming kann Zeilen schon beim Ingest vor-clustern, sodass die Daten bereits nach Ihren Clustering Keys sortiert landen. Das verbessert die Abfrageperformance bei stark genutzten Tabellen und reduziert die Last auf das automatische Clustering. Wir haben das selbst noch nicht getestet, aber für Kunden mit hohen Kosten für automatisches Clustering dürfte das ein echter Sparhebel sein.

Aktivieren Sie das Pre-Clustering in der COPY-Definition über CLUSTER_AT_INGEST_TIME=TRUE; Ihre Zieltabelle muss bereits Cluster Keys besitzen.

CREATE OR REPLACE PIPE TEST_PRECLUSTERED_PIPE
AS
    COPY INTO TEST_PRECLUSTERED_TABLE (num) FROM (
            SELECT $1:num::number as num FROM TABLE(
                DATA_SOURCE(
                    TYPE => 'STREAMING')
        ))
        CLUSTER_AT_INGEST_TIME=TRUE;

COPY FILES-Befehl (GA)

COPY FILES verschiebt Objekte von einer Stage zu einer anderen. Ein typischer Anwendungsfall: das Verschieben von Dateien aus einem "unprocessed"- in einen "processed"-Ordner.

In diesem Szenario können Sie (außerhalb von Snowflake) Bucket Policies setzen, um Ihren unprocessed-Ordner nach einer bestimmten Zeit automatisch zu bereinigen – ganz ohne zusätzlichen Code für das Datenlebenszyklus-Management.

Beispielsweise könnten Sie eine Policy einrichten, die Daten in unprocessed nach 30 Tagen löscht, während die Policy für processed-Daten diese nach 60 Tagen ins Glacier archiviert. Eine solche Strategie reduziert Datenduplizierung und Speicherkosten außerhalb von Snowflake.

Tasks unter einem anderen User ausführen: EXECUTE AS USER + IMPERSONATE (GA)

Tasks lassen sich jetzt mit den Privilegien eines bestimmten Users ausführen – über EXECUTE AS USER, sofern die Task-Owner-Rolle IMPERSONATE auf diesem User besitzt. Das ist nützlich, wenn nachgelagerte Policies oder Systeme von der User-Identität abhängen (etwa für Row Access oder Masking). Außerdem ist in den Logs nachvollziehbar, als wer ein Task tatsächlich agiert hat.

Unten ein vereinfachtes Beispiel, das das neue Feature zeigt. Es wird vorausgesetzt, dass User und Rollen bereits existieren. Ein vollständiges Beispiel inklusive Anlegen der User, Rollen, Warehouses, Task Grants usw. finden Sie in den Snowflake-Docs.

-- grant impersonate.  New feature!
GRANT IMPERSONATE ON USER task_user TO ROLE task_role;

USE ROLE task_owner;

-- run the task as another user
CREATE TASK team_task
  SCHEDULE='12 HOURS'
  EXECUTE AS USER task_user
  AS SELECT 1;

Neues Snowpipe-Pricing aus dem Summit: jetzt GA für Business Critical und VPS

In unserem Summit-Recap haben wir bereits beschrieben, warum das neue Snowpipe-Pricing-Modell für Kunden ein Gewinn ist. Das alte Snowpipe-Pricing hatte zwei Komponenten: pro Sekunde pro Core und pro 1.000 Dateien. Das neue Preismodell ist vereinfacht: ein fester Credit-Betrag pro ingestiertem GB.

Aus dem Konzept ist nun GA geworden – zunächst für Business-Critical- und VPS-Kunden, in Kürze auch für Standard- und Enterprise-Kunden.

Für alle Details lohnt sich ein Blick in die Credit Consumption Table und die Snowpipe-Kosten-Docs.

Snowpark Connect for Spark und Snowpark Submit (Preview)

Kurz gesagt: Sie können Apache-Spark-Jobs jetzt direkt in Snowflake ausführen, ohne Code umzuschreiben. Das umfasst Spark DataFrame, SQL und UDFs. Über Snowpark Submit lassen sich außerdem nicht-interaktive Jobs asynchron einreichen.

Diese Features sind eine pragmatische Brücke für Spark-Teams, die zu Snowflake migrieren und ihren Spark-Code nicht auf Snowpark-APIs umschreiben wollen.

Entwickeln können Sie in vertrauten Tools wie Jupyter Notebooks oder Snowflake Notebooks. Mehr dazu in den Docs.

Snowflake Scripting UDFs (GA)

Sie können nun die Scripting-Logik von Snowflake in SQL-UDFs verwenden und diese inline aus Abfragen heraus aufrufen – nicht mehr nur via CALL wie bei Stored Procedures. Ideal für kleine prozedurale Helper oder eigene SQL-Funktionen, die Sie in SELECT- oder INSERT-Statements wiederverwenden möchten.

Snowflake Scripting ist eine leistungsstarke SQL-Scripting-Sprache. Alle Details zum neuen UDF-Feature finden Sie hier.

Wichtig: Cursor (declare … c1 cursor for select foo from bar) werden nicht unterstützt. Diese Einschränkung dürfte für Anwender eher ein Vorteil sein, denn zeilenbasierte Logik wie Cursor ist in SQL-Funktionen ohnehin keine gute Idee.

Dynamic Tables: UNION im Incremental Refresh (GA)

Da immer mehr Kunden die nativen Datenpipeline-Funktionen von Snowflake nutzen, schließt Snowflake eine offensichtliche und ärgerliche Lücke: Inkrementelle Dynamic Tables unterstützen jetzt UNION (distinct) in Refresh-Abfragen. Damit lassen sich mehr Arten von Multi-Source-Merges ausführen, ohne auf einen Full Refresh zurückzufallen. Andere Mengenoperatoren (z. B. minus, except, intersect) werden im Incremental-Modus weiterhin nicht unterstützt.

CREATE DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 AS
 SELECT * from foo
 -- no longer need union all
 union
 select * from bar;

Ein Tipp für SQL-Einsteiger: Es gilt als Best Practice, union all dem union vorzuziehen, weil union ein distinct erzwingt und damit die Abfrageausführung verlangsamt. Nutzen Sie das neue Feature also nur, wenn Sie tatsächlich eine distinct-Union benötigen.

Stand heute wurden die Snowflake-Docs noch nicht um die Unterstützung des union-Operators ergänzt – released ist das Feature aber dennoch. 🧐

Monitoring-Events für Snowpipe sowie Iceberg-Auto-Refresh-Events (GA)

Snowpipe veröffentlicht jetzt detaillierte Ingest-Events in die aktive Event Table. Sie sehen, wann eine Pipe ihren Status ändert, können den Fortschritt pro Datei verfolgen und periodische Digests einsehen, die Ingest-Aktivitäten zusammenfassen. Zusätzlich gibt Snowflake Events aus, sobald eine extern verwaltete Iceberg-Tabelle automatisch aktualisiert wird.

Das Ergebnis: Sie beobachten den gesamten Ingest-Lebenszyklus an einer Stelle – von Staging-Dateien, die in Snowpipe landen, bis zu nachgelagerten Iceberg-Tabellen, die aktuell gehalten werden. Damit wird eine seit Langem bestehende Beobachtungslücke geschlossen. In der Praxis wird das Troubleshooting hängender Dateien oder verzögerter Refreshes deutlich einfacher und ermöglicht ein engeres Alerting rund um Pipeline-SLAs. Für mich ist das eines dieser "Quality of Life"-Features, das auf den ersten Blick unspektakulär klingt, das Teams mit produktiven Ingest-Pipelines aber sofort zu schätzen wissen.

Mehr Infos zum Feature finden Sie hier.

Ziel-Dateigröße für Iceberg-Tabellen festlegen (Preview)

Sie können beim Anlegen oder Ändern einer Iceberg-Tabelle nun eine Ziel-Dateigröße für Parquet-Dateien festlegen. Das gibt Ihnen mehr Kontrolle darüber, wie die Daten geschrieben werden, und kann die Performance verbessern, wenn diese Dateien später von Engines wie Spark oder Trino gelesen werden.

Besonders nützlich ist das in Multi-Engine-Setups, in denen die Dateigröße über die Abfrageeffizienz entscheidet. Kleinere Dateien eignen sich für schnelle, granulare Abfragen, größere reduzieren den Overhead bei großen Scans. Für mich ein praktischer Schritt, der Snowflake für hybride Lakehouse-Szenarien flexibler macht.

Hier ein Beispiel, wie Sie eine Iceberg-Tabelle mit diesem neuen Feature erstellen oder ändern:

CREATE ICEBERG TABLE my_iceberg_table (
  amount INT,
  name STRING
)
  CATALOG = 'SNOWFLAKE'
  EXTERNAL_VOLUME = 'my_external_volume'
  BASE_LOCATION = 'my_iceberg_table'
  TARGET_FILE_SIZE = '64MB'; -- NEW!

ALTER ICEBERG TABLE my_iceberg_table
SET TARGET_FILE_SIZE = '128MB';

ALTER LISTING: einfacheres Hinzufügen und Entfernen von Targets (GA)

Marketplace-Provider können Listing-Targets jetzt mit einem partiellen Manifest hinzufügen oder entfernen, anstatt das komplette Target-Set neu einzureichen. Das reduziert die Automatisierungs-Komplexität bei vielen Accounts, Rollen oder Organisationen erheblich.

Private Facts und Metrics in Semantic Views (General Availability)

Sie können Facts und Metrics beim Definieren einer Semantic View als PRIVATE markieren. Private Elemente dürfen innerhalb der View in Berechnungen verwendet werden, lassen sich aber nicht direkt abfragen oder in Filtern nutzen. In DESCRIBE SEMANTIC VIEW und GET_DDL tauchen sie weiterhin auf, was Auffindbarkeit und Audits unterstützt. Praktisch, wenn Sie an der Oberfläche saubere, geschäftstaugliche Kennzahlen bereitstellen und Hilfs-Facts sowie Zwischen-Metrics ausblenden möchten. Mein Eindruck: eine Lücke, die mir vorher gar nicht bewusst war, die Semantic Views für Governed Analytics aber deutlich produktionstauglicher macht.

CREATE SEMANTIC VIEW my_sales_view
  TABLES (
    orders AS my_db.my_schema.orders PRIMARY KEY (order_id)
  )
  FACTS (
	  -- NEW Feature
    PRIVATE adjustment_factor AS AVG(orders.adjustment)
  )
  METRICS (
    total_revenue AS SUM(orders.revenue),
    -- NEW feature
    PRIVATE adjusted_revenue AS SUM(orders.revenue + adjustment_factor)
  );

AI_EXTRACT-Funktion (Preview)

AI_EXTRACT extrahiert strukturierte Felder aus unstrukturierten Eingaben. Sie funktioniert mit Strings oder FILE-Inputs, das Antwortformat definieren Sie über einfache Prompts oder Name-Prompt-Paare. Denken Sie an Rechnungen, Verträge, Patientennotizen oder Marketing-PDFs – alles direkt in Snowflake extrahiert. Das bedeutet weniger Round-Trips zu externen Services und einen einfacheren Weg zu strukturierten Daten. Vielversprechend für Teams, die ihre Daten ohnehin in Snowflake zentralisieren – behandeln Sie es aber wie jedes Preview-AI-Feature. Mein Vorgehen wäre, mit einem gelabelten Testset zu starten, um die Qualität zu bewerten. Überlegen Sie sich Guardrails, bevor Sie das Feature in kritische Pipelines einbinden!

Beispiele:

-- Syntax:
AI_EXTRACT( <text>, <responseFormat> )

-- example which specifies structured output
AI_EXTRACT( <'sql column containing unstructured text'>,
['address': 'City, street, ZIP', 'name': 'First and last name'] )

-- another example where the output is in natural language
-- here we extract from a file instaed of a column
AI_EXTRACT( <'a pdf file in Snowflake Stage'>,
['give me address and first and last name' );\
```\
\
### AI Parse Document Layout-Modus (GA)\
\
Der Layout-Modus von [`AI_PARSE_DOCUMENT`](https://docs.snowflake.com/en/user-guide/snowflake-cortex/parse-document#ai-parse-document) ist ein neues GA-Feature, das die Funktion `SNOWFLAKE.CORTEX.PARSE_DOCUMENT` ablöst. Es überführt das Layout eines Dokuments in Markdown und bewahrt dabei Textfluss, Tabellen und Struktur. Kurz gesagt: PDF (oder Ähnliches) zu Markdown! 🥳 Das ergibt eine saubere Zwischenform für Chunking, RAG oder weiterführendes Parsing. Dieses layout-bewusste Parsing ist offenbar die Grundlage für verlässliche Document AI. Ich kann mir auch gut vorstellen, dies mit `AI_EXTRACT` zu kombinieren, um in weniger Schritten von Rohdateien zu strukturierten Datensätzen zu kommen.\
\

\

Verteilte Verarbeitung in Snowflake ML: Many Model Training und Distributed Partition Function (General Availability)\

Snowflake ML unterstützt jetzt zwei verteilte Muster. Many Model Training (MMT) trainiert separate Modelle pro Partition eines Snowpark DataFrames parallel. Distributed Partition Function (DPF) führt Ihre Python-Funktion partitionsübergreifend auf einem oder mehreren Nodes in einem Compute Pool aus – Artefaktspeicherung und Fortschritts-Tracking inklusive. Das nimmt viel Orchestrierungsaufwand ab und skaliert direkt auf der Plattform, die Sie ohnehin nutzen.

Wer tiefer einsteigen möchte, findet ausführliche Dokumentation zu Train models across data partitions und Process data with custom logic across partitions.
\

\

Data Metric Function: ACCEPTED_VALUES (GA)\

ACCEPTED_VALUES ist eine System-DMF, die prüft, ob die Werte einer Spalte einem booleschen Ausdruck entsprechen, und die Anzahl der Zeilen zurückgibt, die das nicht tun. Sie verknüpfen sie geplant mit einer Tabelle oder View oder führen sie ad hoc mit SYSTEM$DATA_METRIC_SCAN aus.

Eine Methode mit geringem Aufwand und hohem Nutzen, um einfache Konformitätsprobleme wie Enums und Code Sets ohne eigenes SQL aufzudecken.
\

1-- syntax\
\
2SNOWFLAKE.CORE.ACCEPTED_VALUES ON ( <column>, <lambda-expression> )\
\
3\
\
4-- example\
\
5ALTER TABLE orders\
\
6  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ACCEPTED_VALUES\
\
7    ON (\
\
8      order_status,\
\
9      order_status -> order_status IN ('Pending', 'Shipped', 'Delivered', 'Returned')\
\
10    );\
\
11\
\
12 CALL SYSTEM$DATA_METRIC_SCAN('orders');\
\
13 -- this will return all DMFs on the orders table\
```\
\
### Updates für Snowflake Data Clean Rooms (GA)\
\
Ein Data Clean Room ist eine sichere Umgebung, in der mehrere Parteien kombinierte Datensätze analysieren können, ohne direkten Zugriff auf die Rohdaten der jeweils anderen zu haben. Möglich wird das durch strikte Abfragekontrollen und Richtlinien, die ausschließlich freigegebene Ergebnisse wie Aggregate oder anonymisierte Outputs zulassen – niemals Daten auf Zeilenebene.\
\
Snowflake hat im vergangenen Monat vier Updates für Data Clean Rooms ausgerollt. Im Kern sind das Quality-of-Life-Verbesserungen, die Reibungspunkte bei der Nutzung von Data Clean Rooms beseitigen.\
\
- **Vereinfachter Ablauf für regionsübergreifendes Sharing**: Provider müssen nicht mehr sowohl `request_laf_cleanroom_requests` als auch `mount_laf_cleanroom_requests_share` aufrufen, um Consumer-Anfragen aus einer anderen Region zu akzeptieren. Jetzt genügt `provider.mount_request_logs_for_all_consumers`. Das wird im [Developer Guide](https://docs.snowflake.com/en/user-guide/cleanrooms/activation?utm_source=chatgpt.com) unter "Implementing activation in your clean room" beschrieben.\
- **Vereinfachte Installation**: Snowflake legt den benötigten Service-User für Clean Rooms jetzt automatisch an und verifiziert ihn – oder verwendet einen bestehenden –, statt dies manuell zu verlangen. Das bedeutet weniger Setup-Schritte, bevor Sie Clean Rooms tatsächlich einsetzen können.\
- **Tests in einem einzigen Account**: Sie können jetzt einen einzigen Snowflake-Account sowohl als Provider als auch als Consumer in einem Test-Clean-Room verwenden. Ideal für Dev/Test-Umgebungen, um Clean-Room-Templates zu erstellen und zu validieren, ohne separate Accounts hochziehen zu müssen. Die Tutorials- & Samples-Seite zeigt das in der Praxis ("[Basic UI tutorial, single account](https://docs.snowflake.com/en/user-guide/cleanrooms/tutorials-and-samples?utm_source=chatgpt.com)"). Für einen schnelleren Überblick siehe die [Docs](https://docs.snowflake.com/en/user-guide/cleanrooms/developer-introduction#label-dcr-self-share-for-developers).\
- **Konfigurierbare Refresh-Raten für Cross-Cloud Auto-Fulfillment**: Standardmäßig wird die Datenaktualisierung zwischen Provider- und Consumer-Accounts in unterschiedlichen Clouds oder Regionen jetzt alle 30 Minuten ausgeführt (vorher: alle 24 Stunden). Und Sie können diese Rate konfigurieren. [Siehe Docs](https://docs.snowflake.com/en/user-guide/cleanrooms/provider.html#dcr-provider-set-laf-dcr-refresh-schedule).\
\
### Write Once, Read Many (WORM) Snapshots (Preview)\
\
WORM-[Snapshots](https://docs.snowflake.com/en/user-guide/snapshots) sind zeitpunktbezogene, **unveränderliche** Backups von Tabellen, Schemas oder Datenbanken. Sie nutzen Snapshot Sets und optionale Snapshot Policies für Planung und Ablauf. **Retention Lock** und **Legal Holds** schützen zusätzlich vor Löschung, wobei Retention Lock auf belastbare Compliance-Garantien ausgelegt ist. Selbst ACCOUNTADMIN kann diese Tabellen nicht löschen – das bietet starken Schutz gegen kompromittierte Credentials und Ransomware. WORM Snapshots stehen in allen Editionen zur Verfügung, Retention Lock und Legal Holds gibt es ab Business Critical.\
\
Ein praxistauglicher Kontrollmechanismus für Ransomware-Resilienz und regulatorische Aufbewahrung, der über Time Travel hinausgeht. Das Feature wirkt vielversprechend für eine saubere Backup-Hygiene, befindet sich aber noch in der Preview – testen Sie also unbedingt Ihre Restore-Pfade und planen Sie den Storage, bevor Sie sich auf Retention Lock verlassen.\
\

\

Org Profiles (General Availability)\

Sie können jetzt Organization Profiles in Snowsight anlegen und verwalten, festlegen welche Accounts und Rollen unter einem Profil veröffentlichen dürfen, und interne Listings mit einem Profil-Avatar und einer URL-Referenz brandieren. Das stärkt das Vertrauen im Internal Marketplace und macht eine Menge einmaligen Setup-SQL überflüssig. Große Organisationen wirken so deutlich organisierter, und Consumer erkennen die Herkunft interner Datenprodukte klarer.

\

Self-Service-Aktivierung für Tri-Secret Secure (General Availability)\

Zur Auffrischung aus dem Snowflake-Training: Tri-Secret Secure ist Snowflakes Ansatz zur Verschlüsselung mit drei Schlüsseln – dem Schlüssel von Snowflake selbst, dem des Cloud-Providers und einem kundenverwalteten Schlüssel. Daten lassen sich nur entschlüsseln, wenn alle drei verfügbar sind. Dadurch können Kunden den Zugriff direkt aussetzen, indem sie ihren Schlüssel deaktivieren. Verfügbar ist das Feature für Business Critical und VPS.

Mit der neuen Self-Service-Aktivierung können ACCOUNTADMINs Tri-Secret Secure eigenständig über Systemfunktionen aktivieren, den kundenverwalteten Schlüssel verwalten und bei Bedarf auch wieder deaktivieren. Das erspart den Umweg über den Support und macht starke Verschlüsselungskontrollen zu einem Standardbestandteil der Account-Hygiene – statt zu einem Sonderprojekt mit Support-Beteiligung.
\

Query Insights: Join-Performance und Optimierung (Public Preview)\

Hintergrund:

Query Insights ist ein relativ neues integriertes Feature, das automatisch Auffälligkeiten zu Ihren Abfragen aufdeckt – etwa ineffiziente Joins oder fehlende Filter. Statt sich durch Roh-Profile zu wühlen, erhalten Sie verständliche Hinweise, die Sie zu Fixes führen, die Performance verbessern und Kosten senken.

Insights finden Sie in Snowsight unter Query History → Query Profile, oder indem Sie die View snowflake.account_usage.query_insights abfragen. Ein Drittanbieter-Tool wie SELECT bietet deutlich bessere Observability für Query Insights in einer dafür gebauten UI.


Neues Feature:

Query Insights ergänzt neue Auffälligkeiten zu Join-Fehlern und Optimierungspotenzialen, sichtbar in Snowsight oder über die View QUERY_INSIGHTS. Die Hinweise zeigen Muster wie fehlende Join-Bedingungen, explodierende Joins, fehlende Filter, Search Optimization-Nutzung und Spillage auf – so kommen Sie schneller an die Ursache. Sehr nützlich für die Triage, auch wenn Sie für tiefere Analysen weiterhin auf Query Profile zurückgreifen.
\

Semantic Views: Dimensions und Metrics in beliebigem Scope auflisten (GA)\

Sie können Ihren Semantic Layer mit SHOW SEMANTIC DIMENSIONS und SHOW SEMANTIC METRICS inventarisieren – auf jeder Ebene: View, Schema, Database oder Account. Sie können sich sogar anzeigen lassen, welche Dimensions für eine bestimmte Metric gültig sind. Das hilft beim Auditieren von Modellen, beim Prüfen von Granularität und Beziehungen und sorgt dafür, dass Teams transparent über das verfügen, was tatsächlich verfügbar ist. Ein kleines Feature, aber sehr willkommen für alle in Admin-Rollen, die zur Governance-Übersicht auf show-Befehle setzen.
\

Hier eine kurze Liste weiterer erwähnenswerter Updates:
\

• Multi-Node ML Jobs – Preview\
• Create Index unterstützt "Include Columns" – GA\
• Consistency Secret in generate_synthetic_data jetzt optional – GA\
• Querying Semantic Views von Preview zu GA\
• Die Funktion SEARCH_IP unterstützt jetzt die Suche nach IPv6-Adressen – GA\
• Trust Center Emails von Preview zu GA Neues Stage Volume für Snowpark Container Services – Preview\
• Microsoft Power Apps Connector – GA
  \

Wow, das sind eine Menge Features in nur zwei Monaten! Melden Sie sich gern, wenn Sie zu einem der Themen Unterstützung brauchen.



Jeff ist Data- und Analytics-Berater mit über 15 Jahren Erfahrung darin, Insights zu automatisieren und Geschäftsprozesse mit Daten zu steuern. Technologisch ist er auf Snowflake + dbt + Tableau spezialisiert. Inhaltlich bringt er Erfahrung aus den Bereichen Public Utility, Klinische Studien, Verlagswesen, CPG und Fertigung mit. Schreiben Sie ihm jederzeit: [email protected].\