Intercambio de datos en Databricks sobre AWS: OpenSharing, Marketplace y Lakehouse Federation

Las lecciones 01 to 11 construyeron y gobernaron un lakehouse que aloja tus datos. En el momento en que una segunda organización necesita leer esos datos, un socio, un cliente, una filial, un regulador, un suscriptor de pago, aparecen tres superficies distintas de la plataforma dispuestas a ayudar, y rutinariamente se confunden entre sí. OpenSharing (el producto; el protocolo abierto se llamó Delta Sharing hasta junio de 2026) entrega una vista viva de tablas seleccionadas a alguien que no eres tú. Databricks Marketplace es un escaparate situado encima de esa entrega que añade descubrimiento, aprobación y adquisición. Lakehouse Federation hace lo contrario con el mismo vocabulario: permite que tu SQL llegue a la base de datos o el catálogo vivo de otra persona sin copiar un solo byte. Cada uno se gobierna mediante securables de Unity Catalog, cada uno tiene su propia historia de red en AWS y cada uno falla de una manera característica.

La regla de enseñanza de esta lección, y la frase que hay que conservar cuando la sintaxis se difumina: un share es un puntero vivo, un foreign catalog es una dependencia viva, un listado del Marketplace es un escaparate sobre el puntero, y solo una copia ETL es algo que posees. Ordena bien eso y cada función de abajo caerá en su lugar.

En esta lección vas a:

• distinguir las tres superficies, OpenSharing, Marketplace, Lakehouse Federation, y enrutar seis peticiones de colaboración realistas a la correcta (y saber cuándo la respuesta correcta es una copia deliberada);
• aplicar correctamente el cambio de nombre de junio de 2026: el producto y las docs dicen OpenSharing, la superficie SQL sigue diciendo CREATE SHARE / GRANT ... ON SHARE, el cliente OSS sigue siendo delta_sharing, y los eventos de auditoría siguen empezando por deltaSharing*;
• construir un share tal como lo especifican las docs de octubre de 2026: CREATE SHARE en el metastore, ALTER SHARE ... ADD TABLE ... WITH HISTORY, parametrizado por partición con CURRENT_RECIPIENT(), CREATE RECIPIENT, GRANT SELECT ON SHARE, verificado con SHOW GRANTS TO RECIPIENT;
• elegir una historia de autenticación sobre evidencia, Databricks-to-Databricks (ningún artefacto), federación OIDC (ningún secreto emitido por Databricks) o token bearer (archivo de credenciales de un solo uso, IP ACL, rotación programada), y explicar el corte de tokens de 2026-12-08 a quien todavía dependa de uno;
• leer la capa de red: acceso por URL prefirmada frente a cloud tokens basados en directorio, qué activos son elegibles para cada uno y por qué las credenciales de directorio entregan al destinatario el Delta log incluyendo los datos eliminados aún sin vacuum;
• gobernar shares como cualquier otro securable de Unity Catalog: quién puede crearlos, qué responde SHOW GRANTS TO RECIPIENT, cómo funciona la revocación inmediata y cómo ejecutar una revisión trimestral de acceso contra system.access.audit;
• publicar en Databricks Marketplace: listados instantáneos frente a por solicitud, Marketplace público frente a intercambio privado, la economía de sin cuota / sin recorte para el proveedor y la aritmética del 10% de Universal Commit Drawdown;
• montar Lakehouse Federation con CREATE CONNECTION y CREATE FOREIGN CATALOG, usando secret() (o una service credential de UC más un rol de AWS IAM en RDS PostgreSQL), y decir exactamente dónde empuja el join pushdown;
• mantener separados los dos problemas de red: intercambio saliente (SecureConnect, NCC private endpoints sobre el metastore, IP ACLs de destinatarios) frente a federación entrante (PrivateLink, solo en la misma nube);
• situar clean rooms, un veredicto comparativo de Delta Sharing frente a Lake Formation entre cuentas sobre S3 frente a copias ETL, tres casos de estudio nombrados en AWS, un recuadro de actualización de octubre de 2026 con fuentes, ocho ejemplos resueltos, cinco diagramas, cuatro comprobaciones interactivas y doce preguntas de práctica.

---

1. Tres superficies, una pregunta: ¿cómo salen, o llegan, los datos sin moverse?

1.1 El mapa de superficies

«OpenSharing es la plataforma de intercambio de datos segura de Databricks que te permite compartir datos y activos de IA con usuarios fuera de tu organización, independientemente de si usan Databricks. OpenSharing es también la base de Databricks Marketplace, un foro abierto para intercambiar productos de datos, y de Clean Rooms» (docs, What is OpenSharing?, AWS, consultado 2026-10). Esa frase es la arquitectura en miniatura: Marketplace y Clean Rooms están construidos sobre la capa de intercambio, y por eso una lección que cubre las tres empieza con el objeto share y no con el escaparate.

Dos límites que conviene fijar antes de que aparezca cualquier sintaxis:

