SQL-Connector als Shard

Artikel
10/16/2024

Hinweis

Azure HDInsight on AKS wird am 31. Januar 2025 eingestellt. Vor dem 31. Januar 2025 müssen Sie Ihre Workloads zu Microsoft Fabric oder einem gleichwertigen Azure-Produkt migrieren, um eine abruptes Beendigung Ihrer Workloads zu vermeiden. Die verbleibenden Cluster in Ihrem Abonnement werden beendet und vom Host entfernt.

Bis zum Einstellungsdatum ist nur grundlegende Unterstützung verfügbar.

Wichtig

Diese Funktion steht derzeit als Vorschau zur Verfügung. Die zusätzlichen Nutzungsbedingungen für Microsoft Azure-Vorschauen enthalten weitere rechtliche Bestimmungen, die für Azure-Features in Betaversionen, in Vorschauversionen oder anderen Versionen gelten, die noch nicht allgemein verfügbar gemacht wurden. Informationen zu dieser spezifischen Vorschau finden Sie unter Informationen zur Vorschau von Azure HDInsight on AKS. Bei Fragen oder Funktionsvorschlägen senden Sie eine Anfrage an AskHDInsight mit den entsprechenden Details, und folgen Sie uns für weitere Updates in der Azure HDInsight-Community.

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

Voraussetzungen

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

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

Allgemeine Konfiguration

Der Connector kann mehrere SQL-Server als einzelne Datenquelle abfragen. Erstellen Sie eine Katalogeigenschaftendatei, und verwenden Sie connector.name=sharded-sql, um SQL-Connector als Shard 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>

Eigenschaft	Beschreibung
connector.name	Name des Connectors für SQL als Shard, der `sharded_sqlserver` lauten sollte.
connection-user	Benutzername in SQL Server
connection-password	Das Kennwort für den Benutzer in SQL-Server
sharded-cluster	Muss für SQL-Connector als Shard auf `TRUE` festgelegt werden.
shard-config-location	Speicherort des Konfigurationsdefinitionsschemas

Authentifizierung der Datenquelle

Der Connector verwendet die Benutzerkennwortauthentifizierung zum Abfragen von SQL-Servern. Es wird erwartet, dass sich der in der Konfiguration angegebene Benutzer 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 die dateibasierte Shardingschemadefinition unterstützt.

Sie können den Speicherort der JSON-Datei des Shardingschemas in den Katalogeigenschaften als shard-config-location=etc/shard-schema.json angeben. Konfigurieren Sie die JSON-Datei des Shardingschemas mit den gewünschten Eigenschaften, um das Layout anzugeben.

Die folgende JSON-Datei beschreibt die Konfiguration für einen Trino-SQL-Connector als Trino-Shard. Im Folgenden ist die Struktur aufgeschlüsselt:

tables: Ein Array von Objekten, die jeweils eine Tabelle in der Datenbank darstellen. Jedes Objekt enthält Folgendes:
- 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 das in den nächsten Schritten beschriebene sharding_schema fungiert.
sharding_schema: Ein Array von Objekten, die jeweils ein Shardingschema darstellen. Jedes Shardingschemaobjekt enthält:
- name: Der Name des Shardingschemas.
- partitioned_by: Ein Array, das mindestens eine Spalte enthält, nach der das Shardingschema partitioniert wird.
- bucket_count(optional): Eine ganze Zahl, die die Gesamtanzahl der Buckets darstellt, über die die Tabelle verteilt ist, standardmäßig festgelegt auf 1.
- bucketed_by(optional): Ein Array mit einer oder mehreren Spalten, nach denen ein Bucket für die Daten verwendet wird. Beachten Sie, dass Partitionierung und Bucketing hierarchisch sind, was bedeutet, dass jede Partition in einem Bucket erstellt wird.
- partition_map: Ein Array von Objekten, die jeweils eine Partition innerhalb des Shardingschemas darstellen. Jedes Partitionsobjekt enthält Folgendes:
  - partition: Der in Form von partition-key=partitionvalue angegebene Partitionswert
  - shards: Ein Array von Objekten, die jeweils eine Shard innerhalb der Partition darstellen. Jedes Element des Arrays stellt ein Replikat dar, Trino fragt eine beliebige davon zufällig ab, um Daten für eine Partition/für Buckets abzurufen. Jede Shard enthält Folgendes:
    - connectionUrl: Die URL der JDBC-Verbindungs-URL zur Datenbank der Shard.

Wenn beispielsweise zwei Tabellen lineitem und part mit diesem Connector abfragen möchten, können Sie diese wie folgt angeben.

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

Hinweis

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

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

	"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 Tabellenzeilenelement partitioniert durch shipmode.
Jede Partition verfügt über 10 Buckets.
Jede Partition ist bucketed_by partkey-Spalte.
Buckets 1-7 für Partitionswert AIR befindet sich in der test1-Datenbank.
Buckets 8-10 für Partitionswert AIR befindet 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 Bucketbereinigung

Der Connector wertet die Abfrageeinschränkungen während der Planung aus, und die Ausführung erfolgt basierend auf den bereitgestellten Abfrageprädikaten. Dadurch wird die Abfrageleistung beschleunigt und der Connector kann große Datenmengen abzufragen.

Die Bucketing-Formel zur Bestimmung von Zuordnungen unter Verwendung der Implementierung der Murmur-Hash-Funktion wird hier beschrieben.

Typzuordnung

SQL-Connector als Shard unterstützt die gleichen Typzuordnungen wie Typzuordnungen für SQL Server-Connector.

Weitergabe

Die folgenden Weitergabeoptimierungen werden unterstützt:

Begrenzung der Weitergabe
Verteilungsaggregate
Pushdown von JOIN

Die JOIN-Operation kann nur dann an den Server weitergegeben werden, wenn der Connector bestimmt, dass die Daten für die Build- und Prüfpunkttabelle zugeordnet sind. Der Connector bestimmt, wann die Daten zugeordnet sind werden – das sharding_schema für die Tabellen left und right ist identisch. – Verknüpfungsbedingungen sind eine Obermenge von Partitionierungs- und Bucketingschlüsseln.

Um JOIN Weitergabeoptimierung zu verwenden, sollte die Katalogeigenschaft join-pushdown.strategy auf EAGER festgelegt sein.

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

Freigeben über