O que vem aí?

Saiba mais sobre funcionalidades e mudanças comportamentais nas próximas versões do Azure Databricks.

Mudança de comportamento iminente: Escolha direitos ao adicionar princípios aos espaços de trabalho

O Databricks está a mudar a forma como os principais têm direito aos espaços de trabalho. Após esta alteração, concede-se direitos explicitamente ao adicionar um principal a um espaço de trabalho, em vez de depender da herança do users grupo do sistema. Os administradores de espaços de trabalho podem aderir a partir de 15 de junho de 2026, e o novo comportamento entra em vigor para todos os espaços de trabalho em 14 de setembro de 2026.

Esta alteração permite-lhe adicionar princípios em qualquer nível de acesso, incluindo utilizadores exclusivos para consumidores, sem que estes herdem automaticamente privilégios de autoria.

O que muda

Cada espaço de trabalho tem dois grupos do sistema: users, que inclui todas as identidades a quem foi concedido acesso ao espaço de trabalho, e admins, que inclui os administradores do espaço de trabalho. Hoje, cada principal adicionado a um espaço de trabalho herda os direitos concedidos a users. Por predefinição, são os seguintes:

• Acesso ao espaço de trabalho — crie e use cadernos, trabalhos, pipelines, aplicações e muito mais.
• Acesso ao Databricks SQL — crie e use painéis, espaços Genie, alertas e muito mais.

Após a alteração:

• O users grupo não terá direitos. O admins grupo terá todos os direitos ao espaço de trabalho. Os direitos de ambos os grupos estão bloqueados.
• Os novos principais devem receber direitos explicitamente quando adicionados a um espaço de trabalho.
• users e admins não podem ser aninhados noutros grupos como membros.

Os diretores existentes mantêm o seu nível atual de acesso. O Databricks migra automaticamente as permissões anteriormente concedidas a users para um novo grupo clone local da área de trabalho denominado users-clone-<TIMESTAMP> (em que <TIMESTAMP> corresponde à hora da migração). Geres o grupo clone como qualquer outro grupo local de espaço de trabalho, e podes personalizar o nome dele quando te inscreves cedo. O admins grupo não precisa de migração.

Ação necessária

• Se gerir direitos de grupos de sistema através de automação (Terraform, APIs SCIM do Workspace ou scripts personalizados), atualize os seus fluxos de trabalho para direcionar grupos de contas padrão, não grupos de sistema. Depois de o novo comportamento ser ativado, as tentativas de modificar os direitos dos grupos do sistema falharão.
• Se users ou admins estiver aninhado como membro de um outro grupo, remova o aninhamento. A nidificação não é permitida com o novo comportamento.
• Se a sua sincronização SCIM apagar grupos de espaço de trabalho que não reconhece, atualize a configuração para preservar o grupo de clones de migração (users-clone-<TIMESTAMP>). Se a sincronização remover o grupo clone, os principais que migraram para ele perdem os seus direitos.

Timeline

• 15 de junho de 2026 – Adesão disponível nas definições do espaço de trabalho, em Controlo de acesso avançado >.
• 27 de julho de 2026 – Auto-ativado para espaços de trabalho que não optaram por aderir ou sair. A opção de exclusão continua disponível.
• 14 de setembro de 2026 – Novo comportamento aplicado para todos os espaços de trabalho. Opção de exclusão removida.

Geres o novo comportamento a partir das definições do teu espaço de trabalho, em Controlo de Acesso Avançado>:

Antes da adesão: o comportamento herdado está ativo.

Após a adesão ou a ativação automática: o novo comportamento fica ativo.

O Embed Genie Space estará em breve disponível predefinidamente para espaços de trabalho com o perfil de segurança de conformidade ativado

A incorporação de um Genie Space num iframe estará disponível por defeito para espaços de trabalho com o perfil de segurança de conformidade ativado em junho de 2026.

Incorporar um Espaço Genie permite que os utilizadores empresariais interajam diretamente com o Genie nas suas ferramentas internas ou portais, sem terem de navegar para o Azure Databricks.

