Arquitectura de referencia del capstone: observabilidad, activación de ML y el plan de 90 días para Databricks en AWS

Dieciséis lecciones construyeron la máquina. La lección 01 te dio el concepto de lakehouse y la separación entre plano de control y plano de cómputo en AWS; la lección 02, el sustrato de VPC, bucket raíz, KMS y PrivateLink; la lección 03, el metastore de Unity Catalog y los external locations; la lección 04, el registro de transacciones de Delta y el liquid clustering; la lección 05, Auto Loader; la lección 06, DBR, Photon y la economía de los clusters; la lección 07, los pipelines declarativos de Lakeflow con expectations; la lección 08, los SQL warehouses de Databricks SQL y Lakeview; la lección 09, Lakeflow Jobs; la lección 10, los quality gates y la cuarentena; la lección 11, grants, vistas dinámicas y auditoría; la lección 12, Delta Sharing y Marketplace; la lección 13, Structured Streaming; la lección 14, rendimiento; la lección 15, coste en DBU; la lección 16, Declarative Automation Bundles y Terraform. Este capstone hace una sola cosa: esas dieciséis capas se ensamblan en una única arquitectura de referencia y después se añaden las dos capas que las lecciones anteriores solo esbozaron, la pila de observabilidad y una sección de ML gobernada, y se te entrega un plan secuenciado para construirlas de verdad.

La capa de observabilidad merece un cuidado especial, porque es donde los lakehouses de producción fallan en silencio. «System tables provide a Databricks-hosted analytical store of your account's operational data found in the system catalog», y «Las system tables son de uso gratuito; solo se te cobra por el cómputo que usas para consultarlas» (docs.databricks.com/aws/en/admin/system-tables, pie de página 8 oct 2026). Gratis no es lo mismo que automático: la retención se acumula desde la activación, el historial nunca se rellena hacia atrás, y las docs dicen sin rodeos que hay «No support for real-time monitoring. Data is updated throughout the day.» Cada dato de esta lección lleva su fuente de Databricks o de AWS y una fecha de octubre de 2026; todo lo que las docs no confirman se deja fuera o se marca explícitamente como elaborado por el curso.

En esta lección:

• modela la observabilidad como cinco planos distintos que se apoyan todos en Unity Catalog, más un sexto plano de conciencia del modelo, y aprende exactamente qué latencia carga cada plano;
• inventaría los nombres actuales de las system tables (referencia del 8 oct 2026), sus retenciones gratuitas y su latencia por tabla, y ejecuta un dashboard de auditoría de seis consultas sobre ellas;
• usa la monitorización de calidad de datos, detección de anomalías más data profiling, la familia de producto que absorbió «Lakehouse Monitoring», con sus indicadores de salud, incidentes y reglas de alerta;
• cierra el circuito con un runbook de alerta → incidente → replay, conectado mediante webhooks de jobs, reglas de alerta de DQM y SQL Alerts como código;
• dibuja el diagrama completo del capstone de extremo a extremo: VPC/S3/KMS de AWS, ambos planos de Databricks, Unity Catalog, pipelines de Lakeflow, serving de DBSQL, Delta Sharing y la pila de observabilidad en una sola página;
• secuencia una hoja de ruta de 30/60/90 días elaborada por el curso frente a las 10 fases de planificación de producción de Databricks, con una tarjeta de hitos que nombra la system table que prueba cada hito;
• sitúa a tu equipo en un modelo de madurez de cuatro etapas (ad hoc → gobernado → self-service → ML-ready) con criterios de salida;
• activa una sección de ML gobernada, modelos de MLflow en Unity Catalog, firmas, aliases, observabilidad de serving y de inference tables, respetando la frontera entre este curso y un curso dedicado de ML;
• estudia Rivian, Block y NAB en AWS, lee el recuadro de actualizaciones de octubre de 2026, mapea el curso sobre el blueprint de Data Engineer Associate y responde doce preguntas de estilo examen más cuatro comprobaciones interactivas.

---

1. Cinco planos de observabilidad, un plano de gobernanza

El error arquitectónico más común en esta capa es tratar la observabilidad como un producto que se «enciende». No lo es: son cinco planos con responsables distintos, privilegios distintos y, de manera crítica, latencias distintas. Los cinco se apoyan en Unity Catalog, y las propias system tables son securables gobernados por UC: «Los usuarios con los roles de account admin y metastore admin tienen acceso a las system tables por defecto… USE CATALOG sobre el catálogo system, USE SCHEMA sobre los schemas system y SELECT sobre los schemas system» (referencia de system tables, 2026-10-08). Todo el resto necesita esos grants de forma explícita, o una vista dinámica. La observabilidad se concede, no es ambiental.

Se siguen tres consecuencias, y cada una ha mordido a equipos de producción:

