Freigeben über

Behandeln von doppelten Daten in Azure Data Explorer

  • Artikel

Geräte, die Daten an die Cloud senden, speichern diese in einem lokalen Cache zwischen. Je nach Größe der Daten werden diese unter Umständen über Tage oder sogar Monate im lokalen Cache gespeichert. Es empfiehlt sich, Ihre Analysedatenbanken vor fehlerhaften Geräten zu schützen, die die zwischengespeicherten Daten erneut senden und so zu duplizierten Daten in der Analysedatenbank führen. Duplikate können sich auf die Anzahl der von einer Abfrage zurückgegebenen Datensätze auswirken. Dies ist relevant, wenn Sie eine genaue Anzahl von Datensätzen benötigen, z. B. beim Zählen von Ereignissen. In diesem Thema werden bewährte Methoden für den Umgang mit doppelten Daten in Szenarien dieser Art beschrieben.

Im günstigsten Fall wird eine Datenduplizierung von vornherein verhindert. Beheben Sie das Problem nach Möglichkeit bereits frühzeitig in der Datenpipeline. Das spart Kosten für die Verschiebung von Daten entlang der Datenpipeline und vermeidet den Einsatz von Ressourcen für die Behandlung doppelter Daten, die im System erfasst wurden. In Situationen, in denen das Quellsystem nicht geändert werden kann, gibt es verschiedene andere Möglichkeiten für den Umgang mit diesem Szenario.

Grundlegendes zu den Auswirkungen doppelter Daten

Überwachen Sie den prozentualen Anteil doppelter Daten. Nach Ermittlung des prozentualen Anteils doppelter Daten können Sie den Umfang und die geschäftlichen Auswirkungen des Problems analysieren und geeignete Maßnahmen ergreifen.

Beispielabfrage zur Ermittlung des prozentualen Anteils doppelter Datensätze:

let _sample = 0.01; // 1% sampling
let _data =
DeviceEventsAll
| where EventDateTime between (datetime('10-01-2018 10:00') .. datetime('10-10-2018 10:00'));
let _totalRecords = toscalar(_data | count);
_data
| where rand()<= _sample
| summarize recordsCount=count() by hash(DeviceId) + hash(EventId) + hash(StationId)  // Use all dimensions that make row unique. Combining hashes can be improved
| summarize duplicateRecords=countif(recordsCount  > 1)
| extend duplicate_percentage = (duplicateRecords / _sample) / _totalRecords

Lösungen für den Umgang mit doppelten Daten

Lösung 1: Beibehalten doppelter Daten

Untersuchen Sie Ihre geschäftlichen Anforderungen und die Toleranz gegenüber doppelten Daten. Bei manchen Datasets ist ein gewisser prozentualer Anteil doppelter Daten kein Problem. Wenn die duplizierten Daten keine größeren Auswirkungen haben, können Sie sie einfach ignorieren. Vorteil: Es entsteht kein Zusatzaufwand bei der Datenerfassung, und die Abfrageleistung wird nicht beeinträchtigt.

Lösung 2: Verarbeiten doppelter Zeilen während der Abfrage

Die doppelten Datenzeilen können auch beim Abfragen herausgefiltert werden. Mit der Aggregatfunktion arg_max() können Sie die doppelten Datensätze herausfiltern und den letzten Datensatz auf der Grundlage des Zeitstempels (oder einer anderen Spalte) zurückgeben. Vorteil: Die Datenerfassung wird beschleunigt, da die Deduplizierung bereits bei der Abfrage erfolgt. Darüber hinaus stehen alle Datensätze (einschließlich Duplikate) für die Überwachung und Problembehandlung zur Verfügung. Nachteil: Durch die Verwendung der Funktion arg_max erhöhen sich bei jeder Datenabfrage die Abfragezeit und die CPU-Last. Je nach abgefragter Datenmenge kann es vorkommen, dass die Lösung nicht mehr funktioniert oder zu viel Arbeitsspeicher benötigt und auf eine andere Option ausgewichen werden muss.

Im folgenden Beispiel wird der zuletzt erfasste Datensatz für eine Gruppe von Spalten abgefragt, die die eindeutigen Datensätze bestimmen:

DeviceEventsAll
| where EventDateTime > ago(90d)
| summarize hint.strategy=shuffle arg_max(EventDateTime, *) by DeviceId, EventId, StationId

Diese Abfrage kann auch in einer Funktion platziert werden, anstatt die Tabelle direkt abzufragen:

.create function DeviceEventsView
{
    DeviceEventsAll
    | where EventDateTime > ago(90d)
    | summarize arg_max(EventDateTime, *) by DeviceId, EventId, StationId
}

Lösung 3: Verwenden von materialisierten Sichten für die Deduplizierung

Materialisierte Sichten können für die Deduplizierung unter Verwendung der Aggregationsfunktionen take_any()/arg_min()/arg_max() verwendet werden (siehe Beispiel 4: Befehl zum Erstellen materialisierter Sichten).

Hinweis

Materialisierte Sichten sind mit Kosten für die Nutzung von Clusterressourcen verbunden, die möglicherweise nicht unerheblich sind. Weitere Informationen finden Sie im Artikel zu materialisierten Sichten im Abschnitt Überlegungen zur Leistung.

Lösung 4: Verwenden von vorläufigem Löschen zum Entfernen von Duplikaten

Das vorläufige Löschen unterstützt die Möglichkeit zum Löschen einzelner Datensätze und kann daher zum Löschen von Duplikaten verwendet werden. Diese Option wird nur für seltene Löschvorgänge empfohlen, nicht, wenn Sie ständig alle eingehenden Datensätze deduplizieren müssen.

Wahl zwischen materialisierten Sichten und vorläufigem Löschen für die Datendeduplizierung

Es gibt mehrere Überlegungen, die Ihnen bei der Wahl zwischen materialisierten Sichten oder dem vorläufigen Löschen für die Deduplizierung helfen können:

  • Verwaltung und Orchestrierung: Materialisierte Sichten sind eine vollständig verwaltete Lösung. Eine Sicht wird einmal definiert, und das System übernimmt die Deduplizierung aller eingehenden Datensätze. Für vorläufiges Löschen sind Orchestrierung und Verwaltung erforderlich. Wenn materialisierte Sichten sich für Ihren Anwendungsfall eignen, sollten Sie daher immer diese Option wählen.
  • Wenn Datensätze dedupliziert werden: Beim vorläufigen Löschen werden doppelte Datensätze einer Tabelle zuerst hinzugefügt und dann gelöscht. Daher enthält die Tabelle zwischen dem Erfassungs- und dem vorläufigen Löschvorgang Duplikate. Bei materialisierten Sichten sind die in der Sicht enthaltenen Datensätze immer dedupliziert, da die Deduplizierung vor dem Eintritt in die Ansicht erfolgt.
  • Häufigkeit: Wenn eine Tabelle ständig dedupliziert werden muss, verwenden Sie materialisierte Sichten. Wenn Sie davon ausgehen, dass Duplikate selten sind, und Sie sie während der Erfassung identifizieren können, erbringt der Prozess des vorläufigen Löschens in der Regel bessere Leistung als materialisierte Sichten. Gehen Sie beispielsweise von einer Situation aus, in der Ihre Erfassungen normalerweise keine Duplikate aufweisen, sie aber gelegentlich einen Stream erfassen, von dem bekannt ist, dass er Duplikate enthält. In diesem Szenario ist es besser, diese Duplikate mithilfe von vorläufigem Löschen zu behandeln, als eine materialisierte Sicht zu definieren, die ständig versucht, alle Datensätze zu deduplizieren.

Lösung 5: ingest-by-Umfangs-Tags

Umfangs-Tags vom Typ 'ingest-by:' können verwendet werden, um Duplikate bei der Erfassung zu verhindern. Dies ist nur in Anwendungsfällen relevant, in denen jeder Erfassungsbatch garantiert keine Duplikate aufweist und Duplikate nur erwartet werden, wenn derselbe Erfassungsbatch mehr als einmal erfasst wird.

Zusammenfassung

Datenduplizierung kann auf verschiedene Arten behandelt werden. Sehen Sie sich die Optionen sorgfältig an, um unter Berücksichtigung von Preis- und Leistungsaspekten die passende Methode für Ihr Unternehmen zu ermitteln.

Zugehöriger Inhalt