Partilhar via

Conector SQL fragmentado

  • Artigo

Nota

Vamos desativar o Azure HDInsight no AKS em 31 de janeiro de 2025. Antes de 31 de janeiro de 2025, você precisará migrar suas cargas de trabalho para o Microsoft Fabric ou um produto equivalente do Azure para evitar o encerramento abrupto de suas cargas de trabalho. Os clusters restantes na sua subscrição serão interrompidos e removidos do anfitrião.

Apenas o apoio básico estará disponível até à data da reforma.

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 ainda não disponibilizadas para disponibilidade geral. Para obter informações sobre essa visualização específica, consulte Informações de visualização do Azure HDInsight no AKS. Para perguntas ou sugestões de recursos, envie uma solicitação no 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>
Property Description
connector.name Nome do conector Para SQL fragmentado, que deve ser sharded_sqlserver
conexão-usuário Nome de usuário no servidor SQL
conexão-senha Senha para o usuário no servidor SQL
fragmentado-cluster Necessário para ser definido como TRUE para conector sharded-sql
shard-config-location Local da configuração que define o esquema de fragmentação

Autenticação da origem 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 do esquema

O conector assume uma partição 2D/layout bucketed 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:

    • schema: O nome do esquema da tabela, que corresponde ao banco de dados no servidor SQL.
    • name: 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:

    • name: 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 que a tabela é distribuída, cujo padrão é 1.
    • bucketed_by(opcional): Uma matriz contendo uma ou mais colunas pelas quais os dados são bucketed, observe que o particionamento e o bucketing são hierárquicos, o que significa que cada partição é bucketed.
    • 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:
      • partition: 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 com o banco de dados do fragmento.

Por exemplo, se duas tabelas lineitem e part que você deseja consultar usando esse conector, você pode especificá-las da seguinte maneira.

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

Nota

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 por shipmode.
  • Cada partição tem 10 buckets.
  • Cada partição é bucketed_by partkey coluna.
  • Os buckets 1-7 para o valor AIR da partição estão localizados no test1 banco de dados.
  • Os buckets 8-10 para o valor AIR da partição estão localizados no test2 banco de dados.
  • Os estilhaços são uma variedade 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 bucketing para determinar atribuições usando a implementação da função hash murmur descrita aqui.

Mapeamento de tipo

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

Empurrar para baixo

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

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

JOIN A operação pode ser empurrada para o servidor somente quando o conector determina que os dados são colocalizados para a tabela de compilação e teste. O conector determina que os dados são colocados quando - o sharding_schema para ambos left e a right tabela é a mesma. - as condições de junção são superconjuntos de chaves de particionamento e bucketing.

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

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