1. Los planos no se sustituyen entre sí. Las expectations y las constraints de Delta previenen escrituras malas en el momento de escribir (lección 10); la detección de anomalías detecta deriva a lo largo de un schema; el profiling mide y almacena métricas de deriva; las alertas de SQL y de jobs notifican. Privilegios distintos también: MANAGE sobre un schema para activar la detección de anomalías, SELECT sobre las tablas de métricas para construir alertas, CAN MONITOR sobre un warehouse para abrir el query profile de otro. Mezclarlo todo en «ya tenemos DQ» oculta qué capa falta.
2. La reacción a escala de minutos debe ser in-band. Las system tables se actualizan «throughout the day»: todo lo que deba dispararse en minutos es una política fail de expectations, un webhook de job, una regla de alerta de DQM o una SQL Alert dentro de un job, no un escaneo de system.access.audit.
3. La latencia es un dato de diseño, no trivia. Los registros del historial de consultas están «typically available within one hour» (referencia de historial de consultas, 2026-10-06); el uso facturable «typically available within 12 hours» para record_type = 'ORIGINAL' (referencia de facturación, 2026-09-15). Un dashboard de «anomalía horaria de coste» sobre system.billing.usage es un error de categoría: la tabla no puede sostenerlo.

📚 ¿Sabías que…? Los schemas antiguos system.operational_data y system.lineage están «descontinuados y contendrán tablas vacías» (referencia de system tables, 2026-10-08). Cualquier runbook, notebook o dashboard de un proveedor que siga apuntando a ellos está leyendo nada en silencio. Los hogares actuales son system.lakeflow.* para los timelines de jobs/pipelines y system.access.table_lineage / system.access.column_lineage para el lineage.

---

2. Plano 1: las system tables como plano de cuenta

2.1 El inventario que importa (verificado el 2026-10-08)

No necesitas todas las tablas del catálogo system el primer día: necesitas estas, con sus retenciones, para que tus dashboards y tus políticas de retención coincidan con la realidad:

Fuentes: referencia de system tables (2026-10-08); referencia de audit-logs (2026-07-01); referencia de historial de consultas (2026-10-06); referencia de facturación (2026-09-15); referencia de lineage (consultada 2026-10). La retención configurable existe en Beta, opt-in, 395 días por defecto, configurable de 30 a 3,650 días, pero «does not apply to system.data_classification, system.data_quality_monitoring, system.lakebase» (2026-10-08). Y ten en cuenta las advertencias de streaming si quieres hacer stream de las system tables hacia tus propias tablas Delta: DBR 16.4+ para hacer stream, 17.3+ para CDF, Trigger.AvailableNow en 18.0+, y los schemas de sistema usan «the default 7 days retention for VACUUM».

2.2 Ejemplo resuelto E1: el dashboard de auditoría de seis consultas

Este es el corazón de la lección: un solo dashboard de Lakeview, seis consultas, todas válidas frente a los schemas de arriba, desplegado como código mediante un bundle (lección 16). Ejecútalo cada semana; publícalo para un grupo platform-ops con USE CATALOG / USE SCHEMA / SELECT concedidos, o mejor, una vista dinámica por grupo (la propia recomendación de la página de historial de consultas).

Notas didácticas, cada una ganada a partir de una trampa documentada. Q1 es tu consulta de evidencia de cumplimiento: siempre predicada por event_date, porque la página de auditoría dice «To improve query performance, filter on event_date rather than event_time». Q3 es el puente desde la vista de flota hasta la vista de una sola consulta: haz clic en cualquier statement_id en la UI de Query History y aterrizarás en el query profile de esa sentencia. Q5 tiene que combinarse con una pieza de AWS Cost Explorer, porque system.billing.usage contiene cero gasto de AWS: ni EC2, ni S3, ni NAT (lección 15). Los escaneos sin filtro de cualquiera de estas tablas pueden chocar con la salvaguarda documentada: «System Table query returned too much data. Please repeat query with more selective predicates.». Y Databricks «highly discourages» exportar las system tables fuera de la plataforma: los datos «pueden exponer datos sensibles y poner tu despliegue en riesgo».

⚠️ ADVERTENCIA, la observabilidad añadida al final es observabilidad que empieza vacía. La retención se acumula desde la activación, y el historial nunca se rellena hacia atrás: un dashboard construido el día 200 tiene 200 días de datos; construido el día 400 sigue teniendo 200 días. La propia mejor práctica de la página de system tables (llevada a la Fase 9 de la guía de despliegue, 2026-09-11) es «Enable system tables for all metastores to capture comprehensive usage data» durante la cimentación, que es exactamente por lo que la hoja de ruta de 30/60/90 de la sección 8 pone la activación en los días 1 to 30, no en el día 89.

---

3. Plano 2: monitorización de calidad de datos (el producto que se comió a «Lakehouse Monitoring»)

3.1 Los nombres, de una vez por todas

Si un tutorial de 2024, una presentación de un proveedor o incluso un post del blog de Databricks de septiembre de 2026 dicen Lakehouse Monitoring, la respuesta de octubre de 2026 es: esa capacidad ahora es data profiling, una de las dos capacidades bajo data quality monitoring en Unity Catalog, siendo la otra la detección de anomalías (página de data-quality-monitoring, 2026-09-11: «Data profiling was formerly known as Lakehouse Monitoring»; página de producto, consultada 2026-10). Enseña el nombre nuevo, reconoce el antiguo, y sabe que incluso el material actual de Databricks se desvía: la guía de despliegue todavía titula una sección «Lakehouse Monitoring capabilities» (2026-09-11).

