Cómo usar MinIO como tablas externas para extender Snowflake

Snowflake es ahora el estándar de facto para las plataformas de almacenamiento de datos en la nube. Está diseñado para admitir una variedad de tareas de datos desde canalizaciones, ETL, análisis y gobierno. Tradicionalmente, todos los datos debían trasladarse a Snowflake para que una empresa aprovechara las capacidades de Snowflake.

Sin embargo, Snowflake ha entendido que las empresas quieren integrar sus datos dondequiera que residan, sin tener que moverlos. Como resultado, con la introducción del soporte de mesa externo, las empresas ahora podrán lograr precisamente eso.

Esto tiene un impacto real, tanto en la economía de la implementación de Snowflake como en la cantidad de datos disponibles para la plataforma Snowflake para análisis y ciencia de datos.

La disponibilidad de tablas externas no cambiará las ubicaciones donde se ejecuta Snowflake; seguirá ejecutándose exclusivamente en las tres nubes públicas principales (AWS, GCP, Azure). Sin embargo, eliminará el requisito de que todos los datos se almacenen en Snowflake para que Snowflake pueda operar con ellos.

MinIO es quizás el mayor beneficiario de este cambio. MinIO es un almacén de objetos nativos en la nube de alto rendimiento. Funcionará en todos los tipos de Kubernetes (ascendente, EKS, AKS, GKE, etc.), así como en máquinas virtuales como las máquinas virtuales de nube pública, VMWare, etc. y en hardware sin sistema operativo. Debido a esto, MinIO puede convertirse en el almacén de datos global para los clientes de Snowflake, donde sea que se encuentren sus datos.

Para garantizar que los datos correctos estén disponibles para el usuario correcto, es imperativo que haya un control de acceso detallado en estos lagos de datos de múltiples nubes. La capacidad de MinIO para integrarse con IDP de terceros y sus capacidades sofisticadas de control de acceso basado en políticas (PBAC) garantizan que esto no sea una ocurrencia tardía.

Si bien Snowflake admitirá puntos finales S3 (que naturalmente incluyen otros almacenes de objetos), esos almacenes de objetos no pueden ejecutarse en todos los lugares donde una empresa guarda sus datos. Por ejemplo, los dispositivos no se ejecutan en la nube pública ni en OpenShift o Tanzu. Para lograr una estrategia coherente de datos en cualquier lugar, las empresas deberán adoptar MinIO.

Además, Snowflake se ha convertido en una misión crítica en la empresa. Tanto es así que la resiliencia ahora se está integrando en la arquitectura de estos sistemas. Esa resiliencia no solo tiene en cuenta la falla de la región en la nube, sino que también tiene en cuenta la falla de toda la nube.

La dependencia de una sola nube ha demostrado ser una arquitectura deficiente, como he escrito anteriormente. MinIO, con su capacidad de estar disponible en todas partes y replicarse entre nubes privadas, públicas y de borde, proporciona la única solución real para la disponibilidad de datos en múltiples nubes.

Fácil de usar

Entonces, ¿qué tan simple es para el usuario final? Imagina que tienes un depósito en MinIO llamado 'Cubo1'. Puede configurarlo para que pueda ejecutar cualquier comando de SnowSQL como si fuera una tabla más.

Por ejemplo: seleccione * de Bucket1;

Como la mayoría de las cosas en Snowflake, conectarse a sus datos almacenados en MinIO también es relativamente simple.

Esto es lo que necesita para empezar:

Configuración de copo de nieve

La compatibilidad con tablas externas debe estar activada para su entorno de Snowflake. Si obtiene errores como 'prefijo de URL no válido encontrado en: ' s3compat://snowflake/ ', probablemente significa que no está habilitado. Comuníquese con su representante de Snowflake para habilitarlo.

Configuración de MinIO

Solo hay un par de requisitos en la configuración de MinIO para que funcione con Snowflake.

1. MinIO debe configurarse para permitir el acceso de estilo DNS y el depósito debe estar disponible públicamente.
2. Actualmente, la región debe establecerse en NULL o igual que la región de la instancia de Snowflake (por ejemplo, 'us-west-2'). Recibirá un mensaje de error de la consulta de Snowflake para que sepa qué región está esperando.

En el siguiente ejemplo, el depósito "copo de nieve" tiene 4 objetos y otro objeto en la carpeta/subprefijo "sn1". Copo de nieve buscará todos estos objetos.

