Flujo ágil de datos entre entornos con Snowflake.

Seguro que, en múltiples ocasiones, os habéis visto ante la problemática de no disponer de datos actualizados en los entornos no productivos, ocasionando retrasos en la realización de pruebas para nuevos desarrollos o teniendo que completar las mismas en entornos productivos por no poder replicar los datos de producción de forma ágil. Y es probable que os enfrentéis al inconveniente de disponer de un espacio de almacenamiento más reducido en los entornos no productivos, lo que da lugar a tener muestras de datos en vez de conjuntos completos. Si es así, seguid leyendo.

En este post queremos presentaros una funcionalidad de Snowflake que viene a facilitarnos un poco el día a día y que junto a la funcionalidad de Data-Sharing (que, como ya os contamos en Trabajando con Snowflake I - Snowflake UI y Snowflake Data-Sharing, permite el intercambio de datos a través de copias compartidas) es una de sus características más potentes en nuestra opinión. Se trata de la funcionalidad de Zero-Copy Cloning.

Utilizando Zero-Copy Cloning en el día a día

Supongamos que, por ejemplo, tenemos una empresa hotelera (continuando con el mismo ejemplo que hemos usado en otros posts) en la que existen los típicos entornos de producción, preproducción y desarrollo, en los cuales podemos tener distintos datos según se vayan validando y/o realizando pruebas de los diferentes sistemas que queramos implementar en producción.

Por un lado, podemos encontrarnos con que se trate de una empresa poco digitalizada, en cuyo caso en producción simplemente tendrán los datos de los hoteles, reservas y algunos datos de usuarios recogidos a mano. Por otro lado, si la empresa está inmersa en un proceso de digitalización es probable que tenga sus datos del entorno de producción y otros sobre las visitas realizadas a su web o a otras aplicaciones importados en su entorno preproductivo preparados para integrarlos en un futuro con los datos que ya se encuentren en producción. Y, a su vez, que se encuentre desarrollando modelos de predicción para, por ejemplo, predecir la probabilidad de que un usuario finalmente reserve un hotel en base a anteriores reservas y a las acciones que haya realizado en la web, y cuyos datos devueltos estarían en el entorno de desarrollo.

Con este escenario tenemos, por tanto, varios actores que van a desempeñar papeles fundamentales en el flujo de los datos a la hora de pasar de un entorno a otro, y validar que estos datos sean correctos y puedan generar un impacto positivo en el negocio.

Quizá es más fácil verlo en orden inverso, comenzando por el final de los datos, donde tendremos a las personas más cercanas al negocio (por ejemplo, equipos de ventas, de marketing, de operaciones, etc.) que utilizan los datos a través de herramientas de visualización (PowerBI / Qlik) y para los que contar con unos datos validados y correctos, así como actualizados, es primordial a la hora de desarrollar sus funciones. Pero no tienen por qué consumir los datos solamente de manera visual, ya que estos actores también necesitarán consumir datos a un nivel más operativo que les permita dirigir las acciones que van a llevar a cabo de manera más directa, como establecer campañas de marketing dirigidas a determinados usuarios que hayan visitado la web y aplicaciones que tenemos recién estrenadas y para ello necesitarán tener mayor detalle de los datos. Ellos serían, por tanto, los usuarios o consumidores finales de los datos, los cuales deben estar validados y con el sello de "calidad certificada".

Al mismo tiempo, en el entorno de preproducción estarían trabajando los analistas de datos validando que estos datos que provienen de la nueva herramienta de analítica web se corresponden con la realidad de las visitas y las reservas que realizan los usuarios. Para ello, se habría realizado una copia de los datos productivos correspondientes al backoffice de la empresa en este entorno y se estarían comparando los datos recibidos por la nueva herramienta de analítica web con los datos reales. Es más, dado que los datos productivos se están actualizando constantemente, el volcado de los mismos al entorno preproductivo es algo que tiene que hacerse con una determinada frecuencia para poder asegurar que el testeo de la nueva herramienta sea correcto.

Además, en este entorno de preproducción también estarían trabajando los diseñadores y desarrolladores encargados de adaptar los actuales cuadros de mando para incluir en ellos las visualizaciones que permitan consumir los datos arrojados por la nueva herramienta de analítica web en el entorno productivo.

