SQL warehouses de Databricks y la capa de servicio: serverless, escalado, dashboards, BI y federación

Todo lo que hay aguas arriba en este curso termina igual: una tabla Delta, gobernada por Unity Catalog, que alguien tiene que leer. Los analistas la leen en un SQL editor, los directivos en un dashboard, Tableau la lee por ODBC y un pipeline de informes la lee a través de un catálogo federado. En Databricks toda esa lectura ocurre en una sola pieza de cómputo, el SQL warehouse, y la decisión que tomes sobre el tipo de warehouse, el tamaño, la ventana de auto-stop y el driver de BI es a la vez una decisión de latencia, una decisión de gobernanza y una factura.

Esta lección es esa decisión, resuelta de punta a punta. La columna vertebral es una distinción única que las docs de octubre de 2026 enuncian sin rodeos: con un SQL warehouse pro o classic la capa de cómputo existe en tu cuenta de AWS; con un SQL warehouse serverless existe en la cuenta de Databricks (docs.../compute/sql-warehouse/warehouse-types, última actualización 11 sep 2026). Todo lo demás, arranques en frío de 2 a 6 segundos frente a unos cuatro minutos, cluster policies que dejan de aplicar, una VPC gestionada por el cliente que deja de importar, el pie de página de $0.70 "includes cloud instance cost", se deriva de esa única línea.

En esta lección vas a:

• leer la línea de warehouses de oct 2026, tres tipos GA más la Beta de Lakehouse//RT, y la matriz de capacidades que los separa (Photon, Predictive IO, Intelligent Workload Management);
• dibujar dónde vive el cómputo en AWS (cuenta de Databricks frente a tu VPC), incluida la historia del egress serverless y del PrivateLink saliente;
• resolver siete ejemplos resueltos: una tabla de decisión de tipo de warehouse con la invocación de la API, cálculos de dimensionado de concurrencia, un cálculo de desperdicio por auto-stop, un paquete de consultas de monitoreo, una ficha de conexión BI para Tableau y Power BI, una secuencia de DDL de consulta federada y un boceto de coste mensual a dos columnas DBU + EC2 con tarifas de oct 2026;
• dimensionar un warehouse del síntoma al mando usando el query profile y los códigos de performance insights;
• construir dashboards AI/BI, consultas guardadas y alertas, y saber exactamente qué pasó con los dashboards heredados;
• cablear herramientas de Tableau, Power BI, Excel y Partner Connect con los nombres de driver y los mínimos actuales;
• bocetar Lakehouse Federation con foreign catalogs, y nombrar el requisito que excluye en silencio a los warehouses classic;
• estudiar NAB, Punchh y nCino en AWS, leer el recuadro de actualizaciones de 2026 y practicar con doce preguntas más cuatro comprobaciones interactivas.

---

1. Qué es Databricks SQL y las dos puertas que atraviesa cada consulta

1.1 Una interfaz, muchas superficies

Databricks SQL es "a cloud data warehouse built on lakehouse architecture. It runs directly on your data lake": un data warehouse en la nube construido sobre arquitectura lakehouse que corre directamente sobre tu data lake: con SQL ANSI y extensiones de Delta Lake (docs.../sql/, última actualización 11 sep 2026). Las superficies documentadas: SQL editor (autoría asistida por IA, comentarios de código, historial de versiones), notebooks adjuntos a un warehouse, jobs, dashboards, metric views, alerts, ETL (streaming tables y materialized views definidas directamente desde SQL) y una REST API: más los monitores: historial de consultas, query profile y query performance insights.

La regla de cómputo que vale la pena memorizar: "Databricks uses SQL warehouses for compute in the following interfaces: SQL editor · Databricks SQL queries · Dashboards · SQL alerts" y, opcionalmente, notebooks, el file editor y Lakeflow Jobs (docs .../query, última actualización 11 sep 2026). La misma página añade dos restricciones que dan forma a todo lo que sigue:

• "Cuando consultas datos con SQL warehouses, solo puedes usar sintaxis SQL.": al consultar datos con SQL warehouses solo puedes usar sintaxis SQL.
• "For workspaces that are enabled for Unity Catalog, SQL warehouses always use Unity Catalog to manage access to data sources.": en los workspaces con Unity Catalog habilitado, los SQL warehouses usan siempre Unity Catalog para gestionar el acceso a las fuentes de datos.

Y desde la página warehouse-types: "SQL warehouses do not support credential passthrough. Databricks recommends using Unity Catalog for data governance." No existe en un warehouse la vía de credencial por usuario: la gobernanza son grants de Unity Catalog, punto y final.

1.2 Las dos puertas

Toda consulta que pasa por un warehouse atraviesa dos comprobaciones independientes, y los estudiantes suelen confundirlas:

1. El ACL del warehouse, ¿puede este principal usar este cómputo? (CAN USE para ejecutar, CAN MONITOR para ver profiles, CAN MANAGE para reconfigurar, sección 9.)
2. El grant de Unity Catalog: ¿puede este principal leer esta tabla? (SELECT sobre catálogo/schema/tabla.)