• Los workspaces en el mismo metastore de Unity Catalog no usan OpenSharing en absoluto: Unity Catalog ya gobierna el acceso entre ellos. «El intercambio Databricks-to-Databricks entre metastores de Unity Catalog en la misma cuenta está siempre habilitado»; el intercambio fuera de la cuenta requiere que un administrador de cuenta o de metastore marque «Allow OpenSharing with parties outside your organization» y fije la duración predeterminada del token del destinatario (misma página de docs).
• La federación no es intercambio. La federación es tu cómputo consultando su base de datos por JDBC (o escaneando su object storage tras un rastreo de metadatos); no se concede nada a una parte externa, y no se comparte nada hacia fuera.

1.2 Ejemplo resuelto E1: enrutar seis peticiones de colaboración

Lectura: cuatro de las seis peticiones son intercambio, una es federación y una es una copia. El error más caro de esa lista es responder (4) con un share o (5) con un share: ambos «funcionan» en una demo y ambos incumplen el requisito real (una dependencia viva donde se quería un snapshot; un puntero revocable donde se quería un artefacto inmutable).

• 📚 ¿Sabías que…? Databricks informa de la adopción del protocolo cinco años después de su lanzamiento en 2021 como «más de 28.000 destinatarios de datos y el 33% de los shares que fluyen entre plataformas mediante conectores abiertos» (blog de Databricks, Introducing OpenSharing: the Next Evolution of Delta Sharing for the Agentic Era, 2026-06-16). El tercio entre plataformas es la cifra que importa para este curso: un tercio de los shares los consume algo que no es Databricks, y por eso mismo el protocolo abierto, no una API de plataforma, es lo que ahora aloja la Linux Foundation.

---

2. OpenSharing: el protocolo, el producto y el cambio de nombre de junio de 2026

2.1 Dos capas, un nombre cada una

Delta Sharing se lanzó en 2021 como subproyecto de Delta Lake. El 2026-06-10 Databricks anunció OpenSharing, «Alojado por la Linux Foundation … la siguiente evolución de Delta Sharing» (comunicado de prensa de Databricks, 2026-06-10), y el blog técnico del 2026-06-16 dibujó el pastel por capas explícitamente: «OpenSharing existe en dos capas. El protocolo de código abierto, ahora alojado por la Linux Foundation, es la especificación publicada… Databricks OpenSharing es la implementación empresarial del protocolo abierto, construida sobre otras funciones de Databricks como Unity Catalog para la gobernanza y el registro de auditoría, Marketplace para la descubribilidad, y más.»

El alcance creció con el cambio de nombre: de datos tabulares a Agent Skills, modelos de IA y datos no estructurados, más clientes de Iceberg REST catalog (IRC) y socios de almacenamiento on-premises, de modo que «los clientes ahora pueden conectar sus activos on-premises directamente a plataformas en la nube sin movimiento de datos» (comunicado de prensa, 2026-06-10).

2.2 Medio obsoleto, medio vivo: la tabla de vocabulario que de verdad necesitarás

Para este curso: di OpenSharing para el producto, Delta Sharing solo cuando te refieras al linaje del protocolo, a las librerías cliente o a los nombres de eventos de auditoría, y nunca confíes en la ruta de UI de un tutorial antiguo.

2.3 Los tres modelos de intercambio

2.4 Unity Catalog: obligatorio y no obligatorio: la nuance verificada

Las docs responden esto como una FAQ, literalmente: «No, no necesitas Unity Catalog para compartir (como proveedor) ni para consumir datos compartidos (como destinatario). Sin embargo, Unity Catalog ofrece ventajas como soporte para la compartición de activos no tabulares y de IA, gobernanza lista para usar, simplicidad y rendimiento de consultas» (docs, What is OpenSharing?, consultado 2026-10). Descompuesto, porque ambos extremos son error de examen:

1. El intercambio alojado por Databricks requiere UC en la práctica: un share es un securable de UC, los recipients son securables de UC, y la configuración significa «Enable OpenSharing on a Unity Catalog metastore».
2. El servidor OSS OpenSharing puede ejecutarlo cualquiera, en cualquier plataforma, sin Databricks: esa es la ruta de implementación gestionada por el cliente, y es lo que hace verdadero «no necesitas UC» en general.
3. Los recipients nunca necesitan UC en Databricks-to-Open.
4. Databricks-to-Databricks necesita un metastore de UC en ambos lados.
5. Los workspaces en el mismo metastore de UC no usan OpenSharing en absoluto.

---

3. Un share es un securable de Unity Catalog

3.1 El objeto y sus privilegios

«Un share es un objeto securable en Unity Catalog que representa una colección de datos y activos de IA que quieres compartir con uno o más recipients» (docs, Create shares for OpenSharing, pie de página 2026-10-09). De ahí siguen tres reglas, y cada una ha roto una integración en producción:

• Crear un share necesita CREATE SHARE en el metastore. Las docs recomiendan poseer los shares como grupo, no como persona: la gente se va, los grupos no.
• Añadir activos requiere la propiedad del share más USE CATALOG + USE SCHEMA + SELECT sobre cada activo. La advertencia de las docs es explícita: «Debes conservar ese privilegio para que el activo siga compartido. Si lo pierdes, el destinatario no podrá acceder al activo a través del share.» Transferencias de propiedad, reestructuraciones de grupos y limpiezas de grants rompen shares en vivo de esta manera.
• Delegar usa USE SHARE + SET SHARE PERMISSION sobre el share; el lado del destinatario necesita USE RECIPIENT (o la propiedad del recipient), y los flujos de aprobación de Marketplace necesitan además CREATE RECIPIENT / USE RECIPIENT. Un share puede contener activos de un solo metastore de Unity Catalog.

