Compartilhar via

Conector SQL fragmentado

  • Artigo

Observação

Desativaremos o Microsoft Azure HDInsight no AKS em 31 de janeiro de 2025. Para evitar o encerramento abrupto das suas cargas de trabalho, você precisará migrá-las para o Microsoft Fabric ou para um produto equivalente do Azure antes de 31 de janeiro de 2025. Os clusters restantes em sua assinatura serão interrompidos e removidos do host.

Somente o suporte básico estará disponível até a data de desativação.

Importante

Esse recurso está atualmente na visualização. Os Termos de uso complementares para versões prévias do Microsoft Azure 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 essa versão prévia específica, confira Informações sobre a versão prévia do Azure HDInsight no AKS. Caso tenha perguntas ou sugestões de recursos, envie uma solicitação no AskHDInsight com os detalhes e siga-nos para ver mais atualizações sobre a 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 de:

  • SQL Server 2012 ou superior ou Banco de Dados SQL do Azure.
  • Acesso à rede do coordenador Trino e 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
connector.name Nome do conector Para SQL fragmentado, que deve ser sharded_sqlserver
usuário de conexão Nome de usuário no servidor SQL
senha de conexão Senha do usuário no SQL server
cluster fragmentado Necessário para ser definido como TRUE para conector sharded-sql
shard-config-location localização da configuração que define o esquema de fragmentação

Autenticação da fontes 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 seja autenticado em todos os servidores SQL.

Definição de esquema

O Connector assume um layout de partição/compartimento 2D dos dados físicos nos servidores SQL. A definição do 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 contendo uma ou mais colunas pelas quais o esquema de fragmentação é particionado.
    • bucket_count(opcional): Um número inteiro que representa o número total de buckets em 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 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 formato partition-key=partitionvalue
      • shards: uma matriz de objetos, cada um representando um fragmento dentro da partição, cada elemento da matriz representa uma réplica, 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 houver duas tabelas lineitem e part que você deseja consultar usando esse conector, será possível especificá-las da seguinte maneira.

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

Observação

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

Esse exemplo descreve:

  • Os dados do item de linha da tabela particionados por shipmode.
  • Cada partição possui 10 buckets.
  • Cada partição é uma coluna bucketed_by partkey.
  • Buckets 1-7 para valor de partição AIR estão localizados em test1 banco de dados.
  • Buckets 8-10 para valor de partição AIR estão localizados em test2 banco de dados.
  • Os fragmentos são uma série de connectionUrl. Cada membro da matriz representa um replicaSet. Durante a execução da consulta, Trino seleciona um fragmento aleatoriamente da matriz para consultar os dados.

Poda de partição e balde

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 agrupamento para determinar atribuições usando a implementação da função hash de murmúrio descrita aqui.

Mapeamento de tipo

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

Pushdown

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

  • Limitar pushdown
  • Agregados distributivos
  • Pushdown de junção

JOIN a operação pode ser transferida para o servidor somente quando o conector determina que os dados estão localizados para a tabela de construção e sondagem. O conector determina que os dados estã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 bucket.

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

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