Principais conceitos nos Aplicativos do Databricks

Este artigo apresenta os principais conceitos por trás dos Aplicativos do Databricks, incluindo como os aplicativos são estruturados, como eles gerenciam dependências e estado, como as permissões funcionam e como os aplicativos interagem com os recursos da plataforma. Entender esses conceitos ajuda no desenvolvimento, implantação e gerenciamento de aplicativos em seu workspace.

App

Um aplicativo da Databricks é uma aplicação web que é executada como um serviço em contêineres na plataforma sem servidor do Azure Databricks. Os desenvolvedores usam estruturas com suporte, como Streamlit, Dash ou Gradio, para criar aplicativos que fornecem dados interativos ou experiências de IA em um workspace do Azure Databricks.

Cada aplicativo inclui sua própria configuração, identidade e ambiente de runtime isolado. Como os aplicativos pertencem a um espaço de trabalho específico, eles podem acessar recursos no nível do espaço de trabalho, como SQL warehouses, e recursos de nível de conta, como o Catálogo do Unity. Os desenvolvedores também podem optar por compartilhar aplicativos com usuários fora do workspace, mas dentro da mesma conta do Azure Databricks.

Embora o contêiner do aplicativo seja executado na infraestrutura sem servidor do Azure Databricks, o próprio aplicativo pode se conectar a recursos com e sem servidor. Conceitualmente, um aplicativo atua como um serviço de plano de controle que hospeda uma interface da Web e acessa os serviços disponíveis do plano de dados do Azure Databricks. Para obter mais informações, consulte a visão geral da arquitetura do Databricks.

Para iniciar e gerenciar aplicativos, vá para a seção Aplicativos na interface do usuário do workspace.

URL do Aplicativo

O Databricks atribui automaticamente a cada aplicativo uma URL exclusiva ao criá-la. O URL segue este formato:

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

Where:

• <app-name> é o nome que você fornece ao criar o aplicativo
• <workspace-id> é o identificador único para seu espaço de trabalho
• <region> é a região de nuvem em que seu workspace está localizado

Você não pode alterar a URL depois de criar o aplicativo. Se você precisar de uma URL diferente, crie um novo aplicativo com um nome diferente.

Template

Um modelo de aplicativo é um scaffold predefinido que ajuda os desenvolvedores a começar a criar aplicativos rapidamente usando uma estrutura com suporte. Cada modelo inclui uma estrutura de arquivo básica, um app.yaml manifesto, um requirements.txt arquivo para aplicativos Python e um código-fonte de exemplo.

O app.yaml arquivo define o comando para executar o aplicativo (por exemplo, streamlit run <app-name> para um aplicativo Streamlit), configura variáveis de ambiente locais e declara todos os recursos necessários.

• Use requirements.txt para listar pacotes adicionais do Python para instalar com pip.
• Use package.json para listar pacotes Node.js para instalar com npm.

Esses arquivos complementam o ambiente do sistema padrão e os pacotes pré-instalados. Para obter mais informações, consulte o ambiente do sistema de Aplicativos do Databricks.

Os desenvolvedores podem gerar um novo aplicativo a partir de um modelo usando a interface do usuário ou a CLI do Azure Databricks.

Ambiente e pacotes do sistema

Os Aplicativos do Databricks são executados em um ambiente de sistema pré-configurado gerenciado pelo Azure Databricks. Para obter detalhes, consulte o ambiente do sistema de Aplicativos do Databricks.

Cada aplicativo tem seu próprio ambiente isolado para evitar conflitos de dependência. Para garantir a consistência, defina os pacotes necessários e suas versões no arquivo apropriado para seu aplicativo:

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

Para implantações híbridas, você provavelmente terá os dois arquivos.

Durante a implantação, o Azure Databricks instala essas dependências no ambiente de runtime isolado do aplicativo. Se você incluir um pacote já pré-instalado, a versão especificada substituirá o padrão.

Consulte Gerenciar dependências de um aplicativo do Databricks para obter mais detalhes.

Recursos do aplicativo

Os recursos de aplicativo são serviços nativos do Azure Databricks dos quais um aplicativo depende, como SQL warehouses, pontos de extremidade de veiculação de modelos, trabalhos, segredos ou volumes. Você declara essas dependências no databricks.yml manifesto usando o resources campo. O Azure Databricks dá suporte aos seguintes tipos de recurso:

• SQL Warehouse
• Job
• Ponto de extremidade do Serviço de Modelo
• Espaço do gênio
• Secret
• Volume

Para acessar os serviços do Azure Databricks que ainda não têm um tipo de recurso com suporte, use um segredo gerenciado pelo Catálogo do Unity para injetar credenciais com segurança. Confira Gerenciamento de segredos.

Há dois estágios para configurar recursos do aplicativo:

• Declaração (desenvolvimento) – declare cada recurso necessário no databricks.yml manifesto. Isso define quais recursos o aplicativo precisa e quais permissões ele requer.
• Configuração (implantação) – Durante a implantação, use a Interface de Usuário do Databricks Apps para configurar os recursos declarados com instâncias específicas do espaço de trabalho reais (por exemplo, selecionando um SQL Warehouse específico).

