AnalyticDB:Desenvolvimento de XIHE BSP SQL

Pré-requisitos

• A job resource group is created para o cluster AnalyticDB for MySQL Enterprise Edition, Basic Edition ou Data Lakehouse Edition.

• Uma conta de banco de dados criada para o cluster AnalyticDB for MySQL Enterprise Edition, Basic Edition ou Data Lakehouse Edition.

Casos de uso

O mecanismo XIHE BSP executa jobs XIHE BSP SQL, adequados para cenários de ETL, consultas grandes e consultas esporádicas de baixa prioridade. Para obter mais informações sobre o mecanismo XIHE BSP, consulte compute engine.

Cenários de ETL

A figura a seguir ilustra um processo típico de ETL.

Operações de limpeza e transformação de dados em grandes conjuntos entre uma fonte de dados e a camada ADS geralmente demandam muito tempo. Nesses jobs, o tempo de resposta não é a principal preocupação; o foco é a alta confiabilidade para garantir a conclusão do processo de ELT dentro de um prazo específico. O sistema também precisa oferecer suporte a recursos como novas tentativas automáticas. Execute essas consultas com o mecanismo XIHE BSP para aproveitar seu alto throughput, alta confiabilidade e baixo custo.

Consultas na camada ADS costumam ser mais sensíveis ao tempo de resposta e exigem retornos em segundos ou até milissegundos. Utilize o mecanismo XIHE MPP para executar essas consultas e beneficiar-se de sua maior velocidade.

Consultas grandes para o mecanismo BSP

Devido às limitações do XIHE MPP, algumas consultas grandes podem causar erros de falta de memória (OOM) ou outras exceções. Executá-las no mecanismo XIHE MPP exigiria aumentar o cluster e adicionar mais recursos, o que não é econômico. Nesse caso, utilize o mecanismo XIHE BSP. As consultas são executadas em um grupo de recursos de job especificado e os dados são descarregados em disco, tornando essa abordagem mais adequada para consultas volumosas. Além disso, os recursos de um grupo de recursos de job são solicitados e faturados sob demanda, o que reduz custos.

Consultas esporádicas de baixa prioridade

Consultas de baixa prioridade geralmente não são sensíveis ao tempo de resposta. No entanto, se muitas forem enviadas simultaneamente, poderão consumir recursos do sistema e afetar a execução de outras consultas. Para resolver esse problema, execute essas consultas de baixa prioridade em um grupo de recursos de job usando o mecanismo XIHE BSP. Essa abordagem isola recursos, alivia a pressão sobre o sistema e evita interferência entre as consultas.

Limitações

• O mecanismo XIHE BSP não oferece suporte à gravação em tabelas Hudi.

• O mecanismo XIHE BSP não oferece suporte à leitura nem à gravação em tabelas Delta.

Desenvolvimento de jobs XIHE BSP

Desenvolva um job XIHE BSP usando um dos métodos a seguir.

/*+ resource_group=<resource_group_name>*/ <SQL Statement>;

/*+ resource_group=bsptest*/SELECT count(*) from test_db.ods_hudi;

/*+ resource_group=<resource_group_name>, query_submission_type=async*/ <SQL Statement>;

/*+ resource_group=bsptest, query_submission_type=async*/SELECT count(*) from test_db.ods_hudi;

Configuração de jobs XIHE BSP

Configure os recursos, o tempo limite padrão e a prioridade de um job XIHE BSP.

Métodos de configuração

Aplique definições de configuração a um único job BSP, a todos os jobs em um grupo de recursos de job específico ou a todos os jobs em um cluster.

/*+ resource_group=bsptest,elastic_job_max_acu=20*/SELECT count(*) from test_db.ods_hudi;

SET adb_config bsptest.elastic_job_max_acu=20;

SET adb_config elastic_job_max_acu=20;

Parâmetros

A tabela a seguir descreve os parâmetros configuráveis para jobs XIHE BSP.

FAQ

Visualizar status do job BSP

• Se você enviou o job BSP pelo editor de desenvolvimento SQL, acesse a página Job Editor > SQL Development e visualize o status do job na aba Execution Records.

• Caso tenha utilizado outros métodos de envio, consulte o status na tabela information_schema.kepler_meta_elastic_job_list executando a seguinte instrução:

  SELECT status FROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';

  Nota

  A tabela information_schema.kepler_meta_elastic_job_list armazena até 1.000 jobs BSP enviados nos últimos 30 dias. É possível realizar análises estatísticas adicionais, como agregações, nessa tabela. O exemplo abaixo mostra como contar o número de jobs BSP por estado:

  SELECT status,count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BY status;

Envio síncrono versus assíncrono

Os envios síncrono e assíncrono oferecem os mesmos recursos. A única diferença reside na necessidade de o cliente aguardar a conclusão da consulta.

Recomenda-se o envio assíncrono para consultas longas e intensivas em computação que retornam pequenos conjuntos de resultados, como INSERT INTO SELECT, INSERT OVERWRITE SELECT e CREATE TABLE AS SELECT.