Databricks — Fundamentos, Arquitectura, Delta Lake, Unity Catalog, Spark, SQL, Pipelines, Machine Learning, Rendimiento, Seguridad y DevOps

Q1. ¿Qué es Databricks y para qué tipo de soluciones se usa?

Databricks es una plataforma de datos e IA en la nube, construida sobre Apache Spark y el paradigma lakehouse, que unifica ingeniería de datos, analítica SQL, ciencia de datos y machine learning sobre un único almacenamiento abierto. Ofrece workspaces gestionados con notebooks colaborativos, clusters elásticos, SQL warehouses, Delta Lake, Unity Catalog para gobierno, pipelines declarativos, orquestación, MLflow y servicios de IA generativa. Se usa en banca, seguros, retail, salud, telecomunicaciones y sector público para construir lagos de datos gobernados, ETL/ELT a escala, analítica en tiempo real, feature engineering, modelos predictivos y aplicaciones RAG sobre datos corporativos.

Q2. ¿Qué es el lakehouse y cómo se diferencia de un data lake y de un data warehouse?

• Data lake: almacenamiento barato y flexible (S3, ADLS, GCS) con formatos abiertos, pero sin transacciones, esquema fuerte ni gobierno consistente; tiende a convertirse en un pantano de datos.
• Data warehouse: esquema y SQL muy optimizados para BI, pero costoso para datos crudos, semiestructurados o cargas de ML, y con formatos propietarios.
• Lakehouse: capa de almacenamiento abierto (Parquet + Delta Lake) con una capa de metadatos y transacciones que aporta ACID, esquema, time travel, gobierno y rendimiento de warehouse, permitiendo BI y ML sobre los mismos datos sin duplicarlos.

Q3. ¿Cuál es la historia y evolución de Databricks?

Databricks nació en 2013 de la mano de los creadores de Apache Spark (UC Berkeley AMPLab) para comercializar Spark como servicio. En 2019 abrió el código de Delta Lake, que aportó transacciones ACID al data lake; en 2021 publicó el paper del lakehouse y lanzó SQL, Unity Catalog y Photon. La compañía creció con servicios gestionados en AWS, Azure y Google Cloud, la suite de MLflow y Mosaic AI, y adquisiciones como MosaicML (2023), Tabular (2024) y Neon (2025) para reforzar IA generativa, interoperabilidad con Iceberg y bases de datos serverless. Su propuesta actual abarca todo el ciclo del dato: ingesta, ingeniería, analítica, ciencia de datos, IA generativa y gobierno.

Q4. ¿Cuáles son los componentes principales de la plataforma?

• Workspace: entorno colaborativo con notebooks, repositorios Git, SQL editor, jobs, dashboards y permisos.
• Compute: clusters interactivos, clusters de jobs, SQL warehouses, pools y opciones serverless.
• Delta Lake: formato transaccional abierto sobre el almacenamiento del cliente.
• Unity Catalog: metastore y gobierno unificado de tablas, vistas, volúmenes, funciones, modelos y conexiones, con privilegios, linaje y auditoría.
• Lakeflow: ingesta (Connect), pipelines declarativos y jobs/orquestación.
• Databricks SQL: warehouses, consultas, dashboards y alertas para analistas.
• Mosaic AI / MLflow: experimentos, registro de modelos, serving, vector search y aplicaciones de IA.
• Account console: administración de cuentas, workspaces, identidades, redes y facturación.

Q5. ¿Qué ediciones, nubes y modalidades de despliegue existen?

Databricks está disponible en AWS, Microsoft Azure y Google Cloud, con regiones en muchos países. Las ediciones tradicionales son Standard, Premium y Enterprise, que añaden capacidades de seguridad, gobierno, Unity Catalog, Private Link, auditoría y soporte; sobre ellas se contratan servicios serverless y unidades de consumo (DBUs). Existen modalidades de compute clásico (clusters en la cuenta del cliente, con VPC/VNet injection opcional) y serverless (gestionado por Databricks), además de Databricks Free Edition y pruebas para aprender. La elección de edición y modalidad depende de requisitos de gobierno, residencia de datos, red y costo.

Q6. ¿Cuáles son los casos de uso más habituales?

Ingeniería de datos y ETL/ELT por lotes y en streaming; construcción de lakehouses con arquitectura medallion (bronce, plata, oro); analítica y BI con SQL y dashboards; ciencia de datos y feature engineering a escala; entrenamiento y despliegue de modelos con MLflow y Model Serving; detección de fraude, riesgo, recomendadores y segmentación; procesamiento de datos semiestructurados y logs; gobierno y compartición de datos entre áreas o empresas (Delta Sharing, clean rooms); y aplicaciones de IA generativa con RAG, Vector Search y agentes sobre datos gobernados. También se usa como plataforma de migración de Hadoop/Spark on-premise a la nube.

Q7. ¿Cómo se compara Databricks con Snowflake, BigQuery, Microsoft Fabric y un stack EMR + Glue?

• Snowflake: excelente warehouse SQL y marketplace; su fortaleza es BI y SQL, con menos foco nativo en Spark/ML y notebooks, aunque ha incorporado Iceberg y cargas de ML.
• BigQuery: serverless y muy integrado en GCP, con BigQuery ML y Spark opcional; gran simplicidad, pero menor control de infraestructura y un modelo de costos por consulta/ranuras.
• Microsoft Fabric: suite integrada con Power BI, OneLake y Spark; muy atractiva si la organización ya vive en el ecosistema Microsoft.
• EMR + Glue + Athena: piezas de AWS muy flexibles y económicas, pero exigen ensamblar y operar el stack (catálogo, gobierno, orquestación, notebooks).

Q8. ¿Qué roles intervienen y cómo se organiza un proyecto de datos en Databricks?

Suelen convivir data engineers (ingesta, pipelines, modelado), analistas/BI (SQL, dashboards), data scientists (experimentos, modelos), ML engineers (serving, MLOps), platform admins (workspaces, redes, identidades, costos) y data stewards/governance (catálogo, calidad, accesos). Un patrón habitual es la arquitectura medallion: bronce (datos crudos), plata (limpios y conformados) y oro (agregados de negocio), con catálogos y esquemas por dominio. Se recomienda separar entornos (dev, staging, prod) por workspace o por catálogos/entornos dentro de Unity Catalog, definir convenciones de nombres, usar IaC y bundles, y establecer revisiones de código y de acceso.

Q9. ¿Qué son el control plane y el data plane?

El control plane es la capa gestionada por Databricks: interfaz web, APIs, notebooks, scheduler, gestión de clusters, Unity Catalog y metadatos. El data plane es donde se ejecuta el cómputo y se accede a los datos. En el modelo clásico, los clusters corren en la cuenta cloud del cliente (VPC/VNet propia) y los datos permanecen en su almacenamiento; en serverless, Databricks gestiona el cómputo en su cuenta y accede al almacenamiento del cliente mediante credenciales controladas. La separación permite escalar sin mover datos, aislar cargas y aplicar controles de red, pero exige entender dónde vive cada componente para diseñar seguridad y residencia de datos.

Q10. ¿Qué diferencia hay entre un cluster all-purpose y un job cluster?

Un all-purpose cluster es interactivo, se crea y configura para que varios usuarios ejecuten notebooks y consultas, y puede permanecer encendido (con auto-stop configurable); es cómodo para desarrollo y exploración, pero también más caro si se descuida. Un job cluster se crea automáticamente para una ejecución de Workflows, se destruye al terminar y solo ejecuta ese job; es más eficiente y aislado para producción. Ambos pueden usar autoscaling, instancias spot, Photon y librerías. La recomendación es desarrollar en clusters interactivos pequeños y ejecutar producción con job clusters o serverless, con políticas de cluster que limiten tamaños y tipos de nodo.

Q11. ¿Qué es el compute serverless y cuándo conviene?

El compute serverless lo gestiona Databricks: no hay que elegir ni mantener clusters, el arranque es rápido y se escala automáticamente por carga, con facturación por uso. Aplica a SQL warehouses serverless para BI, jobs serverless para pipelines y notebooks serverless para desarrollo. Conviene cuando se quiere reducir administración, tener cargas intermitentes o picos, o acelerar el time-to-value; puede no convenir para configuraciones muy específicas de red, librerías o GPUs, o cuando el volumen constante hace más económico un cluster dedicado. Hay que revisar limitaciones de runtime, init scripts, acceso a VPC y costo por DBU frente a instancias reservadas.

Q12. ¿Qué es Databricks Runtime y qué aporta Photon?