Essa separação entre a declaração e a configuração permite que os aplicativos sejam portáteis entre ambientes. Por exemplo, você pode implantar o mesmo código de aplicativo em um workspace de desenvolvimento e vinculá-lo a um SQL Warehouse. Em produção, você pode reutilizar o código e configurar um warehouse diferente sem fazer alterações de código. Para dar suporte a isso, evite inserir diretamente os identificadores de recursos ou valores específicos do ambiente em seu aplicativo.

O Azure Databricks impõe acesso baseado em menores privilégios. Os aplicativos devem usar recursos existentes e não podem criar novos. Durante a implantação, os administradores do workspace revisam e aprovam o acesso solicitado do aplicativo aos recursos. A entidade de serviço do aplicativo recebe as permissões necessárias e o desenvolvedor do aplicativo deve ter permissão para concedê-las.

Para saber mais, confira Adicionar recursos a um aplicativo do Databricks.

Status do aplicativo

Um aplicativo pode ter um dos seguintes status: Em execução, parado, implantando ou com falha.

• Em execução – o aplicativo está ativo e acessível. O Azure Databricks cobra os recursos de computação usados enquanto o aplicativo está em execução.
• Parado - O aplicativo não está acessível e não incorre em custos. O Azure Databricks preserva a configuração e o ambiente do aplicativo, para que você possa reiniciá-lo sem reconfigurar.
• Implantando – O aplicativo está sendo iniciado. Ele ainda não está acessível e não gera custos durante esta fase.
• Falha – O aplicativo falhou ao iniciar ou parou inesperadamente. É inacessível e não gera cobranças. Você pode exibir logs para solucionar problemas e reiniciar o aplicativo assim que o problema for resolvido.

Estado do aplicativo

O estado do aplicativo inclui todos os dados ou contexto que o aplicativo precisa para persistir entre sessões ou interações do usuário. Os aplicativos não preservam o estado na memória após a reinicialização. Todos os dados mantidos na memória são perdidos quando o aplicativo é desligado.

Você pode armazenar o estado das seguintes maneiras:

• Armazenamento na memória para dados temporários em uma única sessão. Esses dados são perdidos quando o aplicativo é reiniciado.
• Sistema de arquivos local para arquivos temporários durante a execução do aplicativo. Esses dados são perdidos quando o aplicativo é reiniciado.
• Tabelas do Azure Databricks usando o DATAbricks SQL para cargas de trabalho de análise e dados estruturados persistentes.
• Arquivos de workspace para dados persistentes não estruturados.
• Volumes do Unity Catalog para dados não estruturados persistentes com governança no Unity Catalog.

• Instâncias de banco de dados do Lakebase para dados relacionais persistentes com compatibilidade do PostgreSQL.

Os casos de uso comuns incluem armazenar em cache os resultados da consulta, salvar preferências do usuário ou registrar ações do usuário em log em sessões.

Autenticação e autorização de aplicativo

Os Aplicativos do Databricks usam o OAuth 2.0 para autenticação e controle de acesso. Cada aplicativo tem duas identidades complementares que determinam como ele autentica e autoriza o acesso aos recursos do Azure Databricks: autorização de aplicativo e autorização do usuário.

• Autorização do aplicativo – o Azure Databricks cria automaticamente uma entidade de serviço para cada aplicativo. Essa entidade de serviço atua como a identidade do aplicativo e recebe permissões do desenvolvedor do aplicativo. Todos os usuários do aplicativo compartilham essa identidade e têm acesso ao mesmo conjunto de permissões. Esse modelo é útil para operações que não dependem do contexto do usuário individual, como registro em log ou ações no nível do sistema.

• Autorização do usuário – Esse modelo usa a identidade do usuário do aplicativo para autenticar e autorizar o acesso. Os usuários devem pertencer à conta do Azure Databricks em que o aplicativo é implantado. Depois de entrar por meio do SSO (logon único), o aplicativo pode usar as credenciais do usuário para acessar recursos controlados, como um SQL Warehouse. Isso permite que o aplicativo respeite as permissões detalhadas gerenciadas pelo Unity Catalog sem conceder essas permissões ao principal do serviço do aplicativo.

Os aplicativos solicitam escopos OAuth específicos em seu manifesto para controlar quais APIs e recursos podem ser acessados. Esse modelo flexível dá suporte à segurança de nível empresarial e permite o controle de acesso refinado.

Para obter mais informações, consulte Configurar autorização em um aplicativo do Databricks.

Usuários do aplicativo

Após a implantação, os desenvolvedores de aplicativos podem compartilhar um aplicativo com usuários ou grupos concedendo a permissão CAN_USE ou CAN_MANAGE na instância do app. Os usuários não precisam pertencer ao mesmo workspace, mas devem fazer parte da mesma conta do Azure Databricks. Para compartilhar com usuários externos, primeiro sincronize-os na conta usando seu provedor de identidade. Para obter mais informações, consulte Sincronizar usuários e grupos do Microsoft Entra ID utilizando o SCIM.

Você também pode distribuir o mesmo aplicativo em ambientes de desenvolvimento, homologação e produção usando pipelines de CI/CD e infraestrutura como código. A interface do usuário de aplicativos centralizados ajuda os usuários a descobrir e iniciar aplicativos que estão autorizados a usar.