Arquitectura Lakehouse en Databricks: Planos, Pilares y el Sustrato AWS

Todas las demás lecciones de este curso dan por sentadas tres cosas que todavía no has demostrado a ti mismo: que un lakehouse es una categoría arquitectónica real y no una palabra de marketing, que el software de Databricks se ejecuta en dos cuentas de la nube a la vez, y que el dinero llega en dos facturas separadas. Si te equivocas en una de esas tres, diseñarás un workspace cuyo data lake está en el bucket equivocado, cuyo modelo de amenazas apunta a la cuenta equivocada y cuyo modelo de costes se queda corto en aproximadamente la mitad.

Esta lección demuestra las tres con fuentes primarias. Cada hecho arquitectónico de esta lección proviene de páginas de docs.databricks.com fechadas entre 2026-07-28 y 2026-09-25, de los propios blogs de despliegue de Databricks en AWS (2022-09-30, 2023-01-27) y de las páginas de precios de AWS consultadas en octubre de 2026. Todos los precios son de lista en USD, sellados con la fecha en que se leyeron, porque las tarifas de DBU y las de AWS se mueven.

En esta lección vas a:

• definir el lakehouse frente al data lake y al data warehouse, usando las tres propiedades que Databricks publicó en 2020 y el patrón medallion (bronze → silver → gold);
• separar los dos pilares, Delta Lake para la fiabilidad y el formato, Unity Catalog para la gobernanza, y asociar cada uno al objeto de AWS que toca (tu bucket S3, tu IAM role);
• dibujar la división plano de control / plano de cómputo, incluyendo secure cluster connectivity, la IAM role cross-account y la regla de región del plano serverless;
• deducir dónde viven realmente los datos, y por qué el bucket de almacenamiento del workspace no es, ni de lejos, tu data lake;
• construir el mapa de cargas de trabajo (ingest → curate → serve → ML) y hacer corresponder cada carga de trabajo con el cómputo que la ejecuta;
• leer la tabla de tarifas DBU a oct 2026 y calcular a mano seis ejemplos resueltos con cifras reales;
• comparar la plataforma con la stack nativa de AWS, con Snowflake y con Hadoop on-prem sin repetir el marketing del proveedor como si fuera un hecho;
• estudiar tres casos de estudio de AWS con nombre propio, leer el recuadro de actualizaciones de 2026 y responder doce preguntas tipo examen.

---

1. Qué es un lakehouse: una arquitectura, tres propiedades

La definición actual de Databricks (databricks.com/blog/what-is-data-lakehouse-article, 2026-06-23) es la que hay que memorizar:

“Un lakehouse de datos es una nueva arquitectura abierta de gestión de datos que combina la flexibilidad, la eficiencia de costes y la escala de los data lakes con la gestión de datos y las transacciones ACID de los data warehouses, permitiendo la inteligencia empresarial (BI) y el machine learning (ML) sobre todos los datos.”

El post canónico de 2020 que nombró el patrón enumera exactamente tres propiedades definitorias (databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html, 2020-01-30):

1. Soporte de transacciones: transacciones ACID sobre almacenamiento de objetos, de modo que escritores concurrentes y jobs fallidos no pueden corromper una tabla.
2. Imposición de esquema y gobernanza: la capa de almacenamiento rechaza los datos que violan el esquema declarado en vez de aceptarlos en silencio.
3. Apertura: los formatos de almacenamiento son “abiertos y estandarizados, como Parquet”, de modo que motores distintos del que escribió los datos puedan leerlos.

Compara esas tres propiedades con las dos arquitecturas entre las que se sitúa el lakehouse:

La frase “permitir BI y ML sobre todos los datos” es todo el caso de negocio: los data warehouse obligan a elegir entre SQL gobernado y ML utilizable, y los lagos obligan a elegir entre almacenamiento barato y datos de confianza. El lakehouse elimina ambas elecciones al poner una gestión de tablas de nivel data warehouse directamente sobre el almacenamiento de lago.

1.1 El patrón medallion

Databricks documenta el diseño lógico estándar como la arquitectura medallion, “un patrón de diseño de datos usado para organizar lógicamente los datos en un lakehouse ... (desde las tablas de la capa Bronze ⇒ Silver ⇒ Gold)” (databricks.com/blog/what-is-medallion-architecture, 2022-03-09):

• Bronze: en bruto, solo inserciones, todo lo que llegó, con los metadatos de origen intactos.
• Silver: limpiado, deduplicado, conformado, una fila por entidad del mundo real.
• Gold: agregados de nivel de negocio y tablas anchas listas para BI, dashboards y feature stores.

Las capas son lógicas. Físicamente son tablas Delta corrientes en buckets S3 corrientes, separadas por nombres de catálogo o de esquema: por eso la lección 03 (Unity Catalog) y la lección 04 (transacciones de Delta) arrancan desde este diagrama.