Databricks Runtime (DBR) es la distribución optimizada de Apache Spark con mejoras de rendimiento, seguridad y compatibilidad, disponible en versiones estándar, LTS (soporte extendido, recomendadas para producción) y ML Runtime (con librerías de machine learning preinstaladas). Photon es un motor de ejecución vectorizado en C++ que acelera consultas SQL y operaciones de DataFrame, especialmente agregaciones, joins y escaneos; se activa por defecto en muchos tipos de compute y suele reducir el tiempo y el costo. La elección de versión debe considerar compatibilidad de librerías, soporte, características de Delta y el ciclo de upgrades; conviene fijar una LTS y probar antes de actualizar.

Q13. ¿Qué son los pools y qué tipos de compute existen?

Un pool es un conjunto de instancias preaprobadas y ociosas que reduce el tiempo de arranque de clusters y jobs; los nodos se reutilizan y se facturan mientras están disponibles. Tipos de compute: all-purpose clusters (interactivo), job clusters (efímeros), SQL warehouses (optimizados para SQL/BI, con tamaño y auto-stop), serverless (SQL, jobs, notebooks) y clusters con GPUs para ML. También existen instance pools y cluster policies para estandarizar configuraciones. La elección depende de interacción, latencia, concurrencia, tipo de carga y gobierno; para BI conviene un warehouse; para ETL, job clusters o serverless; para ML, clusters con GPU y runtime ML.

Q14. ¿Cómo se diseña la red y el aislamiento?

En el modelo clásico se puede desplegar el data plane en la VPC/VNet del cliente (VPC injection / VNet injection), con subredes públicas y privadas, security groups, NAT y endpoints privados. Se recomienda Private Link para el tráfico al control plane y a los servicios cloud (S3, ADLS, GCS, KMS), IP access lists para restringir el acceso al workspace, no public IP en los nodos y salida controlada. En serverless, Databricks gestiona la red pero se configuran network connectivity configurations, private endpoints y reglas de firewall para acceder al almacenamiento del cliente. Hay que documentar flujos, rangos CIDR, DNS y requisitos de residencia; probar conectividad y monitorizar con flow logs.

Q15. ¿Cómo se accede al almacenamiento (DBFS, mounts, external locations, volumes)?

DBFS es el sistema de archivos del workspace; hoy se usa sobre todo para archivos temporales y utilidades, no como almacén principal de datos. Los mounts (/mnt/...) montan contenedores cloud, pero Unity Catalog los desaconseja porque el acceso no queda gobernado por privilegios de catálogo. La forma recomendada es usar external locations (con storage credentials) para tablas externas y volumes para archivos no tabulares (documentos, imágenes, modelos, CSV sueltos), con permisos de Unity Catalog y rutas gobernadas. Las tablas managed de Unity Catalog viven en el almacenamiento del metastore o en locations definidas. La elección afecta gobierno, rendimiento y portabilidad; conviene evitar rutas físicas hardcodeadas en el código.

Q16. ¿Qué considerar en alta disponibilidad, regiones y recuperación ante desastres?

Databricks gestiona la disponibilidad del control plane, pero el diseño de continuidad depende del cliente: datos en almacenamiento cloud con replicación entre regiones, clusters recreables por IaC, código en Git y configuraciones versionadas. No hay un failover automático de workspace entre regiones; en un desastre se aprovisiona un workspace en otra región, se reasocia al metastore o se restaura desde backups, y se reconfiguran jobs, secretos y redes. Conviene definir RPO/RTO, probar restauraciones, documentar dependencias (Unity Catalog, metastore, Delta Sharing, modelos) y mantener artefactos (bundles, Terraform, notebooks) en repositorios. Los datos en Delta Lake con time travel y backups cloud facilitan la recuperación lógica, no sustituyen un plan de DR.

Q17. ¿Qué es Delta Lake y cómo funciona?

Delta Lake es un formato de tabla abierto que combina archivos Parquet con un transaction log (_delta_log) en JSON y checkpoints Parquet. El log registra cada commit de forma atómica y ordenada, lo que aporta transacciones ACID, control de concurrencia, esquema, time travel, evolución de esquema y operaciones como MERGE, UPDATE y DELETE. Los lectores consultan el log para saber qué archivos componen la versión de la tabla, y los escritores usan bloqueo optimista para resolver conflictos. Al ser abierto, lo pueden leer Spark, Databricks SQL, Trino, Flink y otros motores. En Databricks es el formato por defecto del lakehouse y la base de streaming, tablas gobernadas por Unity Catalog y muchas optimizaciones (Photon, liquid clustering, deletion vectors).

Q18. ¿Cómo se hacen upserts y otras operaciones en Delta?

El upsert se hace con MERGE INTO: se define la tabla destino, una fuente (tabla, vista o subconsulta) y la condición de match, con cláusulas WHEN MATCHED THEN UPDATE, WHEN NOT MATCHED THEN INSERT y WHEN NOT MATCHED BY SOURCE THEN DELETE. Es la base de CDC y SCD. También se usan UPDATE, DELETE, INSERT INTO/OVERWRITE, COPY INTO y OPTIMIZE. Para MERGE eficiente: limitar la fuente a lo necesario, incluir particiones o claves de clustering en la condición, evitar múltiples matches por fila y controlar el tamaño de archivos. En streaming, foreachBatch o APPLY CHANGES simplifican los upserts. La idempotencia es clave: el mismo lote reprocesado no debe duplicar filas.

Q19. ¿Qué son OPTIMIZE, Z-ORDER y liquid clustering?

OPTIMIZE compacta archivos pequeños en archivos de mayor tamaño (por defecto ~1 GB) para reducir el overhead de listado y mejorar escaneos; puede ejecutarse completo o con WHERE por partición. Z-ORDER ordena los datos por varias columnas para agrupar valores relacionados y mejorar el data skipping; se aplica con OPTIMIZE ... ZORDER BY (col1, col2). Liquid clustering es la evolución recomendada: define claves de clustering en la tabla y Databricks las mantiene incrementalmente sin particiones fíjas ni reescrituras completas, adaptándose a cambios de volumen; se combina con OPTIMIZE. En tablas nuevas conviene liquid clustering en lugar de particionar por columnas de baja cardinalidad; medir el skipping y el costo antes de elegir claves.

Q20. ¿Qué es VACUUM y cómo se gestiona la retención?

VACUUM elimina los archivos físicos que ya no referencia la tabla (versiones antiguas, archivos reemplazados por OPTIMIZE o MERGE) y libera almacenamiento. Por defecto respeta un período de retención de 7 días para no romper lectores concurrentes ni time travel; se puede cambiar con delta.deletedFileRetentionDuration y delta.logRetentionDuration, pero reducirlo puede invalidar consultas históricas y jobs que leen versiones anteriores. VACUUM no debe ejecutarse mientras hay escrituras o lectores de versiones antiguas; en tablas con deletion vectors, los borrados lógicos se materializan al compactar. La estrategia habitual: OPTIMIZE periódico, VACUUM programado fuera de ventanas críticas y retención alineada con auditoría y recuperación.

Q21. ¿Cómo funcionan el schema enforcement y la evolución de esquema?

Delta aplica schema enforcement: rechaza escrituras cuyos tipos o columnas no coinciden con el esquema de la tabla, evitando corrupción silenciosa. La evolución se habilita explícitamente: mergeSchema en escrituras batch, cloudFiles.schemaEvolutionMode en Auto Loader, write.mergeSchema o ALTER TABLE ADD COLUMNS. Se pueden añadir columnas y promover tipos compatibles (por ejemplo int a bigint), pero no se debe confiar en cambios destructivos; para renombrar o cambiar tipo conviene reescribir con overwriteSchema o una migración controlada. En producción, definir el esquema esperado, validar tipos en la ingesta, documentar cambios y evitar inferSchema sin control en fuentes inestables. Unity Catalog añade gobierno y linaje sobre esos cambios.

Q22. ¿Qué diferencia hay entre tablas managed y external?

En una managed table (gestionada), Databricks controla la ubicación y, al hacer DROP TABLE, también elimina los datos subyacentes; es el modo recomendado para tablas creadas y mantenidas por la plataforma, con Unity Catalog gestionando la ubicación. En una external table, el dato vive en una ruta del almacenamiento del cliente y la tabla solo registra metadatos; al hacer DROP se elimina el metadato pero no los archivos. Las external tables se usan cuando otros sistemas escriben/leen el dato, cuando hay que conservarlo fuera del ciclo de vida de Databricks o por requisitos de propiedad. Con Unity Catalog, también existen external locations y volumes. La elección afecta gobierno, borrado, migraciones y costo; documentar quién es dueño del dato y cómo se elimina.

