Proyecto

Entity 360 — Golden record multicloud en Databricks

La misma empresa aparece en 5 fuentes, traídas por 4 productores, con nombres e identificadores distintos. Esta plataforma la convierte en un solo golden record explicable: cada atributo dice de qué fuente vino y cada unión dice por qué se hizo. Sexto proyecto de la serie, y el primero que cruza on-prem, tres nubes y dos warehouses en un mismo DAG.

Arquitectura

4 productores

→

Landing + contratos

→

Bronze / Silver SCD2

→

Resolución

→

Gold (dbt + Iceberg)

→

Snowflake zero-copy

Un SQL Server legacy con CDC (GLEIF), una Lambda en AWS (SEC EDGAR), GitHub Actions + BigQuery (GDELT) y un container (OpenSanctions + Wikidata) guardan primero en su propio almacenamiento y después empujan cada lote al landing de Unity Catalog con un manifest (sha256, registros, rango extraído). Contratos de Soda Core aprueban el lote o lo mandan a cuarentena antes de Bronze; Silver es incremental con SCD2 y la resolución de identidades une 1.268 registros en 1.136 entidades. Gold se construye con dbt en Iceberg, y Snowflake lo lee vía Iceberg REST con una base catalog-linked, sin copiar datos. Airflow 3 orquesta todo y avisa por Telegram; el consumo es un dashboard AI/BI con Genie.

Decisiones de ingeniería

Resolución de identidades medida, no afirmada: set etiquetado a mano (59 registros + 60 pares) con intervalos de Wilson al 95 %. La v1, con medición ciega, dio precisión 0,913 [0,732–0,976] y recall 0,955 [0,782–0,992]; la v2.1, sobre el set completo (no ciego), precisión 1,000 [0,921–1,000] y recall 0,978 [0,887–0,996].
Lo dudoso no se fuerza: una empresa que solo aparece por nombre en GDELT queda en resolution.revision en vez de unirse suponiendo el país.
Latido ≠ frescura: un productor sin novedades deja un _manifest vacío (sin_cambios: true), así "estoy vivo" se separa de "hay datos nuevos".
Identidad estable de Gold: CREATE OR REPLACE cambiaba el UUID de la tabla y rompía Snowflake; Gold pasó a incremental con insert_overwrite, mismo table_id.
Mínimo privilegio probado: el SP de Snowflake recibe 403 en silver y la base catalog-linked rechaza escrituras incluso a ACCOUNTADMIN. Un SP por productor y 0 secretos en el state de Terraform.
Silver incremental bajó de 423 s a 32 s sin lotes nuevos, con huellas idénticas en las 12 tablas contra el recálculo completo.

Stack

Databricks Unity Catalog dbt Iceberg Snowflake Airflow 3 Soda Core SQL Server CDC AWS Lambda BigQuery Terraform

Ver repo en GitHub

El problema

Los datos de una organización viven repartidos entre un ERP legacy on-prem y varias nubes. Acá las entidades son empresas reales y las fuentes son registros públicos reales que se pisan entre sí — y ninguna comparte un identificador (LEI, CIK, QID o solo un nombre) con todas las demás.

La solución

Cada productor empuja lotes con manifest a un landing común, los contratos filtran lo roto antes de Bronze, y una resolución por reglas calibrada arma un golden record con procedencia por atributo. Gold en Iceberg se comparte a Snowflake zero-copy (el proyecto completo consumió ~0,24 créditos, ≈ USD 1 del trial), y todo corre en un DAG de 28 tareas en ~12 minutos.

demo en video

Qué evalúa esto

Pregunta típica de entrevista	Dónde está la respuesta
¿Cómo resolvés la misma entidad entre fuentes sin un ID común?	`databricks/resolucion/calibracion/INFORME.md` — reglas calibradas con P/R e intervalos de Wilson
¿Cómo evitás que un lote roto contamine el lakehouse?	Contratos Soda en la llegada + cuarentena — `docs/adr/0006-bronze-exige-contrato.md`
¿Cómo compartís datos entre Databricks y Snowflake sin copiarlos?	Base catalog-linked vía Iceberg REST + credential vending — `snowflake/evidencia/`
¿Cómo distinguís un productor caído de uno sin novedades?	Manifest de latido — `docs/adr/0014-latido-separado-de-frescura.md`
¿Cómo bajás el costo de un pipeline que se recalcula entero?	Silver incremental, 423 s → 32 s — `docs/adr/0011-silver-incremental-y-cuota.md`
¿Cómo manejás secretos en una infra multicloud con Terraform?	0 secretos en el state, un SP por productor — `docs/adr/0002` y `docs/adr/0012`