Novedades en Snowflake: verano 2025

Nueva barra lateral (Preview, en despliegue)

Snowflake está desplegando una barra lateral de navegación izquierda reorganizada. Algunas cuentas ya la tienen y otras la irán recibiendo por fases. Por lo que he visto, la mayoría ya la tiene. Los grupos del menú quedaron más limpios y reflejan mejor cómo trabajan los equipos. A mí me costó un poco acostumbrarme: tardé unos segundos en ubicar "databases" y "query history", ¡pero en general me encanta el nuevo diseño!

Distribución:

• Shortcuts: ancla hasta tres páginas para acceso rápido. Arrástralas para reordenarlas.
• Work with data: Projects, Ingestion, Transformation (dbt, Task History, Dynamic Tables), AI & ML, Monitoring (¡query history! También la vista GUI de tu event table está aquí), Marketplace.
• Horizon Catalog: Catalog (¡aquí están las bases de datos!), Data sharing, Governance & security.
• Manage: Compute y Admin.

Así puedes anclar y desanclar shortcuts:

Esta captura, tomada de la documentación de Snowflake, muestra la barra lateral nueva y la antigua una al lado de la otra.

Por cierto, si todavía no probaste la nueva búsqueda global, ¡tienes que hacerlo! Busca en bases de datos, marketplace, documentación o prácticamente cualquier cosa dentro de Snowflake. A mí me ha resultado muy útil para encontrar lo que necesito en segundos.

Crea una Semantic View desde Snowsight (Public Preview)

Puedes crear y administrar Semantic Views directamente en Snowsight desde el explorador de objetos de base de datos o desde la página de Cortex Analyst. Tienes dos opciones: el asistente o la carga de un YAML.

• Puntos de entrada:
  • Barra lateral antigua: Data → Databases → selecciona un esquema → Create → Semantic View, o AI & ML → Cortex Analyst → Create / Upload YAML.
  • Barra lateral nueva: Horizon Catalog → Catalog → Database → selecciona un esquema → create, Semantic View
  • O desde AI & ML → Cortex Analyst

Crear una Semantic View nueva me resultó muy sencillo. Las capturas a continuación describen el proceso.

Paso 1: ve a un Schema y haz clic en "Create". Abajo se ve la nueva barra lateral; las bases de datos y los esquemas ahora están en "Horizon Catalog".

Paso 2: completa las páginas del formulario

Así se hace lo mismo desde el menú de Cortex Analyst:

Nota: consultar semantic views con SQL también está en Preview. Revisa la documentación para más información.

Dynamic Tables: lectura desde Iceberg gestionado externamente (GA)

Las dynamic tables ya pueden leer directamente desde tablas Iceberg gestionadas por un catálogo externo. Es una mejora importante a las capacidades de data pipeline de Snowflake para clientes que se apoyan en Iceberg. Encontrarás más detalles en la documentación.

Tipos estructurados para tablas estándar (GA)

Otras plataformas de datos como Big Query y Databricks llevan tiempo ofreciendo tipos de datos estructurados (struct, array, record), mientras que Snowflake solo contaba con el tipo variant para cubrir estos casos de uso.

Ahora puedes definir ARRAY, OBJECT y MAP como columnas estructuradas en tablas estándar de Snowflake, con hasta 1.000 sub-columnas por columna. Por ahora, los tipos estructurados no son compatibles con tablas dynamic, hybrid ni externas. Consulta la documentación para más detalles.

Pre-clustering para Snowpipe Streaming (Preview)

Snowpipe Streaming puede hacer pre-clustering de filas en el momento de la ingesta, de modo que los datos lleguen ordenados por tus claves de clustering. Esto mejora el rendimiento de las consultas en tablas calientes y reduce la carga del clustering automático. Aún no lo hemos probado, pero seguramente sea una buena táctica de ahorro para clientes con un gasto alto en clustering automático.

Se activa el pre-clustering en la definición de COPY con CLUSTER_AT_INGEST_TIME=TRUE; tu tabla destino debe tener cluster keys.

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;

Comando COPY FILES (GA)

COPY FILES mueve objetos de un stage a otro. Un caso de uso real es mover archivos desde una carpeta "unprocessed" hacia una "processed".

En este escenario, puedes definir políticas de bucket (por fuera de Snowflake) para que tu carpeta unprocessed se limpie automáticamente al cabo de cierto tiempo, sin tener que escribir código adicional para gestionar el ciclo de vida de los datos.

Por ejemplo, podrías tener una política que elimine los datos de unprocessed a los 30 días, y otra que archive los datos processed en Glacier a los 60 días. Esta estrategia reduce la duplicación de datos y los costos de almacenamiento fuera de Snowflake.

