Configuração do Trino

O que é o Trino?

O Trino (antigo PrestoSQL) é o motor de consulta SQL distribuída do TDP.

Ele permite fazer queries em múltiplas fontes de dados com um único comando SQL — você pode unir uma tabela do ClickHouse com uma tabela do Iceberg no Ozone em um único SELECT, sem mover dados.

O Trino não armazena dados próprios: ele é um query engine federado.

Todo dado lido ou escrito pelo Trino vem de fontes externas chamadas catálogos.

Cada catálogo aponta para uma fonte de dados (Hive/Iceberg no Ozone, ClickHouse, PostgreSQL, Kafka) e usa um connector específico.

Para saber mais

Consulte Trino — Conceitos para uma visão completa da ferramenta, sua arquitetura e funcionamento.

Arquitetura coordinator-worker

O Trino funciona com um modelo coordinator + workers:

Componente	Função
Coordinator	Recebe a query SQL, cria o plano de execução e distribui o trabalho
Workers	Executam as partes do plano em paralelo, processando dados das fontes

Você não escala o coordinator — ele é sempre um.

Você escala os workers (trino.server.workers) para aumentar paralelismo.

Em produção, configure autoscaling (trino.server.autoscaling) para que os workers escalem conforme a carga.

Esta página descreve a configuração do Trino no TDP Kubernetes. O chart tdp-trino implanta o coordenador, workers e catálogos configuráveis para consultas SQL distribuídas.

Visão geral

Propriedade	Valor
Chart	tdp-trino
Versão do Trino	478
Versão do Chart	3.0.0
Registry (exemplos)	oci://registry.tecnisys.com.br/tdp/charts/tdp-trino

Instalação

Exemplo

helm install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-trino \
  -n <namespace> --create-namespace

Nomes de recursos seguem o release Helm; é possível ter várias instâncias no cluster com releases diferentes.

Parâmetros principais (chart)

Parâmetro	Descrição	Padrão típico
trino.enabled	Habilitar Trino	true
trino.image.tag	Tag da imagem	Ver helm show values
trino.server.workers	Réplicas de worker	2
trino.server.node.environment	Rótulo de ambiente Trino	Placeholder no values
trino.service.port	Porta do serviço	8080
trino.ingress.enabled	Ingress	false
trino.server.autoscaling.enabled	HPA nos workers	false
trino.server.keda.enabled	KEDA nos workers	false
trino.jmx.enabled	JMX	false
trino.serviceMonitor.enabled	ServiceMonitor	false
trino.accessControl	Controle de acesso (opcional)	{}
trino.catalogs	Definições de catálogo	Ex.: tpch / tpcds / memory (ver values.yaml)
trinoCerts.pvc.enabled	PVC para certificados	false
trinoCerts.secret.enabled	Secret com certificados	false
trinoCerts.copyJob.enabled	Job pré-install para copiar certificados ao PVC	false

Catálogos (connectors)

Os catálogos ficam em trino.catalogs. Para habilitar um connector, adicione uma entrada no formato de propriedades, seguindo os exemplos do values.yaml do chart.

Exemplo genérico (PostgreSQL — ajuste host, banco e credenciais):

trino:
  catalogs:
    postgresql: |
      connector.name=postgresql
      connection-url=jdbc:postgresql://<db-host>:5432/<database>
      connection-user=<user>
      connection-password=<password>

Exemplo de catálogo em memória:

trino:
  catalogs:
    memory: |
      connector.name=memory

Aplique com helm upgrade usando seu arquivo de values ou -f.

TLS e certificados (trinoCerts)

Quando for necessário HTTPS ou keystore (por exemplo com LDAP ativado), o chart pode:

• provisionar um PVC (trinoCerts.pvc)
• referenciar um Secret com arquivos (trinoCerts.secret)
• executar um Job antes do install/upgrade para copiar do Secret para o PVC (trinoCerts.copyJob)

Detalhes exatos de montagem e nomes de chaves estão no values.yaml do chart.

LDAP e HTTPS

Com ldap.enabled: false (padrão): HTTP na porta 8080, sem autenticação obrigatória.

Com ldap.enabled: true e values de LDAP: HTTPS na porta 8443, autenticação PASSWORD, volumes de certificado e secrets associados.

Passos e exemplos de values estão em Segurança — Trino. Ingress com LDAP costuma exigir TLS passthrough — veja Ingress — Trino.

Conectar ao Trino

O nome DNS do serviço Kubernetes costuma ser o nome do release ou o definido pelo chart; confira com:

kubectl -n <namespace> get svc

Mesmo namespace

• Host: <nome-do-serviço-trino>
• Porta HTTP: 8080 (sem LDAP)
• Porta HTTPS: 8443 (com LDAP, conforme configuração)

Outro namespace

• Host: <nome-do-serviço-trino>.<namespace>.svc.cluster.local

Exemplos

Python (trino client):

import trino

conn = trino.dbapi.connect(
    host="<nome-do-serviço-trino>",
    port=8080,
    user="<user>",
    catalog="tpch",
    schema="tiny",
    http_scheme="http",
)

CLI:

trino --server http://<nome-do-serviço-trino>:8080 \
      --user <user> \
      --catalog tpch \
      --schema tiny

Acesso local (port-forward)

kubectl -n <namespace> port-forward service/<release> 8080:8080

(Com LDAP/HTTPS, use a porta 8443 no mapeamento se for o caso.)

Escalonamento

O Trino usa um coordenador e vários workers. O número de workers é controlado por trino.server.workers ou recursos de autoscaling no values.yaml, conforme suportado pelo chart — não escale o coordenador para mais de uma réplica.

Resolução de Problemas

kubectl -n <namespace> get pods
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Desinstalação

helm uninstall <release> -n <namespace>

Para a lista completa de parâmetros, consulte o values.yaml do chart.