Trino

Cómo funciona

Un coordinador planifica las consultas y trabajadores distribuidos ejecutan fragmentos. Los catálogos configuran conectores a cada fuente. Parte del filtrado puede ejecutarse en el origen cuando el conector lo permite.

Ejemplo: combinar PostgreSQL e Iceberg

Con ambos catálogos configurados y estos esquemas disponibles:

SELECT c.segmento, sum(v.importe) AS total
FROM postgres.crm.clientes AS c
JOIN lakehouse.ventas.operaciones AS v
  ON c.id = v.cliente_id
GROUP BY c.segmento;

Configurar catálogos

# etc/catalog/postgres.properties
connector.name=postgresql
connection-url=jdbc:postgresql://replica-crm:5432/crm
connection-user=trino_ro
connection-password=${ENV:PG_PASSWORD}

# etc/catalog/lakehouse.properties
connector.name=iceberg
iceberg.catalog.type=rest
iceberg.rest-catalog.uri=https://catalogo.internal/api/catalog
fs.native-gcs.enabled=true

Cada archivo es un catálogo, y las tablas se nombran como catalogo.esquema.tabla. Hay conectores para PostgreSQL, MySQL, SQL Server, Oracle, Iceberg, Delta Lake, Hive, BigQuery, Kafka, Elasticsearch, MongoDB, Google Sheets y muchos más.

Leer un plan de ejecución

EXPLAIN ANALYZE
SELECT c.segmento, sum(v.importe)
FROM postgres.crm.clientes c
JOIN lakehouse.ventas.operaciones v ON c.id = v.cliente_id
WHERE v.fecha >= DATE '2026-09-01'
GROUP BY c.segmento;

Busca en el plan qué filtros se delegaron a la fuente (pushdown), cuántas filas lee cada TableScan y el tipo de join. El dynamic filtering aprovecha los valores del lado pequeño del join para reducir lo que se lee del lado grande.

Rendimiento

Técnica	Efecto
Particionado y orden en Iceberg	Menos archivos leídos con filtros por fecha
Estadísticas (ANALYZE)	Mejores decisiones de join y orden
Formatos columnares (Parquet, ORC)	Solo se leen las columnas necesarias
Evitar SELECT *	Reduce lectura y transferencia
Agregados materializados	Tablas de resumen para dashboards muy consultados

Operación

• Resource groups: limitan concurrencia y memoria por usuario o tipo de consulta (dashboards frente a ETL).
• Ejecución tolerante a fallos (retry-policy=TASK con exchange manager sobre almacenamiento de objetos): las consultas largas sobreviven a la pérdida de un worker; útil para ETL, con algo de sobrecoste.
• Control de acceso: reglas por archivo, Open Policy Agent o Apache Ranger, además de los permisos del usuario técnico de cada conector.
• Autenticación: OAuth2/OIDC, LDAP, certificados.

Ecosistema

Trino es la base de Amazon Athena y de Starburst (distribución comercial). Encaja como motor SQL de un lakehouse sobre Apache Iceberg, y como fuente de herramientas de BI como Metabase. Para consultas de muy baja latencia sobre eventos, ClickHouse suele ser más adecuado.

Criterios de implementación

Filtra pronto y observa qué operaciones pueden delegarse al origen. Limita concurrencia y consumo para no saturar bases operativas. Define identidad y permisos en cada catálogo; una consulta federada no elimina los límites de acceso de las fuentes.