Conector SQL particionado
Oharra
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.
Garrantzitsua
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.
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.
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 |
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.
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.
- partición: valor de partición especificado en el formulario
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"
}
]
Oharra
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ónAIR
se encuentran en la base de datostest1
. - Los cubos
8-10
para el valor de particiónAIR
se encuentran en la base de datostest2
. - 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.
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í.
El conector SQL particionado admite las mismas asignaciones de tipos que las asignaciones de tipos del conector de SQL Server.
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.