As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Trino
O Trino é um mecanismo de consulta de código aberto projetado para consultas interativas em uma ampla variedade de fontes de dados. Essas fontes podem incluir bancos de dados relacionais, dados baseados em arquivos e dados HDFS, entre outras. O objetivo mais comum do Trino com o Amazon EMR é executar consultas SQL complexas em grandes conjuntos de dados armazenados no Amazon S3. Ele também é compatível com o ANSI SQL, o que o torna familiar para engenheiros de banco de dados, analistas de dados e cientistas de dados que estão familiarizados com SQL.
**nota**
O PrestoSQL foi renomeado para Trino em dezembro de 2020. As versões 6.4.0 e posteriores do Amazon EMR geralmente fazem referência ao [Trino](https://trino.io/), enquanto as versões anteriores fazem referência ao PrestoSQL.
**Importante**
O PrestoSQL, versão anterior do Trino, ainda está disponível para uso com o Amazon EMR. Porém, é altamente recomendável usar o Trino no futuro com o Amazon EMR. Observe também que o Trino e o PrestoSQL não podem ser executados ao mesmo tempo no mesmo cluster.
A tabela a seguir lista a versão do Trino incluída na versão mais recente do Amazon EMR 7.x, juntamente com os componentes que o Amazon EMR instala com o Trino. Para a versão dos componentes instalados com o Trino nesta versão, consulte Versões de componentes da [versão 7.12.0](emr-7120-release.md).
**Informações sobre a versão do Trino (PrestoSQL) para o emr-7.12.0**
| Rótulo de versão do Amazon EMR | Versão do Trino (PrestoSQL) | Componentes instalados com o Trino (PrestoSQL) |
| --- | --- | --- |
| emr-7.12.0 | trino-prestosql 476-amzn-1 | emrfs, emr-goodies, hadoop-client, hadoop-hdfs-datanode, hadoop-hdfs-library, hadoop-hdfs-namenode, hadoop-hdfs-zkfc, hadoop-kms-server, hadoop-yarn-nodemanager, hadoop-yarn-resourcemanager, hadoop-yarn-timeline-server, hive-client, hudi, hudi-trino, hcatalog-server, mariadb-server, trino-coordinator, trino-worker |
**Topics**
+ [História e design do Trino](emr-trino-intro-history.md)
+ [Conceitos básicos do Trino](emr-trino-getting-started.md)
+ [Configurar o Trino no Amazon EMR](emr-trino-config.md)
+ [Praticas recomendadas para o Trino no Amazon EMR](emr-trino-advanced.md)
+ [Considerações sobre o Trino](Trino-considerations.md)
+ [Histórico de lançamentos do Trino](Trino-release-history.md)
# História e design do Trino
O Trino é especializado em consultar grandes conjuntos de dados de muitas fontes diferentes. O Trino pode acessar e consultar o HDFS em um caso de uso tradicional de big data, mas também pode consultar fontes adicionais, como bancos de dados relacionais e bancos de dados NoSQL. O Trino começou originalmente como um fork do mecanismo de consulta Presto, em 2019. Desde então, ele tem sido desenvolvido independentemente da base de código do Presto.
Para obter mais informações sobre o mecanismo de consulta Trino e como ele é usado, consulte o [site do Trino](https://trino.io/). Para ler a documentação da origem do Trino, consulte [Visão geral do Trino](https://trino.io/docs/current/overview.html).
## Conceitos de arquitetura
O Trino pode executar consultas rápidas e eficientes porque processa dados paralelamente em um cluster. Ele foi projetado pensando na consulta de um data lake, pois é especializado em consultas em grandes volumes de dados, normalmente em casos de uso que envolvem Hadoop e HDFS. Porém, o Trino também pode consultar bancos de dados relacionais tradicionais. Para obter mais informações, consulte os tópicos sobre arquitetura na [documentação do Trino](https://trino.io/docs/current/overview/concepts.html#architecture).
### Componentes do Trino
O Trino tem alguns componentes principais de arquitetura que trabalham juntos para agilizar a execução de consultas. É útil ter conhecimento prático deles quando você ajusta seu cluster para melhorar a performance:
+ O **coordenador** é responsável pela orquestração de consultas. Ele analisa e otimiza consultas SQL recebidas, gera planos de execução, atribui tarefas aos nós de processamento e coleta e monta os resultados de consultas. Além disso, ele monitora o uso de recursos e acompanha o status dos nós de processamento. Para obter mais informações, consulte [Coordenador* na *documentação do Trino](https://trino.io/docs/current/overview/concepts.html#coordinator).
+ **Nós de processamento** lidam com o processamento de dados para consultas. Depois que o coordenador atribui tarefas, esses nós recuperam dados, realizam as operações necessárias, como uniões e agregações, e trocam dados intermediários com outros nós de processamento. Para obter mais informações, consulte [Processamento* na *documentação do Trino](https://trino.io/docs/current/overview/concepts.html#worker).
+ **Conectores** são plug-ins que permitem que o Trino se conecte a várias fontes de dados e as consulte. Cada conector sabe como acessar e recuperar dados de sua fonte, como Amazon S3, Apache Hive ou bancos de dados relacionais. Esses conectores mapeiam os dados de origem para a estrutura do esquema do Trino.
+ Um **catálogo** é uma coleção lógica de esquemas e tabelas associados a um conector específico. Definidos no coordenador, catálogos permitem que o Trino trate diferentes fontes de dados como um único namespace. Isso faz com que os usuários possam consultar várias fontes juntas, como Hive e MySQL, de maneira unificada na mesma consulta.
+ **Clientes** como a CLI do Trino se conectam por meio de drivers JDBC e ODBC ao coordenador do Trino para enviar consultas SQL. O coordenador gerencia o ciclo de vida das consultas, fornecendo resultados ao cliente para análises ou relatórios adicionais.
### Executar consultas
Para entender como o Trino usa instruções SQL e as executa como consultas, consulte [Conceitos do Trino](https://trino.io/docs/current/overview/concepts.html#query-execution-model), na *documentação do Trino*.
# Conceitos básicos do Trino
Os procedimentos nesta seção mostram como configurar um cluster do Amazon EMR para consultar as fontes de dados do metastore usando o Trino. Esses metastores, que incluem o AWS Glue Data Catalog, armazenam metadados e objetos de banco de dados e gerenciam permissões de acesso. Os procedimentos abrangem pré-requisitos, definições de configurações recomendadas, criação de conectores e execução de consultas em tabelas de metastore.
**Topics**
+ [Conclua as etapas de pré-requisitos para usar o Amazon EMR com o Trino](emr-trino-getting-started-pre.md)
+ [Iniciar um cluster do Amazon EMR com o Trino](emr-trino-getting-started-launch.md)
+ [Conectar-se ao nó primário do cluster do Amazon EMR e executar consultas](emr-trino-getting-started-connect.md)
# Conclua as etapas de pré-requisitos para usar o Amazon EMR com o Trino
Se você não usou ou não criou um cluster do Amazon EMR AWS, conclua essas etapas de pré-requisito antes de criar um cluster do Amazon EMR com o Trino.
## AWS configuração do ambiente
Conclua estas etapas para configurar sua AWS conta, caso ainda não tenha feito isso:
1. Crie uma AWS conta, caso ainda não tenha uma. Para obter mais informações, consulte [Criar uma AWSAWS conta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) *no Guia de referência de gerenciamento de contas*.
1. Faça login na sua conta como usuário administrativo.
1. Crie um grupo e atribua usuários a ele.
1. Crie um par de chaves do Amazon EC2, que você pode usar mais tarde para proteger a comunicação entre recursos com SSH. Essa etapa será necessária se você planeja se conectar ao nó primário para realizar tarefas. Para obter mais informações, consulte [Conecte-se ao nó primário do cluster do Amazon EMR usando SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html).
# Iniciar um cluster do Amazon EMR com o Trino
A seguir, são descritas as opções de configuração corretas ao criar um cluster com o Trino.
## Usar um conector do Hive para disponibilizar dados para consulta
Você pode configurar um conector do Trino para um metastore do Hive com o objetivo de consultar dados do metastore do seu cluster. Um metastore é uma camada de abstração que disponibiliza conteúdo ou dados baseados em arquivos como tabelas, facilitando a consulta. É necessário configurar um conector no Amazon EMR para disponibilizar as tabelas de metastore do Hive para o cluster. O procedimento a seguir mostra como fazer isso:
1. Escolha AWS Glue no console e crie uma tabela com base em seus dados de origem no Amazon S3. Uma tabela no AWS Glue Data Catalog é a definição de metadados para os dados. Nesse contexto, faz sentido gerar a tabela manualmente, criando colunas conforme desejar, a partir dos dados de origem. Para obter mais informações sobre a criação de tabelas no AWS Glue a partir de dados semiestruturados no Amazon S3, [consulte Criação de tabelas usando o console no Guia do](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#console-tables) usuário do *AWS Glue*.
1. Defina sua configuração como parte da criação do cluster. Selecione a guia **Configuração**. Configurações são especificações opcionais para o seu cluster. Ao inserir uma configuração, adicione JSON como no exemplo a seguir, que instrui Trino a usar o AWS Glue Data Catalog como seu metastore externo do Hive para metadados de tabelas:
```
{
"classification": "trino-connector-hive",
"properties": {
"hive.metastore": "glue"
}
}
```
Como alternativa, você pode aplicar configurações na seção **Configurações de software** ao criar um cluster.
Além disso, é possível configurar outros tipos de conectores, como para conexão com o Apache Iceberg. Para saber mais, consulte [Usar um cluster do Iceberg com Trino](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-trino-cluster.html), no *Guia de lançamento do Amazon EMR*. A configuração de definições adicionais é opcional.
Para continuar com as etapas iniciais, consulte [Conectar-se ao nó primário do cluster do Amazon EMR e executar consultas](emr-trino-getting-started-connect.md).
## Criar um cluster com o Trino
A seguir, são descritas as opções de configuração corretas ao criar um cluster que você deseja usar com o Trino.
**Importante**
Antes de criar seu cluster, conclua a configuração do AWS Glue Data Catalog como seu metastore do Hive, o que recomendamos para começar. Para obter mais informações, consulte [Usar um conector do Hive para disponibilizar dados para consulta](#emr-trino-getting-started-connect-hive).
1. No AWS console, selecione Amazon EMR nos serviços. Ao escolhe o Amazon EMR, se você tiver clusters existentes, seus clusters do **EMR no EC2** serão listados.
1. Selecione **Criar cluster**. A partir daqui, é iniciado o processo de criação de um cluster.
1. Dê um nome para o seu cluster e escolha uma **versão do Amazon EMR**. Para o tutorial, você pode escolher a versão mais atual.
1. Escolha o pacote **Trino**, que tem a aplicação Trino pré-selecionada. Pacotes são configurados para maior conveniência quando você sabe antecipadamente a finalidade do cluster. Caso contrário, basta marcar a caixa de seleção do Trino.
1. Em **Configuração do cluster**, escolha **Grupos de instâncias uniformes**. Vá em frente e remova os grupos de instâncias adicionais.
1. Escolha um **Tipo de instância**. Em geral, recomendamos escolher um tipo de instância com pelo menos 16 GiB de memória. Além disso, para **Ajuste de escala e provisionamento do cluster**, escolha **Definir tamanho do cluster manualmente**.
1. Neste ponto, defina a configuração da metastore do Hive para apontar para Glue. AWS Isso está detalhado na seção [Usar um conector do Hive para disponibilizar dados para consulta](#emr-trino-getting-started-connect-hive). Conclua essa etapa antes de criar o cluster.
1. Selecione **Criar cluster**. Ela pode demorar alguns minutos.
As etapas aqui descritas não abrangem todas as etapas de configuração em detalhes. Informações adicionais sobre a configuração de um cluster estão disponíveis em [Planejar, configurar e iniciar clusters do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html).
**nota**
Não selecione o Presto e o Trino para uso no mesmo cluster. Não há suporte para a execução simultânea. Também é recomendável que, se você executar o Trino, não execute nenhuma outra aplicação no cluster, como o Spark.
# Conectar-se ao nó primário do cluster do Amazon EMR e executar consultas
## Provisionar dados de teste e configurar permissões
Você pode testar o Amazon EMR com o Trino usando o AWS Glue Data Catalog e seu metastore Hive. Essas etapas de pré-requisitos descrevem como configurar dados de teste, caso você ainda não tenha feito isso:
1. Crie uma chave SSH para usar na criptografia de comunicação, caso ainda não tenha criado uma.
1. É possível escolher entre vários sistemas de arquivos para armazenar dados e arquivos de log. Para começar, crie um bucket do Amazon S3. Dê um nome exclusivo para o bucket. Ao criá-lo, especifique a chave de criptografia que você criou.
**nota**
Escolha a mesma região para criar seu bucket de armazenamento e o cluster do Amazon EMR.
1. Selecione o bucket que você criou. Escolha **Criar pasta** e atribua a ela um nome fácil de lembrar. Ao criar a pasta, escolha uma configuração de segurança. É possível escolher as mesmas configurações de segurança da pasta pai ou torná-las mais especializadas.
1. Adicione dados de teste à sua pasta. Para este tutorial, usar um .csv de registros separados por vírgula funciona bem para concluir esse caso de uso.
1. Depois de adicionar dados a um bucket do Amazon S3, configure uma tabela no AWS Glue para fornecer uma camada de abstração para consultar os dados.
## Conectar e executar consultas
A seguir, descrevemos estabelecer a conexão e executar consultas em um cluster executando o Trino. Antes disso, certifique-se de configurar o conector de metastore do Hive, descrito no procedimento anterior, para que as tabelas do metastore fiquem visíveis.
1. Recomendamos usar o EC2 Instance Connect para estabelecer a conexão com o cluster, pois ele fornece uma conexão segura. Escolha **Conectar-se ao nó primário usando SSH** no resumo do cluster. A conexão exige que o grupo de segurança tenha uma regra de entrada para permitir conexões pela porta 22 com clientes na sub-rede. Você também deve usar o usuário **hadoop** ao se conectar.
1. Inicie a CLI do Trino executando `trino-cli`. Isso permite executar comandos e consultar dados com o Trino.
1. Executar `show catalogs;`. Verifique se o catálogo **hive** está listado. Ele fornece uma lista de catálogos disponíveis, que contêm datastores ou configurações do sistema.
1. Para visualizar os esquemas disponíveis, execute `show schemas in hive;`. A partir daqui, é possível executar `use schema-name;` e incluir o nome do esquema. Em seguida, execute `show tables;` para listar tabelas.
1. Consulte uma tabela executando um comando como `SELECT * FROM table-name`, usando o nome de uma tabela no seu esquema. Se você já executou a `USE` instrução para se conectar a um esquema específico, não precisa usar a notação de duas partes, como. *schema* *table*.
# Configurar o Trino no Amazon EMR
**Topics**
+ [Configurar conectores para o Trino](#emr-trino-config-connector)
+ [Monitoramento](#emr-trino-monitoring)
## Configurar conectores para o Trino
### Conectando-se ao AWS Glue como sua metastore do Hive
É importante e útil entender que você pode configurar o AWS Glue Data Catalog como seu metastore do Hive ao executar consultas com o Trino. Para obter informações adicionais, incluindo etapas para configurar um cluster com um metastore do Hive, consulte Usando [o AWS Glue Data Catalog como metastore do](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) Hive.
Para obter informações sobre a integração do EMR no EKS com o AWS Glue, consulte as seguintes melhores práticas: integração de [contêineres do EMR](https://aws.github.io/aws-emr-containers-best-practices/metastore-integrations/docs/aws-glue/) com o Glue. AWS
### Conexão com tabelas do Iceberg ao usar o Trino com o Amazon EMR
O Iceberg é um formato de tabela aberta para tabelas analíticas. Ele foi criado para mecanismos como o Spark e o Trino consultarem big data das mesmas tabelas usando consultas SQL. Ele inclui recursos como isolamento de leituras e gravações de dados, para que um leitor possa evitar consultar dados parcialmente atualizados, por exemplo. Ele também oferece suporte a recursos de estado, como snapshots. Ele fornece uma camada de abstração por meio do uso de metadados e arquivos de manifesto. Estes últimos descrevem o esquema da tabela e facilitam a consulta de dados sem precisar saber muitos detalhes sobre como são formatados ou organizados. Quando você está conectado, pode ler dados de tabelas, atualizar dados ou gravar novos dados nos arquivos subjacentes.
Há um workshop disponível que mostra como configurar tabelas Iceberg com o Amazon EMR e o Glue AWS . Para obter mais informações, consulte [Workshop de analytics - configurar e usar tabelas do Apache Iceberg no seu data lake](https://youtu.be/SZDYmWIStUo?si=sW35AjSWIcHu5x_p).
### Estabelecer conexões com clientes
Você pode se conectar ao Trino usando um driver JDBC disponível. Para obter mais informações, consulte o [driver JDBC](https://trino.io/docs/current/client/jdbc.html) na *documentação do Trino*.
## Monitoramento
Você pode monitorar clusters do Amazon EMR por meio do. Console de gerenciamento da AWS Para obter mais informações, consulte [Visualizar e monitorar um cluster do Amazon EMR enquanto ele executa trabalhos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view.html). O Amazon EMR também envia suas métricas de monitoramento para o Amazon CloudWatch. Para obter mais informações sobre como monitorar um cluster do Amazon EMR, consulte [Eventos e métricas do Amazon CloudWatch a partir do Amazon EMR]().
# Praticas recomendadas para o Trino no Amazon EMR
A arquitetura do Trino foi projetada para consultas SQL rápidas e distribuídas em grandes conjuntos de dados em várias fontes de dados, seguindo um modelo de coordenador/trabalhador em que cada componente tem um papel específico na execução de consultas. Há algumas áreas ou categorias nas quais você pode se concentrar para configurar seu cluster do Amazon EMR executando o Trino para obter a melhor performance. Incluindo o seguinte:
+ Ajustar as configurações do cluster para otimização da memória.
+ Otimizar as configurações para particionamento e distribuição de dados.
+ Usar a filtragem dinâmica para reduzir a contagem de resultados de consultas.
Algumas dessas configurações são ajustadas automaticamente quando o Trino é usado com o Amazon EMR. Outras podem ser definidas manualmente por meio do console ou de comandos da CLI. Os tópicos desta seção ajudam a configurar seus dados e o cluster da maneira ideal.
**Topics**
+ [Principais áreas de foco para melhoria da performance](emr-trino-performance-areas.md)
+ [Coleta e utilização de estatísticas de tabelas](emr-trino-performance-areas-collect-stats.md)
+ [Desafios comuns ao escalar workloads do Trino](emr-trino-common-issues.md)
# Principais áreas de foco para melhoria da performance
O Trino maximiza o paralelismo de consultas e a otimização da memória. Essa arquitetura oferece flexibilidade ao permitir que ela consulte diversas fontes de dados variadas e, ao mesmo tempo, escale com eficiência. As principais áreas de melhoria de performance no Trino incluem as listadas abaixo.
## Otimização de memória
O gerenciamento de memória no Trino é fundamental para alcançar alta performance e estabilidade, especialmente ao executar consultas grandes e complexas. O Trino usa um modelo de memória distribuída. Nesse modelo, a memória é alocada entre nós de processamento para processar tarefas, agregações, uniões e outras operações. A lista a seguir apresenta uma coleção dessas configurações:
+ **query.max-memory**: define a memória máxima disponível para uma única consulta em todo o cluster. Esse é um limite fixo. Se uma consulta exceder essa memória, ela falhará.
+ **consulta. max-memory-per-node** — Define a memória máxima que uma consulta pode consumir em cada nó de trabalho. Essa configuração garante que nenhuma consulta monopolize os recursos de nenhum processamento.
+ **Tamanho do heap da JVM**: configurado no nível da JVM, define o tamanho máximo do heap para o processo do servidor Trino em cada nó. **Esse valor geralmente deve ser maior do que as configurações relacionadas à memória (essa é a soma da consulta). max-memory-per-node**e **memória. heap-headroom-per-node**) no Trino para evitar que o sistema fique sem memória no nível da JVM.
+ **memória. heap-headroom-per-node** — Especifica a quantidade de memória do buffer a ser omitida do tamanho do heap da JVM para operações que não sejam de consulta. Isso é crucial para garantir despesas gerais suficientes para operações internas e coleta de resíduos.
## Filtragem dinâmica
A filtragem dinâmica no Trino é uma técnica de otimização que melhora a performance das consultas ao reduzir a quantidade de dados processados, principalmente durante junções. Ela aplica condições de filtro dinamicamente para limitar os dados verificados por um lado de uma junção, com base nos dados vistos no outro lado, o que é especialmente útil em consultas em que um lado da junção é altamente seletivo (o que significa que contém um pequeno subconjunto de dados). Ela está habilitada por padrão no Amazon EMR. Veja a seguir um exemplo de consulta:
```
SELECT orders.order_id, orders.total_amount
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE customers.country = 'France';
```
Sem a filtragem dinâmica, o Trino verifica toda a tabela “orders” em uma junção, embora apenas um pequeno subconjunto de clientes (os da França) seja relevante. Essa abordagem lê todas as linhas na tabela de **pedidos**, resultando em altos I/O custos de processamento. Com a filtragem dinâmica, o Trino verifica inicialmente a tabela **customers** menor, recupera valores de customer\$1id somente para clientes da França e, em seguida, aplica esse subconjunto como um filtro à tabela “orders”. Isso significa que apenas as linhas relevantes em **orders**, aquelas com um customer\$1id correspondente ao subconjunto filtrado, são verificadas, o que reduz significativamente os registros processados.
## Vazamento para o disco
No Trino, o vazamento para o disco permite que resultados de consultas intermediárias sejam transferidos para o disco, o que possibilita a conclusão de consultas com uso intensivo de memória, mesmo que elas excedam os limites de memória definidos por `query_max_memory` ou `query_max_memory_per_node`. Por padrão, o Trino impõe esses limites para garantir a alocação justa de memória e evitar impasses do cluster. Porém, quando uma consulta grande ultrapassa esses limites, ela corre o risco de ser encerrada. O vazamento para o disco resolve isso com o uso de `revocable memory`, o que permite que uma consulta peça emprestado memória adicional que pode ser revogada se forem necessários recursos em outro lugar. Quando a memória é revogada, os dados intermediários vazam para o disco, permitindo que as consultas continuem a ser processadas sem excederem os limites de memória. Observe que uma consulta que é forçada a ser transferida para o disco pode ter um tempo de execução mais longo e, portanto, esse recurso está desabilitado por padrão. Para habilitar o vazamento no Amazon EMR, use a seguinte configuração:
+ `spill-enabled=true`: habilita o vazamento para o disco quando o uso da memória excede os limites disponíveis.
+ `spill-paths`: define os diretórios em que os dados vazados são armazenados, `spill-paths=/mnt/spill`.
# Coleta e utilização de estatísticas de tabelas
A coleta de estatísticas de tabelas permite que o otimizador baseado em custos do Trino tome decisões embasadas sobre ordens de junção, imposição de filtros e remoção de partições, resultando em melhor performance.
Você pode usar o comando `ANALYZE` para coletar estatísticas de tabelas do Hive ou Iceberg:
```
ANALYZE sales;
```
Coletar estatísticas em tabelas amplas pode sobrecarregar recursos. Recomendamos especificar um subconjunto de colunas usadas em junções, filtros ou operações de agrupamento.
Esse é outro comando útil. Ele exibe as estatísticas atuais de uma tabela para verificar se as estatísticas estão atualizadas.
```
show stats for table_name;
```
# Desafios comuns ao escalar workloads do Trino
Os principais benefícios de usar o Amazon S3 com o Trino são a capacidade do S3 de escalar para grandes volumes de dados e a relação custo-benefício do S3. Porém, quando grandes volumes de dados são consultados, vários problemas de performance relacionados pode acontecer de vez em quando. Isso pode resultar da maneira como os dados são armazenados, de configurações que limitam a boa performance ou outros motivos. Quando esses problemas ocorrem, existem medidas eficazes que você pode tomar para evitá-los ou mitigá-los.
Esta seção começa com uma lista de otimizações gerais que você pode implementar para aumentar a performance das consultas em grandes volumes de dados. Em seguida, os problemas comuns são detalhados, e mitigações são fornecidas para cada um.
Este tópico foi extraído da seguinte apresentação da conferência: [Acelerar a performance em grande escala: práticas recomendadas para o Trino com o Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ).
## Otimizar o layout dos dados para conjuntos de dados grandes
Gargalos de performance não são raros quando você está consultando grandes conjuntos de dados. Porém, existem práticas recomendadas que você pode implementar para ter uma vantagem inicial ao usar o Trino para consultar dados no Amazon S3. Incluindo o seguinte:
+ **Particionamento**: Particionamento significa organizar dados em uma hierarquia e armazenar dados relacionados juntos, com base em atributos relacionados. O particionamento faz com que as consultas não precisem verificar tantos dados irrelevantes, e isso resulta em uma melhor performance de consultas. É possível usar várias estratégias de particionamento, como organizar dados de origem com prefixos, especificamente por intervalos de datas, regiões ou outros atributos. Para obter informações mais detalhadas sobre dados de particionamento no Amazon S3 para aumentar o desempenho, consulte a [postagem do blog Comece a gerenciar partições para tabelas do Amazon S3 apoiadas AWS pelo Glue Data Catalog ou a](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) [postagem Top 10 Performance Tuning Tips](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) for. Amazon Athena
+ **Armazenamento em bucket**: armazenamento em bucket refere-se ao agrupamento de dados relacionados em arquivos comuns. Por exemplo, se você consulta dados de acordo com uma região geográfica, como um estado, pode aumentar a performance das consultas agrupando todos os dados de um determinado estado no mesmo arquivo ou grupo de arquivos. Para que isso funcione melhor, baseie seu agrupamento em um atributo de dados com alta cardinalidade, como um estado ou província, por exemplo. Além disso, você pode levar seus padrões de consulta em consideração. Um exemplo disso poderia ser agrupar os dados da Califórnia e do Oregon, se suas consultas normalmente leem dados desses estados juntos.
+ **Gerenciamento de prefixos do S3**: é possível usar prefixos do Amazon S3 para implementar uma estratégia de particionamento. Se você usar apenas um prefixo para um bucket do Amazon S3, como uma data específica, por exemplo, isso pode resultar em um grande número de solicitações e em um erro HTTP 503. Recomendamos o uso de prefixos para adicionar outras condições e organizar os dados de origem com mais eficiência. Para obter mais informações, consulte [Organizar objetos usando prefixos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html), na documentação do Amazon S3. O breve exemplo a seguir mostra um prefixo que resulta em um throughput de solicitações melhor: `s3://bucket/country=US/dt=2024-06-13`. Neste exemplo, o país e a data são incluídos no prefixo, o que resulta em menos leituras do que em um caso onde o prefixo inclui somente a data.
A mitigação de erros HTTP 503 é discutida com mais detalhes na seção sobre *desaceleração do HTTP* mais adiante.
+ **Otimizar o tamanho dos dados**: é possível executar o comando OPTIMIZE para definir uma configuração que resulte em consultas com melhor performance. Para executá-lo em tabelas externas do Hive, siga estas etapas:
+ Use `OPTIMIZE` com o seguinte parâmetro: `hive.non-managed-table-writes-enabled=true`. Para obter mais informações sobre essa propriedade, consulte [Propriedades gerais de configuração do Hive](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties).
+ Defina o seguinte parâmetro de sessão: `SET SESSION` `catalog.non_transactional_optimize_enabled=true`
+ Execute o comando `OPTIMIZE`: `ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`. Nesse caso, `file_size_threshold` é de 100 MB por padrão. Aumentar esse limite, como mostra o exemplo, fará com que arquivos abaixo de 128 MB sejam mesclados.
+ **Configurar novas tentativas**: é possível aumentar o limite de novas tentativas, o que pode reduzir a chance de erros HTTP 503, definindo o seguinte: `s3.max-error-retries`. Isso se aplica quando você usa a TrinoFileSystem API e a versão 449 do Trino ou posterior. Por outro lado, ao usar o Amazon EMR com Trino, você usa o EMRFS para acessar o Amazon S3. Com o EMRFS, é possível aumentar o número de retiradas alterando o parâmetro `fs.s3.maxRetries`.
+ **Escolha uma classe de armazenamento do Amazon S3**: escolher a classe de armazenamento apropriada para dados em diferentes pontos do ciclo de vida pode ajudar tanto na performance quanto no custo, com base nos seus requisitos para coleções de dados específicas. Para ter mais informações, consulte [Compreender e gerenciar classes de armazenamento do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm) na documentação do Amazon S3.
+ **Migrar para o Iceberg**: outra solução para mitigar problemas de performance, especificamente em relação à execução de consultas em arquivos pequenos, é migrar para tabelas do Iceberg. O Iceberg possui recursos que lidam bem com arquivos pequenos.
+ **Use compactação automática de dados** — Se você utiliza tabelas Iceberg, a compactação automática de dados com o AWS Glue Data Catalog pode otimizar o tamanho dos dados e resultar em melhor desempenho de consultas.
## Desafios comuns ao consultar conjuntos grandes de dados
Esta seção apresenta uma coleção de problemas comuns que podem ocorrer quando você acumula um grande conjunto de dados no Amazon S3 e o consulta com o Trino. Cada seção mostra maneiras de resolver o problema ou reduzir seu impacto nas consultas. Cada um dos problemas descritos nas seções a seguir foi reproduzido e testado usando um conector do Hive.
### Varreduras de dados grandes
Quando sua consulta precisa verificar grandes conjuntos de dados, isso pode resultar em problemas como baixa performance de consultas e maior custo de armazenamento. Volumes grandes de dados podem ser gerados devido a um rápido crescimento ou planejamento de dados que não resulta na movimentação de dados legados dentro de um cronograma adequado. Isso pode gerar consultas mais lentas.
Para reduzir o impacto na performance causado pela verificação de conjuntos de dados grandes, recomendamos o uso do particionamento e da compartimentação:
+ O particionamento agrupa dados relacionados com base em seus atributos. Usar o particionamento de maneira eficiente pode melhorar muito a performance das consultas.
+ Compartimentação refere-se ao agrupamento de dados em arquivos ou buckets de acordo com colunas de dados específicas e relacionadas. Em geral, a compartimentação significa manter fisicamente os arquivos de dados de origem relacionados juntos.
Para ilustrar como a atenuação pode funcionar para grandes verificações de dados, suponha que você armazene e consulte dados que tenham registros com um atributo de estado, que pode ser atribuído à Califórnia ou ao Alasca, e esse atributo de estado seja uma das suas condições de consulta. É possível melhorar a performance da consulta armazenando dados de cada estado em um bucket do S3 separado ou particionando seus dados com base no estado, usando um prefixo do S3. O particionamento e a compartimentação também podem melhorar a performance se você os basear em uma coluna adicional, como um atributo de data, por exemplo.
**nota**
Se uma coluna tiver alta cardinalidade e você quiser usá-la para agrupar dados, recomendamos o uso da compartimentação nesse caso. Por outro lado, geralmente, as chaves de partição devem ter menor cardinalidade.
**Usar vários tipos de armazenamento do S3**
Em geral, você escolhe os tipos de armazenamento com base nos requisitos de performance, acesso a dados, resiliência e custo para suas workloads. Pode haver compensações entre custo e performance. É importante escolher a classe de armazenamento apropriada do Amazon S3 que corresponda aos seus padrões de acesso a dados. Há dois padrões principais de acesso:
+ Dados que são acessados de forma conhecida ou previsível. Em geral, se você tem dados que são acessados com pouca frequência, o S3 Standard IA pode ser uma boa escolha, pois ajuda a reduzir os custos. Se você acessa dados com frequência, o S3 Standard é melhor para acessar com o Amazon EMR e o Trino.
+ Dados que são acessados de maneira desconhecida ou imprevisível. Isso pode exigir o uso de outras classes de armazenamento do Amazon S3. Há vantagens e desvantagens entre as classes de armazenamento do Amazon S3. Isso inclui latência, custo e disponibilidade de armazenamento. Você pode escolher um tipo de armazenamento do S3 apropriado, com base em suas workloads e padrões de acesso. Para obter descrições dos benefícios de cada classe, consulte [Classes de armazenamento do Amazon S3]().
**Usar a compactação**
Você também pode usar a compactação automática do Iceberg, se usar tabelas do Iceberg, o que resulta em tamanhos de arquivo mais otimizados, para aumentar a eficiência das consultas. Para obter mais informações, consulte [O Catálogo de dados do AWS Glue agora oferece suporte para a compactação automática de tabelas do Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Erros de lentidão de HTTP
Isso acontece quando a taxa de solicitação excede um limite pré-configurado em um prefixo do Amazon S3. O erro HTTP que ocorre com mais frequência quando esse estado é atingido é: **Erro 503: reduza sua taxa de solicitações**. A origem desse problema pode estar enraizada na presença de um grande número de arquivos pequenos, devido ao número de *divisões* que devem ser criadas para ler os dados. Há algumas maneiras de atenuar o problema:
+ Aumente o limite de novas tentativas para solicitações do Amazon S3 no Trino. Esse limite é definido para o EMRFS usando `fs.s3.maxretries` no Trino 449.
+ Otimize os tamanhos dos arquivos, o que também pode resultar em uma menor taxa de solicitações.
Para obter mais informações sobre como o Trino determina o número de divisões em um conjunto de dados a serem consultados, consulte [Propriedades de configuração de ajuste da performance](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties), na documentação do conector do Hive.
### Dificuldade em consultar arquivos pequenos
Consultar muitos arquivos pequenos pode resultar em uma I/O sobrecarga pesada, devido ao alto número de solicitações GET e LIST, e, consequentemente, afetar negativamente o desempenho da consulta. A otimização do tamanho dos arquivos pode melhorar a performance das consultas. Existem algumas maneiras de fazer isso:
+ Consolide os dados em menos arquivos maiores. (Em geral, recomendamos manter tamanhos de arquivos em torno de 128 MB.) Isso pode ser feito com ferramentas ao ingerir dados, como em um pipeline de ETL, ou você consolidar dados manualmente. Se essas soluções não estiverem disponíveis para você, as opções restantes poderão ser mais adequadas.
+ Execute o comando `OPTIMIZE`.
+ Defina o parâmetro `SESSION`.
Observe que o Iceberg tem um recurso disponível para mesclar arquivos pequenos em arquivos maiores, que é a compactação automática. Ele funciona com arquivos gerenciados com o AWS Glue Data Catalog. Para obter mais informações, consulte [O Catálogo de dados do AWS Glue agora oferece suporte para a compactação automática de tabelas do Apache Iceberg](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/).
### Consultas que incluem dados que não são necessários
É comum que os dados cresçam, o que torna imperativo rastrear seus padrões de acesso aos dados e movê-los adequadamente à medida que envelhecem ou se tornam irrelevantes. Isso ocorre porque, à medida que os dados aumentam, a performance da consulta pode diminuir com o tempo, principalmente devido ao grande volume de dados a serem verificados quando uma consulta é executada. O Amazon S3 e outros serviços oferecem orientação para a migração do ciclo de vida dos dados, que mostra estratégias para mover dados para diferentes locais de armazenamento à medida que esfriam. Também há um benefício de custo de armazenamento em fazer isso.
Além da migração de dados, você pode usar outras estratégias, como remover dados de origem que não são relevantes para as consultas que você está executando. Isso pode dar um certo trabalho, pois pode significar alterar seu esquema de dados de origem. Porém, seu resultado positivo é reduzir o volume de dados e resultar em consultas mais rápidas. Para mais informações, consulte [Gerenciar o ciclo de vida dos objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html).
# Considerações sobre o Trino
Considere o seguinte ao executar o Trino no Amazon EMR.
## Propriedades de implantação do Trino não configuráveis
A tabela a seguir mostra as diferentes opções de configuração para arquivos de `properties` do Trino.
| Arquivo | Configurável |
| --- | --- |
| `log.properties` | Trino: configurável nas versões 6.1.0 e posteriores do Amazon EMR. Use a classificação de configuração `prestosql-log` ou `trino-log`. |
| `config.properties` | Trino: configurável nas versões 6.1.0 e posteriores do Amazon EMR. Use a classificação de configuração `prestosql-config` ou `trino-config`. |
| `hive.properties` | Trino: configurável nas versões 6.1.0 e posteriores do Amazon EMR. Use a classificação de configuração `prestosql-connector-hive` ou `trino-connector-hive`. |
| `node.properties` | Trino: configurável nas versões 6.1.0 e posteriores do Amazon EMR. Use a classificação de configuração `prestosql-node` ou `trino-node`. |
| `jvm.config` | Não configurável. |
## Considerações adicionais
+ Para o Trino nas versões 6.1.0 e posteriores do EMR, o Amazon EMR configura automaticamente uma chave secreta compartilhada para comunicação interna segura entre os nós do cluster. Você não precisa fazer qualquer configuração adicional para habilitar esse atributo de segurança e pode substituir a configuração com sua própria chave secreta. Para obter informações sobre a autenticação interna do Trino, consulte a [documentação do Trino 353: Proteger a comunicação interna](https://trino.io/docs/current/security/internal-communication.html).
# Histórico de lançamentos do Trino
As seções de notas de lançamento detalham as alterações e atualizações de uma versão específica do Trino no Amazon EMR.
## Notas da versão do Trino por versão
+ [Amazon EMR 7.6.0 - Notas da versão do Trino](Trino-release-history-760.md)
+ [Amazon EMR 7.3.0 - Notas da versão do Trino](Trino-release-history-730.md)
+ [Amazon EMR 6.9.0 - Notas da versão do Trino](Trino-release-history-690.md)
# Amazon EMR 7.6.0 - Notas da versão do Trino
## Amazon EMR 7.6.0 - Novos atributos do Trino
+ Para dar suporte a consultas de longa execução, o Trino agora inclui um mecanismo de execução tolerante a falhas. A execução tolerante a falhas atenua as falhas nas consultas ao tentar novamente as consultas com falha ou as tarefas dos seus componentes.
## Amazon EMR 7.6.0 - Mudanças no Trino
**Amazon EMR 7.6.0 - Mudanças no Trino**
| Tipo | Description |
| --- | --- |
| Upgrade | Upgrade do Trino para 457 |
# Amazon EMR 7.3.0 - Notas da versão do Trino
## Amazon EMR 7.3.0 - Mudanças no Trino
+ Essa versão atualiza o Trino da versão 436 para a 442.
+ Essa versão redireciona as consultas do Hudi para o novo corretor do Hudi. O antigo conector do Hive não consegue mais ler tabelas do Hudi. Observação
+ Essa versão remove o módulo Rubix do Amazon EMR porque ele já está obsoleto do código aberto.
+ Essa versão [remove o modo legado](https://github.com/trinodb/trino/pull/21013) na propriedade `hive.security`. O padrão agora é `allow-all`.
# Amazon EMR 6.9.0 - Notas da versão do Trino
## Amazon EMR 6.9.0 - Novos atributos do Trino
+ Para dar suporte a consultas de longa execução, o Trino agora inclui um mecanismo de execução tolerante a falhas. A execução tolerante a falhas atenua as falhas nas consultas ao tentar novamente as consultas com falha ou as tarefas dos seus componentes.
## Amazon EMR 6.9.0: alterações no Trino
**Amazon EMR 6.9.0: alterações no Trino**
| Tipo | Description |
| --- | --- |
| Upgrade | Atualização do Trino para 398 |
| Upgrade | Suporte para Hadoop 3.3.3 |
| Recurso | Suporte ao Tardigrade: adicione suporte para spooling de troca no HDFS e no Amazon S3. |
| Correção de bugs | Quando o Iceberg do Trino é usado e o catálogo do Glue está habilitado, evite adicionar o uri do metastore em `iceberg.properties.` |
## Amazon EMR 6.9.0 - Problemas conhecidos do Trino
+ Para a versão 6.9.0 do Amazon EMR, o Trino não funciona em clusters habilitados para o Apache Ranger. Se você precisar usar o Trino com o Ranger, entre em contato com o [Suporte](https://console.aws.amazon.com/support/home#/).