Opis

Wstęp

Zarejestruj się, aby wyświetlić podgląd.

Jeśli nie skontaktujesz się z nami w ciągu jednego dnia roboczego, zarejestruj się ponownie.

Prognozowanie i wykrywanie anomalii w miliardach serii czasowych wymaga intensywnych obliczeń. Większość istniejących systemów korzysta z prognozowania i wykrywania anomalii jako zadań zbiorczych (np. Potoków ryzyka, prognozowania ruchu, planowania popytu itp.). To poważnie ogranicza typ analizy, jaką można przeprowadzić online (np. Jeśli mamy do czynienia z nagłym wzrostem lub spadkiem zakresu wymiarów zdarzeń).

Główne cele prognozowania serii czasowych i korzystania z niego do wykrywania anomalii za pomocą interfejsu API Timeseries Insights to:

  • skalowanie do miliardów serii czasowych (gdzie seria czasowa jest zdefiniowana jako liczba zliczeń w czasie dla usługi zdarzenia - np. liczba transakcji zrealizowanych przez operatora).
  • zapewnia opóźnienie w czasie rzeczywistym na potrzeby prognozowania i wykrywania anomalii (np. w ciągu kilku sekund wykrywa trendy i sezonowość we wszystkich wyświetlanych seriach i decyduje, czy jakieś wycinki mają gwałtownie wzrosnąć czy spaść).

Funkcje interfejsu API

  • Indeksuj i wczytuj zestaw danych składający się z wielu źródeł danych przechowywanych w Google Cloud Storage. Zezwalaj na dołączanie dodatkowych wydarzeń w trybie strumieniowym.
  • Wykonywanie zapytań dotyczących serii czasowych w załadowanym zbiorze danych w celu prognozowania trendów i wykrywania anomalii.
  • Usuń obciążenie niepotrzebnego zbioru danych.
  • Zapytaj o stan przetwarzania zbioru danych.

Dane wejściowe

Dane z przedziałów czasu to zbiór obserwacji, wielokrotnie mierzonych w czasie. Na przykład średnie wykorzystanie procesora przez konkretną pracę w ciągu minuty to proste dane serii czasowych. Najniższa jednostka danych wejściowych to punkt danych w postaci pary klucz-wartość w określonym czasie. Klucz to nazwa wymiaru. Wymiary w naszym przykładzie to cpu, ram i state itd.

Serwery czasu

Zdarzenie

Interfejs Timeseries Insights API używa zdarzeń jako podstawowego wpisu danych. Do obsługi punktów danych w skali bilionów można stosować wiele wymiarów. Na przykład centrum danych, użytkownik, nazwy zadań i numery zadań są w pełni reprezentowane przez jedno zdarzenie.

{"name":"user","stringVal":"user_64194"},
{"name":"job","stringVal":"job_45835"},
{"name":"data_center","stringVal":"data_center_30389"},
{"name":"task_num","longVal":19},
{"name":"cpu","doubleVal":3840787.5207877564},
{"name":"ram","doubleVal":1067.01},
{"name":"state","stringVal":"idle"}

Każde Wydarzenie ma:

  • sygnaturę czasową
  • Co najmniej jeden wymiar, przy czym każdy wymiar ma:
    • nazwa (niepowtarzalna w zbiorze danych)
    • wartość (ciąg znaków, wartość logiczna, liczba całkowita/podwójna) Wymiary zdarzenia to właściwości powiązane ze zdarzeniem. Ogólnie mówiąc, zestaw nazw wymiarów odpowiada typowi zdarzeń. Na przykład ["user", "job", "data_center", "task_num", "gcu"] są używane w zdarzeniach związanych z wykorzystaniem zasobów pracy, a ["user", "gcu", "disk", "ram"] - w przypadku zdarzeń związanych z limitem użytkownika.
  • długi identyfikator grupy, ustawiony na tę samą wartość w powiązanych rekordach Event. Najczęściej każdy rekord Event otrzymuje unikalny identyfikator. Przykłady użycia identyfikatora grupy obejmują również:
    • Identyfikator zdarzenia dla tego samego zdarzenia (z tą samą sygnaturą czasową) z wielu rekordów Zdarzenie, zwłaszcza gdy różne aspekty tego samego zdarzenia pochodzą z różnych źródeł i nie zostały scalone przed wprowadzeniem do systemu. Na przykład kilka czujników monitorujących to samo urządzenie może wygenerować osobny rekord zdarzenia.
    • identyfikator sesji dla zbioru powiązanych zdarzeń (zwykle z sygnaturami czasowymi w krótkim okresie). Przykładem są aktywności z sesji przeglądania internetu. Kolejnym przykładem są wpisy z dziennika przejazdu taksówką.
    • identyfikator konta użytkownika, więc wszystkie rekordy Event z tym samym identyfikatorem grupy należą do tego samego użytkownika.