Q23. ¿Qué son las streaming tables y las materialized views?

Son objetos declarativos de Lakeflow (antes Delta Live Tables) y Databricks SQL. Una streaming table se alimenta de una fuente en streaming o de una consulta incremental y procesa solo datos nuevos, con checkpoints y semántica exactly-once; es adecuada para ingesta continua y transformaciones incrementales. Una materialized view se recalcula total o incrementalmente según la consulta y sirve resultados precalculados para BI; es útil para agregaciones y joins costosos. Se definen en SQL o Python dentro de pipelines declarativos, con expectations de calidad y dependencias gestionadas por el motor. La diferencia clave es el modo de actualización: incremental/streaming frente a refresco de resultados. Elegir mal puede multiplicar costos; revisar freshness, volumen y patrones de consulta.

Q24. ¿Qué es la arquitectura medallion?

Es un patrón de organización del lakehouse en capas con calidad creciente: bronce guarda datos crudos de fuentes (a menudo append-only, con metadatos de ingesta), plata limpia, deduplica, conforma tipos y aplica reglas de negocio, y oro expone agregados y modelos listos para BI/ML. Cada capa puede implementarse con tablas Delta, streaming tables o vistas, y gobernarse con esquemas y privilegios distintos. Ventajas: trazabilidad, reprocesamiento, separación de responsabilidades y reutilización. No es obligatorio tener exactamente tres capas; el principio es que cada una tenga un propósito y contrato claro. Complementar con quality gates/expectations, linaje, catálogo y documentación; evitar copiar datos sin necesidad y controlar el costo de almacenamiento.

Q25. ¿Delta Lake, Parquet, Iceberg o Hudi? ¿Qué papel juega UniForm?

Parquet es un formato de archivo columnar sin transacciones ni metadatos de tabla; sirve para datos simples o intercambio, pero no para un lakehouse gobernado. Delta Lake añade ACID, time travel y operaciones DML sobre Parquet y es el formato nativo de Databricks. Apache Iceberg es otro formato de tabla abierto con gran adopción en el ecosistema; Hudi se usa para upserts y CDC en ecosistemas Hadoop. Databricks soporta leer/escribir Iceberg y ofrece Delta Lake UniForm, que escribe metadatos compatibles para que motores Iceberg/Hudi lean tablas Delta sin duplicar datos. La elección depende del ecosistema, de los motores que deban leer y del gobierno; para un lakehouse Databricks, Delta + UniForm suele dar interoperabilidad sin perder las optimizaciones nativas.

Q26. ¿Qué es Unity Catalog y qué problemas resuelve?

Unity Catalog es el catálogo y la capa de gobierno unificada de Databricks: un único metastore por región que centraliza el acceso a datos y activos de IA en todos los workspaces. Resuelve la dispersión de metadatos (Hive metastore por workspace), la falta de privilegios consistentes, la ausencia de linaje y auditoría, y la dificultad de compartir datos entre equipos. Aporta un modelo de nombres de tres niveles (catalog.schema.table), permisos granulares (incluidos row filters y column masks), linaje a nivel de columna, búsqueda y tags, gestión de volúmenes y modelos, y compartición mediante Delta Sharing. Es la base para un lakehouse gobernado y para cumplir requisitos de seguridad y auditoría.

Q27. ¿Cuál es el modelo de objetos de Unity Catalog?

• Metastore: contenedor de nivel superior, asociado a una región y a uno o varios workspaces; guarda los metadatos.
• Catalog: agrupación lógica (por dominio, entorno o equipo), por ejemplo prod, dev, ventas.
• Schema: base de datos dentro del catálogo; agrupa tablas, vistas, funciones y volúmenes.
• Tablas y vistas: Delta, external, streaming, materialized; las vistas pueden ser normales o materializadas.
• Volumes: archivos no tabulares gobernados (documentos, imágenes, modelos).
• Funciones, modelos, conexiones y shares: lógica reutilizable, modelos registrados, conexiones a fuentes externas y comparticiones.

Q28. ¿Cómo funcionan los privilegios y la herencia en Unity Catalog?

Los privilegios se conceden con GRANT sobre objetos (metastore, catálogo, esquema, tabla, vista, volumen, función) o con DENY explícito; los principales son usuarios, grupos y service principals. La herencia es jerárquica: un privilegio sobre un catálogo aplica a sus esquemas y objetos, y el propietario (owner) tiene control total y puede transferirlo. Existen privilegios como USE CATALOG, USE SCHEMA, SELECT, MODIFY, CREATE TABLE, EXECUTE y READ VOLUME. Buenas prácticas: conceder a grupos (no a usuarios), aplicar mínimo privilegio, separar prod/dev, usar DENY con cuidado (puede sorprender por la herencia), auditar cambios y revisar accesos periódicamente. Los privilegios de Unity Catalog son la fuente de verdad aunque el acceso físico al storage también exista.

Q29. ¿Cómo se gestionan identidades, grupos y service principals?

Las identidades se administran en la account console y se sincronizan desde el IdP corporativo con SCIM (Entra ID, Okta, Google Workspace), de modo que altas y bajas se reflejen automáticamente. Se recomienda organizar el acceso con grupos (por rol/dominio) y no usuario a usuario, y usar service principals para automatización, jobs, CI/CD y aplicaciones, con tokens OAuth o secretos rotables. Los usuarios humanos se autentican con SSO y MFA; los permisos de workspace se combinan con los de Unity Catalog. Hay que definir owners de grupos, revisar membresías, evitar cuentas compartidas, documentar qué service principal usa cada pipeline y monitorizar la creación de tokens. La gestión de identidades es la base del modelo de seguridad: si el grupo está mal, los privilegios heredados también.

Q30. ¿Qué son los row filters y las column masks?

Son mecanismos de seguridad a nivel de fila y columna en Unity Catalog. Un row filter es una función SQL que se aplica a una tabla (por ejemplo, region = current_user_region()) y hace que cada usuario vea solo las filas permitidas. Una column mask transforma el valor de una columna según el usuario o rol (por ejemplo, mostrar el email completo a RRHH y enmascararlo al resto). Se implementan con funciones y ALTER TABLE ... SET ROW FILTER / SET MASK, y aplican a consultas SQL, DataFrames y vistas; requieren que el usuario tenga SELECT y EXECUTE sobre la función. Ventajas: control fino sin duplicar tablas; consideraciones: rendimiento (la función se evalúa por fila), pruebas rigurosas y gobierno de las funciones, y cuidado con exponer datos sensibles en logs o modelos.

Q31. ¿Qué aporta Unity Catalog en linaje, auditoría, tags y búsqueda?

Linaje muestra el origen y las transformaciones de tablas, columnas, vistas, notebooks y jobs, y ayuda a evaluar impacto antes de cambiar algo. Los audit logs registran accesos y operaciones (queries, cambios de permisos, descargas) y se envían al almacenamiento del cliente para análisis y cumplimiento. Los tags (incluidos tags gobernados) clasifican datos (PII, dominio, sensibilidad) y pueden usarse para búsqueda y políticas. El catálogo/búsqueda permite descubrir tablas y entender su descripción, owner y columnas. Complementos: comentarios, documentación, certificación de tablas, quality monitoring y permisos por grupo. Para un gobierno sólido, definir taxonomía, owners, procesos de alta y revisión, y usar el linaje en Change Advisory/impact analysis.

Q32. ¿Qué son external locations, storage credentials y volumes?

Para acceder a almacenamiento cloud de forma gobernada, Unity Catalog usa:

• Storage credential: un objeto que encapsula la autorización (IAM role, managed identity, service account) para acceder al storage; evita poner claves en el código.
• External location: ruta de storage (bucket/prefijo) asociada a una credencial; permite crear tablas externas y volúmenes y aplicar privilegios.
• Volume: espacio gobernado para archivos no tabulares (documentos, imágenes, modelos, CSV), con rutas /Volumes/catalog/schema/volume/... y permisos de lectura/escritura.

Q33. ¿Qué es Delta Sharing y para qué sirven los clean rooms?

Delta Sharing es un protocolo abierto para compartir datos en vivo entre organizaciones o entre equipos sin copiarlos: el proveedor crea un share, el receptor lo monta como catálogo y consulta las tablas con permisos y auditoría. Funciona con Databricks, otros motores compatibles y clientes que implementan el protocolo; permite compartir tablas, vistas, volúmenes y modelos con control de revocación. Los clean rooms permiten a dos o más partes analizar datos combinados sin exponer los registros crudos (por ejemplo, medir el impacto de una campaña con un socio). Consideraciones: gobierno de lo compartido, licencias/privacidad, identificadores, calidad y trazabilidad. Es útil en banca, retail, salud y publicidad, donde compartir datos es valioso pero sensible.

