Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Diese Seite bietet einen Überblick darüber, was Zerobus Ingest in Lakeflow Connect anbietet. Jede Funktion verlinkt auf die vollständige Dokumentation.
- Immer aktiver Endpunkt: serverlos, standardmäßig aktiviert, skaliert automatisch.
- Authentifizierungsmethoden: wie sich Clients authentifizieren, einschließlich Service Principal OAuth und der Föderation externer Identitätsanbieter.
- Blockierung von Nachrichten: Aufnahmemethoden und wie die Dauerhaftigkeit bestätigt werden kann.
- Bestätigungsrückrufe: Reagieren Sie asynchron auf Bestätigungen und Fehler.
-
Funktionen der Delta-Tabelle: Partitionierung, Flüssigkeitsclustering und
VARIANTDaten. - Rettungsspalte: Erfassen Sie Felder, die nicht ins Tabellenschema passen, anstatt sie abzulehnen.
- Dauerhafter Rückfall-Standort: Wo Daten landen, wenn sie nicht veröffentlicht werden können.
- Überwachung Ihrer Nutzung: Systemtabellen für Nutzung und Ausgaben.
Ständig aktiver Endpunkt
Zerobus Ingest ist ein serverloser Endpunkt, der standardmäßig für Arbeitsbereiche in unterstützten Regionen aktiviert ist. Sie müssen nichts starten, bereitstellen oder skalieren. Nachdem Sie eine Zieltabelle und eine autorisierte Identität haben, können Sie mit der Datenübertragung beginnen, und die Kapazität skaliert automatisch. Um zu starten, siehe Use Zerobus Ingest.
Authentifizierungsmethoden
Jeder Zerobus-Client authentifiziert sich mit einem kurzlebigen Azure Databricks OAuth-Token. Wenn Sie ein SDK verwenden, erhält und aktualisiert es das Token für Sie. Bei den anderen Schnittstellen, wie der REST-API, erhält man das Token selbst und liefert es mit seinen Anfragen. Für Einrichtungsschritte und Code siehe Authentifizierung konfigurieren.
OAuth mit einem Service Principal (Standard)
Authentifizieren Sie sich mit einer Client-ID und einem Secret eines Azure-Databricks-Dienstprinzipals. Dies ist die Standardmethode. Es eignet sich für Workloads, die ein von Azure Databricks verwaltetes Geheimnis enthalten können.
Externe Identitätsanbieter-Föderation
Authentifizieren Sie sich mit einem Token von Ihrem eigenen Identitätsanbieter, wie zum Beispiel mit Microsoft Entra ID, statt mit einem Azure Databricks Secret. Das Identitätsanbieter-Token wird gegen ein Zerobus-Scoped Azure Databricks-Token mit RFC 8693 Token Exchange ausgetauscht, sodass kein langjähriges Azure Databricks-Geheimnis auf dem Client gespeichert wird.
Die Föderation unterstützt zwei Identitätsmodelle:
- Konto-Ebene-Föderation: Es gibt keinen Azure Databricks Service Principal. Ihre Identität vom Identitätsanbieter wird mittels automatischer Identitätsverwaltung in das Azure Databricks-Konto synchronisiert, und Ihr Client authentifiziert sich unter Verwendung dieser Identität. Dies erfordert eine Richtlinie zur Kontoföderation, die Ihren Anbieter als vertrauenswürdige Ausstellerinstanz registriert.
- Workload-Identitätsfederation: Verwenden Sie einen Azure Databricks Service Principal, der eine Client-ID und kein Geheimnis besitzt, mit einer Föderationsrichtlinie angehängt.
Microsoft Entra ID ist das Beispiel auf diesen Seiten, aber derselbe föderierte Flow funktioniert mit anderen OpenID Connect (OIDC)-kompatiblen Identitätsanbietern.
Authentifizierungsmethoden vergleichen
| Methode | Azure Databricks service principal | Azure Databricks client secret | Wann verwenden? |
|---|---|---|---|
| OAuth-Dienstprinzipal | Yes | Yes | Ihr Client kann ein von Azure Databricks verwaltetes Geheimnis halten. |
| Föderation auf Kontoebene | No | No | Ihre Identität wird nur bei Ihrem Anbieter verwaltet, ohne einen Azure Databricks-Dienstprinzipal oder ein Geheimnis. |
| Workload-Identitätsverbund | Ja, ohne Geheimnisse | No | Du möchtest eine Azure Databricks-Dienstprinzipal-Identität, ohne ein Geheimnis zu speichern. |
Hinweis
Automatischer Token-Austausch im SDK ist im Python SDK ab 1.10.0 sowie im Rust SDK ab 2.11.0 verfügbar. Für Einrichtungsschritte und Code siehe Authentifizierung konfigurieren.
Funktionen der Delta-Tabelle
Zerobus Ingest schreibt in standardmäßige, von Unity Catalog verwaltete Delta-Tabellen, sodass Ihre erfassten Daten die Funktionen von Delta-Tabellen nutzen können. Für die Anforderungen, die eine Zieltabelle erfüllen muss, siehe Tabellenanforderungen.
- Partitionierte Tabellen: unterstützt, unterliegen einer Partition-Fan-Out-Begrenzung. Azure Databricks empfiehlt Liquid Clustering für Schlüssel mit hoher Kardinalität. Siehe Partitionierte Tabellen.
- Liquid-Clustertabellen: das empfohlene Layout, das Daten für Abfrageleistung ohne Partitions-Auffächerungsgrenze organisiert. Siehe Verwenden von Flüssigclustering für Tabellen.
-
Variantendaten: halbstrukturierte Daten in
VARIANT-Spalten importieren. Weitere Informationen finden Sie unter Unterstützte Datentypen.
Dauerhafte Rückzugsposition
Wenn ein Breaking Change der Tabelle erfolgt, nachdem Ihre Daten durch Zerobus Ingest dauerhaft gemacht wurden, aber bevor die Daten in der Tabelle veröffentlicht werden können, schreibt Zerobus Ingest diese Daten als Parquet-Dateien in ein Fallback-Verzeichnis innerhalb des Speicherorts Ihrer Tabelle, anstatt sie zu verwerfen. Um diese Daten nach der Behebung des Schemas zu finden und neu zu verarbeiten, siehe Wiederherstellung von Daten vom dauerhaften Rückfallort.
Überwachen der Nutzung
Überwachen Sie Ihren Zerobus Ingest-Verbrauch und Ihre Ausgaben über Systemtabellen. Siehe Referenz zur Zerobus-Ingest-Systemtabelle und für Ausgaben die Systemtabelle für die Abrechnung unter Kosten.