3.2 Detección de anomalías: a nivel de schema, aprendida y paciente

La detección de anomalías se activa en un schema o catálogo: «up to 50 schemas at a time» desde la UI del catálogo, requiriendo MANAGE, y «Databricks creates a background job that monitors tables for freshness and completeness» (página de anomaly-detection, 2026-10-09, Public Preview). Frescura: «If a commit is unusually late, the table is marked as stale.» Completitud: «Si el número de filas confirmadas en las últimas 24 horas es menor que el límite inferior de este rango, la tabla se marca como incompleta.» Los resultados aterrizan en system.data_quality_monitoring.table_results; los indicadores de salud (Healthy / Unhealthy / Training / Error / Excluded / Not enabled) aparecen en las páginas de tabla y en los nodos de lineage; y «Intelligent scanning prioritizes high-impact tables as determined by popularity and downstream usage»: apoyándose en el lineage y la certificación de UC, de modo que una organización que nunca certifica nada obtiene una monitorización más débil. Espera «Smart scanning might delay the population of health indicators for some tables by up to two weeks», incidentes que pueden asignarse («Assign to me» persiste 7 días) o descartarse («Not an issue»), y el pie de arma irreversible: «Cuando desactivas la detección de anomalías, el job de detección de anomalías y todas las tablas e información de detección de anomalías se eliminan. Esta acción no se puede deshacer.»

3.3 Data profiling: dos tablas de métricas, tres tipos de perfil

El profiling es por tabla y produce exactamente lo que un dashboard de deriva necesita: «Profiling creates two metric tables and a dashboard… The profile metric table contains summary statistics… The drift metrics table contains statistics related to the data's drift over time» (página de data-profiling, 2026-09-11). Las tablas de métricas son tablas Delta en un schema de UC que tú eliges. Tres tipos de perfil: time series (métricas a lo largo de ventanas basadas en el tiempo), inference (logs de peticiones del modelo) y snapshot («La tabla completa se procesa en cada refresco. El tamaño máximo de tabla de un perfil snapshot es de 4 TB»). Los perfiles de time series e inference «solo calculan métricas de los últimos 30 días». El profiling se ejecuta en cómputo serverless «pero no requiere que tu cuenta esté habilitada para el cómputo serverless», se factura como DBU serverless bajo billing_origin_product = 'DATA_QUALITY_MONITORING' (resultados desde febrero de 2026 en adelante) y, un alivio para conjuntos regulados, «Data quality monitoring does not modify any tables it monitors, nor does it add overhead to any jobs that populate these tables.»

3.4 Ejemplo resuelto E2: conectar la capa de alertado de extremo a extremo

Tres planos de entrada, un único vocabulario de destinos. (i) Webhook de job: un administrador configura un destino del sistema una vez (email, Slack, Microsoft Teams, PagerDuty o cualquier webhook); después cada job fija notifications.on_failure, con el tope de «a maximum of three system destinations for each notification event type» por job o por task (página de notificaciones de jobs, 2026-10-09). La carga útil es JSON estable:

(ii) Regla de alerta de DQM (Beta), con alcance catalog.acme o catalog.acme.sales, requiriendo MANAGE, entregando al mismo vocabulario de destinos cuando una tabla pasa a Unhealthy. (iii) SQL Alert como código, «Databricks SQL Alerts is Generally Available (GA), with more than 4,000 customers already using Alerts in production» (blog de Databricks, 2026-05-19); una alerta empaqueta «a SQL query, an evaluation condition, a schedule, and a set of notification destinations», es versionable en Git y desplegable mediante bundles/Terraform, y puede ejecutarse como una task SQL Alert de Lakeflow Job (Public Preview) cuyo resultado OK / TRIGGERED / ERROR compuerta la siguiente task vía run_if. Una comprobación de coste de monitorización que de verdad vas a ejecutar:

• 📚 ¿Sabías que…? La propia pila interna de fiabilidad de Databricks, RADAR, son los cuatro planos de esta lección ejecutándose en producción: métricas de fiabilidad → detección de anomalías SPOT (un modelo de streaming no supervisado que aprende «lo normal» de los últimos 14 días) → alertado → dashboards de causa raíz. Resultado publicado: «95% reduction in incident-discovery time, at over 90% precision» (blog de Databricks, 2026-09-19). El mapa de construcción de ese post, métricas en Delta, un detector entrenado con MLflow servido en un endpoint de Model Serving, recurrencias de Workflows, SQL Alerts, Genie para la causa raíz, todo desplegado como un único DAB, es este capstone, por dentro.

---

4. Planos 3 to 5: pipelines, cargas de trabajo y rendimiento de consultas

4.1 El event log del pipeline, y el borrado que rompe Auto Loader