• 📚 ¿Sabías que…? “Lakehouse” es una arquitectura, no un producto de Databricks. El propio post de nombramiento de Databricks de 2020 lo admite: “otros servicios gestionados como BigQuery y Redshift Spectrum tienen algunas de las funciones de lakehouse listadas arriba” (2020-01-30). Snowflake, Amazon Redshift, Microsoft Fabric y otros reivindican hoy funciones de lakehouse. El discriminador en este curso nunca es la palabra: es la combinación de un formato de tablas abierto en tu almacenamiento más una capa de gobernanza que abarca todos los motores.

---

2. Los dos pilares: Delta Lake y Unity Catalog

Todo lo que Databricks vende en AWS se apoya en dos proyectos de código abierto. El propio encuadre de Databricks de 2024 los empareja explícitamente: “fiabilidad de los datos ... Databricks proporciona Delta Lake” y “gobernanza simplificada ... con la ayuda de Unity Catalog” (databricks.com/blog/lakehouse-common-language-across-enterprise, 2024-06-21).

2.1 Pilar uno, Delta Lake: la capa de fiabilidad y formato

Delta Lake es la capa de almacenamiento de código abierto que añade transacciones ACID, imposición de esquema, time travel y gestión escalable de metadatos al almacenamiento de objetos, y es el formato de tablas por defecto en Databricks: “el cimiento del lakehouse” (databricks.com/blog/what-is-data-lakehouse, 2020-02-11). Físicamente es simple: un registro de transacciones write-ahead guardado junto a los archivos Parquet en tu bucket S3 (databricks.com/blog/2020/09/10/diving-deep-into-the-inner-workings-of-the-lakehouse-and-delta-lake.html, página actualizada 2024-06-20).

Lo que eso te compra, todo cubierto en la lección 04: commits serializables, upserts con MERGE, change data feed, time travel por versión o por timestamp, check constraints y evolución de esquema bajo reglas explícitas.

2.2 Pilar dos, Unity Catalog: la capa de gobernanza

Unity Catalog modela “cada recurso que gobiernas ... como un objeto securable”, cubriendo “tablas, vistas, volúmenes, funciones, modelos y servicios”, todos siguiendo “un espacio de nombres de tres niveles (catalog.schema.object)” (docs.databricks.com/aws/en/data-governance/unity-catalog, consultado 2026-10). Tres hechos dan forma a todo diseño de AWS que vayas a construir:

• El metastore es el securable de nivel superior y está acotado a una región de nube: “el metastore es el objeto securable de nivel superior ... Un metastore contiene todos los objetos securables registrados en Unity Catalog en una sola región de nube” (docs .../unity-catalog/securable-objects).
• Necesitas “un metastore para cada región en la que opere tu organización”, y “los usuarios deben estar en un workspace adjunto a un metastore de su región” (docs .../unity-catalog/create-metastore).
• Las concesiones viajan entre workspaces: “un privilegio concedido en un workspace es efectivo en todos los demás workspaces que comparten ese metastore” (misma fuente).
• En AWS, un storage credential es una IAM role: ahí es donde la gobernanza se encuentra con tu cuenta de nube (docs.../securable-objects).

Las tablas y los volúmenes son gestionados (Unity Catalog posee tanto la gobernanza como el ciclo de vida de los archivos) o externos (Unity Catalog gobierna; tú posees los archivos) (docs .../unity-catalog).

2.3 Por qué el emparejamiento importa en AWS

Delta responde “¿puedo confiar en estos bytes?” sin sacarlos de S3. Unity Catalog responde “¿quién puede leer qué bytes?” con un único modelo de concesiones que sobrevive a cambios de workspace, al acotamiento por región y a múltiples cuentas de AWS. Ninguno sustituye al otro: una tabla perfectamente ACID sin concesiones es una fuga sin gobernanza, y un catálogo perfectamente gobernado sobre archivos descuidados es una auditoría esperando a suspenderse.

---

3. Anatomía del workspace: el plano de control y el plano de cómputo

“Databricks opera a partir de un plano de control y un plano de cómputo” (docs.databricks.com/aws/en/getting-started/high-level-architecture, página actualizada por última vez 2026-09-11). Esta es la frase más testeable de la lección 01 y la que más a menudo distorsionan los ingenieros que solo han leído los blogs de ingeniería más antiguos de Databricks.

3.1 Los tres planos

