Übergang von ODBC zu ADBC-Treibern in Power BI und Fabric

Power BI und Microsoft Fabric stellen unterstützte Datenquellenverbindungen von veralteten eingebetteten ODBC-Treibern auf Apache Arrow Database Connectivity (ADBC)-Treiber um. ADBC bietet eine Reihe von Standardschnittstellen für die Interaktion mit Pfeildaten, die besonders effizient beim Abrufen großer Datasets mit minimalem Aufwand und ohne Serialisierung oder Kopieren ist. Die ADBC-Treiber enthalten auch Sicherheitsverbesserungen, z. B. Speichersicherheit und Garbage Collection.

Sie können ADBC heute pro Verbindung verwenden, und Administratoren können das Standardverhalten mandantenweit über eine Mandanteneinstellung steuern, die Arbeitsbereichsadministratoren für Tests und zur Validierung außer Kraft setzen können.

Verbinder und Treiberänderungen

In der folgenden Tabelle sind die Connectors aufgeführt, die von eingebetteten ODBC-Treibern zu Ersatztreibern wechseln. In den meisten Fällen ist der Ersatztreiber ein ADBC-Treiber.

Wer betroffen ist

Sie sind betroffen, wenn Sie einen der auf ADBC umgestellten Konnektoren verwenden (z. B. Databricks, Snowflake oder Google BigQuery) und:

• Sie haben keine Implementierung in der Verbindung explizit ausgewählt (der Implementation Parameter ist nicht angegeben) oder
• Ihre Organisation möchte zentral steuern, ob ADBC oder ODBC die Standardeinstellung für unterstützte Connectors ist.

Diese Standardeinstellung gilt unabhängig davon, wo Sie eine Verbindung erstellen, einschließlich semantischer Modelle, Dataflows Gen2 und paginierten Berichten.

Wie man migriert

Sie können auf drei Arten migrieren, sortiert nach der gewünschten Steuerung:

• Opt-In pro Verbindung: Fügen Sie Implementation="2.0" einzelne Verbindungen hinzu, um ADBC in Ihrem eigenen Tempo zu überprüfen.
• Mandanteneinstellung: Legen Sie die organisationsweite Standardeinstellung über das Verwaltungsportal fest.
• Überschreibung auf Arbeitsbereichsebene: Überschreiben Sie den mandantenweiten Standard auf Arbeitsbereichsebene für die Validierung nebeneinander.

Opt-in pro Verbindung

Sie können ADBC aktivieren, indem Sie Implementation="2.0" zu unterstützten Verbindungen hinzufügen. Mit diesem Ansatz können Sie ADBC in Ihrem eigenen Tempo für einzelne Verbindungen überprüfen.

Ausführliche Anweisungen zur Aktivierung pro Verbindung für einen bestimmten Konnektor finden Sie in der konnektorspezifischen Dokumentation, die in der Tabelle Konnektoren und Treiberänderungen verlinkt ist.

Mandanteneinstellung

Mandantenadministratoren können die Standardeinstellung der Organisation mithilfe der Einstellung des Verwaltungsportals festlegen:

Benutzer können mithilfe der Apache Arrow-Datenbankkonnektivität (ADBC) eine Verbindung mit Datenquellen herstellen.

• Deaktiviert (Standard): Wählt die älteren ODBC-Treiber als Standardoption aus.
• Aktiviert: Wählt die neuen ADBC-Treiber als Standardoption aus.

Diese Einstellung steuert auch das Testverbindungsverhalten für jeden Verbindungstyp innerhalb des Mandanten.

Außerkraftsetzung des Arbeitsbereichs

Die Mandanteneinstellung wird an Arbeitsbereiche weitergegeben, sodass Arbeitsbereichsadministratoren die Standardeinstellung überschreiben und Verhaltensweisen vergleichen können, ohne jede einzelne Verbindung einzeln ändern zu müssen. Dieser Ansatz ermöglicht die parallele Überprüfung. Sie können beispielsweise einen Arbeitsbereich verwenden, um ADBC-Standardwerte zu testen und gleichzeitig einen anderen Arbeitsbereich auf ODBC-Standardwerten beizubehalten.

Wie die Implementierung ausgewählt wird

Wenn Sie den Implementation Parameter in der Verbindung explizit angeben, hat dieser Wert immer Vorrang vor den Standardeinstellungen des Mandanten oder Arbeitsbereichs.

Die folgende Tabelle zeigt, wie der Treiber ausgewählt wird:

Lokales Datengatewayverhalten

Die ADBC-Einstellungen für Mandanten und Arbeitsbereich gelten für Aktualisierungspfade, die im Clouddienst ausgeführt werden. Abfragen, die über ein lokales Datengateway weitergeleitet werden, verwenden weiterhin den Treiber, der mit der Gatewayinstallation gebündelt ist, was heute ODBC für die in diesem Artikel aufgeführten Connectors ist. Aktualisierungen, die über ein Gateway geleitet werden, werden nicht auf ADBC umgestellt, wenn die Einstellung für den Mandanten oder den Arbeitsbereich aktiviert ist; dies ist das erwartete Verhalten.