Ejecutar tareas como otro usuario: EXECUTE AS USER + IMPERSONATE (GA)

Las tareas se pueden ejecutar con los privilegios de un usuario específico mediante EXECUTE AS USER, siempre que el rol propietario de la tarea tenga IMPERSONATE sobre ese usuario. Esto resulta útil cuando las políticas o sistemas downstream dependen de la identidad del usuario para cosas como acceso por filas o enmascaramiento, y además facilita ver en nombre de quién actuó realmente una tarea al revisar los logs.

A continuación, un ejemplo simplificado para mostrar la nueva función. El ejemplo asume que los usuarios y roles ya existen. Revisa la documentación de Snowflake para ver un ejemplo completo, con creación de usuarios, roles, warehouses, grants de tareas, etc.

-- otorgar impersonate. ¡Nueva función!
GRANT IMPERSONATE ON USER task_user TO ROLE task_role;

USE ROLE task_owner;

-- ejecutar la tarea como otro usuario
CREATE TASK team_task
  SCHEDULE='12 HOURS'
  EXECUTE AS USER task_user
  AS SELECT 1;

Los nuevos Precios de Snowpipe anunciados en el Summit: ya en GA para Business Critical y VPS

En nuestro resumen del Summit ya habíamos comentado que el nuevo modelo de Precios de Snowpipe iba a ser una buena noticia para los clientes. Los precios anteriores tenían dos componentes: por segundo por core y por cada 1.000 archivos. El nuevo esquema se simplifica: una cantidad fija de créditos por GB ingerido.

Ya pasó de concepto a GA para clientes Business Critical y VPS, y pronto se desplegará para los clientes Standard y Enterprise.

Para entender todos los detalles, conviene revisar la tabla de consumo de créditos y la documentación de costos de Snowpipe.

Snowpark Connect for Spark y Snowpark Submit (Preview)

En pocas palabras, ya puedes ejecutar trabajos de Apache Spark directamente en Snowflake sin reescribir el código. Esto incluye Spark DataFrame, SQL y UDFs. También puedes enviar trabajos no interactivos de forma asíncrona con Snowpark Submit.

Estas funciones son un puente pragmático para los equipos que vienen de Spark, están migrando a Snowflake y no quieren reescribir su código a las APIs de Snowpark.

Puedes desarrollar en herramientas conocidas como Jupyter Notebooks o Snowflake Notebooks. Más detalles en la documentación.

UDFs de Snowflake Scripting (GA)

Ya puedes usar la lógica de Snowflake Scripting en UDFs de SQL e invocarlas inline desde las consultas, no solo con CALL como ocurre con los stored procedures. Es una gran opción para pequeños helpers procedurales o funciones SQL personalizadas que quieras reutilizar en sentencias SELECT/INSERT.

Snowflake Scripting es un potente lenguaje de scripting SQL. Encuentra todos los detalles de la nueva función de UDF aquí.

Vale la pena mencionar que esto no funciona con cursores (declare … c1 cursor for select foo from bar). Probablemente sea una ventaja para los usuarios, ya que la lógica basada en filas como los cursores no es buena idea dentro de funciones SQL.

Dynamic tables: UNION en refresh incremental (GA)

A medida que más clientes adoptan las capacidades nativas de data pipeline de Snowflake, la plataforma va cerrando una brecha evidente y molesta: las dynamic tables incrementales ya admiten UNION (distinct) en las consultas de refresh, lo que amplía los tipos de merges multi-fuente que puedes correr sin caer en un refresh completo. Los demás operadores de conjuntos (por ejemplo: minus, except, intersect) siguen sin soportarse en modo incremental.

CREATE DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 AS
 SELECT * from foo
 -- ya no hace falta union all
 union
 select * from bar;

Un tip para quienes recién empiezan con SQL: se considera buena práctica preferir union all sobre union, porque union fuerza un distinct, lo que ralentiza la ejecución de la consulta. Así que solo recurre a esta nueva función si necesitas que la union sea distinct.

Al día de hoy, la documentación de Snowflake todavía no se ha actualizado para reflejar el soporte del operador union, pero ya está lanzado. 🧐

Eventos de monitoreo para Snowpipe, más eventos de auto-refresh de Iceberg (GA)

Snowpipe ahora publica eventos detallados de ingesta en la Event Table activa. Puedes ver cuándo un pipe cambia de estado, hacer seguimiento del avance archivo por archivo y revisar resúmenes periódicos con la actividad de ingesta. Además, Snowflake también emite eventos cada vez que una tabla Iceberg gestionada externamente se refresca automáticamente.

