Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 31 · Lección

OpenSharing, shares y recipients

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 1 de 5

OpenSharing, shares y recipients

Distingue Databricks-to-Databricks OpenSharing de Open-to-Databricks y elige autenticación OIDC antes que credenciales portables de larga duración.

Duración
17 min aprox.
Objetivo
Distingue Databricks-to-Databricks OpenSharing de Open-to-Databricks y elige autenticación OIDC antes que credenciales portables de larga duración.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

OpenSharing (antes Delta Sharing) y Federation

Comparte o consulta datos externos con el mínimo movimiento y un perímetro gobernado.

Al terminar podrás
  • Comparar Databricks-to-Databricks y Databricks-to-Open
  • Configurar federation con pushdown
  • Elegir compartir, federar o ingerir
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
delivery
Dominios blueprint
Data Sharing and Federation
Estado
Revisión editorial interna
Fuentes principales
What is OpenSharing? · Share data and AI assets securely
Reportar un error
01
Modelo mental

OpenSharing, shares y recipients

Distingue Databricks-to-Databricks OpenSharing de Open-to-Databricks y elige autenticación OIDC antes que credenciales portables de larga duración.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m30
Reportar un error en esta lección

OpenSharing es la evolución del intercambio abierto conocido históricamente como Delta Sharing. Entre metastores Databricks, el recipient accede mediante integración nativa y no necesita un fichero de credenciales. Para receptores sin Unity Catalog, el protocolo abierto permite Spark, pandas, Power BI y otros conectores mediante bearer token u OIDC federation.

Los activos se consumen en modo read-only y el proveedor controla qué agrega al share. Prefiere OIDC con tokens cortos cuando el receptor puede federar su identidad; los bearer tokens requieren distribución segura, rotación y revocación. La nube del proveedor y receptor puede diferir, pero egress, ubicación y residencia siguen siendo decisiones de arquitectura.

Modelo mental

OpenSharing mueve acceso gobernado hacia el consumidor sin copiar previamente el dataset a una base intermediaria. El proveedor registra un share de activos de solo lectura y un recipient; el consumidor consulta datos actualizados mediante el protocolo y credenciales autorizadas. Databricks-to-Databricks aprovecha Unity Catalog en ambos extremos y puede compartir más tipos de activo entre cuentas y nubes. Databricks-to-Open atiende herramientas o plataformas externas y sus capacidades dependen del protocolo abierto. La autenticación es una decisión separada: OIDC federation intercambia identidad del recipient por tokens cortos; bearer tokens son credenciales portables y duraderas con mayor carga de rotación y exposición. Compartir lectura no transfiere ownership ni aplica mágicamente toda política del proveedor al consumidor.

Databricks-to-Databricks

Modelo de OpenSharing entre metastores de Unity Catalog donde proveedor y recipient usan Databricks, incluso en cuentas o nubes distintas.

Aprovecha identidad y gobierno nativos en ambos lados y admite tipos de activo más ricos según compatibilidad.
Databricks-to-Open

Modelo de OpenSharing para consumidores externos que acceden mediante clientes compatibles con el protocolo abierto de intercambio.

Amplía interoperabilidad, pero exige revisar formatos, autenticación y capacidades disponibles fuera de Unity Catalog del proveedor.
OIDC federation

Intercambio de una identidad afirmada por el IdP del consumidor por credenciales OAuth cortas aceptadas por Databricks.

Evita distribuir bearer tokens duraderos y mejora revocación, atribución y alineación con el ciclo de identidad.
SQLCrear un share y añadir una tabla
CREATE SHARE IF NOT EXISTS retail_partner;

ALTER SHARE retail_partner
ADD TABLE prod.shared.daily_inventory;

SHOW ALL IN SHARE retail_partner;

Antes de asignar un recipient, revisa columnas, historial compartido, región y contrato de datos.

Puntos clave

  • Databricks-to-Databricks evita intercambiar ficheros de credenciales.
  • OIDC reduce riesgo frente a bearer tokens largos.
  • Compartir es read-only y no copia necesariamente los datos al receptor.

Evita

  • Enviar un bearer token por correo o guardarlo en un notebook compartido.
  • Asumir que read-only elimina coste de egress o riesgo de reidentificación.

Recuerdo activo

¿Qué ventaja de seguridad ofrece OIDC frente a un bearer token duradero?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Unity Catalog · Fabric mirror

Azure Databricks Integration Demos · commit 2fcc3db

06-unity-catalog-fabric-mirror/notebooks/01-prepare-unity-catalog-tables.py