Dubbele gegevens verwerken in Azure Data Explorer

Apparaten die gegevens naar de cloud verzenden, onderhouden een lokale cache van de gegevens. Afhankelijk van de gegevensgrootte kan de lokale cache gegevens gedurende dagen of zelfs maanden opslaan. U wilt uw analytische databases beschermen tegen defecte apparaten die de gegevens in de cache opnieuw verzenden en gegevensduplicatie in de analytische database veroorzaken. Duplicaten kunnen van invloed zijn op het aantal records dat door een query wordt geretourneerd. Dit probleem is relevant wanneer u een nauwkeurig aantal records nodig hebt, zoals bij het tellen van gebeurtenissen. In dit artikel vindt u een overzicht van aanbevolen procedures voor het verwerken van dubbele gegevens voor dit soort scenario's.

De beste oplossing voor gegevensduplicatie is het voorkomen van duplicatie. Los indien mogelijk het probleem eerder in de gegevenspijplijn op. Met deze aanpak worden kosten bespaard die zijn gekoppeld aan gegevensverplaatsing in de gegevenspijplijn en worden er geen uitgaven besteed aan het verwerken van dubbele gegevens die in het systeem zijn opgenomen. In situaties waarin u het bronsysteem niet kunt wijzigen, kunt u echter verschillende methoden gebruiken om dit scenario aan te pakken.

Inzicht in de impact van dubbele gegevens

Bewaak het percentage dubbele gegevens. Zodra u het percentage dubbele gegevens hebt gedetecteerd, kunt u het bereik van het probleem en de bedrijfsimpact analyseren en de juiste oplossing kiezen.

Voorbeeldquery om het percentage dubbele records te identificeren:

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

Oplossingen voor het verwerken van dubbele gegevens

Oplossing 1: Dubbele gegevens niet verwijderen

Inzicht in uw zakelijke vereisten en tolerantie voor dubbele gegevens. Sommige datasets kunnen omgaan met een bepaald percentage dubbele gegevens. Als de gedupliceerde gegevens geen grote invloed hebben, kunt u de aanwezigheid negeren. Het voordeel van het niet verwijderen van de dubbele gegevens is dat er geen extra overhead wordt toegevoegd aan het opnameproces of de queryprestaties.

Oplossing 2: dubbele rijen verwerken tijdens query

Een andere optie is om de dubbele rijen in de gegevens tijdens de query uit te filteren. U kunt de arg_max() aggregatiefunctie gebruiken om de dubbele records uit te filteren en de laatste record te retourneren op basis van de tijdstempel (of een andere kolom). Het voordeel van het gebruik van deze methode is een snellere opname omdat ontdubbeling plaatsvindt tijdens de querytijd. Daarnaast zijn alle records (inclusief duplicaten) beschikbaar voor controle en probleemoplossing. Het nadeel van het gebruik van de arg_max functie is de extra querytijd en de belasting van de CPU telkens wanneer de gegevens worden opgevraagd. Afhankelijk van de hoeveelheid gegevens die wordt opgevraagd, kan deze oplossing niet-functioneel of geheugengebruik worden en moet u overschakelen naar andere opties.

In het volgende voorbeeld wordt een query uitgevoerd op de laatste record die is opgenomen voor een set kolommen die de unieke records bepalen:

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

U kunt deze query ook in een functie plaatsen in plaats van rechtstreeks een query uit te voeren op de tabel:

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

Oplossing 3: Gebruik materialized views om duplicaten te verwijderen

U kunt gerealiseerde weergaven gebruiken voor ontdubbeling met behulp van de aggregatiefuncties take_any()//arg_max() (zie voorbeeld 4 in de opdracht voor het maken van gerealiseerde weergaven).

Opmerking

Gerealiseerde weergaven verbruiken clusterbronnen, wat mogelijk niet te verwaarlozen is. Zie prestatieoverwegingen voor gerealiseerde weergaven voor meer informatie.

Oplossing 4: Gebruik 'soft delete' om duplicaten te verwijderen

Voorlopig verwijderen ondersteunt de mogelijkheid om afzonderlijke records te verwijderen, zodat u deze kunt gebruiken om duplicaten te verwijderen. Gebruik deze optie alleen voor onregelmatige verwijderingen, niet als u voortdurend alle binnenkomende records moet ontdubbelen.

Kies tussen gematerialiseerde weergaven en zachte verwijdering voor gegevensontdubbeling

Houd rekening met de volgende factoren bij het kiezen tussen materialized views en soft delete voor ontdubbeling:

  • Beheer en orkestratie: gematerialiseerde weergaven zijn een volledig beheerde oplossing. U definieert eenmaal een weergave en het systeem verwerkt ontdubbeling voor alle binnenkomende records. Voor soft delete zijn coördinatie en beheer vereist. Als gerealiseerde weergaven voor uw gebruikssituatie werken, kies dan deze optie.
  • Wanneer records worden ontdubbeld: Met voorlopig verwijderen voegt u eerst dubbele records toe aan een tabel en verwijdert u deze. Tussen de opname- en voorlopig verwijderen-processen bevat de tabel dus duplicaten. Met materialized views worden records in de weergave altijd ontdubbeld, omdat het systeem ze ontdubbelt voordat ze in de weergave worden opgenomen.
  • Frequentie: Als u een tabel voortdurend wilt ontdubbelen, gebruikt u gerealiseerde weergaven. Als duplicaten zeldzaam zijn en u deze tijdens de opname kunt identificeren, presteert het proces voor soft delete meestal beter dan gematerialiseerde views. Als uw data-invoer doorgaans geen duplicaten bevat, maar af en toe een stream bevat waarvan bekend is dat deze wel duplicaten bevat, is het beter om deze duplicaten met soft delete te verwerken in plaats van een materialized view te definiëren die voortdurend probeert om alle records te ontdubbelen.

Oplossing 5: ingest-by omvangstags

U kunt 'ingest-by:' extent tags gebruiken om duplicaten tijdens opname te voorkomen. Deze oplossing is alleen relevant in gebruiksvoorbeelden waarbij elke opnamebatch geen duplicaten heeft en duplicaten alleen voorkomen als dezelfde opnamebatch meerdere keren wordt opgenomen.

Samenvatting

U kunt gegevensduplicatie op meerdere manieren afhandelen. Evalueer de opties zorgvuldig, rekening houdend met prijs en prestaties, om de beste methode voor uw bedrijf te bepalen.

Verwante inhoud

  • Laatst bijgewerkt om