Veja Incorporar um Espaço Genie numa aplicação externa.

Os alertas SQL do Databricks estarão disponíveis em breve por predefinição para áreas de trabalho com o perfil de segurança de conformidade ativado

Os alertas SQL do Databricks estarão disponíveis por defeito para espaços de trabalho com o perfil de segurança de conformidade ativado em junho de 2026.

Use os alertas SQL do Databricks para monitorizar dados e KPIs, executando consultas num calendário, avaliando condições e notificando os destinatários quando as condições são cumpridas. Casos de uso comuns incluem monitorização de desvios de KPI, deteção de anomalias e evidência de problemas de qualidade dos dados.

Consulte Alertas SQL do Databricks.

O Genie chat estará brevemente disponível por predefinição para espaços de trabalho com o perfil de segurança de conformidade ativado

O Genie chat estará disponível por predefinição em junho de 2026 para espaços de trabalho com o perfil de segurança de conformidade ativado.

O Genie Chat oferece uma interface unificada em ecrã inteiro para colocar questões de dados em linguagem natural. Utiliza dashboards existentes, consultas, Genie Spaces e vistas métricas para responder às suas perguntas com todos os dados disponíveis.

Consulte Genie chat.

Modelo unificado de permissões para projetos criados com a API de instância de base de dados

Entre 11 e 21 de maio de 2026, a Lakebase Autoscaling está a implementar um modelo unificado de permissões para novos projetos criados com a API de instância da base de dados ou ferramentas relacionadas (CLI, SDKs, Terraform, DABs). Os projetos existentes não são afetados.

Após o lançamento, tanto as permissões da instância como do projeto são geridas por uma camada unificada de permissões, em vez de dois conjuntos independentes de ACL. A automação existente que utiliza a API da instância da base de dados continua a funcionar sem alterações.

Ver Permissões (ACLs).

Próxima alteração: Atualização para o dimensionamento automático do Lakebase

O Azure Databricks está a atualizar todas as instâncias Lakebase Provisioned para a plataforma Lakebase Autoscaling. As atualizações começam em junho de 2026 para os clientes que as solicitaram, com as restantes atualizações de instância a continuarem nas semanas seguintes. Os administradores do espaço de trabalho receberão um email com as datas de atualização antes do início da atualização.

A atualização é automática. As ligações reiniciam-se brevemente durante a transição, e as cadeias de ligação existentes, chamadas de API, Pacotes de Automação Declarativa e configurações Terraform continuam a funcionar sem modificações.

Após a atualização, aplicam-se as seguintes alterações:

• As suas instâncias suportarão funcionalidades de autoescalonamento e poderão ser geridas tanto através da nova interface de Autoescalonamento como da familiar interface Provisionada, que permanece disponível até 1 de setembro de 2026.

• Cada instância recebe uma nova cadeia de ligação regional que proporciona entrada otimizada:

  • Cadeias de ligação existentes: Cadeias de ligação provisionadas (sem região) continuam a funcionar sobre a Private Link de entrada existente e não requeremService Direct Private Link.
  • Nova cadeia de ligação regional: Se utilizar o Private Link e estabelecer ligação ao Lakebase a partir de fora do espaço de trabalho do Azure Databricks, tem de configurar o Private Link de entrada para serviços com requisitos de desempenho elevados para utilizar a nova cadeia de ligação regional.

• Para usar novas funcionalidades de autoescalonamento, como escalar até zero, nos seus Pacotes de Automação Declarativa e configurações do Terraform, atualize-as para usar semântica de autoescalonamento.

• Os preços de Lakebase GA aplicam-se. Com a computação elástica a substituir as instâncias de tamanho fixo, a maioria dos clientes verá uma redução nos custos de computação.

• As funcionalidades Forward ETL e REST API Private Preview no Lakebase Provisioned são desativadas após a atualização. Os seus substitutos, Lakebase Change Data Feed e Data API, estão disponíveis na plataforma Autoscaling.