• Plano de control (cuenta de Databricks). “El plano de control incluye los servicios backend que Databricks gestiona en tu cuenta de Databricks. El plano de control está ubicado en la cuenta de Databricks, no en tu cuenta de nube” (misma página, 2026-09-11). Ahí vive la web UI, los comandos y metadatos de los notebooks, el cluster manager, la orquestación de jobs y los metadatos de Unity Catalog: cifrados en reposo (databricks.com/blog/best-practices-and-guidance-cloud-engineers-deploy-databricks-aws-part-1, 2022-09-30).
• Plano de cómputo classic (tu cuenta). Los clusters y los SQL warehouses pro/classic se ejecutan como instancias EC2 “dentro de la red virtual de cada workspace, en la cuenta AWS del cliente”, lo que da al plano “aislamiento natural porque se ejecuta en la propia cuenta AWS de cada cliente” (docs .../high-level-architecture, 2026-09-11).
• Plano de cómputo serverless (cuenta de Databricks). “Databricks crea un plano de cómputo serverless en la misma región AWS que el plano de cómputo classic de tu workspace” y lo aísla “dentro de un límite de red del workspace” (misma página). La misma región que tu plano classic: no una región de Databricks arbitraria.

Material antiguo, incluidos los propios blogs de despliegue de Databricks de 2022 to 2023, dice plano de datos donde la documentación actual dice plano de cómputo. Mismo concepto, vocabulario de hoy. Si un tutorial dice “data plane”, se refiere al plano de cómputo classic/serverless descrito aquí.

3.2 Secure cluster connectivity: sin puertos abiertos, sin IPs públicas

“Todos los workspaces nuevos se crean con secure cluster connectivity activado por defecto. Secure cluster connectivity significa que las VPC de los clientes no tienen puertos abiertos y que los recursos del plano de cómputo classic no tienen direcciones IP públicas” (docs.databricks.com/aws/en/security/network/classic, actualizado 2026-09-25). Los clusters alcanzan el plano de control a través de un túnel seguro por el puerto HTTPS 443 hacia un relay SCC, y el tráfico siempre se inicia desde el plano de cómputo hacia fuera (databricks.com/blog/...part-1, 2022-09-30). No existe ninguna ruta de entrada que Databricks pueda abrir, porque no existe ninguna ruta de entrada en absoluto.

La consecuencia que los estudiantes se pierden: SCC no es “sin egress”. Los clusters todavía necesitan una ruta de salida, NAT gateway, internet gateway o PrivateLink, para alcanzar el plano de control y las APIs de AWS, y un endpoint de gateway de S3 mantiene el tráfico de S3 sobre la columna vertebral de AWS para que nunca se facture por el NAT (databricks.com/blog/optimizing-aws-s3-access-databricks, 2022-08-11). La lección 02 dimensiona esto correctamente.

3.3 La IAM role cross-account: cómo Databricks puede lanzar tu EC2

La creación de un workspace necesita tres configuraciones, credential (una IAM role cross-account), network (VPC/subredes/grupos de seguridad) y storage (el bucket de almacenamiento del workspace), y puede dirigirse desde la consola de cuenta, la Account API o Terraform (docs.databricks.com/aws/en/admin/workspace, 2026-07-28). La credential es un rol que creas en tu cuenta cuya política de confianza nombra a la cuenta AWS de Databricks: “crea una nueva IAM role cross-account con una política de acceso... En el campo Account ID, introduce el ID de cuenta de Databricks 414351767826” (docs.../create-uc-workspace; docs.../administration-guide/account-api/iam-role.html, 2026-01-24), con el ID de tu cuenta de Databricks como external ID. Requisitos previos en esa página: “tener una VPC y un NAT gateway disponibles en tu cuenta AWS, en la región del workspace”.

---

4. Dónde viven realmente los datos (y dónde no)

Un workspace classic tiene tres superficies de almacenamiento en tu cuenta AWS, y solo una de ellas es el lago:

Dos distinciones de la documentación oficial evitan los errores clásicos:

1. Datos del sistema del workspace frente a DBFS root. La documentación los separa explícitamente: “DBFS root es un sistema de archivos accesible por el usuario, mientras que los datos del sistema del workspace los usan internamente las funciones de Databricks”: incluso cuando ambos están en el mismo bucket. DBFS root y los montajes de DBFS son legacy y no se recomiendan para diseños nuevos (docs.../high-level-architecture, 2026-09-11).
2. Tablas gestionadas frente a externas. Los archivos de una tabla Delta gestionada viven donde Unity Catalog los puso (sigue siendo tu S3, bajo una ruta que UC gestiona); los archivos de una tabla externa viven en un prefijo que ya posees, y UC gobierna solo los metadatos. Ambas son “tus datos”: ninguna está en el bucket de almacenamiento del workspace.

Los workspaces serverless cambian la historia del almacenamiento del workspace (los datos del workspace van al almacenamiento predeterminado gestionado por Databricks), pero no cambian la historia del lago: las tablas analíticas siguen viviendo en tus buckets S3, alcanzados a través de Unity Catalog. La pregunta del plano de datos y la pregunta del almacenamiento son preguntas separadas.

