Elementarz danych szeregów czasowych i dlaczego nie będziesz chciał używać “normalnej” bazy danych do ich przechowywania.

Oto zagadka: co wspólnego mają samonapędzający się Teslas, autonomiczne algorytmy handlu Wall Street, inteligentne domy, sieci transportowe, które realizują błyskawicznie szybkie dostawy tego samego dnia, a także Open-data-publishing NYPD?

Po pierwsze, świadczą one o tym, że nasz świat zmienia się z prędkością warp, dzięki naszej zdolności do przechwytywania i analizowania coraz większej ilości danych w coraz szybszy sposób niż dotychczas.

Jednakże, jeśli przyjrzeć się bliżej, zauważysz, że każda z tych aplikacji wymaga specjalnych, całkiem wyjątkowych danych:

Samochody samobieżne stale zbierają dane o tym, jak zmienia się ich lokalne środowisko wokół nich.

Autonomiczne algorytmy transakcyjne stale gromadzą dane o tym, jak zmieniają się rynki.

Nasze inteligentne domy monitorują, co dzieje się w ich wnętrzu, aby zarządzać temperaturą, identyfikować intruzów i odpowiadać na nasze telefony (“Alexa, zagraj trochę relaksującej muzyki”).

Nasza branża detaliczna monitoruje, jak ich aktywa poruszają się z taką precyzją i wydajnością, że tania dostawa tego samego dnia może być luksusem, który wielu ludzi uważa za przyznany.

NYPD śledzi swoje pojazdy, aby umożliwić nam bardziej odpowiedzialne ich przewożenie (np. za analizę czasu reakcji 911).

Aplikacje te wierzą w pewien rodzaj danych, które mierzą, jak rzeczy zmieniają się w czasie. Gdzie czas nie jest tylko metryką, ale główną osią. Często są to dane szeregów czasowych i zaczynają odgrywać większą rolę w naszym świecie.

Wzorce użytkowania oprogramowania przez programistów już to odzwierciedlają. W rzeczywistości, w ciągu ostatnich 24 miesięcy bazy danych szeregów czasowych (TSDB) stale pozostawały najszybciej rosnącą kategorią baz danych:

https://lh6.googleusercontent.com/3ilNt7AbjM0ahQd10tFn41s8ux_9rRIiDtVOUSUCKPqcvwc-5RZfKhA7SVD6RRlXVc2eMjncTtYliL1wIXHy1LNBN0HsDM4kSCHjbDXvvbgl7inygKEazHrf68gsEx-2eSzmqLXT

Co to są dane z serii czasowej?

Niektórzy uważają “dane szeregów czasowych” za sekwencję punktów wiedzy, mierzących równoważną rzecz w czasie, przechowywanych w porządku czasowym. To prawda, ale to tylko zarysowuje powierzchnię.

Inni mogą wyobrazić sobie serię wartości liczbowych, z których każda połączona jest ze znacznikiem czasu, określonym przez reputację i grupę oznaczonych wymiarów (lub “tagów”). Często jest to być może metoda modelowania danych szeregów czasowych, ale nie definicja samej informacji.

Oto podstawowa ilustracja. Wyobraźmy sobie czujniki zbierające dane z trzech ustawień: miasta, gospodarstwa i fabryki. w tym przykładzie każde z tych źródeł okresowo wysyła nowe odczyty, tworząc serię pomiarów zebranych w czasie.

Oto kolejny przykład, z prawdziwymi danymi z miasta najnowszego Yorku, pokazujący przejazdy taksówkami przez pierwsze kilka sekund 2018 roku. Jak widać, każdy rząd może być “pomiarem” zebranym w wybranym czasie:

https://lh3.googleusercontent.com/ZRDripFiX6Le9oupbI-iAEt0_VX7q9xpolqpCE_WsjcSIgXZJK1clIkXhINTMvpTu1aC55j5gBMyJ1c8RdYu03augqDc4y-9WWL6eSDNMsvET-NEk7WchpZyLdpMrt3SvNZFTNxE

Istnieje wiele innych form danych szeregów czasowych. Żeby zadzwonić do kilku: DevOps dane z monitoringu, strumienie zdarzeń aplikacji mobilnych/ internetowych, dane maszyn przemysłowych, pomiary naukowe.

Te zbiory danych mają przede wszystkim 3 cechy wspólne:

Dane, które docierają, są prawie zawsze rejestrowane jako dane zastępcze.

Dane zazwyczaj docierają do nas w odpowiednim czasie.

Czas może być osią główną (przedziały czasowe są często regularne lub nieregularne)