Q34. ¿Cómo se migra de Hive metastore a Unity Catalog y qué convenciones adoptar?

La migración implica inventariar tablas y permisos, crear el metastore y los catálogos, definir external locations/credenciales, y usar el Unity Catalog migration tool o SYNC/UPGRADE para registrar tablas existentes. Hay que mapear bases de datos Hive a esquemas, revisar rutas, propietarios y privilegios, y validar lecturas/escrituras antes de cambiar jobs. Convenciones: nombres en snake_case, catálogo por entorno o dominio, esquemas por capa (bronce/plata/oro) o dominio, comentarios y tags obligatorios, owners claros y privilegios a grupos. Evitar depender de hive_metastore y de mounts; planificar la convivencia temporal, comunicar cambios y actualizar documentación/linaje. La migración es también una oportunidad para limpiar tablas duplicadas y definir estándares.

Q35. ¿Cómo funciona la arquitectura de Apache Spark?

Spark sigue un modelo maestro-trabajador: el driver ejecuta el programa, construye el plan lógico y coordina; el cluster manager (Databricks, YARN, Kubernetes) asigna recursos; y los executors en los workers ejecutan tareas y almacenan datos en memoria/disco. El driver divide el trabajo en jobs (una acción), stages (separadas por shuffles) y tasks (una por partición). En Databricks, el driver corre en el nodo driver del cluster y los executors en los workers; el número de cores y memoria determina el paralelismo. Entender esta jerarquía explica por qué un shuffle es caro, por qué un skew concentra tareas y por qué el tamaño de partición afecta el rendimiento y la estabilidad.

Q36. ¿Qué diferencia hay entre RDD, DataFrame y Dataset? ¿Qué hacen Catalyst y Tungsten?

• RDD: abstracción de bajo nivel, tolerante a fallos, sin esquema ni optimizador; se usa para control fino o código no estructurado, pero es más lento y verboso.
• DataFrame: colección distribuida con esquema, API declarativa y optimizaciones; es la opción habitual en PySpark/SQL.
• Dataset: tipado y orientado a objetos, disponible en Scala/Java; en Python no existe con tipos estrictos.

Q37. ¿Qué es la evaluación perezosa y cómo se relaciona con jobs, stages y tasks?

Las transformaciones (select, filter, join, groupBy) son perezosas: Spark solo construye un plan y no ejecuta nada hasta que aparece una acción (count, collect, write, show). Al ejecutar, Catalyst optimiza el plan y lo divide en stages separados por shuffles; cada stage contiene tasks que procesan particiones en paralelo. La evaluación perezosa permite optimizar globalmente (por ejemplo, empujar filtros antes de un join) y evitar cálculos innecesarios, pero también puede sorprender: un error de esquema no aparece hasta la acción, y encadenar acciones sin cachear recalcula todo. Para depurar, leer el plan físico (explain()) y el Spark UI, donde se ven jobs, stages, tasks, shuffles y spills. Cachear solo resultados reutilizados y no como remedio universal.

Q38. ¿Qué tipos de join usa Spark y cómo se evita el skew?

Spark elige el join según tamaños y estadísticas: broadcast hash join cuando una tabla es pequeña (se replica en cada executor, sin shuffle), sort-merge join para tablas grandes (requiere shuffle y orden), shuffle hash join en ciertos casos y nested loop para condiciones no equi. El skew ocurre cuando unas pocas claves concentran muchas filas: algunas tasks tardan mucho más y el job queda limitado por la cola. Soluciones: AQE (Adaptive Query Execution) activo, skew join y coalesce partitions; salting de claves; separar claves calientes; broadcast si aplica; o pre-agregar. También ayuda revisar el plan y las estadísticas de tabla. En Databricks, AQE y Photon suelen estar activos por defecto; aun así, un join mal diseñado o una clave desbalanceada degradan el rendimiento.

Q39. ¿Cómo se particionan los datos y qué diferencia hay entre repartition y coalesce?

Particionar tablas (PARTITIONED BY) organiza archivos por columnas de baja cardinalidad (fecha, región) para que las consultas lean solo las particiones relevantes; un exceso de particiones o columnas de alta cardinalidad genera archivos pequeños y sobrecarga. Liquid clustering es hoy preferible para muchas tablas porque evita particiones rígidas y mantiene agrupamiento incremental. En el código, repartition(n, col) redistribuye y hace shuffle completo; coalesce(n) reduce particiones sin shuffle (puede dejar particiones desbalanceadas). Para escribir archivos de tamaño sano (~128 MB–1 GB), controlar maxRecordsPerFile y evitar coalesce(1) en datasets grandes. La estrategia debe equilibrar número de archivos, skipping y concurrencia; medir con DESCRIBE DETAIL y el historial de la tabla.

Q40. ¿Cómo funcionan shuffle, memoria y caché en Spark?

El shuffle redistribuye datos entre executors para agrupar por clave (joins, groupBy, repartition); implica serialización, escritura en disco y red, y es la operación más costosa. La memoria se divide entre ejecución y storage; si no alcanza, hay spills a disco y posible OOM. spark.sql.shuffle.partitions (o AQE) define el paralelismo tras un shuffle; demasiadas particiones generan overhead y demasiadas pocas, tareas gigantes. Cache/persist guarda un DataFrame en memoria/disco para reutilizarlo entre acciones, pero consume recursos y puede impedir que otros datasets se cacheen; usar solo cuando se reutiliza de verdad y liberar con unpersist(). Broadcast replica tablas pequeñas para evitar shuffle. En Databricks, el disk cache acelera lecturas de Parquet/Delta en nodos con SSD; no sustituye un buen modelado.

Q41. ¿Cuándo usar UDFs y cómo evitar su costo?

Las UDFs permiten lógica personalizada que SQL no cubre, pero las UDF de Python (serializadas fila a fila) rompen las optimizaciones de Catalyst/Tungsten y añaden overhead de serialización. Alternativas: funciones SQL nativas, higher-order functions (transform, filter, aggregate), expresiones de columna y pandas UDF / Arrow UDF vectorizadas, que procesan lotes y son mucho más rápidas. Para lógica compleja, considerar mapInPandas, applyInPandas o una librería nativa. Buenas prácticas: definir UDFs con tipos explícitos, evitar capturar objetos grandes, no usarlas en columnas de join/filtro si hay alternativa, y medir con y sin UDF. En Databricks, las UDF de Scala/Java pueden ser más eficientes, pero siguen siendo cajas negras para el optimizador; la mejor UDF suele ser la que no se necesita.

Q42. ¿Cómo funciona Structured Streaming y qué garantías ofrece?

Structured Streaming trata un stream como una tabla que se actualiza incrementalmente: se define una consulta sobre una fuente (Kafka, Auto Loader, Delta, socket, rate) y se escribe en un sink (Delta, Kafka, memoria, foreachBatch) con writeStream. El checkpoint guarda el progreso y el estado; con fuentes/sinks transaccionales y procesamiento idempotente se logra exactly-once (o at-least-once con sinks no transaccionales). Los triggers controlan la cadencia (processingTime, availableNow, once, continuous experimental). Watermarks limitan el estado para datos tardíos en agregaciones; las operaciones stateful (deduplicación, joins de stream, agregaciones con ventana) requieren gestión de estado. En Databricks conviene usar Delta como sink y revisar latencia, costo y tamaño de estado; para CDC, APPLY CHANGES simplifica.

Q43. ¿Cómo se depuran problemas de rendimiento y errores en Spark?

Primero el Spark UI (o Spark UI del job en Databricks): revisar duración de stages, número de tasks, shuffle read/write, spills, skew y GC. Luego el plan físico con explain() para detectar escaneos completos, joins costosos, falta de poda de columnas/particiones o UDFs. Errores comunes: OOM del driver (collect/tail de datasets grandes, broadcast demasiado grande), OOM de executor (particiones enormes, skew), FileNotFoundException por VACUUM concurrente, conflictos de escritura Delta (ConcurrentAppendException), datos corruptos o esquemas incompatibles. Soluciones: aumentar/ajustar particiones, evitar collect, usar broadcast con cuidado, activar AQE, corregir skew, aislar jobs, controlar concurrencia y revisar logs del driver/executors. En Databricks también ayudan el query profile y las recomendaciones del Advisor.

Q44. ¿Cómo se trabaja con notebooks en Databricks?

