Snowflake

Arquitectura

Tres capas:

Arquitectura de snowflake

Capa cloud

Maneja:

  • la autenticación
  • el primer paso de la gestión de una consulta (Optimizer) para las instrucciones DML y DDL.
  • gestiona el RESULTS CACHE en varias zonas de disponibilidad.
  • almacena el METADATA (necesario para el optimizer).

¿Cuándo gasta mucho la capa cloud?

  • Queries frecuentes y simples

  • Variables de sesión

  • Información de sesión

  • Metadata queries (SHOW, INFORMATION_SCHEMA)

  • Queries complejas

  • Muchos JOINs

  • Procesamiento pesado de metadata

  • Operaciones ineficientes

  • INSERT fila por fila (no bulk loading)
  • Herramientas externas mal configuradas (JDBC drivers)

Capa de cómputo

Cada cluster de cómputo de snowflake recibe el nombre de virtual warehouse y se crea bajo demanda en tiempo real. Es necesario para consultas SQL y operaciones DML. Estos warehouses se pueden apagar y encender según necesidad, y se pueden cambiar de tamaño incluso durante una query.

Su tamaño se dobla con cada talla XL, 2XL, 4XL. Más allá de 4XL la manera de asignar servidores no es un X2 en cada escalón, pero los créditos sí.

En un mundo teórico, un warehouse XL tardaria 2 segundos en hacer una query y un 2XL un segundo por lo que costaría lo mismo, pero en la realidad no es así. Subir un warehouse no siempre acelera la query. Si hay demasiados usuarios no ayuda subir el warehouse sino aumentar clusters:

Un warehouse se modifica en tres dimensiones:

  • Tamaño del cluster (X-Small a 6X-Large) - Potencia computacional vertical
  • Número de clusters (1-10) - Escalado horizontal para concurrencia
  • Modo de escalado (Standard/Economy) - Política de activación de clusters adicionales. Standard escala número de clusters cuando hay cola, economy espera 6 minutos. Tienen a su vez opción de autoapagado y autoencendido.
ALTER WAREHOUSE mi_warehouse SET 
  WAREHOUSE_SIZE = 'LARGE'
  MAX_CLUSTER_COUNT = 5
  SCALING_POLICY = 'STANDARD';

El coste es igual a: tamaño del cluster + número de clusters + tiempo de uso. se cobra por segundo con un mínimo de 60.

  • Escaladado horizontal - scaling in & out. añade clusters. [xx] -> [xx] [xx].
  • Escalado vertical - scaling UP & down. añade servidores. [xx] -> [xxx].

Capa de almacenamiento

Es la única capa no multitenant para garantizar que nadie tiene acceso a tus datos. Guarda datos estructurados y semiestructurados de manera comprimida, cifrada en AES-256 y columnar. Cada base de datos consiste en varios esquemas que son grupos lógicos de recursos de base de datos. Se guarda en el proveedor de cloud que hayas elegido.

Time travel restaura el estado de la base de datos desde un punto del pasado.

Time Travel solo:

SELECT * FROM tabla AT (TIMESTAMP => '2024-01-15 10:00:00')

Clonación sola:

CREATE TABLE copia CLONE tabla_original

Combinación Time Travel + Clone:

CREATE TABLE backup CLONE tabla_original AT (TIMESTAMP => '2024-01-15 10:00:00')

Zero-copy cloning es la copia de una base de datos, schema o tabla y no se cobra esa copia hasta que se modifica (porque es un puntero hasta entonces).

Se cobra según el tamaño medio diario del dato comprimido.

Caching

Los resultados de snowflake son cacheados en el Query Result Cache y se borran si nadie hace hit en 24 horas. Cada hit renueva otras 24 horas hasta un maximo de 31 días, momento en que se borra. Si se alteran las filas afectadas, se borra igual. Un hit de caché no usa los warehouses. Este cache se puede quitar temporalmente con:

Hay un cache en el nivel cloud de Metadata donde se guarda estructura y los conteos de las tablas así como info de número de clusters.

ALTER SESSION SET USE_CACHED_RESULT=FALSE;

Hay otro cache a nivel warehouse Virtual Warehouse Local Disk Cache que guarda trozos de datos raw que necesita releer con frecuencia. Es complementario a los otros cachés y se borra cuando se apaga el warehouse.

Roles

  • Roles del sistema (predefinidos):

  • ACCOUNTADMIN: El rol más poderoso que combina SECURITYADMIN y SYSADMIN.

  • SECURITYADMIN: Administra usuarios, roles y redes.
  • SYSADMIN: Crea y gestiona almacenes, bases de datos y otros objetos.
  • USERADMIN: Crea y gestiona usuarios y roles (subconjunto de SECURITYADMIN).

  • PUBLIC: Rol predeterminado asignado a todos los usuarios.

  • Roles personalizados*: Creados por administradores para definir permisos específicos.

Jerarquía de roles: Los roles pueden concederse a otros roles, creando una estructura jerárquica.

Contexto de autorización y roles activos

Cuando un usuario inicia sesión en Snowflake:

  1. Rol primario (PRIMARY ROLE):
    • Es el rol activo principal del usuario
    • Se selecciona con USE ROLE <nombre_rol>
    • Proporciona los privilegios para crear objetos
  2. Roles secundarios (SECONDARY ROLES):
    • Son roles adicionales que pueden activarse simultáneamente
    • Complementan los privilegios del rol primario
    • Se activan con USE SECONDARY ROLES ALL/NONE/<específicos>

Relación entre roles primarios y secundarios

  • Contexto de autorización tradicional (antes): Un usuario operaba solo con un rol activo a la vez.
  • Contexto de autorización extendido (ahora): Un usuario puede operar con un rol primario y múltiples roles secundarios simultáneamente.

Base de datos

Una base de datos es una forma de agrupar datos. Otra forma de agrupación de segundo nivel son los esquemas.

Tiene por defecto dos esquemas: public e INFORMATION_SCHEMA.

  • El primero está vació y puede ser alterado
  • El segundo es una colección de vistas sobre el Metadata Layer que no puede ser alterada
Snowflake Database
├── User Data Layer (tus tablas, datos)
└── Metadata Layer (base de datos interna)
    ├── Definiciones de esquemas
    ├── Estructura de tablas
    ├── Permisos y roles
    ├── Estadísticas de queries
    └── Información de objetos