Sdílet prostřednictvím


Shardovaný konektor SQL

Důležitý

Azure HDInsight v AKS byl vyřazen 31. ledna 2025. Zjistěte více z tohoto oznámení.

Abyste se vyhnuli náhlému ukončení úloh, musíte migrovat úlohy do Microsoft Fabric nebo ekvivalentního produktu Azure.

Důležitý

Tato funkce je aktuálně ve verzi Preview. Doplňkové podmínky použití pro náhledové verze Microsoft Azure obsahují další právní podmínky vztahující se na funkce Azure, které jsou v beta verzi, ve fázi náhledu, nebo ještě nejsou obecně dostupné. Informace o této konkrétní verzi najdete v tématu Předběžné informace o Azure HDInsight na AKS. Pokud máte dotazy nebo návrhy funkcí, odešlete prosím žádost na AskHDInsight s podrobnostmi a sledujte nás pro další aktualizace komunity Azure HDInsight .

Horizontálně dělený konektor SQL umožňuje spouštění dotazů nad daty distribuovanými napříč libovolným počtem serverů SQL.

Požadavky

Pokud se chcete připojit k horizontálně děleným SQL serverům, potřebujete:

  • SQL Server 2012 nebo novější nebo Azure SQL Database
  • Síťový přístup z koordinátoru Trino a pracovníků k SQL Serveru. Port 1433 je výchozí port.

Obecná konfigurace

Konektor může dotazovat více sql serverů jako jeden zdroj dat. Vytvořte soubor vlastností katalogu a použijte connector.name=sharded-sql k použití horizontálně děleného konektoru SQL.

Příklad konfigurace:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
Vlastnost Popis
konektor.název Název konektoru pro shardovaný SQL, který by měl být sharded_sqlserver
uživatel připojení Uživatelské jméno na SQL Serveru
heslo k připojení Heslo pro uživatele na SQL Serveru
rozdělený klastr Vyžaduje se nastavení na TRUE pro konektor sharded-sql.
umístění konfigurace shardu umístění konfigurace definující shardingové schéma

Ověřování zdroje dat

Konektor používá k dotazování sql serverů ověřování pomocí uživatelského hesla. Očekává se, že se stejný uživatel zadaný v konfiguraci ověří na všech serverech SQL.

Definice schématu

Konektor předpokládá 2D rozložení fyzických dat napříč SQL servery. Definice schématu popisuje toto rozložení. V současné době se podporuje pouze definice schématu horizontálního dělení na základě souborů.

Umístění JSON schématu horizontálního dělení můžete zadat ve vlastnostech katalogu, jako je shard-config-location=etc/shard-schema.json. Nakonfigurujte json schématu horizontálního dělení s požadovanými vlastnostmi a určete rozložení.

Následující soubor JSON popisuje konfiguraci konektoru SQL s horizontálním dělením Trino. Tady je rozpis struktury:

  • tabulky: Pole objektů, z nichž každá představuje tabulku v databázi. Každý objekt tabulky obsahuje:

    • schéma: Název schématu tabulky, která odpovídá databázi na SERVERU SQL.
    • název: Název tabulky.
    • sharding_schema: Název schématu horizontálního dělení přidruženého k tabulce, který funguje jako odkaz na sharding_schema popsané v dalších krocích.
  • sharding_schema: Pole objektů, z nichž každý představuje shardingové schéma. Každý objekt schématu horizontálního dělení obsahuje:

    • název: Název shardingového schématu.
    • partitioned_by: Pole obsahující jeden nebo více sloupců, podle kterých je shardovací schéma rozděleno.
    • bucket_count(volitelné): Celé číslo představující celkový počet kbelíků, které tabulka distribuuje, což je výchozí hodnota 1.
    • bucketed_by (volitelné): Pole obsahující jeden nebo více sloupců, podle kterých jsou data rozdělena do segmentů. Všimněte si, že rozdělování a segmentování jsou hierarchické, což znamená, že každý oddíl je dále členěn do segmentů.
    • partition_map: Pole objektů, z nichž každý představuje oddíl v rámci schématu horizontálního dělení. Každý objekt oddílu obsahuje:
      • oddílu: Hodnota oddílu zadaná ve formuláři partition-key=partitionvalue
      • shardů: Pole objektů, z nichž každý představuje shard v rámci oddílu, každý prvek pole představuje repliku, trino dotazuje libovolný z nich náhodně za účelem načtení dat pro oddíl nebo kbelíky. Každý objekt šardu obsahuje:
        • connectionUrl: Adresa URL připojení JDBC k databázi shardu.

Například pokud chcete dotazovat dvě tabulky lineitem a part pomocí tohoto konektoru, můžete je určit následujícím způsobem.

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

Poznámka

Konektor očekává, že všechny tabulky budou na SQL Serveru definovaném ve schématu tabulky, pokud tomu tak není, dotazy na danou tabulku selžou.

V předchozím příkladu můžete zadat rozložení tabulky lineitem takto:

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

Tento příklad popisuje:

  • Data pro řádkovou položku tabulky rozdělená podle shipmode.
  • Každý oddíl má 10 kbelíků.
  • Každý oddíl je rozdělen podle sloupce partkey.
  • Kontejnery 1-7 pro hodnotu oddílu AIR se nacházejí v test1 databázi.
  • Kontejnery 8-10 pro hodnotu oddílu AIR se nacházejí v test2 databázi.
  • Shardy jsou pole connectionUrl. Každý člen pole představuje replicaSet. Během provádění dotazu trino náhodně vybere horizontální oddíl z pole a dotazuje se na data.

Ořezávání oddílů a bloků

Konektor vyhodnocuje omezení dotazů během plánování a provádí na základě zadaných predikátů dotazu. To pomáhá zrychlit výkon dotazů a umožňuje konektoru dotazovat velké objemy dat.

Určení přiřazení pomocí bucketing vzorce s implementací hashovací funkce Murmur, jak je popsáno zde.

Mapování typů

Shardovaný konektor SQL podporuje stejné mapování typů jako u konektoru SQL Serveru mapování typů.

Stlačení

Podporují se následující optimalizace pushdown:

  • Omezení přepnutí dolů
  • Distribuční agregace
  • Spojit se s funkcí pushdown

JOIN operaci lze delegovat na server pouze v případě, že konektor určí, že data jsou společně umístěna pro sestavovací a zkušební tabulku. Konektor určuje, že data jsou spolu lokalizována, když je sharding_schema pro tabulku left i tabulku right stejná. - Podmínky pro spojení jsou nadmnožinou partičních a bucketovacích klíčů.

Pokud chcete použít optimalizaci JOIN typu pushdown, měla by být vlastnost katalogu join-pushdown.strategy nastavena na EAGER

AGGREGATE vkládání tohoto konektoru je možné provést pouze pro distribučně agregované operace. Aby bylo možné tuto optimalizaci povolit, musí být konfigurační optimizer.partial-aggregate-pushdown-enabled optimalizátoru nastaven na true.