• 📚 ¿Sabías que…? La terminología se ha desplazado dos veces. El blog de despliegue de Databricks de 2023 dice S3 root bucket; la documentación actual dice workspace storage bucket; y el “data plane” de esos mismos blogs es hoy el compute plane. Cuando leas un tutorial antiguo o un sitio de preparación de exámenes y use las palabras viejas, traduce: root bucket → workspace storage bucket, data plane → plano de cómputo classic/serverless. Los materiales didácticos que todavía presentan “data plane” como vocabulario actual de Databricks están citando posts de ingeniería de 2022 to 2023.

---

5. El mapa de cargas de trabajo: ingest → curate → serve → ML

El flujo de referencia de este curso, ensamblado a partir de la documentación de Auto Loader, medallion, Databricks SQL y MLflow:

1. Fuentes: Kafka/Amazon MSK, Kinesis, JDBC, APIs de SaaS y archivos aterrizan cargas útiles en bruto en un bucket de aterrizaje en S3.
2. Ingest: Auto Loader (cloudFiles) descubre de forma incremental los archivos nuevos y escribe tablas Delta bronze. “Procesa de forma incremental y eficiente los archivos de datos nuevos a medida que llegan al almacenamiento en la nube” y su almacén de estado clave-valor “asegura que los datos se procesan exactamente una vez” (docs.../auto-loader, página fechada 2026-04-01).
3. Curate: Lakeflow Spark Declarative Pipelines (el Delta Live Tables renombrado) o jobs corrientes limpian, deduplican y conforman hacia silver, y luego agregan hacia gold.
4. Serve: Databricks SQL sobre un warehouse serverless/pro/classic impulsa dashboards, el editor SQL, alertas y BI externo vía JDBC/ODBC. “Databricks SQL es un data warehouse en la nube construido sobre una arquitectura lakehouse. Se ejecuta directamente sobre tu data lake, admite ANSI SQL con extensiones de Delta Lake” (docs.../aws/en/sql/, actualizado 2026-09-11).
5. Learn: MLflow registra experimentos, y el Model Registry en Unity Catalog proporciona “control de acceso centralizado, auditoría, lineage y descubrimiento de modelos entre workspaces” (docs.../manage-model-lifecycle).
6. Govern: Unity Catalog cubre cada capa, con lineage y auditoría disponibles desde las system tables.

5.1 Mapeo de carga de trabajo → cómputo

Esta tabla es el núcleo práctico de la lección; toda decisión posterior de coste empieza aquí.

• 📚 ¿Sabías que…? El mismo código PySpark puede costar materialmente menos como job que como cluster interactivo. La guía de gestión de costes de Databricks enuncia el mecanismo directamente: “el mejor rendimiento junto con las tarifas por DBU más bajas que ofrecen los clusters de job conducen a un ahorro de costes drástico” (databricks.com/blog/best-practices-cost-management-databricks, 2022-10-18). Los clusters de job son efímeros y de propósito único; los clusters all-purpose se quedan calientes para los humanos. La brecha exacta de tarifas entre SKUs varía por región y nivel de plan: Databricks solo publica cifras de “desde” en sus páginas públicas de precios (consultadas 2026-10), así que revisa siempre tu propio contrato en lugar de memorizar una cuadrícula de un sitio de terceros.

---

6. Los dos medidores: tarifas DBU y la factura de AWS

“Una Databricks Unit (DBU) es una unidad normalizada de potencia de procesamiento en la Databricks Lakehouse Platform usada con fines de medición y precios” (databricks.com/product/pricing, consultado 2026-10), y el glosario la define como “unidades de capacidad de procesamiento por hora según el tipo de instancia de VM” (docs .../resources/glossary, actualizado 2026-08-15). Pagas DBUs por el procesamiento; AWS te factura por separado por el metal y la fontanería.

6.1 La tabla de tarifas, a octubre de 2026

Precios de lista, USD, consultados en 2026-10; varían según la nube, la región y el nivel de plan (AWS: Standard/Premium/Enterprise) y según el contrato. Databricks publica cifras de “desde” para jobs y SKUs interactivas: trata cualquier cuadrícula completa que encuentres en un sitio de costes de terceros como no verificada.

6.2 Ejemplo resuelto E1: un cluster de jobs de 4 nodos, ambos medidores

A oct 2026. Un job nocturno se ejecuta en un cluster de 4 nodos cuyo tipo de instancia se factura a 3 DBU/hora en el SKU de jobs.