Los notebooks combinan código (Python, SQL, Scala, R), texto Markdown y visualizaciones; permiten colaboración en tiempo real, widgets para parámetros, resultados interactivos y ejecución por celdas. Se organizan en el workspace o en Git folders (Repos) para versionar con Git y trabajar con ramas/PRs. Buenas prácticas: separar lógica reutilizable en módulos o paquetes en lugar de copiar celdas, usar widgets para parámetros, fijar la versión del runtime y las librerías, documentar entradas/salidas y evitar estado oculto entre celdas. Para producción, convertir la lógica en un job, pipeline o bundle reproducible; el notebook es una herramienta de desarrollo y exploración, no un artefacto de despliegue único. Cuidado con credenciales en celdas y con outputs que persisten datos sensibles.

Q45. ¿Qué ofrece Databricks SQL para analistas y BI?

Databricks SQL incluye un editor SQL con autocompletado, historial, parámetros y visualizaciones; SQL warehouses (clásicos o serverless) optimizados para consultas concurrentes; dashboards y alertas; y un modelo de permisos gobernado por Unity Catalog. Se conecta con herramientas de BI (Power BI, Tableau, Looker, Metabase) por JDBC/ODBC y APIs. Los warehouses tienen tamaño, auto-stop y escalado; para BI conviene serverless o warehouses con escalado y revisar el query history y el query profile para detectar consultas costosas. Se pueden crear vistas y materialized views para acelerar. Un antipatrón común es usar un warehouse enorme para todo; mejor ajustar tamaño, cachear resultados y optimizar las consultas y el modelo físico.

Q46. ¿Qué tipos de tablas y vistas existen en Databricks?

• Managed/external tables: Databricks gestiona el ciclo de vida o solo los metadatos; en Unity Catalog ambas se gobiernan igual.
• Vistas: consultas guardadas; no almacenan datos y se recalculan al consultar.
• Materialized views: resultados precalculados y refrescables, útiles para BI y agregaciones costosas.
• Streaming tables: procesamiento incremental con checkpoints.
• Vistas temporales: viven en la sesión de Spark; las global temp views son visibles entre sesiones del mismo cluster pero no persisten.
• Tablas Delta, Parquet, Iceberg, Hudi: según formato; Delta es el recomendado para el lakehouse.

Q47. ¿Qué particularidades tiene el SQL de Databricks?

Databricks SQL sigue el dialecto Spark SQL con extensiones: soporta CTEs, funciones de ventana, QUALIFY para filtrar resultados de ventanas, higher-order functions (transform, filter, exists, aggregate), tipos complejos (struct, array, map), MERGE, LATERAL VIEW, PIVOT/UNPIVOT, GROUP BY ALL, QUALIFY, parámetros con :param y funciones de IA. El modo ANSI está recomendado: hace que operaciones inválidas (división por cero, conversiones) fallen en lugar de devolver null, lo que mejora la calidad pero puede romper código heredado. Conocer el motor ayuda a escribir consultas que aprovechen predicate pushdown, particiones y Photon; evitar funciones no deterministas en joins y revisar el plan. Databricks SQL y Spark SQL comparten gran parte del dialecto, con diferencias en gobernanza y ejecución.

Q48. ¿Cómo se parametrizan consultas y notebooks?

En notebooks se usan widgets (dbutils.widgets.text/dropdown/combobox) para parámetros de fecha, entorno o tabla; se leen con dbutils.widgets.get y se pasan a SQL/DataFrames. En Databricks SQL hay parámetros de consulta (:fecha) y parámetros de dashboard. En jobs, los parámetros se definen en la tarea y llegan como widgets o argumentos. Para SQL dinámico se puede usar IDENTIFIER(:tabla) en lugar de concatenar strings, lo que evita inyección y permite nombres parametrizados. Buenas prácticas: validar valores, usar defaults seguros, no incrustar credenciales, separar entornos por parámetro y documentar cada parámetro. En pipelines declarativos, los parámetros se definen en la configuración y se reutilizan entre tareas.

Q49. ¿Qué es dbutils y para qué se usa?

dbutils es la utilidad de Databricks para interactuar con el entorno desde notebooks y scripts: fs (listar, copiar, mover, eliminar archivos), widgets (parámetros), secrets (leer secretos de ámbitos gestionados), notebook (ejecutar o salir con valor), jobs (ejecutar jobs desde un notebook), library (instalar librerías) y credentials (en algunos contextos). No está pensado para transformar datos a escala; para eso se usa Spark/SQL. Consideraciones: fs opera sobre DBFS/mounts y no siempre respeta los privilegios de Unity Catalog; para datos gobernados usar SQL, volúmenes o APIs. secrets requiere un scope y permisos; nunca imprimir secretos. Las llamadas a dbutils en código compartido deben aislarse para facilitar pruebas.

Q50. ¿Cómo se gestionan librerías y entornos?

Las librerías se instalan a nivel de cluster (todas las ejecuciones), de notebook (%pip install, solo la sesión) o en el runtime ML que ya incluye muchas. Para reproducibilidad, fijar versiones, usar requirements.txt o un wheel interno, y evitar instalar desde notebooks en producción. Los init scripts configuran el sistema al arrancar el cluster (paquetes del SO, variables, certificados), pero no funcionan en serverless y deben versionarse. En Databricks Runtime ML se dispone de CUDA, PyTorch, TensorFlow, XGBoost, etc.; aun así conviene alinear versiones con el modelo. Buenas prácticas: artefacto inmutable, entorno declarado, pruebas de compatibilidad y separar dependencias de desarrollo/producción. Para jobs, usar env specs o bundles y evitar latest.

Q51. ¿Cómo se integra Databricks con Git y CI/CD?

Git folders (antes Repos) permiten clonar un repositorio, trabajar con ramas, hacer commit/pull y abrir PRs desde el workspace. Para automatización se usa Databricks Asset Bundles (definición YAML de jobs, pipelines, notebooks y permisos) o el Terraform provider; el bundle se valida y despliega desde GitHub Actions, GitLab CI o Azure DevOps. El flujo típico: PR → tests/lint → deploy a dev → validación → aprobación → deploy a prod. Los secretos se gestionan con secret scopes o el gestor del CI; los entornos se parametrizan (workspace, catálogo, rutas). No conviene editar producción a mano: todo cambio debería pasar por código revisado y un pipeline reproducible. Los bundles también facilitan rollback y promoción entre entornos.

Q52. ¿Cómo se prueba y asegura la calidad de los datos y del código?

En pipelines declarativos se usan expectations (reglas de calidad con acciones warn/drop/fail) para validar nulos, rangos, unicidad y referencias. Para código, tests unitarios de funciones puras (pytest con SparkSession local), tests de integración sobre datos de muestra y tests de contrato de esquema. Herramientas: Great Expectations, dbt tests (si se usa dbt), Chispa para comparar DataFrames, hypothesis para propiedades y monitoreo de calidad con Lakehouse Monitoring. En producción, cuarentena de datos inválidos, alertas, métricas de frescura/volumen/distribución y revisión de linaje. La calidad no es solo un test al final: se diseña en la ingesta (esquema, deduplicación, idempotencia) y se monitoriza de forma continua.

Q53. ¿Qué es Auto Loader y cómo funciona?

Auto Loader (cloudFiles) ingiere archivos nuevos de un directorio de cloud storage de forma incremental y escalable. Detecta archivos por directory listing o por file notification (SQS/SNS, Event Grid, Pub/Sub) y mantiene un checkpoint con los ya procesados, evitando reprocesar. Infiere y evoluciona el esquema (schemaEvolutionMode), admite rescue data para registros corruptos y se ejecuta en streaming o batch con trigger availableNow. Es la opción recomendada para ingesta continua de archivos en bronce; para volúmenes pequeños o cargas manuales, COPY INTO puede ser suficiente. Buenas prácticas: esquema explícito cuando sea posible, ruta de esquema/checkpoint estable, control de archivos pequeños, y no mover/renombrar archivos ya ingeridos sin gestionar el checkpoint.

Q54. ¿COPY INTO o Auto Loader? ¿Cuándo usar cada uno?

COPY INTO es una carga SQL idempotente que procesa archivos de una ruta y recuerda los ya cargados; es sencillo para cargas programadas, volúmenes moderados y escenarios donde se quiere controlar explícitamente el lote. Auto Loader está diseñado para ingesta continua y grandes volúmenes, con notificaciones, evolución de esquema y mejor escalabilidad; se integra con streaming y pipelines. Regla práctica: si necesitas latencia baja, muchos archivos o esquema cambiante, Auto Loader; si son cargas batch sencillas y pocas, COPY INTO. Ambos evitan duplicados con su propio mecanismo y conviene no mezclarlos sobre la misma ruta sin coordinación. Para bases de datos y SaaS, usar conectores o CDC, no archivos.

