Bacardi Account Matching

Motor de entity resolution que consolida un master ERP corporativo y seis sistemas SFA regionales en un único Golden Record con provenance controlada por stewards. Pipeline de seis etapas en Databricks — filtrar, normalizar, features, score, routing, ensamblado — con historia SCD2, survivorship determinístico y stewardship app que escribe en paralelo. Seed validado end-to-end, pipeline incremental diario operando en desarrollo y traspaso a QA bajo el partner.

Mi rol

Arquitecto de datos / lead del pipeline

Período

2025

Estado

En producción

Stack

DatabricksPySparkDelta LakeLightGBMrapidfuzzFastAPIDatabricks Apps

La verdad sobre cuentas comerciales en Bacardi estaba fracturada. El master ERP corporativo guardaba la identidad estructural — nombres, direcciones, IDs legales — para cientos de miles de cuentas. Seis sistemas SFA regionales, cubriendo EMEA, LATAM y APAC, sumaban un volumen mayor de registros con el ADN comercial: tipo de cuenta, actividad de consumo, segmentación de punto de venta, frecuencia de visita. El mismo outlet aparecía con frecuencia tres o cuatro veces, nunca reconciliado y a menudo con atributos mutuamente contradictorios. El mandato no era un modelo, era un par pipeline-más-gobernanza. El pipeline tenía que dedupar de forma determinística donde fuera posible, scorear probabilísticamente donde fuera necesario, rutear los casos ambiguos a humanos y producir un Golden Record SCD2 con auditoría completa de qué fuente aportó cada campo. La gobernanza tenía que mantener al ERP corporativo como autoritativo, impedir que las decisiones de los stewards se sobrescribieran y permitir que el equipo de datos siguiera editando el Golden mientras el mismo pipeline corría cada noche. Modelo de delivery: el equipo de ingeniería poseía dev; el partner de implementación desplegaba QA y prod vía bundle de Azure Data Factory.

Dos fuentes, un pipeline, seis etapas, dos targets de escritura (Golden Record y mapping table) y una stewardship app que escribe en ambos. La identidad la resuelve el mapping; los valores de campo, un survivorship rankeado donde el ERP corporativo siempre prevalece.

1. Detección de delta — watermarks por fuente en una tabla de control protegida con anti-join híbrido y diff de timestamp.
2. Filtro y unión — ambas fuentes a una staging única con `source_type`; deletes excluidos, status como metadato no como filtro.
3. Normalización — país a ISO-2, claves de blocking trimadas, geocoordenadas casteadas; países sin normalizar van a cuarentena.
4. Atajo de identidad y features — filas ya mapeadas saltan el scoring; solo las nuevas entran al blocking N1/N2/N3.
5. Score con LightGBM sobre siete features; match exacto de clave ERP bypassa con 1.0; LLM solo refina la revisión.
6. Routing en una sola decisión por fuente: AutoApproved, PendingReview con top-5 candidatos, o PendingCreation.
7. Ensamblado SCD2 con MERGE en Golden y mapping; campos estructurales del ERP, comerciales por survivorship rankeado.
8. Stewardship app FastAPI + Databricks Apps con cinco pantallas que escribe Golden y mapping en una sola transacción.

LightGBM, no XGBoost.

La serialización nativa de texto de LightGBM es independiente del ABI binario de NumPy. Los workers de Databricks Serverless corren un NumPy más antiguo que el entorno de entrenamiento; el pickle de XGBoost se rompe cruzando esa frontera. El `.txt` de LightGBM carga limpio en cualquier worker.

Features sobre embeddings.

El matching de cuentas es un problema de identidad, no de similitud semántica. Las features ingenieradas — Jaro-Winkler sobre nombre y dirección, Haversine, flags de match exacto, igualdad de TIN — son interpretables para los stewards en casos borderline, baratas a escala de cientos de millones de pares y robustas frente a la fracción significativa de matches confirmados cuyos nombres difieren.

Clustering conservador.

Preferir Goldens duplicados que se puedan fusionar después antes que contaminar un Golden uniendo cuentas reales distintas. Los falsos negativos son recuperables vía herramienta de merge del steward; los falsos positivos corrompen el master y se propagan en cascada al reporting downstream.

