🧭 REPASO DEL PARADIGMA — de la ingesta al catálogo

1 · El recorrido, y por dónde NO pasa

  FUENTE (Postgres del cliente)
     │  Node · streaming real (fetch batch → yield)
     ▼
  COORDENADA en Index          ← el único punto donde la ingesta toca gobernanza ✅
     │
     ▼
  warehouse-writer (PyIceberg) ──⛔ NO pasa por la cara ──▶  CATALOG-STORE (Lakekeeper)
     │  llave estática RW de todo el bucket                        │  commit = CAS sobre `table_refs`
     ▼                                                             ▼
  DATA-STORAGE (R2)  ◀───────────────────────────────────── el metadata.json es una SALIDA


  SQL Editor ──▶ JUNCTION ──▶ COMPUTE (Spark) ──▶ ICEBERG-FACE ──▶ CATALOG-STORE
                  ✅ la persona          ✅ el motor        ✅ 1 de 4 carriles

⭐ La imagen tiene una asimetría que lo explica casi todo: el carril de lectura del producto está gobernado de punta a punta, y el carril por el que entra el 100 % del dato nuevo no pasa por ninguna puerta.

2 · Los seis patrones que se repiten

No son ocho listas de pendientes: son seis formas de fallar que aparecen en piezas distintas. Ordenados por lo que cuestan.

P1 · Declarado y no aplicado

Lo más frecuente, con diferencia. La decisión está tomada, escrita y visible — y no actúa.

P2 · Construido y sin disparador

La mitad cara está hecha. Falta la barata.

P3 · Traducido y no registrado

Se toma una decisión por el usuario y no queda rastro de que se tomó.

• Un tipo desconocido cae a string sin aviso; Decimal → decimal(38,9) pierde escala en silencio (INGESTION).
• 17 de 26 fuentes están en main.default sin que nadie lo eligiera, y «lo eligió» y «se lo pusimos» son indistinguibles (INGESTION).
• El accessKeyId de R2 es el del token padre ⇒ en los logs del bucket todos los inquilinos se ven iguales (DATA-STORAGE).
• ⭐ Y el caso más caro: el 404 significa tres cosas — no existe, no puedes y no está enrutado (CATALOG-STORE capas 4 y 5). Tres causas, un síntoma, y la primera hipótesis de cualquiera será la equivocada.

P4 · El mismo conocimiento en dos sitios, sostenido por un comentario

• JSON_ENCODED_BASE_TYPES existe en TypeScript y en Python con un # MUST mirror encima y ningún trinquete que lo compare. Si divergen, una columna se escribe codificada y se lee sin decodificar: texto JSON donde el usuario espera un objeto, sin error (INGESTION).
• tenant_warehouses.key_prefix en Index y key-prefix en Lakekeeper: ya divergieron, en 4 de 8 filas (DATA-STORAGE).

P5 · Medir una parte y llamarlo el todo

El patrón que más veces ha producido una conclusión falsa, no incompleta:

⚠️ Y uno esperando a repetirse: rest-page-size: 100 con main.default a 99 tablas — cualquier listado que no siga next-page-token está a una tabla de truncar en silencio (arreglado en el censo, no en el resto del repo).

P6 · La puerta es más estrecha que lo que gobierna

• La cara enruta 13 de 25 endpoints del catálogo, y falla cerrada. Lo que usamos de lo bloqueado —renombrar, registrar— funciona porque va por fuera de ella (CATALOG-STORE capa 5).
• La cara gobierna 1 de 4 carriles; los otros tres apuntan a Lakekeeper directo (ICEBERG-FACE).
• Junction pregunta «¿puede esta persona?» sólo en el carril del SQL Editor.

3 · El sustrato legacy que queda, con nombre

4 · Y entonces: ¿Polaris como sustrato de catálogo?

4·1 · Lo primero, porque ordena el resto

De los ~40 pendientes repartidos por las ocho piezas, cambiar de catálogo arregla tres: el /plan, la compactación/expiración programada, y —si además se cambia el modelo— la unidad de tenencia. Todo lo demás sigue igual el día después.

⇒ La pregunta no es «¿es Polaris mejor que Lakekeeper?». Es «¿qué de nuestros problemas es del catálogo?» — y la respuesta medida es: pocos, y ninguno de los dos que más duelen (la ingesta sin puerta, y la recuperación que no recupera).