3.2 Qué puede entrar en un share (lista verificada a oct 2026)

Tablas y particiones de tabla (sí, PARTITION(...) y particiones basadas en propiedades con CURRENT_RECIPIENT()), schemas completos (ADD SCHEMA, que también concede activos futuros), views incluidas las dynamic views (el mecanismo de restricción fila/columna para recipients abiertos), materialized views, metric views, streaming tables, tablas Iceberg gestionadas, tablas Iceberg foráneas, tablas Delta foráneas, schemas y tablas foráneos, volumes, UDFs de Python, notebooks, modelos de IA, Genie Agents y FeatureSpecs, la lista de activos compartibles en la página de creación de share (docs, 2026-10-09). Lo que no viaja gratis: los comentarios de tabla/columna y las restricciones de clave primaria solo fluyen en shares Databricks-to-Databricks compartidos a partir del 2024-07-25; los grants más antiguos deben revocarse y concederse de nuevo.

3.3 Los flags de historial deciden lo que pueden hacer los destinatarios

La trampa de las dos últimas filas: la configuración «más barata» (WITHOUT HISTORY, o un share con filtro de partición) desactiva en silencio el time travel, el streaming y el CDF del destinatario, y también descalifica la ruta rápida de cloud tokens. «WITHOUT HISTORY está bien» es una decisión que hay que volver a tomar cada vez que cambian los requisitos del destinatario.

3.4 Ejemplo resuelto E2: el proveedor construye un share (SQL real, a oct 2026)

Cifras a octubre de 2026: el WITH HISTORY por defecto requiere DBR 16.2+; ambos flags de historial necesitan 12.2 LTS+; ADD SCHEMA necesita 13.3 LTS+ o un SQL warehouse; el share contiene activos de un metastore; revocarlo después es un solo REVOKE porque el destinatario nunca tuvo los datos.

---

4. Recipients: cinco tipos de autenticación, tres historias

4.1 El enum authentication_type

CREATE RECIPIENT produce un objeto cuyo authentication_type es uno de DATABRICKS, TOKEN, EMAIL (Beta; envuelve un hijo DATABRICKS o TOKEN y requiere que un administrador de cuenta habilite OpenSharing por correo desde la página Previews de la consola de cuenta), OAUTH_CLIENT_CREDENTIALS u OIDC_FEDERATION (docs, Manage data recipients, 2026-06-23). Los recipients también llevan listas de acceso por IP, estado de activación, duración del token y, para OIDC, el endpoint del IdP más el endpoint mTLS. SHOW GRANTS TO RECIPIENT lista los shares que un destinatario puede leer.

4.2 Ejemplo resuelto E3: Databricks-to-Databricks, el flujo sin artefactos

El acceso persiste «mientras el token subyacente sea válido y el proveedor siga compartiendo los datos» (docs, 2026-07-13): en este modelo no hay token, así que persiste exactamente mientras conserves el grant. Los recipients «pueden leer y hacer copias de los datos compartidos, pero… no pueden modificar los datos de origen».

4.3 Ejemplo resuelto E4, Databricks-to-Open: token bearer y después el lado del cliente

4.4 Federación OIDC: el flujo en el que Databricks no emite ningún secreto

«Este flujo de autenticación usa federación OIDC, que permite JSON Web Tokens (JWT) emitidos por el IdP del destinatario como tokens OAuth de corta vida autenticados por Databricks… Databricks no genera ni gestiona ningún token ni credencial. En su lugar, el IdP del destinatario genera un JWT con reclamaciones de identidad» (docs, Enable OIDC federation for OpenSharing recipients, consultado 2026-10). El proveedor escribe una política de federación contra el IdP del destinatario, nombre de política, URL del issuer, reclamación del subject (oid / groups / azp en Entra ID), subject, audiences, y Databricks devuelve una URL de portal. El destinatario descarga un perfil oauth_config.share y se lo da al cliente abierto:

Dos flujos documentados: U2M (Power BI / Tableau mediante el OAuth Authorization Code Grant contra la app multitenant de Entra de Databricks 64978f70-f6a6-4204-a29e-87d74bfea138, consentimiento único del administrador del tenant) y M2M (OAuth Client Credentials con un service principal registrado en el IdP del destinatario: la ruta Python/Spark). «No se intercambian secretos ni credenciales entre Databricks, el proveedor y el destinatario. Toda la gestión de secretos permanece interna en cada organización.» Los grants siguen usando el mismo SQL GRANT... ON SHARE.

La escalera de postura, en orden: destinatario de Databricks → Databricks-to-Databricks (ningún artefacto); socio que no es Databricks → federación OIDC (ningún secreto emitido por Databricks); solo cuando el destinatario no tiene un IdP utilizable → token + IP ACL + rotación programada, y revisa el corte de 2026-12-08 antes de construir sobre cualquier token emitido antes de 2025-12-08.

