Condividi tramite

Connettore SQL partizionato

  • Articolo

Nota

Azure HDInsight su AKS verrà ritirato il 31 gennaio 2025. Prima del 31 gennaio 2025, sarà necessario eseguire la migrazione dei carichi di lavoro a Microsoft Fabric o a un prodotto Azure equivalente per evitare interruzioni improvvise dei carichi di lavoro. I cluster rimanenti nella sottoscrizione verranno arrestati e rimossi dall’host.

Solo il supporto di base sarà disponibile fino alla data di ritiro.

Importante

Questa funzionalità è attualmente disponibile solo in anteprima. Le Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure includono termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale. Per informazioni su questa anteprima specifica, vedere Informazioni sull'anteprima di Azure HDInsight nel servizio Azure Kubernetes. Per domande o suggerimenti sulle funzionalità, inviare una richiesta in AskHDInsight con i dettagli e seguire Microsoft per altri aggiornamenti nella Community di Azure HDInsight.

Il connettore SQL partizionato consente l’esecuzione di query sui dati distribuiti in un numero qualsiasi di server SQL.

Prerequisiti

Per connettersi ai server SQL partizionati, è necessario:

  • SQL Server 2012 o versione successiva o database SQL di Azure.
  • Accesso di rete dal coordinatore Trino e dai ruoli di lavoro a SQL Server. La porta 1433 è la porta predefinita.

General configuration

Il connettore può eseguire query su più server SQL come singola origine dati. Creare un file di proprietà del catalogo e usare connector.name=sharded-sql per usare il connettore SQL partizionato.

Esempio di configurazione:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
Proprietà Descrizione
connector.name Nome del connettore per SQL partizionato, che deve essere sharded_sqlserver
connection-user Nome utente in SQL Server
connection-password Password per l’utente in SQL Server
sharded-cluster Deve essere impostato su TRUE per il connettore sharded-sql
shard-config-location Percorso della configurazione che definisce lo schema di partizionamento orizzontale

Autenticazione dell'origine dati

Il connettore usa l’autenticazione con user-password per eseguire query sui server SQL. Si prevede che lo stesso utente specificato nella configurazione esegua l’autenticazione in tutti i server SQL.

Definizione dello schema

Il connettore presuppone un layout di partizione/a bucket 2D dei dati fisici tra server SQL. La definizione dello schema descrive questo layout. Attualmente è supportata solo la definizione dello schema di partizionamento orizzontale basata su file.

È possibile specificare il percorso del file JSON dello schema di partizionamento orizzontale nelle proprietà del catalogo, ad esempio shard-config-location=etc/shard-schema.json. Configurare il file JSON dello schema di partizionamento orizzontale con le proprietà desiderate per specificare il layout.

Il file JSON seguente descrive la configurazione per un connettore SQL partizionato Trino. Ecco una suddivisione della struttura:

  • tables: matrice di oggetti, ognuno dei quali rappresenta una tabella nel database. Ogni oggetto tabella contiene:

    • schema: nome dello schema della tabella che corrisponde al database nel server SQL.
    • nome: nome della tabella.
    • sharding_schema: nome dello schema di partizionamento orizzontale associato alla tabella, che funge da riferimento al valore sharding_schema descritto nei passaggi successivi.

  • sharding_schema: matrice di oggetti, ognuno dei quali rappresenta uno schema di partizionamento orizzontale. Ogni oggetto schema di partizionamento orizzontale contiene:

    • nome: nome dello schema di partizionamento orizzontale.
    • partitioned_by: matrice contenente una o più colonne in base alle quali viene partizionato lo schema di partizionamento orizzontale.
    • bucket_count(optional): numero intero che rappresenta il numero totale di bucket in cui è distribuita la tabella, che per impostazione predefinita è 1.
    • bucketed_by(optional): matrice contenente una o più colonne in base alle quali vengono suddivisi in bucket i dati. Il partizionamento e i bucket sono gerarchici, ciò significa che ogni partizione viene inserita in bucket.
    • partition_map: matrice di oggetti, ognuno dei quali rappresenta una partizione all’interno dello schema di partizionamento orizzontale. Ogni oggetto partizione contiene:
      • partition: valore della partizione specificato in formato partition-key=partitionvalue
      • shards: matrice di oggetti, ognuno dei quali rappresenta un extent all’interno della partizione. Ogni elemento della matrice rappresenta una replica. Trino esegue una query casuale per recuperare i dati per una partizione o un bucket. Ogni oggetto extent contiene:
        • connectionUrl: URL di connessione JDBC al database dell’extent.

Ad esempio, è possibile specificare le due tabelle lineitem e part, su cui si vuole eseguire una query usando questo connettore, come indicato di seguito.

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

Nota

Il connettore prevede che tutte le tabelle siano presenti nel server SQL definito nello schema per una tabella, in caso contrario, le query per tale tabella avranno esito negativo.

Nell’esempio precedente, è possibile specificare il layout della tabella lineitem come:

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

Questo esempio descrive:

  • Dati per l’elemento riga della tabella partizionato da shipmode.
  • Ogni partizione ha 10 bucket.
  • Ogni partizione è bucketed_by dalla colonna partkey.
  • I bucket 1-7 per il valore di partizione AIR si trovano nel database test1.
  • I bucket 8-10 per il valore di partizione AIR si trovano nel database test2.
  • Gli extent sono una matrice di connectionUrl. Ogni membro della matrice rappresenta un oggetto replicaSet. Durante l’esecuzione della query, Trino seleziona un extent in modo casuale dalla matrice per eseguire query sui dati.

Eliminazione di partizioni e bucket

Il connettore valuta i vincoli di query durante la pianificazione e compie delle esecuzioni in base ai predicati di query forniti. Ciò consente di velocizzare le prestazioni delle query e consente al connettore di eseguire query su grandi quantità di dati.

Formula di bucket per determinare le assegnazioni usando l’implementazione della funzione MurmurHash descritta qui.

Mapping dei tipi

Il connettore SQL partizionato supporta gli stessi mapping dei tipi del Connettore SQL Server.

Pushdown

Sono supportate le ottimizzazioni di pushdown seguenti:

  • Pushdown di limite
  • Aggregazioni di distribuzione
  • Pushdown join

Il pushdown dell’operazione JOIN al server può essere eseguito solo quando il connettore determina che i dati sono condivisi per la tabella di compilazione e probe. Il connettore determina che i dati sono condivisi quando sharding_schema è lo stesso per le tabelle left e right. Le condizioni di JOIN sono superset di chiavi di partizionamento e bucket.

Per usare l’ottimizzazione del pushdown di JOIN, la proprietà del catalogo join-pushdown.strategy deve essere impostata su EAGER

Il pushdown AGGREGATE per questo connettore può essere eseguito solo per le aggregazioni di distribuzione. La configurazione dell’ottimizzatore optimizer.partial-aggregate-pushdown-enabled deve essere impostata su true per abilitare questa ottimizzazione.