Compartilhar via


O que vem por aí?

Saiba mais sobre recursos e alterações comportamentais nas próximas versões do Azure Databricks.

ai_parse_document em breve estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado

ai_parse_document estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado e os controles HIPAA, HITRUST, C5 e TISAX selecionados em meados de maio de 2026.

Use ai_parse_document para analisar o conteúdo estruturado de documentos não estruturados, incluindo PDFs, imagens, documentos Word e arquivos de PowerPoint.

Veja a ai_parse_document função.

Mudança futura importante: o filtro de linha ABAC e a avaliação da máscara de coluna para visões e funções serão mudadas para serem baseadas na identidade da sessão.

A partir do final de abril, o Catálogo do Unity avaliará filtros de linha ABAC e máscaras de coluna em tabelas acessadas por meio de exibições e funções usando a identidade do usuário da sessão (a identidade da pessoa que está executando a consulta), em vez de da identidade do proprietário da exibição ou função. Essa alteração torna o comportamento da política mais fácil de entender e alinha-o com a forma como Azure Databricks lida com a segurança em nível de tabela e o mascaramento de colunas em nível de linha.

Essa alteração não afeta a forma como o acesso a tabelas subjacentes é verificado. Os usuários que consultam por meio de exibições e funções ainda não precisam de privilégios diretos nessas tabelas.

Quem é afetado: essa alteração afeta os clientes que consultam tabelas protegidas pelo ABAC (tabelas com filtros de linha ou máscaras de coluna) por meio de exibições ou funções. Azure Databricks entrarão em contato ativamente para identificar os clientes que podem estar usando esse padrão.

  • Se Azure Databricks entrou em contato com você como um cliente potencialmente afetado: você recebeu um período de carência de três meses para adaptar suas políticas. Durante essa janela, você pode optar pelo novo comportamento gradualmente usando uma configuração de nível de conta ou um campo por política na API de criação/atualização. Azure Databricks fornecerá um notebook de diagnóstico para ajudá-lo a identificar exibições e funções em sua conta que fazem referência a tabelas protegidas pelo ABAC e verificar se suas políticas produzem os resultados de acesso pretendidos sob o novo comportamento.
  • Se você não for contatado pelo Azure Databricks ou se for um novo cliente após o lançamento esperado no final de abril: o novo comportamento de identidade da sessão se tornará o padrão para sua conta no final de abril. Nenhuma ação é necessária.

Consulte o ABAC (controle de acesso baseado em atributo) do Catálogo do Unity.

Próxima alteração comportamental: VOID colunas incluídas nas leituras da tabela Delta

Em meados de junho de 2026, o Delta Lake dará suporte total a VOID colunas. Anteriormente, as colunas VOID eram silenciosamente ignoradas por leituras de DataFrame baseadas em caminho (por exemplo, spark.read.format("delta").load(path)) e consultas de viagem no tempo. Após essa alteração, essas consultas incluem VOID colunas na saída.

Consultas que dependem da contagem ou posição de colunas, como INSERT INTO ... SELECT *, podem falhar ou produzir resultados incorretos após essa alteração. Revise as consultas que leem as tabelas Delta Lake com VOID colunas para garantir que elas manipulem as colunas adicionais corretamente.

Consulte VOID tipo.

Alteração de falha futura: comportamento padrão ao excluir um pipeline do Catálogo do Unity

Em uma versão futura, o comportamento padrão ao excluir um pipeline do Catálogo do Unity será alterado. Atualmente, a exclusão de um pipeline também remove todas as exibições materializadas, tabelas de streaming e exibições associadas. Após essa alteração, as tabelas associadas serão mantidas, mas se tornarão inativas após a remoção do pipeline. A API também será alterada para reter tabelas por padrão, mas ajustar o campo cascade para true anula isso e mantém o comportamento atual.

O cascade campo já está disponível. Para preservar o comportamento atual de remover todas as tabelas ao excluir um pipeline, atualize o código para definir cascade=true.

Consulte Excluir um pipeline e excluir um pipeline.

A implantação baseada em Git para aplicativos do Databricks estará disponível em breve para espaços de trabalho com o perfil de segurança de conformidade habilitado.

