Aufgeteilter SQL-Connector

Artikel
09/20/2024

Wichtig

Azure HDInsight auf AKS wurde am 31. Januar 2025 eingestellt. Erfahren Sie mehr mit dieser Ankündigung.

Sie müssen Ihre Workloads zu Microsoft Fabric oder ein gleichwertiges Azure-Produkt migrieren, um eine abrupte Beendigung Ihrer Workloads zu vermeiden.

Wichtig

Dieses Feature befindet sich derzeit in der Vorschau. Die zusätzlichen Nutzungsbedingungen für Microsoft Azure Previews weitere rechtliche Bestimmungen enthalten, die für Azure-Features gelten, die in der Betaversion, in der Vorschau oder auf andere Weise noch nicht in die allgemeine Verfügbarkeit veröffentlicht werden. Informationen zu dieser spezifischen Vorschau finden Sie unter Azure HDInsight auf AKS-Vorschauinformationen. Für Fragen oder Featurevorschläge senden Sie bitte eine Anfrage an AskHDInsight mit den Details und folgen Sie uns, um weitere Updates zu Azure HDInsight Community.

Der shardierte SQL-Connector ermöglicht die Ausführung von Abfragen über Daten, die über eine beliebige Anzahl von SQL-Servern verteilt werden.

Voraussetzungen

Um eine Verbindung mit Sharded SQL-Servern herzustellen, benötigen Sie Folgendes:

SQL Server 2012 oder höher oder Azure SQL-Datenbank.
Netzwerkzugriff vom Trino-Koordinator und den Mitarbeitern auf SQL Server. Port 1433 ist der Standardport.

Allgemeine Konfiguration

Der Connector kann mehrere SQL-Server als einzelne Datenquelle abfragen. Erstellen Sie eine Katalogeigenschaftendatei; verwenden Sie connector.name=sharded-sql, um den shardierten SQL-Connector zu verwenden.

Konfigurationsbeispiel:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>

Eigentum	Beschreibung
Steckverbinder.name	Name des Connectors für Sharded SQL, der `sharded_sqlserver`.
Verbindungsbenutzer	Benutzername in SQL Server
Verbindungskennwort	Kennwort für den Benutzer in SQL Server
Sharded-Cluster	Muss für Sharded-SQL-Connector auf `TRUE` festgelegt werden.
Shard-Konfigurationsstandort	Standort der Konfiguration, die das Sharding-Schema definiert

Datenquellenauthentifizierung

Der Connector verwendet die Benutzerkennwortauthentifizierung zum Abfragen von SQL-Servern. Derselbe in der Konfiguration angegebene Benutzer wird erwartet, dass er sich für alle SQL-Server authentifiziert.

Schemadefinition

Connector setzt ein 2D-Partitions-/Bucketed-Layout der physischen Daten auf SQL-Servern voraus. Die Schemadefinition beschreibt dieses Layout. Derzeit wird nur dateibasierte Shardingschemadefinition unterstützt.

Sie können den Speicherort der Shardingschema-JSON-Datei in den Katalogeigenschaften wie shard-config-location=etc/shard-schema.jsonangeben. Konfigurieren Sie das Shardingschema-JSON mit den gewünschten Eigenschaften, um das Layout festzulegen.

Die folgende JSON-Datei beschreibt die Konfiguration für einen Trino-Sharded SQL-Connector. Hier ist eine Aufschlüsselung der Struktur:

Tabellen: Ein Array von Objekten, die jeweils eine Tabelle in der Datenbank darstellen. Jedes Tabellenobjekt enthält:
- Schema: Der Schemaname der Tabelle, der der Datenbank im SQL Server entspricht.
- Name: Der Name der Tabelle.
- sharding_schema: Der Name des mit der Tabelle verknüpften Shardingschemas, das als Verweis auf die in den nächsten Schritten beschriebene sharding_schema fungiert.
sharding_schema: Ein Array von Objekten, die jeweils ein Shardingschema darstellen. Jedes Sharding-Schemaobjekt enthält:
- Name: Der Name des Sharding-Schemas.
- partitioned_by: Ein Array, das eine oder mehrere Spalten enthält, nach denen das Sharding-Schema partitioniert ist.
- bucket_count(optional): Eine ganze Zahl, die die Gesamtanzahl der Buckets darstellt, auf die die Tabelle verteilt ist und die standardmäßig auf 1 gesetzt ist.
- bucketed_by(optional): Ein Array mit einer oder mehreren Spalten, nach denen die Daten zusammengefasst werden, beachten Sie, dass die Partitionierung und Bucketing hierarchisch sind, was bedeutet, dass jede Partition zusammengefasst wird.
- partition_map: Ein Array von Objekten, die jeweils eine Partition innerhalb des Shardingschemas darstellen. Jedes Partitionsobjekt enthält:
  - Partition: Der im Formular angegebene Partitionswert partition-key=partitionvalue
  - Shards: Ein Array von Objekten, das jeweils einen Shard innerhalb der Partition darstellt. Jedes Element des Arrays repräsentiert ein Replikat. Trino wählt zufällig eines davon aus, um Daten für eine Partition oder einen Bucket abzurufen. Jedes Shard-Objekt enthält:
    - connectionUrl-: Die JDBC-Verbindungs-URL zur Datenbank-Partition.

