Trino como sustrato de cómputo de la plataforma — la vía de la industria

1 · La topología de referencia (lo que hace la industria, no lo que nos apetece)

                    clientes (SQL Editor · Junction · BI · notebooks)
                                      │  una sola URL
                                      ▼
                          ┌───────────────────────┐
                          │    TRINO GATEWAY      │  routing por reglas · blue/green
                          └───────────┬───────────┘  · health · historial
                    ┌─────────────────┼─────────────────┐
                    ▼                 ▼                 ▼
             cluster INTERACTIVO  cluster ETL      cluster BI
             (concurrencia media) (pocas, pesadas) (muchas, simples)
                    │                 │                 │
                    └────────┬────────┴─────────────────┘
                             ▼
                  catálogo Iceberg REST  ──▶  ⭐ NUESTRA CARA (`/api/iceberg`)
                             │                    grants · access_events · políticas
                             ▼
                        Lakekeeper  ──▶  R2 (credencial acuñada por tabla)

Nadie corre un cluster Trino. Netflix opera 15+ (>10 M queries/mes, >1 M tablas Iceberg); Lyft mueve ~250 K queries/día y ~10 PB/día leídos; Expedia corre tres clusters especializados por perfil de carga con el Gateway delante. Lo que se adopta no es un motor: es una flota.

2 · Las seis piezas, y ninguna es opcional en producción

2.1 · Orquestación — Kubernetes, y operador antes que Helm suelto

Para nosotros gana el operador, y por una razón que es nuestra: con TrinoCatalog como objeto declarativo, «un catálogo por warehouse de inquilino» deja de ser un fichero de propiedades y pasa a ser un recurso de Kubernetes que se crea con el alta de la organización. Es la pieza que encaja con la decisión de P2 (un catálogo = un warehouse).

⚠️ El Helm oficial tiene huecos documentados que hay que cubrir aparte: no cubre autoscaling, ni secretos/TLS, ni exchange manager, ni HA. Y su único aviso explícito de producción: «Trino works best with fewer pods each having more resources available» — nada de muchos pods pequeños, y nunca dos pods de Trino en el mismo host físico.

2.2 · Frontal — Trino Gateway

Una sola URL para todos los clientes, enrutado por reglas (tabla grande → cluster pesado; show catalogs → cluster de un nodo; cabecera X-Trino-Source → cluster de BI), upgrades blue/green sin downtime y estados de salud. Nació en Lyft como Presto Gateway. Sin él, cada cambio de versión es una ventana de caída y cada carga pesada envenena a las interactivas.

2.3 · Seguridad — el orden importa y no admite «tres de cuatro»

⭐ La ⑤ es la que convierte a Trino en el motor gobernado, y es donde nuestra arquitectura ya está más cerca que de costumbre: la gobernanza deja de estar al lado del camino y pasa a estar en el camino, que es la diferencia con Databricks que warehouse-index.md §2 lleva señalando desde el principio.

2.4 · Resiliencia — fault-tolerant execution con exchange manager

Spooling de los intercambios a almacenamiento externo (S3/R2) para que la caída de un worker no mate la query. Es lo que hace viable el cluster de ETL. Sin FTE, una query larga es una apuesta.

2.5 · Elasticidad — autoescalado por cola, no por CPU

KEDA sobre queries encoladas + presión de memoria (el patrón que documenta BESTSECRET), o el autoscaler del operador. Escalar por CPU en un motor que se pasa la vida esperando a la red del storage mide lo que no es.

2.6 · Catálogos — contra nuestra cara, nunca contra Lakekeeper

Un TrinoCatalog por warehouse de inquilino, apuntando a /api/iceberg. El orden inverso funciona igual de bien el primer día y deja una puerta trasera para siempre.

⚠️ catalog.management=dynamic + CREATE CATALOG existe, pero es experimental y loguea la sentencia completa —credenciales incluidas— en la Web UI. Para altas automáticas, el CRD del operador, no SQL.

3 · Dónde vive

Railway no llega: coordinador + N workers + spooling + gateway + autoescalado no es «un servicio más» en cozy-comfort. Es un plano de infraestructura distinto.

Candidato natural GKE — ya tenemos presencia en GCP (la VM de OpenMetadata). Las alternativas son EKS o un Trino gestionado (Starburst Galaxy, Dataproc), que cambian coste de ingeniería por coste de licencia y por menos control sobre la cara abierta.

4 · Lo que cuesta de verdad, dicho antes de empezar

1. Un cluster de Kubernetes que alguien mantiene.
2. Un operador, un gateway y sus upgrades.
3. Certificados, un realm y clientes de Keycloak, políticas de OPA.
4. Un bucket de exchange para FTE.
5. El impuesto de la equivalencia: equivalence.ts tiene 25 sondas y dos brazos. Con tres motores divergen en silencio. El tercer brazo es requisito para servir tráfico, no para registrar el adaptador.
6. Carbon SQL se re-mide entero. Todo el pilar M0-M6 descansa en «parser y ejecutor son el mismo binario». Con Trino el binario es otro: el pin de extensiones, la estrictez ANSI declarada, errors_as_json y SUPPORT_NESTED_NAMESPACES se vuelven a levantar contra su dialecto (que sí soporta namespaces anidados desde la 463, con nested-namespace-enabled=true y comillas obligatorias).
7. Guardia. Netflix: 15 clusters. Expedia: 3 + gateway.

5 · Fases, con el mismo criterio que P1-P4

T1 · El cluster mínimo, de verdad (no la VM)

Operador Stackable en GKE · un TrinoCluster interactivo · TLS + shared secret · un TrinoCatalog contra /api/iceberg.

• Gate: SELECT sobre una tabla real por la cara, y el control negativo — sin credenciales, 401; un CREATE TABLE, denegado.

T2 · Identidad y política

OIDC contra Keycloak para usuarios · JWT para Junction · bridge OPA de Lakekeeper.

• Gate: el mismo control negativo de P1-P3 de storage — con el motor sirviendo a la organización A, un intento explícito contra B falla en el motor, no por ausencia de referencia.

T3 · El adaptador sirve tráfico

TRINO_URL puesta ⇒ lib/compute/engines/trino.ts deja de ser inerte.

• Gate BLOQUEANTE: el tercer brazo de equivalence.ts, y features poblado midiendo.

T4 · La flota

Gateway + clusters por perfil + FTE + KEDA.

• Gate: una regla de enrutado en producción y un upgrade blue/green sin downtime.

T5 · Retirar el Trino de la VM de OM

Repuntar la ingesta de OpenMetadata al cluster nuevo y apagar el docker-compose.

• Gate: el perfilado sigue dando números, y docker compose ps no lista Trino.

6 · Lo que este approach NO decide

• GKE vs EKS vs gestionado — depende de coste y de quién opera, no de arquitectura.
• El tamaño y el número de clusters — sale de una prueba de carga, no de una tabla.
• Si Trino sustituye a DuckDB o convive — hoy conviven: DuckDB es imbatible en el tramo pequeño e interactivo, y ése es el 100 % del tráfico actual. La convivencia se decide con el tercer brazo del comparador delante, no antes.

Approach vivo. Cada fase que aterrice actualiza este doc con lo MEDIDO, no con lo previsto.