O Lakebase Autoscaling adiciona dimensionamento automático e redução para zero, restauro para um ponto anterior no tempo e instantâneos, agendamento de janelas de manutenção, ramificação de bases de dados e outras melhorias. Para detalhes sobre o que esperar, que mudanças e que ações tomar, consulte Atualizar para Autoscaling.

Para solicitar uma atualização acelerada ou se tiver dúvidas, contacte a sua equipa de contas ou o Suporte do Azure Databricks.

O suporte para o formato de ficheiro do Excel ficará brevemente disponível por predefinição

O suporte ao formato de ficheiros Excel estará disponível por defeito para todos os espaços de trabalho no início de junho de 2026. Pode ingerir, analisar e consultar .xls, .xlsx, e .xlsm ficheiros diretamente usando suporte incorporado, sem bibliotecas externas ou conversões manuais. Os administradores do espaço de trabalho podem agora ativá-lo em Definições>Pré-visualizações>Suporte para o formato de ficheiro Excel. Requer o Databricks Runtime 17.1 ou posterior.

Veja Leia ficheiros do Excel.

O Databricks Runtime 19 utilizará um modelo de lançamento unificado

A partir da versão 19, o Databricks Runtime utilizará um modelo de lançamento unificado. Em vez de várias versões de funcionalidades (por exemplo, 19.0, 19.1, 19.2), cada versão principal terá uma única página de notas de lançamento.

Após uma Beta inicial, cada versão Databricks Runtime será lançada como disponível de forma geral (GA) e receberá novas funcionalidades e correções aproximadamente semanalmente, com atualizações diferenciadas por data numa única página. Os clusters receberão atualizações quando reiniciarem. Após aproximadamente seis meses, a versão transita para suporte a longo prazo (LTS) com três anos de suporte.

O Databricks Runtime 18 é a versão de transição. As páginas das versões de funcionalidades 18.0, 18.1 e 18.2 continuam disponíveis para referência histórica, e o Databricks Runtime 18 LTS será a última versão unificada da linha 18.x.

Anexos tabulares em subscrições por email de dashboards para espaços de trabalho com o perfil de segurança de conformidade ativado

Em junho de 2026, os anexos tabulares nas subscrições por e-mail de dashboards estarão disponíveis por defeito para áreas de trabalho com o perfil de segurança de conformidade ativado.

Os subscritores de email recebem um snapshot em PDF e, opcionalmente, dados tabulares de widgets selecionados do dashboard como anexos de ficheiros CSV, TSV ou Excel.

As ligações Power BI vão transitar para ADBC

O Power BI planeia transferir todas as ligações Power BI para a Conectividade Arrow Database (ADBC) em julho de 2026. Para evitar interrupções, a Databricks recomenda mudar os seus modelos semânticos de desenvolvimento e staging para ADBC agora e validar as suas cargas de trabalho.

O driver ADBC para Power BI no Azure Databricks está em Pré-visualização Pública desde outubro de 2025. Desde fevereiro de 2026, todas as novas ligações no Power BI Desktop e no serviço Power BI usam o ADBC por defeito. As ligações existentes continuam a usar ODBC, a menos que as atualize manualmente.

Veja Configure o driver ADBC ou ODBC para Power BI.

A autorização de utilizador para as aplicações Databricks estará em breve disponível para espaços de trabalho com o perfil de segurança de conformidade ativado

No início de junho de 2026, a autorização do utilizador para as Apps Databricks será automaticamente ativada para espaços de trabalho com o perfil de segurança de conformidade ativado. A autorização do utilizador permite que as aplicações atuem com a identidade do utilizador da aplicação, para que as aplicações possam aceder a recursos em nome do utilizador enquanto fazem cumprir as permissões existentes do utilizador.

Veja Autorização do Utilizador.

As permissões de objetos de workspace serão em breve herdadas de todos os grupos de contas

