Udostępnij za pośrednictwem

Konektor Shardowany SQL

  • Artykuł

Ważny

Usługa Azure HDInsight w usłudze AKS została wycofana 31 stycznia 2025 r. Dowiedz się więcej z tego ogłoszenia .

Aby uniknąć nagłego kończenia obciążeń, należy przeprowadzić migrację obciążeń do usługi Microsoft Fabric lub równoważnego produktu platformy Azure.

Ważny

Ta funkcja jest obecnie dostępna w wersji zapoznawczej. Dodatkowe warunki użytkowania platformy Microsoft Azure zawierają więcej warunków prawnych, które dotyczą funkcji platformy Azure w wersji beta, wersji zapoznawczej lub w inny sposób nie są jeszcze ogólnodostępne. Aby uzyskać informacje na temat tej konkretnej wersji zapoznawczej, zobacz szczegóły dotyczące wersji zapoznawczej Azure HDInsight na AKS. W przypadku pytań lub sugestii dotyczących funkcji prześlij żądanie dotyczące AskHDInsight, aby uzyskać więcej informacji na temat społeczności usługi Azure HDInsight.

Łącznik SQL podzielony na fragmenty umożliwia wykonywanie zapytań za pośrednictwem danych rozproszonych na dowolnej liczbie serwerów SQL.

Warunki wstępne

Aby nawiązać połączenie z podzielonymi na fragmenty serwerami SQL, potrzebne są następujące elementy:

  • SQL Server 2012 lub nowszy lub Azure SQL Database.
  • Dostęp sieciowy z koordynatora Trino i pracowników do serwera SQL Server. Port 1433 jest portem domyślnym.

Konfiguracja ogólna

Łącznik może wykonywać zapytania dotyczące wielu serwerów SQL jako pojedynczego źródła danych. Utwórz plik właściwości katalogu i użyj connector.name=sharded-sql, aby użyć łącznika SQL podzielonego na fragmenty.

Przykład konfiguracji:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
Własność Opis
connector.name Nazwa łącznika Dla fragmentowanego kodu SQL, który powinien być sharded_sqlserver
użytkownik połączenia Nazwa użytkownika na serwerze SQL
hasło połączenia Hasło użytkownika w programie SQL Server
klaster podzielony na fragmenty Wymagane ustawienie na wartość TRUE dla łącznika sharded-sql
shard-config-location lokalizacja konfiguracji definiującej schemat fragmentowania

Uwierzytelnianie źródła danych

Łącznik używa uwierzytelniania za pomocą hasła użytkownika do wykonywania zapytań dotyczących serwerów SQL. Ten sam użytkownik określony w konfiguracji ma zostać uwierzytelniony na wszystkich serwerach SQL.

Definicja schematu

Łącznik zakłada dwuwymiarowy układ partycji podzielonych na zasobniki danych fizycznych na serwerach SQL. Definicja schematu opisuje ten układ. Obecnie obsługiwana jest tylko definicja schematu fragmentowania opartego na plikach.

Możesz określić lokalizację pliku json schematu fragmentowania we właściwościach wykazu, takich jak shard-config-location=etc/shard-schema.json. Skonfiguruj kod json schematu fragmentowania z żądanymi właściwościami, aby określić układ.