Por su parte, en el entorno de desarrollo tendríamos trabajando al equipo de científicos de datos que estuvieran desarrollando el modelo de predicción así como posibles sistemas de recomendación de otros hoteles personalizados (en base a las visitas de los usuarios) o recomendaciones de actividades asociadas a los hoteles que les pueda interesar al usuario. Estos actores también necesitarían disponer de datos reales, aunque en un principio comiencen con pequeños sets de datos para afinar el modelo, en algún momento tendrían que realizar pruebas con sets completos o casi completos para asegurar que el tiempo de ejecución es aceptable o no. Por lo que, al igual que sucedía con los datos del entorno de preproducción, también se necesitará realizar un volcado de los datos desde producción con una relativa frecuencia para poder asegurar el entrenamiento y la fiabilidad del modelo productivo.

Además de los perfiles de usuarios ya nombrados, también tendríamos a los ingenieros de datos, perfil que, en este ejemplo, sería transversal a todos los sistemas y tendría que ser capaz de comunicarse con todos los actores y entender las necesidades de cada uno de ellos.

Comenzando con el entorno de desarrollo, el ingeniero de datos no solo podría estar encargado de prepararles el terreno a los equipo de científicos de datos para que puedan trabajar, por ejemplo, generándoles diferentes virtual warehouses dentro de Snowflake en base a las necesidades de cada proyecto, sino también asegurándose de que los datos que se reciben son exactamente los que necesitan tanto si es un pequeño set de datos como si ya están en la fase de pruebas. Además, podrían ayudar a la hora de mejorar el desempeño de los modelos.

Por otro lado, la función principal del entorno de preproducción sería disponibilizar y actualizar los datos del backoffice para que estén también en preproducción. Mientras que de cara a los usuarios finales debería encargarse de mantener el rendimiento de las visualizaciones en niveles aceptables.

Y con este escenario, ¿qué ocurre si tenemos un nuevo desarrollo?, ¿cómo lo promocionamos hasta producción?

Imaginemos que tenemos estos sistemas y se pide incluir una valoración de los usuarios en base al modelo de predicción que indica cómo de probable es que un usuario realice una reserva, modificación que implicaría añadir una nueva columna, llamada "probabilidad_reserva", a la tabla final que se encuentra en producción.

Y puesto que estamos trabajando con Snowflake, vamos a hacer uso de las ventajas que la plataforma nos ofrece a la hora de pasar datos de un entorno a otro.

Una vez que los equipos de científicos e ingenieros de datos ya tienen la columna integrada en el entorno de preproducción, existe el proceso de generación de la columna, pero tarda varios días en generarla. Además de eso, el tener replicados los datos en cualquier otra plataforma generaría costes y, dependiendo de la cantidad de datos, podrían llegar a ser cuantiosos. Por suerte, en Snowflake existe el Zero-Copy Cloning, con lo que con una simple query podríamos tener replicada la tabla con la nueva columna dentro de ambos entornos, por supuesto pasando primero por preproducción, asegurándonos que los datos son correctos y luego pasando a producción y realizando las comprobaciones necesarias.

Aún así, los errores ocurren y puede darse el caso que, por algún motivo en el cálculo, en lugar de sumar 2 puntos por realizar click en un botón de la página sumemos 22 puntos (por lo que ya la tendríamos liada). Por suerte, seguimos dentro de Snowflake y podemos viajar en el tiempo, aunque "solo" por 90 días.

Con esta herramienta podemos conseguir no parar la producción: podemos seguir realizando consultas a tablas que se hayan borrado o actualizado, además de crear clones de datos en un tiempo determinado, antes o después de romper algo, e incluso recuperar datos que se hayan borrado también con una consulta SQL.

Clonando datos en Snowflake

Zero-Copy Cloning es la funcionalidad de Snowflake que proporciona la posibilidad de copiar bases de datos, esquemas y tablas sin la necesidad de tener que copiar los datos reales a través de sentencias SQL simplemente utilizando la palabra clave CLONE.

Esta funcionalidad permite tener datos clonados entre entornos prácticamente en tiempo real, y todo ello sin realmente replicar los datos, con el ahorro de costes de almacenamiento que eso supone.

¿Y cómo es posible?

Gracias a los metadatos. Cuando se crea un clon, Snowflake, en lugar de copiar los datos, lo que hace es crear unos nuevos metadatos que apuntan a la información de la que se desea tener una copia, consiguiendo con ello que no sea necesario duplicar los datos.

