Novità in arrivo

Informazioni sulle funzionalità e sulle modifiche comportamentali nelle prossime versioni di Azure Databricks.

Prossima modifica del comportamento: MANAGE non richiede più né USE CATALOG né USE SCHEMA sullo stesso oggetto

Il privilegio MANAGE consente agli utenti di gestire i privilegi su, trasferire la proprietà di ed eliminare un oggetto senza essere proprietario.

In genere, i privilegi di utilizzo (USE CATALOG e USE SCHEMA) sono prerequisiti per l'interazione con un oggetto Catalogo Unity. Oggi, il MANAGE privilegio per un catalogo o uno schema diventa effettivo solo se si hanno anche i privilegi di utilizzo appropriati.

A partire dal 3 agosto 2026, MANAGE non sarà più necessario il privilegio di utilizzo per l'oggetto specifico in cui MANAGE viene concesso. Questa modifica rende MANAGE il comportamento più coerente con la proprietà dell'oggetto. Saranno comunque necessari privilegi di utilizzo per tutti i contenitori padre. Per esempio:

• Attualmente, la gestione di uno schema richiede USE CATALOG + USE SCHEMA + MANAGE su tale schema.
• Dopo la modifica, la gestione di uno schema richiede solo USE CATALOG + MANAGE su tale schema.

La tabella seguente riepiloga i nuovi requisiti per la gestione degli oggetti:

Cosa non cambia

• USE CATALOG e/o USE SCHEMA sono ancora necessari nei contenitori padre al di sopra dell'oggetto per cui viene concesso MANAGE, a meno che l'utente non abbia la proprietà o MANAGE sul contenitore padre.
• Tutti gli altri privilegi rimangono invariati e continuano a richiedere USE CATALOG e USE SCHEMA quali prerequisiti. L'interrogazione di una tabella richiede ancora SELECT sulla tabella, oltre a USE CATALOG e USE SCHEMA nel catalogo e nello schema padre. L'applicazione di un tag a uno schema richiede ancora APPLY TAG e USE SCHEMA sullo schema, oltre a USE CATALOG nel catalogo padre.

Raccomandazione

Se hai concesso MANAGE in generale (ad esempio, per semplificare la delega) senza concedere anche i privilegi USE corrispondenti, tieni presente che tali MANAGE concessioni diventeranno attive: i titolari otterranno la possibilità di gestire tale oggetto dopo questa modifica. Databricks consiglia di controllare le concessioni esistenti MANAGE per verificare che riflettano l'accesso previsto.

La Ricerca basata sull'IA con QPS elevato sarà presto disponibile per impostazione predefinita nelle aree di lavoro con il profilo di sicurezza per la conformità abilitato

Il QPS elevato di AI Search sarà disponibile per impostazione predefinita per le aree di lavoro con il profilo di sicurezza della conformità abilitato alla fine di agosto 2026.

Imposta un QPS target sugli endpoint standard di AI Search per supportare carichi di lavoro a throughput elevato e in tempo reale come barre di ricerca, sistemi di raccomandazione e matching di entità. L'opzione QPS elevata è abilitata per impostazione predefinita, ma gli endpoint esistenti non sono interessati. La capacità aggiuntiva e il costo associato si applicano solo quando si configura un QPS di destinazione per un endpoint.

Consulta Come scalare il throughput degli endpoint di AI Search con QPS elevato.

La tabella di sistema dei tag regolamentati sarà disponibile in Beta

Azure Databricks prevede di lanciare la system.governance.governed_tags tabella di sistema in versione beta. Questa tabella contiene i record versionati per tutte le chiavi di tag gestite nel tuo account, inclusi quelli creati dal cliente e quelli generati dal sistema.

I servizi MCP forniti da Azure Databricks saranno presto generalmente disponibili

Azure Databricks servizi MCP forniti per applicazioni SaaS come Slack, GitHub, Atlassian e Google Drive saranno presto disponibili a livello generale, con operazioni di lettura e scrittura abilitate per impostazione predefinita. Gli amministratori e gli utenti possono disabilitare i servizi MCP e i singoli strumenti in Unity AI Gateway.

Vedere Connettere gli agenti a strumenti di terze parti con i servizi MCP.

Il connettore SharePoint in Lakeflow Connect sarà presto generalmente disponibile