Zbiór danych

Zbiór danych to zbiór zdarzeń. Każde zapytanie jest wykonywane w tym samym zbiorze danych. Każdy projekt może mieć wiele zbiorów danych.

Każdy zestaw danych można utworzyć z danych przesyłanych zbiorczo i przesyłanych strumieniowo. Kompilacja zbiorcza odczytuje dane z wielu identyfikatorów URI Cloud Storage jako źródeł danych. Po ukończeniu kompilacji zbiorczej możesz dodać do zbioru danych dane przesyłane strumieniowo. Używając kompilacji zbiorczej dla danych historycznych, system może uniknąć problemów związanych z zimnym startem.

Przed wysłaniem zapytania lub zaktualizowaniem zbioru danych należy go utworzyć/zaindeksować. Indeksowanie rozpoczyna się po utworzeniu zestawu danych i zwykle trwa od kilku minut do kilku godzin, w zależności od ilości danych. Mówiąc dokładniej, źródła danych są skanowane raz podczas początkowego indeksowania. Jeśli zawartość identyfikatorów URI Cloud Storage zmieni się po zakończeniu wstępnego indeksowania, nie zostaną one ponownie przeskanowane. Używaj aktualizacji przesyłanych strumieniowo, aby uzyskać dodatkowe dane. Aktualizacje przesyłane strumieniowo są indeksowane niemal w czasie rzeczywistym.

Uwaga: interfejs Timeseries Insights API nie może zwracać nieprzetworzonych aktualizacji strumieniowych, więc klienci powinni mieć własne miejsce na te dane.

Wykrywanie anomalii przez serwery czasu

Wycinki

Wycinek to zbiór zdarzeń z określoną kombinacją wartości wymiarów. Jesteśmy zainteresowani dystrybucją wydarzeń należących do tych wycinków. W przypadku danego wycinka zdarzenia są agregowane w wartości liczbowe na określoną przez użytkownika rozdzielczość przedziałów czasu, czyli serie czasowe służące do wykrywania anomalii. Powyższy rysunek ilustruje różne wybory wycinków ze zbioru danych o wymiarach "user", "job", "data_center".

Serwery czasu i anomalie

Anomalie występują w przypadku określonego wycinka, jeśli wartość liczbowa z przedziału czasowego jest znacznie różna od wartości z przeszłości. Zdjęcie przedstawia serię czasową opartą na globalnych wartościach temperatury z ostatnich 10 lat. Załóżmy, że interesuje nas, czy ostatni miesiąc 2015 r. Jest anomalią. Zapytanie systemowe określa przedział czasowy testInterval na „jeden miesiąc kończy się 2015/12/31”. Pobrana seria czasowa sprzed testInterval jest dzielona na wcześniejszy okres szkoleniowy, po którym następuje okres wstrzymania. System używa danych z okresu trenowania, by wytrenować model, a okres wstrzymania umożliwia sprawdzenie, czy model może w wiarygodny sposób przewidywać kolejne wartości. W tym przykładzie okres wstrzymania wynosi 1 rok. Zazwyczaj okres wstrzymania to 5-10% całej historii. Obraz przedstawia rzeczywiste dane i przewidywane wartości z modelu z górnymi i dolnymi granicami. Temperatura w roku 2015/12 jest oznaczona jako anomalie, ponieważ rzeczywista wartość znacznie wykracza poza zakres prognozy.