• 📚 ¿Sabías que…? Tres hechos sobre las credenciales bearer que sorprenden: el archivo de credenciales «solo puede descargarse una vez», si lo pierdes, reemites el objeto recipient, no el archivo; el proveedor debe «configure el valor por defecto de duración del token del destinatario cuando habilite OpenSharing para tu metastore de Unity Catalog», así que existe un valor predeterminado a nivel de organización antes que cualquier recipient individual; y también hay federación OIDC para recipients de Iceberg REST, entregada mediante un enlace de portal de generación de perfiles, la misma postura de sin secreto emitido por Databricks, apuntada al cliente Iceberg REST en lugar del cliente tabular (docs, consultado 2026-10).

---

5. Cómo se mueven realmente los bytes: URL prefirmadas frente a cloud tokens

5.1 Dos modos de acceso sobre la red

Views, materialized views, streaming tables, volumes, notebooks, UDFs y modelos son explícitamente no elegibles para cloud tokens, así que se entregan por materialización: la página de configuración del proveedor documenta el TTL de la materialización de datos, «Por defecto, el TTL es de ocho horas. La caché en sí misma será evacuada por materialización después de tres horas adicionales», y cada materialización aterriza en la tabla system.sharing.materialization_history (retención de 365 días). Las materializaciones ocurren «cuando un destinatario consulta dynamic views, materialized views, streaming tables y foreign tables compartidos».

5.2 La exposición del Delta log: la sorpresa de privacidad del modo directorio

Las docs de creación de share afirman que las credenciales de cloud token están limitadas al directorio raíz de la tabla: archivos de datos y el Delta log, que «contiene el historial de commits de cada versión de la tabla, información sobre quien hizo el commit, y datos eliminados aún no vaciados con VACUUM». Dos consecuencias sobre las que debes diseñar:

1. Un destinatario con acceso de directorio puede ver más que «las filas actuales»: puede ver el pasado sin vacuum del proveedor, hasta la ventana de retención de VACUUM (archivos de datos: 7 días por defecto; el propio log: 30 días vía delta.logRetentionDuration, docs.delta.io, consultado 2026-10).
2. Si tu historia de privacidad asumía «solo ven lo que muestra la view», usa acceso por URL prefirmada, comparte una dynamic view en lugar de la tabla base, o limpia con VACUUM antes de que el share salga: no después.

5.3 Ejemplo resuelto E5: leer la capa de red desde la pista de auditoría

Lectura: la mezcla de modos de esta consulta es en sí una señal de seguridad. Un destinatario que pretendías estar en URL prefirmadas y que aparece de golpe en generateTemporaryTableCredential significa que cambió la elegibilidad de su share (se añadió el flag de historial, se quitó el filtro de partición): que puede ser exactamente lo que configuraste, o exactamente lo que no.

---

6. Gobernar shares: grants, auditoría, revocación, y la trampa del puntero vivo

6.1 El modelo de privilegios, comprimido

La revocación es instantánea y total por la frase que sostiene todo el modelo: el destinatario nunca tuvo los datos, solo el derecho a leerlos. Esa es la propiedad que las copias ETL no pueden ofrecer, y la razón por la que un share gana a una bucket policy siempre que «puede que necesitemos retirar esto» sea un requisito real.

6.2 Ejemplo resuelto E6: la revisión trimestral de acceso

6.3 ⚠️ ADVERTENCIA: un share es un PUNTERO VIVO, y el VACUUM está apuntado a tus destinatarios

Reglas de diseño que se derivan: (1) nunca apuntes un share WITH HISTORY a una tabla que alguien vacuumee con un temporizador corto sin acordar la ventana de retención; (2) prefiere compartir views (incluidas dynamic views con lógica de fila CURRENT_RECIPIENT()) cuando el contrato del destinatario sea más estrecho que la tabla base; (3) trata la ruta de lectura del destinatario como una dependencia de producción de las operaciones de ciclo de vida de tu tabla: la misma disciplina que aplicarías a un job aguas abajo que no controlas, porque exactamente eso es.

---

7. Databricks Marketplace: el escaparate encima del share

7.1 Anatomía de un listado

Un listado apunta a un share. Dos opciones de acceso, fijadas al crear: «los activos de datos son accesibles instantáneamente» frente a «los consumidores deben solicitar acceso al listado». Dos destinos de publicación: Marketplace público o un intercambio privado. Tipos de activo: tablas · archivos (Volumes) · modelos · notebooks · servidores MCP: más apps desde junio de 2026 (Public Preview). El asistente te permite adjuntar hasta 10 notebooks de muestra por listado.

El cumplimiento es la capa de intercambio haciendo lo que ya sabe hacer: «Si el consumidor está en un workspace de Databricks con Unity Catalog habilitado, obtiene acceso a ese share como catálogo en su workspace de Databricks casi en tiempo real. Si el consumidor no está en un workspace de Databricks con Unity Catalog habilitado, se genera un archivo de credenciales y se pone a su disposición para descarga» (docs, 2026-06-23).

7.2 Convertirse en proveedor, y las políticas que te condicionan

