Transizione da ODBC a driver ADBC in Power BI e Fabric

Power BI e Microsoft Fabric stanno passando le connessioni supportate alle origini dati dai precedenti driver ODBC integrati ai driver Apache Arrow Database Connectivity (ADBC). ADBC offre un set di interfacce standard per l'interazione con i dati Arrow, particolarmente efficienti nel recupero di set di dati di grandi dimensioni con overhead minimo e senza serializzazione o copia. I driver ADBC incorporano anche miglioramenti della sicurezza, ad esempio sicurezza della memoria e Garbage Collection.

È possibile adottare ADBC fin da oggi a livello di singola connessione e gli amministratori possono controllare il comportamento predefinito a livello globale tramite un'impostazione del tenant che gli amministratori dell'area di lavoro possono sovrascrivere per test e convalida.

Modifiche ai connettori e ai driver

Nella tabella seguente sono elencati i connettori che passano dai driver ODBC incorporati ai driver sostitutivi. Nella maggior parte dei casi, il driver sostitutivo è un driver ADBC.

Chi è interessato

Sei interessato se utilizzi uno dei connettori in transizione ad ADBC (ad esempio Databricks, Snowflake o Google BigQuery) e:

• Non è stata scelta in modo esplicito un'implementazione nella connessione (il Implementation parametro non è specificato) o
• L'organizzazione vuole un controllo centralizzato sul fatto che ADBC o ODBC sia l'impostazione predefinita per i connettori supportati.

Questa impostazione predefinita si applica ovunque si crei una connessione, inclusi modelli semantici, Flussi di dati Gen2 e report impaginati.

Come eseguire la migrazione

È possibile eseguire la migrazione in tre modi, ordinati in base alla quantità di controllo desiderata:

• Attivazione facoltativa per connessione: Aggiungi Implementation="2.0" alle singole connessioni per convalidare ADBC secondo i tuoi tempi.
• Impostazione del tenant: impostare l'impostazione predefinita a livello di organizzazione tramite il portale di amministrazione.
• Sostituzione a livello di area di lavoro: sostituisci il valore predefinito del tenant a livello di area di lavoro per la convalida affiancata.

Consenso per ogni connessione

È possibile acconsentire esplicitamente ad ADBC aggiungendo Implementation="2.0" alle connessioni supportate. Questo approccio consente di convalidare ADBC con i propri tempi per ogni singola connessione.

Per istruzioni dettagliate sull'abilitazione esplicita per singola connessione per un connettore specifico, vedere la documentazione specifica del connettore riportata nella tabella Modifiche ai connettori e ai driver.

Impostazione del tenant

Gli amministratori tenant possono impostare l'impostazione predefinita dell'organizzazione usando l'impostazione del portale di amministrazione:

Gli utenti possono connettersi alle origini dati usando la connettività del database Apache Arrow (ADBC)

• Disabilitato (impostazione predefinita): seleziona i driver ODBC legacy come opzione predefinita.
• Abilitato: seleziona i nuovi driver ADBC come opzione predefinita.

Questa impostazione controlla anche il comportamento di Test di connessione per ogni tipo di connessione nel tenant.

Sovrascrittura dell'area di lavoro

L'impostazione del tenant delega le aree di lavoro, in modo che gli amministratori dell'area di lavoro possano ignorare i comportamenti predefiniti e confrontarli senza modificare ogni singola connessione. Questo approccio consente la convalida parallela. Ad esempio, è possibile usare un'area di lavoro per testare le impostazioni predefinite di ADBC mantenendo un'altra area di lavoro nelle impostazioni predefinite ODBC.

Modalità di scelta dell'implementazione

Se si specifica in modo esplicito il Implementation parametro nella connessione, tale valore ha sempre la precedenza sui valori predefiniti del tenant o dell'area di lavoro.

La tabella seguente mostra come viene selezionato il driver:

Comportamento del gateway dati locale