Los pipelines de Lakeflow exponen tres superficies de observabilidad anidadas: la UI (página de monitoring, grafo, métricas del dataset, pestaña Data quality); el event log por pipeline, una tabla Delta oculta legible vía SELECT * FROM event_log(<pipelineId>) y publicable hacia una tabla de UC con nombre; y la system.lakeflow_pipeline_events_preview.pipeline_events de ámbito regional (Beta), a la que las docs ahora llaman «the recommended way to query events», con un JSON de dashboard de Lakeview listo para importar en la página de monitoring (fechada 2026-10-09). Los resultados de las expectations viajan en los eventos flow_progress: details:flow_progress.data_quality.expectations es un array<struct<name: string, dataset: string, passed_records: int, failed_records: int>>. Atribución de coste de un pipeline: SELECT sku_name, sum(usage_quantity) FROM system.billing.usage WHERE usage_metadata.dlt_pipeline_id = :pipeline_id GROUP BY 1.

⚠️ IMPORTANTE, nunca borres el event log de un pipeline. «La ubicación del event log también sirve como ubicación del schema para las consultas de Auto Loader de la pipeline… No borres el event log ni el catálogo o schema padre» (página de event log del pipeline, 2026-10-09). Borrarlo no solo hace perder el historial, rompe las futuras actualizaciones, porque el estado exactly-once de Auto Loader vive ahí (lección 05).

Un matiz operativo que merece entrar en tus runbooks: las actualizaciones por trigger iniciadas desde la UI/API usan «fast-start, debugging-focused behavior», mientras que «Las actualizaciones iniciadas desde Jobs o la API de Pipelines, y todas las actualizaciones de pipelines continuas, usan reintentos y reinicios automáticos»: que es exactamente por lo que los pipelines de producción deben lanzarse desde un job (lección 09), no desde la UI.

4.2 Notificaciones de jobs: la capa de paginación, con dos trampas documentadas

Las notificaciones de jobs cubren inicio, finalización correcta, fallo, umbral de duración, umbral de backlog de streaming y eventos de mantenimiento continuo, entregadas a email o a destinos del sistema configurados por el administrador (Slack, Teams, PagerDuty, webhook), con un máximo de tres destinos por tipo de evento por job o por task. Los códigos event_type de los webhooks son estables: jobs.on_start, jobs.on_success, jobs.on_failure, jobs.on_duration_warning_threshold_exceeded. Las alertas de backlog de streaming evalúan «average backlog over a 10-minute period» y vuelven a notificar después de 30 minutes. Las trampas: «Job-level notifications aren't sent when failed tasks are retried» (silenciado hasta el último retry, o usa notificaciones a nivel de task), y «Succeeded with failures» cuenta como éxito. Para poner escala: un workspace está limitado a 2,000 task runs concurrentes, puede guardar hasta 12,000 jobs, crear 10,000 jobs por hora, y un solo job puede contener hasta 1,000 tasks (visión general de Lakeflow Jobs, 2026-10-09).

4.3 Query profiles: el plano por sentencia

Para los SQL warehouses y el cómputo serverless, el query profile es el diagnóstico por sentencia: DAG de operadores con Time spent / Memory peak / Rows, un panel de Top operators, Performance insights ordenados «by their projected effect on total task duration», y reescrituras asistidas por Genie Code presentadas para tu aprobación (página de query-profile, 2026-09-11). El acceso es un hecho de permisos con consecuencias reales de organización: «debes ser el propietario de la consulta o tener al menos el permiso CAN MONITOR sobre el SQL warehouse que ejecutó la consulta». No existen perfiles para consultas de cache-hit, y la exportación/importación del JSON del perfil no persiste. Las cargas de trabajo en clusters classic usan la Spark UI en su lugar: la Fase 9 de la guía de despliegue enuncia la división sin rodeos: «Para cómputo serverless y warehouses de SQL, usa el query profile… Para clusters de cómputo clásicos, usa la Spark UI». La Q3 de E1 es la vista de flota en system.query.history; el profile es la vista de una sola consulta; statement_id las une.

El cuerpo del runbook, cada paso nombrando su herramienta: 1. Detectar desde cualquiera de los tres planos. 2. Clasificar frescura frente a completitud frente a pico de failed_records en expectations frente a fallo de cómputo. 3. Delimitar con system.access.table_lineage / column_lineage. 4. Causa raíz en pipeline_events (error.exceptions[0].error_class) y en el array de expectations. 5. Reparar en dev mediante un PR de DAB (lección 16). 6. Replay de forma idempotente: el repair de un job re-ejecuta solo los subconjuntos fallidos/saltados; Auto Loader reproduce desde el prefijo de aterrizaje exactamente una vez. 7. Validar y cerrar, dejando espacio para hasta dos semanas de retraso en el escaneo de indicadores de salud, y escribe el nuevo umbral de vuelta en el runbook (Fase 9: «Document runbooks for common operational scenarios», 2026-09-11).

---

5. Plano 6: la sección de ML: la gobernanza primero, los algoritmos en otra parte

5.1 La línea divisoria, dicha una sola vez