Poniższy plik JSON opisuje konfigurację łącznika SQL podzielonego na fragmenty Trino. Oto podział jego struktury:

  • tabele: tablica obiektów, z których każda reprezentuje tabelę w bazie danych. Każdy obiekt tabeli zawiera:

    • schemat: nazwa schematu tabeli, która odpowiada bazie danych na serwerze SQL.
    • nazwa: nazwa tabeli.
    • sharding_schema: nazwa schematu fragmentowania skojarzonego z tabelą, która działa jako odwołanie do sharding_schema opisanej w następnych krokach.

  • sharding_schema: tablica obiektów, z których każda reprezentuje schemat fragmentowania. Każdy obiekt schematu fragmentowania zawiera:

    • nazwa: nazwa schematu fragmentowania.
    • partitioned_by: tablica zawierająca co najmniej jedną kolumnę, według której podzielony jest schemat fragmentowania.
    • bucket_count(opcjonalnie): liczba całkowita reprezentująca łączną liczbę zasobników, na które tabela jest podzielona, z domyślną wartością 1.
    • bucketed_by (opcjonalnie): tablica zawierająca co najmniej jedną kolumnę, za pomocą której dane są zasobnikowane, zwróć uwagę, że partycjonowanie i zasobniki są hierarchiczne, co oznacza, że każda partycja jest zasobnikowana.
    • partition_map: tablica obiektów, z których każda reprezentuje partycję w schemacie fragmentowania. Każdy obiekt partycji zawiera:
      • partycja: Wartość partycji określona w formularzu partition-key=partitionvalue
      • fragmentów: tablica obiektów, z których każda reprezentuje fragment w partycji. Każdy element tablicy to replika, a Trino losowo kieruje zapytania do jednej z nich, aby pobrać dane dla partycji/wiaderek. Każdy obiekt fragmentu zawiera:
        • connectionUrl: adres URL połączenia JDBC z bazą danych shardu.

Na przykład, jeśli chcesz wykonać zapytania na dwóch tabelach lineitem i part przy użyciu tego łącznika, możesz je określić w następujący sposób.

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

Notatka

Łącznik oczekuje, że wszystkie tabele będą obecne na serwerze SQL zdefiniowanym w schemacie tabeli, jeśli tak nie jest, zapytania dotyczące tej tabeli nie powiedzą się.

W poprzednim przykładzie można określić układ tabeli lineitem jako:

	"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"
						}
					]
				}                
			]
        }
    ]

W tym przykładzie opisano:

  • Dane elementu tabeli podzielone na partycje według shipmode.
  • Każda partycja ma 10 zasobników.
  • Każda partycja jest podzielona według kolumny partkey.
  • Wiadra 1-7 dla wartości partycji AIR znajdują się w bazie danych test1.
  • Kosze 8-10 dla wartości partycji AIR znajdują się w bazie danych test2.
  • "Części tworzą tablicę connectionUrl." Każdy element tablicy reprezentuje replicaSet. Podczas wykonywania zapytania Trino wybiera fragment losowo z tablicy do wykonywania zapytań o dane.

Oczyszczanie partycji i zasobnika

Łącznik ocenia ograniczenia zapytania podczas planowania i wykonuje je na podstawie podanych predykatów zapytania. Pomaga to przyspieszyć wydajność zapytań i umożliwia łącznikowi wykonywanie zapytań o duże ilości danych.

Aby określić przypisania za pomocą implementacji funkcji haszującej murmur opisanej tutaj, stosuje się formułę bucketingu.

Mapowanie typów

Łącznik Sharded SQL obsługuje te same mapowania typów co łącznik serwera SQL mapowania typów.

Wypychanie

Obsługiwane są następujące optymalizacje wypychania:

  • Ogranicz wypychanie
  • Agregacje dystrybucyjne
  • Dołączenie pushdown

JOIN operację można wypchnąć na serwer tylko wtedy, gdy łącznik określi, że dane są kolokowane dla tabeli tworzenia i sprawdzania. Łącznik określa, że dane są kolokowane, gdy schemat sharding dla zarówno tabeli left, jak i right jest taki sam. — warunki sprzężenia są nadzbiorem kluczy partycjonowania i segmentacji.

Aby użyć optymalizacji wypychania JOIN, właściwość katalogu join-pushdown.strategy powinna być ustawiona na EAGER

AGGREGATE operacja wypychania dla tego łącznika może być wykonana tylko w przypadku agregatów dystrybucyjnych. Należy ustawić konfigurację optymalizatora optimizer.partial-aggregate-pushdown-enabled na true, aby włączyć tę optymalizację.