Superar una no dice nada de la otra. Un usuario con CAN USE en el warehouse y sin SELECT en la tabla recibe un error de autorización; un usuario con SELECT y sin CAN USE ni siquiera llega al motor. Enseña las dos, siempre.

Ese diagrama es también el modelo mental del resto de la lección: las secciones 2 to 4 deciden dónde está el cómputo y cuánto hay, las secciones 5 to 6 deciden qué ve el usuario, las secciones 7 to 8 deciden qué herramientas pueden hablar con él, la sección 9 decide quién puede, y la sección 10 decide cuánto cuesta.

---

2. La línea de warehouses a oct 2026: serverless, pro, classic, y una Beta

2.1 Tres tipos GA, una Beta

"Databricks SQL supports serverless, pro, and classic types" y "Additionally, Lakehouse Real-Time (Beta) is a specialized serverless warehouse type for sub-second, high-concurrency read queries" que "supports (SELECT) queries only" (docs .../warehouse-types, última actualización 11 sep 2026). La matriz de capacidades de la misma página:

De la fila del medio se siguen tres consecuencias:

1. Pro y classic heredan tu red de AWS. Corren como EC2 en la VPC del workspace, eligen una availability zone mediante Auto-AZ y están gobernados por cluster policies, ajustes de spot y tu diseño de VPC/PrivateLink (la red del workspace de la lección 02).
2. Serverless no. "Customer-managed VPCs are not applicable to compute resources for serverless SQL warehouses", "Cluster policies, including spot instance policies, are not supported" y "serverless SQL warehouses do not have public IP addresses" (docs .../sql/admin/serverless, última actualización 10 jun 2026).
3. Classic es el valor por defecto de la API siendo el tipo menos capaz. Usando la UI "the default SQL warehouse type is serverless"; usando la API de SQL warehouses con valores por defecto "the default SQL warehouse type is classic. To use serverless, set the enable_serverless_compute parameter to true and warehouse_type to pro." Los scripts de Terraform que omiten esa bandera crean en silencio el único tipo de warehouse que no puede federar, no puede crear materialized views ni streaming tables y no puede llamar a AI Functions.

2.2 Requisitos de serverless en AWS (léelos antes de prometerlo)

Desde docs .../sql/admin/serverless (última actualización 10 jun 2026): la cuenta "must not be on a free trial"; el workspace "must be on the Premium plan or above"; "Serverless SQL warehouses are supported in all AWS regions"; el workspace "must not use S3 access policies" ni usar "an external Hive legacy metastore" (warehouse-types repite la cláusula del metastore: "If your workspace uses a legacy external Hive metastore, serverless SQL warehouses are not supported"). La identidad es Unity Catalog y la conectividad es privada: serverless "usa conectividad privada entre el plano de control de Databricks y el plano de cómputo serverless en casi todos los casos."

• 📚 ¿Sabías que…? El egress de serverless hacia tus recursos es un problema distinto de la propia falta de IPs públicas de serverless. Para cualquier cosa fuera de Amazon S3 o DynamoDB de la misma región, "serverless compute uses public IP addresses to reach your resources", y desde mediados de febrero de 2026 Databricks "publishes outbound IPs in JSON format on a public endpoint", tras el 25 may 2026 las listas IP heredadas quedaron retiradas (docs.../serverless-firewall, consultadas 2026-10). Para conectividad dedicada usas PrivateLink saliente a través de una network connectivity configuration: cada cuenta recibe hasta 10 NCC por región, cada región 30 private endpoints y cada NCC adjunta hasta 50 workspaces, y esa vía necesita el Enterprise plan (docs.../pl-to-internal-network, consultadas 2026-10).

2.3 Dónde vive el cómputo, dibujado

El borde derecho es el que los estudiantes se pierden: la federación desde un warehouse serverless hacia una base de datos privada aún tiene que recorrer una ruta de red, y serverless trae consigo sus propias reglas de egress. Pro es la elección documentada cuando "tienes una red definida de forma personalizada y quieres conectarte a bases de datos de tu red" (warehouse-types, 11 sep 2026).

2.4 Ejemplo resuelto E1: la tabla de decisión de tipo de warehouse y la invocación de la API

Entradas (tres bifurcaciones, todas específicas de AWS):

1. ¿El workspace es elegible para serverless (Premium o superior, sin trial, sin metastore Hive externo heredado, sin S3 access policies)?
2. ¿Necesitas alcanzar una base de datos privada/on-prem para la federación, o imponer una red personalizada?
3. ¿Necesitas AI Functions, o materialized views / streaming tables creadas desde SQL?

El cuerpo de la API que te da serverless (docs .../api/warehouses/v1/warehouse, consultadas 2026-10):

warehouse_type solo acepta PRO u CLASSIC; serverless es PRO más enable_serverless_compute: true. Omite la bandera y has construido un warehouse pro: que es un warehouse perfectamente bueno, solo que con un arranque en frío de cuatro minutos y una línea de EC2 en tu factura de AWS. Las tags están limitadas a menos de 45 por warehouse y existen, en las propias palabras de la API, "to monitor the cost of cloud resources used by users and groups."

---