Este curso es dueño del sustrato de lakehouse sobre el que corre el ML: UC como plano de gobernanza para modelos y features (nombres de tres niveles, grants, aliases, lineage), la observabilidad de inference tables y de serving endpoints como el mismo patrón de observabilidad aplicado a los modelos, y dónde se sitúan los artefactos de ML en la arquitectura de referencia. Un curso dedicado de ML es dueño de los algoritmos, la metodología de entrenamiento y de hiperparámetros, AutoML, la disciplina de experiment tracking, el diseño de feature engineering, el desarrollo de LLM/agentes, la redacción de políticas de AI Gateway y el ajuste del rendimiento en despliegue. La división limpia: enseñamos la gobernanza y la observabilidad de los modelos, no cómo construirlos.

5.2 Modelos en Unity Catalog: la mecánica verificada

«Models in Unity Catalog, which Databricks recommends» (página de model-lifecycle, 2026-10-09) es «a hosted version of MLflow Model Registry in Unity Catalog… including centralized access control, auditing, lineage, and model discovery across workspaces». Mecánica que hay que tener dominada:

• el URI de registro por defecto en MLflow 3 es databricks-uc; los modelos reciben nombres de tres niveles <catalog>.<schema>.<model>;
• los modelos son un subtipo del securable FUNCTION: se conceden con GRANT ON FUNCTION, se crean con GRANT CREATE MODEL ON SCHEMA, se usan con EXECUTE;
• «Las nuevas versiones de modelos ML en UC deben tener una signature de modelo»; sin ella pierdes la validación de entrada, el uso de funciones de AI y los ejemplos de entrada de serving autogenerados;
• los aliases reemplazan a los stages: «Los stages no se admiten para modelos en Unity Catalog»: una referencia nombrada mutable como Champion es el mecanismo de promoción;
• la promoción entre entornos se hace «by deploying ML pipelines as code» (preferido) o copy_model_version() (MLflow 2.8.0+);
• el lineage tabla→modelo vía mlflow.log_input (MLflow 2.11.0+) se muestra en la pestaña Lineage de la versión del modelo en Catalog Explorer;
• no soportado en modelos de UC: webhooks, notificaciones por email, hilos de comentarios, el registro de actividad: usa audit logs y compuertas de CI en su lugar.

Emparejamiento de versiones de MLflow por runtime (notas de versión, 2026-09-11): DBR 19 → MLflow 3.12.0; 18 LTS → 3.8.1; 17.3 LTS → 3.0.1; 16.4 LTS → 2.21.3.

5.3 Ejemplo resuelto E3: la sección de activación de ML con la gobernanza primero

Veinte líneas que cumplen cada regla de UC de arriba, y después observa el modelo como si fuera datos:

Grants: GRANT CREATE MODEL ON SCHEMA acme.ml TO el principal de entrenamiento; GRANT EXECUTE ON FUNCTION acme.ml.churn_model TO los consumidores. Observabilidad: una inference table registra predicciones para el análisis de deriva; system.serving.endpoint_usage (retención de 90 días, el seguimiento de uso debe activarse) y system.serving.served_entities dan la vista de flota; system.mlflow.runs_latest / run_metrics_history (180 días) llevan la telemetría de entrenamiento. El propio Model Serving es una superficie REST serverless que «puede soportar más de 25K consultas por segundo con una latencia adicional de menos de 50 ms» (página de model-serving, 2026-10-06): con dos advertencias para las que debes diseñar: los datos de métricas solo se retienen 14 días (logs de construcción de contenedores, 30 días), y «Model Serving does not provide security patches to existing model images because of the risk of destabilization to production deployments». Feature Store está actual y es UC-first: las Feature Views (declarativas, Public Preview, recomendadas) y las feature tables se publican ambas en el Online Feature Store con joins point-in-time que matan el desajuste entre entrenamiento y serving; Workspace Feature Store está obsoleto.

📚 ¿Sabías que…? Databricks anunció Genie ZeroOps el 2026-06-16: «an autonomous background agent that monitors your data and AI assets… and takes action before or when things go wrong», con validación de las correcciones propuestas mediante shallow clone sobre datos reales sin tocar producción. Su disponibilidad declarada en el anuncio era «entering private preview in the coming weeks»; esta lección lo cita solo como una dirección anunciada de viaje para la capa de runbook, nunca como una capacidad de la que puedas depender hoy.

---

6. El capstone completo: AWS + Databricks de extremo a extremo

Aquí está todo el curso en una sola página. Léela de arriba abajo: las fuentes a la izquierda de tu mente, el almacenamiento en la cuenta de AWS del cliente, la gobernanza en Unity Catalog, los pipelines medallion en el centro, el serving y el sharing a la derecha, la observabilidad envolviendo todo, y los dos medidores de facturación (la factura de AWS frente a los DBU) que la lección 15 te enseñó a no confundir jamás.

6.1 Ejemplo resuelto E4: la lista de comprobación de 17 componentes

Cada componente de abajo se construyó en una lección anterior; la columna de «prueba» nombra la system table o el artefacto que demuestra que existe. Esta es la tabla que revisas en el día 90.

---