Innymi słowy, obciążenia danymi z serii czasowej są zazwyczaj “tylko dołączane”. Chociaż muszą one poprawiać błędne dane po samym fakcie, lub obsługiwać dane opóźnione lub nieporządane, są to wyjątki, a nie norma.

Możesz zadać sobie pytanie: Czym to się różni od posiadania pola czasowego w trakcie tworzenia zbioru danych? Cóż, zależy to od tego: jak zmienia się tor twojego zbioru danych? Poprzez aktualizację obecnego wpisu, czy poprzez wstawienie zastępczego?

Kiedy zbierasz zastępczy odczyt dla sensora_x, czy nadpisuje się poprzedni odczyt, czy też tworzy się nowy odczyt w osobnym wierszu? Podczas gdy obie metody podadzą ci aktualny stan systemu, tylko zapisując nowy odczyt w osobnym wierszu będziesz gotowy do śledzenia wszystkich stanów systemu w czasie.

Mówiąc prosto: zestawy danych serii czasowej śledzą zmiany w ogólnym systemie jako WSTAWIENIA, a nie UPDATKI.

Ta praktyka nagrywania każdej zmiany w systemie w zastępstwie, inny rząd jest tym, co sprawia, że dane szeregów czasowych są tak potężne. Pozwala nam to żyć zmianą: analizować jak coś zmieniło się w przeszłości, monitorować jak coś zmienia się w teraźniejszości, przewidywać jak to się zmieni w przyszłości.

Mówiąc prościej, oto jak wolę definiować dane szeregów czasowych: dane, które zbiorowo reprezentują jak system/procesy/zachowania zmieniają się w czasie.

Jest to dość proste rozróżnienie. Skupiając naszą definicję wokół “zmiany”, zaczniemy dostrzegać zbiory danych szeregów czasowych, których dzisiaj nie zbieramy, ale które zawsze powinniśmy zbierać w dół drogi. W rzeczywistości, często ludzie mają dane szeregów czasowych, ale ich nie znają .

Wyobraź sobie, że utrzymujesz aplikację internetową. Za każdym razem, gdy użytkownik się loguje, po prostu uaktualniasz znacznik czasu “last_login” dla tego użytkownika w jednym wierszu tabeli “users”. Ale co by było, gdybyś traktował każde logowanie jako osobne zdarzenie i odbierał je w czasie? Wtedy mógłbyś: śledzić historyczną aktywność logowania, zobaczyć jak wykorzystanie (w-/de-)rośnie w czasie, wiadro użytkowników po tym jak często korzystają z aplikacji i więcej.

Ten przykład ilustruje kluczową kwestię: zachowując nieodłączny charakter szeregów czasowych naszych danych, jesteśmy gotowi zachować cenne informacje o tym, jak dane te zmieniają się w czasie. Kolejny punkt: dane o zdarzeniach są dodatkowo danymi szeregowymi czasowo.

Oczywiście, przechowywanie danych w tej rozdzielczości wiąże się z oczywistym problemem: kończy się na tonacji wiedzy, dość szybko. I to jest właśnie ten haczyk: dane szeregów czasowych piętrzą się bardzo szybko.

Posiadanie ogromnej wiedzy stwarza problemy zarówno przy jej zapisywaniu, jak i wyszukiwaniu w sposób wydajny, dlatego też ludzie zwracają się teraz do baz danych szeregów czasowych.

Dlaczego chcę mieć bazę danych szeregów czasowych?

Możesz zapytać: Dlaczego nie mogę po prostu użyć “normalnej” (tzn. nieseryjnej) bazy danych?

Prawda jest taka, że ty po prostu możesz, i kilka osób tak robi. Dlaczego jednak TSDB są obecnie najszybciej rozwijającą się kategorią baz danych? Dwa powody: (1) skala i (2) użyteczność.

Skala: Dane z serii czasowej gromadzą się bardzo szybko. (Na przykład jeden podłączony samochód będzie gromadził 4 000 GB wiedzy dziennie.) A zwykłe bazy danych nie są zaprojektowane do obsługi tej skali. Relatywne bazy danych słabo radzą sobie z bardzo dużymi zbiorami danych; bazy danych NoSQL radzą sobie lepiej w skali, ale i tak mogą być lepsze niż baza danych dostosowana do danych szeregów czasowych. Natomiast bazy danych szeregów czasowych (często obsługiwane przez relacyjne lub NoSQL) radzą sobie ze skalą, wprowadzając efektywność, która jest możliwa tylko wtedy, gdy czas traktuje się jak obywatela klasy podstawowej. Efektywność ta kończy się poprawą wydajności, w tym większymi wskaźnikami spożycia, szybszymi zapytaniami na skalę (chociaż niektóre obsługują więcej zapytań niż inne) oraz lepszą kompresją danych.