No início de maio de 2026, a implantação baseada em Git para Aplicativos do Databricks será habilitada automaticamente para workspaces com o perfil de segurança de conformidade habilitado. Implante aplicativos diretamente de um repositório Git para simplificar o fluxo de trabalho de CI/CD.

Consulte Implantar um aplicativo do Databricks.

Nova ativação padrão do editor SQL e desativação do editor SQL legado

O novo editor do SQL está disponível em geral desde outubro de 2025. Como parte da transição para o novo editor, as seguintes alterações são planejadas:

  • A partir do final de maio de 2026: o novo editor de SQL será habilitado por padrão para todos os workspaces. A capacidade de desativar o recurso no nível do workspace não estará mais disponível. Os usuários individuais ainda poderão alternar suas consultas para o editor de SQL herdado após o início desse período.
  • A partir do final de julho de 2026: o editor de SQL herdado será desativado. Todos os usuários usarão o novo editor do SQL e a recusa individual não estará mais disponível.

Para saber mais sobre o novo editor de SQL, consulte Escrever consultas e explorar dados no novo editor do SQL. Se você tiver dúvidas sobre essa transição, entre em contato com sua equipe de conta.

Alteração na ordem de classificação da API de Painéis

Em uma versão futura, uma nova versão da API de Painéis de Lista alterará a ordem de classificação dos resultados. Os painéis serão retornados em ordem cronológica inversa pela data da última modificação, com o painel mais recentemente modificado primeiro, em vez de em ordem alfabética por título.

Essa é uma alteração significativa para usuários que paginam resultados usando next_page_token. Os tokens gerados por uma versão anterior da API não são válidos com a nova versão. Se você usar um token de uma versão anterior, a API retornará um erro:

Invalid page_token: this token was generated by a previous/different API version. Please retry without page_token.

Para continuar paginando após essa alteração, inicie uma nova solicitação sem um next_page_token.

O Lakebase será habilitado por padrão para workspaces com o perfil de segurança de conformidade

Em 30 de abril de 2026 ou após 30 de abril de 2026, o Lakebase será habilitado por padrão para workspaces com o perfil de segurança de conformidade quando o padrão de conformidade for definido como HIPAA, C5, TISAX ou None.

Consulte a conformidade do Lakebase.

Alterações para acessar tokens de destinatários do Delta Sharing

O Compartilhamento Delta para destinatários abertos fará a transição para um novo formato de URL específico do destinatário. A data de transição foi atualizada e agora é 1º de julho de 2026. Novos tokens criados em ou após 1º de julho de 2026 usarão automaticamente o novo formato de URL. Essa alteração melhora a segurança de rede e permite que os destinatários configurem políticas de rede e regras de firewall específicas do destinatário.

Para Azure China, a transição será anunciada mais tarde.

As novas URLs incluem a ID do destinatário no domínio:

https://<recipient-id>.delta-sharing.westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

Para referência, as URLs criadas antes dessa alteração não contêm a ID do destinatário.

https://westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

As URLs antigas continuarão funcionando por um período de tempo. A duração específica depende do tipo de destinatário e da data de criação do token. Os provedores de dados devem fazer a transição para o novo formato de URL antes que o formato de URL antigo se torne inválido.

Compartilhamento da Federação OIDC:

Os provedores de dados precisam verificar se seus destinatários estão usando o novo formato de URL antes de 1º de julho de 2027. A partir de 1º de julho de 2026, os provedores podem encontrar a nova URL na interface do Delta Sharing. Após 1º de julho de 2027, o formato de URL antigo não será válido.

Compartilhamento de token do portador:

Data de criação do token Formato de URL Data de validade do token Ação recomendada
Antes de 1º de julho de 2026 Formato antigo Um ano a partir da data de criação ou 8 de dezembro de 2026, seja qual for a data futura Os provedores de dados precisam de atualizar tokens antes da expiração para migrar para o novo formato de URL. Para fornecer tempo de migração aos destinatários, configure uma janela de tempo de inatividade definindo uma data de validade para o token atual durante a rotação. Há suporte para formatos de URL antigos e novos durante esse período.
Após 1º de julho de 2026 Novo formato De acordo com sua configuração, até um ano a partir da data de criação. Nenhum

A Classificação de Dados estará disponível em breve por padrão para alguns workspaces com o perfil de segurança de conformidade habilitado