7. 30/60/90 días: una hoja de ruta del curso sobre las 10 fases de Databricks

📌 Nota de procedencia. No existe ningún calendario de adopción de «30/60/90 días» publicado por Databricks; el calendario de abajo es una síntesis del curso anclada a la secuencia oficial de planificación de producción de 10 fases (página de deployment-guide, 2026-09-11: cuya propia página introductoria dice 9 fases en otro lugar; nosotros enseñamos la tabla de 10 fases, la página que de verdad enumera las fases). Los nombres de las fases son de Databricks; los días son nuestros.

Días 1 to 30: Cimentación (fases 1 to 5: cuenta, estrategia de workspace, Unity Catalog, red, almacenamiento). Cuenta + metastore en pie; SSO/SCIM; un metastore por región; buckets S3 raíz + externos con KMS; storage credential + external location para el prefijo de aterrizaje; workspaces dev/prod; un módulo de Terraform para los recursos a nivel de cuenta; system tables activadas; USE CATALOG / USE SCHEMA / SELECT concedidos a un grupo platform-ops. Hito: una primera tabla bronze de Auto Loader aterriza en S3 a través de una external location, es consultable en UC, y system.access.audit devuelve filas para ella.

Días 31 to 60: Pipeline + calidad (fases 6 to 8: Delta Lake, IaC, cómputo). Pipeline de Lakeflow bronze→silver→gold con expectations y una tabla de cuarentena; constraints de Delta en silver; job multi-task con compuertas run_if, retries, run_as con service principal; DABs desplegando targets dev/prod; cluster policies + instance pools + auto-stop; un warehouse serverless de DBSQL con auto-stop; detección de anomalías activada en el schema silver y un perfil time series en la tabla gold de KPI; un webhook jobs.on_failure al canal del equipo. Hito: un archivo corrompido a propósito dispara métricas de expectation → cuarentena → el estado de DQM cambia → se dispara el webhook, de extremo a extremo, en un drill de game day.

Días 61 to 90: Operar + extender (fases 9 to 10: observabilidad, HA/DR). Un dashboard «Ops» de Lakeview sobre system.lakeflow.job_run_timeline, system.query.history, system.billing.usage y pipeline_events; SQL Alerts para los KPI de frescura/recuento con versionado en Git/DAB; el dashboard de auditoría de E1 revisado cada semana; runbooks publicados (sección 4.3); política de retención de backup/time travel + VACUUM documentada; atribución de coste por tag con <5% de gasto sin etiquetar. Hito: la guardia resuelve una página usando solo el dashboard de ops y un runbook.

7.1 Ejemplo resuelto E5: la tarjeta de hitos

7.2 Ejemplo resuelto E6: un boceto del coste mensual de observabilidad

Las system tables son gratuitas; las consultas y los dashboards no. Supón un warehouse de ops (serverless, $0.70/DBU de lista, página de precios de SQL consultada 2026-10) ejecutando el dashboard de E1 más triaje ad-hoc 2 horas/día × 20 días/mes a ~4 DBU/hora: 160 DBU × $0.70 = $112/mes por el lado de Databricks, más cero almacenamiento para las propias tablas. Añade un perfil snapshot sobre una tabla gold de 500 GB (bajo el tope de 4 TB) y detección de anomalías sobre dos schemas, ambos se facturan como DBU serverless bajo billing_origin_product = 'DATA_QUALITY_MONITORING'; la tarifa no se publica, así que mide las cantidades en system.billing.usage y ponles precio frente a tu acuerdo empresarial en lugar de asumir una tarifa de lista. Por el lado de AWS, no añadas nada más allá del almacenamiento de S3 ya contado en la lección 15 ($0.023/GB-mes) y el tráfico de NAT de tu VPC. La lección de diseño: el plano de observabilidad es un error de redondeo al lado del plano de pipelines, siempre que el auto-stop esté activo y el warehouse del dashboard no se quede con los valores por defecto de 45 minutos sin nadie mirándolo.

---

8. El modelo de madurez: ad hoc → gobernado → self-service → ML-ready

📌 Nota de procedencia. No existe ninguna página oficial de «modelo de madurez» de Databricks; las cuatro etapas son un constructo del curso mapeado sobre funciones verificadas, con las recomendaciones de la Fase 9 y el post de productos de datos de septiembre de 2026 como el lenguaje oficial de apoyo más cercano.

Cada criterio de salida es observable en una system table o en un objeto de UC, que es justo el punto. La etapa 2→3 está bloqueada por el diseño de organización (propiedad de los catalogs, MANAGE delegado, contratos de datos), no por la falta de funciones; los equipos que instalan DQM sin propietarios reciben alertas que nadie contesta, que es peor que no tener alertas. La etapa 3→4 requiere un lineage que abarque tabla → feature → modelo, que solo existe si el entrenamiento usó mlflow.log_input y las features están registradas en UC. El post de productos de datos de Databricks del 2026-09-03 prescribe «data contracts upfront that include quality metrics, schema definitions, usage policies and security parameters» más una fase de «Operate and Govern», el vocabulario de la Etapa 3, con las propias palabras de Databricks.

