Partager via

Connecteur SQL partitionné

  • Article

Remarque

Nous allons mettre hors service Azure HDInsight sur AKS le 31 janvier 2025. Avant le 31 janvier 2025, vous devrez migrer vos charges de travail vers Microsoft Fabric ou un produit Azure équivalent afin d’éviter leur arrêt brutal. Les clusters restants de votre abonnement seront arrêtés et supprimés de l’hôte.

Seul le support de base sera disponible jusqu’à la date de mise hors service.

Important

Cette fonctionnalité est disponible actuellement en mode Aperçu. Les Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure contiennent davantage de conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou ne se trouvant pas encore en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez les Informations sur la préversion d’Azure HDInsight sur AKS. Pour toute question ou pour des suggestions à propos des fonctionnalités, veuillez envoyer vos requêtes et leurs détails sur AskHDInsight, et suivez-nous sur la Communauté Azure HDInsight pour plus de mises à jour.

Le connecteur SQL partitionné permet d’exécuter des requêtes sur des données réparties sur un nombre quelconque de serveurs SQL.

Prérequis

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

  • SQL Server 2012 ou supérieur, ou Azure SQL Database.
  • Accès réseau du coordinateur et des travailleurs de Trino au serveur SQL. Le port par défaut est le port 1433.

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
connector.name Nom du connecteur Pour SQL partitionné, qui doit être sharded_sqlserver
connection-user Nom d’utilisateur dans SQL Server
connection-password Mot de passe de l’utilisateur(-trice) dans le serveur SQL
sharded-cluster Obligatoire pour être défini sur TRUE pour le connecteur SQL partitionné
shard-config-location emplacement de la configuration définissant le schéma de partitionnement

Authentification aux sources de données

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

Définition de schéma

Le connecteur suppose une disposition partition/compartimentée 2D des données physiques 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 décomposition de sa structure :

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

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

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

    • nom : le nom du schéma de partitionnement.
    • partitioned_by : un tableau contenant une ou plusieurs colonnes selon lesquelles le schéma de partitionnement est partitionné.
    • bucket_count(facultatif)  : un entier représentant le nombre total de compartiments distribués par défaut à 1.
    • bucketed_by(facultatif) : un 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 : un tableau d’objets, chacun représentant une partition dans le schéma de partitionnement. Chaque objet de partition contient :
      • partition : la valeur de partition spécifiée dans le formulaire partition-key=partitionvalue
      • partitions : un tableau d’objets, chacun représentant une partition 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/compartiments. Chaque objet partitionné contient les éléments suivants :
        • connectionUrl : L’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"
		}
    ]

Remarque

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 compartiments.
  • Chaque partition est bucketed_by partkey colonne.
  • 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 test2 base de données.
  • Les partitions sont un tableau de connectionUrl. Chaque membre du tableau représente un replicaSet. Pendant l’exécution de la requête, Trino sélectionne une partition de manière aléatoire dans le tableau pour interroger des données.

Taille 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 le niveau de performance des requêtes et permet au connecteur d’interroger de grandes quantités de données.

Formule de compartimentage pour déterminer les affectations à l’aide de l’implémentation de fonction de hachage murmure décrite ici.

Mappage de type

Le connecteur SQL partitionné supporte les mêmes mappages de type que les mappages de type du connecteur SQL server.

Pushdown

Les optimisations pushdown suivantes sont prises en charge :

  • Limiter le pushdown
  • Agrégats distributifs
  • Pushdown de jointure

JOIN opération peut être envoyée au serveur uniquement lorsque le connecteur détermine que les données sont colocalisées pour la table de génération et de sonde. Le connecteur détermine que les données sont colocalisées quand : le sharding_schema pour les deux left et la table right est identique. – les conditions de jointure sont un sur-ensemble de clés de partitionnement et de compartimentage.

Pour utiliser JOIN optimisation pushdown, les propriétés de catalogue join-pushdown.strategy doivent être définies sur EAGER

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