Proyecto

Lakebase Multiformato — OLTP gobernado en Databricks

Ingesta de 5 formatos de origen sin relación temática entre sí (XML, CSV/Excel/Parquet, JSON de API, geoespacial vía OpenStreetMap, y texto+embeddings) hacia Databricks Lakebase, el motor OLTP (Postgres gestionado, Autoscaling) de Databricks — con las 7 tablas resultantes consultables en vivo desde Unity Catalog vía Lakehouse Federation. Cuarto proyecto de la serie, y el primero que trabaja sobre un motor OLTP en vez de OLAP.

Arquitectura

5 fuentes heterogéneas

→

Lakebase (Postgres)

→

branch production / dev

→

Unity Catalog

→

Databricks SQL

XML (RSS), JSON (API Open-Meteo), CSV/Excel/Parquet (datos.gob.ar, INDEC, sample DuckDB), geoespacial (Overpass/OSM) y texto+embeddings (Gutenberg + OpenRouter) se ingestan con upsert hacia 7 tablas en Lakebase, el Postgres administrado y autoscaling nativo de Databricks. Infra completa con Terraform: project → branch → endpoint → catalog. El catálogo registra la base directamente en Unity Catalog vía Lakehouse Federation — consultable en vivo desde SQL/notebooks, sin copiar el dato.

Decisiones de ingeniería

GEOGRAPHY en vez de geometry para los puntos de OSM — las consultas de demo son de distancia real en metros (ST_DWithin, ST_Distance), y geography la calcula directo sobre la esfera terrestre sin reproyectar.
IPC de INDEC normalizado en (fecha, region, categoria) en vez de replicar el layout ancho del Excel original — el archivo fuente cambia de columnas entre publicaciones, y un esquema normalizado no se rompe con eso.
Índice HNSW (no IVFFlat) para los embeddings — no necesita re-entrenarse a medida que la tabla crece, mejor default para un dataset que se ingesta de forma incremental.
Sin password estática de Postgres — toda conexión usa un token OAuth de corta duración vía el SDK de Databricks (generate_database_credential).
Branch dev como fork copy-on-write de production (ttl 48h) — aislamiento probado insertando una fila marcada en dev y confirmando que nunca aparece en production.

Stack

Databricks Lakebase Postgres Terraform PostGIS pgvector Unity Catalog Lakehouse Federation

Ver repo en GitHub

El problema

Demostrar versatilidad de ingesta hacia un motor relacional gobernado, no contar una historia de negocio unificada: 5 formatos de origen completamente distintos, sin relación temática entre sí, cada uno con su propio tipo de dato Postgres específico (relacional simple, INET, GEOGRAPHY, VECTOR).

La solución

Un script de ingesta por formato con upsert idempotente (ON CONFLICT ... DO UPDATE) escribiendo a Lakebase, el OLTP administrado de Databricks con PostGIS y pgvector habilitados. El puente hacia el lado analítico es Lakehouse Federation: las 7 tablas quedan consultables en vivo desde Unity Catalog sin mover el dato ni armar CDC.

demo en video

Qué evalúa esto

Pregunta típica de entrevista	Dónde está la respuesta
¿Cuándo OLTP y cuándo OLAP?	`reglas/03-conceptos-oltp-postgres.md` — Lakebase (este proyecto) vs. Delta Lake (los 3 anteriores)
¿Cómo modelás datos heterogéneos?	`schemas/*.sql` — una tabla por formato, tipo Postgres específico para cada uno
¿Cómo autenticás sin password estática?	OAuth M2M + `generate_database_credential` — `ingestion/_lakebase.py`
¿Cómo garantizás idempotencia en la ingesta?	`ON CONFLICT ... DO UPDATE` en los 5 scripts de `ingestion/`
¿Cómo conectás OLTP con el lado analítico?	Lakehouse Federation (`databricks_postgres_catalog`), no copia CDC
¿Cómo aislás un ambiente de desarrollo?	Branch copy-on-write (`dev`, fork de `production`, ttl 48h)