---

9. Síntesis del curso: lecciones 01 to 16 mapeadas al blueprint de Data Engineer Associate

El último acto académico del capstone es conectar este curso con la credencia para la que más directamente te prepara. La guía de examen de referencia de la Databricks Certified Data Engineer Associate está fechada el 4 may 2026: 45 preguntas de opción múltiple puntuadas, 90 minutos, $200, válida 2 años, con el blueprint de siete dominios de abajo (página de certificación y PDF de la guía de examen, consultados 2026-10-12). Observa el cambio de marca que absorbió la guía de 2026: la redacción de audiencia más antigua, «Databricks Workflows», es ahora «Lakeflow Jobs».

9.1 Ejemplo resuelto E7: mapeo curso → dominio DEA

Dónde se detiene el curso y empieza la Data Engineer Professional (59 ítems, 120 min, los mismos $200, diez dominios): el dominio más pesado de DEP, «Developing Code for Data Processing» con un 22%, más el triage sistemático de fallos y la teoría de modelado, están aquí a nivel de conciencia, este curso demuestra patrones de producción; DEP asume la propiedad de producción (guardias, backfills, incidentes de rotura de esquema, sobrecostes). La acreditación gratuita AWS Platform Architect (20 preguntas, tiempo ilimitado, 80% para aprobar, válida 1 año) es la contraparte del lado del sustrato y cubre exactamente el terreno de la lección 02: «Customer-managed VPCs · Customer-managed keys · Cloud service integrations». Línea de presupuesto a oct 2026: un intento de certificación = $200, sin repeticiones gratuitas, espera de 14 días entre intentos; las insignias (Fundamentals, acreditaciones) son gratuitas, 10 to 25 preguntas, 80% para aprobar, vía Accredible, no Credly.

---

Veredicto comparativo: Databricks-on-AWS frente a AWS nativa frente a Snowflake (final, a oct 2026)