Il connettore SharePoint in Lakeflow Connect sarà presto disponibile a livello generale. È possibile acquisire file e dati strutturati dai siti SharePoint in Azure Databricks per la trasformazione, l'analisi e le pipeline downstream.

Vedi connettore SharePoint.

Il connettore Google Drive in Lakeflow Connect sarà presto disponibile a livello generale

Il connettore Google Drive in Lakeflow Connect sarà presto disponibile a livello generale. È possibile inserire file da Google Drive in Azure Databricks per le pipeline di trasformazione, analisi e downstream.

Vedere Connettore Google Drive.

Passare all'editor della pipeline predefinito per le aree di lavoro con il profilo di sicurezza di conformità abilitato

L'editor di Lakeflow Pipelines è disponibile a livello generale a partire da maggio 2026. In agosto diventerà l'editor predefinito per lo sviluppo e il debug di pipeline nelle aree di lavoro con il profilo di sicurezza di conformità abilitato. In quel momento l'editor legacy verrà rimosso.

Per altre informazioni sull'editor delle pipeline di Lakeflow, vedere Sviluppare ed eseguire il debug di pipeline ETL con l'editor di pipeline di Lakeflow. Per domande su questa transizione, contattare il tuo team account.

Modifiche del comportamento per processi e pipeline continue

All'inizio di agosto 2026, le pipeline e i processi continui di Lakeflow riceveranno aggiornamenti per semplificare la configurazione e la gestione dello stato.

Pipeline continue

Sarà possibile configurare una pianificazione continua direttamente dalla pagina della pipeline, incluse le impostazioni a livello di processo, ad esempio la modalità prestazioni. Configurando una pianificazione continua in questo modo, la pipeline viene trasformata in un processo in esecuzione continua.

Databricks consiglia di eseguire pipeline continue con un processo continuo anziché con l'impostazione continua predefinita della pipeline. Quando un processo continuo esegue il wrapping di una pipeline, il processo gestirà il ciclo di vita di esecuzione della pipeline. L'impostazione continua predefinita non viene rimossa, ma le nuove pipeline continue devono usare il modello di processo continuo.

Processi continui

La gestione dello stato per i processi continui sarà semplificata. Verranno applicate le modifiche di rilievo seguenti:

• L'aggiunta di una pianificazione continua a un processo annulla tutte le esecuzioni attive, indipendentemente dal fatto che la pianificazione venga sospesa o annullata.
• La rimozione di una schedulazione continua da un processo annullerà tutte le esecuzioni in corso.
• L'esecuzione di un processo continuo in pausa lo riattiverà.
• Se si sospende un processo continuo, verrà annullata anche l'esecuzione attiva.
• L'arresto dell'esecuzione attiva di un processo continuo sospende anche il processo.

Un nuovo campo API di sola lettura tiene traccia dello stato di un processo continuo.

Esaminare tutti i flussi di lavoro o di automazione che si basano sui comportamenti dei processi continui correnti e aggiornarli prima di questa versione.

L'attività di avviso SQL in Lakeflow Jobs sarà disponibile per impostazione predefinita

L'attività di avviso SQL in Lakeflow Jobs è ora generalmente disponibile e sarà abilitata per impostazione predefinita nel tuo spazio di lavoro. Usa l'attività per verificare un avviso SQL di Databricks come parte di un job Lakeflow. La task restituisce il proprio stato di valutazione come valore di output, in modo che le task successive possano diramarsi in base al risultato.

Vedere Attività di avviso SQL per i processi.

La creazione dell'area di lavoro classica con una rete virtuale gestita da Azure Databricks sarà presto deprecata

In una versione futura, Azure Databricks prevede di deprecare la creazione dell'area di lavoro classica con una rete virtuale gestita da Azure Databricks. Per le nuove aree di lavoro, Azure Databricks consiglia un'area di lavoro serverless per l'avvio rapido più semplice o l'inserimento di reti virtuali se è necessaria un'area di lavoro classica. Una sequenza temporale dettagliata della migrazione verrà comunicata separatamente.

Vedere Rete del piano di calcolo classico.

La connettività sicura del cluster diventerà presto obbligatoria per le aree di lavoro classiche

In una versione futura, Azure Databricks prevede di richiedere la connettività del cluster sicura per tutte le aree di lavoro classiche. Le aree di lavoro create con enableNoPublicIp impostato su false non saranno più supportate e il parametro diventerà obbligatorio. Una sequenza temporale dettagliata della migrazione verrà comunicata separatamente.