El resultado neto es que puedes observar todo el ciclo de ingesta en un solo lugar: desde los archivos en stage que llegan a Snowpipe hasta las tablas Iceberg downstream que se mantienen al día. Con esto se cierra una brecha de visibilidad que llevaba mucho tiempo abierta. En la práctica, debería facilitar enormemente la resolución de archivos atascados o refreshes lentos, y abre la puerta a alertas más finas sobre los SLAs de los data pipelines. Creo que esta es una de esas funciones de "calidad de vida" que tal vez no suene llamativa al principio, pero que los equipos que corren pipelines de ingesta en producción van a agradecer de inmediato.

Aquí tienes más información sobre la función.

Definir un tamaño de archivo objetivo para tablas Iceberg (Preview)

Ya puedes definir un tamaño objetivo de archivo Parquet al crear o modificar una tabla Iceberg. Esto te da más control sobre cómo se escriben los datos y puede mejorar el rendimiento cuando esos archivos se leen desde motores como Spark o Trino.

Resulta especialmente útil en setups multi-motor, donde el tamaño de archivo puede definir o arruinar la eficiencia de la consulta. Los archivos más pequeños funcionan bien para consultas rápidas y granulares, mientras que los más grandes reducen la sobrecarga en escaneos grandes. Lo veo como un paso práctico que vuelve a Snowflake más flexible para escenarios de lakehouse híbrido.

Aquí tienes un ejemplo de cómo crear o modificar una tabla Iceberg usando esta nueva función:

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'; -- ¡NUEVO!

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

ALTER LISTING: agregar o quitar targets de forma más simple (GA)

Los proveedores del Marketplace ahora pueden agregar o quitar targets de un listing con un manifest parcial, en lugar de tener que reenviar el conjunto completo. Esto reduce la complejidad de la automatización al gestionar muchas cuentas, roles u organizaciones.

Facts y métricas privados en semantic views (General Availability)

Puedes marcar facts y métricas como PRIVATE al definir una semantic view. Los elementos privados se permiten en cálculos dentro de la view, pero no se pueden consultar directamente ni usar en filtros. Siguen apareciendo en DESCRIBE SEMANTIC VIEW y GET_DDL, lo que ayuda con la descubribilidad y las auditorías. Es útil cuando quieres mostrar métricas limpias y listas para el negocio en la superficie, manteniendo ocultos los facts auxiliares y las métricas intermedias. Mi lectura: es una brecha que ni sabía que existía, pero hace que las semantic views se sientan mucho más listas para producción en escenarios de analítica gobernada.

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

Función AI_EXTRACT (Preview)

AI_EXTRACT extrae campos estructurados a partir de entradas no estructuradas. Funciona con strings o entradas FILE, y defines el formato de la respuesta con prompts simples o pares nombre-prompt. Piensa en facturas, contratos, notas clínicas o PDFs de marketing, todos extraídos directamente dentro de Snowflake. Eso se traduce en menos viajes de ida y vuelta a servicios externos y un camino más simple hacia datos estructurados ya listos. Es prometedor para equipos que ya centralizan sus datos en Snowflake, pero trátalo como cualquier función de IA en preview. Mi enfoque sería arrancar con un set de prueba etiquetado para ver cómo rinde. ¡Piensa qué guardrails quieres sumar antes de conectarlo a pipelines críticos!

Ejemplos:

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

-- ejemplo que especifica salida estructurada
AI_EXTRACT( <'columna sql que contiene texto no estructurado'>,
['address': 'City, street, ZIP', 'name': 'First and last name'] )