Le impostazioni ADBC del tenant e dell'area di lavoro si applicano ai percorsi di aggiornamento eseguiti nel servizio cloud. Le query che passano attraverso un gateway dati locale continuano a usare il driver incluso nell'installazione del gateway, che attualmente è ODBC per i connettori elencati in questo articolo. Gli aggiornamenti indirizzati al gateway non passano ad ADBC quando l'impostazione del tenant o dell'area di lavoro è abilitata e questo è il comportamento previsto.

Due conseguenze da tenere presenti durante la pianificazione della migrazione:

• Se si usa un gateway per testare la transizione ad ADBC, gli aggiornamenti tramite il gateway non rifletteranno il percorso ADBC. Testare ADBC usando una connessione cloud per convalidare accuratamente il comportamento di ADBC end-to-end.
• I clienti che devono rimanere in ODBC (ad esempio, per mantenere un percorso di collegamento privato attraverso il gateway) possono rinviare la modifica continuando a instradare gli aggiornamenti attraverso il gateway locale con i driver ODBC installati. Si tratta di un differimento, non di un rifiuto esplicito permanente: una volta rimossi i driver ODBC dalle installazioni future del gateway (vedere Date chiave), i gateway aggiunti alle versioni precedenti alla fine non sono supportati. Pianificare gli aggiornamenti del gateway e la convalida di ADBC di conseguenza.

Elenco di controllo per la migrazione consigliato

1. Verifica il tuo ambiente di lavoro con pq-adbc-advisor per inventariare ogni connessione vincolata al driver legacy e visualizzare, per ciascun elemento, la relativa classificazione del rischio. Vedere Controllare l'area di lavoro con pq-adbc-advisor.
2. Selezionare un'area di lavoro pilota e abilitare ADBC prima di tutto usando l'override dell'area di lavoro per convalidare i set di dati chiave e gli scenari di aggiornamento. Per verificare il percorso ADBC end-to-end, eseguire il test usando una connessione cloud: vedere Comportamento del gateway dati locale per capire perché gli aggiornamenti instradati tramite gateway rimangono su ODBC.
3. Convalidare in Power BI Desktop. Installare la versione corrente di Power BI Desktop, che include il driver ADBC per ogni connettore supportato per il quale è già stata completata l'attivazione predefinita. Non esiste alcuna opzione per file per forzare l'uso di ADBC per una query esistente: per fare in modo che una query esistente usi ADBC, elimina la query, aggiungi nuovamente l'origine e seleziona di nuovo i campi. Aggiornare e confrontare i conteggi delle righe, i tipi di colonna e la durata dell'aggiornamento rispetto alla baseline ODBC.
4. Per qualsiasi connessione critica che si desidera convalidare immediatamente, attivare l'opzione per ogni singola connessione con Implementation="2.0".
5. Al termine della convalida, decidere se abilitare ADBC per impostazione predefinita a livello di tenant.

Controllare l'area di lavoro con pq-adbc-advisor

Prima di eseguire la migrazione, è necessario sapere cosa modificare. pq-adbc-advisor è un notebook di Fabric di sola lettura che analizza un'area di lavoro e restituisce un report sull'impatto per ogni elemento, indicando quali modelli semantici, flussi di dati e pipeline di dati usano ancora il driver ODBC legacy e cosa fare per ciascuno di essi.

Cosa ti offre il report di impatto

Il report sull'impatto offre:

• Un inventario di tutte le chiamate dei connettori in migrazione nell'area di lavoro relative ai connettori in transizione ad ADBC.

• Una classificazione del rischio di passaggio per ogni elemento:

  Rischio	Cosa significa il rischio	Cosa fare
  Non riuscirà	I pin Implementation="1.0" di query M e l'elemento non dispone di alcuna associazione gateway. Al momento del cutover, questo refresh smette di funzionare.	Rimuovere [Implementation="1.0"] dalla fase di origine o associare l'elemento a un gateway prima del passaggio finale.
  Da rivedere	La query M vincola ODBC, ma è associata a un gateway (sopravvive al cutover, ma dovrebbe comunque essere commutata), oppure M costruisce una stringa DSN grezza che ADBC non utilizza così com’è.	Testate il percorso ADBC in una copia dell'elemento, quindi procedete con la distribuzione. Per i casi di stringa DSN che il connettore standard non copre, inoltrate il caso alla casella di posta per le escalation indicata nell'acceleratore.
  Ready	La query M blocca già ADBC (Implementation="2.0"), oppure non è bloccata e lo switch del tenant lo gestisce correttamente.	Nessuna azione. Eseguire nuovamente la scansione dopo il passaggio per verificarlo.

