Snowflake & Snowpark Python

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 1 de 17. El mayor cuello de botella en big data rara vez es el almacenamiento. La verdadera fricción ocurre cuando tienes que mover datasets masivos a través de la red solo para llegar a tu capa de compute. La arquitectura de Snowflake evita este problema por completo. La gente suele asumir que Snowflake es solo una base de datos relacional on-premise a la que se le ha hecho un lift and shift a la nube, o un cluster de Hadoop tradicional que tienes que vigilar constantemente. No es ninguna de las dos cosas. Snowflake es un servicio totalmente autogestionado, creado de forma nativa para la nube. No instalas software. No configuras hardware. Todo el mantenimiento, la gestión y el tuning se hacen por ti en segundo plano. Para entender cómo lo consigue, fíjate en su arquitectura híbrida. Snowflake combina una configuración shared-disk con una configuración shared-nothing. En un diseño shared-disk tradicional, todos los nodos de compute acceden a un repositorio de datos central. En un diseño shared-nothing, cada nodo de compute tiene su propio chunk de datos local para procesar. Snowflake coge lo mejor de ambos. Mantiene un único repositorio de almacenamiento central accesible para todos los nodos de compute, pero utiliza clusters de procesamiento masivamente paralelo independientes para ejecutar las queries reales contra esos datos. Este modelo híbrido se divide en tres capas distintas. La primera es la capa de Database Storage. Cuando cargas datos en Snowflake, no se limita a soltar archivos raw en un bucket de la nube. Reorganiza esos datos en un formato columnar interno, optimizado y comprimido. Snowflake gestiona todos los aspectos de cómo se almacenan estos datos. No puedes acceder al almacenamiento raw directamente, solo interactúas con él a través de queries SQL. La segunda capa es el Query Processing. Aquí es donde ocurre el trabajo usando lo que Snowflake llama Virtual Warehouses. Un virtual warehouse es simplemente un cluster de compute independiente. Como el compute está estrictamente separado de la capa de almacenamiento central, múltiples virtual warehouses pueden hacer queries a los mismos datos simultáneamente. No compiten por los recursos, y no se bloquean entre sí. Aquí está la clave. Puedes escalar tu potencia de compute al instante sin mover ni un solo byte de datos. Imagina un informe financiero de fin de mes que requiere una agregación masiva de datos. Normalmente, tendrías que migrar tablas a un servidor más grande para manejar el workload complejo. En Snowflake, simplemente levantas un virtual warehouse más grande, ejecutas el informe pesado en minutos y apagas el warehouse cuando terminas. Las tablas subyacentes nunca se mueven. La tercera capa que une todo es Cloud Services. Este es el cerebro de la plataforma. Es una colección de servicios que coordinan todo en el sistema. Maneja la autenticación de usuarios, gestiona la infraestructura, parsea las queries entrantes y optimiza las rutas de ejecución. También gestiona la metadata, rastreando exactamente dónde viven piezas específicas de datos en la capa de almacenamiento para que las queries puedan ejecutarse de forma eficiente sin escanear todo. La conclusión más potente es que, en Snowflake, el escalado de rendimiento es solo un interruptor en el cluster de compute, mientras que las tablas de datos masivas permanecen completamente estáticas. Si estás disfrutando de la serie y quieres apoyar el programa, puedes encontrarnos buscando DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 2 de 17. ¿Qué pasaría si pudieras escribir Python puro y que se ejecutara como SQL distribuido hiperoptimizado? Ese es precisamente el cambio de paradigma que abordamos hoy con una introducción a Snowpark. Tradicionalmente, trabajar con grandes datasets en Python implicaba sacar los datos de tu base de datos. Escribes una query, te traes los datos por la red a la memoria local o a un cluster de procesamiento externo, ejecutas tus transformaciones y, finalmente, devuelves los resultados. Este enfoque crea cuellos de botella en la red, aumenta los costes de infraestructura e introduce riesgos de seguridad al mover los datos fuera de un entorno gobernado. Snowpark le da la vuelta a este modelo. En lugar de mover los datos al compute, Snowpark lleva el compute a los datos. Un error común es pensar que Snowpark es un motor de procesamiento externo. La gente suele asumir que necesita levantar y gestionar un cluster de compute separado solo para ejecutar código Python. No es así. Los cálculos de Snowpark se ejecutan directamente dentro de Snowflake. Estás usando exactamente los mismos virtual warehouses que ejecutan tus queries SQL estándar. No hay ninguna infraestructura nueva que aprovisionar o mantener. Cuando escribes código usando la API de Python de Snowpark, estás interactuando con un objeto DataFrame. Esto resulta muy similar a trabajar con las herramientas de datos de Python que ya conoces. Haces un chain de operaciones, definiendo cómo seleccionar, filtrar, agrupar o agregar tus datos. Sin embargo, la librería de Snowpark no ejecuta estas operaciones en local. En su lugar, traduce de forma nativa las operaciones de tu DataFrame de Python a construcciones SQL complejas. Luego, Snowflake procesa estas sentencias SQL usando su motor de ejecución estándar. Aquí está la clave. Snowpark utiliza lazy evaluation. Cuando defines tu DataFrame y aplicas varias transformaciones, en realidad ningún dato se mueve ni cambia. La API de Snowpark simplemente construye un plan lógico. Registra tu intención paso a paso. La ejecución real solo se dispara cuando llamas a una acción específica, como pedirle al sistema que devuelva los resultados finales o los escriba en una tabla nueva. Este modelo de lazy evaluation, combinado con la traducción SQL nativa, reduce drásticamente la transferencia de datos. Imagina un escenario donde eres un data engineer encargado de filtrar mil millones de filas de datos transaccionales para aislar unas pocas anomalías específicas. Escribes tu lógica de filtrado en un script de Python en local. Como la ejecución se retrasa hasta que se llama a la acción, la API tiene tiempo para optimizar todo el chain de operaciones y traducirlo en una única query SQL altamente eficiente. El filtrado real ocurre completamente dentro de Snowflake. La base de datos hace todo el trabajo pesado. Los únicos datos que viajan por la red hasta tu máquina local son el pequeño subconjunto final de anomalías. Acabas de procesar mil millones de filas usando sintaxis de Python sin traerte ni un solo registro raw a tu memoria local. La verdadera ventaja aquí es mantener la experiencia de desarrollo nativa de Python mientras aprovechas el motor de la base de datos para lo que mejor sabe hacer. Tú escribes Python, pero Snowflake ejecuta SQL. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 3 de 17. Los boilerplates de conexión suelen ser una pesadilla de seguridad, llenos de contraseñas hardcodeadas y variables de entorno dispersas. Quieres darle a tu equipo una herramienta de línea de comandos local, pero bajo ningún concepto puedes hardcodear las credenciales en el código. La solución es establecer una sesión de forma limpia usando las features de configuración nativas de Snowpark. Cada script de Snowpark comienza creando un objeto Session. Este es tu enlace activo con el entorno de Snowflake. Encapsula tu autenticación, tu warehouse de destino y tu contexto. Para construirlo, usas el objeto builder disponible en la clase Session. El enfoque más directo es pasar un diccionario. Creas un diccionario de Python con keys para tu account, user, password, role, database y warehouse. Pasas ese diccionario al método configs del builder de la sesión, y luego llamas al método create. La lógica fluye directamente desde tu diccionario al backend de Snowflake. Pero hardcodear credenciales dentro de un script de Python es un riesgo de seguridad enorme, lo que hace que este enfoque no sea adecuado para herramientas compartidas. Para sacar las credenciales de tu código, Snowpark se apoya en un archivo de configuración estándar llamado connections.toml. Colocas este archivo en la raíz de tu proyecto o en un directorio oculto snowflake dentro de tu carpeta home de usuario. El archivo TOML contiene bloques de conexión. Puedes definir un bloque default, un bloque dev y un bloque prod, cada uno con sus propios parámetros de conexión. Aquí está la clave. Cuando usas un archivo TOML, tu código Python se simplifica drásticamente. No pasas ningún diccionario en absoluto. Simplemente llamas al método get o create en el builder de la sesión. Snowpark escanea automáticamente los directorios estándar, encuentra tu archivo TOML, lee el bloque default e instancia la sesión. Si quieres un entorno específico, le pasas el nombre de la conexión al método configs antes de crear la sesión. Tu código se mantiene limpio y las credenciales permanecen seguras en la máquina local. Podemos asegurar nuestra herramienta de línea de comandos aún más. Incluso con un archivo TOML, puede que no quieras que los desarrolladores almacenen contraseñas permanentes localmente. Puedes eliminar las contraseñas por completo usando Single Sign-On basado en el navegador. En tu archivo TOML, omites la key password. En su lugar, añades una key llamada authenticator y configuras su valor como externalbrowser. Cuando tu script llega al paso de creación de sesión, la ejecución se pausa. Snowpark intercepta el proceso y abre automáticamente el navegador web por defecto del usuario. Redirige al desarrollador al identity provider de tu organización. El desarrollador se loguea normalmente, cumpliendo con cualquier requisito de autenticación multifactor. Una vez que el identity provider aprueba el login, envía un token de autenticación temporal de vuelta a un puerto local en el que Snowpark está escuchando. El script recibe el token, establece la sesión segura de Snowflake y la ejecución de Python se reanuda. Tu herramienta CLI ahora tiene acceso totalmente autenticado a Snowflake sin que una sola contraseña toque jamás tus archivos de configuración o tu código fuente. La credencial más segura es la que nunca toca tu código, y delegar la autenticación al navegador mantiene tus scripts locales seguros y completamente enfocados en los datos. Me gustaría tomarme un momento para darte las gracias por escucharnos, nos ayuda mucho. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 4 de 17. Quieres probar una transformación de datos rápida, pero tu entorno local de Python vuelve a fallar. Tus connection strings están desactualizadas y acabas de perder veinte minutos intentando autenticarte. ¿Y si pudieras escribir código contra un entorno completamente configurado directamente en tu navegador con cero setup? Ese es precisamente el problema que resuelven los Python Worksheets en Snowsight. Los Python Worksheets son un editor de código nativo integrado directamente en la interfaz web de Snowflake. Eliminan la fricción de configurar el entorno local. Imagina prototipar un script rápido de limpieza de datos sobre datos en vivo. En lugar de abrir un IDE y gestionar credenciales, abres una pestaña del navegador y empiezas a escribir código inmediatamente. La lógica de ejecución se basa en un entry point designado. No escribes un script procedural suelto. Snowflake necesita una función específica para lanzar tu código. Por defecto, es una función handler llamada main. Esta función recibe un único argumento, que es el objeto session activo. Como ya estás logueado en la interfaz de Snowflake, el sistema gestiona la autenticación automáticamente y pasa una session activa directamente a tu función main. Usas esta session para leer tablas, ejecutar queries y manipular datos usando los métodos estándar de Snowpark. Aquí está la clave sobre las dependencias. Igual te esperas abrir una terminal y usar pip para instalar tus librerías, pero así no es como funcionan los worksheets. No usas pip en absoluto. Snowflake se integra de forma nativa con el repositorio de Anaconda. Dentro de la interfaz del worksheet, hay un menú desplegable de packages dedicado. Simplemente buscas la librería que necesitas, como pandas o scikit-learn, seleccionas la versión, y Snowflake la aprovisiona para tu entorno de ejecución al instante. Eso cubre los inputs y el setup. ¿Qué pasa con los outputs? Tu función handler debe devolver un valor, y tú configuras cómo Snowflake interpreta este valor usando los settings del worksheet. Principalmente, eliges entre dos return types, Table o String. Si configuras el return type en Table, tu función main necesita devolver un DataFrame de Snowpark. Snowflake coge ese DataFrame y lo renderiza como un grid limpio e interactivo en el panel de resultados. Esto es perfecto para inspeccionar el output de tu script de limpieza de datos. Si configuras el return type en String, tu función debe devolver un valor de texto escalar. Usas esto cuando quieres devolver un mensaje de estado, un agregado numérico casteado a texto, o un payload JSON. Debes alinear tu código con los settings del worksheet. Si configuras el worksheet para que espere un Table pero tu función devuelve un String, la ejecución fallará. El verdadero poder de los Python Worksheets no es crear aplicaciones masivas de múltiples archivos. Es la capacidad de validar la lógica de transformación contra datos a escala de producción en segundos, de forma segura, sin tener que configurar nunca una máquina local. Gracias por pasarte. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 5 de 17. Si instancias un DataFrame que representa mil millones de filas, ¿cuánta memoria consume en tu portátil? Casi cero. El motivo se reduce a la mecánica central de construir DataFrames de Snowpark. Un DataFrame de Snowpark no es un contenedor que almacena tu información. Es simplemente una referencia lógica a los datos que residen en Snowflake. Cuando defines un DataFrame en tu código Python, estás construyendo un query plan. Esto se basa en un concepto llamado lazy evaluation. Con el lazy evaluation, Snowpark retrasa la ejecución del SQL subyacente hasta que haces un trigger explícito de una acción que requiere un resultado final. Hasta que ocurre ese trigger, cada DataFrame que construyes es solo un conjunto ligero de instrucciones. La forma principal de empezar a construir estas instrucciones es mediante el método session dot table. Le pasas el nombre de una tabla o vista existente de Snowflake como un string. Puedes pasarle solo el nombre de la tabla, o un fully qualified name que incluya la base de datos y el schema. Un error frecuente que cometen los nuevos usuarios es asumir que llamar a session dot table descarga el contenido de la tabla en su entorno local de Python, de forma similar a como funciona Pandas. No es así. Si apuntas session dot table a un log de transacciones de diez terabytes, la función de Python devuelve el resultado en milisegundos. Ningún dato viaja por la red. El objeto DataFrame simplemente registra esa tabla específica como el nodo raíz de tu execution plan. Otro enfoque es el método session dot sql. Lo usas cuando quieres definir un DataFrame usando un string de raw SQL. Esto es especialmente útil si tienes una query existente que quieres portar, o si prefieres expresar una extracción inicial específica en SQL. Al igual que con el método table, pasar una query a session dot sql no envía la query a Snowflake para su ejecución inmediata. Crea un DataFrame que representa el output de esa query específica. Puedes pensar en ello como definir una inline view. El tercer mecanismo es el método session dot create dataframe. Este funciona de manera diferente porque empieza con datos que ya están en tu máquina local. Puedes pasarle una lista de Python, un diccionario o un DataFrame de Pandas a este método. Al ejecutarse, Snowpark coge esos datos locales, los sube a Snowflake y los mete en una tabla temporal. Luego, el método devuelve un DataFrame de Snowpark que apunta a esa nueva tabla temporal. Aquí está la clave. Como session dot create dataframe mueve físicamente los datos de tu máquina a Snowflake, su rendimiento depende por completo del tamaño de tu dataset local y de tu conexión de red. Lo usas para hacer push de pequeñas lookup tables o parámetros de configuración a Snowflake para que puedan interactuar con tus datasets más grandes. Puedes dejar que Snowpark infiera los nombres de las columnas y los data types de tus objetos locales, o puedes definir explícitamente un schema usando un objeto StructType de Snowpark para asegurar la precisión. Cada vez que construyes un DataFrame de Snowpark, sin importar el método, estás definiendo una relación con los datos en lugar de recuperar los datos en sí. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 6 de 17. Escribes diez operaciones complejas de DataFrame seguidas, pero el sistema no ejecuta diez queries separadas. En cambio, retrasa la ejecución y construye una sentencia SQL perfectamente optimizada por debajo. Hoy hablamos sobre transformar DataFrames. Cuando transformas un DataFrame, estás preparando una receta sobre cómo dar forma a tus datos. Para construir esta receta, necesitas una forma fiable de referenciar las columnas de datos subyacentes. Esto lo haces usando una función llamada col. Le pasas el nombre de una columna como string a esta función, y te devuelve un objeto columna. Luego usas este objeto dentro de otros métodos para construir expresiones, como comprobar si el valor de una columna es igual a un número específico o a un string. Veamos un caso práctico. Tienes dos DataFrames. Uno contiene perfiles de clientes y el otro tiene registros de transacciones. Quieres identificar a los usuarios de alto valor y conectarlos con sus compras recientes. Si escribieras esto en raw SQL, podrías acabar con una query anidada enorme que te obligaría a leer la lógica de dentro hacia fuera. Con DataFrames, usas method chaining para escribir la lógica de arriba a abajo. Primero, coges tu DataFrame de clientes y llamas al método filter. Dentro de ese filter, usas la función col para apuntar a la columna del nivel de gasto, y especificas que debe ser igual a tu nivel más alto. Justo después de ese filter, haces chain de un método select. Usas la función col otra vez para indicar que solo quieres quedarte con el ID de cliente y el email. Cada transformación devuelve un nuevo DataFrame, lo que te permite enganchar la siguiente instrucción directamente al final de la anterior. Ahora, la segunda parte de esto es traer los datos de las transacciones. Llamas al método join en tu DataFrame de clientes filtrado. Pasas el DataFrame de transacciones como primer argumento. Luego, especificas la condición para el join, como que coincida la columna del ID de cliente en ambos datasets. También puedes definir el tipo de join, como un inner join o un left join. La lógica se lee de forma secuencial. Filtras, haces select y haces join. Aquí está la clave. Mientras Python lee este chain de métodos, Snowpark no toca los datos reales. Las transformaciones se evalúan de forma lazy. El DataFrame simplemente actúa como un blueprint. Registra cada filter, select y join que pides, pero no los ejecuta paso a paso. Esta ejecución retrasada permite que el framework analice toda tu secuencia de operaciones y la optimice antes de que nada se ejecute realmente. La ejecución solo se dispara cuando finalmente pides un resultado concreto. Esto requiere llamar a un método de acción. Si quieres imprimir una pequeña muestra de los datos en tu terminal, llamas al método show. Si quieres descargar los resultados completamente procesados de vuelta a tu memoria local de Python, llamas al método collect. En el momento en que llamas a collect, Snowpark traduce tu blueprint en una única query SQL eficiente y la envía a Snowflake. Obtienes la ventaja de escribir Python legible paso a paso, mientras que el motor de la base de datos sigue procesando los datos en una sola pasada altamente optimizada. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 7 de 17. Estás construyendo un data pipeline y de repente necesitas una manipulación de strings compleja o una conversión matemática poco común. No tienes que escribir esa lógica desde cero en Python. La base de datos ya sabe cómo hacerlo. Ahí es donde entra en juego llamar a las system functions. Snowflake tiene cientos de system functions integradas escritas en C++ altamente optimizado. Estas se encargan de todo, desde hacer parsing de texto hasta calcular desviaciones estándar. Snowpark te permite ejecutar estas funciones SQL nativas directamente desde tu código Python. Tienes la estructura familiar de Python, pero el trabajo pesado ocurre completamente dentro de Snowflake. Los datos reales nunca salen del servidor para ser procesados en tu entorno local de Python. Para acceder a ellas, importas el módulo snowflake punto snowpark punto functions. Este módulo contiene wrappers directos de Python para la mayoría de las operaciones SQL estándar. Si necesitas convertir texto a mayúsculas, simplemente llamas a la función upper de este módulo y le pasas tu objeto column. Por debajo, Snowpark traduce tu código Python a la sintaxis SQL equivalente y lo envía a la base de datos para que se ejecute. Esto cubre la mayoría de los casos de uso. Pero, ¿qué pasa cuando Snowflake lanza una nueva función SQL, o necesitas usar una system function especializada que aún no tiene un wrapper explícito de Python en el módulo? No tienes que esperar al próximo release de la librería Snowpark para usarla. Esta es la parte que importa. Puedes usar un método dedicado llamado call_function para invocar cualquier system function de Snowflake por su nombre SQL exacto. Imagina un escenario donde tienes una tabla con millones de filas que contienen mediciones de ángulos en grados, y tu modelo de machine learning downstream las requiere en radianes. En lugar de escribir una transformación matemática a medida en Python que arrastre todas esas filas a la memoria, dejas que el motor de la base de datos haga el trabajo. Importas call_function. Luego, lo invocas pasándole el string radians como primer argumento. El segundo argumento es el objeto column que quieres transformar. Snowpark hace un push down instantáneo de eso como una operación SQL nativa de radians en todo tu dataset. Se ejecuta con la velocidad del código C++ compilado, y te lleva exactamente una línea de Python escribirlo. El método call_function es flexible. Si la función SQL subyacente requiere múltiples inputs, simplemente los pasas en secuencia después del nombre de la función. Estos inputs pueden ser otros objetos column, o pueden ser valores literales, como un string o un número específico. Snowpark mapea tus argumentos de Python directamente a los parámetros SQL esperados. Este diseño mantiene tu código limpio mientras maximiza el rendimiento. No pierdes el acceso a la potencia bruta de las funciones SQL nativas de Snowflake solo porque estés escribiendo en un lenguaje diferente. Al aprovechar las system functions, tratas a Python como el orquestador, dejando que el motor de la base de datos haga exactamente lo que fue construido para hacer. Gracias por escuchar. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 8 de 17. Escalar un pipeline de pandas existente tradicionalmente implicaba tirar tu código y reescribirlo todo en un framework distribuido como Spark. ¿Y si pudieras manejar un dataset cien veces mayor con solo cambiar un import? Esa es la premisa de pandas en Snowflake. pandas es el estándar universal para la manipulación de datos en Python. Es expresivo, legible y está profundamente arraigado en la forma en que trabajan los ingenieros y científicos de datos. El problema es que pandas está fundamentalmente limitado a la ejecución en un solo nodo. Requiere que todos tus datos quepan en la memoria local. Cuando tu dataset supera la capacidad de tu portátil o de tu instancia en la nube, el pandas estándar falla. pandas en Snowflake representa un cambio de paradigma completo para estos pipelines legacy. Actúa como una herramienta de migración sin fricciones. Supongamos que tienes un script de Python que limpia y agrega logs de transacciones diarias. Funciona perfectamente con diez gigabytes de datos, pero de repente te piden procesar un terabyte. Para escalar esto, no necesitas reescribir tu lógica en SQL. Ni siquiera necesitas aprender la sintaxis específica de la API de DataFrames estándar de Snowpark. Solo tienes que cambiar una línea al principio de tu archivo. Eliminas el import estándar import pandas as pd. Y lo reemplazas por import snowflake.snowpark.modin.pandas as pd. Aquí es donde la cosa se pone interesante. Un punto de confusión muy común es cómo procesa esto los datos realmente. Muchos desarrolladores asumen que esto es simplemente el pandas estándar operando sobre una conexión activa, descargando millones de filas a su máquina local para procesarlas. Eso es incorrecto. Cuando usas este import específico de Modin, no se descarga ningún dato a tu máquina. En su lugar, esta librería intercepta cada comando de pandas que escribes en tu script. Cuando haces un chain de un filter, un group-by y una agregación de media, el motor subyacente traduce esa secuencia exacta en una query SQL optimizada de Snowflake. Transpila tu sintaxis de pandas a SQL, y luego envía ese SQL al motor de computación de Snowflake. La operación se ejecuta completamente dentro de tu warehouse de Snowflake. Tu máquina local solo se encarga de orquestar los comandos. El trabajo pesado se distribuye entre los clusters de Snowflake. Esto te da la misma developer experience de pandas, pero respaldada por una base de datos masivamente paralela. Este cambio resuelve dos grandes dolores de cabeza organizativos a la vez. Primero, elimina el problema del data egress. Como las operaciones se envían a la base de datos, tus datos raw nunca salen del perímetro seguro de Snowflake. Segundo, ahorra meses de reentrenamiento de desarrolladores. Tu equipo sigue escribiendo los mismos dataframes, joins y agregaciones que ya conocen a la perfección. Simplemente los ejecutan contra la nube en lugar de en su procesador local. El verdadero poder de pandas en Snowflake es que desacopla el lenguaje que utilizas para describir tus transformaciones de datos del motor que realmente las ejecuta. Si estos deep dives técnicos te resultan útiles, puedes apoyar el programa buscando DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 9 de 17. Tu código ahora es lo suficientemente inteligente como para saber exactamente cuándo usar la memoria de tu portátil y cuándo iniciar un cluster en la nube. Este es el concepto fundamental de pandas en Snowflake: Hybrid Execution. Cuando usas pandas estándar, cada operación se ejecuta en la memoria de tu máquina local. Si cargas un dataset enorme, tu proceso falla. La API de pandas de Snowpark resuelve esto mapeando tus comandos de pandas a SQL y ejecutándolos en el warehouse de Snowflake. Pero no todas las funciones de pandas tienen un equivalente directo en SQL. Ciertas operaciones, como hacer plotting o aplicar funciones custom de Python, requieren la librería local de pandas para ejecutarse. El desafío es cambiar sin problemas entre el motor en la nube y tu entorno local sin arrastrar gigabytes de raw data a través de la red. Hybrid Execution gestiona esta transición dinámicamente. Es un modelo de ejecución diseñado totalmente para optimizar al máximo el coste de transferencia de datos. Cuando ejecutas un script usando la API de pandas de Snowpark, el motor actúa como un router inteligente. Su comportamiento por defecto es mantener los datos en la nube. Traduce tu código a queries SQL y las ejecuta utilizando el compute de Snowflake. Veamos un escenario práctico. Empiezas con una tabla que contiene diez millones de filas. Escribes una línea de código para filtrar los registros no válidos y, a continuación, agrupas los datos para calcular una media. Hasta este punto, el motor traduce tus comandos de filtrado y agregación directamente a SQL. El warehouse de Snowflake hace el trabajo pesado. Tu máquina local no descarga ni una sola fila de ese enorme dataset. La agregación reduce esos diez millones de filas a una tabla resumen de exactamente siete filas. Como siguiente paso, escribes un comando para hacer un plot de esas siete filas en un gráfico. El plotting es, por naturaleza, una operación local. El motor de base de datos de Snowflake no puede dibujar un gráfico por ti. Aquí está la clave. El motor reconoce que el comando plot requiere una transición al backend local de pandas. Dado que el motor procesa tus operaciones de forma inteligente, analiza el estado de tus datos justo antes de que se solicite la operación local. Sabe que la agregación previa da como resultado solo siete filas. Por lo tanto, en lugar de mover los diez millones de filas originales a tu portátil para procesar la agregación localmente, deja que Snowflake termine los cálculos en la nube. A continuación, lanza una descarga de solo esas siete filas finales a tu memoria local. Una vez que los datos llegan a tu entorno local, el pandas estándar toma el control. La librería local ejecuta el comando plot utilizando esas siete filas. Cualquier operación posterior que realices sobre esa estructura de datos específica seguirá ejecutándose localmente, ya que los datos ya han cruzado el límite de la red. El sistema aísla la manipulación pesada de datos dentro de la infraestructura de la nube. Pospone la transferencia de red hasta que una operación requiere estrictamente la ejecución local. Para cuando se produce esa demanda, tus pasos de manipulación de datos generalmente han reducido el dataset a una fracción de su tamaño original. Conservas la sintaxis de la API que ya conoces, pero evitas por completo el cuello de botella de la red. La característica principal de Hybrid Execution no es solo que hace fallback a la memoria local, sino que reduce estratégicamente el payload en la nube antes de dar el salto. Eso es todo por este episodio. ¡Gracias por escuchar y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 10 de 17. ¿Qué pasaría si pudieras consultar una base de datos PostgreSQL desde tu script de Python en Snowflake? Normalmente, transferir datos de una base de datos operativa a Snowflake requiere un intermediario externo. Configuras una herramienta de extracción en un servidor aparte, gestionas credenciales, preparas archivos en un stage y programas jobs solo para tener los datos listos para el análisis. La ingesta directa de datos externos a través de Snowpark Python resuelve este problema eliminando por completo el intermediario. Este enfoque te permite simplificar tu arquitectura de datos. Al aprovechar el acceso a la red externa en Snowflake, tu código Python puede conectarse directamente a otros sistemas. Puedes usar las librerías estándar de Python DB-API o los drivers JDBC para conectarte a bases de datos externas, directamente desde un stored procedure de Snowpark o una user-defined table function. Imagina un escenario concreto. Tienes una base de datos de inventario PostgreSQL legacy on-premise, y necesitas hacer un join de esos datos de inventario con tus tablas de clientes de Snowflake en producción. En lugar de montar un pipeline de ingesta complejo, escribes un stored procedure de Snowpark Python. Dentro de ese procedure, usas un conector estándar DB-API de Postgres. Le pasas tu connection string, que hace referencia a las credenciales gestionadas de forma segura por Snowflake. Abres la conexión, ejecutas un select statement estándar de SQL contra la base de datos PostgreSQL externa, y haces un fetch del result set. Una vez que los datos están en memoria dentro de tu función de Python, simplemente haces un yield de las filas de vuelta a Snowflake, o las conviertes directamente en un DataFrame de Snowpark. Ahora tienes tus datos de inventario externos disponibles como un objeto nativo de Snowflake, listos para hacer un join con tus tablas de clientes en una sola query. La lógica fluye desde el sistema operacional externo directamente a tu entorno analítico, de forma segura y sin servidores de staging intermedios. Eso cubre los inputs relacionales. ¿Qué pasa con las fuentes de datos semiestructuradas, como los archivos anidados que se dejan en un stage? Snowpark también proporciona herramientas específicas para parsear formatos complejos. Un ejemplo clave es el reader de XML RowTag. Cuando necesitas ingerir un archivo XML pesado, no tienes que escribir lógica de parsing personalizada para navegar por todo el árbol del documento. En su lugar, especificas un row tag. Este es el elemento XML específico que representa un único registro. Llamas al método read en tu session de Snowpark, configuras el formato como XML y proporcionas el parámetro row tag. Snowflake escanea el documento, identifica cada instancia de ese tag y la extrae como una fila individual en un DataFrame. La jerarquía compleja por encima y por debajo de ese tag se aplana o se empaqueta en columnas, dependiendo de tu schema. Convierte un documento de texto anidado en una tabla limpia y lista para hacer queries en un solo paso. Aquí está la clave. Ya sea que estés abriendo una conexión JDBC a una base de datos on-premise antigua o apuntando un reader de row tag a un archivo XML anidado, estás consolidando tu lógica de ingesta dentro de la plataforma de datos. Estás transformando los problemas de integración en simples problemas de ejecución de código. Gracias por escuchar. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 11 de 17. ¿Cómo ejecutas lógica personalizada de parsing de strings en Python a través de miles de millones de filas sin mover los datos? La respuesta está en crear UDFs escalares, o User-Defined Functions. Las funciones SQL estándar cubren la mayoría de las transformaciones de datos cotidianas. Cuando el SQL estándar falla, las UDFs de Python entran en acción sin problemas. Si trabajas con reglas muy personalizadas, como escribir una regex compleja para parsear direcciones de correo electrónico sucias, el SQL puro se vuelve rápidamente ilegible o imposible. Las UDFs escalares resuelven este problema permitiéndote escribir lógica Python simple y ejecutarla de forma nativa dentro del compute engine de Snowflake. Una función escalar simplemente procesa una fila de entrada y devuelve exactamente un valor de salida. Para hacer deploy de tu código Python, usas Snowpark para registrar la función. Si solo necesitas la lógica para tu script actual, creas una UDF anónima. La forma más fácil de lograrlo es usar el decorador arroba UDF. Primero, escribes una función Python estándar. Llamémosla extract email domain. Dentro de ella, usas el módulo regex estándar de Python para parsear el string de texto y devolver el dominio coincidente. Justo encima de la definición de la función, colocas el decorador arroba UDF. Cuando tu script se ejecuta, Snowpark serializa automáticamente esta función de Python, la envía al servidor y devuelve una referencia a un objeto UDF. Ahora puedes pasar este objeto a las operaciones de columna de tu DataFrame, aplicando tu parser personalizado en tablas masivas como si fuera una característica nativa de la base de datos. Alternativamente, puedes omitir el decorador y pasar tu función de Python explícitamente al método session punto udf punto register. Ambos métodos crean un objeto temporal en el motor de la base de datos. En el momento en que tu sesión de Snowpark se cierra, la UDF anónima se elimina por completo. Aquí es donde la cosa se pone interesante. Si tu nueva lógica de parsing es valiosa, probablemente quieras compartirla con otros usuarios o hacerla disponible para pipelines SQL downstream. Para lograr esto, creas una UDF permanente y con nombre. Usando el mismo método register, añades un flag is permanent en true, y proporcionas un valor de string para el parámetro name. Este nombre determina cómo se llamará a la función en la base de datos. Cuando haces que una UDF sea permanente, Snowflake necesita un lugar físico para persistir tu código Python y que siga disponible mucho después de que tu sesión se desconecte. Por esto, también debes proporcionar un parámetro stage location. Este apunta a un stage interno existente de Snowflake. Snowpark subirá y almacenará de forma segura los archivos Python compilados directamente en ese stage. Una vez que termina el registro, cualquiera con los permisos de base de datos correctos puede llamar a tu lógica Python personalizada directamente desde una query SQL estándar. Al crear cualquier UDF, Snowpark normalmente se basa en los type hints de Python para entender qué tipos de datos acepta y devuelve la función. Si tu función espera un string y devuelve un string, añades esos type hints estándar a la definición de Python, y Snowpark los mapea automáticamente a los tipos de datos equivalentes de Snowflake. El verdadero poder de la UDF escalar no es solo la capacidad de escribir Python, sino la capacidad de ejecutar ese Python dentro de la memoria distribuida del motor de la base de datos, eliminando por completo la latencia de red de sacar los datos para procesarlos. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 12 de 17. Ejecutar paquetes Python de terceros dentro de una base de datos solía ser un infierno de dependencias. Terminabas creando complejos contenedores Docker solo para pasar un array a través de una función matemática. Ahora, basta con exactamente una línea de código. Este episodio trata sobre la gestión de dependencias para UDFs. Cuando escribes una User-Defined Function, o UDF, tu lógica rara vez existe en el vacío. Necesitas librerías. En una configuración tradicional, mover tu código Python a donde viven los datos significa que también tienes que mover todo tu entorno. Te preocupas por los pip installs, las dependencias del compilador y por mantener el servidor idéntico a tu máquina local. Snowflake evita esta pesadilla automáticamente a través de una integración nativa con el Anaconda channel. El Anaconda channel de Snowflake aloja miles de paquetes Python preconstruidos y precompilados que tienen garantizado su funcionamiento dentro del entorno de ejecución de Snowflake. Para usarlos, no instalas nada manualmente. Simplemente declaras lo que necesita tu función. Cuando defines tu UDF usando el decorador de Python, añades un parámetro llamado packages. Le pasas a este parámetro una lista de strings, nombrando las librerías que necesitas. Imagina un escenario concreto. Quieres usar un modelo de machine learning para hacer scoring de filas directamente dentro de una query de Snowflake. Tu función de predicción depende de scikit-learn y pandas. Justo encima de tu función de Python, añades el decorador UDF y configuras la lista packages para que contenga los strings scikit-learn y pandas. No construyes un contenedor, y no ejecutas un gestor de paquetes. Cuando llamas a esa UDF, Snowflake aprovisiona un entorno seguro, descarga esos paquetes exactos del Anaconda channel y ejecuta tu código. Si necesitas una versión específica, puedes fijar la versión añadiendo dos signos de igual y el número de versión justo dentro del string, igual que en un archivo requirements estándar de Python. Eso cubre las librerías externas. Ahora, la segunda parte de esto es tu propio código personalizado. No todo lo que escribes pertenece a Anaconda. A menudo tienes funciones helper o reglas de negocio personalizadas escritas en un archivo Python separado. Snowflake gestiona este código propio a través de tu sesión activa. Llamas a un método llamado add import en el objeto session. Le pasas la ruta de tu archivo personalizado a add import. Puede ser un archivo Python local en tu portátil, un archivo que ya esté en un stage de Snowflake, o un archivo zip que contenga un directorio de módulos más profundo. Cuando registras tu UDF, Snowflake coge los archivos que especificaste y los sube. En runtime, Snowflake extrae esos archivos y los coloca directamente en el system path del entorno aislado que ejecuta tu UDF. Dentro del código de tu función principal, simplemente usas sentencias import estándar de Python para traer tus módulos personalizados, exactamente como si estuvieran en la misma carpeta localmente. Puedes combinar libremente estos dos enfoques. Declaras tus requirements externos mediante el parámetro packages, e inyectas tus módulos internos usando add import. Snowflake construye el contexto de ejecución fusionando de forma segura los binarios de Anaconda con tus archivos personalizados en stage antes de que se procese una sola fila de datos. Aquí está la clave. Al gestionar las dependencias de esta manera, Snowflake desacopla completamente tu código funcional de la infraestructura necesaria para ejecutarlo, permitiéndote definir un entorno de ejecución distribuido y seguro usando nada más que una lista de nombres y rutas de archivo. Gracias por escuchar, ¡feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 13 de 17. ¿Qué haces cuando tu función de Python necesita devolver una tabla completa de resultados en lugar de un solo valor? Las funciones definidas por el usuario estándar son geniales, pero están estrictamente limitadas a devolver un único valor escalar por fila de entrada. Cuando necesitas descomponer una sola entrada en múltiples salidas, creas una User-Defined Table Function, o UDTF. La diferencia es fundamental. Una función estándar devuelve un solo valor. Una UDTF devuelve una relación. Esto significa que devuelve una estructura tabular a la que puedes hacer queries, filtrar o hacer join con otras tablas exactamente como si fuera una tabla física en tu base de datos. Imagina un escenario concreto. Tienes una tabla con una columna que contiene logs de aplicación en JSON personalizados y muy anidados. Cada fila contiene una entrada de log enorme, pero esa única entrada podría contener cinco, diez o cincuenta eventos del sistema distintos ocultos en lo más profundo del JSON. Necesitas normalizar estos datos programáticamente. Quieres pasar un string JSON y obtener una tabla estructurada donde cada evento individual se extraiga en su propia fila. Para crear una UDTF en Snowpark Python, no escribes una función independiente. Escribes una clase de Python. Esta clase actúa como handler para la table function y orquesta la lógica usando hasta tres métodos específicos. El primero es el método de inicialización. Este es opcional. Snowflake lo ejecuta una vez por partición antes de procesar cualquier fila. Si tu parser de logs necesita compilar una expresión regular compleja o inicializar un diccionario de estado personalizado, lo haces aquí para que el coste de configuración se pague solo una vez por lote de datos. El segundo es el método process. Este es el único método obligatorio en la clase. Snowflake lo llama para cada fila de entrada. En nuestro escenario de logging, el método process recibe el string JSON, desempaqueta el array de eventos y los recorre en un bucle. Aquí es donde ocurre la conversión. En lugar de devolver un valor final, el método process hace yield de tuplas. Cada tupla a la que hace yield se convierte instantáneamente en una nueva fila en tu tabla de salida. Si un string de log en JSON contiene doce eventos, el método process hace yield de doce tuplas separadas, y Snowflake las convierte en doce filas de salida distintas. El tercero es el método end partition. Este también es opcional. Snowflake lo dispara después de que todas las filas de la partición actual hayan pasado por el método process. Normalmente usas esto si estabas agregando estado en toda la partición y necesitas hacer yield de una fila de resumen final, o simplemente para limpiar memoria y recursos. Cuando registras esta clase handler en Snowpark, debes declarar explícitamente tu esquema de salida. Como una UDTF devuelve una tabla, el motor de ejecución de la base de datos necesita conocer los nombres exactos de las columnas y los tipos de datos de las tuplas a las que estás haciendo yield antes incluso de que se ejecute la query. Aquí está la clave. Las UDTFs cierran la brecha entre la lógica compleja de Python y las operaciones de bases de datos relacionales, permitiéndote encapsular el desordenado desanidamiento procedimental de datos dentro de una interfaz de tabla limpia a la que el resto de tu aplicación puede hacer queries de forma nativa. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 14 de 17. Deja de pagar por un servidor de orquestación externo solo para ejecutar scripts de Python que le dicen a Snowflake qué hacer. La creación de Stored Procedures integra ese control flow directamente en la plataforma de datos. A menudo la gente confunde los Stored Procedures con las User-Defined Functions, o UDFs. Una UDF no está pensada para la orquestación. Las UDFs devuelven valores dentro de una query y transforman los datos fila por fila. Los Stored Procedures son completamente diferentes. Ejecutan scripts enteros, lanzan múltiples queries y gestionan el control flow procedimental. Los usas para orquestar tareas, no para calcular valores de columnas. Para crear un Stored Procedure en Snowpark Python, escribes una función estándar de Python. El requisito fundamental es el primer argumento de esa función. Siempre debe ser un objeto Session de Snowpark. Esta Session es tu enlace activo con la base de datos. Cuando tu procedimiento se ejecuta, usa esta Session para ejecutar sentencias SQL, construir DataFrames y leer o escribir datos. Para decirle a Snowflake que esta función es un Stored Procedure, pones el decorador sproc justo encima de la definición de tu función. El decorador actúa como capa de configuración. Lo usas para especificar el return type de tu procedimiento y cualquier paquete de Python de terceros que tu código necesite para ejecutarse. Cuando ejecutas el código de registro, Snowpark coge tu función de Python, la empaqueta junto con sus dependencias y la registra en Snowflake. A partir de ese momento, la lógica vive dentro de la base de datos y se ejecuta en el compute de Snowflake. Piensa en una data pipeline nocturna. Tu proceso necesita crear una tabla temporal, cargar raw data en ella, ejecutar una serie de transformaciones de varios pasos y, finalmente, limpiar los objetos temporales. Si ejecutas esto desde un servidor externo, tu código Python envía un comando por la red, espera a que Snowflake termine, recibe el resultado y envía el siguiente comando. Al escribir esta misma lógica de Python como un Stored Procedure, todo el script se ejecuta dentro de Snowflake. Usa el objeto Session para ir paso a paso por las creaciones de tablas y las transformaciones de DataFrames de forma nativa. Hay cero latencia de red entre la lógica de orquestación y los datos que manipula. Aunque un Stored Procedure no devuelve un valor por fila como una UDF, sigue devolviendo un único valor cuando el script termina. Tú defines este return type cuando configuras el decorador sproc. A menudo, esto es un simple string confirmando el éxito, un integer que representa el total de filas procesadas, o incluso un resultado tabular que muestra un log de ejecución. Tienes varias opciones sobre cómo hacer el deploy de este código. Puedes definir y ejecutar un procedimiento anónimo dinámicamente en un script de Python si solo lo necesitas para una única Session. Para pipelines automatizadas, lo registras como un objeto permanente. Snowflake guarda la definición para que cualquier usuario autorizado, aplicación externa o tarea programada pueda llamarlo más tarde. Aquí está la clave. Escribir un Stored Procedure de Snowpark Python significa que estás tratando a Snowflake como un runtime de aplicaciones, no solo como una capa de almacenamiento. Estás moviendo el cerebro de tu orquestación justo al lado de los datos que controla. Si disfrutas del programa y quieres apoyar el trabajo que hacemos, puedes encontrarnos buscando DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 15 de 17. Mover terabytes de datos seguros a un servidor externo de machine learning es lento, caro y arriesgado. Te pasas horas enviando datos por la red, y tu equipo de seguridad se pone nervioso por dónde acaban. ¿Y si en lugar de eso, el compute fuera hacia los datos? Esta es la idea principal detrás de entrenar modelos de machine learning dentro de Snowflake. Aprovechando Snowpark Python, puedes entrenar modelos de machine learning single-node directamente dentro de tu data warehouse usando stored procedures. Los datos nunca salen del perímetro de Snowflake. Esto resuelve el problema de la data gravity. En lugar de extraer millones de filas a una instancia cloud separada, ejecutas tu script de entrenamiento justo donde viven los datos. Entrenar un modelo de machine learning requiere cargar el dataset en memoria. Un virtual warehouse estándar en Snowflake está optimizado para queries SQL en paralelo, no para mantener datasets masivos en la RAM del sistema. Si intentas meter un algoritmo complejo en un warehouse estándar, lo más probable es que te topes con errores out-of-memory y el proceso pete. Para manejar esto, necesitas un perfil de compute diferente. Snowflake proporciona warehouses optimizados para Snowpark específicamente para esta tarea. Estos warehouses ofrecen hasta dieciséis veces más memoria por nodo en comparación con las instancias estándar. Veamos un escenario concreto. Necesitas entrenar un modelo random forest de scikit-learn con un dataset de clientes enorme. Empiezas escribiendo un stored procedure en Python. Al registrar este procedure, especificas los paquetes de Python necesarios, como scikit-learn, pandas y joblib. Snowflake aprovisiona automáticamente estas dependencias usando su canal de Anaconda integrado. También asignas el procedure para que se ejecute en tu warehouse optimizado para Snowpark. Dentro del procedure, usas el objeto session de Snowpark para definir la query de tus datos de entrenamiento. Luego llamas al método para convertir ese dataframe de Snowpark en un dataframe estándar de pandas. Esta acción se trae los resultados de la query directamente a la memoria física del nodo del warehouse. Como aprovisionaste el compute optimizado, hay RAM de sobra para mantener todo el dataset a la vez. Después, inicializas tu modelo random forest e invocas el método fit, pasándole el dataframe de pandas. El procesador del warehouse gestiona el ciclo de entrenamiento exactamente igual que lo haría en un servidor dedicado de machine learning. Una vez que el modelo termina de entrenar, tienes un algoritmo entrenado esperando en la memoria temporal del entorno de ejecución. Tienes que persistirlo para futuras predicciones antes de que termine el stored procedure. Aquí es donde entra en juego la serialización. Usas una librería como joblib para empaquetar el modelo. Coges el objeto del modelo entrenado en memoria y haces un dump a un archivo, creando un artefacto. Luego le indicas al stored procedure que escriba ese archivo recién creado directamente en un stage interno de Snowflake. Un stage actúa como una carpeta de almacenamiento seguro vinculada a tu cuenta de Snowflake. Aquí está la clave. Tu stored procedure actúa como un contenedor seguro que conecta tus tablas raw con las librerías estándar de machine learning de Python. Al mantener el pipeline completamente dentro de Snowflake, reduces la latencia de red a cero, te saltas todas las operaciones de data egress y mantienes controles de acceso estrictos, todo mientras escribes exactamente el mismo código de entrenamiento en Python que ya conoces. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 16 de 17. ¿Cómo procesas archivos no estructurados del tamaño de gigabytes dentro de una user-defined function sin reventar tus límites de memoria? Si intentas mapear archivos grandes como dependencias estáticas, el sistema intenta descargarlo todo por adelantado y tu código crashea. La solución a esto es el Dynamic File Access con SnowflakeFile. Para entender por qué esto importa, fíjate en cómo funciona normalmente el acceso a archivos en Snowpark. Normalmente, usas el parámetro imports para vincular un archivo a tu función. Este enfoque estático es genial para archivos de configuración pequeños o un modelo de machine learning especializado, porque el archivo se descarga al compute warehouse antes de que empiece la ejecución. Pero se viene abajo a gran escala. Si tu pipeline necesita procesar cientos de archivos de log de servidor enormes o PDFs de alta resolución almacenados en un stage de Snowflake, descargarlos todos estáticamente es increíblemente lento y te garantiza un error de out-of-memory. Aquí es donde entra en juego la clase SnowflakeFile. Ubicada en el módulo snowflake punto snowpark punto files, esta clase permite que tu función o stored procedure abra archivos directamente desde un stage en runtime. No vinculas el archivo durante la creación de la función. En su lugar, tu función acepta la ubicación del archivo como un argumento string estándar. Cuando llamas a la función en tu query SQL o en una operación de dataframe, le pasas esa ubicación. Dentro del código Python, llamas al método open en la clase SnowflakeFile y le pasas el string con la ubicación del archivo. También especificas el modo de lectura, usando las convenciones estándar de Python, como r para texto o r b para leer bytes. Aquí está la clave. Llamar a open no carga el archivo. Devuelve un objeto file-like que hace stream de los datos. El archivo se queda en el stage, y tú te traes los datos a través de un pipe de red. Apliquemos esto al escenario de procesamiento de logs. Tienes una tabla de base de datos donde cada fila contiene una scoped URL que apunta a un archivo de log grande diferente en un stage interno. Le pasas esa columna de la URL a tu función. Dentro de la función, abres el stream y escribes un bucle estándar para leer el archivo línea por línea. A medida que tu código evalúa cada línea para extraer códigos de error o timestamps, Python descarta las líneas anteriores de la memoria. Puedes parsear un archivo de log de cincuenta gigabytes mientras tu función solo mantiene una única línea de texto en memoria en cualquier milisegundo dado. Exactamente el mismo concepto funciona para archivos binarios. Si estás extrayendo texto de PDFs grandes, abres el archivo en modo binario y pasas el stream resultante directamente a una librería de Python para parsear PDFs. La librería lee el stream de bytes secuencialmente sin requerir que todo el documento resida en la memoria del sistema. SnowflakeFile también gestiona el security boundary automáticamente. Cuando pasas una scoped URL generada dinámicamente a tu función, Snowflake otorga acceso de lectura a ese archivo específico solo durante la duración de la query, expirando inmediatamente cuando la query termina. Hacer stream de archivos especificados dinámicamente mantiene tu memory footprint plano independientemente del tamaño del archivo, permitiendo que tu compute warehouse se centre por completo en procesar los datos en lugar de simplemente intentar retenerlos. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Snowflake y Snowpark Python, episodio 17 de 17. Jamás harías deploy de código de una aplicación backend sin unit tests, entonces, ¿por qué los data pipelines a menudo se suben a producción cruzando los dedos? Snowpark cambia esto al hacer que tu lógica de datos sea modular, lo que significa que por fin puedes testearla como cualquier otro software. Testear Snowpark Python es lo que aporta el rigor de la ingeniería de software a la ingeniería de datos. Snowpark te permite extraer tu lógica de transformación de scripts monolíticos y convertirla en funciones de Python independientes. Como estas funciones reciben un DataFrame como input y devuelven un DataFrame como output, puedes testearlas usando frameworks de Python estándar. PyTest es la opción más común. Para ejecutar cualquier código de Snowpark, necesitas una sesión activa. En lugar de meter los detalles de autenticación dentro de cada test, defines un fixture de sesión. Esto lo haces en un archivo de configuración dedicado llamado conftest.py, que PyTest reconoce automáticamente. Dentro de este archivo, escribes una función de setup que establece una conexión con Snowflake, devuelve el objeto de sesión y cierra la sesión cuando terminan los tests. Decoras esta función como un fixture de PyTest. Ahora, cualquier test de tu proyecto puede solicitar una sesión activa simplemente pidiéndola por su nombre en los argumentos de la función del test. Apliquemos esto a un escenario concreto. Tienes una transformación de DataFrame personalizada y compleja que filtra los usuarios inactivos, calcula un risk score y estandariza los nombres de las columnas. Necesitas validar esta lógica antes de hacer deploy del pipeline a producción. Empiezas escribiendo un test. El primer paso dentro de ese test es crear un DataFrame de input que contenga unas cuantas filas de mock data cuidadosamente seleccionada. Defines los nombres exactos de las columnas y los valores de las filas necesarios para activar los edge cases específicos en tu lógica. Usas tu fixture de sesión para convertir esta raw mock data en un DataFrame de Snowpark. A continuación, pasas este DataFrame de mock input a tu función de transformación. La función aplica tu lógica de negocio y devuelve el DataFrame de output real. Ahora necesitas verificar que la lógica hizo lo que se suponía que debía hacer. Creas un segundo mock DataFrame dentro de tu test, esta vez representando el resultado exacto esperado. Esta es la parte que importa. Debes comparar el DataFrame real con el DataFrame esperado. Sin embargo, no puedes simplemente usar un equality check estándar de Python en los propios objetos DataFrame, porque son meramente referencias a query plans. En su lugar, necesitas comparar los datos que contienen. Llamas al método collect en ambos DataFrames, el real y el esperado, para traer los resultados de vuelta a memoria como listas de objetos row. Como las bases de datos distribuidas no garantizan el orden de los result sets a menos que se indique explícitamente, comparar dos listas de filas directamente podría fallar incluso si los datos son correctos. Para solucionar esto, ordenas ambas listas de filas antes de hacer un assert de que son iguales. Si los datos reales ordenados coinciden con los datos esperados ordenados, tu test pasa. Al pasar datasets pequeños y controlados por funciones de transformación aisladas, detectas errores lógicos en local antes de que toquen una tabla de producción. Esto aísla los componentes de tu pipeline y hace que tu workflow de ingeniería de datos sea tan fiable como el desarrollo de software tradicional. Con esto finaliza nuestra serie sobre Snowpark Python. Te animo a explorar la documentación oficial de Snowflake, a probar a escribir estos tests de forma práctica, o a visitar devstories.eu para sugerir temas para nuestras futuras series. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda muchísimo. ¡Que tengas un buen día!