Compartir a través de

Conector SQL particionado

  • Artículo

Nota:

Retiraremos Azure HDInsight en AKS el 31 de enero de 2025. Antes del 31 de enero de 2025, deberá migrar las cargas de trabajo a Microsoft Fabric o un producto equivalente de Azure para evitar la terminación repentina de las cargas de trabajo. Los clústeres restantes de la suscripción se detendrán y quitarán del host.

Solo el soporte técnico básico estará disponible hasta la fecha de retirada.

Importante

Esta funcionalidad actualmente está en su versión preliminar. En Términos de uso complementarios para las versiones preliminares de Microsoft Azure encontrará más términos legales que se aplican a las características de Azure que están en versión beta, en versión preliminar, o que todavía no se han lanzado con disponibilidad general. Para más información sobre esta versión preliminar específica, consulte la Información de Azure HDInsight sobre la versión preliminar de AKS. Para plantear preguntas o sugerencias sobre la característica, envíe una solicitud en AskHDInsight con los detalles y síganos para obtener más actualizaciones sobre Comunidad de Azure HDInsight.

El conector SQL particionado permite ejecutar consultas mediante datos distribuidos entre cualquier número de servidores SQL.

Requisitos previos

Para conectarse a servidores SQL con particiones, necesita:

  • SQL Server 2012 o posterior, o Azure SQL Database.
  • Acceso de red desde el coordinador y los trabajadores de Trino a SQL Server. El puerto 1433 es el puerto predeterminado.

Configuración general

El conector puede consultar varios servidores SQL Server como un único origen de datos. Cree un archivo de propiedades de catálogo y use connector.name=sharded-sql para usar el conector SQL particionado.

Ejemplo de configuración:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
Propiedad Descripción
connector.name Nombre del conector para SQL particionado, que debe ser sharded_sqlserver
connection-user Nombre de usuario en SQL Server
connection-password Contraseña del usuario en SQL Server
sharded-cluster Se requiere establecer en TRUE para el conector de sharded-sql
shard-config-location ubicación de la configuración que define el esquema de particionamiento

Autenticación con orígenes de datos

El conector usa la autenticación de contraseña de usuario para consultar servidores SQL Server. Se espera que el mismo usuario especificado en la configuración se autentique en todos los servidores SQL Server.

Definición de esquema

El conector supone un diseño de partición 2D o de cubo de los datos físicos en los servidores SQL Server. La definición de esquema describe este diseño. Actualmente, solo se admite la definición de esquema de particionamiento basada en archivos.

Puede especificar la ubicación del esquema de particionamiento json en las propiedades del catálogo como shard-config-location=etc/shard-schema.json. Configure el esquema de particionamiento json con las propiedades necesarias para especificar el diseño.

En el siguiente archivo JSON se describe la configuración de un conector SQL particionado de Trino. Este es un desglose de su estructura:

  • tablas: matriz de objetos, cada una de las cuales representa una tabla de la base de datos. Cada objeto de tabla contiene:

    • esquema: el nombre de esquema de la tabla, que corresponde a la base de datos de SQL Server.
    • nombre: nombre de la tabla.
    • sharding_schema: el nombre del esquema de particionamiento asociado a la tabla, que actúa como referencia sharding_schema descrito en los pasos siguientes.

  • sharding_schema: matriz de objetos, cada una de las cuales representa un esquema de particionamiento. Cada objeto de esquema de particionamiento contiene:

    • nombre: nombre del esquema de particionamiento.
    • partitioned_by: matriz que contiene una o varias columnas por las que se particiona el esquema de particionamiento.
    • bucket_count(opcional): un entero que representa el número total de cubos que se distribuye la tabla, que tiene como valor predeterminado 1.
    • bucketed_by(opcional): matriz que contiene una o varias columnas en las que se agrupan los datos, debe tener en cuenta que la creación de particiones y la creación de cubos son jerárquicas, lo que significa que cada partición se agrupa en depósitos.
    • partition_map: matriz de objetos, cada una de las cuales representa una partición dentro del esquema de particionamiento. Cada objeto de partición contiene:
      • partición: valor de partición especificado en el formulario partition-key=partitionvalue
      • particiones: una matriz de objetos, cada una que representa una partición dentro de la partición, cada elemento de la matriz representa una réplica, trino consulta cualquiera de ellos al azar para capturar datos de una partición o cubos. Cada objeto de partición contiene:
        • connectionUrl: la dirección URL de conexión de JDBC a la base de datos de la partición.

Por ejemplo, si dos tablas lineitem y part que desea consultar mediante este conector, puede especificarlas de la siguiente manera.

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

Nota:

El conector espera que todas las tablas estén presentes en el servidor SQL Server definido en el esquema de una tabla, si no es así, se producirá un error en las consultas de esa tabla.

En el ejemplo anterior, puede especificar el diseño de la tabla lineitem como:

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

En este ejemplo se describe lo siguiente:

  • Datos del elemento de línea de tabla particionado por shipmode.
  • Cada partición tiene 10 cubos.
  • Cada partición es bucketed_by columna partkey.
  • Los cubos 1-7 para el valor de partición AIR se encuentran en la base de datos test1.
  • Los cubos 8-10 para el valor de partición AIR se encuentran en la base de datos test2.
  • Las particiones son una matriz de connectionUrl. Cada miembro de la matriz representa un replicaSet. Durante la ejecución de la consulta, Trino selecciona una partición aleatoriamente de la matriz para consultar los datos.

Eliminación de particiones y cubos

El conector evalúa las restricciones de la consulta durante la planificación y las ejecuta basándose en los predicados de consulta proporcionados. Esto ayuda a acelerar el rendimiento de las consultas y permite al conector consultar grandes cantidades de datos.

Fórmula de bucketing para determinar las asignaciones mediante la implementación de la función hash murmur descrita aquí.

Asignación de tipos

El conector SQL particionado admite las mismas asignaciones de tipos que las asignaciones de tipos del conector de SQL Server.

Delegación

Se admiten las siguientes optimizaciones de aplicación:

  • Limitación de la aplicación
  • Agregados distributivos
  • Delegación de la combinación

La operación JOIN solo se puede insertar en el servidor cuando el conector determina que los datos se colocan para la tabla de compilación y sondeo. El conector determina que los datos se colocan cuando el sharding_schema para left y la tabla right es el mismo. - las condiciones de combinación son superconjunto de particiones y claves de depósito.

Para usar la optimización de la aplicación JOIN, la propiedad de catálogo join-pushdown.strategy debe establecerse en EAGER

la inserción AGGREGATE de este conector solo se puede realizar para agregados distributivos. La configuración del optimizador optimizer.partial-aggregate-pushdown-enabled debe establecerse en true para habilitar esta optimización.