[Beta]{class="badge informative"}
Überlegungen zu Experience Platform Data Mirror
In diesem Artikel werden Faktoren beschrieben, die Sie beim Einrichten von Data Mirror-Datensätzen berücksichtigen sollten.
Neue Spalte in Quelltabelle
Wenn eine neue Spalte zu einer Quelltabelle in einem CDC-fähigen gespiegelten Datensatz hinzugefügt wird, kann diese Änderung Trigger-Aktualisierungen für alle vorhandenen Zeilen bewirken. Diese Aktualisierungen werden als Änderungen über die CDC verarbeitet, die:
- Kann sich aus fortschreitender Perspektive wie eine vollständige Tabellenumschreibung verhalten.
- Kann das Aufnahmevolumen erheblich erhöhen, was dazu führen kann, dass die Aktualisierung Ihre Aufnahmeberechtigung überschreitet.
Die empfohlene Strategie für Spalten in der Quelltabelle:
- Stellen Sie sicher, dass alle relevanten Spalten anfänglich definiert sind.
- Ordnen Sie zunächst alle Spalten zu, die Sie benötigen.
Wenn Sie eine neue Spalte hinzufügen möchten, gibt es zwei Optionen, je nachdem, ob eine rückwirkende Aufstockung erforderlich ist:
-
Rückwirkende Aufstockung:
- Entfernt den aktuellen Datensatz.
- Konfigurieren Sie den Connector erneut mit der aktualisierten Spalte.
Dadurch wird sichergestellt, dass die Daten effizienter und schneller aufgestockt werden.
-
Keine rückwirkende Aufstockung:
- Fügen Sie die Spalte in der Quelltabelle hinzu.
- Fügen Sie die Spalte im Zieldatensatzschema hinzu.
- Aktualisieren Sie die Zuordnung, um das neue Feld (Spalte) aus der Quelltabelle in den Zieldatensatz einzuschließen.
Diese Strategie:
- Vermeidet kostspielige Schemaentwicklung später (Massenaktualisierungen beim Hinzufügen von Spalten).
- Das Änderungsvolumen ist vorhersehbarer als beim späteren Hinzufügen oder Ändern von Spalten.
- Hilft bei der Begrenzung potenzieller Berechnungskosten auf der Seite der externen Datenbank, da das Data Warehouse die neue Spalte möglicherweise als Aktualisierung für alle Zeilen interpretiert.
Privacy Service
Datenschutzanfragen müssen auf die gleiche Weise verarbeitet werden wie heute bei nicht relationalen Schemata, da Datenschutzanfragen keine Rolle bei der Datenstruktur spielen.
Daten, die von einem externen relationalen Schema gespiegelt werden, werden Teil des Adobe-Ökosystems und können in diesem Ökosystem gemeinsam genutzt werden, z. B. über die Veröffentlichung von Customer Journey Analytics-Zielgruppen. Durch die Übermittlung einer Datenschutzanfrage wird sichergestellt, dass Identitäten und zugehörige Daten im gesamten Adobe-Ökosystem ordnungsgemäß verarbeitet werden.
Daher sollten Datenschutzanfragen nicht auf den gespiegelten Datensatz beschränkt sein, sondern auch Aktualisierungen der Quelldaten in der externen Datenbank umfassen.
Hygieneverhalten
Der Hygiene-Service arbeitet mit primären Identitäten, aber gespiegelte Tabellen in der externen Datenbank haben Primärschlüssel keine primären Identitäten.
Der Unterschied zwischen Primäridentitäten und Primärschlüsseln hat zur Folge, dass Löschvorgänge im Rahmen der Hygiene nicht direkt für diese relationalen Tabellen ausgeführt werden können. Daher müssen Sie:
- Löschen Sie Daten in ihren eigenen Quelltabellen innerhalb der Data Warehouse-Lösung und stellen Sie sicher, dass die Löschvorgänge über CDC (oder die Spalte für manuelle Änderungen) laufen.
- Senden Sie Hygiene- und Datenschutzanfragen an Adobe für alle nachgelagerten XDM-basierten Datensätze mit Identitätsinformationen (z. B. Customer Journey Analytics-Ansichten, Real-Time Customer Data Platform-Datensätze, Adobe Journey Optimizer-spezifische Datensätze usw.).
Der Unterschied zwischen primärer Identität und primärem Schlüssel führt zu einem Modell der gemeinsamen Verantwortung:
- Adobe verarbeitet die Hygiene, wenn Identitäten vorhanden sind.
- Als Kunde sind Sie dafür verantwortlich, Ihre eigenen Hygieneprozesse in der Quelldatenbank mit den an Adobe gesendeten Hygieneanfragen abzustimmen.
Governance-Unterschiede
In XDM Schemata und zugrunde liegenden Konzepten wie Feldergruppen propagiert ein definiertes Feld innerhalb einer Feldergruppe seine Kennzeichnungen über alle Datensätze hinweg, in denen die Feldergruppe verwendet wird. Beispiel: Ein E-Mail-Feld, das in einer identities Feldergruppe emailID wird, ist für alle Datensätze, in denen die identities verwendet wird, gleich beschriftet.
In einem relationalen Schema ist ein Spaltenname unabhängig. Eine Spalte mit dem Namen email in Tabelle customers ist unabhängig von einer Spalte mit dem Namen email in einer prospects und unterscheidet sich von dieser Spalte. Dieses Verhalten bedeutet, dass Kennzeichnungen (wie DULE-Nutzungskennzeichnungen, Richtlinien) einzeln auf die Felder in den gespiegelten Datensätzen angewendet werden müssen. Auf der Grundlage des obigen Beispiels müssen Sie Kennzeichnungen sowohl auf das email Feld im customers Datensatz als auch auf das email Feld im prospects Datensatz anwenden.
Der Unterschied bei der Governance hat folgende Auswirkungen:
- Mehr manuelle Governance und Konfiguration arbeiten für Sie als Kunde.
- Möglicherweise benötigen Sie eine explizite Anleitung, sodass Sie nicht davon ausgehen, dass eine einmalige Kennzeichnung über Feldergruppen für eine ordnungsgemäße Governance ausreicht.
Zuordnung
Relationale Schemata haben hinsichtlich des Zusammenfügens die folgenden Einschränkungen:
- Diagrammbasiertes Stitching wird teilweise unterstützt. Relationale Schemata können nicht für das Profil bzw. den Beitrag zum Diagramm aktiviert werden.
- Feldbasiertes Stitching wird vollständig unterstützt.
Systemschlüssel und -felder
Die folgenden Überlegungen gelten für Systemschlüssel und -felder:
- Primärschlüssel, Versionsdeskriptor und Zeitstempeldeskriptor müssen Felder auf Stammebene im relationalen XDM-Schema sein. Verwenden Sie Feldzuordnung während der Aufnahme, um diese Anforderung zu unterstützen.
- Sie können die entsprechenden Quellfelder während der Zuordnungsphase auslassen.