Conceptos clave de Databricks Apps

En este artículo se presentan los conceptos básicos de Las aplicaciones de Databricks, incluido cómo se estructuran las aplicaciones, cómo administran las dependencias y el estado, cómo funcionan los permisos y cómo interactúan las aplicaciones con los recursos de la plataforma. Comprender estos conceptos ayuda a desarrollar, implementar y administrar aplicaciones en el área de trabajo.

App

Una aplicación de Databricks es una aplicación web que se ejecuta como un servicio en contenedor en la plataforma sin servidor de Azure Databricks. Los desarrolladores usan marcos compatibles, como Streamlit, Dash o Gradio, para crear aplicaciones que proporcionan datos interactivos o experiencias de inteligencia artificial dentro de un área de trabajo de Azure Databricks.

Cada aplicación incluye su propia configuración, identidad y entorno en tiempo de ejecución aislado. Dado que las aplicaciones pertenecen a un área de trabajo específica, pueden acceder a recursos de nivel de área de trabajo, como almacenes de SQL y recursos de nivel de cuenta, como catálogo de Unity. Los desarrolladores también pueden optar por compartir aplicaciones con usuarios fuera del área de trabajo, pero dentro de la misma cuenta de Azure Databricks.

Aunque el contenedor de aplicaciones se ejecuta en la infraestructura sin servidor de Azure Databricks, la propia aplicación puede conectarse a recursos sin y con servidor. Conceptualmente, una aplicación actúa como un servicio de plano de control que hospeda una interfaz de usuario web y accede a los servicios de plano de datos de Azure Databricks disponibles. Para más información, consulte la introducción a la arquitectura de Databricks.

Para iniciar y administrar aplicaciones, vaya a la sección Aplicaciones de la interfaz de usuario del área de trabajo.

URL de la aplicación

Databricks asigna automáticamente a cada aplicación una dirección URL única al crearla. La dirección URL sigue este formato:

https://<app-name>-<workspace-id>.<region>.databricksapps.com

Where:

• <app-name> es el nombre que se proporciona al crear la aplicación.
• <workspace-id> es el identificador único del área de trabajo.
• <region> es la región de nube donde se encuentra el área de trabajo.

No se puede cambiar la dirección URL después de crear la aplicación. Si necesita una dirección URL diferente, cree una aplicación con un nombre diferente.

Template

Una plantilla de aplicación es un scaffold precompilado que ayuda a los desarrolladores a empezar a compilar aplicaciones rápidamente mediante un marco compatible. Cada plantilla incluye una estructura de archivos básica, un app.yaml manifiesto, un requirements.txt archivo para aplicaciones de Python y código fuente de ejemplo.

El app.yaml archivo define el comando para ejecutar la aplicación (por ejemplo, streamlit run <app-name> para una aplicación Streamlit), configura variables de entorno locales y declara los recursos necesarios.

• Use requirements.txt para enumerar paquetes adicionales de Python para instalar con pip.
• Use package.json para enumerar los paquetes de Node.js para instalar con npm.

Estos archivos complementan el entorno del sistema predeterminado y los paquetes preinstalados. Para obtener más información, consulte Entorno del sistema de Databricks Apps.

Los desarrolladores pueden generar una nueva aplicación a partir de una plantilla mediante la interfaz de usuario o la CLI de Azure Databricks.

Entorno y paquetes del sistema

Databricks Apps se ejecuta en un entorno del sistema preconfigurado administrado por Azure Databricks. Para obtener más información, consulte Entorno del sistema de aplicaciones de Databricks.

Cada aplicación tiene su propio entorno aislado para evitar conflictos de dependencias. Para garantizar la coherencia, defina los paquetes necesarios y sus versiones en el archivo adecuado para la aplicación:

• Para Python, use requirements.txt.
• Para Node.js, use package.json.

En el caso de las implementaciones híbridas, es probable que tenga ambos archivos.

Durante la implementación, Azure Databricks instala estas dependencias en el entorno de tiempo de ejecución aislado de la aplicación. Si incluye un paquete que ya está preinstalado, la versión especificada invalida el valor predeterminado.

Consulte Administración de dependencias para una aplicación de Databricks para obtener más información.

Recursos de la aplicación

Los recursos de la aplicación son servicios nativos de Azure Databricks de los que depende una aplicación, como almacenes de SQL, modelos que sirven puntos de conexión, trabajos, secretos o volúmenes. Estas dependencias se declaran en el manifiesto de databricks.yml mediante el campo resources. Azure Databricks admite los siguientes tipos de recursos:

• Almacén de SQL
• Job
• Modelo de puntos de conexión de servicio
• Espacio de Genie
• Secret
• Volume

Para acceder a los servicios de Azure Databricks que aún no tienen un tipo de recurso compatible, use un secreto administrado por el catálogo de Unity para insertar credenciales de forma segura. Consulte Administración de secretos.

Hay dos fases para configurar los recursos de la aplicación:

• Declaración (desarrollo): declare cada recurso necesario en el manifiesto de databricks.yml. Esto define qué recursos necesita la aplicación y qué permisos requiere.
• Configuración (implementación): durante la implementación , use la interfaz de usuario de Aplicaciones de Databricks para configurar los recursos declarados con instancias específicas del área de trabajo reales (por ejemplo, seleccionar un almacenamiento SQL específico).