• Copertura per le pipeline di dati e Dataflow Gen2, non solo per i modelli semantici.

• Rilevamento della risoluzione tra le analisi: ogni analisi include sia una baseline di prima esecuzione che un contatore di esecuzione corrente, quindi una nuova analisi indica cosa è stato pulito dal primo passaggio.

Cosa non fa il report sull'impatto

Il report di impatto non è:

• Riscrivere qualsiasi espressione M.
• Il Trigger si aggiorna automaticamente (per la convalida è disponibile un'opzione separata di adesione esplicita).
• Inviare codice M, nomi di elementi, URL endpoint, credenziali o aggiornare corpi dei messaggi di errore all'esterno dell'area di lavoro.

Ogni analisi invia conteggi anonimi al team Power Query in modo da poter misurare l'adozione e definire la priorità della copertura del connettore. L'analisi invia solo gli identificatori del tenant e dell'utente sottoposti ad hashing SHA-256, senza valori in chiaro per impostazione predefinita. Per disattivare in qualsiasi momento, disattiva la telemetria come documentato nell'acceleratore. La disattivazione rimane attiva anche dopo i riavvii del kernel.

Come eseguire il report di impatto

Il modo più semplice per usare lo strumento consiste nell'usare il notebook di avvio nella casella degli strumenti Microsoft Fabric.

1. Scaricare il notebook di avvio e importarlo in un'area di lavoro Fabric.
2. Collegare il notebook all'area di lavoro da inventariare.
3. Esegui il notebook dall’alto verso il basso. Installa pq-adbc-advisor nella sessione, analizza lo workspace, visualizza direttamente il report sull'impatto e salva una copia HTML del report nel lakehouse predefinito, se ne colleghi uno.
4. Apportare le correzioni.
5. Esegui nuovamente il notebook. Il report mostra i delta di risoluzione, ovvero il numero di pin puliti dopo la prima analisi.

Se si dispone delle autorizzazioni di amministratore e si vuole eseguire lo sweep di ogni area di lavoro nel tenant, l'acceleratore documenta un'opzione di analisi a livello di tenant che usa l'API scanner di amministrazione Fabric. Le analisi del tenant richiedono in genere 15-30 minuti per un tenant di medie dimensioni.

Per segnalare bug, richiedere nuove funzionalità e segnalare lacune nella copertura dei connettori, consulta il repository dell'acceleratore.

Date chiave

• Luglio 2026 (pianificato): inizia l'implementazione generale dell'impostazione del tenant. Il comportamento dell'area di lavoro eredita questa impostazione e può essere modificato dagli amministratori dell'area di lavoro, ove supportato.
• Ottobre 2026 (previsto): Microsoft prevede di iniziare ad attivare gradualmente per impostazione predefinita l'impostazione del tenant, in base alla prontezza della distribuzione.
• Inizio 1° trimestre 2027 (pianificato): Microsoft prevede di iniziare a rimuovere i driver ODBC dal servizio, in base all'idoneità per l'implementazione. Se è necessario rimanere in ODBC (Implementation="1.0" o l'impostazione dell'area di lavoro Disattivata), è necessario usare un gateway per continuare a eseguire query con ODBC.
• Primavera 2027 (pianificata): i driver ODBC a cui si fa riferimento in questo articolo non sono più disponibili con Power BI Desktop o il gateway.

Prima delle attività cardine di imposizione, Microsoft prevede di fornire una notifica anticipata in modo che i clienti possano completare le attività di migrazione e convalida.

Domande frequenti

È ora possibile testare ADBC?

Yes. Installa la versione corrente di Power BI Desktop e aggiungi nuovamente qualsiasi origine inclusa nell'ambito — le nuove query vengono instradate immediatamente ad ADBC. Per i test sul lato servizio, usare l'override dell'area di lavoro per abilitare ADBC in un'area di lavoro pilota e convalidare tramite una connessione cloud.

Come si trova ogni posizione in cui si usa ancora il driver ODBC legacy?

Esegui pq-adbc-advisor nell'area di lavoro. Si tratta di un notebook Fabric di sola lettura che inventaria tutti i modelli semantici, i flussi di dati e le pipeline di dati che usano ancora il driver legacy. Classifica ciascuno in base al rischio associato al cutover e indica cosa modificare. Considerarlo come diagnostica del punto di partenza, non come controllo finale. Vedere Controllare l'area di lavoro con pq-adbc-advisor. Gli amministratori possono eseguire uno sweep a livello di tenant tramite l'API scanner di amministrazione Fabric. Per informazioni dettagliate, vedere la documentazione dell'acceleratore.

Sono interessati se si usa già il gateway dati locale?

Le impostazioni ADBC del tenant e dell'area di lavoro si applicano solo alle esecuzioni nel servizio, ma non influiscono sugli aggiornamenti indirizzati tramite un gateway dati locale. Gli aggiornamenti indirizzati tramite gateway continuano a usare ODBC tramite cutover per i connettori in questo articolo. Vedi il comportamento del gateway dati locale. È prevista la rimozione dei driver ODBC nelle future installazioni del gateway — consulta le date chiave per le tempistiche.

Come è possibile rifiutare esplicitamente la transizione ADBC?

Non è possibile rifiutare esplicitamente definitivamente. L'impostazione del tenant consente di rinviare l'inversione predefinita durante la finestra di convalida, ma una volta disabilitato ODBC nel servizio, la modifica è universale. Per continuare a usare ODBC dopo il cutover sul lato servizio, è necessario instradare gli aggiornamenti tramite un gateway dati locale con i driver ODBC installati. Questa modifica è solo un rinvio: è prevista la rimozione dei driver ODBC nelle future installazioni del gateway.

Perché l'impostazione di ADBC dell'area di lavoro non modifica il file Power BI Desktop?

Non esiste alcuna opzione per singolo file per ADBC in Power BI Desktop. Le query esistenti in un file di Desktop continuano a utilizzare il driver con cui sono state create finché la query non viene ricreata. Per convalidare ADBC per una query esistente, eliminare la query, aggiungere nuovamente l'origine e selezionare nuovamente i campi. Le nuove query nella versione Desktop corrente vengono instradate automaticamente ad ADBC per i connettori che sono passati all'impostazione predefinita.

L'impostazione ADBC dell'area di lavoro riscrive le query M esistenti?

No. Le impostazioni del tenant e dell'area di lavoro modificano il driver selezionato in fase di esecuzione della query, ma non modificano l'espressione M stessa, ovvero nomi host, porte, parametri di connessione e argomenti del connettore nella M rimangono esattamente come creati. Questo comportamento si applica sia alle connessioni appena create sia a quelle esistenti: qualsiasi connessione che non fissa esplicitamente Implementation in M segue l'impostazione predefinita dell'area di lavoro/del tenant nel momento in cui questa cambia.

Le connessioni che fissano il driver su M hanno la precedenza rispetto all'impostazione predefinita dello spazio di lavoro/del tenant. Una connessione con Implementation="1.0" rimane in ODBC e Implementation="2.0" rimane in ADBC, indipendentemente dall'impostazione dell'area di lavoro o del tenant. Per modificare uno di questi, modificare la M.

Per il comportamento specifico del connettore (incluse eventuali differenze tra porte o opzioni tra i driver ODBC e ADBC), vedere la documentazione specifica del connettore collegata nella tabella Connettori e modifiche del driver .

Contenuti correlati

• Connettore Databricks
• Connettore di Azure Databricks
• Connettore Google BigQuery
• Connettore Google BigQuery (Microsoft Entra ID)
• Connettore Impala
• Connettore Snowflake
• pq-adbc-advisor accelerator (Microsoft Fabric Toolbox)