Q55. ¿Qué son los pipelines declarativos de Lakeflow (antes Delta Live Tables)?

Lakeflow Declarative Pipelines (anteriormente Delta Live Tables o DLT) permite definir datasets en SQL o Python declarando dependencias entre streaming tables, materialized views y vistas; el motor construye el DAG, gestiona la orquestación, los checkpoints, la escalabilidad y las actualizaciones. Incorpora expectations de calidad (warn, drop, fail) y modos de ejecución triggered o continuous, con serverless o compute dedicado. Es ideal para medallion, CDC y pipelines con muchas dependencias; reduce código de orquestación y facilita el linaje. Consideraciones: entender el modelo de refresco (incremental vs completo), el costo de las materialized views, la gestión de estado y las limitaciones de librerías/init scripts. Para lógica muy imperativa o dependencias externas complejas, puede convenir Workflows con notebooks.

Q56. ¿Cómo funcionan los jobs y Workflows de Databricks?

Lakeflow Jobs (Workflows) permite definir un job con múltiples tasks en un DAG: notebooks, scripts Python, SQL, pipelines, dbt, jars o tareas de copia; cada tarea puede tener dependencias, parámetros, reintentos, timeouts y compute propio (job cluster o serverless). Los triggers pueden ser programados (cron), por llegada de archivos, continuos o manuales; también se puede disparar por API/CLI. Incluye notificaciones, reparación de ejecuciones fallidas, historial y líneas de tiempo. Para producción: idempotencia, parámetros por entorno, alertas, límites de concurrencia y políticas de cluster; versionar la definición con Asset Bundles. Evitar jobs monolíticos y usar tareas con responsabilidades claras y dependencias explícitas.

Q57. ¿Databricks Workflows, Airflow o dbt? ¿Cómo se orquesta un lakehouse?

No son excluyentes: Workflows es el orquestador nativo, ideal para tareas dentro de Databricks y pipelines; Airflow (o Dagster/Prefect) aporta orquestación entre sistemas heterogéneos, dependencias externas y observabilidad centralizada; dbt modela transformaciones SQL y se ejecuta como una tarea más (hay task nativa de dbt en Workflows). Un patrón común: Airflow dispara jobs de Databricks y espera, mientras Workflows organiza las tareas internas; dbt se usa para la capa de transformación cuando el equipo ya lo domina. La clave es evitar dos orquestadores compitiendo por el mismo DAG, definir el dueño de cada dependencia, centralizar alertas y mantener idempotencia y trazabilidad. Para equipos pequeños, Workflows suele bastar y reduce infraestructura.

Q58. ¿Cómo se implementa CDC y SCD en Databricks?

Para CDC se ingieren cambios (inserts, updates, deletes) desde Debezium, Kafka, bases de datos o archivos, y se aplican con MERGE o con APPLY CHANGES / AUTO CDC en pipelines declarativos. APPLY CHANGES permite definir claves, secuencia (SEQUENCE BY), columnas de delete y el tipo de SCD: SCD 1 (sobrescribe) o SCD 2 (guarda versiones con válidos desde/hasta y flag actual). Para SCD 2 se añaden columnas de vigencia y se filtran las consultas por la versión actual. Consideraciones: ordenar eventos por timestamp/versión, manejar late data, deletes lógicos, duplicados y reinicios de la fuente; elegir claves estables; y validar que el reprocesamiento no duplique historia. En tablas Delta, las escrituras MERGE deben ser idempotentes y la fuente debe estar limpia antes de aplicar cambios.

Q59. ¿Qué conectores y patrones de ingesta existen?

• Archivos: Auto Loader, COPY INTO sobre S3/ADLS/GCS, con formatos Parquet, JSON, CSV, Avro, ORC, XML (con librerías).
• Streaming: Kafka, Kinesis, Event Hubs, Pulsar y sockets, con Structured Streaming; para CDC, Debezium hacia Kafka.
• Bases de datos: JDBC (PostgreSQL, MySQL, SQL Server, Oracle), con lecturas batch; para CDC, herramientas como Debezium/Fivetran/Qlik Replicate.
• SaaS: Lakeflow Connect ofrece conectores gestionados (Salesforce, Workday, ServiceNow, NetSuite, SQL Server, etc.) y también se usan Fivetran, Airbyte o Stitch.
• Federación: Lakehouse Federation para consultar fuentes externas sin copiarlas.

Q60. ¿Qué es Lakehouse Federation y cuándo usarla?

Lakehouse Federation permite consultar bases de datos externas desde Databricks mediante foreign catalogs en Unity Catalog, sin mover los datos: se crea una connection con credenciales, se registra el catálogo y se consultan tablas con SQL (con pushdown cuando el motor lo soporta). Fuentes habituales: PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, BigQuery, Redshift y otras. Es útil para joins puntuales, exploración, migraciones graduales o datos que deben quedarse en su sistema por latencia o regulación. Limitaciones: rendimiento dependiente de la red y del origen, menos optimizaciones que una tabla local, y gobierno compartido entre sistemas. Para cargas frecuentes o grandes volúmenes, suele ser mejor ingerir y modelar en el lakehouse; la federación complementa, no sustituye, una estrategia de integración.

Q61. ¿Cómo se gestionan idempotencia, datos tardíos y reprocesamientos?

La idempotencia se diseña: MERGE por clave, deduplicación con dropDuplicates/ROW_NUMBER, checkpoints estables y escrituras transaccionales en Delta. Para datos tardíos, usar watermarks en streaming y ventanas; en batch, reprocesar por fecha/partición y volver a calcular agregados afectados. Los backfills deben ejecutarse sobre bronce (fuente de verdad), con parámetros de rango y sin reutilizar checkpoints incompatibles; para streaming, crear un checkpoint nuevo o una tabla destino temporal. Evitar sobrescribir tablas de producción sin transacción; preferir escribir a staging y hacer swap/merge. Documentar la lógica de negocio y las claves; probar reprocesos en dev; y monitorizar duplicados, frescura y conteos. Un pipeline que no se puede reprocesar de forma segura es un riesgo operativo.

Q62. ¿Qué es MLflow y cómo se usa en Databricks?

MLflow es la plataforma open source de MLOps integrada en Databricks: Tracking registra parámetros, métricas, artefactos y versiones de código/entorno; Models empaqueta el modelo con su firma y dependencias; el Model Registry (en Unity Catalog) versiona, documenta y promueve modelos con alias (champion/challenger) y permisos; Projects empaqueta el código reproducible. Se usa con autologging (mlflow.autolog()) o instrumentación manual, y se integra con serving, batch inference y evaluación. Buenas prácticas: experimentos nombrados por proyecto, runs con tags y versión de datos, registro de métricas de negocio además de técnicas, y promover modelos solo tras validación. El modelo debe poder reproducirse: código, datos, entorno y parámetros.

Q63. ¿Qué es Feature Engineering / Feature Store en Databricks?

Es la capa que centraliza la definición, el cálculo y el acceso a features para que entrenamiento y serving usen la misma lógica. En Unity Catalog, las feature tables se registran como tablas Delta con una primary key y una timestamp key, lo que permite point-in-time lookups y evitar leakage; se pueden publicar en un online store (online tables) para baja latencia en serving. La ventaja es la consistencia training/serving y la reutilización entre modelos. Consideraciones: gobierno de features, linaje, frescura, costo del online store y dueño de las definiciones. Alternativas: calcular features en el pipeline y servirlas desde Delta/Serving; para equipos pequeños puede bastar una tabla de features bien documentada. Lo importante es evitar dos implementaciones divergentes de la misma feature.

Q64. ¿Cómo se entrena a escala en Databricks?

El patrón habitual: preparar y agregar datos con Spark/SQL, entrenar en un nodo con sklearn/XGBoost/PyTorch y, si el modelo no cabe, usar entrenamiento distribuido. Databricks ofrece clusters con GPU (runtime ML con CUDA), TorchDistributor para data-parallel con PyTorch, Spark MLlib para algoritmos distribuidos, XGBoost Spark y Ray para escalar cómputo. Para hiperparámetros se usa Optuna o Hyperopt con MLflow tracking y, si aplica, jobs en paralelo. Buenas prácticas: fijar semillas, versionar datos y entornos, separar train/validation/test por tiempo o entidad, controlar el costo de GPU, y registrar todo en MLflow. En muchos casos el cuello de botella es la preparación de datos, no el entrenamiento; optimizar primero el pipeline y el feature engineering.

Q65. ¿Cómo se despliegan modelos con Model Serving?

