Share via

Gestire i dati duplicati in Esplora dati di Azure

  • Articolo

I dispositivi che inviano dati al cloud mantengono una cache locale dei dati. A seconda delle dimensioni dei dati, la cache locale potrebbe archiviare i dati per giorni o anche mesi. Si vogliono proteggere i database analitici dai dispositivi non funzionanti che inviano di nuovo i dati memorizzati nella cache e causano la duplicazione dei dati nel database analitico. I duplicati possono influire sul numero di record restituiti da una query. Ciò è rilevante quando è necessario un conteggio preciso dei record, ad esempio il conteggio degli eventi. Questo argomento descrive le procedure consigliate per la gestione dei dati duplicati per questi tipi di scenari.

La soluzione migliore per la duplicazione dei dati è evitare la duplicazione. Se possibile, risolvere il problema prima nella pipeline di dati, risparmiando così sui costi associati allo spostamento dati lungo la pipeline di dati ed evitando di sprecare risorse per gestire i dati duplicati inseriti nel sistema. Nelle situazioni in cui il sistema di origine non può essere modificato, esistono tuttavia diversi modi per gestire questo scenario.

Informazioni sull'impatto dei dati duplicati

Monitorare la percentuale di dati duplicati. Dopo che è stata rilevata la percentuale di dati duplicati, è possibile analizzare l'ambito del problema e l'impatto aziendale e scegliere la soluzione appropriata.

Query di esempio per identificare la percentuale di record duplicati:

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

Soluzioni di gestione dei dati duplicati

Soluzione 1: Non rimuovere i dati duplicati

È importante conoscere i requisiti aziendali e la tolleranza dei dati duplicati. Alcuni set di dati possono gestire una certa percentuale di dati duplicati. Se i dati duplicati non hanno un impatto significativo, è possibile ignorarne la presenza. Il vantaggio di non rimuovere i dati duplicati è che non vengono generati overhead aggiuntivi nel processo di inserimento o nelle prestazioni delle query.

Soluzione 2: Gestire le righe duplicate durante la query

È anche possibile filtrare le righe duplicate nei dati durante la query. La funzione di aggregazione arg_max() può essere usata per filtrare i record duplicati e restituire l'ultimo record in base al timestamp (o a un'altra colonna). Il vantaggio dell'uso di questo metodo è un inserimento più rapido perché durante la fase di query si verifica la deduplicazione. Tutti i record (inclusi quelli duplicati) sono inoltre disponibili per il controllo e la risoluzione dei problemi. Lo svantaggio di usare la funzione arg_max è la maggior durata della query e il carico sulla CPU ogni volta che viene eseguita una query dei dati. A seconda della quantità dei dati sottoposti a query, questa soluzione potrebbe diventare non funzionale o utilizzare troppa memoria e sarà necessario passare ad altre opzioni.

Nell'esempio seguente viene eseguita una query dell'ultimo record inserito per trovare un set di colonne che determinano i record univoci:

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

Questa query può anche essere inserita all'interno di una funzione invece di eseguire direttamente una query sulla tabella:

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

Soluzione 3: Usare viste materializzate per deduplicare

Le viste materializzate possono essere usate per la deduplicazione usando le funzioni di aggregazione take_any()arg_min()//arg_max() (vedere l'esempio 4 nella creazione di viste materializzate).

Nota

Le viste materializzate comportano un costo per l'utilizzo delle risorse del cluster, che potrebbero non essere trascurabili. Per altre informazioni, vedere Considerazioni sulle prestazioni delle viste materializzate.

Soluzione 4: Usare l'eliminazione temporanea per rimuovere i duplicati

L'eliminazione temporanea supporta la possibilità di eliminare singoli record e può quindi essere usata per eliminare i duplicati. Questa opzione è consigliata solo per le eliminazioni non frequenti e non se è costantemente necessario deduplicare tutti i record in ingresso.

Scegliere tra viste materializzate ed eliminazione temporanea per la deduplicazione dei dati

Esistono diverse considerazioni che consentono di scegliere tra l'uso di viste materializzate o l'eliminazione temporanea per la deduplicazione:

  • Gestione e orchestrazione: le viste materializzate sono una soluzione completamente gestita. Una vista viene definita una sola volta e il sistema gestisce la deduplicazione di tutti i record in ingresso. L'eliminazione temporanea richiede orchestrazione e gestione. Pertanto, se le visualizzazioni materializzate funzionano per il caso d'uso, è consigliabile scegliere sempre questa opzione.
  • Quando i record vengono deduplicati: con l'eliminazione temporanea, i record duplicati vengono prima aggiunti a una tabella e vengono quindi eliminati; di conseguenza, tra i processi di inserimento e eliminazione temporanea, la tabella contiene duplicati. Con le viste materializzate, i record in visualizzazione verranno sempre deduplicati, man mano che vengono deduplicati prima di entrare nella visualizzazione.
  • Frequenza: se una tabella deve essere costantemente deduplicata, utilizzare viste materializzate. Se si prevede che i duplicati non saranno frequenti e si è in grado di identificarli durante l'inserimento, il processo di eliminazione temporanea offre in genere prestazioni migliori rispetto alle viste materializzate. Ad esempio, se si verifica una situazione in cui gli inserimenti non hanno in genere duplicati, ma occasionalmente si inserisce un flusso noto per contenere duplicati. In questo scenario, è preferibile gestire questi duplicati usando l'eliminazione temporanea rispetto alla definizione di una vista materializzata che tenterà costantemente di deduplicare tutti i record.

Soluzione 5: ingest-by tag extent

I tag extent "ingest-by:" possono essere usati per impedire duplicati durante l'inserimento. Ciò è rilevante solo nei casi d'uso in cui ogni batch di inserimento non ha duplicati e i duplicati sono previsti solo se lo stesso batch di inserimento viene inserito più volte.

Riepilogo

La duplicazione dei dati può essere gestita in diversi modi. Valutare le opzioni con attenzione, tenendo conto del prezzo e delle prestazioni, per determinare il metodo corretto per la propria azienda.

Contenuti correlati