Bacardi Nielsen Matching

Pipeline de entity resolution nativo de Databricks que eleva datos de medición de mercado externa a la jerarquía UPH de Bacardi, dejando que volúmenes de panel sindicado dialoguen directamente con ventas internas, finanzas y masters dimensionales en una sola capa de dashboarding. Arquitectura de diez etapas con cascada de cuatro pasadas (Override → Exact → Vector Search → juez LLM) que sustituye reconciliaciones ad-hoc en Excel por tablas Delta determinísticas, matches versionados en SCD2 y una cola unificada de stewardship.

Mi rol

Arquitecto de datos

Período

2026

Estado

En producción

Stack

DatabricksPySparkMosaic AI Vector SearchClaude LLMsDelta LakeLangGraph

Los datos de panel de medición de mercado son la única lente externa con la que Bacardi observa el sell-through de sus competidores. El feed llega a escala en once mercados europeos y americanos sobre nueve categorías de spirits, vinos y adyacentes, pero su capa de identidad de producto no se alinea con el master corporativo: marca, owner, sub-marca y tamaño de envase cargan variantes ortográficas, etiquetas placeholder contaminadas y texto libre donde el master espera códigos canónicos. Los joins por clave directa son imposibles — la columna de descripción del feed colapsa en pocas etiquetas de nombre de dataset y la identidad real de variante está fragmentada en docenas de tablas dimensionales heterogéneas por categoría. Sin resolución, cada pregunta de share-of-market o benchmarking competitivo se contesta en hojas de cálculo fuera de la plataforma. Con resolución, esas respuestas se mueven dentro del warehouse, se versionan en el tiempo y alimentan el BI downstream sin reconciliación manual por consulta. El mandato: construir el pipeline de resolución una vez, versionarlo correctamente y desplegarlo país a país.

Diez etapas Delta Lake con un principio operativo por encima de todos: ningún registro queda fuera. Los campos contaminados se marcan inutilizables, no se excluyen, y todo origen llega al consumo final con un match status definitivo.

1. Capa de referencia — ocho tablas Delta SCD2 con mappings, matriz de elegibilidad, override unificado y cola de stewards.
2. Cleansing de campos — `field_reliability_mask` por fila marca columnas usables; drift detection sobre owner y brand corre en paralelo.
3. Armonizar y canonicalizar — Pattern-B join trae las dimensiones por categoría; tamaño de envase canonical por función compartida.
4. Deduplicación — catálogo canónico con composición de hash estable; tabla de lineage preserva la procedencia por dataset origen.
5. Elegibilidad — la estructural se desacopla de la efectiva; combinaciones sin cobertura master cortocircuitan a la cola de revisión.
6. Match en cascada — cuatro pasadas estrictas: Override force, Exact join, Mosaic AI Vector Search y jueces Claude.
7. Ensamblado — vista row-grain para auditoría forense y agregado materializado a once dimensiones; FX falla abierto con visibilidad.
8. Embeddings — tres índices vectoriales nuevos sobre el endpoint compartido que ya sirve al landscape MDM más amplio.

Ningún registro queda fuera; los campos contaminados se marcan, no se excluyen.

Eliminar filas con owner o brand placeholder fue tentador y equivocado: siguen representando volumen real que el negocio necesita ver en dashboards aunque no se pueda matchear. Los stewards trabajan la cola; el pipeline no trabaja a su alrededor.

El override precede a las reglas regex en cada nivel del pipeline.

Cuando un steward inserta un override, el pipeline se autocorrige sin redeploy de código. Esa precedencia se mantiene a lo largo de las cuatro pasadas de match y de la canonicalización de envase, convirtiendo el override en la palanca de evolución del sistema.

Reaprovechar artefactos de los pipelines hermanos.

El endpoint de Vector Search, el mapping canónico de marcas y la caché de embeddings se reutilizan del landscape MDM existente en vez de duplicarse. Una decisión arquitectónica temprana cerró el debate y mantiene una única superficie compartida para los proyectos de entity resolution.

Match en cascada de cuatro pasadas en orden estricto.

Override → Exact → Vector Search → juez LLM. Cheapest-first: cada pasada solo recibe lo que la anterior no resolvió, y el orden de coste también es el orden de confianza, así que la tasa de revisión humana cae sin sacrificar precisión.

Cascada Haiku → Sonnet → Opus con tope como freno de incidente.

El cap duro sobre el modelo más caro funciona como detector de comportamiento anómalo, no como control de presupuesto. Si la cascada empieza a llamar al modelo más caro fuera de banda, algo aguas arriba — un drift de datos o un override roto — está pidiendo investigación.

• La revisión adversarial reescribió cuatro decisiones del borrador antes del lock arquitectónico — el council fue load-bearing para el diseño final (triggers SCD2 duales, override extensible por payload JSON, máscara cascadeable).
• Briefings de terceros pueden cargar errores factuales load-bearing que solo el profiling expone — el Phase 0 atrapó tres antes de que la arquitectura empezara.
• Disciplina en el design log a escala: ochenta y seis decisiones numeradas durante la fase de arquitectura con diez supersedes parciales, todas trazables.

Estado actual

Phase 0 cerrado con cross-comparison report y profiling de corrección del brief; Phase 1 con la arquitectura bloqueada vía walkthrough de once pasos con el boss, ochenta y seis decisiones numeradas y ratificación por council multi-agente.

Próximos pasos

Implementación del Phase 1 con el build de las diez etapas del pipeline, piloto país arrancando en el Reino Unido para validar la cascada en producción, y rollout multi-mercado posterior conforme cada país pase la verificación de cobertura y match-rate.