Mosaic AI Model Serving expone modelos como endpoints HTTP en tiempo real, con escalado automático, scale-to-zero y opción de GPU; puede servir modelos de MLflow, modelos personalizados o foundation models. Para batch inference se usan jobs con mlflow.pyfunc.spark_udf o predict_batch, que evitan mantener un endpoint encendido. Características útiles: versiones y aliases, split de tráfico para A/B/canary, inference tables para registrar peticiones/respuestas, y monitoring. Consideraciones: latencia, concurrencia, costo, tamaño del modelo, dependencias y seguridad de los datos. Para cargas intermitentes, batch suele ser más económico; para aplicaciones interactivas, serving. Documentar contrato de entrada/salida, versionado y rollback; probar con carga realista antes de exponer a producción.

Q66. ¿Qué es Lakehouse Monitoring y qué se puede monitorizar?

Lakehouse Monitoring crea perfiles y métricas de calidad sobre tablas Delta e inference tables: distribución de columnas, nulos, cardinalidad, rangos, frescura y volumen; también puede comparar contra una línea base o ventana anterior para detectar drift. En modelos, monitoriza la distribución de features y predicciones y, si hay ground truth, la performance. Genera dashboards y tablas de métricas que se pueden alertar. Se complementa con expectations en pipelines, tests y observabilidad de jobs. Consideraciones: definir qué métricas importan al negocio, evitar alertas ruidosas, gestionar el costo de perfilar tablas grandes y proteger datos sensibles en los perfiles. No sustituye la validación humana ni las pruebas de causalidad; es una señal temprana de problemas.

Q67. ¿Qué ofrece Databricks para IA generativa y RAG?

Databricks integra Foundation Model APIs (modelos gestionados como Llama, Mistral, Claude o GPT, según disponibilidad, con pago por token o throughput aprovisionado), modelos externos vía AI Gateway, y herramientas para construir RAG: ingesta y chunking de documentos, embeddings, Vector Search (con índices sincronizados desde Delta), recuperación, prompting y serving del agente. El flujo típico: documentos en un volume o tabla → parsing/chunking → embeddings → índice vectorial → retrieval + prompt → endpoint. Se añaden evaluación, guardrails, trazabilidad y control de acceso a los datos. Buenas prácticas: gobernar las fuentes, medir calidad de recuperación, controlar costo/latencia, versionar prompts y modelos, y no asumir que el LLM conoce datos internos. Databricks Assistant y AI Playground ayudan a prototipar.

Q68. ¿Cómo se ajusta, evalúa y protege un modelo de IA generativa?

Ajuste: fine-tuning supervisado o adaptadores con Mosaic AI Model Training, o modelos propios; requiere dataset curado, formato de conversación, particiones y control de costo de GPU. Evaluación: MLflow Evaluate / Mosaic AI Agent Evaluation con métricas de corrección, fidelidad a la recuperación, relevancia, toxicidad, latencia y costo; usar datasets de evaluación representativos y LLM-as-judge con revisión humana. Guardrails: filtros de contenido, validación de entrada/salida, AI Gateway para políticas, rate limits, PII redaction, prompt injection defenses y permisos sobre las fuentes. Buenas prácticas: versionar prompts/modelos, registrar trazas, hacer A/B y canary, definir criterios de aceptación y rollback, y documentar limitaciones. La evaluación continua importa tanto como la del modelo clásico.

Q69. ¿Cómo se construyen agentes y aplicaciones de IA en Databricks?

El Mosaic AI Agent Framework permite definir agentes con herramientas (búsqueda vectorial, funciones SQL, APIs, modelos), memoria y lógica de planificación, y desplegarlos como endpoints de Model Serving; Agent Bricks ofrece plantillas de bajo código para casos comunes. Se integra con Unity Catalog para gobernar datos, funciones y modelos, con MLflow para trazas/evaluación y con AI Gateway para control de acceso, límites y observabilidad. Consideraciones: diseñar herramientas seguras y con mínimo privilegio, validar argumentos, evitar que el agente ejecute acciones destructivas sin confirmación, gestionar contexto y costo, y evaluar con casos reales. Los agentes son útiles para tareas multietapa, pero añaden no determinismo y superficie de ataque; empezar con un caso acotado, medir y escalar.

Q70. ¿Cómo se optimiza el rendimiento con Photon, AQE y particiones de shuffle?

Photon acelera SQL/DataFrames con ejecución vectorizada; conviene dejarlo activo salvo incompatibilidades. AQE (Adaptive Query Execution) ajusta el plan en tiempo de ejecución: coalesce particiones, convierte sort-merge en broadcast si detecta tablas pequeñas y maneja skew joins; en Databricks suele estar activo. spark.sql.shuffle.partitions controla el paralelismo tras un shuffle; con AQE, un valor inicial alto y coalesce automático funciona mejor que fijar un número mágico. Además: podar columnas y particiones, filtrar temprano, evitar UDFs opacas, revisar el plan físico y el query profile, y usar cache solo cuando se reutiliza. Medir antes y después con la misma carga; optimizar sin medir suele mover el cuello de botella, no eliminarlo.

Q71. ¿Cómo se optimiza el layout físico de las tablas?

El objetivo es reducir archivos pequeños, mejorar el data skipping y evitar reescrituras innecesarias. Herramientas: OPTIMIZE para compactar, liquid clustering para agrupar por columnas de filtro/join sin particiones rígidas, Z-ORDER en tablas heredadas con particiones, y VACUUM para limpiar archivos obsoletos. El particionamiento clásico debe reservarse para columnas de baja cardinalidad y consultas que filtran por ellas; partir por columnas de alta cardinalidad produce miles de carpetas y archivos diminutos. Controlar el tamaño al escribir (maxRecordsPerFile, repartition), elegir claves de clustering según patrones de consulta y revisar DESCRIBE DETAIL (número/tamaño de archivos). En streaming, la compactación programada y el control de frecuencia de commits son clave para no degradar el rendimiento.

Q72. ¿Qué opciones de caché existen y cuándo usarlas?

• Disk cache (Databricks): caché automática en SSD local de los nodos para datos Parquet/Delta leídos; acelera consultas repetidas y se gestiona por el runtime. Requiere nodos con disco suficiente y no aplica igual en serverless.
• Spark cache (persist): guarda un DataFrame/RDD en memoria/disco entre acciones; útil si se reutiliza mucho, pero consume recursos y puede empeorar la presión de memoria. Liberar con unpersist().
• Result cache (Databricks SQL): reutiliza resultados de consultas idénticas en warehouses; se invalida cuando cambian los datos o la consulta.
• Materialized views: precalculan resultados para BI; no son una caché de sesión, sino objetos gobernados con refresco.

Q73. ¿Cómo se dimensiona un SQL warehouse y se analizan consultas?

El tamaño del warehouse determina número de workers y concurrencia; se puede escalar y configurar auto-stop. Un warehouse demasiado pequeño encola consultas; uno demasiado grande desperdicia DBUs. Para BI, considerar serverless y el escalado automático, y separar cargas (dashboards vs ETL/ad-hoc) para no competir. Analizar con query history y query profile: tiempo de ejecución, bytes leídos, spills, operadores costosos, pruning y uso de caché. Optimizar SQL (filtros, joins, agregaciones, evitar SELECT * y funciones costosas), crear materialized views si aplica y revisar el modelo físico. Configurar alertas de consultas lentas y revisar el costo por query; no todas las consultas necesitan el mismo warehouse ni la misma prioridad.

Q74. ¿Cómo se dimensionan clusters y se reduce el costo de cómputo?

Elegir el tipo de instancia según CPU, memoria, GPU y disco; usar autoscaling con mínimos y máximos realistas; activar auto-stop en clusters interactivos; usar job clusters o serverless para producción; y aprovechar instancias spot para cargas tolerantes a fallos (con fallback on-demand). Los pools reducen el arranque; las cluster policies limitan tamaños y tipos; las reserved instances o compromisos de uso reducen el precio por DBU. Medir utilización (CPU, memoria, workers ociosos) y ajustar; el error típico es sobredimensionar «por si acaso» o dejar clusters encendidos. Separar cargas (ETL, BI, ML) y usar el compute adecuado; Photon y optimizaciones de runtime también reducen el tiempo facturable.

Q75. ¿Cómo se monitorizan y controlan los costos?

