El mapa del cómputo — Spark, el cluster y la paridad

1 · El pipeline completo — de la tecla al Parquet

  ① NAVEGADOR · CarbonSqlEditor.tsx
     el usuario escribe SQL · Monaco (pgsql) · Idempotency-Key por intento
                    │  POST /api/sql-editor/execute
                    ▼
  ② SUPERFICIE · app/api/sql-editor/execute  (Vercel · Next.js)
     Clerk da el principal · gramática de catálogo (¿es DDL curado?)
     clasifica lectura/escritura · DECLARA el destino (no lo parsea)
                    │  runQuery(sql, principal, { writeTarget })
                    ▼
  ③ ⭐ LA PUERTA · lib/compute/junction.ts   ← la política vive aquí
     catálogo lógico → plan físico → TENENCIA TABLA POR TABLA
     elige motor · abre la txn del LEDGER (durable, ANTES de ejecutar)
                    │  HTTPS + JWT (HS256, TTL 120 s)
                    ▼
  ④ EL PUENTE · services/spark-bridge  (GKE, 1 réplica)
     HTTP entra, gRPC sale · POOL DE SESIONES CALIENTES por inquilino
     (LRU 8 · 30 min · AuthManager que refresca el token en 2º plano)
                    │  gRPC Spark Connect
                    ▼
  ⑤ EL MOTOR · carbon-connect-server-0 + 2 executors  (Spark 4.1.2)
     parsea, planifica, ejecuta · para leer/escribir pide la tabla al catálogo
                    │  Iceberg REST  ──►  CATALOG_URI=app.paladio.io/api/iceberg
                    ▼
  ⑥ ⭐ LA CARA · app/api/iceberg/v1/[...path]  ← el catálogo GOBERNADO
     autoriza (Index) · comprueba el prefijo del inquilino · resuelve
     `diets` ↔ `ds_<uuid>` · FIRMA el commit · acuña credencial acotada
                    │
                    ▼
  ⑦ LAKEKEEPER (Railway) → STS 900 s → ⑧ CLOUDFLARE R2 (Parquet + metadata)
                    │
                    └──► de vuelta: ⑥ anota `access_events` · ③ cierra el ledger

Lo que hace especial a este camino, en una frase por pieza:

⇒ Dos puertas y una cintura. La puerta del producto (③) y la puerta de los motores (⑥); entre ellas, todo lo que es dato pasa por Iceberg + Lakekeeper.

El viaje del UPDATE main.default.diets que ejecutaste

txn 7f55f64c  UPDATE committed  row_count=5  ventana 10.868 ms
   engine=spark · attributable=true · attribution=exclusive
   write_target=main.default.`diets`
   landed=true · snapshot=8478955347166888000     ⇒ RECONCILIABLE
   snapshots 1 → 2 · filas 5 → 5

⛔ Y lo único que NO es correcto: rowsAffected: 0. Afectó 5. Es un defecto conocido y acotado: sparkEngine.runQuery no devuelve commit, y la puerta hace r.commit?.rows ?? 0. Spark no devuelve filas afectadas en un DML por SQL, así que el arreglo honesto no es inventar el número: es devolver null y que la UI muestre «—». Un 0 dice «no afectó nada», que es falso; un — dice «el motor no lo reporta», que es cierto. El total sí lo sabemos (el ledger apunta row_count=5, preguntado al catálogo).

2 · ⭐⭐⭐ ¿Es Rubix la referencia? Sí — y dice lo contrario de lo que parece

La intuición es buena y la fuente lo confirma… pero invierte la conclusión.

⇒ Rubix es la MALLA, no el motor. Lo que Palantir centralizó fue dónde y cómo se ejecuta, no con qué. Y la prueba está en su propia guía de elección de motor:

Y lo dicen sin rodeos: «Spark tiene más overhead para operaciones pequeñas».

⇒ Lo que esto significa para nosotros

⭐ La arquitectura que ya tenemos es la de Rubix, y está escrita en el sustrato desde hace dos días: «el cómputo es PLURAL y desechable; los motores entran y salen por un registro; ninguno es la arquitectura» + «la cintura estrecha es el catálogo».