Lectura: el lado DBU de un job nocturno de 8 horas es de $432/mes a la tarifa publicada de “desde” para jobs; el lado AWS es una segunda factura que tienes que sumar tú. Mismo código, SKU distinto: si esa carga de trabajo se dirigiera de forma interactiva a la tarifa interactiva de “desde” de $0.40/DBU, los mismos 2,880 DBU facturarían $1,152: una diferencia de 2.67× por un cómputo que hace la misma aritmética. Esa brecha es la razón por la que las cargas de trabajo de producción van en clusters de job y el BI va en warehouses.

6.3 Ejemplo resuelto E2: un mes de warehouse serverless, y el impuesto por inactividad

Un equipo ejecuta un SQL warehouse serverless 8 horas/día, 20 días/mes, con una media de 4 DBU/hora (el serverless auto-escala dentro de la hora; 4 DBU/h es una media plausible para un equipo pequeño: ajústala a tus propias cifras de system.billing.usage cuando llegues allí).

Lectura: la propia documentación de Databricks advierte que “los SQL warehouses inactivos siguen acumulando cargos de DBU y de instancia en la nube hasta que se detienen” (docs .../compute/sql-warehouse/create). Valores por defecto de auto-stop a oct 2026: pro/classic 45 minutos (mínimo 10), serverless 10 minutos (mínimo en la UI 5; la API puede fijar 1 minuto). Bajar el auto-stop de 45 minutos a 10 en un warehouse pro usado en sesiones de 30 minutos es un ahorro gratuito; dejar algo encendido 24/7 es la partida evitable más grande de todo un entorno de BI.

6.4 Ejemplo resuelto E3: la factura de almacenamiento bajo las mismas tablas

El propio almacenamiento del lago, para poner escala: 1 TB (1,024 GB) retenido un mes en S3 Standard a $0.023/GB-mes (aws.amazon.com/s3/pricing, consultado 2026-10) = $23.55/mes, más las peticiones PUT/GET (el GET de S3 Standard cuesta $0.0004 por cada 1,000 peticiones). Un entorno curado de gold de 10 TiB cuesta por tanto unos $235/mes solo por retenerlo: aproximadamente la mitad de lo que factura un único SQL warehouse serverless inactivo en la misma ventana (E2). El almacenamiento es la mitad barata de un lakehouse; la disciplina de cómputo es donde está el dinero.

---

7. La misma consulta, tres medidores: Databricks frente a la stack nativa de AWS

La alternativa nativa de AWS es una composición, no un producto: S3 para almacenamiento, Glue Data Catalog para metadatos/crawlers/ETL, Athena para SQL serverless, Redshift para un warehouse aprovisionado o serverless, Lake Formation para concesiones, QuickSight para BI. Precios, todos consultados en 2026-10:

7.1 Ejemplo resuelto E4: Athena frente a Databricks SQL para una carga de trabajo de dashboard

Un dashboard escanea 20 GB/día durante 22 días/mes.

Lectura: para un dashboard de BI ligero y con many escaneos, el medidor por TB de Athena es drásticamente más barato: ~$2.15 frente a ~$168. Ese es un resultado honesto, no un fallo de Databricks: el precio por byte castiga los escaneos pesados repetidos, el ETL, los joins, MERGE, el streaming y el ML, y premia las lecturas raras, anchas y ad hoc. La pregunta de diseño nunca es “qué motor es más barato” sino “qué medidor encaja con la forma de la carga de trabajo”. Exactamente por eso la lección 15 enseña la atribución de costes a través de system.billing.usage en lugar de benchmarks de proveedores.

7.2 Ejemplo resuelto E5: dimensionar la zona de aterrizaje

Un pipeline aterriza 500 GB/día de archivos en bruto en S3 Standard.

Lectura: $345/mes para retener un mes de datos de aterrizaje. Dos palancas dominan: retención (limpiar los archivos de origen después de que Auto Loader haga commit; las opciones cleanSource de la documentación existen exactamente para esto) y tamaño de archivo (miles de archivos diminutos inflan tanto las cargos por peticiones como la planificación de Delta). El almacenamiento es predecible; los lados de peticiones y de cómputo son donde los diseños fallan en silencio.

7.3 Las dos stacks, lado a lado

• 📚 ¿Sabías que…? La propia AWS documenta la interoperabilidad de Delta en lugar de tratarla como competencia: Athena “puede leer tablas de Delta Lake almacenadas en Amazon S3 directamente sin tener que generar archivos de manifiesto ni ejecutar la sentencia MSCK REPAIR” (docs.aws.amazon.com/athena/latest/ug/delta-lake-tables.html, consultado 2026-10): con los límites honestos de solo lectura, motor v3 y sin time travel. Glue, EMR y Redshift Spectrum también pueden procesar tablas Delta en S3 (databricks.com/blog/databricks-aws-guide-data-ai-summit-2023-featuring-labcorp-conde-nast-grammarly-vizio-ntt-data, 2023-06-23). Los formatos abiertos cortan en ambas direcciones: tu lago es portable, y los motores de tus competidores pueden leerlo.