«Para ser un proveedor solo de intercambio privado, puedes registrarte usando la consola del proveedor. Para crear listados públicos, solicita el acceso mediante el Databricks Data Partner Program» (docs, 2026-04-09). Tras la aprobación «debes conceder al menos a un usuario el rol de Marketplace admin», lo concede un administrador de cuenta de Databricks, y los listados que requieren aprobación necesitan además CREATE RECIPIENT / USE RECIPIENT. La página de políticas del proveedor (2023-10-10) es corta y absoluta: cada listado debe indicar la frecuencia de actualización y los términos de uso del proveedor y del consumidor, y «si tu Producto incluye Datos Personales, debes estar legalmente autorizado para compartir tales Datos Personales. Sin embargo, un Producto nunca debe incluir Datos Personales Sensibles.»

7.3 El dinero: sin recorte y un drawdown del 10% del commit

• Economía del listado: «No hay cuota para que los proveedores publiquen sus activos en Databricks Marketplace. Alojamos tanto listados gratuitos como de pago, pero no nos llevamos ninguna parte de los ingresos que reciben los proveedores. Las transacciones de los listados de pago ocurren directamente entre consumidores y proveedores» (blog de Databricks, Top 10 Marketplace Questions, Answered, 2024-11-11).
• Economía de la adquisición (nueva, junio de 2026): el programa Universal Commit Drawdown permite a los consumidores usar «hasta el 10% de sus Universal Commits para comprar productos de socios de terceros elegibles a través de Databricks Marketplace» (docs, consultado 2026-10). Condiciones: el contrato «debe firmarse después del 15 de junio de 2026»; la factura «no debe tener más de 45 días» y «debe estar denominada en USD»; el socio «valida la transacción en 10 días hábiles»; y «No hay comisiones de transacción» en esta ruta. La propia aritmética de las docs: «Universal Commit de $50M = hasta$5M de drawdown en Marketplace».
• Todavía roadmap, no GA: la transactabilidad dentro de la plataforma, el gasto prepago como checkout, «menos una pequeña comisión (estándar del sector)», se anunció para «más adelante en 2026» (blog, 2026-06-17). No se publica ningún porcentaje; no modeles una comisión que no puedas citar.

7.4 Ejemplo resuelto E7: runbook del listado y la aritmética del drawdown

Pasa el cursor sobre una barra: el techo es lineal y duro: el 10% del Universal Commit, el 10% completo disponible desde el primer día del commit, contrato firmado después del 2026-06-15, factura ≤ 45 días de antigüedad, el socio valida en 10 días hábiles, sin comisiones de transacción en la ruta de factura. La cifra resuelta de las docs es la tercera barra: un Universal Commit de $50M equivale a hasta $5M de drawdown en Marketplace.

• 📚 ¿Sabías que…? Marketplace tiene dos historias de adquisición que la gente confunde. La ruta de drawdown se basa en la factura y hoy no tiene comisiones; la ruta de transactabilidad (checkout dentro de la plataforma contra gasto prepago, «menos una pequeña comisión estándar del sector») se anunció el 2026-06-17 para «más adelante en 2026» y es un elemento de roadmap: modela la primera, no presupuestes la segunda. Mientras tanto, Apps on Databricks Marketplace están en Public Preview (2026-06-16): las apps del proveedor se distribuyen como contenedores de código cerrado, el egress controlado por el consumidor se gobierna con la política del Serverless Egress Gateway del workspace, y cada app se ejecuta en cómputo serverless dedicado.

---

8. Lakehouse Federation: consultar sin mover

8.1 Dos sabores, tres securables

Lakehouse Federation son consultas de solo lectura sobre un sistema externo vivo, expresadas mediante tres objetos de Unity Catalog: una connection («un objeto securable en Unity Catalog que especifica una ruta y credenciales para acceder a un sistema de base de datos externo»), un foreign catalog («un objeto securable en Unity Catalog que refleja una base de datos en un sistema de datos externo, permitiéndote realizar consultas de solo lectura»), y grants ordinarios sobre ese foreign catalog «a nivel de catálogo, schema o tabla, igual que harías con securables normales» (docs, consultados 2026-06-16 / 2026-06-29).

«Databricks mantiene la definición de los schemas del catálogo y sus relaciones en sincronía con la fuente externa»: un foreign catalog es un espejo vivo de metadatos de solo lectura, no un snapshot. Cada consulta golpea la fuente; no hay capa de caché salvo que construyas una (CREATE TABLE AS SELECT hacia una tabla Delta).

8.2 Las listas de fuentes verificadas de octubre de 2026: enséñalas como listas

Query federation (11):

• MySQL
• PostgreSQL
• Teradata
• Oracle
• Amazon Redshift
• Salesforce Data 360
• Snowflake
• Microsoft SQL Server
• Azure Synapse (SQL Data Warehouse)
• Google BigQuery
• Databricks

Catalog federation (7):

• Legacy Databricks Hive metastore
• External Hive metastore
• AWS Glue metastore
• Salesforce Data 360
• Snowflake
• Palantir Foundry
• Workday Data Connect