El ERP corporativo siempre manda.

El survivorship es rankeado: ERP master es rank 1, los sistemas regionales rank 2-4. Para cualquier campo compartido, gana la fuente más alta con valor no nulo. Un secondary sort determinístico sobre source ID evita la indeterminación del window de Spark.

Identidad y gestión de campo son problemas distintos.

Una vez mapeada una fila origen, su identidad ya está resuelta — re-scorearla en cada corrida gasta cómputo y crea PendingCreation falsos cuando el campo origen deriva tras una edición del steward. El pipeline divide cada delta en rama «ya mapeada» (join-and-tag, sin modelo) y rama «genuinamente nueva» (blocking + scoring + routing completo).

El LLM como blend dirigido, no como scorer principal.

La normalización multilingüe de nombres y la equivalencia fonética son zonas donde un LLM aporta señal real en la banda de revisión. El LLM se cablea solo en esa zona, detrás de un volume gate, con llamadas batch paralelizadas para que la corrida diaria respete el SLA.

• La evaluación lazy de Spark contra tablas Delta mutantes es una clase de pérdida silenciosa de datos: hay que materializar el DataFrame antes de hacer MERGE en la misma tabla que se lee.
• Los literales de tipo que reflejan un schema físico son una trampa de mantenimiento; o se validan en runtime contra `DESCRIBE TABLE`, o se eliminan y se confía en el flujo de tipos nativo del origen.
• Una etapa productora no puede borrar las tablas temporales que consume una vista lazy aguas abajo — el cleanup vive en el overwrite del próximo run o en un epílogo del orquestador.
• Una revisión adversarial de PM antes de decidir entre fix estructural y cosmético atrapa la generalización «si todas las filas tuvieran este bug, ¿qué haríamos?» que parchear un subconjunto pasa por alto.
• La lógica intestable pero correcta merece tracking de primera clase: un ticket de «Empirical Gap» pesa más que un watch-item que deriva y se pierde entre sesiones.
• Una unificación de regla MERGE de dos líneas (aritmética de rank sobre exclusiones hardcodeadas de fuente) puede ser más estricta en la protección del steward y arreglar un drift de self-refresh al mismo tiempo.

• Golden Record unificado con historia SCD2 completa, validado end-to-end sobre las seis etapas en la corrida de seed.
• Pipeline incremental diario que ejecuta como un único notebook orquestado, procesando solo registros cambiados y haciendo MERGE sin sobrescribir decisiones de stewards.
• Provenance por campo para cada atributo comercial de cada Golden — cada valor responde «qué fuente me escribió y cuándo».
• Stewardship app que crea, edita y obsoletiza Goldens en tiempo real, escribiendo en paralelo con el pipeline en una única transacción.
• Detección de drift, gestión de cola y operaciones bulk expuestas a los stewards a través de una web app de cinco pantallas.
• Contrato de hand-off para QA y producción vía bundle de Azure Data Factory propiedad del partner — el equipo de ingeniería no toca entornos no-dev.

Hardening de producción

Atomicidad sobre la escritura close-then-append del SCD2, paralelización de las llamadas LLM batch para meter el runtime de la zona de revisión dentro del SLA diario, y persistencia de la tabla de cuarentena para que las filas rechazadas sobrevivan a las fronteras de sesión.

Ciclo de vida del modelo

Migración del scorer LightGBM de archivo estático en repo a modelo registrado en el registry con reentrenamiento alimentado por decisiones de stewards, monitorización de drift y enriquecimiento de ground truth con hard negatives extraídos de los rechazos manuales.

Recall y cobertura

Activación condicional de un pase ANN sobre el pool no-match, gateado por evidencia de producción; y fallback fuzzy del lado ERP para registros que llegan después de que un steward ya creó un Golden desde una fuente regional.

Comunicación cross-system

Handshake bidireccional con la stewardship app para propagar las ediciones de stewards aguas arriba, eliminando el drift del lado origen que hoy obliga a lógica compensatoria dentro del pipeline.