---

8. El sustrato AWS que heredas (dimensionamiento resuelto)

La lección 02 va en profundidad; aquí está el marco. Los requisitos centrales de un despliegue estándar son “una VPC gestionada por el cliente, conectividad de plano de datos a plano de control, una IAM role cross-account y un root bucket S3” (databricks.com/blog/...part-2, 2023-01-27), y “para cada workspace debe haber un mínimo de dos subredes privadas dedicadas, cada una con una máscara de red entre /17 y /26, y en zonas de disponibilidad separadas” (misma fuente). La guía bien arquitecturada añade: “crea una VPC con un bloque CIDR mínimo /18 para despliegues de workspace” (docs.databricks.com/aws/en/lakehouse-architecture/security-compliance-and-privacy/best-practices, 2026-07-16).

8.1 Ejemplo resuelto E6: dimensionamiento de subredes para un workspace

Lectura: dos /24 en AZs separadas satisfacen la regla publicada con holgura. La restricción que realmente muerde es “dedicadas por workspace”: las subredes no se agrupan entre workspaces, así que cada workspace que creas consume sus propias dos subredes del CIDR de tu VPC. Planifica la VPC como /18 (según la guía bien arquitecturada) y podrás alojar varios workspaces antes de tocar el enrutamiento.

A oct 2026 existen tres arquitecturas de referencia de red de Databricks, Managed security, Hardened connectivity e Isolated environment, que difieren en la profundidad de PrivateLink, las listas de acceso por IP, los controles de egress serverless y el PrivateLink de entrada, mientras que secure cluster connectivity más una VPC gestionada por el cliente están presentes en las tres (docs.databricks.com/aws/en/security/network/deployment-architecture, consultado 2026-10). Observa también los límites por plan: la VPC gestionada por el cliente, la creación del metastore de UC y el SQL serverless todos requieren el plan Premium o superior (docs.../permissions, actualizado 2026-09-11; docs.../create-metastore; docs.../admin/sql/serverless).

---

9. Elegir la plataforma: Snowflake, y el Hadoop que estás dejando

9.1 Frente a Snowflake

Encuadre neutral, porque ambos proveedores publican páginas de comparación que se contradicen entre sí:

Ambas páginas hacen afirmaciones de rendimiento y de precio/rendimiento opuestas. Este curso trata cada una de ellas como una afirmación de proveedor con fecha, nunca como un hecho, y nunca cita un multiplicador cara a cara como algo que un estudiante deba memorizar. Elige Snowflake cuando la carga de trabajo es SQL/BI puro con concurrencia predecible y quieres la simplicidad del warehouse; elige Databricks cuando ML/AI, streaming, Python/Spark y la portabilidad de formatos abiertos son requisitos de primera clase; cada vez más, coexisten: la federación y Delta Sharing significan que los dos no se excluyen mutuamente (véanse las lecciones 12 y 17).

9.2 Frente a Hadoop on-prem (HDFS + YARN + Hive)

La guía de migración de Databricks es directa: “aunque migres cargas de trabajo heredadas de Hadoop on-premises a servicios gestionados en la nube como EMR ... seguirás tropezando con los mismos problemas de fiabilidad y escalabilidad” (databricks.com/solutions/migration/hadoop, 2023-09-03). El mapeo es mecánico:

Las habilidades y las inversiones de BI se trasladan precisamente porque los formatos siguen abiertos: no hay que reescribir el SQL para pasar de tablas estilo Hive a tablas gold respaldadas por Delta, y la lección 03 cubre esa ruta de migración (hive_metastore aparece como catálogo legacy de nivel superior).

9.3 La decisión, dibujada

El diagrama codifica tres reglas prácticas de esta lección: la portabilidad de formatos abiertos y las cargas de trabajo mixtas apuntan al lakehouse; solo SQL más preferencia por un solo proveedor apunta a la stack nativa de AWS; y un entorno Hadoop no se “levanta y se traslada”: se rediseña (por eso la lección 03 trata la migración de hive_metastore como una ruta de primera clase).

---

10. Por qué la apertura es un requisito de diseño, no un eslogan

Tres hechos concretos de interoperabilidad, cada uno oficial y cada uno fechado:

