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

Matriz compartir, federar o copiar

Contenido abierto

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

Lección 5 de 5

Matriz compartir, federar o copiar

Selecciona sharing, federation o ingestión comparando dirección, frecuencia, frescura, escritura, gobierno, coste y aislamiento operacional.

Duración
17 min aprox.
Objetivo
Selecciona sharing, federation o ingestión comparando dirección, frecuencia, frescura, escritura, gobierno, coste y aislamiento operacional.
Siguiente paso
Continuar con el laboratorio
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
05
Decisión de diseño

Matriz compartir, federar o copiar

Selecciona sharing, federation o ingestión comparando dirección, frecuencia, frescura, escritura, gobierno, coste y aislamiento operacional.

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

Sharing publica un producto gobernado hacia consumidores externos; federation consulta una fuente externa in situ; ingestión copia cambios al lakehouse para transformación y SLA propios. Si un partner necesita leer una tabla curada, sharing evita una exportación. Si un analista explora PostgreSQL unas veces, federation reduce time-to-value. Si cientos de jobs agregan esa base cada hora, ingiere incrementalmente.

Interoperabilidad no elimina contratos. Documenta tipos, time zones, semántica de deletes, límites y ownership. Considera Iceberg REST Catalog u otros protocolos cuando clientes externos deban leer tablas gobernadas directamente, siempre contrastando soporte de features Delta/ABAC. Diseña una salida: cómo revocar, materializar o migrar sin romper consumidores.

Modelo mental

Sharing, federation e ingestión resuelven direcciones distintas. Sharing publica desde un proveedor hacia consumidores read-only y conserva el producto en origen. Federation permite a Databricks consultar un sistema externo in situ, normalmente para exploración o modelo híbrido. Ingestión mueve cambios a Delta para que Databricks controle rendimiento, historial, calidad y escritura downstream. La decisión se formula con dirección, frecuencia, frescura, volumen, write needs, gobierno, egress y aislamiento operacional. La menor latencia aparente puede esconder carga en OLTP; la copia más robusta puede incumplir residencia; sharing puede ser perfecto para colaboración pero no para actualizar el sistema del provider. Ninguna etiqueta sustituye una matriz de requisitos y una prueba de fallo.

Dirección de acceso

Relación entre quien posee el dato, quien inicia la consulta y dónde debe materializarse el estado resultante.

Distingue publicar a consumidores, consultar una fuente externa y copiar datos para procesamiento controlado.
Aislamiento operacional

Grado en que fallos, carga o cambios de un sistema pueden afectar disponibilidad y rendimiento del otro.

Una consulta federada puede impactar OLTP, mientras una copia ingerida desacopla ambos a cambio de frescura.
Frescura efectiva

Edad observable del dato utilizable después de transporte, procesamiento, validación y disponibilidad para el consumidor.

Evita comparar sólo frecuencia de trigger y revela retrasos de calidad, backlog o publicación downstream.
JSONMatriz de decisión de interoperabilidad
{
  "use_case": "partner_inventory_daily",
  "direction": "outbound",
  "write_required": false,
  "freshness": "daily",
  "consumer_platform": "non_databricks",
  "classification": "internal",
  "selected_pattern": "open_sharing_oidc",
  "rejected": {
    "federation": "el partner no debe acceder al sistema operacional",
    "file_export": "duplica datos y credenciales"
  }
}

Una decisión útil conserva también el motivo de alternativas rechazadas y la fecha de revisión.

Puntos clave

  • Sharing sirve publicación; federation, consulta in situ; ingestión, procesamiento controlado.
  • La frecuencia y carga sobre el origen suelen decidir entre federation e ingesta.
  • Cada patrón necesita contrato, owner, coste y estrategia de salida.

Evita

  • Usar federation para una transformación horaria pesada y trasladar el cuello al OLTP.
  • Exportar ficheros con credenciales estáticas cuando OpenSharing cubre el contrato.

Recuerdo activo

¿Qué señal indica que una consulta federada debería materializarse por ingesta?

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