Freigeben über

Einschränkungen des SQL Server-Connectors

Auf dieser Seite werden Einschränkungen und Überlegungen für die Aufnahme von SQL Server mithilfe von Databricks Lakeflow Connect aufgeführt.

Allgemeine Einschränkungen des Datenbankkonnektors

Die Einschränkungen in diesem Abschnitt gelten für alle Datenbankkonnektoren in Lakeflow Connect. Lesen Sie weiter, um verbindungsspezifische Einschränkungen zu erfahren.

  • Wenn Sie eine geplante Pipeline ausführen, werden Warnungen nicht sofort ausgelöst. Stattdessen werden sie ausgelöst, wenn das nächste Update ausgeführt wird.
  • Wenn eine Quelltabelle gelöscht wird, wird die Zieltabelle nicht automatisch gelöscht. Sie müssen die Zieltabelle manuell löschen. Dieses Verhalten entspricht nicht dem Verhalten von Lakeflow Spark Declarative Pipelines.
  • Während der Quellwartungszeiträume können Databricks möglicherweise nicht auf Ihre Daten zugreifen.
  • Wenn ein Quelltabellenname mit einem vorhandenen Zieltabellennamen in Konflikt steht, schlägt die Pipelineaktualisierung fehl.
  • Die Unterstützung für Multi-Destination-Pipelines erfolgt ausschließlich über die API.
  • Sie können nach Belieben eine Tabelle umbenennen, die Sie importieren. Wenn Sie eine Tabelle in Ihrer Pipeline umbenennen, wird sie zu einer nur API-Pipeline, und Sie können die Pipeline nicht mehr in der Benutzeroberfläche bearbeiten.
  • Wenn Sie eine Spalte auswählen, nachdem eine Pipeline bereits gestartet wurde, füllt der Verbinder die Daten für die neue Spalte nicht automatisch aus. Um historische Daten zu erfassen, führen Sie manuell eine vollständige Aktualisierung der Tabelle aus.
  • Databricks können nicht zwei oder mehr Tabellen mit demselben Namen in derselben Pipeline aufnehmen, auch wenn sie aus verschiedenen Quellschemas stammen.
  • Das Quellsystem geht davon aus, dass die Cursorspalten monoton steigen.
  • Managed Ingestion Pipelines werden für Arbeitsbereiche in Azure GovCloud Regionen nicht unterstützt.
  • Wenn SCD Typ 1 aktiviert ist, erzeugen Löschvorgänge kein explizites delete Ereignis im Änderungsdatenfeed. Verwenden Sie für überprüfbare Löschungen SCD-Typ 2, wenn der Connector ihn unterstützt. Ausführliche Informationen finden Sie unter Beispiel: SCD-Typ 1- und SCD-Typ 2-Verarbeitung mit CDF-Quelldaten.
  • Der Connector erfasst rohe Daten ohne Transformationen. Verwenden Sie die Downstream-Pipelines von Lakeflow Spark Declarative Pipelines für Transformationen.
  • Die Unterstützung ist auf primäre SQL Server-Instanzen beschränkt. Dies liegt daran, dass die Änderungsverfolgung und die Erfassung von Änderungsdaten auf Lesereplikaten oder sekundären Instanzen nicht unterstützt werden.

Authentifizierung

  • Der Connector unterstützt die grundlegende Authentifizierung (Benutzername und Kennwort). Für Azure SQL-Datenbank und azure SQL Managed Instance unterstützt der Connector auch die Microsoft Entra ID-Authentifizierung.
  • Konfigurationen von Failoverclustern mit mehreren Subnetzen müssen eine einzige vorwärts gerichtete IP-Adresse bereitstellen.