Użyteczność: SSDB zazwyczaj zawierają również funkcje i operacje typowe dla analizy danych szeregów czasowych, takie jak zasady retencji danych, zapytania ciągłe, elastyczne agregacje czasowe, itp. Mimo, że skalowanie nie jest priorytetem w danej chwili (np. jeśli dopiero zaczynasz zbierać dane), funkcje te mogą zapewnić o wiele lepsze wrażenia użytkownika i ułatwić mu życie.

Z tego powodu programiści coraz częściej wykorzystują bazy danych z szeregiem czasowym i wykorzystują je do szerokiego zakresu zastosowań:

Monitoring systemów oprogramowania: Maszyny wirtualne, kontenery, usługi, aplikacje

Monitorowanie systemów fizycznych: Sprzęt, maszyny, podłączone urządzenia, środowisko, nasze domy, nasze ciała

Aplikacje do śledzenia aktywów: Pojazdy, ciężarówki, fizyczne kontenery, palety

Systemy obrotu finansowego: Klasyczne papiery wartościowe, nowsze waluty kryptograficzne

Zdarzające się aplikacje: Śledzenie danych dotyczących interakcji między użytkownikiem a klientem

Narzędzia wywiadu biznesowego: Śledzenie kluczowych metryk, a tym samym ogólnej kondycji przedsiębiorstwa

(i więcej)

Nawet wtedy będziesz musiał wybrać bazę danych z serii czasowej, która najbardziej pasuje do Twojego modelu danych i wzorów zapisu/odczytu.

Myśl rozstania: Czy wszystkie dane są danymi szeregowymi czasowymi?

Przez ostatnią dekadę żyliśmy mniej więcej w erze “Big Data”, zbierając ogromne ilości danych o naszym świecie i wykorzystując zasoby obliczeniowe do stworzenia jego sensu.

Chociaż era ta rozpoczęła się od skromnej technologii obliczeniowej, nasza zdolność do przechwytywania, przechowywania i analizowania danych poprawiła się w wykładniczym tempie, ze względu na duże trendy makro: Prawo Moore’a, prawo Krydera, cloud computing, cała branża technologii “dużych danych“.

Teraz chcielibyśmy więcej. Nie zadowalamy się już tylko obserwacją stanu planety, ale chcemy teraz żyć jak nasz świat zmienia się w czasie, w subsekundowych odstępach czasu. Nasze zbiory danych “wielkoskalowych” są teraz karłowate przez inny rodzaj danych, który w dużym stopniu opiera się na czasie, aby zachować informacje o zachodzącej zmianie.

Czy wszystkie dane zaczynają się jako dane z serii czasowej? Przypomnijmy wcześniejszy przykład aplikacji internetowej: mieliśmy dane szeregowe, ale nie wiedzieliśmy o tym. Albo rozważyć każdy “normalny” zbiór danych. Powiedzmy, obecne konta i salda w poważnym banku detalicznym. Albo plik tekstowy ASCII dla projektu oprogramowania. Albo tekst dla tego tekstu. . .

Zazwyczaj wybieramy zapisywanie najnowszego stanu systemu, ale co by było, gdybyśmy zapisywali każdą zmianę i obliczali najnowszy stan w czasie zapytania? Czy “normalny” zbiór danych nie jest po prostu widokiem na szczycie zbioru danych serii czasowej (buforowanym ze względu na wydajność)? Czy banki nie mają ksiąg transakcji? (I czy łańcuchy blokowe nie są po prostu rozproszonymi, niezmiennymi logami szeregów czasowych?) Czy projekt oprogramowania nie miałby kontroli nad wersjami (np. git commits)? Czy ten tekst nie ma historii rewizji? (Undo. Redo.)

Ujmijmy to inaczej: Czy wszystkie bazy danych nie mają logów?

Zdajemy sobie sprawę, że wiele aplikacji może nigdy nie wymagać danych szeregów czasowych (i lepiej byłoby, gdyby były one obsługiwane przez “widok aktualnego stanu”). Ale w miarę jak będziemy podążać za wykresem postępu technologicznego, może się wydawać, że te “widoki z aktualnego stanu” przestały być potrzebne. Które, przechowując coraz więcej danych w postaci szeregów czasowych, moglibyśmy być również gotowi lepiej je poznać.