3. Dimensionado: tallas de camiseta, la regla de concurrencia y los límites duros

3.1 La escalera de tamaños

Las tallas van de 2X-Small a 5X-Large, y para classic/pro la escalera es concreta: "All workers use i3.2xlarge instances" (docs .../compute/sql-warehouse/warehouse-behavior, última actualización 8 oct 2026).

Solo el driver escala, i3.2xlarge → i3.4xlarge → i3.8xlarge → i3.16xlarge, mientras que cada worker sigue siendo i3.2xlarge (misma página). Las docs advierten que la tabla "can vary based on product or region availability and workload"; lee system.compute.warehouses para saber la forma que realmente te tocó.

El valor por defecto al crear un warehouse en la UI es X-Large. La caché de disco vive en los SSD locales de esos workers (sección 6), y por eso la familia i3 optimizada para almacenamiento importa para el rendimiento de consultas, y por eso el precio del nodo i3 en AWS importa para el boceto de coste de la sección 10.

3.2 La concurrencia es un mando de número de clusters, no de tamaño

Reglas documentadas (warehouse-behavior 8 oct 2026; create 11 sep 2026):

• "a cluster for every 10 concurrent queries": la regla de dimensionado, enunciada en ambas páginas.
• "El número máximo de consultas en cola para todos los tipos de warehouse es 1,000."
• Límites de la API: max_num_clusters ≤ 40; min_num_clusters ≤ min(máx, 30); mínimo por defecto 1. Subir min_num_clusters "will ensure that a larger number of clusters are always running and therefore may reduce the cold start time": a un coste de facturación continua.
• Tope del workspace: 1,000 SQL warehouses en total, fijo (docs .../resources/limits, 9 oct 2026).
• "Databricks recicla los clusters que llevan más de 24 horas en ejecución" y puede terminarlos a la fuerza: así que ninguna consulta ni ninguna sesión de notebook adjunto debe dar por sentados clusters inmortales.

La regla de los dos mandos que arregla la mayoría de los dashboards: la talla (tamaño del cluster) compra potencia por consulta; max_num_clusters compra concurrencia. Vuelco a disco significa el primer mando; cola significa el segundo.

La serie plana es la lección: con max_num_clusters fijado en 4 obtienes 4 × 10 = 40 slots de consulta concurrentes en cualquier talla, desde un 2X-Small de 1 worker hasta un 5X-Large de 512 workers. Ir más ancho en el eje de tamaños multiplica la potencia por consulta (y el coste) sin admitir ni una consulta concurrente más; ir más ancho en max_num_clusters hace lo contrario. Los nombres de talla de warehouse son idénticos entre tipos, pero las tallas de serverless se facturan a una tarifa fija de DBU por hora que depende de la talla que elijas (docs answers, página fechada el 2026-08-27).

3.3 Ejemplo resuelto E2: dimensionar 30 usuarios concurrentes de dashboard

Escenario. Un equipo de BI con 30 usuarios concurrentes de dashboard, consulta media de 4 s, dashboards en marcha de 09:00 a 18:00, 21 días laborables al mes.

Respuesta: tres clusters como mínimo bajo el ratio documentado, con talla Medium o Large según la evidencia de vuelco, y max_num_clusters ajustado por adelantado al estallido del pico, y en serverless, un único warehouse más grande con IWM en lugar de ajustar a mano tres clusters.

3.4 Síntoma → mando

Dos límites duros se esconden detrás de ese árbol: la cola admite como máximo 1,000 consultas, y el profile de un resultado en caché no existe (sección 6): así que para medir hay que derrotar primero la caché, o el árbol se verá más limpio de lo que es.

---

4. Escalado, auto-stop y economía del arranque en frío

4.1 Dos modelos de escalado, no uno

Dos modelos de escalado documentados: uno por familia de warehouse:

• Classic y pro: clusters min/máx más autoscaling según carga, con las bandas de carga citadas en E2 (añade clusters tras 2 to 6, 6 to 12, 12 to 22 minutos de carga; escala hacia arriba cuando una consulta espera 5 minutos; escala hacia abajo tras 15 minutos seguidos de carga baja). Las availability zones se resuelven con Auto-AZ.
• Serverless: Intelligent Workload Management. "IWM uses machine learning models to dynamically manage compute resources"; cuando falta capacidad "the query is placed in a queue", y "if wait times increase, the autoscaler quickly provisions more clusters" (warehouse-behavior, 8 oct 2026). IWM es exclusivo de serverless: pro y classic reciben Photon y Predictive IO pero no IWM.

4.2 Auto-stop: la optimización más barata de este curso

Y la frase del dinero, literal: "Idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped." (misma página). Un warehouse factura mientras está encendido: no mientras está ocupado.