Bei der Planung der Migration sind zwei Konsequenzen zu beachten:

• Wenn Sie ein Gateway verwenden, um den Übergang zu ADBC zu testen, spiegelt die Aktualisierung über das Gateway nicht den ADBC-Pfad wider. Testen Sie ADBC mithilfe einer Cloudverbindung , um das ADBC-Verhalten vollständig zu überprüfen.
• Kunden, die auf ODBC verbleiben müssen (z. B. um einen Pfad für private Verbindungen über das Gateway beizubehalten), können die Änderung zurückstellen, indem Sie die Aktualisierungen über das lokale Gateway fortsetzen, wobei die ODBC-Treiber installiert sind. Dies ist eine Verzögerung, keine dauerhafte Abmeldung: Sobald ODBC-Treiber aus zukünftigen Gatewayinstallationen entfernt werden (siehe Wichtige Daten), werden Gateways, die an frühere Versionen angeheftet sind, schließlich nicht mehr unterstützt. Planen Sie Gatewayupgrades und ADBC-Validierung entsprechend.

Empfohlene Migrationsprüfliste

1. Prüfen Sie Ihren Arbeitsbereich mit pq-adbc-advisor, um alle Verbindungen zu erfassen, die den Legacytreiber verwenden, und für jedes Element eine Risikoeinstufung anzuzeigen. Siehe "Überwachen Ihres Arbeitsbereichs mit pq-adbc-advisor".
2. Wählen Sie einen Pilotarbeitsbereich aus, und aktivieren Sie ADBC zuerst mithilfe der Arbeitsbereichüberschreibung, um wichtige Datasets zu überprüfen und Szenarien zu aktualisieren. Um den ADBC-Pfad durchgängig zu überprüfen, testen Sie mit einer Cloudverbindung – unter Verhalten des lokalen Datengateways erfahren Sie, warum über das Gateway geleitete Aktualisierungen weiter ODBC verwenden.
3. Überprüfen Sie in Power BI Desktop. Installieren Sie die aktuelle Power BI Desktop-Version, die den ADBC-Treiber für jeden In-Scope-Connector enthält, der seine Standard-Flip übergeben hat. Es gibt keine Umschaltfläche pro Datei, um ADBC für eine vorhandene Abfrage zu erzwingen – um eine vorhandene Abfrage an ADBC weiterzuleiten, die Abfrage zu löschen, die Quelle erneut hinzuzufügen und die Felder erneut auszuwählen. Aktualisieren und vergleichen Sie die Anzahl der Zeilen, die Spaltentypen und die Dauer der Aktualisierung mit Ihrem ODBC-Basiswert.
4. Für alle kritischen Verbindungen, die Sie sofort überprüfen möchten, melden Sie sich für jede einzelne Verbindung über Implementation="2.0" an.
5. Nachdem die Überprüfung abgeschlossen ist, entscheiden Sie, ob ADBC standardmäßig auf Mandantenebene aktiviert werden soll.

Überprüfen Sie Ihren Arbeitsbereich mit pq-adbc-advisor

Bevor Sie migrieren, müssen Sie wissen, was geändert werden soll. pq-adbc-advisor ist ein schreibgeschütztes Fabric-Notebook, das einen Arbeitsbereich scannt und einen Auswirkungsbericht pro Element zurückgibt, der zeigt, welche semantischen Modelle, Datenflüsse und Datenpipelines noch den Legacy-ODBC-Treiber verwenden und was bei jedem davon zu tun ist.

Was ihnen der Auswirkungsbericht gibt

Der Auswirkungsbericht gibt Ihnen Folgendes:

• Eine Übersicht aller Connector-Aufrufe im Arbeitsbereich für alle Connectoren, die auf ADBC umgestellt werden.

• Eine Risikoklassifizierung für das Umstellungsrisiko jedes Elements:

  Risiko	Was das Risiko bedeutet	Was zu tun ist
  Schlägt fehl	Die M-Abfrage-Pins Implementation="1.0" und das Element verfügt über keine Gatewaybindung. Bei der Umschaltung funktioniert diese Aktualisierung nicht mehr.	Entfernen Sie [Implementation="1.0"] aus dem Quellschritt, oder binden Sie das Element vor der Umstellung an ein Gateway.
  Überprüfung erforderlich	Entweder ist die M-Abfrage an ODBC gebunden, aber ein Gateway ist zugeordnet (die Umstellung wird zwar überstanden, sollte aber trotzdem noch umgestellt werden), oder M erstellt eine rohe DSN-Zeichenfolge, die ADBC nicht unverändert übernimmt.	Testen Sie den ADBC-Pfad an einer Kopie des Elements und rollen Sie es dann aus. Für Fälle mit DSN-Zeichenfolgen, die der Standardkonnektor nicht abdeckt, eskalieren Sie an das im Accelerator aufgeführte Eskalationspostfach.
  Ready	Die M-Abfrage heftet ADBC (Implementation="2.0") bereits an oder wird gelöst, und der Mandantenwechsel behandelt ihn sauber.	Keine Aktion. Scannen Sie nach der Umschaltung zur Bestätigung erneut.