Para integrar esto con Snowflake, si el servidor MinIO está en https://play.min.io , el depósito debe estar accesible en https://snowflake.play.min.io

Los archivos de muestra están disponibles en https://docs.snowflake.com/en/user-guide/getting-started-tutorial-prerequisites.html#sample-data-files-for-loading

Hay dos formas de integrar los cubos MinIO con Snowflake. El primero es como "Área de ensayo" y el segundo es como una mesa externa. Veamos ambos

Acceso al área de preparación

Como parte de un proceso ETL, los datos normalmente se seleccionan y preparan a partir de una fuente de datos o un lago de datos, se mueven a un área de preparación y luego se cargan en un almacén para que se puedan ejecutar consultas en él.

Tradicionalmente, estas áreas de preparación para Snowflake estaban en Snowflake mismo, por lo que este era el flujo:

Lago de datos (on-prem, nube pública, etc.) -> Puesta en escena de Snowflake -> Tabla interna de Snowflake

Las empresas ahora pueden configurar MinIO como un área de preparación y mover los datos directamente a una tabla interna de Snowflake para ejecutar consultas en ella.

Esto hace lo siguiente

• Simplifica el flujo
• Permite que los datos estén disponibles más rápido para el análisis para satisfacer las necesidades comerciales
• Garantiza que no haya copias innecesarias de los datos, lo que ayuda tanto en la gestión como en el costo.

El nuevo flujo sería: Datos en MinIO (on-prem, nube pública, etc.) -> Tabla interna de Snowflake

Los siguientes ejemplos se muestran en la consola de Snowflake, pero los mismos se pueden ejecutar a través de la CLI de Snowflake.

Para play.min.io , use
AWS_KEY_ID='Q3AM3UQ867SPQQA43P2F'
AWS_SECRET_KEY='zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG'

La referencia para el comando CREATE STAGE de Snowflake está disponible aquí: https://docs.snowflake.com/en/sql-reference/sql/create-stage.html

Acceso a tablas externas

Las consultas en Snowflake debían realizarse en tablas internas. Esto significaba que todos los datos, incluso para consultas ad hoc, debían trasladarse a Snowflake. Esto resultó tanto en costos como en la imposibilidad de consultar de manera oportuna.

Las empresas ahora pueden acceder directamente a los datos en depósitos MinIO utilizando las nuevas capacidades de acceso a tablas externas introducidas por Snowflake.

El tiempo que tarda la consulta inicial dependerá de la cantidad de datos que se transfieran, pero las lecturas se almacenan en caché y las consultas posteriores pueden ser más rápidas hasta la próxima actualización.

Con el enfoque de tabla externa, no es necesario copiar los datos y el cubo se puede usar como una tabla externa para consultas, uniones, etc.

Sin embargo, a cambio, los beneficios son enormes.

• Esto amplía las capacidades del almacén sin incurrir en el costo de la mudanza.
• La capacidad de ejecutar análisis en datos en tiempo real ya está disponible.
• Se puede evitar por completo mover datos solo para ejecutar una consulta ad hoc.
• El análisis es posible en instancias en las que los datos no se pueden mover por cumplimiento u otras razones comerciales.
• Todavía obtiene todas las ventajas de las capacidades de Snowflake con los mismos recursos que ya están familiarizados con la plataforma Snowflake

A continuación se muestra un ejemplo:

La referencia para el comando Snowflake CREATE EXTERNAL TABLE está disponible aquí: https://docs.snowflake.com/en/sql-reference/sql/create-external-table.html

Uso de la CLI de Snowflake (SnowSQL)

Los mismos comandos se pueden ejecutar mediante la CLI de Snowflake (SnowSQL).

Puede encontrar las instrucciones sobre cómo instalar SnowSQL en su plataforma aquí: https://docs.snowflake.com/en/user-guide/snowsql-install-config.html

La única diferencia es que tienes que empezar con el comando

$ snowsql -a <identificador_de_cuenta> -u <nombre_de_usuario>

El identificador de cuenta tiene el formato <nombre-organización>-<nombre-cuenta>. Puede encontrar esto en la página de administración en la consola de Snowflake.

Resumen

Y eso es todo.

Si es un cliente de MinIO que busca agregar capacidades de Snowflake o si es un cliente de Snowflake que busca ampliar sus capacidades a los datos almacenados fuera de Snowflake, pruébelo. De cualquier manera, puede extraer más de su inversión actual.