⚠️ ADVERTENCIA, un valor por defecto de auto-stop es una decisión de facturación que heredas. El valor por defecto de 45 minutos de pro/classic está elegido por comodidad, no por economía: cualquier hueco más corto que 45 minutos mantiene un warehouse (y sus instancias EC2, en tu cuenta de AWS) facturable. Al contrario, un warehouse serverless con su mínimo de 1 minuto por API se detendrá entre dos refrescos de dashboard de un usuario, barato, y a solo un reinicio de 2 to 6 segundos. En un warehouse pro/classic ese mismo reinicio es de ~4 minutos, que los usuarios leen como una caída del servicio. Ajusta el auto-stop al comportamiento del cliente: extracts y refrescos programados → auto-stop más largo o min_num_clusters = 1; humanos interactivos sobre serverless → auto-stop corto. Y nunca pongas el auto-stop en "never": la frase de cargo por inactividad de las docs es incondicional.

4.3 Ejemplo resuelto E3: lo que cuesta al mes un valor por defecto de auto-stop

Escenario (supuestos declarados: vuelve a ejecutarlo con tu propio tráfico): un warehouse pro que sirve dashboards con tráfico real solo en dos estallidos: 09:00 to 10:00 y 14:00 to 15:00: durante 21 días laborables.

Tarifas: SQL Classic $0.22/DBU (instantánea de página 2026-10) y AWS us-east-1 bajo demanda i3.2xlarge $0.624/h (lista de precios de AWS EC2, leída el 2026-10-12). La emisión de 4 DBU/h es una cifra ilustrativa por talla: la página de precios publica $/DBU únicamente, así que lee tu propia DBU/hora por talla desde system.billing.list_prices (sección 10). El argumento sobrevive a la sustitución: veinte minutos de auto-stop innecesario en veinte warehouses eclipsan cualquier cambio de nivel de talla.

• 📚 ¿Sabías que…? El auto-stop es solo la mitad de la historia de la inactividad. Subir min_num_clusters "reduce el tiempo de arranque en frío de consultas nuevas" (Warehouses API, consultadas 2026-10) pero mantiene clusters facturables calientes las 24 horas: mientras que en serverless el arranque en frío ya es de 2 to 6 segundos, así que min_num_clusters > 1 rara vez compensa pagarlo. Y porque "Databricks recicla los clusters que llevan más de 24 horas en ejecución", un warehouse que nunca se queda inactivo aún ve reciclados sus clusters, con posible terminación forzada de trabajos largos (docs.../sql-warehouse/create, 11 sep 2026).

---

5. Consultas, dashboards y alertas: el banco de trabajo de DBSQL

5.1 Las consultas guardadas tienen sus propios permisos

El SQL editor se entrega con asistencia de IA, comentarios de código e historial de versiones (docs .../sql/, 11 sep 2026). Las consultas guardadas son securables en su propio derecho (docs .../sql/user/queries, última actualización 29 abr 2026):

• compartir una consulta requiere CAN MANAGE sobre esa consulta;
• dos modos de credencial: "Run as viewer", "La credencial del visor se usa para ejecutar la consulta; el visor también debe tener al menos permisos CAN USE sobre el warehouse", frente a "Run as owner";
• "A Databricks workspace admin user has view access to all queries in the workspace."

La UI del historial de consultas conserva 30 días de historial; ves tus propias consultas como owner, o las de otros si tienes al menos CAN VIEW sobre el warehouse que las ejecutó. Cualquier cosa de vida más larga va a system.query.history (sección 6).

5.2 Dashboards AI/BI: la generación Lakeview, hoy la única generación

"AI/BI dashboards feature AI-assisted authoring, an enhanced visualization library, and a streamlined configuration experience" (docs .../dashboards, última actualización 11 sep 2026). El conjunto de capacidades documentado: datasets y visualizaciones; filtros a nivel global/página/widget con cross-filtering y drill-through; cálculos personalizados; borrador/publicación; "Una vez publicados, tus dashboards pueden compartirse con cualquier persona registrada en tu cuenta de Databricks, aunque no tenga acceso al workspace"; incrustación por iframe; programación y suscripción por correo o Slack; integración Git / source control; Declarative Automation Bundles; APIs REST; programación como Lakeflow Job; agentes Genie; monitoreo de uso mediante audit logs y system tables; y lineage de Unity Catalog incorporado.

Los dashboards heredados ya no existen. "End of support for legacy dashboards: April 10, 2025. You can no longer create or clone legacy dashboards using the UI or API" (docs.../ai-bi/release-notes/2025); la documentación heredada está retirada, y el endpoint de migración POST /api/2.0/lakeview/dashboards/migrate está marcado como Deprecated con la nota "Use Lakeview (AI/BI) dashboards instead" (referencia de la API Lakeview, consultadas 2026-10).