• Abdeckung für Datenpipelinen und Dataflow Gen2, nicht nur semantische Modelle.

• Auflösungsnachverfolgung über Scans hinweg – jeder Scan führt sowohl einen Basisplan für die erste Ausführung als auch einen Leistungsindikator für die aktuelle Ausführung, sodass eine erneute Überprüfung Ihnen sagt, was seit dem ersten Durchlauf bereinigt wurde.

Was der Auswirkungsbericht nicht tut

Der Auswirkungsbericht enthält Folgendes nicht:

• Schreiben Sie alle M-Ausdrücke neu.
• Löst Aktualisierungen selbstständig aus (für die Validierung wird eine separate Opt-in-Option bereitgestellt).
• Senden von M-Code, Elementnamen, Endpunkt-URLs, Anmeldeinformationen oder Aktualisieren von Fehlermeldungstexten außerhalb des Arbeitsbereichs.

Jeder Scan sendet anonyme Zählungen an das Power Query Team, damit sie die Akzeptanz messen und die Connectorabdeckung priorisieren können. Der Scan sendet nur SHA-256-Hash-Mandanten- und Benutzer-IDs, wobei standardmäßig keine Rohwerte vorhanden sind. Um sich jederzeit abzumelden, deaktivieren Sie die Telemetrie wie im Accelerator dokumentiert. Die Abmeldung bleibt über Kernelneustarts hinweg erhalten.

So führen Sie den Auswirkungsbericht aus

Die einfachste Möglichkeit, das Tool zu verwenden, ist das Startnotizbuch in der Microsoft Fabric Toolbox.

1. Laden Sie das Startnotizbuch herunter, und importieren Sie es in einen Fabric Arbeitsbereich.
2. Fügen Sie das Notizbuch an den Arbeitsbereich an, den Sie inventarisieren möchten.
3. Führen Sie das Notebook von oben nach unten aus. Es installiert pq-adbc-advisor in die Sitzung, scannt den Arbeitsbereich, zeigt den Auswirkungsbericht inline an und speichert eine HTML-Kopie des Berichts im Standard-Lakehouse, wenn Sie eines anfügen.
4. Nehmen Sie Ihre Korrekturen vor.
5. Führen Sie das Notebook erneut aus. Der Bericht zeigt die Auflösungsdelta an – wie viele Pins Sie seit dem ersten Scan bereinigt haben.

Wenn Sie über Administratorberechtigungen verfügen und alle Arbeitsbereiche im Mandanten scannen möchten, beschreibt der Accelerator eine mandantenweite Scanoption, die die Fabric-Administrator-Scanner-API verwendet. Mandantenscans dauern typischerweise 15 bis 30 Minuten bei einem mittelgroßen Mandanten.

Informationen zu Fehlern, Feature-Anfragen und Lücken bei der Connector-Abdeckung finden Sie im Accelerator-Repository.

Wichtige Datumsangaben

• Juli 2026 (geplant): Die breite Einführung der Mandanteneinstellung beginnt. Das Arbeitsbereichsverhalten erbt diese Einstellung und kann von Arbeitsbereichsadministratoren außer Kraft gesetzt werden, sofern diese unterstützt werden.
• Oktober 2026 (geplant): Microsoft plant, vorbehaltlich der Rolloutbereitschaft schrittweise damit zu beginnen, die Mandanteneinstellung standardmäßig zu aktivieren.
• Anfang 1. Quartal 2027 (geplant): Microsoft pläne, ODBC-Treiber aus dem Dienst zu entfernen, vorbehaltlich der Rolloutbereitschaft. Wenn Sie bei ODBC bleiben müssen (Implementation="1.0" oder die Arbeitsbereichseinstellung Aus), müssen Sie ein Gateway verwenden, um weiterhin Abfragen mit ODBC auszuführen.
• Frühjahr 2027 (geplant): Die in diesem Artikel referenzierten ODBC-Treiber sollen nicht mehr mit Power BI Desktop oder dem Gateway ausgeliefert werden.

Vor den Durchsetzungsmeilensteinen plant Microsoft, im Voraus zu informieren, damit die Kunden Migrations- und Validierungsaktivitäten abschließen können.

Häufig gestellte Fragen