1. Tus datos son Parquet más un registro de transacciones de Delta en tu bucket S3: cualquier motor que entienda el formato puede leerlos sin exportarlos de un almacén propietario (databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html).
2. Lectores del lado de AWS: Athena lee tablas Delta registradas en el catálogo AWS Glue (solo lectura, motor v3, sin time travel: docs.aws.amazon.com/athena/latest/ug/delta-lake-tables.html, consultado 2026-10).
3. Lectores de terceros vía Unity Catalog: “a través de APIs abiertas y concesión de credenciales, Unity Catalog permite que motores externos como Trino, DuckDB, Apache Spark, Daft y motores integrados con Iceberg REST catalog, como Dremio, accedan a las tablas gestionadas” (docs .../tables/managed, 2026-08-18), a través de la Unity REST API y el Iceberg REST Catalog (IRC) (docs .../external-access/unity-rest, 2026-08-26).

El punto estratégico es del propio Databricks: un lakehouse propietario guarda los datos “en formatos que solo un proveedor puede leer”, mientras que los datos de un lakehouse abierto viven en “Delta Lake y Apache Iceberg ... sobre formatos de archivo abiertos como Apache Parquet” (databricks.com/blog/what-open-lakehouse-open-data-standards-explained, 2026-06-16). En AWS eso importa de una segunda manera: tú conservas los datos en tu cuenta, de modo que un cambio de motor, una disputa con el proveedor o una adquisición no se convierte en un proyecto de extracción de datos.

• 📚 ¿Sabías que…? El compartir también es abierto: Delta Sharing es un protocolo abierto (cubierto en la lección 12), mientras que Databricks Marketplace es el catálogo comercial construido encima. Como los archivos subyacentes son formatos abiertos, un share puede ser consumido por motores que no son Databricks: que es la respuesta práctica a “¿qué pasa con mi lago si algún día nos vamos?”.

---

11. Las trampas: once confusiones que este curso no te deja conservar

1. “Data plane” frente a “compute plane”. Lo mismo; la documentación desde 2026 dice plano de cómputo, dividido en classic y serverless. Los blogs antiguos dicen plano de datos.
2. El plano de control ≠ tu cuenta. Está en la cuenta AWS de Databricks, pero el bucket de almacenamiento del workspace en un workspace classic está en tu cuenta. Confundir los dos produce un modelo de amenazas equivocado.
3. El bucket de almacenamiento del workspace ≠ data lake. Solo datos del sistema; no se puede borrar; nunca se comparte entre workspaces; nunca se usa para datos de clientes.
4. DBFS root es legacy. Puede estar en el mismo bucket que los datos del sistema del workspace, pero “DBFS root es un sistema de archivos accesible por el usuario, mientras que los datos del sistema del workspace los usan internamente las funciones de Databricks” (docs.../high-level-architecture, 2026-09-11), y DBFS root/montajes no se recomiendan para diseños nuevos.
5. Los renombramientos son reales; verifica antes de enseñar o responder. Delta Live Tables → Lakeflow Spark Declarative Pipelines (docs .../ldp/concepts/where-is-dlt, 2026-01-23; nota de versión 2025-11-12) sin migración de código requerida y con los SKUs classic todavía empezando por DLT; SQL endpoints → SQL warehouses (2023); Model Registry del workspace → Models in Unity Catalog.
6. Dos facturas. DBU más tu factura de AWS; las tarifas serverless empaquetan instancias, las tarifas classic no.
7. SKU de jobs frente a all-purpose. El mismo código puede costar materialmente menos como job, la guía oficial lo dice (2022-10-18), pero la brecha exacta depende de la región y del contrato, así que revisa en lugar de memorizar.
8. Athena leyendo Delta ≠ soporte completo de Delta. Solo catálogo de Glue, motor v3, solo lectura, sin time travel.
9. El alcance del metastore es regional, no por workspace. Un metastore por región; hive_metastore es un catálogo legacy de nivel workspace.
10. Serverless es condicional. Se requiere plan Premium, y el cómputo serverless corre en la cuenta de Databricks en la misma región AWS que tu plano classic.
11. Los benchmarks de proveedores son marketing en ambas direcciones. Las páginas Databricks-vs-Snowflake y Snowflake-vs-Databricks hacen afirmaciones mutuamente contradictorias; cítalas solo como “afirmación de proveedor, sellada en fecha”.

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: Biogen (farmacéutica, Cloud: AWS) Desafío. La informática on-premises no podía escalar a petabytes de genómica: “un pipeline que antes requería 2 semanas para procesar 700,000 variantes”. Stack en AWS. Databricks for Genomics runtime con Delta Lake, junto a la plataforma DNAnexus en AWS: la página de la historia de cliente lleva la propia etiqueta Cloud: AWS de Databricks. Resultado reportado. “2 million Genomic variants analyzed in 15 minutes · 2 drug targets Discovered” (https://www.databricks.com/customers/biogen, página sin fecha, consultada 2026-10; origen de la historia 2020-11). Encaja con esta lección. L01: la migración a un lakehouse en la nube medida en semanas de cómputo eliminadas, no solo en dólares: el concepto de lakehouse y el pilar de formatos abiertos hicieron portable un entorno on-prem. ⏳ Nota temporal: una cifra de origen 2020; trátala como lo que Biogen reportó entonces, no como una garantía de plataforma de 2026.

📋 Caso B: Punchh / fidelización de minoristas (Cloud: AWS) Desafío. AWS MySQL superado, un data warehouse demasiado costoso, herramientas sin ACID, y informes de Tableau pagando un join de 12 tablas en cada actualización. Stack en AWS. Databricks SQL sobre Delta Lake bronze/silver/gold, notebooks, Tableau encima: Cloud: AWS en la página de la historia. Resultado reportado. “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; origen de la historia 2021-09). Cita. “Podemos almacenar datos en bruto así como datos refinados en el mismo lakehouse.”: Jagan Mangalampalli, Punchh (misma URL). Encaja con esta lección. L01 secundario: el diseño medallion de la sección 5 como control de coste: las tablas gold pre-unidas ganan a los joins de 12 vías en el momento del informe. ⏳ Nota temporal: reportado en 2021; las proporciones son de Punchh, no de un SLA de plataforma.