Esta separación entre la declaración y la configuración permite que las aplicaciones sean portátiles entre entornos. Por ejemplo, puede implementar el mismo código de aplicación en un área de trabajo de desarrollo y vincularlo a una instancia de SQL Warehouse. En producción, puede reutilizar el código y configurar un almacenamiento diferente sin realizar cambios en el código. Para admitir esto, evite codificar de forma rígida los identificadores de recursos o los valores específicos del entorno en la aplicación.

Azure Databricks aplica el acceso con privilegios mínimos. Las aplicaciones deben usar recursos existentes y no pueden crear otras nuevas. Durante la implementación, los administradores del área de trabajo revisan y aprueban el acceso solicitado de la aplicación a los recursos. La entidad de servicio de la aplicación recibe los permisos necesarios y el desarrollador de la aplicación debe tener permiso para concederlos.

Para más información, consulte Incorporación de recursos a una aplicación de Databricks.

Estado de la aplicación

Una aplicación puede tener uno de los siguientes estados: En ejecución, Detenido, Implementación o Bloqueado.

• En ejecución : la aplicación está activa y es accesible. Azure Databricks factura los recursos de proceso usados mientras se ejecuta la aplicación.
• Detenido: la aplicación no es accesible y no conlleva ningún coste. Azure Databricks conserva la configuración y el entorno de la aplicación, por lo que puede reiniciarla sin volver a configurarla.
• Implementación : la aplicación se está iniciando. Aún no es accesible y no incurre en cargos por el momento durante esta etapa.
• Se bloqueó - La aplicación no se pudo iniciar o se detuvo inesperadamente. No es accesible y no incurre en cargos. Puede ver los registros para solucionar problemas y reiniciar la aplicación una vez resuelto el problema.

Estado de la aplicación

El estado de la aplicación incluye cualquier dato o contexto que la aplicación necesite conservar en las sesiones de usuario o las interacciones. Las aplicaciones no conservan el estado en memoria después de reiniciarse. Los datos que se mantienen en la memoria se pierden cuando la aplicación se apaga.

Puede almacenar el estado de las maneras siguientes:

• Almacenamiento en memoria para datos temporales dentro de una sola sesión. Estos datos se pierden cuando se reinicia la aplicación.
• Sistema de archivos local para archivos temporales durante la ejecución de la aplicación. Estos datos se pierden cuando se reinicia la aplicación.
• Tablas de Azure Databricks para datos estructurados persistentes y cargas de trabajo de análisis mediante Databricks SQL.
• Archivos de área de trabajo para datos no estructurados persistentes.
• Volúmenes de catálogo de Unity para datos no estructurados persistentes con gobernanza de catálogos de Unity.

• Instancias de base de datos de Lakebase para datos relacionales persistentes con compatibilidad con PostgreSQL.

Entre los casos de uso comunes se incluyen el almacenamiento en caché de los resultados de la consulta, el guardado de preferencias del usuario o el registro de acciones de usuario entre sesiones.

Autenticación y autorización de aplicaciones

Databricks Apps usa OAuth 2.0 para la autenticación y el control de acceso. Cada aplicación tiene dos identidades complementarias que determinan cómo autentica y autoriza el acceso a los recursos de Azure Databricks: autorización de aplicaciones y autorización de usuario.

• Autorización de aplicaciones - Azure Databricks crea automáticamente un principal de servicio para cada aplicación. Esta entidad de servicio actúa como identidad de la aplicación y el desarrollador de la aplicación concede permisos. Todos los usuarios de la aplicación comparten esta identidad y tienen acceso al mismo conjunto de permisos. Este modelo es útil para las operaciones que no dependen del contexto del usuario individual, como el registro o las acciones de nivel del sistema.

• Autorización de usuario: este modelo usa la identidad del usuario de la aplicación para autenticar y autorizar el acceso. Los usuarios deben pertenecer a la cuenta de Azure Databricks donde se implementa la aplicación. Después de iniciar sesión mediante el inicio de sesión único (SSO), la aplicación puede usar las credenciales del usuario para acceder a los recursos regulados, como sql warehouse. Esto permite que la aplicación respete los permisos específicos administrados por el catálogo de Unity sin conceder esos permisos a la entidad de servicio de la aplicación.

Las aplicaciones solicitan ámbitos de OAuth específicos en su manifiesto para controlar a qué API y recursos pueden acceder. Este modelo flexible admite la seguridad de nivel empresarial y permite el control de acceso específico.

Para obtener más información, consulte Configuración de la autorización en una aplicación de Databricks.

Usuarios de la aplicación

Después de la implementación, los desarrolladores de aplicaciones pueden compartir una aplicación con usuarios o grupos concediéndole permiso CAN_USE o CAN_MANAGE en la instancia de la aplicación. Los usuarios no necesitan pertenecer al mismo área de trabajo, pero deben formar parte de la misma cuenta de Azure Databricks. Para compartir con usuarios externos, primero sincronícelos con la cuenta usando su proveedor de identidades. Para obtener más información, consulte Sincronizar usuarios y grupos de Microsoft Entra ID mediante SCIM.

También puede distribuir la misma aplicación en entornos de desarrollo, almacenamiento provisional y producción mediante canalizaciones de CI/CD e infraestructura como código. La interfaz de usuario de aplicaciones centralizada ayuda a los usuarios a detectar e iniciar aplicaciones que están autorizadas a usar.