Cómo leer tablas de Unity Catalog en Snowflake, en 3 sencillos pasos

Actualización: Este blog se ha actualizado para reflejar la compatibilidad de Snowflake con las credenciales proporcionadas por el catálogo.

Databricks fue pionero en la arquitectura abierta de data lakehouse y ha estado a la vanguardia de la interoperabilidad de formatos. Nos complace ver que más plataformas adoptan la arquitectura lakehouse y comienzan a utilizar formatos y estándares interoperables. La interoperabilidad permite a los clientes reducir la duplicación costosa de datos utilizando una sola copia de datos con su elección de herramientas de análisis e IA para sus cargas de trabajo. En particular, un patrón común para nuestros clientes es utilizar el rendimiento/precio de ETL de primera clase de Databricks para datos upstream, accediendo a ellos desde herramientas de BI y análisis, como Snowflake.

Unity Catalog es una solución de gobernanza unificada y abierta para activos de datos e IA. Una característica clave de Unity Catalog es su implementación de las API de Iceberg REST Catalog. Esto facilita el uso de un lector compatible con Iceberg sin tener que actualizar manualmente la ubicación de sus metadatos. 

En esta publicación de blog, cubriremos por qué el catálogo REST de Iceberg es útil y recorreremos un ejemplo de cómo leer tablas de Unity Catalog en Snowflake.

Nota: Esta funcionalidad está disponible en todos los proveedores de nube. Las siguientes instrucciones son específicas para AWS S3, pero es posible utilizar otras plataformas de almacenamiento de objetos como Azure Data Lake Storage (ADLS) o Google Cloud Storage (GCS).

Integración de catálogo de Iceberg REST API

Apache Iceberg™ mantiene la atomicidad y la consistencia creando nuevos archivos de metadatos para cada cambio de tabla. Esto garantiza que las escrituras incompletas no corrompan un archivo de metadatos existente. El catálogo de Iceberg rastrea los nuevos metadatos por escritura. Sin embargo, no todos los motores pueden conectarse a todos los catálogos de Iceberg, lo que obliga a los clientes a realizar un seguimiento manual de la ubicación del nuevo archivo de metadatos.

Iceberg resuelve la interoperabilidad entre motores y catálogos con la API de catálogo REST de Iceberg. El catálogo REST de Iceberg es una especificación de API abierta y estandarizada que es una interfaz unificada para los catálogos de Iceberg, desacoplando las implementaciones de catálogo de los clientes.

Unity Catalog ha implementado las API de catálogo REST de Iceberg desde el lanzamiento de Universal Format (UniForm) en 2023. Unity Catalog expone los metadatos de tabla más recientes, lo que garantiza la interoperabilidad con cualquier cliente de Iceberg compatible con el catálogo REST de Iceberg, como Apache Spark™, Apache Trino y Snowflake. Los puntos de conexión del catálogo REST de Iceberg de Unity Catalog permiten a los sistemas externos acceder a las tablas y beneficiarse de mejoras de rendimiento como Liquid Clustering y Predictive Optimization, mientras que las cargas de trabajo de Databricks continúan beneficiándose de las características avanzadas de Unity Catalog como Change Data Feed. Además, los puntos de conexión del catálogo REST de Iceberg de Unity Catalog extienden la gobernanza a través de credenciales proporcionadas.

La integración de catálogo REST API de Snowflake le permite conectarse a las API de catálogo REST de Iceberg de Unity Catalog para recuperar la ubicación del archivo de metadatos más reciente. Esto significa que con Unity Catalog, puede leer tablas directamente en Snowflake. 

Nota: Al momento de escribir esto, la compatibilidad de Snowflake con el catálogo REST de Iceberg está en vista previa pública. Sin embargo, las API de catálogo REST de Iceberg de Unity Catalog están disponibles de forma general.

Hay 3 pasos para crear una integración de catálogo REST en Snowflake:

1. Habilitar UniForm en una tabla de Delta Lake en Databricks para generar metadatos de Iceberg
2. Registrar Unity Catalog en Snowflake como su catálogo
3. Crear una tabla de Iceberg en Snowflake para poder consultar sus datos

Primeros pasos

Comenzaremos en Databricks, con nuestra tabla administrada por Unity Catalog, y nos aseguraremos de que se pueda leer como Iceberg. Luego, pasaremos a Snowflake para completar los pasos restantes.

Antes de comenzar, hay algunos componentes necesarios:

• Una cuenta de Databricks con Unity Catalog (esto está habilitado por defecto para nuevas áreas de trabajo)
• Un bucket de AWS S3 y privilegios de IAM
• Una cuenta de Snowflake que pueda acceder a su instancia de Databricks y S3

Los espacios de nombres de Unity Catalog siguen un formato de nombre_catalogo.nombre_esquema.nombre_tabla. En el siguiente ejemplo, usaremos uc_catalog_name.uc_schema_name.uc_table_name para nuestra tabla de Databricks. 

Paso 1: Habilitar UniForm en una tabla Delta en Databricks

En Databricks, puede habilitar UniForm en una tabla de Delta Lake. Por defecto, las tablas nuevas son administradas por Unity Catalog. Las instrucciones completas están disponibles en la documentación de UniForm, pero también se incluyen a continuación.