Tres observaciones de nivel examen, cada una sacada de las propias listas: Amazon Athena no aparece en ninguna de las dos: no enseñes federación de Athena; AWS Glue es una fuente de catalog federation, no de query federation; y Amazon Redshift está en la query federation mientras la propia página de Redshift arrastra su restricción de que «You cannot run federated queries on Amazon Redshift external data». CREATE CONNECTION admite exactamente 8 valores de TYPE: DATABRICKS, HTTP, MYSQL, POSTGRESQL, REDSHIFT, SNOWFLAKE, SQLDW, SQLSERVER.

8.3 Ejemplo resuelto E8: catálogo federado de PostgreSQL (DDL real, AWS)

Variante nativa de AWS (verificada): «Run federated queries on Amazon RDS for PostgreSQL (IAM authentication)» está «available on Databricks on AWS only, because it relies on an AWS IAM role referenced by a service credential»; requiere DBR 18 LTS o superior y modo de acceso Standard o Dedicated, un rol de IAM en la cuenta del RDS con una política de confianza autoasumible que lleve el external ID de la service credential, y la conexión añade aws_region '<region>' más credential '<service-credential-name>' en lugar de una contraseña (docs, 2026-08-19). Snowflake admite además OAuth (client_id, client_secret).

8.4 Semántica del pushdown: qué le pasa de verdad a tu SQL

Las consultas se ejecutan en cómputo de Databricks (SQL warehouse o cluster). Los predicados, las proyecciones, los joins y las agregaciones se empujan hacia la fuente foránea cuando el conector lo admite, y solo vuelven las filas necesarias. El join pushdown lo admiten «Oracle, PostgreSQL, MySQL, SQL Server, Teradata, Redshift, Snowflake, BigQuery», y «Esta función está disponible en GA y habilitada de forma predeterminada para Redshift, Snowflake y BigQuery» (docs, 2026-03-26). La catalog federation no empuja nada de ese tipo: el escaneo ocurre en Databricks contra S3. Consecuencias: la latencia de la federación = latencia de la consulta en la fuente + transferencia; una fuente lenta o caída significa consultas lentas o caídas en Databricks; y un catálogo federado es una dependencia viva, no un snapshot.

8.5 Red: dos problemas que se parecen y no lo son

«Private Link (solo cuando la base de datos externa está en la misma nube que el cómputo de Databricks)» (docs, Networking recommendations for Lakehouse Federation, consultado 2026-10).

Resolver uno no resuelve el otro. Un PrivateLink entre tu workspace y RDS no le hace nada a un destinatario que pega contra el firewall de tu bucket de S3; un proxy SecureConnect no le hace nada a tu conexión federada con Postgres.

• 📚 ¿Sabías que…? Las credenciales de la federación tienen exactamente tres hogares documentados, y solo uno de ellos es idiomático en AWS: la función secret('<scope>','<key>') dentro de CREATE CONNECTION («Te recomendamos que uses los secretos de Databricks en lugar de cadenas de texto en claro para los valores sensibles»); una service credential de Unity Catalog apuntando a un rol de AWS IAM para la autenticación IAM de RDS PostgreSQL (DBR 18 LTS+, Standard/Dedicated, solo AWS); y: para Snowflake: OAuth con client_id / client_secret. Nunca una contraseña literal en un notebook, en una entrada del historial de consultas, en system.access.audit.request_params ni en el estado de Terraform. También conviene saber: CREATE CONNECTION es la API de Lakehouse Federation; las ingestion connections son otra API (databricks connections create, la familia Lakeflow Connect): misma palabra, producto distinto.

---

9. Clean rooms en una página

Databricks Clean Rooms es «una función de Databricks que usa OpenSharing y cómputo serverless para proporcionar un entorno seguro y protector de la privacidad donde múltiples partes pueden trabajar juntas sobre datos empresariales sensibles sin acceso directo a los datos de los demás» (docs, 2026-10-08): un consumidor de la capa de intercambio, no un protocolo aparte. Cada parte posee un securable de clean room en su propio metastore de UC, más un entorno central efímero gestionado por Databricks donde corre el cómputo; los activos llegan mediante OpenSharing bajo alias; los colaboradores ven nombres y tipos de columna, pero no las filas de los demás.

El punto de enseñanza honesto: la garantía de privacidad descansa sobre la aprobación humana del notebook, no sobre una cota matemática. Aprobar código que no has leído es el modo de fallo, y es el único que la plataforma no puede atrapar por ti.

---

10. Las trampas que esta lección no te deja conservar