4·2 · ⭐ El argumento que descartó a Polaris ha CADUCADO

index-catalog-sota.md (2026-08-03), fortaleza F6:

Medido hoy: nadie consume el vending del catálogo.

El warehouse tiene sts-enabled: true y no lo pide nadie.

4·3 · 🏁 El argumento que quedaba vivo — MEDIDO: Polaris habla R2

Sonda lanzada el 2026-08-12, misma disciplina que la R1 de Gravitino:

docker run -d --name polaris-probe -p 18181:8181 \
  -e POLARIS_BOOTSTRAP_CREDENTIALS=POLARIS,root,s3cr3t \
  -e polaris.persistence.type=in-memory \
  -e AWS_ACCESS_KEY_ID=$R2_KEY -e AWS_SECRET_ACCESS_KEY=$R2_SECRET -e AWS_REGION=auto \
  apache/polaris:1.7.0
npx tsx scripts/warehouse/p1-polaris-r2-gate.ts --clean

① config: endpoint propio + path-style + region=auto, sin roleArn   ✅ aceptada
③ createNamespace 200 · createTable 200
④ ⭐ LISTANDO EL BUCKET:
     _probe-polaris/probe/r2_gate_…/metadata/00000-….metadata.json    ✅ ESCRITO
⑤ control negativo: fuera de `allowedLocations` → 403, y 0 objetos    ✅
═══ 🏁 POLARIS HABLA R2 ═══

La pieza es stsUnavailable: true, y la dice el propio servidor. Sin ella intenta acuñar por STS y muere con StsException — que es exactamente el fallo que se leyó en su día como «es AWS-céntrico». Su aviso de arranque es literal:

⇒ El almacenamiento S3-compatible sin STS es un camino de primera clase en Polaris, no un apaño. Y la afirmación que lo descartó era, otra vez, el patrón P5: se midió un error de una configuración y se concluyó sobre una capacidad.

⚠️ Con una consecuencia que sí hay que anotar: Polaris sobre R2 no vende llaves.

loadTable + X-Iceberg-Access-Delegation: vended-credentials
  → 400 «Credential vending was requested … but no credentials are available»
  → remote-signing: 400 «Unsupported access delegation mode»
  → sin delegación: 200

Es el comportamiento honesto —sin STS no hay credencial acotada, así que se niega en vez de entregar la llave ambiente— y para nosotros no cambia nada: la acuñamos en la puerta desde P4-bis. Pero cierra la puerta a que algún día la venda el catálogo.

4·3·bis · ⭐⭐⭐ Y la sonda destapó lo que no íbamos buscando

El endpoints[] de Polaris declara 36, frente a 25 de Lakekeeper y 24 de Gravitino. Los 12 de diferencia no son relleno:

Y la API de políticas funciona, medida en la misma sonda:

system.data-compaction        → CREADA
system.snapshot-expiry        → CREADA
system.orphan-file-removal    → CREADA
mapping política → tabla      → 204
applicable-policies(tabla)    → [{ "policy-type":"system.data-compaction",
                                   "inheritable":true, "inherited":false }]

⇒ El eje de la decisión ya no es el almacenamiento: es qué se quiere del catálogo.

4·4 · Lo que CATALOG-STORE añade y no estaba en la mesa el 3 de agosto

El 08-03 el coste de salida se estimó así: «no hay atadura de API; el coste real es el registro». Ahora sabemos cuánto es ese registro, y qué clase de cosa es:

• el catálogo es la fuente, no un índice: la metadata Iceberg vive normalizada en 44 tablas de su Postgres, y el metadata.json de R2 es una salida (probado con diferencial en frío);
• el estado vivo son 194 tabulars · 619 snapshots · 851 entradas de metadata-log · 181 refs · 13 warehouses · 2 tags del JOP;
• ⇒ migrar de catálogo no es re-apuntar una URI: es reconstruir el estado. Y la operación con la que se reconstruiría —register— es una de las 12 que nuestra cara no enruta.

⚠️ Y hay una prueba que nadie ha hecho, para ninguno de los tres candidatos: registrar una tabla existente en un catálogo nuevo y comprobar que conserva su historia (snapshots, refs, tags). Sin eso, «migrable» es una opinión.