⛔ «Expandir Spark como motor único» sería alejarnos de la referencia, no acercarnos. Un SELECT * FROM diets LIMIT 10 sobre 5 filas tarda 6-15 s por Spark. Esa misma query por un motor de un nodo tarda milisegundos. Foundry no lo resolvió metiendo todo en Spark: lo resolvió eligiendo motor por tamaño, sobre una malla común.

⇒ Lo que sí hay que centralizar —y es lo que Rubix enseña— son tres cosas, ninguna de ellas «el motor»:

1. El sustrato de ejecución (Kubernetes): un sitio donde todo cómputo corre, se autoescala y se apaga. Hoy tenemos el cluster, pero sólo Spark vive en él — el resto (duck-server, ml-runner, warehouse-writer) está repartido en Railway.
2. La cintura (catálogo + formato): ya la tenemos, y es la pieza más madura.
3. La elección de motor como POLÍTICA declarada, no como accidente. Hoy elegirMotorDeLectura devuelve spark siempre. Eso fue correcto para cerrar el fallback silencioso, y es insuficiente como destino.

2·bis · ⭐⭐⭐ Junction ≈ Furnace — correcto en la INTENCIÓN, falso en el MECANISMO

La memoria del repo dice «Junction = el Furnace de Carbon». Investigado: Furnace existe y es el motor de SQL warehousing de Foundry. La equivalencia es real… y la diferencia es exactamente donde nos duele.

⇒ Y esto explica, de golpe, TODOS los fallos de dialecto de esta semana

No fueron descuidos independientes: son el mismo fallo estructural, seis veces.

· `WITH … CREATE TABLE …`        → ParseException  (el prólogo, mal colocado)
· destino cualificado DOS veces  → main.default.main.default.diets
· el CTE homónimo capturaba el destino de un DELETE  (silencioso)
· `qualifyWriteTarget` anclado a `^` no veía el prólogo → devolvía el SQL intacto
· 2 divergencias SILENCIOSAS del corpus de lectura (16/25)
· `INSERT … SELECT` fuera, porque «la fuente no se resuelve»

⭐⭐ Todos salen de tratar el SQL como texto. Y la consecuencia importante es que ya tenemos un parser —accidental, disperso y por regex— repartido en sql-parse.ts (locateDmlCommand, extractDmlTarget, splitCtas, extractCteNames, rewriteDottedFromRefs), duck-plan.ts, qualifyWriteTarget, dialect-divergence.ts y equivalence.ts. No es que falte un parser: es que hay uno malo, en diez sitios.

⭐ Y el repo YA SABE cuál es la respuesta — la aplicó a la mitad

catalog-sql/grammar.ts (M3) hizo exactamente este movimiento para los comandos de catálogo, y lo dice en su cabecera:

⇒ La dirección no hay que inventarla: hay que terminarla. M3 llevó a datos la gramática de catálogo (SHOW, DESCRIBE, information_schema); el camino de datos (SELECT/DML) sigue en regex. Ése es el hueco, y es el mismo que Furnace cerró con Calcite.

⚠️ Lo que NO propone esto: adoptar Calcite mañana. Es Java, y el planificador vive en Node. Lo que sí propone es cambiar la frontera: que lo que cruce hacia el motor deje de ser una cadena manipulada y pase a ser una estructura validada — empezando por lo que ya duele (el destino de escritura y la resolución de fuentes), no por reescribirlo todo.

2·ter · El sustrato vs la malla de Rubix — lo medido

Lo nuestro, medido hoy:

kubectl -n spark get pods -o wide
  carbon-connect-server-0        ─┐
  spark-connect-…-exec-1          ├─ LOS CUATRO EN EL MISMO NODO
  spark-connect-…-exec-2          │   gke-…-tnj7 · 4 vCPU · 16 GB · europe-west1-b
  spark-bridge-…                 ─┘

⇒ No tenemos una malla: tenemos un nodo con cuatro pods. Y eso está bien para donde estamos —sirve el editor entero— pero no es lo que la palabra «cluster» sugiere, y conviene no confundirse al planificar.

⚠️ Detalle que delata la historia: el cluster se llama trino-compute-clone, por un motor demolido hace dos días.

3 · Dónde somos débiles — medido, no supuesto

