Databricks

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 1 de 15. Durante años, las empresas han pagado dos veces por almacenar exactamente los mismos datos solo para mantener contentos tanto a sus ingenieros de machine learning como a sus business analysts. Almacenar datos en crudo en un sistema y copiarlos en otro genera problemas de sincronización interminables. Databricks soluciona esto introduciendo un enfoque unificado llamado Data Lakehouse. Históricamente, las organizaciones dividían su arquitectura de datos en dos caminos separados. Primero, construían Data Lakes. Son sistemas de cloud storage baratos y altamente escalables, perfectos para volcar cantidades masivas de datos no estructurados. A los data scientists les encantan para entrenar modelos de machine learning. Pero los Data Lakes son horribles para hacer queries SQL rápidas y fiables. Para solucionar eso, las empresas introdujeron los Data Warehouses para sus equipos de business intelligence. Esto genera una carga operativa enorme. Toma como ejemplo una startup en crecimiento. Sus data engineers vuelcan los logs de eventos en crudo en un bucket de cloud storage. Allí ejecutan sus scripts de Python. Pero el equipo de finanzas necesita dashboards. Así que los ingenieros tienen que construir pipelines complejos para extraer esos datos, transformarlos y cargarlos en un Data Warehouse independiente. La empresa paga por el almacenamiento dos veces. Pagan por el compute necesario para mover los datos. Y en el momento en que los datos llegan al warehouse, ya están desactualizados. Databricks elimina este pipeline por completo con la arquitectura Data Lakehouse. Un Lakehouse combina el almacenamiento barato y flexible de un Data Lake con la fiabilidad y el rendimiento de un Data Warehouse. Mantiene tus datos en un formato único y abierto directamente en tu cloud storage. No los copias a una base de datos propietaria. En su lugar, Databricks añade una capa transaccional directamente sobre tu Data Lake existente. Aquí está la clave. Tus datos se quedan en un solo lugar, pero diferentes profesionales interactúan con ellos exactamente como necesitan. Los data scientists pueden escribir Python o Scala para entrenar modelos directamente sobre los archivos en crudo. Al mismo tiempo, los business analysts pueden ejecutar queries SQL de alto rendimiento sobre exactamente los mismos datos para alimentar sus herramientas de reporting. La gente suele pensar por error que Databricks es solo otra base de datos SQL o simplemente un wrapper gestionado sobre Apache Spark. No es ninguna de las dos cosas. Es una plataforma integral de Data Intelligence. Al fusionar el lake y el warehouse, también fusionas la seguridad y la gobernanza. En el modelo antiguo, tenías que gestionar los permisos de acceso en el cloud storage para los ingenieros y, por separado, en el Data Warehouse para los analistas. Con Databricks, una capa de gobernanza unificada gestiona el control de acceso en cada tabla, archivo y modelo de machine learning. Defines una política de acceso a los datos una sola vez, y se aplica en todas partes, independientemente del lenguaje o la herramienta que uses para hacer la query. El verdadero poder de la arquitectura Lakehouse no es solo ahorrar dinero en pipelines de storage redundantes; es que tus modelos de inteligencia artificial y tus dashboards financieros por fin están viendo exactamente los mismos números al mismo tiempo. Si quieres ayudar a que el programa siga adelante, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 2 de 15. Si tu empresa utiliza varios workspaces para procesar datos, probablemente tengas varios lugares donde gestionas los permisos de seguridad. Esa fragmentación es un riesgo de compliance enorme, porque mantener las políticas sincronizadas en entornos desconectados depende completamente de actualizaciones manuales. Unity Catalog elimina este riesgo al cambiar fundamentalmente cómo funciona la gobernanza de datos en Databricks. Antes de explicar la mecánica, tenemos que aclarar un malentendido muy común. Unity Catalog no es un data dictionary pasivo. No es solo una lista de tablas donde los usuarios van a leer descripciones. Es el policy engine central que aplica activamente las reglas de seguridad en toda tu arquitectura. Unity Catalog resuelve el problema persistente de saber exactamente quién tiene acceso a qué. Proporciona un modelo de seguridad unificado basado en el estándar ANSI SQL. En lugar de configurar por separado los roles de identidad en la nube, los permisos a nivel de workspace y los controles de acceso a nivel de cluster, usas comandos familiares como grant y revoke directamente sobre tus datos y activos de inteligencia artificial. Como Unity Catalog está a nivel de cuenta, en lugar de estar vinculado a un workspace individual, defines cada regla de seguridad una sola vez. Esa regla se aplica de forma instantánea y universal en todos los workspaces conectados a ese catálogo. Imagina una situación en la que un auditor le pide a un CTO que demuestre exactamente quién hizo una query a una tabla específica con números de tarjetas de crédito el martes pasado, y que identifique cada downstream report que usa esos números actualmente. Tradicionalmente, responder a esto significaba parsear logs del sistema inconexos en diferentes herramientas, leer a mano los jobs de transformación programados y cruzar los dedos para no haberte saltado ningún paso intermedio. Unity Catalog gestiona esto de forma nativa a través de sus dos siguientes pilares: auditoría integrada y lineage automatizado. Primero, captura audit logs detallados a nivel de usuario out of the box. Cada vez que un usuario o un service principal accede a los datos, el catálogo registra el evento. Aquí está la clave. Unity Catalog no solo rastrea quién hizo una query a una tabla; rastrea qué pasa con los datos después a través del lineage automatizado. A medida que se ejecutan tus pipelines programadas, el sistema lee continuamente los planes de ejecución y construye un mapa de cómo fluyen los datos. Rastrea qué tablas de origen alimentan qué datasets intermedios, hasta llegar a los dashboards finales. Hace este seguimiento tanto a nivel de tabla como a nivel de columna. Cuando el auditor te pregunte por los datos de las tarjetas de crédito, no tienes que adivinar. Miras el grafo de lineage y ves al instante cada paso de transformación y cada punto de acceso. El último gran pilar es el data sharing seguro. Las organizaciones a menudo necesitan compartir datasets con proveedores externos o unidades de negocio separadas. En lugar de exportar flat files o duplicar datos en buckets de cloud storage separados, Unity Catalog integra un protocolo llamado Delta Sharing. Esto te permite dar a terceros acceso gobernado a datos en vivo sin copiarlos. El consumidor externo lee los datos in place, y su acceso queda registrado y controlado por exactamente el mismo cerebro central. El verdadero valor de Unity Catalog es que elimina por completo la peligrosa brecha entre redactar una política de seguridad en papel y ejecutarla realmente en data silos aislados. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 3 de 15. La forma más fácil de agotar tu presupuesto de cloud es dejar un servidor enorme encendido sin hacer nada todo el fin de semana. Quieres potencia de procesamiento exactamente cuando la necesitas, y cero facturación cuando no. Esto es exactamente lo que veremos hoy en Navegando por el workspace y el compute. Tu punto de entrada a Databricks es el workspace. Piensa en el workspace como el entorno unificado donde tu equipo organiza todos sus assets de Databricks. Te da una interfaz web para gestionar tus notebooks, objetos de datos, experimentos de machine learning y los recursos de compute subyacentes. El workspace reúne todas tus herramientas colaborativas en una vista organizada, asegurando que diferentes equipos puedan interactuar con los mismos datos subyacentes sin pisarse unos a otros. Bajo el capó, Databricks se basa en una arquitectura desacoplada. Tus datos viven de forma persistente en el cloud object storage, mientras que la potencia de compute utilizada para procesar esos datos se levanta de forma completamente separada. Esta separación de responsabilidades dicta tu facturación. Como el compute está aislado del storage, solo aprovisionas y pagas por instancias de servidor cuando estás ejecutando código activamente. Cuando el trabajo termina, el compute se apaga, pero tus datos siguen almacenados de forma segura y accesibles. Para gestionar esta potencia de procesamiento, Databricks ofrece diferentes tipos de recursos de compute adaptados a workflows específicos. El primero es un clúster All-Purpose. Lo usas para trabajo interactivo y ad-hoc. Imagina que un data analyst necesita un entorno muy potente para hacer una query de mil millones de filas un martes por la tarde. Levanta un clúster All-Purpose, adjunta su notebook y empieza a explorar. Para evitar sorpresas en la factura del fin de semana, estos clústeres cuentan con auto-termination. Si el analista se va a casa a las cinco y se deja el notebook abierto, el clúster se monitoriza a sí mismo buscando inactividad y se apaga automáticamente tras un límite de tiempo especificado. Aquí está la clave sobre la automatización. Un error frecuente que cometen los equipos es programar pipelines de producción automatizadas para que corran en estos clústeres interactivos All-Purpose. Evita hacer esto. Los clústeres All-Purpose tienen un coste de uso más alto, y correr múltiples workflows diferentes en un clúster interactivo compartido puede introducir conflictos de librerías o contención de recursos. En su lugar, las pipelines de producción deberían usar Job clusters. Un Job cluster es completamente efímero. Cuando se lanza una pipeline automatizada, el job scheduler de Databricks aprovisiona un Job cluster dedicado estrictamente para esa carga de trabajo. Ejecuta el código, y en el segundo exacto en que el job termina, el clúster se destruye a sí mismo. Esto garantiza un aislamiento estricto de recursos para tu pipeline y asegura que pagues la tarifa de compute más baja posible para tareas automatizadas. Finalmente, si tu carga de trabajo es puramente analítica, puedes usar un SQL warehouse. Este es un recurso de compute optimizado específicamente para ejecutar comandos SQL y queries de dashboards. Si usas Serverless SQL warehouses, Databricks gestiona el compute subyacente automáticamente. Escala hacia arriba instantáneamente cuando llega una avalancha de queries, y escala hacia abajo cuando la cola se vacía, eliminando por completo la necesidad de que configures la infraestructura tú mismo. Elegir el tipo de compute adecuado para la naturaleza exacta de tu tarea es la forma más efectiva de garantizar que tu infraestructura cloud siga siendo potente durante las horas punta y altamente rentable cuando el trabajo termina. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 4 de 15. Creas un data lake, pero en cuestión de meses nadie sabe dónde están los datos de producción, quién es el owner o si es seguro hacerle una query a una tabla específica. La diferencia entre un data lake impecable y un data swamp inmanejable está a exactamente tres niveles de profundidad. Hoy vamos a ver cómo organizar tus datos: el Object Model. Unity Catalog pone orden en tus datos mediante una jerarquía estricta y predecible. El contenedor de nivel más alto es el metastore, que guarda los metadatos de tu organización. Pero tus interacciones diarias dependen del namespace principal de tres niveles. Cada query que escribes apunta a un asset usando el formato catalog punto schema punto object. El primer nivel es el catalog. Esto proporciona un límite amplio para los data assets. Normalmente usas los catalogs para separar entornos lógicamente, como tener un catalog para producción y otro completamente distinto para desarrollo. El segundo nivel es el schema, al que también se le llama base de datos. Los schemas viven dentro de los catalogs y organizan datasets relacionados. Podrías crear un schema para los eventos raw ingeridos y otro para analíticas refinadas. El tercer nivel es el object en sí. Esta es tu tabla real, una view o un volume que contiene archivos no tabulares. Al forzar esta convención de nombres de tres partes, Unity Catalog le da a cada dato una dirección clara e inequívoca. Cuando un analista hace una query a production punto sales punto customers, la ubicación, la fase del ciclo de vida y el propósito de esos datos son evidentes al instante. Aquí está la clave. Una vez que llegas al nivel de tabla, tienes que entender cómo interactúa Unity Catalog con tu almacenamiento real. Hay dos tipos principales de tablas: managed tables y external tables. Las managed tables son las que vienen por defecto. Cuando creas una managed table, Unity Catalog es el owner tanto de los metadatos como de los datos subyacentes. Se encarga del layout de los archivos y gestiona todo el ciclo de vida de los datos. Los archivos reales se guardan en una storage location designada que configuras a nivel de metastore, catalog o schema. Las external tables funcionan de forma diferente. Usas una external table cuando ya tienes archivos en un bucket de cloud storage y quieres dejarlos exactamente donde están. Con una external table, Unity Catalog registra la estructura y gobierna el acceso, pero solo es el owner de los metadatos. Tú mantienes el control total sobre los archivos físicos. Esta distinción se vuelve crítica durante las operaciones destructivas. Imagina un escenario donde un data engineer ejecuta accidentalmente un comando drop table. Si hace un drop de una managed table, Unity Catalog elimina la tabla del metastore y borra automáticamente los archivos subyacentes de tu cloud storage. Los datos se destruyen. Si hace un drop de una external table, Unity Catalog simplemente elimina el enlace de los metadatos. La tabla desaparece de la interfaz de tu workspace, pero los archivos raw en tu cloud storage permanecen perfectamente intactos y sin tocar. Usa siempre managed tables cuando quieras que el catalog optimice y gobierne todo el ciclo de vida del storage, y reserva las external tables para los datos que necesites proteger de un borrado accidental o compartir directamente con otros sistemas externos. Gracias por estar ahí. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 5 de 15. Es fácil restringir quién ve una columna en una base de datos relacional, pero ¿cómo aplicas el control de acceso a un bucket de cloud storage lleno de miles de PDFs raw? La respuesta es dominar los datos no estructurados con Volumes. Antes de explicar cómo funcionan, aclaremos una confusión común. Los Volumes son estrictamente para el acceso a archivos basado en paths. No son para datos tabulares. Si consultas filas y columnas con SQL, usas una tabla. Si lees imágenes, documentos de texto o archivos de audio, usas un Volume. Un Volume es un objeto dentro de Unity Catalog. Representa un espacio de almacenamiento lógico en tu entorno cloud. Al crear un Volume, pones los datos no estructurados bajo el mismo paraguas de seguridad que tus tablas estructuradas. En lugar de gestionar identity policies en AWS o role assignments en Azure solo para leer un archivo, controlas el acceso usando permisos estándar directamente en Databricks. Imagina un hospital que entrena un modelo de machine learning para detectar anomalías en imágenes de rayos X. No pueden meter miles de imágenes de alta resolución en una tabla de base de datos. Necesitan guardarlas como archivos raw en un cloud object storage. Como son archivos de pacientes muy confidenciales, una gobernanza estricta es fundamental. Al meter las radiografías dentro de un Volume de Databricks, el equipo de ingeniería puede controlar exactamente qué data scientists tienen permiso para leer ese directorio específico. Hay dos tipos de Volumes: managed y external. Un managed Volume es administrado completamente por Databricks. Cuando creas uno, no especificas un storage path. Databricks simplemente reserva espacio en la storage location por defecto asignada a tu schema actual. Subes los archivos directamente ahí. Si alguna vez haces drop de un managed Volume, Databricks también borra los archivos subyacentes. Esto los hace ideales para archivos temporales del workspace o datos generados completamente dentro de tus pipelines de Databricks. Un external Volume apunta a un directorio de cloud storage existente que ya posees. Primero, registras un path de cloud storage como una external location en Unity Catalog. Luego, creas un Volume sobre ella. Esto te da una gobernanza estricta sobre los datos generados por otros sistemas. Si una aplicación independiente escribe archivos de log en un bucket de Azure Data Lake, un external Volume permite a los usuarios de Databricks leer esos archivos de forma segura. Si haces drop de un external Volume, se borran los metadatos, pero los archivos subyacentes en tu cloud bucket se quedan completamente intactos. Este enfoque basado en paths es exactamente lo que requiere la IA moderna. Las librerías open-source de machine learning normalmente esperan leer datos de un file system local. No saben cómo autenticarse con las interfaces propietarias de cloud storage. Los Volumes solucionan esto exponiendo un path de directorio que se ve y se comporta como una carpeta local estándar. Tu script de entrenamiento del modelo simplemente abre un file path. Unity Catalog intercepta esa request y verifica los permisos del usuario de forma transparente. Aquí está la clave. Los Volumes eliminan la desconexión entre cómo gestionas tus bases de datos estructuradas y cómo proteges tus archivos raw, permitiéndote ejecutar workloads de machine learning sobre datos no estructurados sin saltarte la seguridad empresarial. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 6 de 15. Si tus ingenieros de datos aún pegan las cloud access keys directamente en sus scripts, tu empresa está a un error de sufrir una brecha de datos masiva. La solución para conectar de forma segura tu workspace y tu cloud storage sin exponer secretos es Bulletproof Cloud Security: External Locations. Cuando un usuario inicia sesión en Databricks, utiliza un identity token. Ese token demuestra quién es ante el workspace. Pero esa identidad no significa absolutamente nada para tu cloud provider subyacente, ya sea AWS, Azure o Google Cloud. Para leer un archivo de un cloud bucket, el propio workspace necesita autenticarse con la infraestructura cloud. Históricamente, los desarrolladores sorteaban esta desconexión hardcodeando las claves IAM cloud directamente en sus notebooks o variables de entorno. Esto crea una grave vulnerabilidad de seguridad, ya que cualquiera con acceso de lectura al código puede robar las claves. Unity Catalog resuelve esto mediante una abstracción estricta de dos partes. La primera parte es la Storage Credential. Una Storage Credential representa un mecanismo de autenticación y autorización directamente vinculado a tu cloud provider. Se mapea a un rol IAM en AWS, una Managed Identity en Azure o una Service Account en Google Cloud. En lugar de entregar raw cloud keys a un desarrollador, tu administrador cloud otorga privilegios de acceso a esta Storage Credential. Unity Catalog tiene la autoridad para asumir este rol, manteniendo la credencial real completamente fuera del alcance de los usuarios del workspace. Ahora bien, una Storage Credential por sí sola es demasiado amplia. Ese rol IAM podría tener permiso para acceder a docenas de buckets diferentes en tu entorno cloud. Aquí es donde entra en juego la segunda parte. Una External Location asocia una Storage Credential con una ruta de cloud storage específica, como la URI de un bucket de S3 o la ruta de un contenedor de Azure Data Lake Storage. Define exactamente dónde se le permite operar a esa credencial. Puedes pensarlo como un límite geográfico para tus credenciales cloud. Pongamos un escenario concreto. Un desarrollador necesita analizar los logs del sistema almacenados en un bucket de S3 altamente seguro. En un setup legacy, un administrador generaría access keys de AWS y se las enviaría al desarrollador, esperando que no hiciera commit accidentalmente de esas claves en un repositorio de código público. Con Unity Catalog, el workflow cambia por completo. El administrador crea una Storage Credential configurada con un rol IAM que puede leer el bucket de destino. A continuación, el administrador crea una External Location que apunta estrictamente a la ruta de S3 que contiene los logs del sistema, y le asocia esa Storage Credential. Finalmente, usando SQL estándar, el administrador otorga al desarrollador permiso para leer archivos exclusivamente en esa External Location. Cuando el desarrollador ejecuta una query contra los logs, Unity Catalog interviene y gestiona de forma transparente la autenticación cloud en su nombre. El desarrollador nunca ve una clave de AWS. No gestiona secretos ni configura cloud profiles. Simplemente lanza la query a la ruta permitida. Más adelante, puedes crear external tables o external volumes directamente sobre esta ubicación para organizar mejor los datos. Si el desarrollador se cambia a otro equipo, el administrador simplemente revoca su permiso a la External Location dentro de Databricks. La configuración IAM cloud subyacente permanece completamente intacta. Aquí está la clave. Las External Locations desacoplan la seguridad de tu infraestructura cloud de la gobernanza de tu acceso diario a los datos. Al mantener los roles IAM fuera del código de usuario y anclarlos a rutas explícitas, garantizas que cada petición de datos sea auditada, segura y restringida exclusivamente a los datos que deseas compartir. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 7 de 15. Los ingenieros de datos dedican una cantidad increíble de tiempo a intentar evitar que fallen los frágiles scripts de ingesta de API. Cuando un endpoint cambia su lógica de paginación o baja el rate limit, tu pipeline falla y te pasas la tarde depurando JSON en lugar de crear modelos de datos. La solución a este dolor de cabeza en concreto es Lakeflow Connect. Antes de ver cómo funciona, vamos a aclarar una confusión habitual con los nombres. Databricks tiene Lakeflow Jobs y Lakeflow Connect. Lakeflow Jobs se encarga de la orquestación, es decir, ejecuta tareas en una secuencia específica. Lakeflow Connect se centra exclusivamente en la ingesta. Es el mecanismo para llevar raw data desde sistemas externos a tu entorno de Databricks. En esencia, Lakeflow Connect proporciona Managed Connectors. Se trata de integraciones nativas, diseñadas específicamente para aplicaciones y bases de datos empresariales. Normalmente, cuando necesitas extraer datos de sistemas externos, escribes código Python a medida. Ese código tiene que gestionar la autenticación, manejar los reintentos cuando el servidor pierde la conexión, controlar qué registros ya se han ingerido y parsear una paginación compleja. Los Managed Connectors eliminan por completo toda esa capa de infraestructura a medida. Databricks se encarga del compute subyacente, las interacciones con la API y el state tracking necesario para las lecturas incrementales. Dado que Lakeflow Connect se ejecuta sobre serverless compute, no necesitas configurar ni gestionar clústeres solo para traerte los datos. El servicio escala automáticamente según el volumen de datos entrantes. Además, se integra directamente con Unity Catalog, lo que significa que los datos que ingieres quedan gobernados de inmediato y disponibles para hacer queries. Imagina un requisito estándar. Tu equipo de marketing necesita datos actualizados de Salesforce en tu lakehouse. Si montas esto desde cero, podrías pasarte una semana escribiendo un script a medida que haga queries a la API de Salesforce. Tienes que escribir la lógica para mantenerte por debajo de los estrictos límites de la API, gestionar los refrescos de tokens y hacer un merge de las actualizaciones en tus tablas Delta existentes sin duplicar registros. Con un Managed Connector en Lakeflow Connect, te saltas por completo el código a medida. Proporcionas las credenciales de conexión, seleccionas los objetos específicos de Salesforce que quieres seguir, y configuras un catálogo y un schema de destino. La configuración solo lleva unos minutos. Databricks se encarga de la ejecución. Se trae el snapshot histórico inicial de tus datos y luego pasa a capturar continuamente los cambios incrementales a medida que ocurren. Aquí está la clave. Al pasar la carga de trabajo de ingesta a un Managed Connector, dejas de mantener scripts de polling. Cuando cambia la especificación de una API externa, Databricks actualiza el conector por detrás. Tu pipeline simplemente sigue funcionando. Esto te libera para centrarte en la lógica de negocio real, como transformar raw data en tablas agregadas o entrenar modelos de machine learning, en lugar de estar cuidando de un script de extracción roto. El verdadero valor de Lakeflow Connect no es solo lo rápido que se configura, sino la eliminación permanente del código de ingesta a medida de tu backlog de mantenimiento. Si quieres ayudar a que el programa siga adelante, puedes buscar DevStoriesEU en Patreon y apoyarnos por allí. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 8 de 15. Tienes un pipeline ETL complejo donde una tabla se actualiza cada hora, otra continuamente, y orquestar las dependencias requiere cientos de líneas de código de state management. ¿Y si pudieras simplemente declarar las tablas finales que quieres, y dejar que el engine construya la infraestructura para mantenerlas actualizadas? Esa es la premisa del ETL automatizado usando pipelines declarativos. En un pipeline imperativo tradicional, le dices al sistema exactamente cómo hacer su trabajo. Escribes el código para gestionar los checkpoints, manejar los retries, mapear las dependencias y provisionar clústeres. Los pipelines declarativos le dan la vuelta a este modelo. Simplemente indicas cómo debería quedar la tabla final, normalmente con una query SQL estándar o una función de Python. El engine subyacente construye el execution graph, gestiona la infraestructura y maneja las state transitions automáticamente. Para que esto funcione, Databricks se basa en dos tipos de tablas específicos. Un error común es tratarlas como intercambiables. No lo son. Debes separar claramente tus datos de eventos append-only de tus agregaciones complejas. El primer tipo es la Streaming Table. Las Streaming Tables están diseñadas estrictamente para un procesamiento incremental y append-only. Leen de forma continua o en batches desde un data source, procesan solo los registros nuevos y les hacen append en el target. Imagina procesar un stream masivo de clics de una web que vienen de Kafka. Escribes una query para poblar una Streaming Table desde ese topic de Kafka. No escribes código para trackear los offsets ni recordar qué mensajes ya se han leído. El pipeline mantiene el state internamente, asegurando que cada clic se procese exactamente una vez, incluso si el sistema se reinicia. Ahora, la segunda parte de esto. Una vez que tienes tus raw events almacenados de forma segura, normalmente necesitas transformarlos. Aquí es donde entran en juego las Materialized Views. Mientras que las Streaming Tables gestionan el ingest inicial de nuevos datos, las Materialized Views están diseñadas para agregaciones complejas, joins y registros que se actualizan o eliminan con el tiempo. Volviendo a los clics de nuestra web, necesitas un dashboard ejecutivo diario que muestre el total de clics agrupados por región. Defines una Materialized View que hace un select de tu Streaming Table y ejecuta la agregación. Cuando el pipeline se ejecuta, el engine evalúa la Materialized View. Determina la forma más eficiente de actualizar la vista. Si puede computar los cambios de forma incremental, lo hará. Si es necesario un recompute completo, lo gestiona automáticamente. Nunca tienes que escribir la lógica que dicta cuándo hacer refresh o cómo hacer merge de las nuevas agregaciones. Aquí está la clave. Como defines tanto las Streaming Tables como las Materialized Views de forma declarativa, el engine de Databricks entiende todo el lineage de tus datos. Sabe que la Materialized View depende de la Streaming Table. Las enlaza en un pipeline graph unificado. Si un compute node falla a mitad del procesamiento, el pipeline se basa en ese graph para pausar, hacer retry y reanudar sin duplicar registros ni corromper el dashboard final. Tu codebase ya no está saturado de scaffolding operativo. Solo contiene la lógica de negocio pura que define cómo fluyen los datos desde el source hasta el destination. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 9 de 15. Si tu procesamiento de datos nocturno depende de una chain de cron schedules independientes, básicamente estás cruzando los dedos para que el paso anterior haya terminado a tiempo. Vas a ciegas. Para evitar fallos silenciosos y garantizar el orden de ejecución, necesitas Master Orchestration con Lakeflow Jobs. Primero, una pequeña aclaración. Las Lakeflow Pipelines gestionan las dependencias de datos a nivel de tabla. Los Lakeflow Jobs, en los que nos vamos a centrar ahora, orquestan tareas a nivel macro. Imagina las pipelines moviendo datos dentro del data warehouse, mientras que los jobs enlazan notebooks, scripts de Python y modelos de machine learning en un workflow más grande. Un job en Databricks es el contenedor principal de tu orquestación. Dentro de ese contenedor, defines múltiples tareas. Una tarea es una única unidad de trabajo aislada. Podría ser ejecutar un notebook de Databricks, hacer submit de una aplicación Spark, ejecutar un proyecto dbt o lanzar una query SQL. Al vincular estas tareas entre sí, construyes un grafo de ejecución donde una tarea solo empieza cuando sus prerrequisitos específicos se completan con éxito. Veamos un caso práctico para ver cómo el control flow gestiona la fiabilidad. Tienes un proceso diario que ingiere raw data, comprueba su calidad, lo transforma y alerta al equipo si algo sale mal. Empiezas definiendo una tarea de ingesta. A continuación, vinculas una tarea de data quality que se ejecuta estrictamente después de que termine la ingesta. Aquí está la clave. En lugar de escribir un error handling a medida dentro de tu código Python para decidir qué pasa después, utilizas el control flow nativo del job. Añades una tarea de condición if-else justo después del quality check. La condición evalúa una variable devuelta por tu tarea de comprobación de datos. Si los datos están limpios, el job sigue la rama if y lanza tu tarea de transformación downstream. Si los datos están corruptos, el job toma la rama else y lanza una tarea de webhook que hace ping a un canal de Slack. También gestionas el estado usando condiciones de tarea run-if. Puedes configurar una tarea de alerta para que se ejecute solo si la tarea anterior ha fallado por completo, mientras que el resto de la pipeline se detiene de forma segura. Esto evita la clásica cascada de fallos silenciosos, donde un paso de ingesta roto lanza silenciosamente un modelo de machine learning para que se entrene con tablas completamente vacías. Para iniciar este workflow, aplicas un trigger. Los jobs pueden ejecutarse on demand, en un intervalo programado tradicional o de forma continua. También pueden ejecutarse en función de un evento, como la llegada de un nuevo archivo a un bucket de cloud storage externo. Una vez que salta el trigger, Databricks proporciona observabilidad built-in. No tienes que adivinar dónde se produjo un fallo. La plataforma registra un historial de ejecución completo con una matrix view, mostrándote exactamente qué tarea tuvo éxito, qué tarea se atascó y cuánto tiempo tardó cada paso. Puedes configurar notificaciones a nivel de job o a nivel de tarea para enviar emails automatizados o webhooks en el momento en que cambie un estado de ejecución. El verdadero valor de este modelo de orquestación es sacar el failure handling de tus scripts individuales y llevarlo a la infraestructura de la plataforma, garantizando que tu sistema sepa exactamente cómo enrutar la ejecución cuando las cosas, inevitablemente, se rompan. Eso es todo por este episodio. Gracias por escuchar, ¡y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 10 de 15. Mover datos de tu data lake solo para que tu equipo de Business Intelligence pueda ejecutar queries es lento, caro y completamente innecesario. Terminas manteniendo pipelines frágiles solo para copiar datos de un sistema a otro, introduciendo retrasos y duplicando los costes de almacenamiento. Este es exactamente el problema que resuelve Databricks SQL. Existe la falsa creencia de que Databricks es estrictamente para ingenieros y científicos de datos que escriben Python o Scala. Databricks SQL aclara esto. Es un workspace dedicado, construido completamente para profesionales de SQL. Imagina un equipo de Business Intelligence migrando desde un data warehouse legacy. Históricamente, esperaban a que los ingenieros ejecutaran jobs de extracción durante la noche para cargar los datos del data lake al data warehouse. Solo entonces podían empezar a crear informes. Databricks SQL elimina toda esa capa de extracción. Permite a los analistas ejecutar queries ANSI-SQL estándar directamente contra el data lake. Obtienes la escala masiva del storage de open lake, pero interactúas con él usando la interfaz rápida y familiar de un data warehouse relacional tradicional. El motor que impulsa estas queries es el Serverless SQL Warehouse. Un SQL warehouse es simplemente un recurso de compute configurado específicamente para workloads de SQL. En arquitecturas más antiguas, tenías que provisionar clústeres manualmente, configurar reglas de escalado y esperar varios minutos a que las máquinas virtuales arrancaran antes de ejecutar una query. Aquí está la clave. Como estos SQL warehouses son serverless, la capa de compute arranca casi al instante. Escala automáticamente cuando tus analistas lanzan workloads concurrentes pesados, y se detiene cuando las queries terminan. La gestión de la infraestructura queda completamente abstraída, dejando que los analistas se centren exclusivamente en sus datos. Para escribir y ejecutar estas queries, la plataforma ofrece un editor SQL integrado. Esta es la interfaz principal para explorar los datos. Dentro del editor, los usuarios pueden escribir SQL estándar, navegar por catálogos de datos, examinar esquemas de tablas y ver historiales de ejecución. Cuando una query devuelve datos, el analista no tiene que exportarlos para entenderlos. Pueden crear visualizaciones directamente en el editor y organizar esas visualizaciones en dashboards personalizados que se actualizan automáticamente. La plataforma también incluye una función de alertas. Los analistas pueden escribir una query que compruebe una métrica específica, y configurar el sistema para que envíe un email o una notificación web si esa métrica cruza un umbral definido. Muchas organizaciones ya tienen herramientas de visualización establecidas. Databricks SQL se integra directamente con herramientas estándar de terceros como Power BI y Tableau. Estas aplicaciones externas se conectan al Serverless SQL Warehouse y tratan el data lake exactamente como si fuera una base de datos de alto rendimiento. El cambio aquí trata fundamentalmente sobre la proximidad a tus datos. Al llevar compute de nivel data warehouse y SQL estándar directamente al data lake, dejas de copiar datos y empiezas a analizar tu single source of truth en el momento en que llega. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 11 de 15. Si tres departamentos diferentes crean tres dashboards distintos para el seguimiento de ingresos y presentan tres cifras diferentes en la reunión ejecutiva, no tienes un problema de data pipeline. Tienes un problema de semantic layer. La solución es establecer una semantic layer como única fuente de la verdad, y en Databricks SQL, esto lo haces usando Metric Views. Los datos raw rara vez están estructurados de la forma en que piensan los usuarios de negocio. Las tablas de la base de datos contienen nombres de columna oscuros, joins complejos y logs de transacciones raw. Una semantic layer salva esta brecha traduciendo esos datos subyacentes a conceptos de negocio familiares. Veamos un escenario clásico donde esto falla. Tu equipo de marketing y tu equipo de finanzas hacen informes sobre los Monthly Active Users. Marketing escribe una query en su dashboard que cuenta a cualquiera que haya abierto la aplicación. Finanzas escribe una query diferente en una herramienta distinta que solo cuenta a los usuarios que han completado una transacción. Ambos equipos llaman a su métrica Monthly Active Users. Cuando los números chocan, la confianza de la organización en los datos se desmorona. Definir los Monthly Active Users como una Metric View dentro de Unity Catalog soluciona esto para siempre. Para entender por qué, necesitamos aclarar qué es realmente esta feature. Una Metric View no es lo mismo que una SQL View estándar. Una SQL View estándar simplemente guarda una query que devuelve filas y columnas raw, dejando totalmente en manos del usuario final la decisión de cómo sumar, promediar o agrupar esos datos más adelante. Una Metric View es mucho más estricta. Impone cálculos de agregación y dimensionalidad específicos directamente a nivel del catalog. Cuando creas una Metric View, fijas la lógica de negocio exacta. Defines la medida, como un distinct count de user IDs basado en criterios de transacción específicos. También defines las dimensiones permitidas. Esto significa que dictas explícitamente que esta métrica solo se puede segmentar por atributos específicos, como la fecha de la transacción, la región del usuario o el tipo de dispositivo. Aquí está la clave. Una vez que esa Metric View se publica en Unity Catalog, se convierte en la única definición autorizada de Monthly Active Users para toda la empresa. Cuando los analistas se conectan a Databricks SQL, no escriben lógica personalizada para agregar los datos. No hacen joins de tablas ni escriben cláusulas where para filtrar los estados activos. Simplemente consultan la Metric View. Esto desacopla por completo la definición de la métrica de la presentation layer. No importa si Marketing usa Tableau, Finanzas usa Power BI y el equipo de producto usa dashboards nativos de Databricks. La herramienta de Business Intelligence simplemente pide la métrica, y Databricks realiza el cálculo predefinido en el server side. Como la lógica vive de forma centralizada en Unity Catalog, es imposible que los diferentes departamentos inventen sus propios cálculos por accidente. Todos obtienen exactamente el mismo número, garantizando una coherencia perfecta en toda la organización. El verdadero poder de una semantic layer no es la eficiencia técnica; es sacar la lógica de negocio de las herramientas downstream desconectadas e integrarla directamente en la base de la propia plataforma de datos. Eso es todo por este episodio. Gracias por escuchar, ¡y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 12 de 15. ¿Qué pasaría si tu director de ventas pudiera simplemente mandarle un mensaje a tu data warehouse para obtener insights de negocio al instante, sin tener que abrir un ticket al equipo de datos? Las peticiones de datos ad-hoc interrumpen constantemente los workflows de ingeniería, y los usuarios de negocio odian esperar días para una simple query. La solución a este cuello de botella es una feature de Databricks llamada Genie Spaces, que forma parte de su oferta más amplia de AI/BI. AI/BI es un producto de business intelligence construido sobre un sistema de IA compuesto. Está diseñado para comprender la semántica específica de tus datos. Genie Spaces sirven como la interfaz conversacional para este sistema. Un Genie Space se ve y se siente como una aplicación de chat estándar, pero está conectado directamente a tu data warehouse. Los usuarios de negocio escriben preguntas en lenguaje natural, y Genie responde con datos reales, visualizaciones y respuestas. Cuando la gente oye hablar de una IA lanzando queries a los datos, inmediatamente se preocupa por las alucinaciones. Asumen que el modelo adivinará los nombres de las columnas, inventará métricas o devolverá respuestas incorrectas con total confianza. Genie evita esto basándose completamente en los metadatos gobernados almacenados en tu Unity Catalog. No está enviando un prompt a ciegas a un modelo de lenguaje genérico. La IA está fundamentada en tu schema real, tus tipos de datos, tus relaciones de foreign key y las métricas predefinidas que tu equipo ha establecido. Para que esto funcione, un analista primero crea y configura el Genie Space. Selecciona los datasets relevantes de Unity Catalog y proporciona un conjunto de instrucciones. Puede añadir queries de ejemplo, definir terminología de negocio específica y aclarar términos ambiguos. Por ejemplo, puede indicarle al sistema que cuando un usuario dice "cliente activo", se refiere específicamente a un cliente que ha comprado en los últimos noventa días. Este setup inicial limita el scope de la IA a un dominio bien definido. Cuando se hace una pregunta, el sistema orquesta múltiples pasos. Lee el prompt en lenguaje natural y comprueba el contexto proporcionado. Hace match entre la intención del usuario y las tablas y columnas exactas del catálogo. A continuación, genera una query SQL precisa, ejecuta esa query contra el compute engine de Databricks SQL y formatea los resultados. Imagina a un manager de ventas no técnico usando un Genie Space preparado. Escribe: "Muéstrame las ventas en Europa por producto del último trimestre". El sistema parsea la petición basándose en su entrenamiento. Reconoce "Europa" como una dimensión de región, localiza las tablas de productos y traduce "último trimestre" a un filtro de fecha preciso. En cuestión de segundos, la IA genera el SQL, lo ejecuta y devuelve un gráfico interactivo mostrando el desglose. Si el manager luego responde: "Ahora excluye Alemania", Genie modifica la query subyacente y actualiza el gráfico al instante, manteniendo el contexto conversacional. Este workflow cambia fundamentalmente cómo se gestionan las peticiones ad-hoc. Los data engineers y analistas dedican una parte enorme de su semana a escribir queries SQL one-off para los stakeholders. Mover esta exploración a Genie Spaces da a los stakeholders de negocio respuestas inmediatas, mientras libera tiempo de ingeniería para tareas complejas. Además, todo el proceso se mantiene completamente gobernado. Genie respeta estrictamente todos los controles de acceso a nivel de fila y columna definidos en Unity Catalog. Si el usuario que hace la pregunta no tiene permiso para ver datos financieros sensibles, la IA simplemente no lanzará la query. Aquí está el insight clave. La eficacia de la exploración de datos conversacional está determinada por la calidad de tu modelo de datos y metadatos subyacentes, no solo por la inteligencia del modelo de lenguaje. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 13 de 15. Entrenar un modelo de machine learning es la parte divertida, pero hacer el deploy como una API REST segura y de alta disponibilidad es donde la mayoría de los proyectos de data science van a morir. Pasar de un experimento en un notebook a un endpoint listo para producción requiere configurar el escalado, el load balancing y una gobernanza estricta. Para resolver esto, usas Mosaic AI Model Serving. Esta feature proporciona una interfaz unificada para hacer deploy, gobernar y consultar modelos de IA. Un error común es pensar que Databricks Model Serving solo sirve para modelos que tú mismo entrenas dentro de Databricks. Eso es incorrecto. En realidad, actúa como un AI Gateway central. Maneja tres tipos distintos de modelos: modelos custom, foundation models y modelos externos. Primero, los modelos custom. Estos son los modelos que construyes, logueas con MLflow y registras en Unity Catalog. Model Serving aprovisiona un container serverless, carga las dependencias de tu modelo y lo expone como una API REST. Tú no gestionas la infraestructura. Escala hacia arriba cuando hay picos de tráfico y escala a cero cuando está idle. Segundo, los foundation models alojados en Databricks. Son grandes modelos open-source que Databricks aloja en compute optimizado. Obtienes acceso instantáneo a arquitecturas state-of-the-art sin preocuparte por el provisioning de GPUs. Tercero, los modelos externos. Aquí es donde configuras endpoints que apuntan a servicios de terceros. ¿Por qué enrutar el tráfico externo a través de Databricks en lugar de llamar directamente a los proveedores externos? Piensa en la gobernanza y el control de costes. Supón que tu empresa quiere usar GPT-4 para una aplicación interna. Si cada developer hardcodea una API key en su script, pierdes visibilidad. No puedes monitorizar estrictamente los costes, gestionar los rate limits, ni aplicar filtros para evitar que los empleados envíen datos sensibles de clientes a un proveedor externo. Al enrutar todas las requests a través de Mosaic AI Model Serving, fuerzas ese tráfico a través de un único gateway seguro. Gestionas un único set de credenciales. Aplicas controles de acceso a través de Unity Catalog, dictando exactamente quién o qué puede consultar el modelo. También obtienes un tracking centralizado del uso, los errores y la latencia. El flujo lógico es sencillo. Defines un serving endpoint en Databricks. Para un modelo custom, apuntas el endpoint a un modelo de MLflow registrado y defines el tamaño del compute y los límites de escalado. Databricks gestiona la containerization automáticamente. Para un modelo externo, proporcionas el nombre del proveedor externo y una API key almacenada de forma segura. Una vez que el endpoint está activo, tus aplicaciones downstream envían un payload JSON estándar mediante una request HTTP a la URL del endpoint. La respuesta vuelve en un formato consistente, independientemente de si el modelo se está ejecutando en compute serverless de Databricks o si está en un data center externo. Aquí está la clave. Mosaic AI Model Serving elimina la fricción del deployment a la vez que refuerza la seguridad. Estandariza tu capa de aplicación, de modo que tu código cliente solo se comunica con un único endpoint de Databricks, completamente abstraído de dónde o cómo se aloja el modelo subyacente. Por cierto, si quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 14 de 15. Tienes diez mil logs raw de soporte al cliente en una tabla de base de datos, y el negocio necesita que estén resumidos y categorizados por sentimiento para el final del día. Normalmente, extraer este tipo de insights requiere un pipeline de Python complejo, una gestión cuidadosa de las API keys y una lógica custom de batching para pasarle el texto a un Large Language Model. ¿Y si pudieras ejecutar todo ese workload con un comando básico de base de datos? Ese es precisamente el problema que resuelven las AI Functions, que integran los LLMs directamente en tus queries SQL. Las AI Functions cierran la brecha entre la Generative AI de vanguardia y la analítica de datos del día a día. Cogen una capacidad que normalmente requiere ingeniería especializada en Machine Learning y se la dan a cualquiera que sepa escribir SQL. En lugar de montar una infraestructura separada para extraer datos, enviarlos a un modelo y volver a escribir las predicciones, las AI Functions llevan el modelo directamente a donde ya viven los datos. La herramienta principal para esto es un comando built-in llamado A I query. Lo usas exactamente igual que una función estándar de procesamiento de texto dentro de un select. Le pasas el nombre del endpoint del modelo que quieres usar, y luego le pasas el prompt. Volviendo a esos diez mil logs de soporte, tu workflow se vuelve trivial. Escribes una query haciendo un select de tu ID de cliente y el texto del log. Luego, añades una nueva columna usando la función A I query. Tu prompt le dice al modelo que lea el texto, extraiga la queja principal y determine si el sentimiento es positivo, neutral o negativo. Le pasas la columna que contiene el texto raw de tu log a ese prompt. Cuando ejecutas la query, el motor de la base de datos distribuye automáticamente esta request. Procesa cada una de las filas a través del Large Language Model especificado. El modelo evalúa el texto y devuelve el resumen y el sentimiento. Como todo esto ocurre en SQL, el output llega como columnas estructuradas estándar. Puedes filtrar inmediatamente los resultados para mostrar solo el sentimiento negativo, hacer un join de esos resultados con una tabla de facturación de clientes, y agregar los datos para descubrir qué producto está causando más frustración. Aquí está el insight clave. Podrías pensar que dar acceso a los analistas de datos a los Large Language Models significa distribuir API keys sensibles por toda tu organización. No es así. Las AI Functions están estrechamente integradas con Databricks Model Serving. Las conexiones reales a modelos externos, o a modelos open-source self-hosted, las configuran los administradores a nivel de plataforma. El analista de datos nunca ve una API key, un token o un secret. Solo hace referencia al nombre del endpoint preconfigurado en su query. Toda la operación permanece completamente segura. Cada query queda registrada en los logs, y todos los controles de acceso aplicados a los datos y a los modelos se cumplen estrictamente mediante el framework de gobernanza de la plataforma. Al eliminar la fricción de la infraestructura y la gestión de credenciales, cambias la naturaleza de la exploración de datos. Transformas el análisis complejo de texto no estructurado en una simple operación de filtrado, mejorando al instante el poder analítico de todo tu equipo. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. Databricks, episodio 15 de 15. Tu chatbot estándar es educado, informativo y completamente pasivo. Puede decirte cómo arreglar una pipeline rota basándose en un manual, pero no puede arreglar la pipeline por ti. Pasar de una IA que solo habla a una IA que ejecuta tareas activamente requiere un cambio fundamental en la arquitectura. Ese cambio es el Agent Framework de IA. Aclaremos de inmediato una confusión común. La gente suele confundir las aplicaciones simples de Retrieval-Augmented Generation con verdaderos agentes. Una aplicación RAG es esencialmente un motor de búsqueda con un modelo de lenguaje encima. Recupera documentos y los resume. Solo lee. Un verdadero agente de IA tiene herramientas. Puede escribir. Puede ejecutar queries SQL, lanzar jobs y llamar a APIs externas. Cambia el estado de tus sistemas. El Agent Framework de Databricks proporciona la infraestructura para construir, evaluar y hacer deploy de estos agentes autónomos de forma segura dentro del Lakehouse. El mecanismo central aquí es el tool calling combinado con el razonamiento multi-step. En lugar de generar una respuesta de una sola vez, el modelo de lenguaje actúa como un motor de razonamiento. Le das un objetivo y un conjunto de herramientas, que son básicamente funciones que has definido. El agente decide qué herramienta usar, espera el resultado y luego decide qué hacer a continuación. Piensa en un agente diseñado para monitorizar data pipelines. Cuando ocurre un fallo, el agente no se queda ahí sentado esperando un prompt del usuario. El framework le permite lanzar un workflow. Primero, el agente necesita contexto. Utiliza una custom tool que le has proporcionado para ejecutar una query SQL contra los logs de tu sistema en Databricks. El framework ejecuta esta query y le devuelve el resultado al agente. Aquí está la clave. El agente evalúa esos logs, identifica la root cause del fallo y pasa a su siguiente paso. Se da cuenta de que el equipo de ingeniería necesita saberlo. Así que selecciona otra herramienta, una integración de API con la aplicación de chat de tu empresa. Llama a esa herramienta para redactar y enviar un mensaje detallando el error exacto y la solución propuesta. Esto es razonamiento multi-step en acción. El agente planificó una secuencia, ejecutó código, observó el resultado y lo comunicó, todo de forma autónoma. Darle a un modelo de lenguaje la capacidad de ejecutar queries y llamar a APIs es un riesgo de seguridad enorme si se gestiona mal. Por eso, el enfoque de Databricks acopla estrechamente el Agent Framework con Unity Catalog. Cuando haces deploy de un agente usando Databricks Model Serving, no le estás dando acceso total a tu infraestructura. Registras tus herramientas como funciones específicas dentro de Unity Catalog. Unity Catalog impone una gobernanza estricta sobre lo que esas funciones pueden hacer. Si le das a un agente una herramienta para hacer queries a tablas de logs, Unity Catalog se asegura de que solo pueda leer esas tablas específicas. Si el modelo de lenguaje alucina e intenta usar la herramienta SQL para eliminar una base de datos de producción, el framework lo detiene porque la función subyacente carece de los permisos necesarios. El agente está estrictamente limitado por las reglas de gobernanza de tu Lakehouse. Esta capacidad transforma el Lakehouse de una capa de almacenamiento pasiva a un entorno activo y automatizado. Al terminar esta serie, te animo a que revises la documentación oficial e intentes construir tú mismo un agente sencillo de tool-calling. Si quieres sugerir temas para nuestra próxima serie, pásate por devstories dot eu. La transición de chatbots a agentes es el cambio fundamental en la forma en que desarrollamos aplicaciones de IA hoy en día. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!