Numa próxima versão, as permissões dos objetos do workspace serão herdadas de todos os grupos de contas, não apenas dos grupos diretamente atribuídos ao workspace. Os principais irão herdar permissões sobre objetos do espaço de trabalho, como jobs, cadernos, pastas, consultas e painéis, de todos os grupos de contas dos quais são membros, independentemente de esses grupos estarem atribuídos ao espaço de trabalho. Os utilizadores ainda precisam de ser atribuídos ao espaço de trabalho para usar estas permissões.

Esta alteração também ativa permissões concedidas que estão inativas ("órfãs"). São concessões de autorização que permanecem num grupo depois de este ser removido de um espaço de trabalho. Não estão a ser adicionadas novas permissões, mas subsídios existentes para órfãos tornar-se-ão ativos, podendo dar aos membros do espaço de trabalho acesso inesperado. Por exemplo, se um grupo "Contractors" foi removido de um workspace mas ainda tiver acesso de edição a uma pasta, qualquer membro do workspace em "Contractors" terá acesso a essa pasta.

O Databricks recomenda rever as permissões do seu espaço de trabalho. Use o seguinte caderno para identificar concessões de permissões inativas nos seus espaços de trabalho:

Bloco de notas de análise de permissões órfãs

Obter caderno

Tokens de acesso pessoal com escopo estarão em breve disponíveis automaticamente para espaços de trabalho com o perfil de segurança de conformidade regulatória ativado

Tokens de acesso pessoal limitados estarão disponíveis por defeito no final de Maio de 2026 para espaços de trabalho com o perfil de segurança de conformidade ativado.

Os tokens pessoais de acesso com âmbito restringem as permissões de um PAT para operações específicas da API, atribuindo um ou mais escopos de API, em vez de conceder ao utilizador da identidade criadora o acesso total ao espaço de trabalho.

Consulte Autenticar com tokens de acesso pessoal do Azure Databricks (legacy).

Mudança comportamental iminente: VOID colunas incluídas nas leituras de tabelas Delta

Em meados de junho de 2026, o Delta Lake irá suportar totalmente as colunas VOID. As colunas VOID anteriormente eram ignoradas de forma silenciosa por leituras do DataFrame baseadas em caminhos (por exemplo, spark.read.format("delta").load(path)) e por consultas de viagem no tempo. Após esta alteração, estas consultas incluem VOID colunas no resultado.

Consultas que dependem do número de colunas ou da posição, como INSERT INTO ... SELECT *, podem falhar ou produzir resultados incorretos após esta alteração. Revise quaisquer consultas que sejam lidas das tabelas Delta Lake com VOID colunas para garantir que lidam corretamente com as colunas adicionais.

Consulte VOID tipo.

Alteração urgente iminente: comportamento padrão ao eliminar um pipeline do Unity Catalog

Numa próxima atualização, o comportamento predefinido ao eliminar um pipeline do Unity Catalog irá mudar. Atualmente, eliminar um pipeline também remove todas as visualizações materializadas, tabelas de streaming e visualizações associadas. Após esta alteração, as tabelas associadas serão mantidas, mas inativas após a remoção do pipeline. A API também mudará para reter tabelas por padrão, mas definir o campo cascade para true sobrepõe-se a 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 eliminar um pipeline, atualize o seu código para definir cascade=true.

Veja Eliminar um fluxo de trabalho e Eliminar um fluxo de trabalho.

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

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

• A partir do final de maio de 2026: O novo editor SQL será ativado por padrão para todos os espaços de trabalho. A capacidade de desligar a funcionalidade ao nível do espaço de trabalho deixará de estar disponível. Os utilizadores individuais ainda poderão mudar as suas consultas para o editor SQL antigo após este período começar.
• A partir do final de julho de 2026: O editor SQL legado será retirado. Todos os utilizadores usarão o novo editor SQL, e a opção individual de exclusão deixará de estar disponível.

Para saber mais sobre o novo editor SQL, consulte Escrever consultas e explorar dados no novo editor SQL. Se tiver dúvidas sobre esta transição, contacte a equipa da sua conta.

Alteração da ordem de classificação da API de Listagem de Dashboards