Em meados de março de 2026, a Classificação de Dados estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado e os controles HIPAA selecionados.

O suporte do EventBridge estará disponível em breve para filas de eventos de arquivo fornecidas.

No final de fevereiro de 2026, o suporte do EventBridge estará disponível para eventos de arquivo fornecidas por filas para locais S3. Atualmente, os eventos de arquivo só podem ser configurados usando SNS ou roteando eventos de armazenamento diretamente para o SQS.

Consulte Como usar uma fila fornecida para S3.

O Supervisor Agent estará disponível em breve por padrão para clientes avançados de Segurança e Conformidade

Em breve, o Supervisor Agent estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado e os controles HIPAA selecionados.

Use o Supervisor Agent para criar um sistema supervisor de vários agentes que orquestra agentes e ferramentas de IA para trabalhar em conjunto em tarefas complexas.

Consulte Usar o Supervisor Agent para criar um sistema de vários agentes coordenado.

Nova lógica de fatiamento para tabelas cronológicas de trabalhos

A partir de 19 de janeiro de 2026, as tabelas de cronograma de tarefas usam uma nova lógica de segmentação alinhada à hora exata. As fatias de tempo agora se alinham aos limites padrão da hora do relógio (das 17h às 18h, das 18h às 19h, e assim por diante), em vez de usarem intervalos de uma hora baseados na hora de início da execução. Novas linhas usarão a nova lógica de fatiamento, enquanto as linhas existentes permanecem inalteradas.

Consulte lógica de fatiamento alinhada ao horário.

Atualizações de navegação do Gerenciador de Catálogos

Em breve, o Catalog Explorer receberá melhorias de navegação para simplificar os fluxos de trabalho e ajudá-lo a descobrir e gerenciar ativos de dados com mais eficiência.

Navegação simplificada:

A guia de Catálogos duplicada é removida para reduzir a redundância e para se concentrar em uma única interface de navegação de catálogo. As ações DBFS e Enviar comentários são movidas para o ícone de menu kebab. para um layout mais limpo.

Nova seção Sugerida:

Uma nova aba Sugerida na página inicial do Catalog Explorer destaca objetos usados com frequência, objetos de exemplo para usuários iniciantes e favoritos do usuário. Isso ajuda você a se reconectar rapidamente com ativos importantes ou encontrar pontos de partida úteis.

Pontos de entrada consolidados:

Os recursos relacionados são agrupados em categorias mais claras para reduzir o ruído visual e melhorar a localização:

  • Governe – Ponto de entrada para tags sob gestão, administração do metastore e classificação de dados
  • Conectar – Pontos de entrada para locais externos, dados externos, credenciais e conexões
  • Compartilhamento – Pontos de entrada para Delta Sharing e Clean Rooms

Esses agrupamentos substituem subtarefas dispersas e criam uma arquitetura de informações mais intuitiva e escalonável.

Federação Lakehouse: compartilhamento e armazenamento padrão

O Delta Sharing na Lakehouse Federation está em Beta, permitindo que os fornecedores de dados do Delta Sharing compartilhem catálogos e tabelas externas. Por padrão, os dados devem ser materializados temporariamente e armazenados no armazenamento padrão (Versão Prévia Privada). Atualmente, os usuários devem habilitar manualmente o recurso Delta Sharing para Armazenamento Padrão – Acesso Expandido no console da conta para usar o compartilhamento do Lakehouse Federation.

Depois que Delta Sharing para Armazenamento Padrão – Acesso Expandido estiver habilitado por padrão para todos os usuários do Azure Databricks, o Delta Sharing na Federação Lakehouse estará automaticamente disponível em regiões onde o armazenamento padrão é suportado.

Consulte o armazenamento padrão no Databricks e adicione esquemas ou tabelas estrangeiras a um compartilhamento.

Recarregar alerta nos espaços de trabalho

Em uma versão futura, uma mensagem para recarregar a aba do espaço de trabalho será exibida se a aba do espaço de trabalho estiver aberta por muito tempo sem ser atualizada. Isso ajudará a garantir que você esteja sempre usando a versão mais recente do Databricks com os recursos e correções mais recentes.

O Compartilhamento Delta para tabelas no armazenamento padrão em breve será habilitado por padrão (Beta)

