Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
Databricks-to-Databricks
Publica un producto de datos mínimo mediante shares, views y recipients con ownership, contrato y revocación ensayada.
- Duración
- 17 min aprox.
- Objetivo
- Publica un producto de datos mínimo mediante shares, views y recipients con ownership, contrato y revocación ensayada.
- 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.
- Comparar Databricks-to-Databricks y Databricks-to-Open
- Configurar federation con pushdown
- Elegir compartir, federar o ingerir
02ImplementaciónDatabricks-to-Databricks
Publica un producto de datos mínimo mediante shares, views y recipients con ownership, contrato y revocación ensayada.
+
Databricks-to-Databricks
Publica un producto de datos mínimo mediante shares, views y recipients con ownership, contrato y revocación ensayada.
El proveedor crea un share, añade tablas, vistas u otros activos compatibles y concede acceso a un recipient. Una vista compartida puede minimizar columnas y filtrar datos según contrato, pero sus capacidades y coste dependen del modelo de sharing. El owner del share debe ser un grupo operativo y los cambios deben pasar revisión igual que un API público.
Versiona esquema y comunica breaking changes. Monitoriza accesos, establece fecha de expiración del acuerdo y prueba revocación. No compartas la tabla bronze por conveniencia: crea una capa estable, documentada y sin campos internos. Si el receptor necesita escribir o transformar en origen, sharing no satisface ese requisito read-only.
Modelo mental
Un share debe ser un producto de datos mínimo y contractual, no un catálogo entero expuesto por comodidad. El provider conserva tablas internas, transformaciones y PII; publica sólo activos estables, documentados y apropiados para la audiencia, a menudo mediante views que fijan columnas y semántica. El recipient obtiene acceso al share, no ownership sobre los objetos origen, y puede delegar lectura internamente según su modelo. Añadir o retirar activos cambia el contrato y requiere versionado o comunicación. La revocación forma parte del diseño inicial: debe saberse quién puede retirar recipient o share, cuánto tarda en surtir efecto y qué copias legítimas pudo materializar ya el consumidor.
Securable de Unity Catalog que agrupa un conjunto explícito de activos read-only ofrecidos por un proveedor a recipients autorizados.
Define la frontera revocable y auditable del producto compartido sin transferir propiedad del almacenamiento subyacente.Entidad registrada que representa a una organización consumidora y su método de autenticación para acceder a shares concedidos.
Separa consumidores, credenciales y revocación, evitando una identidad compartida cuyo uso no puede atribuirse.Compromiso versionado sobre schema, significado, frescura, compatibilidad y proceso de cambio de los activos publicados.
Permite que consumidores dependan del producto sin quedar expuestos a cada detalle interno o columna futura.CREATE OR REPLACE VIEW prod.shared.partner_inventory AS
SELECT
sku,
DATE_TRUNC('day', snapshot_ts) AS snapshot_date,
region,
available_units
FROM prod.gold.inventory
WHERE partner_visible = TRUE;
ALTER SHARE retail_partner
ADD VIEW prod.shared.partner_inventory;Comprueba requisitos actuales para compartir vistas y quién paga el compute asociado; prueba el resultado como recipient.
Puntos clave
- Comparte un contrato estable, no una tabla interna mutable.
- Ownership y revocación forman parte del producto.
- Read-only no cubre casos que requieren escritura remota.
Evita
- Compartir campos internos y confiar en que el receptor no los use.
- Cambiar nombres/tipos sin versión ni aviso porque el share sigue siendo accesible.
Recuerdo activo