Bacardi Concepts MDM

Bacardi opera seis sistemas SFA regionales, cada uno con su propio dialecto del mismo catálogo de producto. Construimos un pipeline de entity resolution sobre Databricks que ingiere cerca de un millón de registros, los normaliza con reglas y una cascada de LLMs Claude, los deduplica en una única lista golden y matchea cada superviviente contra la jerarquía UPH corporativa. La salida es un master record versionado en SCD2 e indexado con embeddings, listo para stewardship y analítica downstream.

Mi rol

Lead de arquitectura de datos

Período

2026

Estado

En producción

Stack

DatabricksPySparkDelta LakeMosaic AI Vector SearchClaude LLMsEmbeddingsSCD2

La realidad comercial de Bacardi está fragmentada por diseño: cada región opera su propia plataforma SFA y la misma botella, marca o concepto de cóctel aparece bajo seis esquemas distintos sin identificador compartido. Una «Bouteille» francesa y un «Bottle» inglés son literalmente filas distintas. La reconciliación por clave directa es imposible y, sin una golden list unificada, cada iniciativa downstream — pricing, listings, analítica, la propia UPH — hereda ambigüedad, atributos contradictorios y trabajo duplicado. El mandato fue consolidar la flota SFA en una única lista master deduplicada, auditada y gobernada, y matchear cada concepto al nivel correcto de UPH (marca, líquido o producto). Dentro hay dos problemas ortogonales: entity resolution dentro de los datos de origen y matching contra la jerarquía corporativa. El pipeline tenía que ser repetible, idempotente y capaz de evolucionar de una corrida única de seed a un flujo incremental diario, sin reejecutar la deduplicación completa cada noche.

Pipeline de Databricks por etapas que convierte seis catálogos SFA fragmentados en un único master golden versionado en SCD2 e indexado vectorialmente, alineado contra la jerarquía corporativa de producto.

1. Seed de referencia — overrides de stewards, diccionarios de display y tablas de revisión en la capa curada.
2. Segregación PRODUCT vs NON_PRODUCT con diccionario estático y cascada Claude Haiku-Sonnet-Opus para casos ambiguos.
3. Armonización de tipo de material, marca, categoría y volumen; canonicalización de marca contra UPH vía embeddings.
4. Deduplicación exacta por clave compuesta y deduplicación semántica con embeddings más juez Claude por cluster.
5. Match contra UPH ruteado por tipo de material a marca, líquido o producto con coseno filtrado y fallback.
6. Enriquecimiento del golden retropoblado vía MERGE INTO una vez conocido el contexto UPH.
7. Ensamblado del lineage para que cada fila origen mapee a su concepto golden y a su entidad UPH.
8. Publicación de embeddings al índice de Mosaic AI Vector Search en modo DELTA_SYNC para matching incremental.
9. Pipeline incremental diario que rutea filas nuevas a AutoApproved, PendingReview o PendingCreation con override previo.
10. Cola unificada de stewardship que persiste matches ambiguos y reincorpora decisiones como reglas autoritativas.

Estandarizar, después deduplicar, después matchear — nunca al revés.

Las cadenas multilingües («Bouteille» frente a «Bottle») generan falsos no-matches si se deduplica antes de normalizar. Y matchear antes de deduplicar gasta cómputo y produce asignaciones UPH contradictorias para lo que es el mismo concepto.

Juez LLM por cluster, no por pares.

Los jueces pareados generan contradicciones de transitividad — A=B, B=C, A≠C — cuando un miembro ambiguo conecta clusters distintos. Presentar el cluster completo a Claude Sonnet para particionarlo elimina la paradoja por construcción y reduce el gasto en API.

La UPH como única fuente de verdad para nombres canónicos de marca.

Los mapas hardcodeados de marca canónica derivan, acumulan typos y resisten la gobernanza. Sustituirlos por un match por embeddings contra la tabla de marcas UPH convierte a la jerarquía corporativa en la autoridad y al drift en una cola medible de revisión.

El seed es one-shot; el incremental es otro código.

Reutilizar el pipeline de seed para el flujo diario rompe la idempotencia y el contrato de golden_id por posición. El incremental se replantea como problema de matching contra el golden congelado, sostenido por Mosaic AI Vector Search en modo DELTA_SYNC.

SCD2 sobre el golden antes de cualquier escritura incremental.

Los IDs golden por posición no sobreviven a nuevas llegadas ni a cambios de atributo sin romper claves foráneas downstream. Promover la tabla golden a SCD2 completo convierte el golden_id en una clave de negocio estable y vuelve consultable la historia de matching.

Revisión adversarial antes de implementar specs de riesgo.

Una pasada de devil's advocate sobre specs de migración detectó bugs semánticos — mutación de columnas entre etapas, divergencia de tipos pre- y post-LLM — que el flujo estándar engineer-then-reviewer habría dejado pasar y que habrían costado varios ciclos de re-deploy en Dev.

• Los embeddings sobre claves compuestas (marca | nombre | categoría) superan al fuzzy matching de cadenas en catálogos multilingües y con abreviaturas.
• Los LLMs desbloquean registros con campos sparse de manera fiable: Claude Haiku resuelve el grueso de la extracción y los modelos mayores cubren la cola larga con coste razonable.
• Las claves primarias por posición son una trampa en cuanto el pipeline pasa a incremental: hay que diseñar la estabilidad SCD2 desde el día uno si algún consumidor downstream va a referenciar esos IDs.
• `NaN != NaN` en merges de pandas tira filas en silencio sobre claves nullables; rellenar con sentinela antes de cualquier merge no es opcional.
• Cada filtro o aserción añadida a un pipeline maduro es un detector de bugs latentes: la primera corrida end-to-end tras desplegarlo destapa corrupción de estado acumulada que las fallas previas enmascaraban.
• Las listas hardcodeadas de «columnas en riesgo» derivan con cada cambio de schema; la auto-detección por dtype es el patrón de defensa duradero.

• Una única golden list deduplicada que reconcilia toda la flota SFA, trazable end-to-end desde la fila origen hasta el record canónico y la entidad UPH.
• Cada concepto de producto ruteado al nivel correcto de la jerarquía corporativa — marca, líquido o producto — con bandas explícitas de auto-match, revisión y unmatched.
• Índice de Mosaic AI Vector Search sobre el master golden, que habilita matching incremental sub-segundo de registros nuevos sin rededuplicar el corpus.
• Historial SCD2 sobre el golden record, de forma que la evolución de atributos y las decisiones de stewards quedan auditables, reversibles y consultables en el tiempo.
• Cola unificada de stewardship que expone matches ambiguos y creaciones pendientes al equipo comercial y reinyecta sus decisiones al pipeline como overrides autoritativos.
• Estructura de jobs Databricks idempotente y parametrizada donde cada task mapea uno-a-uno con su wrapper, eliminando drift entre entornos y haciendo mecánica la promoción DEV → QA.

Estado actual

Seed congelado y validado end-to-end sobre datos productivos; SCD2 e índice de Vector Search vivos sobre el golden; pipeline incremental con cadena serial — match contra golden, minting de creaciones pendientes, evolución del golden con autorización híbrida del steward y revivido de goldens borrados — operando en desarrollo.

Próximos pasos

Cutover a QA, despliegue de las tablas unificadas de override y review-queue en producción, integración con la stewardship app para resolución de cola en vivo, y rollout del writer de borrado origen que cierra el ciclo del incremental.