Datenbankvarianten

  • Der Connector unterstützt Azure SQL-Datenbank, azure SQL Managed Instance und Amazon RDS SQL-Datenbanken. Dazu gehört SQL Server, der auf virtuellen Azure-Computern (VMs) und Amazon EC2 ausgeführt wird. Der Connector unterstützt auch sql Server lokal mit Azure ExpressRoute und AWS Direct Connect-Netzwerk.

  • So verwenden Sie die Microsoft-Änderungsdatenerfassung (CDC):

    • Sie benötigen SQL Server 2012 Service Pack 1 (SP1) kumulatives Updatepaket 3 (CU3) oder höher.

      Mit diesem Update wurde die __$command_id Spalte eingeführt. Ohne diese Spalte kann das Gateway für die Datenerfassung nicht zuverlässig zwischen den Typen von Datenänderungsoperationen unterscheiden (z.B. UPDATE Operationen, die sich als DELETE-INSERT Paare mit identischen __$seqval Werten manifestieren). Dies kann zu Dateninkonsistenzen führen.

    • Für Versionen vor SQL Server 2016 ist enterprise Edition ebenfalls erforderlich.

  • Zur Verwendung der Microsoft-Änderungsnachverfolgung müssen Sie SQL Server 2012 oder höher haben.

Rohrleitungen

  • Jede Aufnahmepipeline muss genau einem Aufnahmegateway zugeordnet sein.
  • Obwohl die Pipeline zum Einbinden von Daten auf Serverless-Compute ausgeführt wird, muss das Gateway zum Einbinden von Daten auf klassischem Compute ausgeführt werden.

Schemaentwicklung

Der Konnektor handhabt neue und gelöschte Spalten automatisch, es sei denn, Sie haben sich dagegen entschieden.

  • Wenn eine neue Spalte in der Quelle erscheint, bindet Databricks sie beim nächsten Ausführen der Pipeline automatisch ein. Sie können dies jedoch deaktivieren.
  • Wenn eine Spalte aus der Quelle gelöscht wird, löscht Databricks sie nicht automatisch. Stattdessen verwendet der Verbinder eine Tabelleneigenschaft, um die gelöschte Spalte im Ziel auf inactive zu setzen. Wenn später eine weitere Spalte mit einem konfliktierenden Namen mit der inactive Spalte angezeigt wird, schlägt die Pipeline fehl. In diesem Fall können Sie eine vollständige Aktualisierung der Tabelle ausführen oder die inaktive Spalte manuell ablegen.

Dies gilt für neu erstellte und gelöschte Tabellen in einem Schema, wenn Sie das gesamte Schema verarbeiten.

Schließlich kann der Verbinder Spaltenumbenennungen verarbeiten, obwohl dies eine vollständige Aktualisierung der Tabelle erfordert.

Zusätzliche Schemaänderungen (z. B. Datentypänderungen) erfordern auch eine vollständige Aktualisierung der Zieltabellen.

Staging

Der Stagingkatalog kann kein fremder Katalog sein.

Tabellen

  • Databricks empfiehlt, maximal 250 Tabellen pro Pipeline zu erfassen. Es gibt jedoch keine Beschränkung für die Anzahl von Zeilen oder Spalten, die in diesen Objekten unterstützt werden.
  • Databricks kann mit einer Pipeline nicht zwei Tabellen einbinden, deren Namen sich nur in der Groß- und Kleinschreibung unterscheiden (z.B. MyTable und MYTABLE). Um solche Fälle zu unterstützen, erstellen Sie zwei Gateway-Ingest-Pipeline-Paare, die in Zielschemas veröffentlichen.
  • Die Namen source_catalog, source_schema und source_table sind groß- und kleinschreibungssensitiv. Wenn beispielsweise der Quelldatenbankkatalog als Marketing in sys.databases angegeben ist, können Sie ihn nicht als marketing in der ingestion_definition angeben.
  • Obwohl Sie aus mehreren Quellkatalogen oder Schemas in einer Pipeline aufnehmen können, können Sie nicht zwei Tabellen mit demselben Namen aufnehmen. Sie können zum Beispiel nicht sowohl schema1.Marketing als auch schema2.Marketing in dieselbe Pipeline einbinden.
  • Mehrere Tabellen- oder Schemaspezifikationen können im objects-Feld des ingestion_definition eingeschlossen werden. Die Quelltabellennamen in verschiedenen Quellschemas können sich jedoch nicht überlappen. Dies führt zu einem Ausfall der Aufnahmepipeline.
  • Last updated on