Service Trino - thekaveh/atlas GitHub Wiki
Trino is an optional, disabled-by-default SQL query engine for the Data Engineering track. Atlas wires Trino to the Iceberg REST catalog and the MinIO lakehouse buckets. Notebooks, Zeppelin, Airflow tasks and local tools can then query the same tables in SQL.
Image: trinodb/trino:482.
Atlas runs one coordinator, one lakehouse catalog and no workers. The catalog uses Iceberg REST for table metadata and MinIO for objects, the same path Spark uses.
| Surface | URL | Notes |
|---|---|---|
| Kong | http://trino.localhost:${KONG_HTTP_PORT} |
Routed only when TRINO_SOURCE=container, behind Kong dashboard basic auth. Kong removes the credential before forwarding, because Trino rejects any password over plain HTTP. The coordinator sets http-server.process-forwarded=true (in JAVA_TOOL_OPTIONS) so it accepts Kong's X-Forwarded-* headers instead of answering 406. |
| Direct | http://localhost:${TRINO_PORT} |
Coordinator UI and HTTP API, with no authentication. Bound through HOST_BIND_IP (default 127.0.0.1:, loopback only). |
| In-network | http://trino:8080 |
Use from notebooks, Zeppelin JDBC, Airflow tasks, and other containers. |
TRINO_SOURCE=disabled # container | disabled
TRINO_IMAGE=trinodb/trino:482
TRINO_PORT= # topology-assigned
TRINO_SCALE= # set by ./start.sh from TRINO_SOURCETRINO_SOURCE=container also needs MINIO_SOURCE=container and ICEBERG_REST_SOURCE=container. If either is disabled, ./start.sh reports a dependency violation and scales Trino to 0.
The mounted catalog file at services/trino/catalog/lakehouse.properties defines:
connector.name=icebergiceberg.catalog.type=resticeberg.rest-catalog.uri=http://iceberg-rest:8181-
iceberg.rest-catalog.warehouse=s3://${ENV:MINIO_BUCKET_ICEBERG_LAKEHOUSE}/(the bucket iceberg-rest, Spark and minio-init use; defaultlakehouse) -
fs.native-s3.enabled=truefor Trino 482 native S3 access to MinIO athttp://minio:9000 - scoped Iceberg MinIO credentials through
${ENV:MINIO_ICEBERG_ACCESS_KEY}and${ENV:MINIO_ICEBERG_SECRET_KEY}
Atlas runs Trino with no Trino authenticator configured. The example user atlas is a convention shared by Atlas notebooks and clients, not an authentication boundary: the local coordinator accepts any user string. Do not use this setup as access control.
Minimal SQL smoke once Spark or another writer has created tables:
SHOW CATALOGS;
SHOW SCHEMAS FROM lakehouse;
SHOW TABLES FROM lakehouse.bronze;
SELECT * FROM lakehouse.bronze.<table_name> LIMIT 10;Atlas seeds a Zeppelin JDBC interpreter when both ZEPPELIN_SOURCE=container and TRINO_SOURCE=container. Use the named Zeppelin 0.12.1 prefix %trino:
%trino
SHOW TABLES FROM lakehouse.bronze;
The seeded profile uses jdbc:trino://trino:8080/lakehouse, driver io.trino.jdbc.TrinoDriver and Maven artifact io.trino:trino-jdbc:482. Atlas registers it as the named interpreter %trino, not as a %jdbc(prefix) profile.
Python clients inside the Docker network can use the official trino DB-API package:
import trino
conn = trino.dbapi.connect(
host="trino",
port=8080,
user="atlas",
catalog="lakehouse",
schema="gold",
)
cur = conn.cursor()
cur.execute("SHOW SCHEMAS FROM lakehouse")
print(cur.fetchall())Host-side Python clients use the assigned host port:
import os
import trino
conn = trino.dbapi.connect(
host="localhost",
port=int(os.environ["TRINO_PORT"]),
user="atlas",
catalog="lakehouse",
schema="gold",
)Live CTAS smoke after the lakehouse path is up:
CREATE SCHEMA IF NOT EXISTS lakehouse.gold;
CREATE TABLE lakehouse.gold.atlas_trino_ctas_smoke AS
SELECT 1 AS id, 'atlas' AS note;
SELECT * FROM lakehouse.gold.atlas_trino_ctas_smoke;
DROP TABLE lakehouse.gold.atlas_trino_ctas_smoke;Atlas does not create bronze/silver/gold namespaces at stack startup; a downstream project or the operator owns those namespaces. The CREATE SCHEMA line is part of the live smoke only.
Support tier: experimental — Capability contract declared; no cited cold-start, workflow, or upgrade qualification run yet (evidence at v0.1.0).
| Capability | Status | Verification | Notes |
|---|---|---|---|
| SQL over the Atlas Iceberg lakehouse | supported | tested | Atlas configures Trino's Iceberg REST catalog, MinIO S3 access, and required service ordering for querying the in-stack lakehouse. |
| Coordinator access control | partial | tested | Kong applies Basic authentication to the browser route, but the directly published coordinator has no Trino authenticator and accepts operator-supplied user names. |
| Distributed multi-catalog query cluster | not-supported | documented | The stock deployment is one coordinator with no workers and one Iceberg catalog; Atlas does not provision clustered execution or additional federation catalogs. |
-
Catalog missing: confirm
ICEBERG_REST_SOURCE=containerand thaticeberg-restis healthy before Trino starts. -
S3 access denied: confirm
minio-initcompleted (it creates theicebergservice account) and.envhas non-emptyMINIO_ICEBERG_ACCESS_KEY/MINIO_ICEBERG_SECRET_KEY. -
Kong alias does not load: run
./start.sh --setup-hostssotrino.localhostresolves locally.
| Service | Category |
|---|---|
| iceberg-rest | data |
| minio | data |
| Service | Category |
|---|---|
| kong | infra |
| zeppelin | apps |

Open the full-size diagram for a full-screen view.
Add richer notebook examples that create a Spark-written Iceberg table and query it through Trino.
Superset or another BI UI can sit downstream of Trino once the lakehouse query path is stable.
Worker scaling, query resource groups, access-control files and additional catalogs are out of scope.