Vedere Abilitare la connettività sicura del cluster.

Prossime modifiche alla fatturazione di Azure per OpenSharing SecureConnect

Azure Databricks addebiterà presto ai provider l'uso di OpenSharing SecureConnect per l'uscita tra aree e dati internet pubblici.

Gli addebiti si applicano quando:

• Il destinatario si trova in un'area diversa rispetto all'archiviazione del provider.
• Il traffico esce verso Internet pubblica.

Non vengono addebitati costi per il traffico in entrata verso SecureConnect né per il traffico in uscita verso i destinatari nella stessa area geografica.

Per i prezzi e le domande frequenti, vedere Prezzi di trasferimento e connettività dei dati.

Zerobus Ingest sarà presto disponibile per impostazione predefinita per le aree di lavoro con il profilo di sicurezza di conformità abilitato

Il connettore Zerobus Ingest in Lakeflow Connect verrà abilitato per impostazione predefinita per le aree di lavoro con il profilo di sicurezza della conformità abilitato a metà luglio 2026.

Zerobus Ingest è un'API di inserimento basata su push che scrive i dati direttamente nelle tabelle Delta del catalogo Unity. Consulta Panoramica del connettore di Ingest Zerobus.

Lakeflow Designer sarà presto disponibile per impostazione predefinita per le aree di lavoro con il profilo di sicurezza di conformità abilitato

Lakeflow Designer sarà disponibile per impostazione predefinita per le aree di lavoro con il profilo di sicurezza di conformità abilitato alla fine di luglio 2026.

Lakeflow Designer è un'esperienza visiva no-code per preparare e trasformare i dati in un'area di lavoro drag-and-drop, con tutti i flussi di lavoro supportati da codice pronto per l'uso in produzione e governato da Unity Catalog.

Vedere Lakeflow Designer.

I bundle di automazione dichiarativa utilizzeranno presto per impostazione predefinita il motore di distribuzione diretta

Il 24 luglio 2026, i bundle di automazione dichiarativa inizieranno a usare il motore di distribuzione diretta per impostazione predefinita anziché il motore di distribuzione Terraform. Verrà attivata una migrazione per tutti i bundle che usano ancora il motore di distribuzione Terraform.

Per altre informazioni sul motore di distribuzione diretta e sulla migrazione dal motore di distribuzione Terraform, vedere Eseguire la migrazione al motore di distribuzione diretta.

Il motore di distribuzione Terraform verrà infine rimosso e non sarà più disponibile.

ai_extract e ai_classify saranno presto disponibili per impostazione predefinita per le aree di lavoro con il profilo di sicurezza di conformità abilitato

Le ai_extract funzioni di intelligenza artificiale e ai_classify SQL saranno disponibili per impostazione predefinita per le aree di lavoro con il profilo di sicurezza della conformità abilitato e i controlli HIPAA, HITRUST, C5 e TISAX selezionati a metà luglio 2026.

Usare ai_extract per estrarre campi strutturati da testo non strutturato rispetto a uno schema definito dall'utente. Usare ai_classify per classificare il testo in etichette definite dall'utente per il routing, l'assegnazione di tag e i flussi di lavoro di categorizzazione dei documenti. È anche possibile usare i mattoni agente per creare un agente di estrazione delle informazioni e un agente di classificazione.

Modifica del comportamento imminente: scegliere i diritti quando si aggiungono entità alle aree di lavoro

Databricks sta cambiando il modo in cui le entità ottengono i diritti dell'area di lavoro. Dopo questa modifica, si concedono i diritti in modo esplicito quando si aggiunge un'entità a un'area di lavoro invece di basarsi sull'ereditarietà dal users gruppo di sistema. Gli amministratori dell'area di lavoro possono acconsentire esplicitamente a partire dal 15 giugno 2026 e il nuovo comportamento viene applicato per tutte le aree di lavoro il 14 settembre 2026.

Questa modifica consente di aggiungere identità in qualsiasi livello di accesso, inclusi gli utenti di tipo consumer, senza che ereditino automaticamente i privilegi di authoring.

Cosa cambia

