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.

Note

I controlli del tenant e dell'area di lavoro descritti in questo articolo vengono abilitati in fasi e potrebbero non essere ancora disponibili in tutti i tenant. Questa transizione si applica solo ai connettori elencati in questo articolo e non modifica il comportamento per il connettore ODBC quando si usa un driver ODBC installato separatamente. La modifica in questo articolo è la transizione dai driver incorporati forniti con Power BI.

È 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.

Connettore Driver attuale Driver sostitutivo
Databricks Simba Spark ODBC Databricks ADBC
Azure Databricks Simba Spark ODBC Databricks ADBC
Dremio Simba Drill ODBC FlightSQL ADBC
Google BigQuery e Google BigQuery (Microsoft Entra ID) Simba Google BigQuery ODBC BigQuery ADBC
Hive Simba Hive ODBC Deprecato
Impala Simba Impala ODBC HiveServer2 ADBC
Snowflake Simba Snowflake ODBC Snowflake ADBC
Spark Simba Spark ODBC HiveServer2 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:

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:

Condition Driver utilizzato
Implementation="2.0" ADBC
Implementation non specificato e l'impostazione dell'area di lavoro è Attivata ADBC
Implementation="1.0" ODBC
Implementation non specificato e l'impostazione dell'area di lavoro è Disattivata ODBC

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.
  1. 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.
  2. 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.
  3. Per qualsiasi connessione critica che si desidera convalidare immediatamente, attivare l'opzione per ogni singola connessione con Implementation="2.0".
  4. Al termine della convalida, decidere se abilitare ADBC per impostazione predefinita a livello di tenant.

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.
  • Agosto 2026 (pianificato): Microsoft prevede di iniziare ad abilitare gradualmente per impostazione predefinita l'impostazione del tenant, in base alla preparazione per la distribuzione.
  • Late Q3 to early Q4 2026 (planned): 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.

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

  • Last updated on