Si bajamos a nivel de la arquitectura, esto se explica porque Snowflake almacena los datos en archivos que son inmutables y encriptados, y su repositorio de metadatos es el encargado de registrar la información sobre esos archivos, sus ubicaciones y la referencia a una determinada versión de los datos. De tal forma que, cuando se modifica algún dato, el repositorio de metadatos se actualiza automáticamente para proporcionar un nuevo puntero a los datos modificados, aunque conserva el registro de todas las versiones del conjunto de datos. Toda esta operativa es completamente invisible para el usuario, realizándose en segundo plano de forma ajena a éste.

¿Cómo utilizarlo?

La clonación de objetos es una operativa sencilla, pues todo lo que el usuario tiene que hacer es ejecutar el comando de clonación (puede ejecutarse en cualquier momento).

Este comando está compuesto por una sentencia SQL en la que se utiliza la palabra clave CLONE y permite clonar objetos a distintos niveles:

• A nivel de base de datos

CREATE OR REPLACE DATABASE Cloned_DB CLONE Original_DB

• A nivel de base de tabla

CREATE OR REPLACE TABLE Cloned_Table CLONE Original_Table

Da como resultado una copia de los datos que corresponde a una nueva entrada en el almacén de metadatos, desde donde se realizará el seguimiento de esos datos clonados.

Igual que sucede con el resto de operativas en Snowflake, también es posible realizar el clonado de objetos a través de su interfaz, acción que puede hacerse desde la opción Databases del menú superior.

• A nivel de base de datos: una vez dentro de la pestaña Databases, bastará con pulsar la opción ‘Clone’ y seleccionar la base de datos de la que se realizará el clonado, así como indicar el nombre que recibirá este y una descripción asociada.

• A nivel de tabla: una vez dentro de la pestaña Databases, deberá seleccionarse la base de datos que contiene la tabla que se desea clonar, acción con la que se accede a la página donde se gestionan todos los objetos contenidos en esa base de datos. Una vez ahí, en la pestaña ‘Tables’, se mostrará el listado de todas las tablas contenidas en la base de datos y, al igual que en el caso anterior, bastará con pulsar la opción ‘Clone’ y seleccionar la tabla de la que se realizará el clonado así como indicar el nombre que recibirá este y una descripción asociada.

Un aspecto importante a tener en cuenta es que si bien, tras la clonación, los objetos clonados son independientes entre sí, estos no requieren de almacenamiento adicional pues los archivos de datos son comunes (aunque sus metadatos, no). Dado que no hay réplica de datos, no existen cargos adicionales por almacenamiento (salvo, claro está, que se realicen modificaciones o se agreguen registros en la copia clonada, momento en que pasaría a ser una entidad diferente de la original).

Es importante tener en cuenta que una vez realizada la clonación todos los cambios que se realicen en el original con posterioridad no se transfieren al clon. Esto es así porque con la funcionalidad de Zero-Copy Cloning lo que se crea es un “duplicado” de los datos originales totalmente independiente de estos, y no una copia compartida de los mismos como sí ocurre con la funcionalidad de Data-Sharing.

Conclusiones

Como habréis podido ver, la funcionalidad de Zero-Copy Cloning es muy potente y muy sencilla de utilizar, basta apenas un comando para crear copias de datos, lo cual es muy útil para el día a día. Con ella, cualquier usuario puede disponer de forma ágil de datos actualizados en entornos no productivos sobre los que poder trabajar.

A diferencia de los sistemas tradicionales en los que para realizar una copia de datos es necesario primero crear toda la estructura requerida y luego insertar los datos en ella, en Snowflake la clonación hace una copia de los objetos a nivel de metadatos. Sin embargo, al igual que ocurre con la copia de datos en los sistemas tradicionales, un objeto clonado puede existir de forma independiente a de su objeto original y ambos pueden modificarse con independencia el uno del otro.

Y, aunque las hemos ido mencionando a lo largo del post, a continuación os dejamos un breve resumen de las principales ventajas que encontramos en esta funcionalidad:

• No existen costes de almacenamiento por los datos clonados; los datos existen en un único lugar. Sin embargo, debe tenerse en cuenta que si se realiza alguna modificación en los datos clonados, estos pasarán a convertirse en conjunto de datos independiente del original que ocupará su espacio de almacenamiento propio con sus correspondientes costes asociados.
• La clonación de datos es inmediata, lo que elimina los tiempos de espera para poder disponer de los datos, permitiendo promocionar datos entre entornos de manera ágil.
• Cualquiera puede hacerlo, ya que siguiendo la filosofía de sencillez de Snowflake, basta con ejecutar un comando SQL o bien utilizar su interfaz.