3·1 · Dialecto y semántica

⭐ La asimetría que ordena la prioridad: una divergencia de lectura da un número raro que alguien puede ver; una de escritura deja el dato mal y nadie mira.

3·2 · Profundidad analítica — lo que los líderes tienen y nosotros no

3·3 · Sustrato

• ⛔ Cuota dura: CPUS_ALL_REGIONS = 12, subida denegada (cuenta de trial), y Spot también (PREEMPTIBLE_CPUS = 0). Ningún plan de escala es real hasta que eso cambie — es el techo de todo lo demás.
• ⚠️ El cluster es regional con un node pool de una zona: paga tarifa regional sin beneficio (−$73/mes si se corrige).
• ⚠️ BRIDGE_JWT_SECRET es simétrico y sin rotar — y desde W4 ese conducto también crea tablas.
• ⚠️ 56 huérfanas · 20 fantasmas de deriva Index↔físico.

4 · El norte, en tres movimientos

M1 · Elegir motor por TAMAÑO, no por defecto — «el Rubix nuestro»

elegirMotorDeLectura pasa de devolver spark siempre a decidir con una política declarada y medible, que es exactamente lo que hace Foundry:

metadata de la tabla (filas · bytes · ficheros)  →  motor
    pequeño / interactivo   →  motor de un nodo   (ms)
    grande / distribuido    →  Spark              (segundos, pero escala)
    escritura gobernada     →  Spark              (hoy es el único que firma)

⭐ Y el dato para decidir ya lo tenemos: getTableStatus devuelve filas, bytes y número de ficheros sin escanear nada. La política puede leerse del catálogo.

⛔ Con una condición innegociable, y es la lección de esta semana: la elección debe ser ruidosa y observable ([junction] motor=…), y nunca un try/catch. El fallback silencioso ya nos costó días de servir DuckDB creyendo que era Spark.

⚠️ Y un requisito previo que no se puede saltar: el corpus diferencial de escritura. Volver a tener dos motores sin haber medido la divergencia de DML sería reabrir el agujero con conocimiento de causa.

M2 · Subir el resto del cómputo a la malla

Hoy sólo Spark vive en el cluster. duck-server, ml-runner y warehouse-writer están en Railway — es decir, hay dos sustratos de ejecución, y Rubix enseña que el valor está en tener uno. No es urgente; es la dirección.

M3 · Cerrar la paridad por orden de daño, no de vistosidad

⇒ Ver §7, que ordena esto junto con todo lo demás.

7 · ⭐ LAS PRIORIDADES, con la vista completa

El criterio es qué pasa si no se hace, no la dificultad ni lo vistoso. Y con la comparación contra Furnace y Rubix delante, el orden cambia respecto a la intuición.

P0 · Lo que ya está cobrando intereses

P1 · El cambio de punto de vista — la frontera deja de ser texto

P2 · Producto que aún no existe

EXTERNAL_LINKS para resultados grandes (B3) · time travel en SQL (los snapshots ya están, sólo falta exponerlos — es lo más barato de esta lista) · vistas materializadas · Iceberg v3 (geo, variant, row lineage).

P3 · Sustrato — importante, y no urgente hasta que se levante la cuota

Malla real (HA, ciclo de nodos, aislamiento entre cargas) · subir el resto del cómputo al cluster · renombrar trino-compute-clone · rotar BRIDGE_JWT_SECRET (⚠️ simétrico, y desde W4 ese conducto también crea tablas) · node pool zonal (−$73/mes).

⛔ CPUS_ALL_REGIONS = 12 con la subida denegada es el techo de todo P3. Mientras no cambie, «malla» es una palabra: no caben más nodos. Conviene atacarlo por el lado administrativo (salir del trial) antes que por el técnico.

⚠️ Y lo que NO está en ninguna prioridad, a propósito

«Expandir Spark a toda la plataforma». La investigación dice lo contrario: Foundry pone Polars/DuckDB por defecto y Spark «sólo cuando el dato excede un nodo». Lo que sí se expande es la malla (P3) y la puerta (P1) — que es exactamente lo que Rubix y Furnace son, cada uno en su capa.

5 · Lo que este documento NO decide

6 · Documentos