[Beta]{class="badge informative"}

Experience Platform Data Mirror i åtanke

I den här artikeln beskrivs faktorer som du bör tänka på när du konfigurerar Data Mirror-datauppsättningar.

Ny kolumn till källtabell

När en ny kolumn läggs till i en källtabell i en CDC-aktiverad datamängd som speglas kan den ändringen utlösa uppdateringar för alla befintliga rader. Uppdateringarna bearbetas som ändringar via CDC, som:

  • Kan fungera som en fullständig tabellskrivning från ett progressivt perspektiv.
  • Kan drastiskt öka volymen för intag, vilket kan göra att uppdateringen överskrider dina behörigheter.

Rekommenderad strategi för kolumner i källtabellen:

  • Se till att alla relevanta kolumner är definierade från början.
  • Kartlägg alla kolumner du tror att du behöver från början.

Om du vill lägga till en ny kolumn finns det två alternativ, beroende på om retroaktiv bakåtfyllning krävs:

  • Retroaktiv bakfyllning:

    • Ta bort den aktuella datauppsättningen.
    • Konfigurera anslutningen igen med den uppdaterade kolumnen.

    Detta gör att informationen fylls i på nytt effektivare och snabbare.

  • Ingen retroaktiv bakgrundsfyllning:

    • Lägg till kolumnen i källtabellen.
    • Lägg till kolumnen i måldataset.
    • Uppdatera mappningen så att den inkluderar det nya fältet (kolumnen) från källtabellen till måldatauppsättningen.

Denna strategi:

  • Undvik kostsam schemautveckling senare (massuppdateringar när du lägger till kolumner).
  • Gör att volymen kan ändras mer förutsägbar än när kolumner läggs till eller ändras senare.
  • Hjälper till att begränsa potentiella beräkningskostnader på den externa databassidan eftersom datalagret kan tolka den nya kolumnen som en uppdatering för alla rader.

Privacy Service

Sekretessförfrågningar måste göras på samma sätt som sekretessförfrågningar hanteras i dag för icke-relationella scheman, eftersom sekretessförfrågningar inte har någon betydelse för hur data struktureras.

Data som speglas från ett externt relationsschema blir en del av Adobe ekosystem och kan delas i hela ekosystemet, till exempel via Customer Journey Analytics Audience Publishing. Genom att skicka in en begäran om sekretess säkerställs att identiteter och tillhörande data hanteras korrekt i hela Adobe ekosystem.

Därför bör förfrågningar om sekretess inte begränsas till den speglade datauppsättningen, utan även innehålla uppdateringar av källdata i den externa databasen.

Hygienbeteende

Hygientjänsten arbetar med primära identiteter, men tabeller i den externa databasen som är speglade har primära nycklar, inte primära identiteter.

Följden av skillnaden mellan primära identiteter och primärnycklar är att hygienborttagningar inte kan utföras direkt mot dessa relationstabeller. Därför måste du:

  • Ta bort data i sina egna källtabeller i datalagerlösningen och se till att borttagningsåtgärderna flödar genom CDC (eller den manuella ändringskolumnen).
  • Skicka frågor om hygien och sekretess till Adobe för XDM-baserade datauppsättningar längre fram i kedjan med identitetsinformation (till exempel: Customer Journey Analytics-vyer, Real-Time Customer Data Platform-dataset, Adobe Journey Optimizer-specifika datauppsättningar med mera).

Skillnaden mellan primär identitet och primärnyckel introducerar en modell för delat ansvar:

  • Adobe behandlar hygien där det finns identiteter.
  • Som kund ansvarar du för att anpassa dina egna hygienprocesser i källdatabasen till de hygienförfrågningar som skickas till Adobe.

Skillnader i styrformerna

I XDM scheman och underliggande koncept som fältgrupper sprids en definierad fältgrupp i en fältgrupp etiketter i alla datamängder där fältgruppen används. Ett e-postfält emailID i en fältgrupp identities får till exempel samma namn i alla datauppsättningar där fältgruppen identities används.

I ett relationsschema är ett kolumnnamn oberoende. En kolumn med namnet email i tabellen customers är oberoende av och skild från en kolumn med namnet email i en tabell prospects. Det här beteendet innebär att etiketter (som DULE-användningsetiketter, principer) måste tillämpas individuellt på fälten i de speglade datauppsättningarna. Baserat på ovanstående exempel måste du använda etiketter både för fältet email i customers-datamängden och för fältet email i datamängden prospects.

Skillnaden i styrningen har följande effekt:

  • Mer manuell styrning och konfigurering fungerar för dig som kund.
  • Du kanske behöver explicit vägledning, så du antar inte att engångsetiketter via fältgrupper räcker för korrekt styrning.

Stitlar

Relationsscheman har följande att tänka på när det gäller stygn:

  • Diagrambaserad sammanfogning stöds delvis. Relationsscheman kan inte aktiveras för profilen/bidra till diagrammet.
  • Fältbaserad sammanfogning stöds fullt ut.

Systemnycklar och fält

Följande gäller för systemnycklar och fält:

  • Den primära nyckeln, versionsbeskrivningen och tidsstämpelbeskrivningen måste vara rotnivåfält i XDM-relationsschemat. Använd fältmappning vid inmatning för att stödja detta krav.
  • Du kan utelämna lämpliga källfält under mappningsfasen.

Batchstorlek för speglade data

För alla speglade datauppsättningar som har konfigurerats som en del av en anslutning måste du se till att varje uppsättning som ska importera data för den speglade datauppsättningen inte överstiger 100 GB. Mer information finns i GuarDRAils for batch-ingång.

recommendation-more-help
analytics-platform-help-main