Ogni area di lavoro ha due gruppi di sistema: users, che include tutte le entità a cui è concesso l'accesso all'area di lavoro e admins, che include gli amministratori dell'area di lavoro. Attualmente, ogni entità aggiunta a un'area di lavoro eredita i diritti concessi a users. Per impostazione predefinita, si tratta di:

• Accesso all'area di lavoro : creare e usare notebook, processi, pipeline, app e altro ancora.
• Accesso SQL di Databricks : creare e usare dashboard, genie agents, avvisi e altro ancora.

Dopo la modifica:

• Il users gruppo non avrà diritti. Il admins gruppo avrà tutti i diritti dell'area di lavoro. Entrambi i diritti dei gruppi sono bloccati.
• Le nuove entità devono essere concesse in modo esplicito ai diritti quando vengono aggiunte a un'area di lavoro.
• users e admins non possono essere annidati come membri di altri gruppi.

Le entità esistenti mantengono il livello di accesso corrente. Databricks esegue automaticamente la migrazione delle autorizzazioni precedentemente concesse a users a un nuovo gruppo clone locale dell'area di lavoro denominato users-clone-<TIMESTAMP> (dove <TIMESTAMP> indica l'ora della migrazione). Il gruppo clone viene gestito come qualsiasi altro gruppo locale dell'area di lavoro ed è possibile personalizzarne il nome quando si acconsente in anticipo. Il admins gruppo non richiede la migrazione.

Azione richiesta

• Se si gestiscono i diritti del gruppo di sistema tramite l'automazione (Terraform, API SCIM dell'area di lavoro o script personalizzati), aggiornare i flussi di lavoro ai gruppi di account standard di destinazione, non ai gruppi di sistema. Dopo aver abilitato il nuovo comportamento, i tentativi di modificare i diritti del gruppo di sistema avranno esito negativo.
• Se users o admins è annidato come membro di un altro gruppo, rimuoverlo. L'annidamento non è consentito con il nuovo comportamento.
• Se la sincronizzazione SCIM elimina i gruppi di aree di lavoro che non riconosce, aggiornarne la configurazione per mantenere il gruppo clone di migrazione (users-clone-<TIMESTAMP>). Se la sincronizzazione rimuove il gruppo clonato, le identità migrate al suo interno perdono le autorizzazioni.

Sequenza temporale

• 15 giugno 2026 - Consenso esplicito disponibile nelle impostazioni dell'area di lavoro in Controllo di accesso avanzato>.
• 27 luglio 2026 – Abilitato automaticamente per le aree di lavoro che non hanno effettuato l'adesione o la disattivazione esplicita. La disattivazione esplicita rimane disponibile.
• 14 settembre 2026 - Nuovo comportamento applicato per tutte le aree di lavoro. Disiscrizione rimossa.

È possibile gestire il nuovo comportamento dalle impostazioni dell'area di lavoro in Controllo di accesso avanzato>:

Prima dell'adesione: è attivo il comportamento precedente.

Dopo il consenso esplicito o l'abilitazione automatica: il nuovo comportamento è attivo.

Per altre informazioni, vedi Eseguire la migrazione del controllo dei diritti dell'area di lavoro.

Profilo di sicurezza di conformità necessario per HIPAA, HITRUST e IRAP

A partire dal 1° settembre 2026, il profilo di sicurezza della conformità sarà necessario per elaborare i dati protetti in HIPAA, HITRUST e IRAP.

Consulta il profilo di sicurezza della conformità .

Modifica imminente: Aggiornamento alla scalabilità automatica di Lakebase

Azure Databricks sta aggiornando tutte le istanze di Lakebase Provisioned alla piattaforma di scalabilità automatica di Lakebase. Gli aggiornamenti iniziano a giugno 2026 per i clienti che li hanno richiesti, con gli aggiornamenti dell'istanza rimanenti che continuano nelle settimane successive. Gli amministratori dell'area di lavoro riceveranno un messaggio di posta elettronica con date di aggiornamento prima dell'inizio dell'aggiornamento.

L'aggiornamento è automatico. Le connessioni vengono riavviate brevemente durante la transizione e le stringhe di connessione esistenti, le chiamate API, i bundle di automazione dichiarativa e le configurazioni terraform continuano a funzionare senza modifiche.

Dopo l'aggiornamento, si applicano le modifiche seguenti:

• Le istanze supporteranno le funzionalità di scalabilità automatica e possono essere gestite tramite la nuova interfaccia utente di scalabilità automatica e l'interfaccia utente con provisioning familiare, che rimane disponibile fino al 1° settembre 2026.

• Ogni istanza riceve un nuovo stringa di connessione a livello di area che fornisce ingresso ottimizzato:

  • Stringhe di connessione esistenti: Le stringhe di connessione di cui è stato effettuato il provisioning (senza un'area geografica) continuano a funzionare tramite il collegamento privato privato in ingresso esistente e non richiedonoService Direct collegamento privato.
  • Nuova stringa di connessione regionale: se si usa collegamento privato e ci si connette a Lakebase dall'esterno dell'area di lavoro di Azure Databricks, è necessario configurare collegamento privato in ingresso per i servizi a uso intensivo delle prestazioni per usare la nuova stringa di connessione regionale.

• Per utilizzare le nuove funzionalità di autoscaling, come scale-to-zero, nei tuoi bundle di automazione dichiarativa e nelle configurazioni Terraform, aggiornali affinché usino la semantica dell’autoscaling.

• Si applicano i prezzi di Lakebase GA. Con il calcolo elastico che sostituisce le istanze a dimensione fissa, la maggior parte dei clienti vedrà una riduzione dei costi di calcolo.

• Le funzionalità Forward ETL e REST Api Private Preview in Lakebase Provisioned sono disabilitate dopo l'aggiornamento. I relativi sostituti, Lakebase Change Data Feed e la Data API, sono disponibili sulla piattaforma Autoscaling.

La scalabilità automatica di Lakebase aggiunge la scalabilità automatica e la scalabilità a zero, il ripristino temporizzato e gli snapshot, la pianificazione delle finestre di manutenzione, la diramazione del database e altri miglioramenti. Per informazioni dettagliate su cosa aspettarsi, sulle modifiche e sulle azioni da eseguire, vedere Eseguire l'aggiornamento alla scalabilità automatica.

Per richiedere un aggiornamento urgente o in caso di domande, contattare il team responsabile dell'account o il supporto tecnico di Azure Databricks.

Databricks Runtime 19 userà un modello di versione unificata

A partire dalla versione 19, Databricks Runtime userà un modello di versione unificata. Anziché più versioni delle funzionalità (ad esempio, 19.0, 19.1, 19.2), ogni versione principale avrà una singola pagina delle note sulla versione.

Dopo una versione beta iniziale, ogni versione di Databricks Runtime verrà avviata come disponibile a livello generale e riceverà nuove funzionalità e correzioni circa settimanali, con aggiornamenti differenziati per data in una singola pagina. I cluster riceveranno aggiornamenti al riavvio. Dopo circa sei mesi, la versione passa al supporto a lungo termine (LTS) con tre anni di supporto.

Databricks Runtime 18 è la versione di transizione. Le pagine delle versioni di funzionalità 18.0, 18.1 e 18.2 rimangono disponibili per consultazione storica e Databricks Runtime 18 LTS sarà la versione unificata finale della serie 18.x.

Power BI connessioni passeranno ad ADBC

Power BI prevede di eseguire la transizione di tutte le connessioni Power BI a Arrow Database Connectivity (ADBC) nell'agosto 2026. Per evitare interruzioni, Databricks consiglia di passare ora a ADBC i modelli semantici di sviluppo e staging e convalidare i carichi di lavoro.

Il driver ADBC per Power BI su Azure Databricks è stato visualizzato in anteprima pubblica a partire da ottobre 2025. A partire da febbraio 2026, tutte le nuove connessioni in Power BI Desktop e il servizio Power BI usano ADBC per impostazione predefinita. Le connessioni esistenti continuano a usare ODBC a meno che non vengano aggiornate manualmente.

Vedere Configurare il driver ADBC o ODBC per Power BI.

Le autorizzazioni per gli oggetti dell'area di lavoro verranno presto ereditate da tutti i gruppi di account

In una versione futura le autorizzazioni per gli oggetti dell'area di lavoro verranno ereditate da tutti i gruppi di account, non solo dai gruppi assegnati direttamente all'area di lavoro. I principali erediteranno le autorizzazioni sugli oggetti dello spazio di lavoro, come processi, notebook, cartelle, query e dashboard, da tutti i gruppi di account di cui fanno parte, indipendentemente dal fatto che tali gruppi siano assegnati allo spazio di lavoro. Gli utenti devono comunque essere assegnati all'area di lavoro per usare queste autorizzazioni.

Questa modifica attiva anche le autorizzazioni inattive ("orfane"). Queste sono concessioni di autorizzazione che rimangono a un gruppo dopo la sua rimozione da un workspace. Non vengono aggiunte nuove autorizzazioni, ma le concessioni orfane esistenti diventeranno attive, consentendo potenzialmente ai membri dell'area di lavoro di accedere in modo imprevisto. Ad esempio, se un gruppo "Contractors" è stato rimosso da un'area di lavoro ma ha ancora accesso alla modifica a una cartella, qualsiasi membro dell'area di lavoro in "Contractors" otterrà l'accesso a tale cartella.

Databricks consiglia di esaminare le autorizzazioni dell'area di lavoro. Usa il notebook seguente per identificare i permessi inattivi nei tuoi workspace.

Notebook di analisi delle autorizzazioni rimaste orfane

Ottieni il notebook

Modifica di rilievo imminente: comportamento predefinito durante l'eliminazione di una pipeline del catalogo Unity

In una versione futura, il comportamento predefinito durante l'eliminazione di una pipeline del catalogo Unity cambierà. Attualmente, l'eliminazione di una pipeline rimuove anche tutte le viste materializzate associate, le tabelle di streaming e le viste. Dopo questa modifica, le tabelle associate verranno mantenute, ma inattive dopo la rimozione della pipeline. L'API cambierà anche per conservare le tabelle per impostazione predefinita, ma impostando il campo cascade su true si esegue l'override e si mantiene il comportamento corrente.

Il cascade campo è ora disponibile. Per mantenere il comportamento corrente della rimozione di tutte le tabelle durante l'eliminazione di una pipeline, aggiornare il codice per impostare cascade=true.

Vedere Eliminare una pipeline ed Eliminare una pipeline.

Nuovo abilitazione predefinita dell'editor SQL e ritiro dell'editor SQL legacy

Il nuovo editor SQL è disponibile a livello generale a partire da ottobre 2025. Nell'ambito della transizione al nuovo editor, sono pianificate le modifiche seguenti:

• A partire dalla fine di maggio 2026: il nuovo editor SQL verrà abilitato per impostazione predefinita per tutte le aree di lavoro. La possibilità di disattivare la funzionalità a livello di area di lavoro non sarà più disponibile. I singoli utenti potranno comunque passare le query all'editor SQL legacy dopo l'inizio di questo periodo.
• A partire dalla fine di luglio 2026: l'editor SQL legacy verrà ritirato. Tutti gli utenti useranno il nuovo editor SQL e il singolo rifiuto esplicito non sarà più disponibile.

Per altre informazioni sul nuovo editor SQL, vedere Scrivere query ed esplorare i dati nel nuovo editor SQL. Per domande su questa transizione, contattare il tuo team account.

Modifiche apportate a OpenSharing (in precedenza Condivisione Delta) per i token dei destinatari aperti

OpenSharing per i destinatari aperti passerà a un nuovo formato di URL specifico del destinatario. I nuovi token creati dopo la data di transizione useranno automaticamente il nuovo formato url. Questa modifica migliora la sicurezza di rete e consente ai destinatari di configurare criteri di rete e regole del firewall specifici dei destinatari.

Per Azure Cina, la transizione verrà annunciata in un secondo momento.

I nuovi URL includono l'ID destinatario nel dominio:

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

Per riferimento, gli URL creati prima di questa modifica non contengono l'ID destinatario e usano l'endpoint di condivisione delta.

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

Gli URL precedenti continueranno a funzionare per un periodo di tempo. La durata specifica dipende dal tipo di destinatario e dalla data di creazione del token. I provider di dati devono passare al nuovo formato URL prima che il formato dell'URL precedente non sia valido.

Condivisione della federazione OIDC:

Databricks consiglia ai provider di dati di iniziare la transizione dei destinatari al nuovo formato URL. Anche se non è stata impostata una data di transizione, è ora possibile eseguire la transizione per consentire la risoluzione dei problemi. Dopo la transizione, i provider possono trovare il nuovo URL nell'interfaccia utente di OpenSharing. Dopo aver ritirato il formato di URL precedente, non è più valido.

Condivisione di token di autenticazione:

Condivisione e archiviazione predefinita di Lakehouse Federation

La Delta Sharing su Lakehouse Federation è in versione beta, consentendo ai provider di dati per Delta Sharing di condividere cataloghi e tabelle esterne. Per impostazione predefinita, i dati devono essere temporaneamente materializzati e archiviati nell'archiviazione predefinita (anteprima privata). Attualmente, gli utenti devono abilitare manualmente la funzionalità Condivisione delta per l'archiviazione predefinita - Accesso espanso nella console dell'account per usare la condivisione di Lakehouse Federation.

Dopo Delta Sharing for Default Storage – Expanded Access è abilitato per impostazione predefinita per tutti gli utenti Azure Databricks, La condivisione Delta in Lakehouse Federation sarà automaticamente disponibile nelle aree in cui è supportata l'archiviazione predefinita.

Vedere Archiviazione predefinita in Databricks e Aggiungere schemi o tabelle esterne a una condivisione.

Il Delta Sharing per le tabelle sullo storage predefinito verrà abilitato di default a breve (Beta)

Questo aggiornamento di archiviazione predefinita per Delta Sharing ha ampliato le funzionalità di condivisione, consentendo ai provider di condividere tabelle supportate dall'archiviazione predefinita con qualsiasi destinatario di Delta Sharing (open o Azure Databricks), inclusi i destinatari che utilizzano il computing classico. Questa funzionalità è attualmente in versione beta e richiede ai provider di abilitare manualmente la condivisione delta per l'archiviazione predefinita - Accesso espanso nella console dell'account. A breve, questa opzione verrà abilitata per impostazione predefinita per tutti gli utenti.

Vedere Limitazioni.

Aggiornamenti agli indirizzi IP pubblici del piano di controllo esterno

Azure Databricks sta aggiornando gli indirizzi IP pubblici del piano di controllo in uscita e i tag di servizio di Azure per migliorare la sicurezza e la disponibilità delle zone. Queste modifiche fanno parte di un aggiornamento del piano di controllo che ha iniziato l'implementazione il 20 maggio 2025.

Se l'organizzazione usa firewall delle risorse per controllare l'accesso in ingresso:

• Se le regole del firewall fanno riferimento al tag Azure Databricks service, non è necessaria alcuna azione.
• Se si consentono indirizzi IP pubblici specifici del piano di controllo, è necessario aggiungere tutti gli INDIRIZZI IP del piano di controllo in uscita entro il 26 settembre 2025.

Gli indirizzi IP del piano di controllo uscente precedenti continuano a essere supportati.

Il campo sourceIpAddress nei log di controllo non includerà più un numero di porta

A causa di un bug, alcuni log di controllo di autorizzazione e autenticazione includono un numero di porta oltre all'Indirizzo IP nel campo sourceIPAddress (ad esempio, "sourceIPAddress":"10.2.91.100:0"). Il numero di porta, registrato come 0, non fornisce alcun valore reale ed è incoerente con il resto dei log di controllo di Databricks. Per migliorare la coerenza dei log di controllo, Databricks ha in programma di modificare il formato dell'indirizzo IP per questi eventi del log di controllo. Questa modifica verrà implementata gradualmente a partire da inizio agosto 2024.

Se il log di controllo contiene un sourceIpAddress di 0.0.0.0, Databricks potrebbe interrompere il log.

L'archiviazione di traccia MLflow in Unity Catalog sarà presto disponibile per impostazione predefinita per le aree di lavoro con il profilo di sicurezza di conformità abilitato

L'archiviazione di traccia MLflow nelle tabelle del catalogo Unity sarà disponibile per impostazione predefinita per le aree di lavoro con il profilo di sicurezza della conformità abilitato a metà agosto 2026.

Archiviare le tracce MLflow nelle tabelle del catalogo Unity per l'archiviazione di traccia scalabile e regolamentata: l'archiviazione è illimitata, le tracce vengono archiviate in formato OpenTelemetry (OTel), l'accesso viene regolato tramite lo schema e le autorizzazioni di tabella del catalogo Unity ed è possibile eseguire query sulle tracce con SQL. Per visualizzare le tracce, imposta un esperimento MLflow in modo che punti a una posizione delle tracce in Unity Catalog.

Vedi Archiviare tracce OpenTelemetry in Unity Catalog.