📋 Caso C: Rivian (vehículos eléctricos, Cloud: AWS) Desafío. Terabytes de datos de vehículos al día desde más de 70,000 vehículos, con herramientas heredadas que “luchaban por escalar pipelines de forma rentable” y equipos estancados que bloqueaban el ML de mantenimiento predictivo. Stack en AWS. Databricks SQL, Delta Lake, Unity Catalog y liquid clustering: Cloud: AWS en la página de la historia; el recopilatorio de 100 casos de uso nombra “Unity Catalog para la gobernanza de datos, Delta Tables para el almacenamiento y Liquid Clustering para la distribución de datos” en el ML de predicción de carga en tiempo real. Resultado reportado. “1,000+ platform users, a 75% increase from a year ago” (https://www.databricks.com/customers/rivian, página sin fecha, consultada 2026-10); “50% better runtime performance” (https://www.databricks.com/your-ai/customers/rivian, 2024-05-30); detalle de la stack en https://www.databricks.com/blog/data-intelligence-action-100-data-and-ai-use-cases-databricks-customers (2025-07-09). Encaja con esta lección. L01: un lakehouse gobernado en AWS que alimenta dashboards y ML de producción desde las mismas tablas, que es la afirmación de “copia única de datos” de la sección 1 hecha concreta. ⏳ Nota temporal: las métricas son de páginas de 2024 to 2025; sellalas con su fecha cuando las cites.

Veredicto comparativo: lakehouse frente a stack nativa de AWS, Snowflake y Hadoop on-prem

• Frente a un lago de datos puro (S3 + Parquet, sin capa de tablas): conservas el coste y la elasticidad pero pierdes ACID, imposición de esquema y time travel. Si nada falla, se sobrescribe nunca o se ejecuta de forma concurrente, un lago en bruto es más barato; en producción, el registro de transacciones de Delta es el seguro más barato de toda la stack.
• Frente a la stack nativa de AWS (S3 + Glue + Athena + Redshift + Lake Formation): la stack nativa de AWS gana para tiendas SQL-only, mayormente batch, estandarizadas en AWS que quieren un solo proveedor y medidores por uso ($5.00/TB en Athena, $0.44/DPU-hora en Glue). Databricks gana cuando necesitas una copia gobernada para SQL y Python/Spark y streaming y ML: al precio de un segundo proveedor, un medidor DBU y un plan Premium para el conjunto completo de funciones. Ambos se apoyan en el mismo S3, y AWS documenta la interoperabilidad de Delta en lugar de cercarla.
• Frente a Snowflake: Snowflake gana en simplicidad de SQL/BI puro y en cero trabajo de VPC; Databricks gana en ML/AI, streaming y portabilidad de formatos abiertos. No publiques ningún multiplicador cara a cara en un documento de diseño: las páginas de comparación de ambos proveedores son marketing sellado en fecha que contradice a la otra parte.
• Frente a Hadoop on-prem (HDFS + YARN + Hive): no es una contienda reñida en 2026, S3 reemplaza a HDFS, el cómputo elástico/serverless reemplaza a YARN, y Unity Catalog reemplaza al metastore de Hive, mientras que los formatos abiertos conservan tus activos de SQL y BI. La advertencia honesta: “aunque migres cargas de trabajo heredadas de Hadoop on-premises a servicios gestionados en la nube como EMR... seguirás tropezando con los mismos problemas de fiabilidad y escalabilidad” (2023-09-03), lo que estás cambiando es la arquitectura, no el alojamiento.

---

Preguntas de Práctica (Practice Questions)