Para una tabla nueva, puede habilitar UniForm durante la creación de la tabla en su área de trabajo:

Si tiene una tabla existente, puede hacerlo a través de un comando ALTER TABLE:

Puede confirmar que una tabla Delta tiene UniForm habilitado en el Explorador de Catálogos, en la pestaña Detalles, con la ubicación de los metadatos. Debería verse algo como esto:

Paso 2: Registrar Unity Catalog en Snowflake

Mientras aún está en Databricks, cree un principal de servicio desde la configuración del administrador del área de trabajo y genere el secreto y el ID de cliente correspondientes. En lugar de un principal de servicio, también puede autenticarse con tokens personales para fines de depuración y prueba. Recomendamos usar un principal de servicio para cargas de trabajo de desarrollo y producción. Para este paso, necesitará su <deployment-name> y los valores para su <client-id> y <secret> de OAuth para poder autenticar la integración en Snowflake.

Ahora cambie a su cuenta de Snowflake.

Nota: Hay algunas diferencias de nomenclatura entre Databricks y Snowflake que pueden ser confusas:

• Un “catálogo” en Databricks es un “almacén” en la configuración de integración del catálogo Iceberg de Snowflake.
• Un “esquema” en Databricks es un “nombre_espacio_catalogo” en la integración del catálogo Iceberg de Snowflake.

Verá en el siguiente ejemplo que el valor CATALOG_NAMESPACE es uc_schema_name de nuestra tabla de Unity Catalog.

En Snowflake, cree una integración de catálogo para catálogos REST de Iceberg. Siguiendo ese proceso, creará una integración de catálogo como la siguiente:

La integración de catálogo REST también habilita credenciales delegadas y la actualización automática basada en tiempo.

Las credenciales delegadas incluyen tanto la ubicación de almacenamiento de una tabla como una credencial de acceso temporal para acceder a esa ubicación. Esto permite a los clientes acceder a las tablas a través del catálogo sin configurar el acceso directo del cliente a la ubicación de almacenamiento de la tabla. Recomendamos usar credenciales delegadas para simplificar y centralizar la gobernanza en el catálogo. En el ejemplo anterior, configuramos Snowflake para usar las credenciales delegadas de Unity Catalog con el parámetro ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS en el objeto REST_CONFIG.

Actualmente, Snowflake solo admite credenciales delegadas para tablas en AWS S3. Para tablas en Azure Data Lake Storage (ADLS) o Google Cloud Storage (GCS), Snowflake requiere acceso directo a la ubicación de almacenamiento de la tabla con un volumen externo.

Con la actualización automática, Snowflake consultará la ubicación de metadatos más reciente de Unity Catalog en un intervalo de tiempo definido para la integración del catálogo. Sin embargo, la actualización automática es incompatible con la actualización manual, lo que requiere que los usuarios esperen hasta el intervalo de tiempo después de una actualización de tabla. El parámetro REFRESH_INTERVAL_SECONDS configurado en la integración del catálogo se aplica a todas las tablas Iceberg de Snowflake creadas con esta integración. No es personalizable por tabla.

Paso 3: Crear una tabla Apache Iceberg™ en Snowflake

En Snowflake, crea una tabla Iceberg con la integración de catálogo creada previamente para conectarte a la tabla Delta Lake. Puedes elegir el nombre de tu tabla Iceberg en Snowflake; no necesita coincidir con la tabla Delta Lake en Databricks.

Nota: La asignación correcta para CATALOG_TABLE_NAME en Snowflake es el nombre de la tabla de Databricks. En nuestro ejemplo, es uc_table_name. No necesitas especificar el catálogo o el esquema en este paso, ya que ya se especificaron en la integración del catálogo.

Opcionalmente, puedes habilitar la actualización automática usando el intervalo de tiempo de la integración del catálogo agregando AUTO_REFRESH = TRUE al comando. Ten en cuenta que si la actualización automática está habilitada, la actualización manual está deshabilitada.

Ahora has leído correctamente la tabla Delta Lake en Snowflake.

Finalización: Prueba la conexión

En Databricks, actualiza los datos de la tabla Delta insertando una nueva fila.

Si previamente habilitaste la actualización automática, la tabla se actualizará automáticamente en el intervalo de tiempo especificado. Si no lo hiciste, puedes actualizar manualmente ejecutando ALTER ICEBERG TABLE <snowflake_table_name> REFRESH.

Nota: si previamente habilitaste la actualización automática, no puedes ejecutar el comando de actualización manual y deberás esperar a que se complete el intervalo de actualización automática para actualizar la tabla.

Estamos entusiasmados por el continuo soporte de la arquitectura lakehouse. Los clientes ya no tienen que duplicar datos, lo que reduce costos y complejidad. Esta arquitectura también permite a los clientes elegir la herramienta adecuada para la carga de trabajo correcta.

La clave para un lakehouse abierto es almacenar tus datos en un formato abierto como Delta Lake o Iceberg. Los formatos propietarios bloquean a los clientes en un motor, pero los formatos abiertos te brindan flexibilidad y portabilidad. Sin importar la plataforma, animamos a los clientes a poseer siempre sus propios datos como primer paso hacia la interoperabilidad. En los próximos meses, continuaremos construyendo funcionalidades que faciliten la gestión de un data lakehouse abierto con Unity Catalog.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original