-- otro ejemplo donde la salida está en lenguaje natural
-- aquí extraemos desde un archivo en lugar de una columna
AI_EXTRACT( <'un archivo pdf en Snowflake Stage'>,
['dame address y first and last name' );\
```\
\
### Modo layout de AI Parse Document (GA)\
\
El modo layout de [`AI_PARSE_DOCUMENT`](https://docs.snowflake.com/en/user-guide/snowflake-cortex/parse-document#ai-parse-document) es una nueva función GA que reemplaza a `SNOWFLAKE.CORTEX.PARSE_DOCUMENT`. Extrae el layout de un documento a Markdown preservando el flujo del texto, las tablas y la estructura. Dicho fácil: ¡de PDF (o similar) a Markdown! 🥳 Eso te deja una forma intermedia limpia para chunking, RAG o parsing posterior. Parece que este parsing consciente del layout es la base para un AI documental confiable. También me imagino combinándolo con `AI_EXTRACT` para pasar de archivos crudos a filas estructuradas con menos pasos.\
\

\

Procesamiento distribuido en Snowflake ML: Many Model Training y Distributed Partition Function (General Availability)\

Snowflake ML ya soporta dos patrones distribuidos. Many Model Training (MMT) entrena modelos separados por cada partición de un Snowpark DataFrame, en paralelo. Distributed Partition Function (DPF) ejecuta tu función de Python sobre las particiones en uno o más nodos de un compute pool, con el almacenamiento de artefactos y el seguimiento del progreso ya resueltos. Esto te ahorra un montón de trabajo de orquestación a la vez que escalas sobre la misma plataforma que ya usas.

Si te interesa profundizar, Train models across data partitions y Process data with custom logic across partitions están muy bien documentados.
\

\

Data Metric Function: ACCEPTED_VALUES (GA)\

ACCEPTED_VALUES es una DMF del sistema que valida si los valores de una columna cumplen una expresión booleana y devuelve el conteo de filas que no lo hacen. La asocias a una tabla o vista con una programación, o la ejecutas ad hoc con SYSTEM$DATA_METRIC_SCAN.

Es una forma de bajo esfuerzo y alto valor para detectar problemas simples de conformidad como enums y conjuntos de códigos, sin tener que escribir SQL personalizado.
\

1-- sintaxis\
\
2SNOWFLAKE.CORE.ACCEPTED_VALUES ON ( <column>, <lambda-expression> )\
\
3\
\
4-- ejemplo\
\
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 -- esto devolverá todas las DMFs sobre la tabla orders\
```\
\
### Novedades en Snowflake Data Clean Rooms (GA)\
\
Una data clean room es un entorno seguro donde varias partes pueden analizar datasets combinados sin acceder directamente a los registros crudos de las demás. Esto se logra mediante controles estrictos de consultas y políticas que solo permiten salidas aprobadas, como agregados o resultados anonimizados, nunca datos a nivel de fila.\
\
Snowflake liberó 4 actualizaciones de data clean rooms el mes pasado. Son, en esencia, mejoras de calidad de vida que reducen la fricción de uso.\
\
- **Flujo simplificado para compartir entre regiones**: los proveedores ya no necesitan invocar tanto `request_laf_cleanroom_requests` como `mount_laf_cleanroom_requests_share` para aceptar solicitudes de consumidores de otra región. Ahora basta con usar `provider.mount_request_logs_for_all_consumers`. Esto se muestra en la [guía del desarrollador](https://docs.snowflake.com/en/user-guide/cleanrooms/activation?utm_source=chatgpt.com), en \"Implementing activation in your clean room\".\
- **Instalación simplificada**: Snowflake ahora crea y verifica automáticamente el usuario de servicio que necesitan las clean rooms, o reutiliza uno existente, en lugar de obligar a los usuarios a hacerlo a mano. Esto se traduce en menos pasos de configuración antes de empezar a usar las clean rooms.\
- **Pruebas con una sola cuenta**: ahora puedes usar una sola cuenta de Snowflake para hacer de proveedor y consumidor a la vez en una clean room de prueba. Es ideal para entornos de dev/test, ya que puedes construir y validar plantillas de clean room sin tener que levantar cuentas separadas. La página de tutoriales y muestras lo demuestra (\" [Basic UI tutorial, single account](https://docs.snowflake.com/en/user-guide/cleanrooms/tutorials-and-samples?utm_source=chatgpt.com)\"). Consulta la [documentación](https://docs.snowflake.com/en/user-guide/cleanrooms/developer-introduction#label-dcr-self-share-for-developers) para una lectura más rápida.\
- **Frecuencia de refresh configurable para Cross-Cloud Auto-Fulfillment**: por defecto, el refresh de datos entre cuentas de proveedor y de consumidor en distintas nubes o regiones ahora es cada 30 minutos (antes era cada 24 horas). Y esa frecuencia se puede configurar. [Consulta la documentación](https://docs.snowflake.com/en/user-guide/cleanrooms/provider.html#dcr-provider-set-laf-dcr-refresh-schedule).\
\
### Snapshots Write Once, Read Many (WORM) (Preview)\
\
Los [Snapshots](https://docs.snowflake.com/en/user-guide/snapshots) WORM son respaldos puntuales e **inmutables** de tablas, esquemas o bases de datos. Usan conjuntos de snapshots y políticas opcionales de snapshots para programación y expiración. **Retention lock** y **legal holds** suman protección contra la eliminación, con retention lock diseñado para garantías sólidas de cumplimiento. Ni siquiera accountadmin puede eliminar estas tablas, por lo que brindan una fuerte protección frente a credenciales comprometidas y ransomware. Los Snapshots WORM están disponibles para todas las ediciones; retention lock y legal holds solo para Business Critical y superiores.\
\
Es un control práctico para resiliencia ante ransomware y retención regulatoria que va más allá de Time Travel. La función pinta prometedora para la higiene de respaldos, pero todavía está en preview, así que prueba las rutas de restauración y planifica el almacenamiento antes de apoyarte en retention lock.\
\

\

Org profiles (General Availability)\

Ya puedes crear y administrar perfiles de organización en Snowsight, asignar qué cuentas y roles pueden publicar bajo cada perfil, y darle marca a los listings internos con un avatar y una referencia URL. Esto refuerza la confianza dentro del Internal Marketplace y elimina mucho SQL puntual de configuración. Hace que las organizaciones grandes se sientan más ordenadas y les da a los consumidores una procedencia más clara para los productos de datos internos.

\

Activación self-service de Tri-Secret Secure (General Availability)\

Como repaso de tu capacitación en Snowflake: Tri-Secret Secure es el enfoque de encriptación de Snowflake donde intervienen tres claves: la propia clave de Snowflake, la clave del proveedor de nube y una clave gestionada por el cliente. Los datos solo pueden desencriptarse si las tres están disponibles, lo que les da a los clientes control directo para suspender el acceso desactivando su clave. Está disponible para Business Critical y VPS.

Con la nueva función de Self Service Activation, los ACCOUNTADMINs pueden activar Tri-Secret Secure por su cuenta usando funciones del sistema, gestionar la clave administrada por el cliente e incluso desactivarla si hace falta. Esto acorta el ciclo de soporte y hace que los controles fuertes de encriptación se sientan como parte estándar de la higiene de la cuenta, en lugar de un proyecto especial que requiere soporte.
\

Query Insights: rendimiento de joins y optimización (Public Preview)\

Contexto:

Query Insights es una función nativa relativamente nueva que automáticamente saca a la luz hallazgos sobre tus consultas, como joins ineficientes o filtros faltantes. En lugar de bucear en profiles crudos, recibes pistas legibles que te orientan hacia ajustes para mejorar el rendimiento y bajar costos.

Los insights se encuentran en Snowsight Query History → Query Profile, o consultando la vista snowflake.account_usage.query_insights. Usar una herramienta de terceros como SELECT les da a los usuarios mucha mejor observabilidad sobre los query insights, en una UI hecha a medida.


Nueva función:

Query Insights suma nuevos hallazgos para errores de join y oportunidades de optimización; los puedes ver en Snowsight o consultando la vista QUERY_INSIGHTS. Las pistas señalan patrones como condiciones de join faltantes, joins que explotan, falta de filtros, uso de search optimization y spillage, para que puedas atacar la causa raíz más rápido. Es muy útil para triage, aunque sigas apoyándote en Query Profile para análisis más profundos.
\

Semantic views: listar dimensiones y métricas en cualquier scope (GA)\

Puedes inventariar tu capa semántica con SHOW SEMANTIC DIMENSIONS y SHOW SEMANTIC METRICS en cualquier scope: nivel view, schema, database o account, e incluso listar qué dimensiones son válidas para una métrica específica. Esto te ayuda a auditar modelos, verificar granularidad y relaciones, y mantener a los equipos honestos sobre lo que realmente está disponible. Es una función pequeña, pero muy bienvenida para quienes tienen roles administrativos y se apoyan en los comandos show para entender el gobierno.
\

Aquí va una lista rápida de otras actualizaciones que vale la pena destacar:
\

• Multi-Node ML jobs - Preview\
• Create Index admite "Include Columns" - GA\
• Consistency Secret ahora es opcional en generate_synthetic_data - GA\
• Consultar Semantic Views pasa de Preview a GA\
• La función SEARCH_IP admite búsqueda de direcciones IPv6 - GA\
• Trust Center Emails pasó de Preview a GA Nuevo Stage Volume para Snowpark Container Services - Preview\
• Conector de Microsoft Power Apps - GA
  \

¡Vaya, son un montón de novedades en solo dos meses! Cuéntanos si necesitas orientación con alguna.



Jeff es Consultor de Datos y Analítica, con más de 15 años de experiencia automatizando insights y usando datos para controlar procesos de negocio. En lo tecnológico, se especializa en Snowflake + dbt + Tableau. En lo sectorial, tiene experiencia en Servicios Públicos, Ensayos Clínicos, Editorial, CPG y Manufactura. Escríbele cuando quieras a [email protected].\