1. «Delta Sharing» como si nada hubiera cambiado. Junio de 2026: el producto y las docs dicen OpenSharing; el SQL, el cliente OSS y los eventos de auditoría conservan los nombres antiguos. Los tutoriales antiguos además tienen mal la ruta de UI.
2. Creer que un share es una copia. Es un puntero vivo (sección 6.3): los borrados se propagan, VACUUM rompe a los destinatarios, los cambios de schema llegan sin puerta, los tokens de directorio exponen el Delta log sin vacuum.
3. Asumir que WITHOUT HISTORY «está bien». Sin time travel, sin streaming, sin CDF, sin la ruta rápida de cloud tokens: la configuración de share más barata desactiva en silencio la mayoría de las funciones del destinatario.
4. Compartir un schema entero esperando que los filtros de fila/columna de UC aguanten. La restricción del lado del destinatario es dynamic views + CURRENT_RECIPIENT() o filtros de partición; las tablas con filtros de fila de UC, máscaras de columna o ABAC quedan excluidas de los shares por schema.
5. Perder SELECT sobre el origen. «Debes conservar ese privilegio»: las limpiezas de grants, las transferencias de propiedad y las reorganizaciones de equipo rompen shares en vivo de esta manera.
6. Tratar un archivo de credenciales bearer como un adjunto casual. Descarga única, secreto bearer, con IP ACL, rotable, y si se filtra, quien lo tiene lee todo lo que el share concede hasta que lo revokes. Prefiere D2D > OIDC > token.
7. Ignorar el corte de tokens de 2026-12-08. Los tokens emitidos antes de 2025-12-08 con caducidad larga o nula dejan de funcionar ese día.
8. Esperar que la federación sea una copia o una caché. Un foreign catalog es un espejo vivo de metadatos de solo lectura; la latencia es la de la fuente; construye una tabla Delta si necesitas un snapshot.
9. Poner las contraseñas de la federación en la SQL de la conexión como literales. Acaban en el historial de consultas, en los request_params de auditoría y en el estado de Terraform. Usa secret() o una service credential de UC + rol de IAM.
10. Asumir que Athena se puede federar porque es de AWS. Las listas de oct 2026 no contienen ninguna entrada de Athena; Glue es catalog federation; Redshift es query federation con su propia restricción de datos externos.
11. Confundir el red de la federación con el red del intercambio. PrivateLink entrante (misma nube) frente a SecureConnect/NCC/IP ACLs salientes: resolver uno no resuelve el otro.
12. Pensar que Marketplace se lleva un recorte de ingresos. No lo hace ni en los listados ni en las transacciones de listados de pago, y la ruta de drawdown no lleva comisiones de transacción; la «pequeña comisión» anunciada pertenece a una futura función de transactabilidad.
13. Confundir un listado privado con un intercambio privado. Un listado privado es invisible fuera de su intercambio; un intercambio privado es un escaparate con acceso por membresía cuyos miembros son clientes de Databricks con metastores de UC. Ninguno de los dos sustituye a OpenSharing hacia un socio que no es Databricks.
14. Confiar demasiado en las clean rooms. ≤10 colaboradores, nombres inmutables, membresía bloqueada, cualquier eliminación anula la room, y la garantía de privacidad es la aprobación humana de un notebook.

---

Veredicto comparativo: OpenSharing (Delta Sharing) frente a Lake Formation entre cuentas sobre S3 frente a copias ETL (AWS, a oct 2026)

