O Hologres integra-se nativamente ao MaxCompute. O mecanismo lê dados do MaxCompute diretamente e usa filtragem de partições em vários níveis e pushdown de operadores para acelerar as consultas.
Há duas abordagens para acelerar consultas do MaxCompute no Hologres:
|
Abordagem |
Ganho de desempenho |
Sobrecarga de armazenamento |
Mais indicada para |
|
Importar dados para o Hologres (recomendado) |
10 a 100 vezes mais rápido que consultas diretas no MaxCompute |
Requer armazenamento para uma cópia dos dados |
Consultas analíticas frequentes, junções com tabelas internas |
|
Consultar via tabela externa |
2 a 5 vezes mais rápido que consultas diretas no MaxCompute |
Sem armazenamento adicional |
Consultas ad hoc, acesso infrequente, grandes conjuntos de dados cuja cópia é inviável |
Consultas em tabelas externas são sempre mais lentas do que em tabelas internas do Hologres. Se o desempenho da consulta for sua principal prioridade, importe os dados. Use tabelas externas quando o custo de armazenamento ou os requisitos de atualização dos dados tornarem a importação inviável.
Importar dados para o Hologres (recomendado)
Importar dados do MaxCompute para uma tabela interna do Hologres oferece desempenho de consulta 10 a 100 vezes superior ao de tabelas externas. Adote essa abordagem ao executar consultas analíticas frequentes ou unir dados do MaxCompute com tabelas internas do Hologres.
Para importar dados, crie uma tabela interna no Hologres com chave de distribuição e propriedade de índice adequadas e use SQL para carregar os dados do MaxCompute. Para obter detalhes, consulte Importar dados do MaxCompute usando SQL.
Consultar via tabela externa
Quando a importação de dados não for prática — por exemplo, se os requisitos de atualização dos dados forem rigorosos ou o conjunto de dados for muito grande para copiar — consulte os dados do MaxCompute por meio de tabelas externas e otimize o desempenho dessas consultas seguindo as melhores práticas abaixo.
|
Melhor prática |
Quando usar |
Impacto no desempenho |
|
Usar computação serverless |
ETL em larga escala, importações em massa, consultas em grandes conjuntos de dados |
Descarrega a computação; previne erros OOM |
|
Usar o mecanismo de execução HQE |
Tabelas no formato ORC, Hologres V0.10+ |
Melhoria de 30–100% |
|
Evitar varreduras completas de tabela |
Todas as consultas |
Reduz imediatamente os dados verificados |
|
Otimizar a estrutura da tabela do MaxCompute para SQE |
HQE não suportado (não-ORC, transacional, Schema Evolution) |
Habilita pruning e pushdown de agregação |
|
Mesclar arquivos pequenos |
Tabelas com >100 arquivos e tamanho médio <64 MB |
Reduz a sobrecarga de varredura |
|
Ajustar parâmetros de consulta |
Características específicas de carga de trabalho |
Controle refinado de recursos |
Usar computação serverless
Para cargas de trabalho em larga escala — como importar grandes volumes de dados do MaxCompute, executar jobs de extração, transformação e carga (ETL) ou consultar tabelas extensas — use a computação serverless (disponível no Hologres V2.1.17 e versões posteriores).
A computação serverless usa recursos computacionais adicionais fora da sua instância. Assim:
Os recursos da sua instância permanecem disponíveis para outras cargas de trabalho.
Não há necessidade de reservar capacidade computacional extra para picos de carga.
Erros OOM (out-of-memory) tornam-se menos prováveis.
A cobrança ocorre apenas pela computação usada pela tarefa.
Para obter detalhes, consulte Computação serverless e Trabalhar com computação serverless.
Usar o mecanismo de execução HQE
O Hologres V0.10 e versões posteriores usam por padrão o Hologres Query Engine (HQE) para consultas em tabelas do MaxCompute, o que melhora o desempenho em aproximadamente 30–100% em comparação às versões anteriores.
O HQE apresenta as seguintes limitações:
O HQE acelera apenas consultas em tabelas do MaxCompute no formato ORC. Outros formatos, como CFile, não têm suporte.
O HQE não acelera consultas em tabelas transacionais do MaxCompute ou tabelas com Schema Evolution. Nesses casos, o Hologres reverte automaticamente para o mecanismo SQE.
É necessário ter o mapeamento de tipos de dados correto entre o MaxCompute e o Hologres. Incompatibilidades reduzem o efeito de aceleração.
Evitar varreduras completas de tabela
Varreduras completas de tabela são a causa mais comum de lentidão em consultas a tabelas externas. Para evitá-las:
Selecione apenas as colunas necessárias. Use
SELECT col1, col2 FROM tableem vez deSELECT * FROM table.Filtre por colunas de partição. Adicione condições de partição na cláusula
WHEREpara limitar o número de partições verificadas.
Recomendamos fortemente o uso de filtros de partição em todas as consultas a tabelas particionadas. O pruning de partições é a maneira mais eficaz de reduzir a quantidade de dados que o Hologres precisa ler do MaxCompute.
Otimizar a estrutura da tabela do MaxCompute para SQE
Quando o HQE não suporta uma consulta, o Hologres reverte para o Seahawks Query Engine (SQE). Para melhorar o desempenho do SQE, reestruture a tabela subjacente do MaxCompute. Há duas estratégias de clustering disponíveis:
|
Estratégia |
Mais indicada para |
Restrição |
|
Hash clustering |
Consultas de agregação, bucket pruning |
Sem garantia contra data skew |
|
Range clustering |
Consultas de intervalo, consultas de chave composta, prevenção de skew |
Layout ordenado globalmente |
Converter para uma tabela de hash clustering
O hash clustering permite bucket pruning, otimização de agregação e otimização de armazenamento. Ao criar ou alterar uma tabela com CLUSTERED BY, o MaxCompute aplica hash nas colunas especificadas e distribui os dados em buckets.
Para a chave de hash, escolha colunas com poucos valores de chave duplicados.
ALTER TABLE <table_name>
[CLUSTERED BY (<col_name> [, <col_name>, ...])
[SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])]
INTO <number_of_buckets> BUCKETS];
Após a instrução ALTER TABLE, apenas novas partições usarão hash clustering. Para mais informações, consulte Hash Clustering na documentação do MaxCompute.
Converter para uma tabela de range clustering
O range clustering distribui dados em um layout ordenado globalmente, o que previne o data skew que o hash clustering pode causar. Sua distribuição ordenada cria um índice de dois níveis que suporta consultas de intervalo e consultas de chave composta.
ALTER TABLE <table_name>
[RANGE CLUSTERED BY (<col_name> [, <col_name>, ...])
[SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])]
[INTO <number_of_buckets> BUCKETS];
Após a instrução ALTER TABLE, apenas novas partições usarão range clustering. Para mais informações, consulte Range Clustering.
Tabelas de hash e range clustering possuem as mesmas restrições que tabelas de hash clustering:
Use
INSERT OVERWRITEpara gravar dados. O comandoINSERT INTOnão tem suporte.Não faça upload de dados para essas tabelas usando o Tunnel. Dados enviados via Tunnel não são ordenados e são incompatíveis com os requisitos de clustering.
Compactar arquivos pequenos
Um excesso de arquivos pequenos em uma tabela do MaxCompute torna as consultas lentas, pois o Hologres precisa abrir e ler cada arquivo individualmente. Execute o seguinte comando no MaxCompute para verificar a contagem de arquivos:
DESC EXTENDED <table_name>;
Na saída, FileNum mostra o número de arquivos e Size exibe o tamanho total em bytes. Se a tabela tiver mais de 100 arquivos e o tamanho médio do arquivo for inferior a 64 MB, mescle os arquivos pequenos. Para mais informações, consulte FAQ: Otimização de arquivos pequenos e diagnóstico de jobs.
Para orientações sobre como mesclar arquivos, consulte FAQ sobre otimização de arquivos pequenos e diagnóstico de jobs.
Ajustar parâmetros de consulta
O Hologres define valores padrão de parâmetros com base em benchmarks internos. Esses padrões funcionam bem para a maioria das cargas de trabalho — altere-os apenas se tiver um motivo específico.
|
Parâmetro |
Padrão |
Observações |
|
|
512 (máx: 1024) |
Máximo de partições verificadas por consulta. Definir um valor muito alto degrada o desempenho. |
|
|
8192 |
Tamanho do lote para cada leitura de uma tabela do MaxCompute. |
|
|
64 MB |
Tamanho por split ao acessar uma tabela do MaxCompute. Para tabelas grandes, aumente este valor para evitar splits excessivos. Disponível no Hologres V1.1 e posteriores. |
|
|
Número de vCPUs da instância (máx: 128) |
Concorrência máxima para acesso a tabelas externas. Mantenha este valor baixo para evitar que consultas a tabelas externas prejudiquem outras cargas de trabalho. Disponível no Hologres V1.1 e posteriores. |
|
|
32 |
Concorrência máxima para instruções DML em tabelas externas. Limita o consumo de recursos durante a importação e exportação de dados. Disponível no Hologres V1.1 e posteriores. |
Não defina hg_foreign_table_executor_max_dop com um valor muito baixo, como 1. Isso pode concentrar a carga em workers específicos durante operações simultâneas de leitura e gravação, desencadeando erros OOM.
Exemplo: Ajustar o limite máximo de partições:
-- Default: 512. Maximum: 1024. Do not set too high.
SET hg_foreign_table_max_partition_limit = 128;
Exemplo: Ajustar o tamanho do split para tabelas grandes:
-- Default: 64 MB. Increase for large tables to reduce the number of splits.
SET hg_foreign_table_split_size = 128;
Exemplo: Limitar a concorrência para acesso a tabelas externas:
-- Default: number of instance cores. Maximum: 128.
SET hg_foreign_table_executor_max_dop = 32;