Compartilhar via

Conector SQL fragmentado

  • Artigo

Importante

O Azure HDInsight no AKS se aposentou em 31 de janeiro de 2025. Saiba mais neste 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

Esse recurso está atualmente em versão prévia. Os termos de uso complementares para o Microsoft Azure Previews incluem mais termos legais que se aplicam aos recursos do Azure que estão em versão beta, em versão prévia ou ainda não lançados em disponibilidade geral. Para obter informações sobre esta versão prévia específica do Azure HDInsight no AKS, consulte . Para perguntas ou sugestões de funcionalidades, envie uma solicitação no AskHDInsight com os detalhes e siga-nos para obter mais atualizações sobre a Comunidade do Azure HDInsight .

O conector SQL fragmentado permite que as consultas sejam executadas por 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 para o 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
usuário de conexão Nome de usuário no SQL Server
senha de conexão Senha para o usuário no SQL Server
cluster fragmentado Necessário para ser definido como TRUE para o conector sharded-sql
localização-configuração-fragmento local da configuração que define o esquema de fragmentação

Autenticação da fonte de dados

O conector usa a autenticação de senha do 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 um layout de partição 2D/em compartimentos dos dados físicos em servidores SQL. A definição de esquema descreve esse layout. Atualmente, há suporte apenas para a definição de esquema de fragmentação baseada em arquivo.

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

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

  • tabelas: uma matriz de objetos, cada uma 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 SQL Server.
    • Nome: o nome da tabela.
    • sharding_schema: o nome do esquema de fragmentação associado à tabela, que atua como uma referência à sharding_schema descrita 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.
    • particionado_por: um array 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 entre os quais a tabela é distribuída, sendo 1 o padrão.
    • bucketed_by(opcional): um array que contém uma ou mais colunas pelas quais os dados são bucketizados, observe que o particionamento e o bucketing são hierárquicos, o que significa que cada partição é bucketizada.
    • 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 uma delas aleatoriamente para buscar dados para uma partição ou buckets. Cada objeto de fragmento contém:
        • connectionUrl: a URL de conexão JDBC com o banco de dados do fragmento.

Por exemplo, se você precisa consultar as tabelas lineitem e part usando este conector, poderá 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 SQL Server 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 do item de linha da tabela são particionados por shipmode.
  • Cada partição tem 10 buckets.
  • Cada partição é distribuída por coluna partkey.
  • Buckets 1-7 para o valor de partição AIR estão localizados no banco de dados test1.
  • Buckets 8-10 para o valor de partição AIR estão localizados no banco de dados test2.
  • Os fragmentos 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.

Particionamento e poda de recipientes

O conector avalia as restrições de consulta durante o planejamento e é executado 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 de hash murmur descrita aqui .

Mapeamento de tipo

O conector SQL fragmentado dá suporte aos mesmos mapeamentos de tipo que o conector SQL Server mapeamentos de tipo.

Pilha

Há suporte para as seguintes otimizações de pushdown:

  • Limitação por pushdown
  • Agregações distributivas
  • Pushdown de junção

A operação JOIN pode ser executada no servidor somente quando o conector determina que os dados estão co-localizados para a tabela de construção e sondagem. O conector determina que os dados são colocados quando o sharding_schema para left e a tabela right é o mesmo. – as condições de junção são um superconjunto de chaves de particionamento e distribuição em buckets.

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

AGGREGATE pushdown para este conector só pode ser realizado para agregações distributivas. A configuração do otimizador optimizer.partial-aggregate-pushdown-enabled precisa ser definida como true para habilitar essa otimização.