Usar las system tables de facturación (system.billing.usage, list_prices) y de compute para atribuir consumo por workspace, cluster, job, usuario o tag; combinar con tags de recursos y clústeres para cost allocation. Configurar budgets y alertas en la account console, budget policies y cluster policies que limiten SKUs, tamaños y auto-stop. Revisar los dashboards de uso, los jobs más caros, warehouses ociosos y consultas que escanean más de lo necesario. Prácticas: apagar recursos, serverless para cargas intermitentes, spot para batch, Photon, compactar archivos, evitar reprocesos innecesarios y elegir el tamaño correcto. El costo es una métrica de ingeniería: debe revisarse en el diseño y en la operación, no solo a fin de mes.

Q76. ¿Cuáles son los cuellos de botella más comunes y cómo se diagnostican?

Los habituales: skew en joins/agrupaciones (unas pocas tasks eternas), shuffle excesivo (joins mal filtrados, repartition innecesario), archivos pequeños (listado y apertura costosos), UDFs de Python fila a fila, collect al driver, spills/OOM por particiones gigantes, y consultas que escanean columnas/particiones innecesarias. Diagnóstico: Spark UI (stages, tasks, shuffle, spill, skew), query profile en SQL, explain(), system tables de query history y métricas de cluster. Soluciones: filtrar temprano, podar columnas, broadcast de tablas pequeñas, AQE, salting, reparticionar por clave, compactar, reemplazar UDFs por funciones nativas, y evitar traer datos al driver. Priorizar el cuello de botella dominante; optimizar lo demás puede no mover la aguja.

Q77. ¿Qué buenas prácticas de modelado y benchmarking aplicar?

Modelar según el consumo: hechos y dimensiones para BI (star schema), tablas desnormalizadas o wide para cargas analíticas, y agregados/materialized views para consultas repetidas; evitar un único modelo gigante para todos los casos. Usar nombres y comentarios claros, tipos correctos, claves y relaciones documentadas, y capas medallion con contratos. Elegir claves de clustering por patrones de filtro/join, controlar granularidad y evitar duplicación. Para benchmarking, definir una carga representativa, medir latencia, costo y frescura con y sin cambios, y probar en un entorno comparable; no comparar consultas con caché caliente contra frías. Documentar decisiones y revisar el modelo periódicamente con los consumidores. La optimización es un ciclo: medir, cambiar una cosa, volver a medir.

Q78. ¿Cómo se gestionan identidades y credenciales en Databricks?

Usuarios humanos con SSO (SAML/OIDC) y MFA a través del IdP; aprovisionamiento con SCIM; grupos para permisos; service principals para automatización, con OAuth (recomendado) o secretos rotables; personal access tokens (PAT) solo cuando sea necesario, con caducidad y alcance mínimo. Las credenciales de almacenamiento se encapsulan en storage credentials de Unity Catalog y los secretos en secret scopes (respaldados por Key Vault/Secrets Manager) o en el gestor de secretos del CI. Buenas prácticas: evitar PAT de usuario para pipelines, no incrustar secretos en notebooks/código, rotar credenciales, revisar tokens y service principals periódicamente, y aplicar mínimo privilegio. La autenticación es el primer control; sin ella, el resto del gobierno es decorativo.

Q79. ¿Qué prácticas de gobierno, privacidad y cumplimiento aplicar?

Clasificar datos (PII, sensibles, financieros) con tags y catálogo; aplicar row filters y column masks; restringir privilegios por grupo y dominio; mantener linaje y audit logs centralizados; definir retención y borrado; y documentar owners y contratos de datos. Para cumplimiento (GDPR, HIPAA, PCI, SOX), mapear controles a la plataforma: cifrado, acceso, auditoría, segregación de entornos, gestión de cambios y backups. Minimizar la copia de datos sensibles, enmascarar en desarrollo, evitar datos reales en notebooks públicos, y revisar permisos de volúmenes/models. La privacidad también aplica a IA: no enviar datos sensibles a modelos externos sin control, y gobernar prompts y trazas. El gobierno debe ser continuo: revisiones, certificaciones de tablas y métricas de cumplimiento.

Q80. ¿Qué controles de red y cifrado existen?

Red: VPC/VNet injection para el data plane en la cuenta del cliente, subredes privadas, Private Link para el control plane y servicios cloud, IP access lists, no public IP en nodos y reglas de firewall/egress. En serverless, configuraciones de conectividad y private endpoints. Cifrado: en reposo con claves gestionadas por el proveedor o customer-managed keys (CMK) en el almacenamiento y, según el servicio, en el control plane; en tránsito con TLS. Los secretos se guardan en secret scopes respaldados por KMS/Key Vault. Consideraciones: rotación de claves, residencia de datos, separación de entornos, logs de flujo y pruebas de conectividad. La seguridad de red no sustituye la autorización: un usuario con privilegios excesivos sigue siendo un riesgo aunque la red sea privada.

Q81. ¿Qué se administra desde la account console y qué políticas conviene definir?

La account console gestiona workspaces, metastore de Unity Catalog y su asignación, usuarios/grupos/service principals, redes y private access, IP access lists, presupuestos y credenciales de almacenamiento. Políticas clave: cluster policies (limitar tipos de nodo, tamaños, auto-stop, uso de spot, librerías), budget policies y alertas, convenciones de nombres de workspaces/catálogos, separación dev/staging/prod, y permisos de workspace alineados con grupos. Definir quién puede crear clusters, warehouses o service principals; revisar la configuración con Terraform/IaC; y documentar el modelo de responsabilidad. La administración debe ser reproducible y auditada; los cambios manuales en producción son una fuente típica de desviaciones.

Q82. ¿Cómo se implementa CI/CD e infraestructura como código?

Databricks Asset Bundles define en YAML jobs, pipelines, notebooks, permisos y variables por entorno; se valida y despliega con la CLI (databricks bundle validate/deploy) desde GitHub Actions, GitLab CI o Azure DevOps. El Terraform provider cubre infraestructura (workspaces, clusters, jobs, permisos, catálogos) y es útil en equipos que ya usan Terraform. Flujo recomendado: rama/PR → lint/tests → deploy a dev → pruebas de integración → aprobación → deploy a prod; secretos desde el CI o secret scopes; promoción de artefactos inmutables. Probar los bundles en un workspace de desarrollo antes de producción, versionar cambios y usar entornos separados. Con esto se reduce el riesgo, se facilita el rollback y se evita configurar a mano.

Q83. ¿Qué observabilidad ofrece la plataforma?

Las system tables exponen auditoría (system.access.audit), facturación (system.billing), compute, query history y ejecuciones de jobs/pipelines; permiten construir dashboards y alertas SQL. Además: query history y query profile en SQL, Spark UI y logs de driver/executors, métricas de cluster, diagnostic logs enviados a S3/ADLS/GCS, y notificaciones de jobs. Se integra con herramientas externas (Datadog, Splunk, New Relic, PagerDuty) y con el proveedor cloud. Buenas prácticas: centralizar logs, definir SLOs (frescura, éxito de jobs, latencia de consultas), alertar sobre fallos y desviaciones de costo, y revisar tendencias. La observabilidad debe cubrir datos, código y costo; un job verde puede estar produciendo datos incorrectos.

Q84. ¿Qué considerar en continuidad de negocio, backups y migraciones?

Definir RPO/RTO por dominio; replicar datos críticos en otra región (almacenamiento cloud); mantener código, bundles y Terraform en Git para recrear workspaces; documentar dependencias de Unity Catalog, metastore, redes, secretos e identidades. Databricks no ofrece failover automático entre regiones: el plan debe incluir aprovisionar un workspace alternativo, reasociar catálogos o restaurar metadatos, y reconfigurar jobs. Los backups lógicos (tablas, volúmenes, modelos) y el time travel de Delta ayudan, pero no cubren metadatos fuera de UC ni configuraciones. Probar restauraciones y simulacros; documentar el orden de recuperación; y para migraciones entre nubes/regiones, planificar redes, permisos, datos y validaciones. La continuidad se prueba, no se declara.

Q85. ¿Qué buenas prácticas de arquitectura y antipatrones conviene conocer?

Buenas prácticas: lakehouse con Delta y Unity Catalog; medallion con contratos; IaC/bundles; idempotencia y reprocesabilidad; liquid clustering y OPTIMIZE; compute adecuado (serverless/job clusters); gobierno por grupos y mínimo privilegio; observabilidad y cost allocation; tests y expectations; documentación y linaje. Antipatrones: mounts y rutas físicas en lugar de UC; sobredimensionar clusters o dejarlos encendidos; particionar en exceso; archivos pequeños; collect al driver; UDFs de Python innecesarias; un único warehouse para todo; permisos a usuarios en vez de grupos; cambios manuales en producción; pipelines no idempotentes; y datos sin owner. La mejor arquitectura es la que el equipo puede operar y evolucionar con seguridad; la simplicidad bien gobernada suele vencer a la complejidad prematura.