4·5 · La asimetría que de verdad decide, y no es de almacenamiento

Dónde pone cada uno la frontera del inquilino:

Eso no es un «no». Es que si el motivo para ir a Polaris es su modelo —multi-catálogo, realms, madurez de vending, comunidad— entonces la decisión que se está tomando no es «qué catálogo» sino «dónde vive la frontera del inquilino», y merece evaluarse como tal.

Si el motivo es /plan, la comparación es otra: Gravitino ya lo tiene medido, desplegado en el cluster, y con el endpoint autorizado por principal leído en la fuente. Polaris tendría que empatar eso desde cero.

4·5·bis · ⛔ ¿Polaris y Gravitino? — no hay sinergia, hay que elegir

① «Gravitino» son dos productos, y el folleto vende el grande. El diagrama del Unified Metadata Lake —SSOT, geo-distribuido, lineage, auditing, optimizing— es el servidor completo (metalake). Lo que medimos y lo que corre en el cluster es el Iceberg REST server: otro artefacto, otro chart, 250m de CPU y 1 Gi. Y su propio conf, leído dentro de la imagen, sólo documenta tres backends:

gravitino.iceberg-rest.catalog-backend = memory     # «it's recommended to change to hive or jdbc»
#                                        jdbc
#                                        hive

⇒ El artefacto que tenemos desplegado no puede montarse encima de otro catálogo REST: no documenta ese backend. La federación, si se quiere, exige la bestia entera — que es justo lo que el mapa §8·1·g concluyó que no hace falta.

② Como catálogo de REGISTRO son mutuamente excluyentes, y no por el protocolo —los dos hablan Iceberg REST— sino por dónde vive la atomicidad. CATALOG-STORE capa 2 lo midió: el commit es un CAS sobre table_refs dentro del Postgres del catálogo, y el metadata.json de R2 es una salida.

③ La sinergia que ofrece el diagrama es federación, y está fuera del norte. Decidido el 2026-08-11 (concepto ⑱ del mapa), y §8·1·b lo dice en físico: «no federamos: se copia al bucket». Un bucket, un formato, un inquilino con datos: no hay nada que federar.

④ La única topología coherente sería Gravitino-metalake ENCIMA y Polaris DEBAJO — nunca al revés. Y su precio es el patrón P4 elevado a sistema: dos servidores, dos Postgres, dos modelos de autorización y dos integraciones de identidad sosteniendo el mismo conocimiento.

⑤ Y la asimetría que decide, visible en las propias rutas medidas:

Gravitino:  POST /v1/{prefix}/tables/{table}/plan          ← SPEC Iceberg REST 1.11
Polaris:    GET  /polaris/v1/{prefix}/applicable-policies  ← EXTENSIÓN de proveedor

4·5·ter · 🏁 El servidor COMPLETO de Gravitino, medido — y reencuadra la elección

(Sonda scripts/warehouse/g2-gravitino-federacion-gate.ts, apache/gravitino:1.3.0, 2026-08-12. Todo entre contenedores: no toca producción.)

① Los tipos de objeto que el catálogo modela — y son los del norte

/opt/gravitino/catalogs/  →  fileset · glue · hive · jdbc-doris · jdbc-mysql
                             jdbc-postgresql · jdbc-starrocks · kafka
                             lakehouse-generic · lakehouse-hudi
                             lakehouse-iceberg · lakehouse-paimon · model

RELATIONAL (tablas, vistas) · FILESET ✅ (ficheros/volúmenes) · MODEL ✅ · MESSAGING (colas)

Los proveedores son paquetes en disco (/opt/gravitino/catalogs/<x>/libs), no una lista cerrada. ⇒ El «tablas, volúmenes, colas, conexiones, ficheros, modelos, vistas» existe como modelo, no como diagrama. Y una «conexión» en su vocabulario es un catálogo: montar una fuente es darla de alta.

⚠️ hive y kafka fallaron por falta de sus propiedades obligatorias (metastore, bootstrap servers), no por no existir.

② ⭐⭐⭐ La federación nativa, con el bucle cerrado