• OpenSharing / Delta Sharing: el puntero abierto, sin copias y revocable. La única opción de aquí que es un protocolo abierto (Linux Foundation desde 2026-06-10) con clientes que funcionan fuera de la plataforma: el 33% de los shares ya fluye entre plataformas (blog, 2026-06-16). Cero copias, revocación inmediata (el destinatario nunca tuvo los datos, solo el derecho a leerlos), el conjunto de activos más rico en Databricks-to-Databricks (views, volumes, modelos, notebooks) y sin coste de egress en lecturas de la misma región. El precio de ese poder es el contrato de puntero vivo de la sección 6: tu política de VACUUM, tus borrados y tus cambios de schema son ahora el incidente de otra persona. Elígelo cuando el destinatario no pueda estar en tu plataforma, cuando la revocabilidad gane a un snapshot offline garantizado y cuando «un solo grant, sin ningún job de entrega que pueda fallar» gane a una landing zone.
• S3 entre cuentas + AWS Lake Formation, el grant nativo de AWS, dentro de la burbuja AWS. Lake Formation «uses the AWS Resource Access Manager (AWS RAM) to share the resource»; los shares dentro de la misma organización se aplican inmediatamente, los de fuera necesitan una invitación; LF-TBAC es el método de grant recomendado; y «Integrated services such as Athena and Amazon Redshift Spectrum require resource links» (docs de AWS, consultados 2026-10). Obtienes granularidad de fila/columna/celda, escalado por atributos LF-Tag y $0 en permisos, pero el consumidor necesita una cuenta de AWS, el catálogo es Glue, y nada de esto alcanza a una casa que vive en Power BI y nunca ha oído hablar de IAM. Elígelo dentro del perímetro de AWS, cuando los consumidores sean tus propias cuentas o socios que de todos modos viven en AWS.
• Copias ETL, lo que posees, y lo que dejas de seguir. Los extractos funcionan con absolutamente todo el mundo (incluido el regulador air-gapped del E1-5), le dan al consumidor un snapshot estable y propio, y sobreviven a tus caídas. Pero el extracto no se puede revocar, nadie sabe quién lo sigue teniendo, pagas dos veces (construir + conciliar) y la obsolescencia va de serie. Elígelo de forma deliberada, con una fecha de caducidad y un responsable, nunca por defecto.
• Nota al margen: Snowflake Secure Data Sharing es igualmente sin copias e igualmente cerrado: «Data sharing is only supported between Snowflake accounts»; cualquier otra cosa significa que el proveedor posee una reader account (≤ 75 por defecto, las eliminadas cuentan durante 7 días) y paga sus créditos de warehouse (docs de Snowflake, consultados 2026-10).
• Veredicto en una línea: destinatario de Databricks → Databricks-to-Databricks; socio que no es Databricks → OpenSharing con OIDC (token solo si te obligan); consumidores del mismo estate de AWS → Lake Formation entre cuentas; nadie en línea y un regulador quiere un archivo → una copia ETL, deliberada, con una fecha de caducidad.

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: Block (Square, Cash App, TIDAL) (servicios financieros, nube: AWS) Reto. 12PB de datos de grafo y analítica fragmentados entre unidades de negocio, más un doloroso flujo IAM de dos pasos, adjuntar políticas IAM a roles y después a buckets de S3, que convertía el acceso entre equipos en una cola de tickets. Stack en AWS. Databricks, Delta Lake, Unity Catalog, Spark Declarative Pipelines, Delta Sharing (con clean rooms planificadas), S3 como almacenamiento co-localizado: Cloud: AWS en la página del caso (https://www.databricks.com/customers/block/unity-catalog, página sin fecha, consultada 2026-10). Resultado reportado. «12X Reduction in compute cost · 20% Reduction in data egress cost · 12PB Of data managed and governed», ~70 equipos, 500 usuarios activos intensivos, y el tiempo de permisos de intercambio de datos reducido «from days to seconds» (misma URL, sin fecha, consultada 2026-10). Cita. «Introduction to Databricks coincided with the launch of Unity Catalog, eliminating the need for evaluating alternative data governance tools.»: Joseph Kesting (misma URL). Encaja con esta lección. Secciones 6 y 9: «de días a segundos» es exactamente el delta entre una cola de permisos IAM/S3 y un GRANT... ON SHARE sobre un securable de UC, y las clean room planificadas son el modelo de aprobación de notebook de la sección 9 a una escala en la que 12PB no pueden moverse físicamente. ⏳ Nota temporal: página sin fecha, consultada oct 2026: trata cada cifra como lo que Block reportó, no como una garantía de la plataforma.

📋 Caso B: nCino (software bancario, nube: AWS) Reto. Consolidar 13 años de datos bancarios y «trillions in loan history» manteniendo la postura de cumplimiento ajustada y la información financiera sensible bajo control total. Stack en AWS. Databricks en AWS, Unity Catalog, AI/BI Genie: Cloud: AWS en la página del caso; los casos de uso listan explícitamente Analytics and BI, AI, Data Warehousing, Governance and Security (https://www.databricks.com/customers/ncino, página sin fecha, consultada 2026-10). Cita. «Keeping data within a single AWS ecosystem reduces complexity, strengthens compliance and gives teams full control over sensitive financial information.» (misma URL). Encaja con esta lección. Sección 1: nCino es el contraejemplo que hace honesto el mapa de superficies: cuando el argumento de cumplimiento es «permanecer dentro del límite de una sola cuenta AWS», la respuesta es Lakehouse Federation (sección 8) para las bases de datos externas y grants al estilo de Lake Formation para las cuentas de dentro, no un share externo. Saber cuándo no compartir también es parte del diseño. ⏳ Nota temporal: página sin fecha, consultada oct 2026.

📋 Caso C: Atlassian, y los adoptantes nombrados del protocolo (software, multindustria) Reto. Desbloquear el acceso a datos críticos en la nube para clientes que no están todos en una misma plataforma: el problema entre plataformas exactamente para el que existe un protocolo abierto. Evidencia. El comunicado de prensa de OpenSharing de Databricks (2026-06-10) nombra a Amadeus, Atlassian, LSEG, SAP, Stripe y The Trade Desk como usuarios del estándar (https://www.databricks.com/company/newsroom/press-releases/databricks-announces-opensharing, 2026-06-10); la página de producto (consultada 2026-10) nombra además Shell, Nasdaq, Deutsche Börse, SafeGraph y YipitData. Atlassian: «Atlassian Analytics launched data shares, leveraging OpenSharing from Databricks, to unlock access to critical cloud data for our customers at scale» (opensharing.io, consultado 2026-10). Encaja con esta lección. Sección 2; estos son los nombres pegados a la estadística del «33% de los shares que fluyen entre plataformas», y son la razón por la que el protocolo (Linux Foundation) y no la API del producto es lo duradero contra lo que diseñar. ⏳ Nota temporal: las afirmaciones de adopción las reporta el proveedor con respecto a los anuncios de 2026-06.

---

---

Preguntas de Práctica (Practice Questions)

Pasa el cursor sobre una barra: WITHOUT HISTORY deja solo lecturas batch básicas (1); añadir historial con un filtro de partición recupera el time travel pero sigue bloqueando el acceso por cloud token (2); un WITH HISTORY completo sin filtro de partición desbloquea lecturas por URL prefirmada más time travel, CDF y streaming (4); el mismo share además se vuelve elegible para cloud tokens basados en directorio (5): con la exposición del Delta log que la sección 5.2 y la ⚠️ ADVERTENCIA adjuntan a ese modo. La escala es un modelo didáctico de la matriz de funciones documentada, no una métrica de la plataforma.