Wenn Sie die beiden Tabellen lineitem und part mit diesem Connector abfragen möchten, können Sie sie wie folgt angeben.

	"tables": [
		{
			"schema": "dbo",
			"name": "lineitem",
			"sharding_schema": "schema1"
		},
		{
			"schema": "dbo",
			"name": "part",
			"sharding_schema": "schema2"
		}
    ]

Anmerkung

Der Connector erwartet, dass alle Tabellen im SQL-Server vorhanden sind, die im Schema für eine Tabelle definiert sind; ist dies nicht der Fall, schlagen Abfragen für diese Tabelle fehl.

Im vorherigen Beispiel können Sie das Layout der Tabelle lineitem wie folgt angeben:

	"sharding_schema": [
		{
			"name": "schema1",
			"partitioned_by": [
				"shipmode"
			],
          		  "bucketed_by": [
              		  "partkey"
           		],
			"bucket_count": 10,
			"partition_map": [
				{
					"partition": "shipmode='AIR'",
                    			"buckets": 1-7,
					"shards": [
						{
							"connectionUrl": "jdbc:sqlserver://sampleserver.database.windows.net:1433;database=test1"
						}
					]
				},
				{
					"partition": "shipmode='AIR'",
                   			"buckets": 8-10,
					"shards": [
						{
							"connectionUrl": "jdbc:sqlserver://sampleserver.database.windows.net:1433;database=test2"
						}
					]
				}                
			]
        }
    ]

In diesem Beispiel wird folgendes beschrieben:

Die Daten für den Tabellenzeilenposten, aufgeteilt durch shipmode.
Jede Partition verfügt über 10 Buckets.
Jede Partition wird nach der partkey-Spalte gruppiert.
Buckets 1-7 für den Partitionswert AIR befindet sich in der test1 Datenbank.
Buckets 8-10 für den Partitionswert AIR befinden sich in der test2-Datenbank.
Shards sind ein Array von connectionUrl. Jedes Element des Arrays stellt ein replicaSet dar. Während der Abfrageausführung wählt Trino eine zufällige Shard aus dem Array aus, um Daten abzufragen.

Partitions- und Bucket-Pruning

Der Connector wertet die Abfrageeinschränkungen während der Planung aus und führt die Ausführung basierend auf den bereitgestellten Abfragebedingungen durch. Dadurch wird die Abfrageleistung beschleunigt und der Connector in die Lage versetzt, große Datenmengen abzufragen.

Bucketing-Formel zur Bestimmung von Zuordnungen unter Verwendung der Murmur-Hash-Funktion, die in hierbeschrieben ist.

Typzuordnung

Der Sharded SQL-Connector unterstützt die gleichen Typzuordnungen wie SQL Server Connector Typzuordnungen.

Pushdown

Die folgenden Pushdownoptimierungen werden unterstützt:

Pushdown einschränken
Verteilungsaggregate
Pushdown beitreten

JOIN Vorgang kann nur dann auf den Server gedrückt werden, wenn der Connector bestimmt, dass die Daten für die Build- und Probetabelle zugeordnet werden. Connector bestimmt, wann die Daten kolociert werden – die sharding_schema für left und die right Tabelle ist identisch. – Verknüpfungsbedingungen sind eine Obermenge von Partitionierungs- und Bucketingschlüsseln.

Um die JOIN-Pushdownoptimierung zu verwenden, sollte die Katalogeigenschaft join-pushdown.strategy auf EAGER gesetzt werden.

AGGREGATE Pushdown für diesen Connector kann nur für distributive Aggregationen durchgeführt werden. Die Optimiererkonfiguration optimizer.partial-aggregate-pushdown-enabled muss auf true festgelegt werden, um diese Optimierung zu aktivieren.

Freigeben über