A 4 de maio de 2026, uma nova versão da API List Dashboards irá alterar a ordem de ordenação dos resultados. Os dashboards serão devolvidos por ordem cronológica inversa pela data da última modificação, com o dashboard mais recentemente modificado primeiro, em vez de por ordem alfabética pelo título.

Esta é uma alteração decisiva para utilizadores que paginam resultados usando next_page_token. Tokens gerados por uma versão anterior da API não são válidos com a nova versão. Se usar um token de uma versão anterior, a API devolve um erro:

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

Para continuar a paginar após esta alteração, inicie um novo pedido sem um next_page_token.

O Lakebase estará ativado por defeito para espaços de trabalho com o perfil de segurança de conformidade

A partir de 30 de abril de 2026, o Lakebase será ativado automaticamente por predefinição para espaços de trabalho com o perfil de segurança de conformidade quando o padrão de conformidade estiver definido para HIPAA, C5, TISAX ou sem nenhum.

Ver conformidade com Lakebase.

Alterações aos tokens de destinatários do Delta Sharing abertos

A Partilha Delta para destinatários abertos irá transitar para um novo formato de URL específico para cada destinatário. A data de transição foi atualizada e é agora 1 de julho de 2026. Novos tokens criados a partir de 1 de julho de 2026 usarão automaticamente o novo formato de URL. Esta alteração melhora a segurança da rede e permite aos destinatários configurar políticas de rede e regras de firewall específicas para cada destinatário.

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

Os novos URLs incluem o 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, URLs criadas antes desta alteração não contêm o ID do destinatário.

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

Os URLs antigos continuarão a funcionar durante algum tempo. A duração específica depende do tipo de destinatário e da data de criação do token. Os fornecedores de dados devem transitar para o novo formato de URL antes que o antigo se torne inválido.

Partilha da Federação OIDC:

Os fornecedores de dados precisam de verificar se os seus destinatários estão a usar o novo formato URL antes de 1 de julho de 2027. A partir de 1 de julho de 2026, os fornecedores podem encontrar o novo URL na Delta Sharing UI. Após 1 de julho de 2027, o antigo formato URL deixará de ser válido.

Partilha de tokens de portador:

A Classificação de Dados estará em breve disponível automaticamente para alguns espaços de trabalho com perfil de segurança de conformidade ativado.

Em meados de março de 2026, a Classificação de Dados estará disponível por defeito para espaços de trabalho com o perfil de segurança de conformidade ativado e os controlos HIPAA selecionados.

O suporte ao EventBridge estará em breve disponível para eventos de ficheiros fornecidos em filas

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

Consulte Utilizar uma fila fornecida para S3.

Nova lógica de fatiamento para tabelas de cronogramas de tarefas

A partir de 19 de janeiro de 2026, as tabelas cronológicas dos empregos utilizam uma nova lógica de seccionamento alinhada com as horas de relógio. As faixas de tempo agora alinham-se com os limites padrão das horas do relógio (17:00-18:00, 18:00-19:00, e assim sucessivamente) em vez de intervalos de uma hora baseados na hora de início da corrida. As novas linhas usam a nova lógica de fatiamento, enquanto as linhas existentes permanecem inalteradas.

Veja lógica de corte alinhada ao horário de relógio.

Atualizações de navegação no Explorador de Catálogos

O Explorador de Catálogos receberá em breve melhorias na navegação para simplificar fluxos de trabalho e ajudá-lo a descobrir e gerir os ativos de dados de forma mais eficiente.

Navegação simplificada:

O separador duplicado Catálogos é removido para reduzir a redundância e focar numa única superfície de navegação de catálogo. DBFS e as ações de Enviar feedback movem-se para o ícone do menu para um layout mais limpo.

Nova secção de Sugestões:

Um novo separador de Sugestões na página de destino do Explorador de Catálogos destaca objetos frequentemente usados, exemplos de objetos para utilizadores iniciantes e favoritos dos utilizadores. Isto ajuda-o a reenvolver-se rapidamente com recursos importantes ou a descobrir pontos de partida úteis.

