Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Saiba mais sobre recursos e alterações comportamentais nas próximas versões do Azure Databricks.
Próxima alteração de comportamento: escolha permissões ao adicionar entidades de segurança a espaços de trabalho
O Databricks está alterando a forma como as entidades de segurança obtêm direitos de workspace. Após essa alteração, você concede permissões explicitamente ao adicionar um principal a um espaço de trabalho, em vez de depender da herança do grupo de sistema users. Os administradores dos espaços de trabalho podem aderir a partir de 15 de junho de 2026, e o novo comportamento passa a ser aplicado a todos os espaços de trabalho em 14 de setembro de 2026.
Essa alteração permite que você adicione identidades em qualquer nível de acesso, incluindo usuários apenas consumidores, sem que eles herdem automaticamente privilégios de autoria.
O que está mudando
Cada espaço de trabalho tem dois grupos de sistema: users, que inclui todos os principais aos quais foi concedido acesso ao espaço de trabalho, e admins, que inclui os administradores do espaço de trabalho. Atualmente, cada entidade adicionada a um espaço de trabalho herda as permissões concedidas a users. Por padrão, estes são:
- Acesso ao espaço de trabalho — crie e use notebooks, tarefas, pipelines, aplicativos e muito mais.
- Acesso ao SQL do Databricks – criar e usar dashboards, espaços do Genie, alertas e muito mais.
Após a alteração:
- O
usersgrupo não terá direitos. Oadminsgrupo terá todos os direitos de ambiente de trabalho. Os direitos de ambos os grupos estão bloqueados. - Novas identidades devem receber permissões explicitamente ao serem adicionadas a um espaço de trabalho.
-
userseadminsnão podem ser aninhados como membros de outros grupos.
As entidades de segurança existentes mantêm o nível atual de acesso. O Databricks migra automaticamente os direitos concedidos anteriormente a users para um novo grupo clone local ao workspace chamado users-clone-<TIMESTAMP> (em que <TIMESTAMP> é o horário da migração). Você gerencia o grupo de clone assim como qualquer outro grupo local do workspace, e pode personalizar o nome dele ao aderir antecipadamente. O admins grupo não requer migração.
Ação necessária
- Se você gerencia direitos de acesso de grupos do sistema por meio de automação (Terraform, APIs SCIM do workspace ou scripts personalizados), atualize seus fluxos de trabalho para direcioná-los aos grupos de conta padrão, não aos grupos do sistema. Depois que o novo comportamento estiver habilitado, as tentativas de modificar os direitos do grupo do sistema falharão.
-
Se
usersouadminsestiver aninhado em outro grupo, remova o aninhamento. O aninhamento não é permitido com o novo comportamento. -
Se a sincronização do SCIM excluir grupos de workspace que não reconhece, atualize sua configuração para preservar o grupo de clones de migração (
users-clone-<TIMESTAMP>). Se a sincronização remover o grupo clone, as identidades migradas para ele perderão suas permissões.
Timeline
- 15 de junho de 2026 – Aceitação disponível nas configurações do workspace no controle de Acesso Avançado>.
- 27 de julho de 2026 – Habilitado automaticamente para espaços de trabalho que não tiverem optado por participar nem por não participar. A opção de não participar continua disponível.
- 14 de setembro de 2026 – Novo comportamento imposto para todos os workspaces. Desativação removida.
Você gerencia o novo comportamento de suas configurações de workspace no controle de Acesso Avançado>:
Antes da adesão: o comportamento legado está ativo.
Depois de aceitar ou habilitar automaticamente: o novo comportamento está ativo.
O Embed Genie Space estará disponível em breve por padrão para espaços de trabalho com o perfil de segurança de conformidade habilitado
A inserção de um Genie Space como um iframe estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado em junho de 2026.
A inserção de um Genie Space permite que os usuários corporativos interajam com o Genie diretamente em suas ferramentas internas ou portais sem navegar para Azure Databricks.
Consulte Inserir um Genie Space em um aplicativo externo.
Os alertas do DATAbricks SQL em breve estarão disponíveis por padrão para workspaces com o perfil de segurança de conformidade habilitado
Os alertas do DATAbricks SQL estarão disponíveis por padrão para workspaces com o perfil de segurança de conformidade habilitado em junho de 2026.
Use alertas sql do Databricks para monitorar dados e KPIs executando consultas em um agendamento, avaliando condições e notificando os destinatários quando as condições forem atendidas. Casos de uso comuns incluem monitorar desvios de KPIs, detectar anomalias e identificar problemas de qualidade dos dados.
Consulte os alertas do DATAbricks SQL.
O chat do Genie estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado
O chat do Genie estará disponível por padrão para workspaces com o perfil de segurança de conformidade habilitado em junho de 2026.
O chat do Genie fornece uma interface unificada em tela inteira para fazer perguntas sobre dados em linguagem natural. Ele usa painéis, consultas, Genie Spaces e exibições de métrica existentes para responder suas perguntas com todos os dados disponíveis.
Veja o chat do Genie.
Modelo de permissões unificadas para projetos criados com a API de instância de banco de dados
Entre 11 de maio e 21 de maio de 2026, o Lakebase Autoscaling está lançando um modelo de permissões unificadas para novos projetos criados com a API de instância de banco de dados ou ferramentas relacionadas (CLI, SDKs, Terraform, DABs). Os projetos existentes não são afetados.
Após a distribuição, as permissões de instância e de projeto são gerenciadas por uma camada de permissões unificadas, em vez de dois conjuntos de ACL independentes. A automação existente que usa a API de instância de banco de dados continua funcionando sem alterações.
Consulte permissões (ACLs).
Próxima alteração: Migrar para o escalonamento automático do Lakebase
O Azure Databricks está atualizando todas as instâncias do Lakebase Provisioned para a plataforma Lakebase Autoscaling. As atualizações começam em junho de 2026 para clientes que os solicitaram, com as atualizações de instância restantes continuando nas semanas seguintes. Os administradores do workspace receberão um email com datas de atualização antes do início da atualização.
A atualização é automática. As conexões são reiniciadas brevemente durante a transição e cadeias de conexão existentes, chamadas à API, Pacotes de Automação Declarativa e configurações do Terraform continuam funcionando sem modificação.
Após a atualização, as seguintes alterações se aplicam:
Suas instâncias oferecerão suporte a recursos de escalonamento automático e poderão ser gerenciadas pela nova interface de Escalonamento automático e pela já conhecida interface Provisioned, que permanecerá disponível até 1º de setembro de 2026.
Cada instância recebe um novo cadeia de conexão regional que fornece entrada otimizada:
- Cadeias de conexão existentes: As cadeias de conexão provisionadas (sem uma região) continuam a funcionar por meio do Link Privado de entrada existente e não exigemLink Privado Direto do Serviço.
- Nova cadeia de conexão regional: se você usa o Link Privado e se conecta ao Lakebase de fora do workspace do Azure Databricks, deve configurar o Link Privado de entrada para serviços que exigem alto desempenho para usar a nova cadeia de conexão regional.
Para usar novos recursos de dimensionamento automático, como escala para zero em seus Pacotes de Automação Declarativa e configurações do Terraform, atualize-os para usar a semântica de dimensionamento automático.
Aplicam-se os preços do Lakebase para GA. Com a computação elástica substituindo instâncias de tamanho fixo, a maioria dos clientes verá uma redução nos custos de computação.
Os recursos de Visualização Privada do ETL Forward e da API REST no Lakebase Provisioned ficam desativados após a atualização. Suas substituições, o Feed de Dados de Alterações do Lakebase e a API de Dados, estão disponíveis na plataforma de dimensionamento automático.
O Dimensionamento Automático do Lakebase adiciona dimensionamento automático e dimensionamento para zero, restauração pontual e instantâneos, agendamento da janela de manutenção, ramificação de banco de dados e outros aprimoramentos. Para obter detalhes sobre o que esperar, quais alterações e quais ações tomar, consulte Atualizar para Dimensionamento Automático.
Para solicitar uma atualização acelerada ou se você tiver dúvidas, entre em contato com sua equipe de conta ou Azure Databricks Suporte.
O suporte ao formato de arquivo do Excel estará disponível em breve por padrão
O suporte ao formato de arquivo Excel estará disponível por padrão para todos os espaços de trabalho no início de junho de 2026. Você pode ingerir, analisar e consultar .xls, .xlsxe .xlsm arquivos diretamente usando suporte interno, sem bibliotecas externas ou conversões manuais. Os administradores do espaço de trabalho podem habilitá-lo agora em Configurações>Prévias>Suporte ao formato de arquivo do Excel. Requer o Databricks Runtime 17.1 ou superior.
Consulte Leitura de arquivos Excel.
O Databricks Runtime 19 usará um modelo de versão unificada
A partir da versão 19, o Databricks Runtime usará um modelo de versão 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 da versão.
Após um Beta inicial, cada versão do Databricks Runtime será iniciada como GA (disponibilidade geral) e receberá novos recursos e correções aproximadamente semanalmente, com atualizações diferenciadas por data em uma única página. Os clusters receberão atualizações quando forem reiniciados. Após aproximadamente seis meses, a versão faz a transição para LTS (suporte de longo prazo) com três anos de suporte.
Databricks Runtime 18 é a versão de transição. As páginas de versão do recurso 18.0, 18.1 e 18.2 permanecem disponíveis para referência histórica e o Databricks Runtime 18 LTS será a versão unificada final na linha 18.x.
Anexos tabulares em assinaturas de e-mail de painéis para espaços de trabalho com o perfil de segurança de conformidade habilitado
Anexos tabulares em assinaturas de email de painel estarão disponíveis por padrão para espaços de trabalho com o perfil de segurança de conformidade ativado em junho de 2026.
Os assinantes de e-mail recebem uma captura em PDF e, opcionalmente, dados tabulares de widgets selecionados do painel como anexos em arquivos CSV, TSV ou Excel.
Conexões do Power BI farão a transição para o ADBC
O Power BI planeja fazer a transição de todas as conexões do Power BI para a Arrow Database Connectivity (ADBC) em julho de 2026. Para evitar interrupções, o Databricks recomenda mudar seus modelos semânticos de desenvolvimento e preparo para a ADBC agora e validar suas cargas de trabalho.
O driver do ADBC para Power BI no Azure Databricks está em versão prévia pública desde outubro de 2025. Desde fevereiro de 2026, todas as novas conexões no Power BI Desktop e no serviço do Power BI usam o ADBC por padrão. As conexões existentes continuam a usar o ODBC, a menos que você as atualize manualmente.
Consulte Configurar o driver ADBC ou ODBC para o Power BI.
A autorização do usuário para Aplicativos do Databricks estará disponível em breve para workspaces com o perfil de segurança de conformidade habilitado
No início de junho de 2026, a autorização do usuário para Aplicativos do Databricks será habilitada automaticamente para workspaces com o perfil de segurança de conformidade habilitado. A autorização do usuário permite que os aplicativos atuem com a identidade do usuário do aplicativo, para que os aplicativos possam acessar recursos em nome do usuário ao impor as permissões existentes do usuário.
Consulte a autorização do usuário.
Em breve, as permissões dos objetos do espaço de trabalho serão herdadas de todos os grupos de contas
Em uma versão futura, as permissões de objeto do workspace serão herdadas de todos os grupos de contas, não apenas de grupos diretamente atribuídos ao workspace. Usuários e grupos herdarão permissões em objetos de workspace, como trabalhos, notebooks, pastas, consultas e dashboards, de todos os grupos de contas dos quais são membros, independentemente de estarem atribuídos ao workspace. Os usuários ainda precisam ser designados ao espaço de trabalho para usar essas permissões.
Essa alteração também ativa as concessões de permissões que estão inativas ("órfãs"). Essas são concessões de permissão que permanecem em um grupo depois que ele é removido de uma área de trabalho. Nenhuma nova permissão está sendo adicionada, mas as concessões órfãs existentes se tornarão ativas, potencialmente dando aos membros do workspace acesso inesperado. Por exemplo, se um grupo "Empreiteiros" tiver sido removido de um workspace, mas ainda tiver acesso de edição a uma pasta, qualquer membro do workspace em "Empreiteiros" obterá acesso a essa pasta.
O Databricks recomenda revisar as permissões do workspace. Use o notebook a seguir para identificar concessões de permissão inativas em seus workspaces:
Notebook de análise de permissões órfãs
Em breve, tokens de acesso pessoal com escopo estarão disponíveis por padrão para espaços de trabalho com o perfil de segurança de conformidade habilitado.
Os tokens de acesso pessoal com escopo estarão disponíveis por padrão para os espaços de trabalho com o perfil de segurança de conformidade habilitado no final de maio de 2026.
Os tokens pessoais de acesso restrito limitam as permissões de um PAT a determinadas operações de API, atribuindo um ou mais escopos de API, em vez de conceder total acesso ao espaço de trabalho da identidade que os criou.
Consulte Autenticar com tokens de acesso pessoal do Azure Databricks (herdado).
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.
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 4 de maio de 2026, 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.
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 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.