Essa atualização de armazenamento padrão para o Compartilhamento Delta expandiu os recursos de compartilhamento, permitindo que os provedores compartilhem tables apoiados pelo armazenamento padrão para qualquer destinatário de compartilhamento Delta (aberto ou Azure Databricks), incluindo destinatários que usam computação clássica. Esse recurso está atualmente em Beta e exige que os provedores habilitem manualmente o Compartilhamento Delta para Armazenamento Padrão – Acesso Expandido no console da conta. Em breve, isso será habilitado por padrão para todos os usuários.

Confira Limitações.

Atualizações para os IPs públicos do plano de controle de saída

Azure Databricks está atualizando os IPs públicos de saída do plano de controle e as tags de serviço do Azure para melhorar a segurança e a disponibilidade da zona. Essas alterações fazem parte de uma atualização do plano de controle que começou a ser distribuída em 20 de maio de 2025.

Se a sua organização utilizar firewalls de recursos para controlar o acesso de entrada:

  • Se as regras de firewall fizerem referência à tag de serviço Azure Databricks, nenhuma ação será necessária.
  • Se você permitir IPs públicos específicos do painel de controle, deverá adicionar todos os IPs do painel de controle de saída até 26 de setembro de 2025.

Os IPs anteriores do plano de controle de saída continuam a ser suportados.

Alteração de comportamento para a opção de listagem de diretório incremental do Carregador Automático

Observação

A opção Carregador Automático cloudFiles.useIncrementalListing está obsoleta. Embora esta observação discuta uma alteração no valor padrão das opções e como continuar a usá-lo após essa alteração, o Databricks recomenda não usar essa opção em favor do modo de notificação de arquivo com eventos de arquivo.

Em uma versão futura do Databricks Runtime, o valor da opção de carregamento automático preterido cloudFiles.useIncrementalListing, por padrão, será definido como false. Definir esse valor para false faz com que o Auto Loader execute uma listagem completa do diretório sempre que for executado. Atualmente, o valor padrão da opção cloudFiles.useIncrementalListing é auto, instruindo o Carregador Automático a fazer uma tentativa de melhor esforço para detectar se uma listagem incremental pode ser usada com um diretório.

Para continuar usando o recurso de listagem incremental, defina a opção cloudFiles.useIncrementalListing para auto. Quando você define esse valor como auto, o Carregador Automático faz uma melhor tentativa de fazer uma listagem completa uma vez a cada sete listagens incrementais, o que corresponde ao comportamento dessa opção antes dessa alteração.

Para saber mais sobre a listagem de diretórios do Carregador Automático, consulte Configurar fluxos do Carregador Automático no modo de listagem de diretórios.

Alteração de comportamento quando as definições do conjunto de dados são removidas dos Pipelines Declarativos do Spark do Lakeflow

Uma versão futura do Lakeflow Spark Declarative Pipelines alterará o comportamento quando uma exibição materializada ou uma tabela de streaming for removida de um pipeline. Com essa alteração, a exibição materializada removida ou a tabela de streaming não serão excluídas automaticamente quando a próxima atualização de pipeline for executada. Em vez disso, você poderá usar o comando DROP MATERIALIZED VIEW para excluir uma exibição materializada ou o comando DROP TABLE para excluir uma tabela de streaming. Depois de remover um objeto, a execução de uma atualização de pipeline não recuperará o objeto automaticamente. Um novo objeto será criado se uma visão materializada ou uma tabela de streaming com a mesma definição for adicionada novamente ao pipeline. No entanto, você pode recuperar um objeto usando o comando UNDROP.

O campo sourceIpAddress nos logs de auditoria não incluirá mais um número de porta

Devido a um bug, determinados registros de auditoria de autorização e autenticação incluem um número de porta além do IP no campo sourceIPAddress (por exemplo, "sourceIPAddress":"10.2.91.100:0"). O número da porta, que é registrado como 0, não fornece nenhum valor real e é inconsistente com o restante dos registros de auditoria do Databricks. Para melhorar a consistência dos registros de auditoria, a Databricks planeja alterar o formato do endereço IP para esses eventos de logs de auditoria. Essa alteração será implementada gradualmente a partir do início de agosto de 2024.

Se o registro de auditoria contiver um sourceIpAddress de 0.0.0.0, o Databricks poderá parar de registrá-lo.