Pontos de entrada consolidados:

As capacidades relacionadas estão agrupadas em categorias mais claras para reduzir o ruído visual e melhorar a localização:

• Govern – Ponto de entrada para etiquetas governadas, administração de metastore e classificação de dados
• Conexão – Pontos de entrada para localizações externas, dados externos, credenciais e ligações
• Share – Pontos de entrada para Delta Sharing e Clean Rooms

Estes agrupamentos substituem as subguias dispersas e criam uma arquitetura de informação mais intuitiva e escalável.

Partilha da Lakehouse Federation e armazenamento predefinido

O Delta Sharing na Lakehouse Federation está em fase Beta, permitindo que os fornecedores de dados Delta Sharing partilhem catálogos e tabelas estrangeiros. Por padrão, os dados devem ser materializados temporariamente e armazenados no armazenamento padrão (Visualização privada). Atualmente, os usuários devem habilitar manualmente o recurso Delta Sharing for Default Storage – Expanded Access no console da conta para usar o compartilhamento Lakehouse Federation.

Depois de o Delta Sharing for Default Storage – Expanded Access estar ativado por defeito para todos os utilizadores Azure Databricks, o Delta Sharing na Lakehouse Federation estará automaticamente disponível nas regiões onde o armazenamento por defeito é suportado.

Consulte Armazenamento padrão em Databricks e Adicionar esquemas ou tabelas externas a uma partilha.

Notificação de recarregamento em espaços de trabalho

Em uma versão futura, uma mensagem para recarregar a guia do espaço de trabalho será exibida se a guia do espaço de trabalho estiver aberta por muito tempo sem atualizar. 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)

Esta atualização de armazenamento predefinido para o Delta Sharing expandiu as capacidades de partilha, permitindo aos fornecedores partilhar tabelas suportadas por armazenamento predefinido a qualquer destinatário do Delta Sharing (aberto ou Azure Databricks), incluindo destinatários que utilizem computação convencional. Esse recurso está atualmente em versão 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.

Consulte Limitações.

Atualizações aos IPs públicos do plano de controlo de saída

Azure Databricks está a atualizar os IPs públicos do plano de controlo outbound e as etiquetas de serviço Azure para melhorar a segurança e a disponibilidade das zonas. Essas mudanças fazem parte de uma atualização do plano de controle que começou a ser lançada em 20 de maio de 2025.

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

• Se as regras do teu firewall referenciarem a etiqueta Azure Databricks service, não é necessária qualquer ação.
• Se você permitir IPs públicos específicos do plano de controle, deverá adicionar todos os IPs do plano de controle de saída até 26 de setembro de 2025.

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

Alteração de comportamento para a opção de listagem incremental de diretórios do Auto Loader

Em uma versão futura do Databricks Runtime, o valor preterido da opção cloudFiles.useIncrementalListing do Auto Loader será, por padrão, definido como false. Definir esse valor como false faz com que o Auto Loader execute uma listagem completa de diretórios cada vez que é executado. Atualmente, o valor padrão da opção cloudFiles.useIncrementalListing é auto, instruindo o Auto Loader a fazer uma tentativa de melhor esforço para detetar 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 como auto. Quando você define esse valor como auto, o Auto Loader faz uma tentativa de melhor esforço para 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 Auto Loader, consulte Configurar fluxos do Auto Loader em modo listagem de diretórios.

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

Uma próxima versão do Lakeflow Spark Declarative Pipelines mudará o comportamento quando uma exibição materializada ou 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á excluída 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 soltar um objeto, a execução de uma atualização de pipeline não recuperará o objeto automaticamente. Um novo objeto é criado se uma exibiçã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, certos logs de auditoria de autorização e autenticação incluem um número de porta além do IP no sourceIPAddress campo (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 logs de auditoria do Databricks. Para melhorar a consistência dos logs de auditoria, o Databricks planeja alterar o formato do endereço IP para esses eventos de log de auditoria. Esta alteração será implementada gradualmente a partir do início de agosto de 2024.

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