Mapear DLOs a DMOs — cómo hacerlo en Data 360
Cómo se asigna el significado en Data 360: el flujo desde los campos de un Data Lake Object hacia los atributos de un Data Model Object, las transformaciones disponibles en el camino, y los errores de mapping que producen data equivocada en silencio downstream.
El mapping es el paso donde la data cruda ingerida se vuelve significativa: conectás los campos de un Data Lake Object con los atributos de un Data Model Object. Es la decisión más consecuente del modelo y la menos visible — un mapping equivocado no tira ningún error, simplemente produce valores equivocados o vacíos en todos lados downstream.
El flujo de mapping
- Ingerí — un Data Stream aterriza data en un DLO.
- Elegí el DMO destino — un DMO estándar cuando se pueda (Individual, Contact Point Email), uno custom solo cuando sea defendible.
- Mapeá campos a atributos — conectá cada campo del DLO con el atributo del DMO que carga su significado. Hacé match por significado, no solo por un nombre de columna parecido.
- Seteá la primary key y las relaciones — decile a Data 360 (antes Data Cloud) qué identifica una fila y cómo se relaciona con otros DMOs.
- Validá — confirmá que los valores aterrizan en los atributos correctos contra data de muestra real antes de que algo downstream lea.
Referencia:
Qué sobrevive en producción
Mapeá por significado, no por nombre de columna
Un campo origen llamado state puede contener un estado de EE.UU., un estado de proceso, o un código de país según el sistema. Mapearlo al atributo del DMO que coincide con el nombre en vez del significado es cómo un campo state termina mapeado a country. Leé qué contiene realmente el campo en el origen antes de mapearlo.
Nunca dejes un atributo requerido sin mapear
Un atributo requerido sin mapear no tira error — produce blancos que se propagan a cada segmento e insight. Tratá los atributos requeridos de cada DMO como un checklist que tiene que estar completamente satisfecho antes de dar el mapping por terminado.
Normalizá en el camino de entrada
El mapping es el lugar natural para normalizar: recortar espacios, pasar emails a minúscula, estandarizar códigos de país. Normalizar una vez en la capa de mapping le gana a que cada consumidor downstream normalice distinto — la misma lógica de "computá una vez" que vuelve confiable a un Calculated Insight.
Revisá los mappings como un entregable
Un mapping es código: merece un revisor que chequee cada campo contra la semántica real del origen. El costo de saltarse la revisión es corrupción de data silenciosa descubierta semanas después en una campaña mal apuntada.
Errores comunes de mapping
- Atributo equivocado —
statemapeado acountry,createdmapeado amodified. Silencioso, y mal en todos lados. - Type mismatch — una fecha guardada como texto en el origen mapeada a un atributo de fecha; o falla al parsear o coerce de forma impredecible.
- Campo requerido sin mapear — blancos downstream, sin warning.
- Mapear un DLO uno-a-uno a un DMO sin armonizar — reubica el desorden del origen en vez de modelarlo.
Relacionado
- Gotchas de arquitectura de Data 360 — las decisiones de modelo que sobreviven a todo
- Data Lake Objects (DLOs) — la capa cruda desde la que mapeás
- Data Model Objects (DMOs) — la capa armonizada a la que mapeás
- Data Architecture Style Guide — la disciplina que ata estas decisiones de modelo