• Databricks en AWS, convergencia. Una capa de almacenamiento (S3 + Delta, lección 04), una capa de gobernanza (UC, lecciones 03/11), una capa de observabilidad (system tables + DQM + logs de eventos, esta lección), una capa de orquestación (Lakeflow Jobs, lección 09), un mecanismo de entrega (DABs/Terraform, lección 16), un registro de modelos (modelos en UC). El inventario de panel único más amplio de esta comparación, y las tablas son gratuitas, solo pagas el cómputo de consulta. El coste honesto: un segundo proveedor, el medido de DBU encima de tu factura de AWS, y un inventario de observabilidad que es tan bueno como tus grants, tus etiquetas y tu disposición a ejecutar el dashboard cada semana.
• AWS nativa (S3 + Glue + Athena + Lake Formation + QuickSight + CloudWatch/CloudTrail), ensamblaje. Cada capacidad de arriba es un servicio aparte que tienes que cablear: Glue Catalog y crawlers ($0.44/DPU-hora), Athena SQL serverless ($5.00/TB escaneado, mínimo de 10 MB por consulta), Lake Formation para los grants, CloudTrail como plano de auditoría. Encaja con tiendas solo SQL, mayormente batch, que no quieren un proveedor de plataforma y quieren control de facturación por servicio. Debilidades con las que este curso se fue tropezando: ni una historia de MERGE/CDF ACID tan rica como la de Delta, batch y streaming son toolchains distintas, el ML vive en otro producto (SageMaker), y el plano de auditoría es CloudTrail, no tablas de gobernanza consultables en SQL dentro del mismo catálogo que tus datos. La propia AWS documenta la interoperabilidad de Delta (Athena lee Delta registrado en Glue, solo lectura, motor v3, sin time travel), así que la puerta de salida es real.
• Snowflake, la abstracción de warehouse. Formato de almacenamiento propietario, buena concurrencia SQL/BI, operativa mínima, observabilidad en gran medida vía ACCOUNT_USAGE más su suite propia de calidad de datos dentro de una sola abstracción de warehouse. Elígelo cuando la carga de trabajo sea SQL/BI puro con concurrencia predecible y quieras la simplicidad del warehouse. Es más débil cuando ML/AI, Python/Spark, ingestión streaming y portabilidad de formatos abiertos son requisitos de primera clase, y ambos proveedores publican cifras de páginas de comparación mutuamente contradictorias (trátalas todas como afirmaciones de marketing selladas en fecha, nunca como hechos).
• Veredicto en una línea: Databricks-on-AWS es la decisión acertada cuando una única copia gobernada de los datos debe servir a BI, streaming y ML con observabilidad consultable en SQL; AWS nativa es la decisión acertada cuando quieres facturación por servicio y aceptas ensamblar los planos tú mismo; Snowflake es la decisión acertada cuando la carga de trabajo es solo SQL y quieres la superficie operativa más simple posible, y los casos de estudio de abajo muestran a clientes reales de AWS que eligieron la primera opción precisamente por esa convergencia.

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: Rivian (vehículos eléctricos, fabricación, Cloud: AWS) Desafío. Terabytes de datos de vehículos y de campo al día a través de más de 70,000 vehículos; herramientas de nube heredadas que «struggled to scale pipelines cost-effectively and spent significant resources on maintenance»; equipos en silos que bloqueaban el ML de mantenimiento predictivo y de eficiencia de baterías. Stack en AWS. Databricks SQL, Delta Lake, Unity Catalog, Agent Bricks / Mosaic AI, Liquid Clustering: Cloud: AWS en la página de historia de cliente. Resultado reportado. «1,000+ platform users, a 75% increase from a year ago» y «Unity Catalog gives us a truly centralized data catalog across all of our different teams» (https://www.databricks.com/customers/rivian, sin fecha, consultada 2026-10); «50% better runtime performance»; «Más de 70,000 Rivians en circulación, generando terabytes de datos cada día» (https://www.databricks.com/your-ai/customers/rivian, 2024-05-30); «Unity Catalog for data governance, Delta Tables for storage, and Liquid Clustering for data layout» para el ML de predicción de carga en tiempo real (https://www.databricks.com/blog/data-intelligence-action-100-data-and-ai-use-cases-databricks-customers, 2025-07-09). Encaja con esta lección. Secciones 5 to 6: Rivian es el ejemplo nombrado de AWS en el capstone: un lakehouse gobernado que alimenta dashboards y ML de producción, con liquid clustering (lecciones 04/14) bajo las feature tables y UC (lección 11) como catálogo único para todos los equipos. ⏳ Nota temporal: las cifras de la página de historia se consultaron en oct 2026; las métricas de los posts de 2024 y 2025 son resultados reportados en su momento, no garantías de 2026.

📋 Caso B, Block (Square, Cash App, TIDAL, servicios financieros, Cloud: AWS) Desafío. 12PB de datos de grafo + analítica fragmentados entre unidades de negocio; un flujo de IAM doloroso de dos pasos (políticas a roles, y después a buckets de S3); gobernanza de PII de GDPR/CCPA. Stack en AWS. Databricks, Delta Lake, Unity Catalog, Spark Declarative Pipelines, Delta Sharing (clean rooms planificadas); S3 como almacenamiento co-localizado: Cloud: AWS. Resultado reportado. «12X Reduction in compute cost · 20% Reduction in data egress cost · 12PB Of data managed and governed»; el tiempo de permiso de intercambio de datos recortado «from days to seconds»; «the adoption of Unity Catalog promoted the collection of data into S3 buckets, resulting in improved latency and the co-location of compute and storage» (https://www.databricks.com/customers/block/unity-catalog, sin fecha, consultada 2026-10). Encaja con esta lección. Secciones 2 y 6: Block es la prueba de gobernanza y coste: UC reemplazó a una herramienta de gobernanza y a un tramo del cableado de IAM/S3, y el dashboard de auditoría de E1 es la superficie operativa que mantiene respondible a un conjunto de 12PB. ⏳ Nota temporal: página sin fecha, consultada oct 2026: resultados de cliente reportados, no benchmarks de la plataforma.

📋 Caso C: National Australia Bank (banca, Cloud: AWS) Desafío. Un almacén Teradata de 26 años con ~1,000 casos de uso y 140 suites de reporting; ETL escrito a mano con hasta 64 union-all por pipeline a través de 300 to 400 ingenieros. Stack en AWS. Databricks SQL, Auto Loader, Spark Declarative Pipelines sobre Lakeflow, Unity Catalog (lineage, enmascaramiento, control de acceso), asset bundles para CI/CD: Cloud: AWS. Resultado reportado. «26-year-old Teradata warehouse decommissioned · 456 Use cases migrated to Databricks SQL · 1,200+ Users enabled» (https://www.databricks.com/customers/nab/dbsql, sin fecha, consultada 2026-10); «1,800 Spark Declarative Pipelines running on Databricks Lakeflow · 99.6% Job success rate · 80% Less transformation complexity», latencia «under 15 minutes», calidad de datos «+38%» (https://www.databricks.com/customers/national-australian-bank-nab, sin fecha, consultada 2026-10). Encaja con esta lección. Secciones 6 to 7: una tasa de éxito de jobs del 99.6% a través de 1,800 pipelines es lo que la capa de carga de trabajo (lección 09) más el runbook de alerta→replay (sección 4.3) se ven a escala de banco nacional; es el hito del día 90 de esta hoja de ruta, logrado por un equipo real. ⏳ Nota temporal: páginas de historia de cliente sin fecha, consultadas oct 2026: resultados reportados en el momento de la historia.

---

---

Preguntas de Práctica (Practice Questions)

Lee las barras como una asignación de estudio, no como trivia: Transformación (22%) más Ingestión (21%) más Lakeflow Jobs (16%) es el 59% del examen, las lecciones 04, 05, 07, 09, 13 y 14 son tu camino mayoritario, mientras que Gobernanza (15%) es donde la profundidad específica de AWS de este curso (storage credentials frente a instance profiles, KMS, PrivateLink, tablas de auditoría de UC) te diferencia de un candidato genérico de Spark.