Partilhar via

Conector SQL fragmentado

  • Artigo

Importante

O Azure HDInsight no AKS foi desativado em 31 de janeiro de 2025. Saiba mais com este anúncio.

Você precisa migrar suas cargas de trabalho para Microsoft Fabric ou um produto equivalente do Azure para evitar o encerramento abrupto de suas cargas de trabalho.

Importante

Esta funcionalidade está atualmente em pré-visualização. Os Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure incluem mais termos legais que se aplicam a funcionalidades do Azure que estão em versão beta, em pré-visualização ou que ainda não estão geralmente disponíveis. Para obter informações sobre essa visualização específica, consulte Azure HDInsight no AKS informações de visualização. Para perguntas ou sugestões de funcionalidades, envie um pedido em AskHDInsight com os detalhes e siga-nos para obter mais atualizações na Comunidade do Azure HDInsight.

O conector SQL fragmentado permite que consultas sejam executadas em dados distribuídos em qualquer número de servidores SQL.

Pré-requisitos

Para se conectar a servidores SQL fragmentados, você precisa:

  • SQL Server 2012 ou superior ou Banco de Dados SQL do Azure.
  • Acesso à rede do coordenador do Trino e dos trabalhadores ao SQL Server. A porta 1433 é a porta padrão.

Configuração geral

O conector pode consultar vários servidores SQL como uma única fonte de dados. Crie um arquivo de propriedades de catálogo e use connector.name=sharded-sql para usar o conector SQL fragmentado.

Exemplo de configuração:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
Propriedade Descrição
conector.nome Nome do conector para SQL fragmentado, que deve ser sharded_sqlserver
conexão-usuário Nome de usuário no servidor SQL
senha de conexão Senha para o usuário no servidor SQL
agrupamento-fragmentado Deve ser definido como TRUE para o conector sharded-sql
shard-config-location Local da configuração que define o esquema de fragmentação

Autenticação da fonte de dados

O conector usa autenticação de senha de usuário para consultar servidores SQL. Espera-se que o mesmo usuário especificado na configuração se autentique em todos os servidores SQL.

Definição de esquema

O conector assume uma disposição de partição em 2D/forma compartimentada dos dados físicos nos servidores SQL. A definição de esquema descreve esse layout. Atualmente, apenas a definição de esquema de fragmentação baseada em arquivo é suportada.

Você pode especificar o local do esquema de fragmentação json nas propriedades do catálogo como shard-config-location=etc/shard-schema.json. Configure o esquema de fragmentação json com as propriedades desejadas para especificar o layout.

O arquivo JSON a seguir descreve a configuração de um conector SQL fragmentado Trino. Aqui está um detalhamento de sua estrutura:

  • tabelas: Uma matriz de objetos, cada um representando uma tabela no banco de dados. Cada objeto de tabela contém:

    • esquema: O nome do esquema da tabela, que corresponde ao banco de dados no servidor SQL.
    • nome: O nome da tabela.
    • sharding_schema: O nome do esquema de fragmentação associado à tabela, que atua como uma referência ao sharding_schema descrito nas próximas etapas.

  • sharding_schema: Uma matriz de objetos, cada um representando um esquema de fragmentação. Cada objeto de esquema de fragmentação contém:

    • nome: O nome do esquema de fragmentação.
    • partitioned_by: Uma matriz que contém uma ou mais colunas pelas quais o esquema de fragmentação é particionado.
    • bucket_count(opcional): Um inteiro que representa o número total de buckets em que a tabela está distribuída, cujo padrão é 1.
    • bucketed_by(opcional): Um array contendo uma ou mais colunas pelas quais os dados são agrupados, observe que o particionamento e o agrupamento são hierárquicos, o que significa que cada partição é agrupada.
    • partition_map: Uma matriz de objetos, cada um representando uma partição dentro do esquema de fragmentação. Cada objeto de partição contém:
      • partição: O valor da partição especificado no formulário partition-key=partitionvalue
      • fragmentos: Uma matriz de objetos, cada um representando um fragmento dentro da partição, cada elemento da matriz representa uma réplica, o trino consulta qualquer um deles aleatoriamente para buscar dados para uma partição / buckets. Cada objeto de fragmento contém:
        • connectionUrl: A URL de conexão JDBC para o banco de dados da partição.

Por exemplo, se duas tabelas lineitem e part que pretendes consultar usando este conector, podes especificá-las da seguinte maneira.

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

Observação

O conector espera que todas as tabelas estejam presentes no servidor SQL definido no esquema de uma tabela, se esse não for o caso, as consultas para essa tabela falharão.

No exemplo anterior, você pode especificar o layout da tabela 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"
						}
					]
				}                
			]
        }
    ]

Este exemplo descreve:

  • Os dados para o item de linha de tabela particionado usando shipmode.
  • Cada partição tem 10 buckets.
  • Cada partição é segregada por coluna partkey.
  • Os buckets 1-7 para o valor de partição AIR estão localizados no banco de dados test1.
  • Os buckets 8-10 para o valor da partição AIR estão localizados no banco de dados test2.
  • Os estilhaços são uma matriz de connectionUrl. Cada membro da matriz representa um replicaSet. Durante a execução da consulta, o Trino seleciona um fragmento aleatoriamente da matriz para consultar dados.

Poda de divisórias e caçambas

O Connector avalia as restrições de consulta durante o planejamento e executa com base nos predicados de consulta fornecidos. Isso ajuda a acelerar o desempenho da consulta e permite que o conector consulte grandes quantidades de dados.

Fórmula de distribuição para determinar atribuições, utilizando a implementação da função hash Murmur descrita aqui.

Mapeamento de tipo

O conector SQL fragmentado suporta os mesmos mapeamentos de tipo que o conector do SQL Server mapeamentos de tipo.

Empurrar para baixo

As seguintes otimizações de pushdown são suportadas:

  • Limite a pressão
  • Agregados distributivos
  • Junte-se ao pushdown

A operação JOIN pode ser transferida para o servidor apenas quando o conector determina que os dados estão colocalizados para a tabela de compilação e de sondagem. O conector determina que os dados estão colocados quando o esquema de sharding para ambas a tabela left e a tabela right é o mesmo. - as condições de junção são um conjunto maior de chaves de particionamento e de distribuição em baldes.

Para usar JOIN otimização pushdown, a propriedade do catálogo join-pushdown.strategy deve ser definida como EAGER

AGGREGATE pushdown para este conector só pode ser feito para agregados distributivos. O optimizer.partial-aggregate-pushdown-enabled de configuração do otimizador precisa ser definido como true para habilitar essa otimização.