• 📚 ¿Sabías que…? El nombre que ves en la API es un fósil. Los dashboards AI/BI "antes se llamaban dashboards Lakeview. La API de Lakeview aún conserva ese nombre": así que toda llamada create/list/publish sigue siendo /api/2.0/lakeview/dashboards/* aunque la UI diga AI/BI (docs.../dashboards, 11 sep 2026; referencia de la REST API, consultadas 2026-10). Cualquier script, resource de Terraform o tutorial que hable de "migrating to Lakeview" está escribiendo historia de 2023 to 2024: el endpoint de migración está obsoleto y los dashboards heredados no pueden crearse en absoluto desde el 2025-04-10.

5.3 Alertas

"Use Databricks SQL alerts to periodically run queries, evaluate defined conditions, and send notifications if a condition is met" (docs.../sql/user/alerts, página fechada el 28 jul 2026). Desde mayo de 2025 el editor está consolidado, configuración de la consulta, condiciones, programaciones y destinos de notificación en una sola interfaz, y las alertas heredadas siguen funcionando junto a él (notas de lanzamiento, mayo de 2025). Las alertas son la mitad de cierre del bucle de monitoreo: adjunta una a la consulta de higiene de la flota del E4 y un warehouse cuyo auto-stop se pasa de 30 minutos avisa a alguien en lugar de facturar en silencio.

---

6. Caché, query profile y system tables

6.1 Cuatro cachés, cuatro vidas

(docs.../queries/query-caching y.../optimizations/disk-cache, consultadas 2026-10). Para medir con honestidad: SET use_cached_result = false;: documentado como apropiado "only in testing or benchmarking". Las consultas deterministas aciertan en caché; un predicado estilo NOW() las derrota y entonces pagas precio completo en cada ejecución.

6.2 El profile, los insights y sus significados

• Query profile: debes ser el owner de la consulta o tener al menos CAN MONITOR en el warehouse; "El profile de consulta no está disponible para las consultas que se ejecutan desde la caché de consultas. Para rodear la caché de consultas, haz un cambio trivial en la consulta, como modificar o quitar el LIMIT" (docs.../query-profile, 10 jun 2026).
• Query performance insights: recomendaciones con código (docs.../performance-insights, 11 sep 2026): DATA_SPILL → "Increase the warehouse size to add memory"; EXCESSIVE_QUEUE_TIME → "Increase the maximum number of clusters"; IO_THROTTLING → solicita límites de peticiones de almacenamiento más altos; más DATA_SKEW, MANUAL_DATA_LAYOUT y las aceleraciones aplicadas AUTO_LIQUID_CLUSTERING, HISTORY_BASED_JOIN_STRATEGY, SHORT_QUERY_PRIORITIZATION.
• System tables: la misma historia que los datos: system.query.history (Public Preview, 365 días, regional, registros "typically available within one hour"), system.compute.warehouses (instantáneas de configuración), system.compute.warehouse_events (eventos de arranque/parada/escalado), system.billing.usage y system.billing.list_prices (el registro de precios, retención indefinida, global).

Nota de acceso sobre system.query.history: "By default, only admins have access to the system table… Databricks recommends creating a dynamic view for each user or group" (docs .../system-tables/query-history, página fechada el 21 sep 2026). Su columna client_application es la que te dice si una consulta vino del "Databricks SQL Editor, Tableau, and Power BI", y cache_origin_statement_id es la forma de probar que un resultado vino de la caché.

6.3 Ejemplo resuelto E4: un paquete de monitoreo para la flota de warehouses

Fuentes: página de monitoring-queries (docs.../sql-warehouse/monitor/queries, 11 sep 2026), referencia de query-history (21 sep 2026), system tables de facturación (actualizadas el 2026-10-08). La consulta (a) es la que hay que cablear a una alerta; la consulta (d) es la que hay que publicar en un dashboard AI/BI: Databricks entrega consultas de coste listas y un Usage Dashboard prefabricado exactamente para esto (docs.../admin/usage/system-tables, 11 sep 2026).

---

7. Conectividad BI: primero los drivers, después las herramientas

7.1 El estado de los drivers a oct 2026

(docs .../integrations/odbc/download, espejo de página fechado el 11 sep 2026; páginas de descarga y de archivo de drivers, consultadas 2026-10). El renombramiento de febrero de 2026 importa operativamente: "A partir de febrero de 2026, Databricks publica nuevas versiones del driver ODBC y el driver pasó a llamarse Databricks ODBC Driver." Rutas de instalación: Windows C:\Program Files\Databricks ODBC Driver, macOS /Library/databricks/databricksodbc, Linux /opt/databricks/databricksodbc. Algunas herramientas empaquetan el driver (versiones recientes de Power BI Desktop); Tableau Desktop no.

El denominador común en todas las herramientas: conexión = Server Hostname + HTTP Path de un SQL warehouse; autenticación = OAuth / acceso de Databricks / personal access token / service principal. La autenticación por usuario y contraseña está muerta: la propia ayuda de Tableau registra que "Basic authentication using a Databricks user name and password reached end of life as of July 2024."

7.2 La matriz de herramientas

• 📚 ¿Sabías que…? Las versiones de driver son un compromiso de soporte, no solo una lista de descargas: "Databricks supports each driver version for at least 2 years" (página de descarga de drivers, consultada 2026-10). El archivo también lleva una advertencia que vale la pena leer una vez: las versiones de Simba JDBC anteriores a 2.6.21 dependen de una librería con CVE-2021-44228 (Log4Shell): una razón concreta por la que las docs "strongly recommend migrating" fuera de las líneas Simba.

7.3 Ejemplo resuelto E5: ficha de conexión BI (especificación para copiar y pegar)

Tableau Desktop → un SQL warehouse serverless

Power BI → el mismo warehouse

Ambas fichas asumen las dos puertas de la sección 1: CAN USE en el warehouse para la identidad de la herramienta, SELECT en las tablas subyacentes para esa misma identidad (un service principal necesita las dos). Añade el auto_stop_minutes del warehouse a la ficha: un extract programado cada 15 minutos contra un warehouse serverless con auto-stop de 10 minutos pagará un reinicio de 2 to 6 segundos cada vez, mientras que el mismo programa contra un warehouse pro paga ~4 minutos.

---

8. Lakehouse Federation: consultar otros sistemas desde Databricks SQL

8.1 Qué es

"Lakehouse Federation is the Databricks query federation platform. It provides governed, read-only access to external data through Unity Catalog foreign catalogs, with automatic query pushdown and fine-grained access controls at the table level" (docs .../query-federation, última actualización 29 sep 2026). Dos sabores:

• query federation: con pushdown hacia la base de datos externa por JDBC; "La consulta se ejecuta en Databricks y en el cómputo remoto… No soportado (solo lectura)" para escrituras;
• catalog federation: "Runs directly against object storage on Databricks compute only. More cost-effective and performance-optimized."

Listas de fuentes verificadas (oct 2026). Query federation: MySQL, PostgreSQL, Teradata, Oracle, Amazon Redshift, Salesforce Data 360, Snowflake, Microsoft SQL Server, Azure Synapse, Google BigQuery, Databricks. Catalog federation: metastore Hive heredado de Databricks, external Hive metastore, AWS Glue metastore, Salesforce Data 360, Snowflake, Palantir Foundry, Workday Data Connect, Google Cloud Lakehouse.

8.2 El requisito que excluye a los warehouses classic

Desde las páginas de federación de MySQL y SQL Server (19 ago / 11 sep 2026): "Databricks compute must use Databricks Runtime 13.3 LTS or above and Standard or Dedicated access mode"; "los SQL warehouses deben ser pro o serverless y usar 2023.40 o superior"; el workspace debe tener Unity Catalog habilitado (los workspaces creados después del 8 nov 2023 lo tienen). MySQL además requiere SSL. El pushdown es desigual por diseño: agregaciones, aritmética, booleanos/bit a bit y orden con límite hacen pushdown en 13.3 LTS+; los joins necesitan DBR 17.2+ (en MySQL: un toggle en Public Preview); las funciones de ventana no están soportadas en MySQL. Y cuando existen las dos vías, "When your source supports both Lakehouse Federation and Lakeflow Connect, Databricks recommends Lakeflow Connect if performance on higher data volumes and lower latency are priorities."

8.3 Ejemplo resuelto E6: consulta federada, MySQL en RDS → Databricks SQL

La referencia del lenguaje (docs.../sql-ref-federated-queries, fechada el 29 jun 2026) lo plantea como exactamente tres prerequisitos: crear una foreign connection, registrar foreign catalogs, conceder acceso, y advierte que aplica a "Databricks SQL · Databricks Runtime 13.3 LTS and above · Unity Catalog only". El join del paso 4 es la mitad interesante: Delta local unido a MySQL remoto, con el lado remoto empujado por JDBC y gobernado por los mismos grants que tus tablas nativas. Es de solo lectura, no sustituye a un ETL a volumen, y la ruta de red de tu warehouse hasta RDS la construyes tú (peering de VPC, PrivateLink o VPN: sección 2.3).

---

9. Quién puede tocar el warehouse: ACLs, entitlements y el patrón de grupos

Permisos de warehouse, desde la matriz de ACLs (docs .../access-control, última actualización 10 jul 2026) y la página de creación de warehouse (11 sep 2026):

Por encima de todo eso hay dos entitlements: el entitlement databricks-sql-access decide quién puede usar Databricks SQL en absoluto, y crear warehouses necesita admin del workspace o el entitlement Allow unrestricted cluster creation: "La mayoría de los usuarios no pueden crear SQL warehouses, pero pueden reiniciar cualquier SQL warehouse al que puedan conectarse." Los warehouses borrados pueden restaurarlos desde soporte dentro de 14 días.

El patrón de delegación que hay que enseñar: data-analysts → CAN USE en el warehouse de BI más SELECT en los schemas gold; bi-viewers → CAN VIEW; data-engineers → CAN MANAGE en el warehouse de plataforma y su auto-stop; service principals para Power BI/Tableau → CAN USE más SELECT. Grupos, no individuos: de lo contrario el CAN MANAGE generalizado de los admins del workspace se convierte en el único modelo que funciona, y con él llega la dispersión de administración.

---

10. Lo que cuesta: tarifas, medidores y la factura a dos columnas

10.1 Las tarifas (lista US, AWS, instantánea de página 2026-10)

Salvedades que tienes que imprimir junto a cualquier número: "Databricks prices and Cloud Infrastructure prices may vary based on geographic region and cloud service provider" (FAQ de precios, 2026-10); las tarifas serverless siguen a la infraestructura regional mientras que las de classic son planas en todas las regiones de AWS porque pagas el precio local de EC2 (una lectura secundaria del archivo de datos de la página de precios informó de $0.91/DBU para SQL Serverless en eu-central-1 frente a $0.70 en us-east-1, 2026-08-07: verifícalo en tu cuenta); los refresh de materialized views y streaming tables se facturan con las tarifas DLT serverless, no con la tarifa de tu warehouse (pie de página 3 de la página de precios, 2026-10); la inferencia de AI Functions se factura aparte bajo MODEL_SERVING / AI_FUNCTIONS (docs.../ai-functions, 9 oct 2026). El número autoritativo siempre es el tuyo: system.billing.list_prices (retención indefinida, global) unido a system.billing.usage.

10.2 Ejemplo resuelto E7: un boceto de coste mensual a dos columnas

Supuestos declarados: un warehouse 2X-Small (driver + 1 worker = 2 × i3.2xlarge), encendido 193 h/mes (≈9.2 h/día × 21 días laborables de BI en horario de oficina), emisión ilustrativa 4 DBU/h, AWS us-east-1 bajo demanda i3.2xlarge $0.624/h (lista de precios de AWS, leída el 2026-10-12), tarifas a 2026-10.

Léelo como tres lecciones, no como una clasificación. (A) solo es la más barata si aceptas un arranque en frío de ~4 minutos, sin Predictive IO, sin federación, sin AI Functions y sin creación de materialized views. (C) gana a (B) aquí porque con esta forma ligera y estable la columna de EC2 del warehouse pro ($240.86) supera todo el premium serverless ($540.40 − $424.60 = $115.80). Y la línea de sensibilidad de (A) es el verdadero titular: las horas inactivas dominan, no las tarifas de lista: que es la aritmética del auto-stop de la sección 4 apareciendo de nuevo en la factura. La cifra de 4 DBU/h es una emisión ilustrativa por talla; la página de precios publica $/DBU únicamente, así que saca tu propia emisión por talla de system.billing.list_prices para tu contrato antes de citarle un número a nadie.

---

11. Las trampas: catorce confusiones que esta lección no te deja conservar

1. "Serverless corre en mi VPC." Corre en la cuenta de Databricks: "las VPCs gestionadas por el cliente no son aplicables", sin cluster policies, sin IPs públicas.
2. "La API crea el mismo warehouse que la UI." Defecto de la UI = serverless; defecto de la API = classic salvo que enable_serverless_compute sea true y warehouse_type sea PRO.
3. "Classic es la opción económica." También es la opción que no puede federar, no puede crear MVs/STs y no puede ejecutar AI Functions.
4. "Un tamaño más grande significa más consultas concurrentes." La concurrencia es max_num_clusters × 10; la talla es potencia por consulta. Vuelco → talla; cola → clusters.
5. "El autoscaler se encarga del estallido de las 9." Classic/pro escalan hacia arriba solo después de que una consulta espere 5 minutos; el tope de cola es 1,000.
6. "Auto-stop de 45 minutos es inofensivo." "Idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped."
7. "El auto-stop de serverless puede ser cero." Mínimo 5 min en la UI, 1 min por API; el mínimo de pro/classic es 10 min.
8. "Conseguí un query profile, así que entiendo la ejecución." No existe profile para un resultado en caché: cambia el LIMIT.
9. "Caché es caché." Caché de UI (≤7 días, no AI/BI) ≠ caché local de resultados (muere con el cluster) ≠ caché remota de resultados (solo serverless, sobrevive a la parada) ≠ caché de disco (archivos, ≤50% del SSD).
10. "Los dashboards heredados siguen funcionando." Fin de soporte 2025-04-10: ni crear, ni clonar, endpoint de migración obsoleto.
11. "Lakeview es un producto distinto de AI/BI." Mismo producto, nombre de preview de 2023 retenido en la ruta REST /api/2.0/lakeview/dashboards.
12. "La autenticación por contraseña funciona con Tableau." La auth básica "reached end of life as of July 2024"; y la línea Simba ODBC está obsoleta desde el renombramiento de febrero de 2026.
13. "La federación me deja escribir de vuelta." Solo lectura, pushdown JDBC con soporte desigual; usa Lakeflow Connect cuando importen volumen y latencia.
14. "La tarifa de $0.70 es toda la factura serverless." Los refresh de MV se facturan con tarifas DLT serverless, la inferencia de IA bajo MODEL_SERVING/AI_FUNCTIONS, y la red hacia tu VPC puede llevar sus propios cargos.

---

Veredicto comparativo: SQL warehouse classic frente a pro frente a serverless (AWS, a oct 2026)

• Classic, $0.22/DBU más cargos de instancia en la nube, arranque de ~4 minutos. El valor por defecto de la API y el suelo de la línea: solo Photon, sin Predictive IO, sin IWM. No puede federar, no puede crear materialized views ni streaming tables desde SQL, no puede ejecutar AI Functions. Corre en tu VPC con cluster policies, ajustes de spot y la caché de disco en el SSD local i3. Elígelo cuando la carga sea SQL simple con una forma estable, el coste por DBU sea la restricción que aprieta y ninguna de las tres funciones ausentes aplique, y pon el auto-stop a 10 minutos, no a 45.
• Pro, $0.55/DBU más cargos de instancia en la nube, arranque de ~4 minutos. Todo lo que tiene classic más Predictive IO, y la elección documentada cuando "tienes una red definida de forma personalizada y quieres conectarte a bases de datos de tu red", es decir, federación desde dentro de tu VPC. Siguen siendo tus instancias, tu Auto-AZ, tus políticas, tu columna de EC2. Elígelo cuando el alcance de la red privada importe más que la latencia del arranque en frío.
• Serverless: $0.70/DBU, máquina incluida, arranque de 2 to 6 segundos. El valor por defecto documentado para la mayoría de las cargas: Photon + Predictive IO + IWM, sin cluster policies (así que tampoco guardrails basados en políticas), sin VPC gestionada por el cliente, sin IPs públicas, auto-stop por defecto de 10 minutos, facturación por segundo sin cargo por inactividad más allá de la ventana de auto-stop. Elígelo salvo que una bifurcación de E1 diga lo contrario.
• Veredicto en una línea: serverless por defecto → pro cuando necesites el cómputo dentro de tu cuenta de AWS para federación o red personalizada → classic solo para SQL estrecho, estable y sin funciones donde $0.22 gana la aritmética. Todas las tarifas son lista US, AWS, instantánea de página 2026-10; la emisión de DBU por hora y por talla debe venir de system.billing.list_prices, no de un tutorial.

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: NAB (National Australia Bank, banca, Cloud: AWS) Reto. Un almacén Teradata de 26 años con ~1,000 casos de uso y ~140 suites de informes, con ETL escrito a mano y prácticas inconsistentes entre 300 to 400 ingenieros. Stack en AWS. Databricks SQL como reemplazo del almacén, más Auto Loader, Spark Declarative Pipelines (Lakeflow), Unity Catalog y asset bundles: Cloud: AWS en la página de la historia. Resultado comunicado. "26-year-old Teradata warehouse decommissioned · 456 Use cases migrated to Databricks SQL · 1,200+ Users enabled"; "95% of critical workloads migrated"; ~140 suites de informes retiradas (https://www.databricks.com/customers/nab/dbsql, página sin fecha, consultada 2026-10). Cita. "La migración no habría sido posible sin Databricks SQL": Gurry, misma URL. Encaje con esta lección. Secciones 3, 7 y 9: reemplazar un almacén es una racionalización de informes más un ejercicio de dimensionado y ACLs: 1,200 usuarios necesitan CAN USE por grupo, y 456 casos de uso necesitan un presupuesto de concurrencia para toda la flota, no un almacén gigante. ⏳ Nota temporal: página sin fecha, consultada en oct 2026: un resultado de cliente comunicado, no una garantía de 2026.

📋 Caso B: Punchh (fidelización de comercio minorista / tecnología de restaurantes, Cloud: AWS) Reto. Había superado a AWS MySQL, un almacén demasiado caro para mantener, y los informes de Tableau lentos por joins de 12 tablas ejecutados de cero en cada informe. Stack en AWS. Databricks SQL sobre tablas Delta bronze/silver/gold, notebooks y Tableau encima: Cloud: AWS en la página de la historia. Resultado comunicado. "10x Faster time-to-insight · 30% Lower operational costs · 12% Increase in customer satisfaction" (https://www.databricks.com/customers/punchh, página sin fecha, consultada 2026-10; historia de origen 2021). Cita. "Cuando unes 12 tablas sobre la marcha cada vez que un cliente ejecuta un informe, el coste de generar el informe puede ser alto. Databricks no solo mejoró el rendimiento del ETL, sino que redujo los costes generales": Phylis Savari, misma URL. Encaje con esta lección. Secciones 7 y 10: el patrón de BI externo en su forma más pura: Tableau por ODBC contra un SQL warehouse, con tablas gold preunidas haciendo lo que de otro modo un warehouse más grande tendría que hacer a la fuerza. ⏳ Nota temporal: una historia de origen 2021 que aún se muestra en 2026: enseña el mecanismo, data las métricas.

📋 Caso C: nCino (software bancario, Cloud: AWS) Reto. Consolidar 13 años de datos bancarios y "trillions in loan history" manteniendo la información financiera sensible bajo control total. Stack en AWS. Databricks sobre AWS con Unity Catalog y AI/BI Genie: Cloud: AWS; los casos de uso listan Analytics and BI, AI, Data Warehousing, Governance and Security. Resultado comunicado. "Keeping data within a single AWS ecosystem reduces complexity, strengthens compliance and gives teams full control over sensitive financial information"; "With Unity Catalog governing access and AI/BI Genie democratizing insights, executives, analysts and relationship managers all benefit from domain-driven AI solutions" (https://www.databricks.com/customers/ncino, página sin fecha, consultada 2026-10). Encaje con esta lección. Secciones 5 y 9: dashboards AI/BI más Genie como capa de servicio gobernada, con las dos puertas (ACL del warehouse + grant de UC) haciendo el trabajo de cumplimiento. ⏳ Nota temporal: página sin fecha, consultada en oct 2026.

---

---

Preguntas de Práctica (Practice Questions)