montar un Iceberg REST AJENO  (catalog-backend: rest)   → 200
listar SUS schemas                                      → 200
CREAR un schema a través de Gravitino                   → 200
⭐ ¿lo ve el catálogo de ABAJO?  ✅ SÍ
   {"namespaces":[["desde_gravitino"], …]}

Y eso demuele la objeción más cara de §4·4. «Migrar de catálogo es reconstruir el estado» sigue siendo cierto para Polaris — que es una sustitución. Para Gravitino no aplica, porque puede adoptarse como superposición:

la cara ──▶ Gravitino (tipos + federación) ──▶ Lakekeeper (sigue siendo el registro Iceberg)

⇒ Gravitino es el único de los tres que se adopta sin migrar nada, y por tanto el único reversible.

③ ⛔ Y el contra que hay que decir igual de fuerte: su gobernanza viene apagada

GET /api/metalakes/probe/roles   → 405
  «You should set 'gravitino.authorization.enable' to true in the server side
   gravitino.conf to enable the authorization of the system»

Roles, usuarios y grupos no responden de fábrica. Es el patrón P1 —declarado y no aplicado— pero de serie. Y su ABAC sigue siendo futuro: el mapa §8·1·d ya midió que empuja los permisos hacia Ranger, que es el producto que decidimos no adoptar.

⇒ Lo que hoy tenemos —decidePrivilege, access_events, la retícula de la cara— es MÁS de lo que Gravitino trae encendido. Adoptarlo no nos da gobernanza: nos da dónde colgarla, y para más tipos de objeto.

4·5·quater · Pros y contras, con lo medido de cada uno

4·5·quinquies · La lectura, sin diplomacia

Sí merece la pena como proyecto ambicioso — pero no como «cambiar de catálogo».

Los dos resuelven mitades distintas del mismo norte, y la comparación honesta no es Gravitino vs Polaris: es qué mitad falta más.

• Si el catálogo tiene que albergar volúmenes, colas, conexiones, modelos y ficheros —y el norte dice que sí, porque la ontología se proyecta desde ahí— entonces Polaris no es candidato: no los modela. La conversación se acaba ahí.
• Y entonces Gravitino no es un catálogo mejor: es la capa que hoy no existe, la que el mapa llama concepto ⑮ —«un solo modelo de tipos y permisos», hoy dos planos que no se hablan—. Eso no es sustituir a Lakekeeper: es ponerle encima lo que le falta, sin migrar, y con la opción de sustituirlo después o nunca.
• El precio es explícito y hay que aceptarlo con los ojos abiertos: la gobernanza no viene incluida. Seguimos escribiendo la política nosotros — sólo que ahora para seis tipos de objeto en vez de uno.

4·6 · ⛔ Y el orden importa más que la elección

Tres razones, todas medidas:

1. Hoy entra por fuera el 100 % del dato nuevo. Cambiar lo que hay debajo de una puerta que la ingesta no cruza no la protege.
2. La cara es la capa que absorbe el cambio. Ya traduce nombres, resuelve inquilino y sustituye el prefijo. Cuando Trino dejó de hablar con Lakekeeper y pasó a hablar con ella, no hubo que cambiar nada más. Es la prueba de que la abstracción funciona — y de que conviene tenerla delante de todos los carriles antes de mover el sustrato.
3. Si se cambia primero el catálogo, el trabajo de meter la ingesta por la cara hay que hacerlo igual, después, y encima contra un sustrato recién movido.

5 · Lo que este repaso propone — con su gate

5·1 · 🏁 La sonda, y lo que queda después de ella

scripts/warehouse/p1-polaris-r2-gate.ts — sólo lectura salvo dentro de _probe-polaris/, idempotente, y con las cuatro comprobaciones que la hacen concluyente: verificar listando el bucket, leer endpoints[], control negativo fuera del prefijo, y versión fijada (apache/polaris:1.7.0, no :latest).

Lo que sigue sin medirse, para ninguno de los tres candidatos:

6 · Las dos frases que resumen el repaso

Relacionado

docs/piezas/ (las ocho piezas) · index-gobernanza-mapa.md §8·1 (la evaluación de Gravitino, con R1 y R2 medidos) · index-catalog-sota.md (el análisis de Polaris del 2026-08-03, cuya F6 este repaso caduca) · f2-catalog-substrate-approach.md (los modelos de tenencia).