Kann ich ADBC jetzt testen?

Yes. Installieren Sie die aktuelle Version von Power BI Desktop, und fügen Sie eine betroffene Datenquelle erneut hinzu – neue Abfragen werden sofort an ADBC geleitet. Verwenden Sie für dienstseitige Tests den Override für den Arbeitsbereich, um ADBC in einem Pilotarbeitsbereich zu aktivieren und mithilfe einer Cloudverbindung zu validieren.

Wie finde ich jeden Ort, an dem ich noch den älteren ODBC-Treiber verwende?

Führen Sie pq-adbc-advisor in Ihrem Arbeitsbereich aus. Es ist ein schreibgeschütztes Fabric-Notebook, das jedes semantische Modell, jeden Datenfluss und jede Datenpipeline erfasst, die weiterhin den Legacy-Treiber verwenden. Sie ordnet jede davon nach Umstellungsrisiko ein und zeigt, was geändert werden muss. Behandeln Sie sie als Ihre Ausgangsdiagnose, keine endgültige Prüfung. Siehe "Überwachen Ihres Arbeitsbereichs mit pq-adbc-advisor". Administratoren können über die Fabric-Administrator-Scanner-API eine mandantenweite Überprüfung durchführen. Einzelheiten finden Sie in der Dokumentation zum Beschleuniger.

Bin ich betroffen, wenn ich bereits das lokale Datengateway verwende?

Die ADBC-Einstellungen für Mandanten und Arbeitsbereiche gelten nur für Ausführungen im Dienst. Sie wirken sich nicht auf Aktualisierungen aus, die über ein lokales Datengateway weitergeleitet werden. Über ein Gateway weitergeleitete Aktualisierungen verwenden für die Konnektoren in diesem Artikel bis zur Umstellung weiterhin ODBC. Siehe Verhalten des lokalen Datengateways. ODBC-Treiber sollen aus künftigen Gateway-Installationen entfernt werden – behalten Sie wichtige Termine im Blick.

Wie kann ich den ADBC-Übergang deaktivieren?

Sie können sich nicht dauerhaft dagegen entscheiden. Mit der Mandanteneinstellung können Sie die standardmäßige Umstellung während des Validierungsfensters verschieben, aber sobald ODBC im Service deaktiviert wird, gilt die Änderung für alle. Um ODBC nach dem dienstseitigen Übernahmevorgang weiterhin zu verwenden, müssen Sie Aktualisierungen über ein lokales Datengateway mit installierten ODBC-Treibern weiterleiten. Diese Änderung ist nur eine Verzögerung – ODBC-Treiber sollen aus zukünftigen Gatewayinstallationen entfernt werden.

Warum ändert die ADBC-Einstellung des Arbeitsbereichs meine Power BI Desktopdatei nicht?

Für ADBC gibt es in Power BI Desktop keine Umschaltfläche pro Datei. Vorhandene Abfragen in einer Desktopdatei bleiben dem Treiber zugeordnet, mit dem sie erstellt wurden, bis die Abfrage neu erstellt wird. Um ADBC für eine vorhandene Abfrage zu überprüfen, löschen Sie die Abfrage, fügen Sie die Quelle erneut hinzu, und wählen Sie die Felder erneut aus. Neue Abfragen in der aktuellen Desktopversion werden für Konnektoren, für die die Standardumstellung erfolgt ist, automatisch über ADBC geleitet.

Schreibt die ADBC-Einstellung des Arbeitsbereichs meine vorhandenen M-Abfragen neu?

No. Die Mandanten- und Arbeitsbereichseinstellungen bestimmen, welcher Treiber bei der Abfrageausführung ausgewählt wird, aber sie ändern den M-Ausdruck selbst nicht – Hostnamen, Ports, Verbindungsparameter und Konnektorargumente in Ihrem M bleiben genau so, wie sie verfasst wurden. Dieses Verhalten gilt sowohl für neu erstellte als auch für vorhandene Verbindungen: jede Verbindung, die Implementation in M nicht explizit anheftet, folgt der Standardvorgabe des Arbeitsbereichs/Mandanten, sobald die Umstellung erfolgt.

Verbindungen, die den Treiber in M anheften, haben Vorrang vor dem Standard "Arbeitsbereich/Mandant". Eine Verbindung mit Implementation="1.0" bleibt bei ODBC und Implementation="2.0" bleibt unabhängig von der Arbeitsbereichs- oder Mandanteneinstellung auf ADBC. Bearbeiten Sie zum Ändern eines dieser Elemente das M.

Informationen zum connectorspezifischen Verhalten (einschließlich aller Port- oder Optionsunterschiede zwischen den ODBC- und ADBC-Treibern) finden Sie in der connectorspezifischen Dokumentation, die in der Tabelle "Connectors" und "Treiberänderungen " verknüpft ist.

Verwandte Inhalte

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