Partage via

Connecteur SQL partitionné

  • Article

Important

Azure HDInsight sur AKS a été mis hors service le 31 janvier 2025. En savoir plus grâce à cette annonce.

Vous devez migrer vos charges de travail vers Microsoft Fabric ou un produit Azure équivalent pour éviter l’arrêt brusque de vos charges de travail.

Important

Cette fonctionnalité est actuellement en préversion. Les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure incluent des termes juridiques supplémentaires qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez informations sur Azure HDInsight sur AKS en préversion. Pour des questions ou des suggestions de fonctionnalités, envoyez une demande sur AskHDInsight avec les détails et suivez-nous pour plus de mises à jour sur Communauté Azure HDInsight.

Le connecteur SQL partitionné permet aux requêtes d’être exécutées sur des données réparties sur n’importe quel nombre de serveurs SQL.

Conditions préalables

Pour vous connecter à des serveurs SQL partitionnés, vous avez besoin des éléments suivants :

  • SQL Server 2012 ou version ultérieure, ou Azure SQL Database.
  • Accès réseau à partir du coordinateur Trino et des travailleurs vers SQL Server. Le port 1433 est le port par défaut.

Configuration générale

Le connecteur peut interroger plusieurs serveurs SQL en tant que source de données unique. Créez un fichier de propriétés de catalogue et utilisez connector.name=sharded-sql pour utiliser le connecteur SQL partitionné.

Exemple de configuration :

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
Propriété Description
connecteur.nom Nom du connecteur Pour SQL partitionné, qui doit être sharded_sqlserver
utilisateur de connexion Nom d’utilisateur dans SQL Server
mot de passe de connexion Mot de passe de l’utilisateur dans SQL Server
cluster éclaté Doit être défini sur TRUE pour le connecteur sharded-sql
shard-config-location emplacement de la configuration définissant le schéma de partitionnement

Authentification de la source de données

Le connecteur utilise l’authentification par mot de passe utilisateur pour interroger des serveurs SQL. Le même utilisateur spécifié dans la configuration est censé s’authentifier auprès de tous les serveurs SQL.

Définition de schéma

Le connecteur considère une disposition en partitions et compartiments 2D des données physiques réparties sur les serveurs SQL. La définition de schéma décrit cette disposition. Actuellement, seule la définition de schéma de partitionnement basée sur les fichiers est prise en charge.

Vous pouvez spécifier l’emplacement du schéma de partitionnement json dans les propriétés du catalogue comme shard-config-location=etc/shard-schema.json. Configurez le schéma de partitionnement json avec les propriétés souhaitées pour spécifier la disposition.

Le fichier JSON suivant décrit la configuration d’un connecteur SQL partitionné Trino. Voici une répartition de sa structure :

  • tables: tableau d’objets, chacun représentant une table dans la base de données. Chaque objet table contient :

    • schéma: nom de schéma de la table, qui correspond à la base de données dans le serveur SQL.
    • nom: nom de la table.
    • sharding_schema: nom du schéma de partitionnement associé à la table, qui sert de référence au sharding_schema décrit dans les étapes suivantes.

  • sharding_schema: tableau d’objets, chacun représentant un schéma de partitionnement. Chaque objet de schéma de partitionnement contient :

    • nom: nom du schéma de partitionnement.
    • partitioned_by: tableau contenant une ou plusieurs colonnes selon lesquelles le schéma de fragmentation est réalisé.
    • bucket_count(facultatif): un entier représentant le nombre total de compartiments dans lesquels la table est distribuée, avec une valeur par défaut de 1.
    • bucketed_by(facultatif): tableau contenant une ou plusieurs colonnes par lesquelles les données sont compartimentées, notez que le partitionnement et le compartimentage sont hiérarchiques, ce qui signifie que chaque partition est compartimentée.
    • partition_map: tableau d’objets, chacun représentant une partition dans le schéma de partitionnement. Chaque objet de partition contient :
      • de partition : valeur de partition spécifiée dans le formulaire partition-key=partitionvalue
      • fragments: Un tableau d’objets, chacun représentant un éclat dans la partition, chaque élément du tableau représente un réplica, Trino interroge l’un d’eux au hasard pour extraire des données pour une partition/buckets. Chaque objet fragmenté contient :
        • connectionUrl: URL de connexion JDBC à la base de données de la partition.

Par exemple, si deux tables lineitem et part que vous souhaitez interroger à l’aide de ce connecteur, vous pouvez les spécifier comme suit.

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

Annotation

Le connecteur s’attend à ce que toutes les tables soient présentes dans le serveur SQL défini dans le schéma d’une table, si ce n’est pas le cas, les requêtes pour cette table échouent.

Dans l’exemple précédent, vous pouvez spécifier la disposition de la table lineitem comme suit :

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

Cet exemple décrit les éléments suivants :

  • Données de l’élément de ligne de table partitionné par shipmode.
  • Chaque partition a 10 seaux.
  • Chaque partition est organisée par colonne partkey.
  • Les compartiments 1-7 pour la valeur de partition AIR se trouvent dans test1 base de données.
  • Les compartiments 8-10 pour la valeur de partition AIR se trouvent dans la base de données test2.
  • Les éclats sont un tableau de connectionUrl. Chaque membre du tableau représente un replicaSet. Pendant l’exécution de la requête, Trino sélectionne un fragment de manière aléatoire dans le tableau pour effectuer une requête sur les données.

Élagage des partitions et des compartiments

Le connecteur évalue les contraintes de requête pendant la planification et s’exécute en fonction des prédicats de requête fournis. Cela permet d’accélérer les performances des requêtes et permet au connecteur d’interroger de grandes quantités de données.

Formule pour déterminer les affectations par compartimentage, utilisant l’implémentation de la fonction de hachage Murmur décrite ici et.

Mappage de type

Le connecteur SQL partitionné prend en charge les mêmes mappages de types que le connecteur SQL Server ,.

Pushdown

Les optimisations de type pushdown suivantes sont prises en charge :

  • Limiter le pushdown
  • Agrégats distribuifs
  • Optimisation de jointure

L'opération JOIN peut être déléguée au serveur uniquement lorsque le connecteur détermine que les données sont colocalisées pour la table de construction et de sondage. Le connecteur détermine que des données sont colocalisées quand : le système de répartition pour la table left et pour la table right est identique. - Les conditions de jointure sont un sur-ensemble de clés de partitionnement et de compartimentage.

Pour utiliser l'optimisation pushdown de JOIN, la propriété de catalogue join-pushdown.strategy doit être définie sur EAGER

AGGREGATE pushdown pour ce connecteur ne peut être effectué que pour les agrégats distribuifs. La configuration de l’optimiseur optimizer.partial-aggregate-pushdown-enabled doit être définie sur true pour activer cette optimisation.