{"id":14302,"date":"2022-10-03T17:57:53","date_gmt":"2022-10-03T17:57:53","guid":{"rendered":"https:\/\/beta.bluetab.net\/?p=14302"},"modified":"2022-10-03T17:57:53","modified_gmt":"2022-10-03T17:57:53","slug":"guia-avanzada-sobre-almacenamiento-en-snowflake","status":"publish","type":"post","link":"https:\/\/beta.bluetab.net\/en\/2022\/10\/guia-avanzada-sobre-almacenamiento-en-snowflake\/","title":{"rendered":"Gu\u00eda avanzada sobre almacenamiento en Snowflake"},"content":{"rendered":"<h1>Gu\u00eda avanzada sobre almacenamiento en Snowflake<\/h1>\n<figure><a href=\"https:\/\/www.linkedin.com\/in\/roberto-garc%C3%ADa-parra-1b914128\/\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" width=\"150\" height=\"150\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/03\/cropped-Isotipo-Bluetab-150x150.png\" alt=\"\" loading=\"lazy\"><\/a><\/figure>\n<h4><a href=\"https:\/\/www.linkedin.com\/in\/roberto-garc%C3%ADa-parra-1b914128\/\" target=\"_blank\" rel=\"noopener\">Roberto Garc\u00eda Parra<\/a><\/h4>\n<p>Technical Delivery Manager<\/p>\n<h2>Introducci\u00f3n a Snowflake<\/h2>\n<p>Snowflake es una plataforma avanzada de datos que se consume en modalidad SaaS 100% en cloud. El principal factor diferenciador de Snowflake es que <b>proporciona capacidades avanzadas para todas las necesidades de datos de las compa\u00f1\u00edas<\/b> (Almacenamiento, procesamiento, explotaci\u00f3n y soluciones de anal\u00edtica avanzada) de una manera <b>m\u00e1s flexible y sencilla<\/b> que las soluciones de Datawarehouse tradicionales.&nbsp;<\/p>\n<p>El motor de queries y procesamiento de Snowflake est\u00e1 <b>basado 100% en SQL<\/b> para facilitar el acceso a la mayor\u00eda de los profesionales de datos, aunque Snowflake est\u00e1 haciendo esfuerzos por ampliar las posibilidades de desarrollo (Por ejemplo, recientemente ha sacado Snowpark, una API que permite a los desarrolladores que est\u00e9n habituados a trabajar con Spark tanto en Scala c\u00f3mo en Java y recientemente en Python, a poder migrar sus c\u00f3digos de forma sencilla a Snowflake). Adem\u00e1s, dispone de conectores nativos con una serie de partners que abarca todas las fases de la ingenier\u00eda de datos, c\u00f3mo por ejemplo partners de integraci\u00f3n de datos tan importantes c\u00f3mo Matillion, Informatica, DBT o DataStage; de Business Intelligence c\u00f3mo Domo, Cognos o Looker; o de Machine Learning c\u00f3mo Alteryx, Dataiku o AWS Sagemaker.<\/p>\n<p>La otra ventaja diferenciadora de Snowflake es que tiene unas c<b>apacidades de optimizaci\u00f3n que no requieren apenas de mantenimiento<\/b> y cubren un abanico muy amplio de casos de uso, entre las que se podr\u00edan destacar <b>la clusterizaci\u00f3n autom\u00e1tica, el cacheo y el search optimization service<\/b>, elementos en los que ahondaremos en detalle en futuros art\u00edculos, ya que en \u00e9ste nos vamos a centrar sobre todo en las capacidades de almacenamiento.<\/p>\n<p>Principales caracter\u00edsticas diferenciadoras de Snowflake:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Pone al alcance de los usuarios <b>funcionalidades avanzadas que se gestionan de forma sencilla<\/b>, abstrayendo a los usuarios de lo que se maneja por debajo.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Multi-cloud: <b>Se puede desplegar en cualquiera de los tres clouds<\/b> m\u00e1s importantes (Amazon, Azure y Google) e incluso permite implementar una <b>estrategia multi-cloud <\/b>d\u00f3nde la mayor\u00eda de la administraci\u00f3n y operaci\u00f3n corre por cuenta de Snowflake.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>No hay que mantener ni hardware ni software<\/b>. Todo gestionado por Snowflake y sin p\u00e9rdida de servicio.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Gesti\u00f3n sencilla de las unidades de procesamiento<\/b> (Llamadas Virtual Warehouses). Es muy sencillo subir o bajar la talla del procesamiento (a golpe de click o una sencilla sentencia SQL), y los cluster se pueden configurar para que se bajen autom\u00e1ticamente tras un tiempo de inactividad, y vuelvan a levantarse de forma r\u00e1pida cu\u00e1ndo entre una nueva petici\u00f3n (en menos de un segundo la mayor de las veces). Dado que una de las variables que marcan el coste es el tiempo de actividad de un warehouse, esto permite eficientar los costes, sin tener que preocuparnos de estar bajando-levantando instancias en funci\u00f3n del uso de la plataforma.<\/li>\n<\/ul>\n<p>La arquitectura de Snowflake est\u00e1 basada en tres principales capas:<\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\">La <b>capa de almacenamiento<\/b>, que es en la que nos centraremos en este art\u00edculo. Esta capa basada en microparticiones es la base de algunas de las funcionalidades m\u00e1s disruptivas de Snowflake c\u00f3mo por ejemplo el Zero-copy cloning o el Time-to-Travel, que veremos tambi\u00e9n en futuros art\u00edculos.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Capa de procesamiento<\/b>.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Cloud Services<\/b>, que es la capa con la que se interact\u00faa con Snowflake y es el cerebro que gestiona y coordina el resto de capas y componentes.<\/li>\n<\/ol>\n<p><img decoding=\"async\" width=\"858\" height=\"485\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake1.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake1.png 858w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake1-300x170.png 300w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake1-768x434.png 768w\" sizes=\"(max-width: 858px) 100vw, 858px\"><\/p>\n<h2>Objetivo del art\u00edculo<\/h2>\n<p>Vamos a entender en profundidad c\u00f3mo funciona Snowflake en la capa de almacenamiento. A grandes l\u00edneas, veremos:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\">C\u00f3mo se almacenan, distribuyen y comprimen los datos.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">La importancia de los metadatos a la hora de escanear de forma eficiente el almacenamiento cu\u00e1ndo se hace tanto una consulta, c\u00f3mo una operaci\u00f3n DML de inserci\u00f3n, actualizaci\u00f3n o borrado.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">C\u00f3mo es este proceso de b\u00fasqueda en los datos, para reducir al m\u00e1ximo el n\u00famero de bytes a escanear (y por tanto, la reducci\u00f3n en los tiempos de consulta).<\/li>\n<\/ul>\n<p>Esto ser\u00e1 la base para entender varias de las funcionalidades diferenciales que ofrece Snowflake:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\">A nivel rendimiento: Clustering, caching, search optimization service y query acceleration service (Recientemente liberada). Estos servicios-funcionalidades ayudan a optimizar diferentes casos de uso d\u00f3nde lo proporcionado por el almacenamiento no sea suficiente para obtener el rendimiento deseado.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Data Sharing, sin necesidad de replicar los datos f\u00edsicamente.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Resiliencia: Zero-copy cloning, Time Travel y Fail Safe.<\/li>\n<\/ul>\n<h2>Introducci\u00f3n al almacenamiento<\/h2>\n<p>El almacenamiento en Snowflake se basa en la generaci\u00f3n de ficheros comprimidos con un tama\u00f1o m\u00e1ximo aproximado de 16MB y que se almacenan en un repositorio orientado a objetos tipo el S3 de AWS. Estos ficheros son inmutables, y cualquier operaci\u00f3n de inserci\u00f3n-borrado-actualizaci\u00f3n siempre se hace generando un nuevo fichero de datos y actualizando los metadatos para saber cu\u00e1les son los ficheros que est\u00e1n activos en cada momento, adem\u00e1s de otros metadatos que veremos m\u00e1s adelante en profundidad para eficientar la cantidad de bytes escaneados a la hora de ejecutar una query.<\/p>\n<h2>Objetivos del almacenamiento Snowflake<\/h2>\n<p>La forma en la que almacena los datos Snowflake est\u00e1 <b>enfocada a dos objetivos principales<\/b>:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Optimizar el rendimiento de las consultas<\/b>, con una combinaci\u00f3n de organizaci\u00f3n autom\u00e1tica de los datos, almacenamiento columnar y el mantenimiento de una metadata.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Posibilitar varias de las caracter\u00edsticas diferenciales<\/b> que tiene Snowflake frente a otros Datawarehouse tradicionales, c\u00f3mo por ejemplo:\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Zero-copy cloning.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Time Travel.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Data Sharing sin necesidad de replicar el dato f\u00edsicamente.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2>Principales caracter\u00edsticas del almacenamiento en Snowflake<\/h2>\n<p><b>Compresi\u00f3n columnar:<\/b> Snowflake <b>analiza y comprime autom\u00e1ticamente los datos<\/b> durante la carga de la tabla, <b>agrup\u00e1ndolos por columnas<\/b>. En funci\u00f3n del tipo de datos de cada una de las columnas, selecciona el esquema de compresi\u00f3n m\u00e1s \u00f3ptimo para cada una de ellas: Cada columna puede tener su propio esquema de compresi\u00f3n y aumentar-reducir de forma independiente. Gracias a esta eficiencia en la compresi\u00f3n, se obtiene una mejora significativa en los rendimientos al reducir la cantidad de datos a escanear, adem\u00e1s de un ahorro en costes de almacenamiento, ya que Snowflake factura por la cantidad almacenada ya comprimida.<\/p>\n<p><b>Microparticiones: <\/b>Son unidades de almacenamiento contiguo en las que Snowflake va almacenando los datos en el orden de la ingesta. A diferencia de otros motores de bases de datos, <b>en Snowflake no es necesario declarar una forma de particionar los datos<\/b> por una o m\u00e1s columnas, sino que \u00e9l ya lo hace de manera autom\u00e1tica de la siguiente forma: Por un lado, va insertando los datos seg\u00fan le llegan en bloques de almacenamiento que oscilan entre los 50 y los 500MB antes de compresi\u00f3n (16MB aprox comprimidos). Cu\u00e1ndo se llena un bloque, pasa al siguiente, y as\u00ed sucesivamente hasta que todos los datos son insertados. Snowflake tambi\u00e9n <b>encripta tanto en tr\u00e1nsito c\u00f3mo en destino todos los datos.<\/b><\/p>\n<p><b>Cada una de estas particiones son inmutables<\/b>: en el caso en el que haya una actualizaci\u00f3n en alguna de las microparticiones, lo que se hace es crear una nueva versi\u00f3n de la misma, y se mantienen las versiones antiguas por el tiempo parametrizado en el time travel (propiedad DATA_RETENTION_TIME_IN_DAYS en la tabla Snowflake). La inmutabilidad permite cosas c\u00f3mo por ejemplo poder acceder a versiones de los datos en diferentes momentos del tiempo o hacer clonados de tablas sin tener que replicar los datos.<\/p>\n<h2>Metadatos en las microparticiones Snowflake<\/h2>\n<p>Para cada micropartici\u00f3n, Snowflake genera una metadata con la siguiente informaci\u00f3n:<\/p>\n<p><b>A nivel columna<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\">El rango de valores para cada una de las columnas de la micropartici\u00f3n.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Valores m\u00ednimo y m\u00e1ximo.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Conteo de valores diferentes.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Conteo de nulos.<\/li>\n<\/ul>\n<p><b>A nivel tabla<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Tama\u00f1o de tabla (en bytes).<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Referencias de archivos y extensiones de tabla.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Conteo de filas.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Otras propiedades adicionales usadas tanto para la optimizaci\u00f3n c\u00f3mo para el procesamiento de las queries.<\/li>\n<\/ul>\n<h2>Principales caracter\u00edsticas del microparticionamiento de Snowflake<\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Autom\u00e1tico y transparente para el usuario: <\/b>A diferencia de otros sistemas tradicionales, no hay que declarar previamente un campo de partici\u00f3n, ni hacer un mantenimiento posterior.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Asegura la eficiencia en el podado<\/b> tanto <b>en las consultas<\/b>, c\u00f3mo <b>en las operaciones <\/b>DML.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Todas las particiones tienen un tama\u00f1o similar:<\/b> En otros sistemas, el tama\u00f1o de las particiones depende del campo elegido, y puede haber un claro desbalance de particiones en funci\u00f3n del n\u00famero de ocurrencias que tenga cada valor del campo particionado (Hot partition Keys). El trade-off para tener estos tama\u00f1os similares es que pueden solaparse valores: Un determinado valor de columna (por ejemplo una fecha) puede estar en m\u00e1s de una micropartici\u00f3n. Cu\u00e1nto mayor es el solapamiento en las particiones de un valor, menor ser\u00e1 el podado, ya que habr\u00e1 que recorrer m\u00e1s particiones para filtrar los valores correctos en una b\u00fasqueda.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Seg\u00fan Snowflake, <b>este m\u00e9todo de particionado autom\u00e1tico ser\u00eda suficiente para tablas con tama\u00f1os de hasta 1TB<\/b> sin tener que plantearse otras opciones c\u00f3mo por ejemplo el clusterizado.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>En campos secuenciales<\/b> c\u00f3mo fechas o num\u00e9ricos es d\u00f3nde m\u00e1s vemos que s<b>e puede obtener un beneficio en esta forma de particionar<\/b>, ya que si la inserci\u00f3n de los datos est\u00e1 ordenada por dichos campos, el podado (pruning) ser\u00e1 altamente eficiente, y en consecuencia la cantidad de datos a escanear y la rapidez en la resoluci\u00f3n de las queries.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">El almacenamiento columnar permite que Snowflake <b>solamente escanee aquellas columnas inclu\u00eddas en la consulta<\/b>. De ah\u00ed que sea importante incluir solamente las columnas que realmente necesitemos y evitar queries del tipo SELECT * si no es necesario consultar todas las columnas.<\/li>\n<\/ul>\n<h2>Entendiendo la organizaci\u00f3n de datos en Snowflake<\/h2>\n<p>Partiendo de los siguientes datos de ejemplo:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"700\" height=\"336\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake2.jpg\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake2.jpg 700w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake2-300x144.jpg 300w\" sizes=\"(max-width: 700px) 100vw, 700px\"><figcaption><\/figcaption><\/figure>\n<p>Ordenados por fecha. Al insertarlos en Snowflake, para ilustrar este ejemplo se supone que se generan dos microparticiones, que se van llenando en el orden en el que entran los datos:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"900\" height=\"497\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake3.jpg\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake3.jpg 900w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake3-300x166.jpg 300w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/snowflake3-768x424.jpg 768w\" sizes=\"(max-width: 900px) 100vw, 900px\"><figcaption><\/figcaption><\/figure>\n<p>Si por ejemplo, hacemos la siguiente query:<\/p>\n<p><em>Select Fecha, sum(importe)<\/em><\/p>\n<p><em>From ventas<\/em><\/p>\n<p><em>Where fecha = \u201801\/01\/2022\u2019<\/em><\/p>\n<p>Snowflake recorrer\u00eda los siguientes datos:<\/p>\n<ul>\n<li>Primero se podan las microparticiones que no est\u00e9n en el rango. En este caso, c\u00f3mo estamos buscando el 1 de Enero, ignorar\u00e1 la segunda micropartici\u00f3n.<\/li>\n<li>Dentro de la primera micropartici\u00f3n, dado que en la query solamente se est\u00e1n seleccionando las columnas fecha e importe de venta, no recorre la parte de los datos del cliente. Esto es posible gracias al almacenamiento columnar.<\/li>\n<\/ul>\n<p>Si se buscan las ventas de un cliente espec\u00edfico:<\/p>\n<p><em>Select sum(importe)<\/em><\/p>\n<p><em>From ventas<\/em><\/p>\n<p><em>Where cliente = \u2018C2\u2019<\/em><\/p>\n<p>En este ejemplo, recorre las dos microparticiones, ya que C2 est\u00e1 dentro del rango de valores de ambas, aunque realmente C2 no est\u00e1 en la micropartici\u00f3n 1. Esto es lo que se comentaba en el apartado anterior de la posible dependencia que puede haber en la b\u00fasqueda de rangos en cada micropartici\u00f3n de c\u00f3mo est\u00e1n distribuidos los datos.<\/p>\n<h2>DML\u2019s en Snowflake<\/h2>\n<p>Para ver c\u00f3mo funcionan las principales operaciones de DML en Snowflake, hemos reproducido el siguiente experimento: Creamos una nueva tabla, partiendo de una tabla origen que tiene las ventas de varios d\u00edas de 60 call centers, seleccionando solamente los Call Center 1 y 20. Lo que haremos ser\u00e1 operaciones at\u00f3micas de <b>inserci\u00f3n, actualizaci\u00f3n y borrado<\/b> para ver c\u00f3mo se gestionan tanto los datos c\u00f3mo los metadatos.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Inserci\u00f3n<\/b>: Para comprobar c\u00f3mo funciona la inserci\u00f3n insertamos dos nuevos registros con Call Center que no existen: El 10 y el 11.<br \/>\nLos ficheros que componen las microparticiones son inmutables, por lo que Snowflake en la inserci\u00f3n puede ejecutar dos posibles acciones:<\/li>\n<\/ul>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Crear un nuevo fichero con los registros existentes m\u00e1s el nuevo, y archivar el antiguo.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Crear una nueva partici\u00f3n para ese dato.<\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Actualizaci\u00f3n<\/b>: Las acciones que realiza Snowflake para ejecutar una actualizaci\u00f3n son:\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Identificar las microparticiones afectadas por la actualizaci\u00f3n.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Generar nuevos ficheros de micropartici\u00f3n que incluyan las modificaciones.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Archivar las versiones anteriores de los ficheros durante el tiempo marcado por el DATA_RETENTION_TIME_IN_DAYS.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Para verificar esto, partiendo del ejemplo anterior hemos lanzado una consulta que actualice los call center 10 y 11 a 15 por ejemplo. Comprobamos que efectivamente Snowflake solamente recorre esa partici\u00f3n, y genera un nuevo fichero con los nuevos valores, archivando el anterior:<\/p>\n<p><img decoding=\"async\" width=\"1024\" height=\"424\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake5-1024x424.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake5-1024x424.png 1024w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake5-300x124.png 300w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake5-768x318.png 768w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake5.png 1339w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"><\/p>\n<p>Si se actualiza alguno de los otros dos call center, el n\u00famero de particiones recorridas ser\u00eda mayor, lo cu\u00e1l implica que el coste de las operaciones DML tambi\u00e9n se ve afectado por la manera en que est\u00e9n organizados los datos.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Borrado<\/b>: Snowflake procede de manera similar a la actualizaci\u00f3n:\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Identifica las microparticiones afectadas por el borrado.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Genera nuevos ficheros de micropartici\u00f3n d\u00f3nde no aparezcan los registros eliminados.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\">Archiva las versiones anteriores de los ficheros durante el tiempo marcado por el DATA_RETENTION_TIME_IN_DAYS.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>La importancia de entender c\u00f3mo gestiona Snowflake estas operaciones es por las implicaciones que tiene a nivel rendimiento y almacenamiento. Sobre todo en el segundo caso, hay que tener en cuenta que si tenemos un alto n\u00famero de d\u00edas de retenci\u00f3n en tablas (DATA_RETENTION_TIME_IN_DAYS) que se modifican frecuentemente, estaremos archivando muchas versiones de los datos que pueden incrementar considerablemente nuestro almacenamiento.<\/p>\n<p>La principal ventaja es que <b>Snowflake se encarga de todo este complejo mantenimiento siendo la gesti\u00f3n del almacenamiento transparente para el usuario<\/b>.<\/p>\n<p>En estos casos, para eficientar el almacenamiento es fundamental conocer los tres tipos principales de tablas que pone a nuestra disposici\u00f3n Snowflake, as\u00ed c\u00f3mo el concepto de Fail-Safe y Time-Travel:<\/p>\n<p><b>Time-Travel:<\/b> Periodo que, en funci\u00f3n de la edici\u00f3n de Snowflake, (hasta un d\u00eda en Standard y hasta 90 d\u00edas en tablas permanentes a partir de edici\u00f3n Enterprise) permite almacenar todas las versiones por las que pasa una tabla, y habilita funcionalidades c\u00f3mo poder restaurar datos en cualquier punto dentro de ese periodo, o hacer queries sobre un estado espec\u00edfico de los datos.<\/p>\n<p><b>Fail-Safe:<\/b> per\u00edodo de siete d\u00edas durante el cu\u00e1l se almacena cada versi\u00f3n de los datos en la que ha expirado su DATA_RETENTION_TIME_IN_DAYS y que permite la restauraci\u00f3n de los mismos durante ese periodo pero solamente a trav\u00e9s del soporte de Snowflake (Los usuarios no tienen acceso directo al Fail-Safe). Este periodo no es configurable y solamente est\u00e1 disponible en las tablas permanentes, c\u00f3mo veremos a continuaci\u00f3n.<\/p>\n<p>Con estos dos conceptos claros, pasamos a describir los tres tipos principales de tablas en Snowflake:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Temporales<\/b>: Solamente persisten durante la sesi\u00f3n, y no tienen Fail-Safe. Se puede definir Time-Travel de cero o 1 d\u00eda.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Transitorias<\/b>: A diferencia de las temporales, s\u00ed pueden persistir m\u00e1s all\u00e1 de la sesi\u00f3n, pero solo permiten tener Time-Travel de hasta un d\u00eda y tampoco incorporan Fail-Safe.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Permanentes<\/b>: Igual que las transitorias, persisten m\u00e1s all\u00e1 de una \u00fanica sesi\u00f3n, pero permiten extender el Time-Travel hasta 90 d\u00edas (siempre y cu\u00e1ndo se est\u00e9 trabajando en una edici\u00f3n Enterprise o superior) e incorporan de caja el Fail-Safe (No configurable ni removible).<\/li>\n<\/ul>\n<p>Por la naturaleza de cada una de las tablas, vemos que por ejemplo debemos tener en cuenta que si nuestra tabla se puede ver afectada por continuas operaciones DML de actualizaci\u00f3n-inserci\u00f3n, en el caso que tengamos una tabla permanente con un alto n\u00famero de d\u00edas de Time-Travel, nuestros costes de almacenamiento pueden verse incrementados.<\/p>\n<p>La recomendaci\u00f3n general para <b>optimizar el almacenamiento<\/b> es que se utilicen <b>tablas temporales<\/b> para tablas que simplemente utilicemos c\u00f3mo <b>tablas intermedias o staging<\/b>, las <b>transitorias<\/b> para <b>tablas permanentes que puedan ser f\u00e1cilmente reproducibles desde fuera<\/b>, y las <b>permanentes para tablas cr\u00edticas<\/b> que tengan que estar siempre disponibles y que el coste de reprocesamiento en caso de desastre ser\u00eda elevado.<\/p>\n<h2>Aspectos a tener en cuenta respecto al almacenamiento<\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Consultas por columnas no ordenadas en la inserci\u00f3n<\/b>: Esta forma de particionar proporcional implica que haya solapes de valores en las diferentes microparticiones. En columnas de baja cardinalidad (por ejemplo con 2-3 valores diferentes) si los datos no est\u00e1n ordenados por esa columna y hacemos un filtro exclusivamente por dicha columna, hay que controlar el nivel de podado de microparticiones, porque puede pasar que esos 2-3 valores se encuentren en todas las particiones y que Snowflake no pueda podar ninguna. En estos casos, se recomienda para solucionarlo bien a\u00f1adir al filtro un campo tipo fecha o num\u00e9rico por el que est\u00e9n ordenados los datos, o plantear la posibilidad de a\u00f1adir una cluster key por dicho campo, que es uno de los servicios de optimizaci\u00f3n con los que cuenta Snowflake. Otra opci\u00f3n ser\u00eda crear una vista tanto standard c\u00f3mo materializada que ordene por ese campo.Ejemplo d\u00f3nde queda evidenciado esto, es, lanzamos una consulta sobre una gran tabla de unos <b>14.000 millones de filas, cuyos datos est\u00e1n ordenados por fecha y cliente<\/b>. En esta tabla, queremos consultar los diferentes tipos de env\u00edo que se han hecho. Si lanzamos la consulta sin filtro:<\/li>\n<\/ul>\n<p><img decoding=\"async\" width=\"1024\" height=\"331\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake6-1024x331.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake6-1024x331.png 1024w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake6-300x97.png 300w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake6-768x248.png 768w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake6.png 1357w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"><\/p>\n<p>Primero vemos que<b> se escanean las 49.448 microparticion<\/b>es, lo cu\u00e1l es l\u00f3gico ya que no hemos inclu\u00eddo filtro alguno. Por otro lado, <b>se escanean 13,58GB de los 770GB<\/b> que tiene la tabla. Esto se debe a que en la query hemos inclu\u00eddo una \u00fanica columna, y ya que Snowflake c\u00f3mo hemos comentado almacena los datos de forma columnar y comprimida, solamente accede a los datos de la columna que consultamos.<\/p>\n<p>Si aplicamos un filtro sobre la columna Call Center, que es un num\u00e9rico que toma valores entre 1 y 60, y es un campo por el que no se ha ordenado en la inserci\u00f3n de los datos, y buscamos por ejemplo el call center n\u00famero 20:<\/p>\n<p>select distinct cr_ship_mode_sk from &#8220;SNOWFLAKE_SAMPLE_DATA&#8221;.&#8221;TPCDS_SF100TCL&#8221;.&#8221;CATALOG_RETURNS&#8221; where cr_call_center_sk = 20&nbsp;<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"1024\" height=\"372\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake7-1024x372.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake7-1024x372.png 1024w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake7-300x109.png 300w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake7-768x279.png 768w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake7.png 1334w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"><figcaption><\/figcaption><\/figure>\n<p>Vemos que efectivamente, apenas se han podado valores: De las 49,448 microparticiones, 49.447 ten\u00edan en su rango de call center el 20, con lo cu\u00e1l ha habido que recorrerlas igualmente.<\/p>\n<p>Sin embargo, si inclu\u00edmos en el filtro uno de los campos de clusterizado, por ejemplo el c\u00f3digo de cliente:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"1024\" height=\"391\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake8-1024x391.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake8-1024x391.png 1024w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake8-300x114.png 300w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake8-768x293.png 768w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake8.png 1347w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"><figcaption><\/figcaption><\/figure>\n<p>Vemos que <b>s\u00f3lo se ha recorrido un 10% aprox de las microparticione<\/b>s, y el tiempo de query ha bajado de 1 minuto 45 segundos a 12 segundos.&nbsp;<\/p>\n<p>Con esto se puede concluir que <b>el principal factor de rendimiento en las consultas es el n\u00famero de bytes que tenga que escanear Snowflake<\/b> el cu\u00e1l viene <b>principalmente determinado por el n\u00famero de particiones a escanear, y la cantidad de datos de cada columna<\/b>, y que si solamente incluimos en el filtro columnas por las que no est\u00e9n ordenados los datos o no est\u00e9n inclu\u00eddos en la cluster key, en tablas de gran tama\u00f1o el rendimiento puede verse afectado. <b>Es recomendable incluir en los filtros al menos uno de los campos de ordenaci\u00f3n o de las cluster ke<\/b>y para que las queries sean eficientes, o de no poder ser as\u00ed, Snowflake nos proporciona otras alternativas para mejorar el rendimiento c\u00f3mo las vistas materializadas, el cacheo o el search optimization service.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>B\u00fasqueda por rangos en las microparticiones<\/b>: A la hora de podar microparticiones, Snowflake busca en la metadata si el valor buscado est\u00e1 en el rango de valores m\u00ednimo-m\u00e1ximo de la columna filtrada en la micropartici\u00f3n. Esto genera una dependencia a la hora de podar valores en base a c\u00f3mo est\u00e9n distribuidos dichos rangos en las microparticiones, lo cu\u00e1l puede afectar a la cantidad de microparticiones podadas cu\u00e1ndo buscamos por columnas por las que no est\u00e9n ordenados o clusterizados los datos: Por ejemplo, nos podemos encontrar casos d\u00f3nde busquemos un valor que no existe, pero que por estar dentro del rango de valores en la metadata, obligue a Snowflake a recorrer igualmente todas las microparticiones.<\/li>\n<\/ul>\n<p>En estos casos, Snowflake dice que en tablas <b>con tama\u00f1os por debajo de 1TB la organizaci\u00f3n autom\u00e1tica de datos debe ser suficiente<\/b> para obtener buen rendimiento en las consultas.<\/p>\n<h2>Pruebas con Snowflake para entender c\u00f3mo funciona el microparticionado y los metadatos asociados a las microparticiones<\/h2>\n<p>La tabla que se ha utilizado para estas pruebas contiene 100 millones de registros y seis columnas, d\u00f3nde los datos se han distribuido en 49 particiones ocupando un total de 708MB (unos 14,5MB de media por micropartici\u00f3n). Los datos est\u00e1n ordenados por un campo de fecha.<\/p>\n<p>Comentar que para estas pruebas, se ha utilizado la <b>herramienta de Profiling de Snowflake<\/b>, que est\u00e1 <b>disponible desde el historial de queries<\/b>. Hemos encontrado esta herramienta muy completa e intuitiva, y permite de un solo vistazo encontrar d\u00f3nde se est\u00e1n generando los cuellos de botella en las queries, todo el plan de ejecuci\u00f3n por el que pasa una query, as\u00ed c\u00f3mo las filas que salen de cada paso (lo cu\u00e1l nos permite por ejemplo detectar cosas habituales de mal rendimiento c\u00f3mo joins explosivos) y las microparticiones que se van podando en cada estado. Gracias a esta herramienta, hemos podido entender qu\u00e9 es lo que pasaba exactamente en cada una de las situaciones que hemos querido investigar y entender la gesti\u00f3n de Snowflake del almacenamiento.<\/p>\n<p>Esta herramienta de profiling est\u00e1 disponible en el men\u00fa History de la UI, pinchando en la query que queramos analizar.<\/p>\n<p>El objetivo de estas pruebas es entender la forma en la que <b>Snowflake selecciona las microparticiones a recorrer <\/b>y c\u00f3mo de importante es <b>la forma en la que se insertan los datos para mejorar el rendimiento en nuestras consultas<\/b>, as\u00ed c\u00f3mo las columnas por las que se filtre.<\/p>\n<p>En la tabla existe una columna, Call Center, d\u00f3nde hay diferentes valores entre el 1 y el 60 pero con saltos (no est\u00e1n todos los posibles valores). Si hacemos una b\u00fasqueda por un call center espec\u00edfico de los que est\u00e1n:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"764\" height=\"567\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake9.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake9.png 764w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake9-300x223.png 300w\" sizes=\"(max-width: 764px) 100vw, 764px\"><figcaption><\/figcaption><\/figure>\n<p>Apreciamos que sea cu\u00e1l sea el Call Center que incluyamos en el filtro <b>siempre se recorren todas las microparticiones<\/b>. La explicaci\u00f3n es que Snowflake para determinar las microparticiones a recorrer, mira en la metadata de la columna Call Center si el valor buscado est\u00e1 dentro del rango, y en este caso, d\u00f3nde los datos est\u00e1n ordenados por fecha, siempre se cumple que el valor est\u00e1 dentro del rango, por lo que tiene que recorrer todas las microparticiones.<\/p>\n<p>Probamos a meter un nuevo registro de un Call Center con ID 11 que se sabe no aparece en los datos. Tras la inserci\u00f3n, el n\u00famero de microparticiones se mantiene en 49, por lo que Snowflake ha debido generar un nuevo archivo que incluye el nuevo registro, y ha archivado la versi\u00f3n anterior de la micropartici\u00f3n.<\/p>\n<p>Hacemos una b\u00fasqueda por ese Call Center, que a priori est\u00e1 en una \u00fanica micropartici\u00f3n, y al revisar el Profile:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"749\" height=\"462\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake10.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake10.png 749w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake10-300x185.png 300w\" sizes=\"(max-width: 749px) 100vw, 749px\"><figcaption><\/figcaption><\/figure>\n<p>Se aprecia que Snowflake ha tenido que escanear las 49 microparticiones aunque se sabe que el valor 11 est\u00e1 en una micropartici\u00f3n espec\u00edfica. Esto confirma que <b>Snowflake busca en base a rangos de valores por columna<\/b>, y no conoce los valores espec\u00edficos de una columna que hay en cada micropartici\u00f3n.<\/p>\n<p>Para evidenciar a\u00fan m\u00e1s este hecho, insertamos un nuevo registro de Call Center que est\u00e9 fuera del posible rango de b\u00fasqueda: Call Center con ID 61. Tras la inserci\u00f3n, verificamos que el n\u00famero de particiones se mantiene, pero cuando se hace una b\u00fasqueda por ese valor:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"725\" height=\"431\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake11.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake11.png 725w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake11-300x178.png 300w\" sizes=\"(max-width: 725px) 100vw, 725px\"><figcaption><\/figcaption><\/figure>\n<p>\u00danicamente ha escaneado una micropartici\u00f3n. Esto se debe a que el 61 es un valor que est\u00e1 fuera del rango de la metadata del resto de las microparticiones, con lo cu\u00e1l, ha podido saber que el Call Center 61 estaba en una \u00fanica micropartici\u00f3n.<\/p>\n<p>La siguiente comprobaci\u00f3n es ver c\u00f3mo Snowflake ejecuta la b\u00fasqueda de un valor de la columna Call Center que no est\u00e1 en los datos, pero s\u00ed en los posibles rangos de valores de la columna en las microparticiones. Por ejemplo, tenemos Call Centers 10, 11 y 13, pero no el 12. Si buscamos por el 12:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"738\" height=\"477\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake12.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake12.png 738w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake12-300x194.png 300w\" sizes=\"(max-width: 738px) 100vw, 738px\"><figcaption><\/figcaption><\/figure>\n<p>C\u00f3mo era de esperar, recorre todas las microparticiones, ya que el 12 entra en todos los posibles rangos de valores.<\/p>\n<p>Para terminar de confirmar si Snowflake busca exclusivamente por rangos de valores, se crea una nueva tabla \u00fanicamente con los Call Center 1, 10 y 11. Esta nueva tabla tiene 8 microparticiones.<\/p>\n<p>Si buscamos por el Call Center 5 (dentro de rango), recorre las 8 microparticiones aunque el Call Center no exista.<\/p>\n<p>Si buscamos por el Call Center 12, directamente la metadata devuelve que ese Call Center no existe, y por tanto, no recorre ninguna micropartici\u00f3n.<\/p>\n<p>Pero ahora, si buscamos por el valor 11, que recordemos fue una nueva inserci\u00f3n que metimos y justo est\u00e1 en el final del rango, en este caso Snowflake s\u00ed es capaz de podar el resto de microparticiones d\u00f3nde no est\u00e1 el valor:<\/p>\n<figure>\n\t\t\t\t\t\t\t\t\t\t<img decoding=\"async\" width=\"757\" height=\"450\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake13.png\" alt=\"\" loading=\"lazy\" srcset=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake13.png 757w, https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/10\/Snowflake13-300x178.png 300w\" sizes=\"(max-width: 757px) 100vw, 757px\"><figcaption><\/figcaption><\/figure>\n<p>El motivo est\u00e1 en que se sabe que el resto de microparticiones tienen un rango 1-10, con lo cu\u00e1l, la \u00fanica que cumple estar en rango 1-11 es d\u00f3nde verdaderamente est\u00e1 el valor. Sin embargo, en la otra tabla d\u00f3nde era altamente probable que todas las microparticiones en la columna Call Center estuviesen en rango 1-60, ah\u00ed s\u00ed que tuvo que recorrerlas todas para saber d\u00f3nde estaba el Call Center 11.<\/p>\n<p><b>Conclusi\u00f3n de las pruebas:<\/b><\/p>\n<p>Cu\u00e1ndo tengamos bajo rendimiento en consultas, hay <b>dos indicadores principales a revisar<\/b> en el profiling: <b>N\u00famero de particiones escaneadas y cantidad de datos procesados<\/b>.<\/p>\n<p>Para mejorar la consulta, <b>el objetivo es reducir el n\u00famero de ambas<\/b>: Para recorrer menos particiones hay que a\u00f1adir filtros por campos en base a los cu\u00e1les se est\u00e9n ordenando los datos (generalmente fechas o id\u2019s num\u00e9ricos) o replantearnos si ese campo es importante a la hora de filtrar, que los datos est\u00e9n ordenados por dicho campo. Por supuesto, revisar tambi\u00e9n si las columnas que utilizamos en la consulta se pueden reducir.&nbsp;<\/p>\n<p>Si esto no es posible, tendr\u00edamos que plantearnos otras estrategias de optimizaci\u00f3n, c\u00f3mo clusterizar la tabla en base a ese campo, utilizaci\u00f3n de cach\u00e9s, ver si el caso de uso se ajusta a la utilizaci\u00f3n del search optimization service, o la utilizaci\u00f3n de vistas materializadas que pueden a su vez estar clusterizadas o no. El detalle de estas estrategias queda fuera del alcance de este art\u00edculo.<\/p>\n<h2>Principales conclusiones del funcionamiento del almacenamiento en Snowflake<\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>El orden de inserci\u00f3n de los datos importa<\/b>. Es recomendable insertar los datos ordenadamente en base a los filtrados m\u00e1s frecuentes que se vayan a hacer en la explotaci\u00f3n.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Al almacenar de forma columnar los datos, el solamente <b>seleccionar las columnas necesarias para la consulta reduce el n\u00famero de bytes escaneados<\/b> y por tanto el tiempo de resoluci\u00f3n de consulta. Es recomendable evitar los SELECT * o a\u00f1adir columnas innecesarias en las queries.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Es muy importante de cara al rendimiento <b>seleccionar el tipo de datos m\u00e1s adecuado para cada columna<\/b>, ya que Snowflake podr\u00e1 reducir de manera m\u00e1s eficiente el tama\u00f1o de los datos, y esto se traduce en menores tiempos de escaneo, y por tanto de respuestas en las queries.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Para que las queries tengan un buen rendimiento, <b>es aconsejable incluir un filtro de la columna por la que est\u00e9n ordenados-clusterizados los datos<\/b> y revisar en el profile de la query que tenga un buen porcentaje de poda de particiones.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>En columnas de cardinalidad muy baja<\/b> (1-10 valores diferentes), si hacemos b\u00fasquedas exclusivamente por ellas,<b> y los datos no est\u00e1n ordenados o clusterizados por estas columnas, puede que no se poden particiones en las b\u00fasquedas<\/b>. Con vol\u00famenes de GB, el recorrer todas las particiones incluso con la talla m\u00e1s peque\u00f1a no perjudica el rendimiento y Snowflake maneja perfectamente, pero en vol\u00famenes en el rango de centenas de GB, la diferencia entre tener o no la cluster key para buscar un valor en concreto, s\u00ed puede afectar en el n\u00famero de bytes a escanear y por tanto en los tiempos de respuesta, con lo cu\u00e1l es importante hacer un estudio de tiempos de consulta, para lo cu\u00e1l Snowflake nos proporciona una potente herramienta de profiling, que a nosotros particularmente nos ha sido de gran utilidad para poder elaborar este art\u00edculo.<\/li>\n<\/ul>\n<p>Entendiendo c\u00f3mo Snowflake gestiona el almacenamiento a nivel inserci\u00f3n, actualizaci\u00f3n y borrado de datos y c\u00f3mo se gestionan estos datos a la hora de realizar consultas, estar\u00edamos en disposici\u00f3n de dar el siguiente paso que es entender todas las funciones avanzadas que proporciona Snowflake a nivel de optimizaci\u00f3n, compartici\u00f3n y seguridad-resiliencia en los datos. \u00c9ste ser\u00e1 el objetivo de siguientes art\u00edculos.<\/p>\n<h2>Referencias<\/h2>\n<p>Documentaci\u00f3n oficial de Snowflake <a href=\"https:\/\/docs.snowflake.com\/en\/\">https:\/\/docs.snowflake.com\/en\/<\/a><\/p>\n<h6><strong>Navegaci\u00f3n<\/strong><\/h6>\n<p><a href=\"\/#intro\">Introducci\u00f3n<\/a><\/p>\n<p><a href=\"\/#objetivo\">Objetivo<\/a><\/p>\n<p><a href=\"\/#escalabilidad\">Introducci\u00f3n al almacenamiento<\/a><\/p>\n<p><a href=\"\/#objetivosal\">Objetivos del almacenamiento<\/a><\/p>\n<p><a href=\"\/#principalal\">Principales caracter\u00edsticas del almacenamiento<\/a><\/p>\n<p><a href=\"\/#metacatos\">Metadatos en las microparticiones<\/a><\/p>\n<p><a href=\"\/#principalmicro\">Principales caracter\u00edsticas del microparticionamiento<\/a><\/p>\n<p><a href=\"\/#entendiendo\">Entendiendo la organizaci\u00f3n de datos<\/a><\/p>\n<p><a href=\"\/#dml\">DML\u2019s en Snowflake<\/a><\/p>\n<p><a href=\"\/#aspectos\">Aspectos a tener en cuenta respecto al almacenamiento<br \/>\n<\/a><\/p>\n<p><a href=\"\/#pruebas\">Pruebas con Snowflake<\/a><\/p>\n<p><a href=\"\/#conclusiones\">Principales conclusiones<\/a><\/p>\n<p><a href=\"\/#referencias\">Referencias<\/a><\/p>\n<p><a href=\"\/#autores\">Autores<\/a><\/p>\n<h5>\u00bfQuieres saber m\u00e1s de lo que ofrecemos y ver otros casos de \u00e9xito?<\/h5>\n<p><a href=\"\/\" role=\"button\"><br \/>\nDESCUBRE BLUETAB<br \/>\n<\/a><\/p>\n<figure><a href=\"https:\/\/www.linkedin.com\/in\/roberto-garc%C3%ADa-parra-1b914128\/\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" width=\"150\" height=\"150\" src=\"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2022\/03\/cropped-Isotipo-Bluetab-150x150.png\" alt=\"\" loading=\"lazy\"><\/a><\/figure>\n<h4><a href=\"https:\/\/www.linkedin.com\/in\/roberto-garc%C3%ADa-parra-1b914128\/\" target=\"_blank\" rel=\"noopener\">Roberto Garc\u00eda Parra<\/a><\/h4>\n<p>Technical Delivery Manager<\/p>\n<p><b>SOLUCIONES, <\/b>SOMOS EXPERTOS<\/p>\n<p><a href=\"\/soluciones\/data-strategy\/\"><\/a><\/p>\n<p><a href=\"\/soluciones\/data-strategy\/\"><\/a><\/p>\n<p><a href=\"\/soluciones\/data-strategy\/\"><\/p>\n<h5>DATA STRATEGY<\/h5>\n<p><\/a><a href=\"\/soluciones\/data-strategy\/\"><\/a><a href=\"\/soluciones\/data-strategy\/\">\t\t\t\t\t\t<\/a><br \/>\n<a href=\"\/soluciones\/data-fabric\/\"><\/a><\/p>\n<p><a href=\"\/soluciones\/data-fabric\/\"><\/a><\/p>\n<p><a href=\"\/soluciones\/data-fabric\/\"><\/p>\n<h5>DATA FABRIC<\/h5>\n<p><\/a><a href=\"\/soluciones\/data-fabric\/\"><\/a><a href=\"\/soluciones\/data-fabric\/\">\t\t\t\t\t\t<\/a><br \/>\n<a href=\"\/soluciones\/augmented-analytics\/\"><\/a><\/p>\n<p><a href=\"\/soluciones\/augmented-analytics\/\"><\/a><\/p>\n<p><a href=\"\/soluciones\/augmented-analytics\/\"><\/p>\n<h5>AUGMENTED ANALYTICS<\/h5>\n<p><\/a><a href=\"\/soluciones\/augmented-analytics\/\"><\/a><a href=\"\/soluciones\/augmented-analytics\/\">\t\t\t\t\t\t<\/a><\/p>\n<p>Te puede interesar<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Gu\u00eda avanzada sobre almacenamiento en Snowflake Roberto Garc\u00eda Parra Technical Delivery Manager Introducci\u00f3n a Snowflake Snowflake es una plataforma avanzada de datos que se consume en modalidad SaaS 100% en cloud. El principal factor diferenciador de Snowflake es que proporciona capacidades avanzadas para todas las necesidades de datos de las compa\u00f1\u00edas (Almacenamiento, procesamiento, explotaci\u00f3n y [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":20818,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"elementor_header_footer","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7,8,9],"tags":[],"class_list":["post-14302","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-es","category-practices","category-tech"],"acf":[],"jetpack_featured_media_url":"https:\/\/beta.bluetab.net\/wp-content\/uploads\/2023\/03\/8.png","_links":{"self":[{"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/posts\/14302","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/comments?post=14302"}],"version-history":[{"count":0,"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/posts\/14302\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/media\/20818"}],"wp:attachment":[{"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/media?parent=14302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/categories?post=14302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/beta.bluetab.net\/en\/wp-json\/wp\/v2\/tags?post=14302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}