S6 · Approach — SparkConnectServer, y el número que decide el motor del SQL Editor

0 · Por qué S6 ahora, y no al final

La decisión pendiente es Spark Connect vs StarRocks para el SQL Editor. Hoy sólo hay argumentos; S6 produce el brazo Spark del comparativo. Sin él, StarRocks entraría por folleto, que es exactamente el error que ya cometimos con la federación de Trino.

Y es barato: SparkConnectServer es un CRD de primera clase del operador que ya corre, el Gateway L7 con su certificado está conservado de F6, y los SecretClass de TLS siguen ahí. No hay que construir infraestructura.

⚠️ S6 NO desbloquea S5·1. El can_commit sigue abierto; Spark Connect lee igual que S2 y chocará con lo mismo el día que escriba.

1 · Qué es, y qué NO es

⚠️ Ningún acelerador arregla la latencia interactiva por sí solo. Gluten y Comet miden 3-4× en TPC-H (picos de 23×) pero aceleran la ejecución, no el arranque ni la planificación. Photon funciona en Databricks porque va con un SQL Warehouse siempre encendido — que es justo lo que SparkConnectServer es.

Limitaciones documentadas:

• Spark Connect no se integra con el History Server (Stackable, desde 25.7).
• Soporte S3 de primera clase desde 26.3 — la nuestra es 26.7, así que está.

2 · Lo que hay que montar

① El SparkConnectServer

Reusa la configuración de catálogo exacta de S2 (s2-spark-catalogo.yaml): type=rest, la cara, el prefijo de inquilino, OAuth2 y X-Iceberg-Access-Delegation: vended-credentials. Lo único nuevo es que vive en vez de morir con el job.

⚠️ Identidad: hoy sería lakekeeper-spark (rol reader) — correcto para medir lectura. El editor multiusuario exige más, y ahí está el techo del §5.

② La exposición

El Gateway 136.69.107.171 y su certificado de Google Trust Services siguen en pie (se conservaron a propósito al demoler Trino). Hace falta una HTTPRoute nueva y un nombre — spark.paladio.io — sobre la misma IP.

⚠️ Spark Connect habla gRPC, no HTTP/1.1. Hay que verificar que el Gateway L7 global de GKE lo enruta (soporta HTTP/2, que es lo que gRPC necesita, pero esto se mide, no se supone).

③ La suspensión

El CRD lleva clusterOperation.stopped, igual que TrinoCluster. El patrón de trino-suspend.sh sirve tal cual. Y aquí hay una diferencia de coste real frente a StarRocks: una capa de serving no se puede apagar; un SparkConnectServer sí.

3 · ⭐ El gate — que es una MEDIDA, no un «funciona»

S1-S4 tenían gates binarios. Éste no: su producto es un número comparable.

⚠️ El ⑤ es el que decide. Los 3,4 s/query que medimos con Trino eran topología (GKE europe-west1 → R2 WEUR), no motor. StarRocks ataca eso con caché local en los pods; Spark Connect no tiene equivalente. Si ⑤ no mejora entre la primera y la segunda pasada, el problema no es el motor y cambiarlo no lo arregla.

Control negativo

Comparar contra DuckDB, que sirve el editor hoy. Si Spark Connect no le gana a 144 tablas, el argumento para cambiarlo tiene que ser tenencia o escala — no velocidad, y hay que decirlo.

3·bis · ⛔ EL HALLAZGO QUE PUEDE DECIDIRLO SIN MEDIR LATENCIA

No existe cliente oficial de Spark Connect para Node/TypeScript.

⚠️ El SQL Editor es Next.js sobre Vercel — o sea, Node. Spark Connect habla gRPC con un protocolo propio (spark.connect.*), no SQL sobre un cable estándar.

⇒ Para que el editor use Spark Connect harían falta piezas nuevas:

• un sidecar en Python/JVM/Go que traduzca HTTP → Spark Connect, y que habría que desplegar, exponer, autenticar y mantener; o
• sacar el camino de query del editor fuera de Vercel.

Y el contraste con StarRocks es estructural, no de rendimiento: StarRocks habla el protocolo de cable de MySQL, para el que Node tiene drivers maduros (mysql2). Se enchufa al editor sin intermediario.

⇒ Esto no lo arregla ningún benchmark. El coste de Spark Connect para nuestro editor no es latencia: es una pieza de infraestructura que hoy no existe. Y es exactamente la misma forma del problema que Kyuubi resuelve —Kyuubi expone JDBC/ODBC, no gRPC propietario— sólo que Kyuubi tampoco tiene driver Node.

4 · Lo que S6 NO resuelve

• La tenencia del editor. SparkConnectServer es una sesión con una identidad de catálogo. El multiusuario real exige o un servidor por inquilino, o Kyuubi (aislamiento de sesión por usuario, Arrow desde 1.7) — que no está en la familia Stackable: sería infraestructura propia.
• La identidad en el catálogo. Con Spark Connect, Lakekeeper sigue viendo a lakekeeper-spark, no al usuario. StarRocks 4.0 hace JWT identity passthrough — es la ventaja de gobernanza que ningún camino Spark da hoy, y es exactamente lo que ha causado el bloqueo de S5·1.
• La escritura. Ver §0.

5 · El techo, dicho antes de medir

DuckDB           1 instancia, 1 warehouse por ATTACH   → no sirve a N inquilinos
Spark Connect    1 sesión, 1 identidad de catálogo     → concurrencia moderada
Kyuubi           1 sesión por usuario                  → multiusuario, infra propia
StarRocks        MPP + caché local + JWT passthrough   → serving, siempre encendido

Van en orden creciente de techo y de coste operativo. La pregunta de S6 no es «¿funciona Spark Connect?» —funcionará— sino «¿dónde está su techo, medido?», para saber si hace falta subir un escalón.

6 · Fases