Udostępnij za pośrednictwem

Obsługa zduplikowanych danych w usłudze Azure Data Explorer

  • Artykuł

Urządzenia wysyłające dane do chmury utrzymują lokalną pamięć podręczną danych. W zależności od rozmiaru danych lokalna pamięć podręczna może przechowywać dane przez dni, a nawet miesiące. Chcesz zabezpieczyć analityczne bazy danych przed awarią urządzeń, które ponownie wyśliją buforowane dane i powodują duplikowanie danych w analitycznej bazie danych. Duplikaty mogą mieć wpływ na liczbę rekordów zwracanych przez zapytanie. Jest to istotne, gdy potrzebna jest dokładna liczba rekordów, takich jak zliczanie zdarzeń. W tym temacie opisano najlepsze rozwiązania dotyczące obsługi zduplikowanych danych dla tego typu scenariuszy.

Najlepszym rozwiązaniem do duplikowania danych jest zapobieganie duplikowaniu. Jeśli to możliwe, rozwiąż problem wcześniej w potoku danych, co pozwala zaoszczędzić koszty związane z przenoszeniem danych wzdłuż potoku danych i unika wydatków na radzenie sobie z zduplikowanymi danymi pozyskanymi do systemu. Jednak w sytuacjach, w których nie można zmodyfikować systemu źródłowego, istnieją różne sposoby radzenia sobie z tym scenariuszem.

Omówienie wpływu zduplikowanych danych

Monitoruj procent zduplikowanych danych. Po odnalezieniu procentu zduplikowanych danych można przeanalizować zakres problemu i wpływu biznesowego i wybrać odpowiednie rozwiązanie.

Przykładowe zapytanie identyfikujące procent zduplikowanych rekordów:

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

Rozwiązania do obsługi zduplikowanych danych

Rozwiązanie nr 1: Nie usuwaj zduplikowanych danych

Poznaj wymagania biznesowe i tolerancję zduplikowanych danych. Niektóre zestawy danych mogą zarządzać określonym procentem zduplikowanych danych. Jeśli zduplikowane dane nie mają poważnego wpływu, możesz zignorować jego obecność. Zaletą braku usuwania zduplikowanych danych nie jest dodatkowe obciążenie związane z procesem pozyskiwania ani wydajnością zapytań.

Rozwiązanie nr 2: Obsługa zduplikowanych wierszy podczas wykonywania zapytania

Inną opcją jest odfiltrowanie zduplikowanych wierszy w danych podczas wykonywania zapytania. Zagregowana arg_max() funkcja może służyć do filtrowania zduplikowanych rekordów i zwracania ostatniego rekordu na podstawie znacznika czasu (lub innej kolumny). Zaletą korzystania z tej metody jest szybsze pozyskiwanie, ponieważ deduplikacja występuje w czasie zapytania. Ponadto wszystkie rekordy (w tym duplikaty) są dostępne do przeprowadzania inspekcji i rozwiązywania problemów. Wadą korzystania z arg_max funkcji jest dodatkowy czas zapytania i obciążenie procesora CPU za każdym razem, gdy są wykonywane zapytania dotyczące danych. W zależności od ilości danych, których dotyczy zapytanie, to rozwiązanie może stać się niefunkcjonalne lub zużywane przez pamięć i będzie wymagać przełączenia na inne opcje.

W poniższym przykładzie wysyłamy zapytanie dotyczące ostatniego rekordu pozyskanego dla zestawu kolumn, które określają unikatowe rekordy:

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

To zapytanie można również umieścić wewnątrz funkcji zamiast bezpośrednio wykonywać zapytania względem tabeli:

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

Rozwiązanie nr 3: Używanie zmaterializowanych widoków do deduplikacji

Zmaterializowane widoki mogą służyć do deduplikacji przy użyciu funkcji agregacji take_any()arg_min()//arg_max() (zobacz przykład #4 w zmaterializowanym poleceniu create widoku).

Uwaga

Zmaterializowane widoki mają koszt zużywania zasobów klastra, co może nie być niewielkie. Aby uzyskać więcej informacji, zobacz zmaterializowane zagadnienia dotyczące wydajności widoków.

Rozwiązanie nr 4: Usuwanie nietrwałe służy do usuwania duplikatów

Usuwanie nietrwałe obsługuje możliwość usuwania poszczególnych rekordów i dlatego może służyć do usuwania duplikatów. Ta opcja jest zalecana tylko w przypadku rzadkich usuwania, a nie w przypadku ciągłego deduplikacji wszystkich rekordów przychodzących.

Wybieranie między zmaterializowanymi widokami a usuwaniem nietrwałym na potrzeby deduplikacji danych

Istnieje kilka zagadnień, które mogą pomóc w wyborze między używaniem zmaterializowanych widoków lub usuwania nietrwałego na potrzeby deduplikacji:

  • Zarządzanie i aranżacja: zmaterializowane widoki są w pełni zarządzanym rozwiązaniem. Widok jest definiowany raz, a system obsługuje deduplikację wszystkich rekordów przychodzących. Usuwanie nietrwałe wymaga orkiestracji i zarządzania. W związku z tym, jeśli zmaterializowane widoki działają w twoim przypadku użycia, zawsze należy wybrać tę opcję.
  • Gdy rekordy są deduplikowane: po usunięciu nietrwałym do tabeli są najpierw dodawane zduplikowane rekordy, a następnie usuwane. W związku z tym między procesami pozyskiwania i usuwania nietrwałego tabela zawiera duplikaty. W przypadku zmaterializowanych widoków rekordy w widoku będą zawsze deduplikowane, ponieważ są one deduplikowane przed wejściem do widoku.
  • Częstotliwość: Jeśli tabela musi być stale deduplikowana, użyj zmaterializowanych widoków. Jeśli przewidujesz, że duplikaty będą rzadko używane i można je zidentyfikować podczas pozyskiwania, proces usuwania nietrwałego zwykle działa lepiej niż zmaterializowane widoki. Jeśli na przykład występuje sytuacja, w której pozyskiwanie nie ma zwykle duplikatów, ale od czasu do czasu pozyskiwanie strumienia, który jest znany ze zduplikowania. W tym scenariuszu lepiej jest obsłużyć te duplikaty przy użyciu usuwania nietrwałego niż zdefiniować zmaterializowany widok, który będzie stale próbować deduplikować wszystkie rekordy.

Rozwiązanie nr 5: ingest-by tagi zakresu

Tagi zakresu "ingest-by:" mogą służyć do zapobiegania duplikatom podczas pozyskiwania. Jest to istotne tylko w przypadkach użycia, w których każda partia pozyskiwania ma gwarancję, że nie ma duplikatów, a duplikaty są oczekiwane tylko wtedy, gdy ta sama partia pozyskiwania jest pozyskiwana więcej niż raz.

Podsumowanie

Duplikowanie danych można obsłużyć na wiele sposobów. Dokładnie oceń opcje, biorąc pod uwagę cenę i wydajność, aby określić poprawną metodę dla twojej firmy.

Powiązana zawartość