Bazy danych szeregów czasowych dla telemetrii obronnej: zapis, retencja, zapytania

Nowoczesny pojazd opancerzony emituje setki odczytów czujników na sekundę – obroty silnika, ciśnienie oleju, temperaturę skrzyni biegów, obciążenie zawieszenia, przepływ paliwa, napięcie akumulatora, pozycję GPS oraz jakość łącza na każdej podłączonej do niego radiostacji. Flota 200 pojazdów wytwarza dziesiątki milionów punktów danych na minutę. Okręt z pełnym monitorowaniem maszynowni wytwarza ich więcej. Przechowywanie tej telemetrii w relacyjnej bazie danych nigdy nie było wykonalne w skali; wzorce zapisu, kształty zapytań i wymagania retencji zasadniczo różnią się od obciążeń transakcyjnych. Bazy danych szeregów czasowych (TSDB) istnieją właśnie po to, by rozwiązać ten problem, a decyzje inżynieryjne podjęte podczas wdrażania jednej z nich – projektowanie schematu, parametry wsadowania, polityka downsamplingu, kardynalność tagów – decydują o tym, czy system utrzyma tempo operacyjne, czy załamie się pod obciążeniem w ciągu dni od wdrożenia. Ten artykuł obejmuje pełny cykl życia: od zapisu sieci czujników przez poziomy retencji po wzorce zapytań dla analityki obronnej.

Dlaczego istnieją bazy danych szeregów czasowych

Baza danych szeregów czasowych to silnik magazynowania zbudowany specjalnie dla danych z intensywnym dopisywaniem i uporządkowanych według znacznika czasu, gdzie zapytania niemal zawsze obejmują zakres czasowy, a podstawowa wartość danych tkwi w ich relacji czasowej – jak metryka zmienia się w czasie, a nie jak pojedynczy odczyt odnosi się do innego bytu.

Podstawowym wyróżnikiem technicznym względem baz relacyjnych jest układ magazynu. TSDB wykorzystują magazyn kolumnowy z automatycznym partycjonowaniem według czasu (zwanym shardami, chunkami lub bucketami w zależności od produktu). Wszystkie odczyty danej metryki w obrębie okna czasowego są przechowywane fizycznie obok siebie na dysku. Oznacza to, że zapytanie agregacji zakresu czasowego – „podaj mi średnią temperaturę silnika dla platformy P w ciągu ostatnich 24 godzin” – odczytuje ciągły blok dysku, a nie rozproszone strony sterty. Przy 10 000 zapisów czujników na sekundę TSDB może utrzymać to obciążenie z opóźnieniem zapisu rzędu jednocyfrowych milisekund na powszechnie dostępnym magazynie NVMe. Relacyjna baza danych nasyciłaby swój podsystem we/wy przy tej samej szybkości zapisu, ponieważ każde wstawienie musi aktualizować wiele indeksów.

Kompresja to druga kluczowa przewaga. Zmiennoprzecinkowe odczyty czujników z sąsiednich znaczników czasu są często niemal identyczne – temperatura zmienia się o ułamki stopnia między próbkami. TSDB wykorzystują kodowanie różnicowe, kompresję XOR (dla liczb podwójnej precyzji IEEE 754) oraz kodowanie długości serii, aby osiągnąć współczynniki kompresji 10:1 lub lepsze na typowych strumieniach telemetrii. Surowy strumień telemetrii, który zająłby 1 TB w relacyjnej bazie danych, przechowuje się w 80–120 GB w TSDB.

Projektowanie schematu: pomiary, tagi i pola

Decyzje dotyczące schematu podjęte przed pierwszym zapisem są najtrudniejsze do odwrócenia. Źle zaprojektowany zestaw tagów powoduje eksplozję kardynalności szeregów – stan, w którym liczba odrębnych szeregów czasowych w bazie rośnie bez ograniczeń, pochłaniając pamięć indeksu i pogarszając wszystkie zapytania. To najczęstszy tryb awarii produkcyjnej dla wdrożeń TSDB i jest całkowicie do uniknięcia przy poprawnym projektowaniu.

Pomiary

Pomiar (w niektórych produktach zwany rodziną metryk) to logiczna grupa powiązanych pól, które są zawsze zapisywane razem przy tym samym znaczniku czasu. Rozsądne granice pomiarów dla telemetrii platform obronnych obejmują: engine_telemetry (obroty, ciśnienie oleju, temperatura cieczy chłodzącej, prędkość przepływu paliwa), nav_position (szerokość, długość, wysokość, kurs, prędkość względem ziemi), power_systems (napięcie akumulatora, wyjście alternatora, prąd obciążenia na szynę) oraz radio_link_quality (siła sygnału, poziom szumu, stopa błędów pakietów, liczba retransmisji). Pola w obrębie tego samego pomiaru współdzielą znacznik czasu i są przechowywane razem, więc grupowanie według kadencji zapisu i spójności operacyjnej daje najwydajniejszy układ.

Tagi kontra pola

Tagi to indeksowane metadane, które identyfikują szereg. Każda unikalna kombinacja wartości tagów tworzy odrębny szereg w indeksie. Pola to wartości liczbowe zapisywane przy każdym znaczniku czasu – nie są indeksowane, a jedynie przechowywane. Zasada projektowania brzmi: jeśli musisz filtrować lub grupować według wymiaru w predykacie zapytania, musi to być tag. Jeśli musisz tylko odczytać wartość, powinno to być pole.

Dla telemetrii platform wojskowych odpowiednie tagi to: platform_id (stabilny krótki identyfikator, np. „VH-041”), platform_type (np. „M1A2”, „BTR-4”, „Mi-8”), unit_id (identyfikator batalionu lub eskadry), sensor_class (np. „engine”, „nav”, „comms”) oraz base lub grid_zone dla zgrubnego kontekstu lokalizacji. Mają one niską kardynalność: flota 500 pojazdów z 20 przydziałami jednostek i 5 typami platform wytwarza co najwyżej 50 000 odrębnych szeregów – komfortowo w zakresie roboczym każdej produkcyjnej TSDB.

Czym NIE mogą być tagi: surowe współrzędne GPS, UUID zdarzeń, kody usterek w wolnym tekście lub jakiekolwiek inne pole o kardynalności proporcjonalnej do liczby punktów danych. Umieszczenie surowej szerokości jako tagu tworzy jeden nowy szereg dla każdego punktu danych – indeks rośnie bez ograniczeń, a wydajność zapytań pogarsza się w ciągu godzin. Identyfikatory o wysokiej kardynalności należą do pól lub do osobnego relacyjnego magazynu metadanych, który łączy się z szeregami TSDB poprzez stabilne tagi o niskiej kardynalności.

Szybki zapis: wsadowanie, buforowanie i zapisy poza kolejnością

Czujniki obronne – zwłaszcza te na platformach pojazdów lub BSP – nie zapisują do TSDB bezpośrednio. Kolektor brzegowy działa na platformie lub na bramie agregującej dane z sekcji pojazdu, buforuje odczyty lokalnie i opróżnia partie do TSDB przez sieć taktyczną. Architektura zapisu ma trzy parametry, które decydują o tym, czy może wchłonąć trwałe obciążenie zapisu bez utraty danych lub nasycenia sieci.

Rozmiar partii. Zapis jednego punktu naraz wytwarza jeden cykl sieciowy na każdy odczyt czujnika – całkowicie niezrównoważone przy wysokich szybkościach. Rozmiary partii 1 000–5 000 punktów na żądanie zapisu redukują narzut sieciowy o trzy rzędy wielkości. Kompromisem jest opóźnienie zapisu: przy partii 1 000 punktów i czujniku 100 Hz dane są opóźniane do 10 sekund przed opróżnieniem partii. Dla monitorowania operacyjnego, gdzie opóźnienie 10–30 sekund jest akceptowalne, duże partie są optymalne. Dla alertowania niemal w czasie rzeczywistym bardziej odpowiednie są mniejsze partie z interwałem opróżniania opartym na czasie (np. opróżniaj co 2 sekundy niezależnie od zapełnienia partii).

Buforowanie z dziennikiem z wyprzedzeniem. Taktyczne łącza radiowe doświadczają przerw. Gdy łącze jest niedostępne, kolektor brzegowy musi buforować niewysłane dane lokalnie – do magazynu trwałego, a nie tylko do pamięci, aby dane przetrwały restart procesu lub cykl zasilania. Rozmiar bufora należy obliczyć z maksymalnego oczekiwanego czasu przerwy w łączu pomnożonego przez szczytową szybkość zapisu: 10-minutowa przerwa ze strumieniem czujnika 5 000 punktów na sekundę wymaga pojemności bufora 3 milionów punktów, około 150 MB przy typowej szerokości pól zmiennoprzecinkowych. Kolektory używające wyłącznie buforów w pamięci tracą dane przy każdym przerwaniu łącza.

Akceptacja zapisów poza kolejnością. Gdy buforowane dane docierają po przywróceniu łącza, niosą znaczniki czasu z przeszłości. TSDB znacznie różnią się tolerancją na zapisy poza kolejnością: jedne odrzucają zapisy ze znacznikami starszymi niż konfigurowalne okno; inne akceptują dowolny zapis historyczny, lecz kosztem wydajności. Okno akceptacji należy skonfigurować tak, aby pasowało do maksymalnej oczekiwanej przerwy w łączu dla typu platformy. Dla platform pojazdów na radiu taktycznym typowe jest 300–600 sekund. Dla platform z przekaźnikiem satelitarnym, gdzie przerwa w łączu podczas luki przelotu może trwać 90 minut, okno musi wynosić 5 400 sekund lub więcej.

Polityki retencji i downsampling

Surowa telemetria w pełnej rozdzielczości jest droga w długoterminowym przechowywaniu i rzadko potrzebna poza krótkim oknem operacyjnym. Trójpoziomowa polityka retencji pokrywa praktycznie wszystkie wymagania telemetrii obronnej bez zbędnych kosztów pamięci.

Poziom 1 – Surowy. Dane pełnej rozdzielczości (10–100 Hz w zależności od typu czujnika) przechowywane przez 7–30 dni. To okno wspiera monitorowanie w czasie rzeczywistym, natychmiastową analizę poincydentalną i przegląd alertów progowych. Dla floty 500 platform z 50 czujnikami na platformę zapisujących z 10 Hz magazyn pełnej rozdzielczości pochłania około 2–4 TB dziennie przy skompresowanym magazynie TSDB – możliwe do opanowania dla 30-dniowej retencji na powszechnie dostępnym sprzęcie NAS.

Poziom 2 – Agregaty 1-minutowe. Obliczane przez zapytanie ciągłe lub zadanie downsamplingu: średnia, minimum, maksimum i liczba dla każdego pola w każdym oknie 1-minutowym. Przechowywane przez 6–12 miesięcy. Ta rozdzielczość wspiera analizę trendów, inżynierię cech dla predykcyjnego utrzymania oraz wykrywanie anomalii w skali floty. Magazyn w rozdzielczości 1-minutowej jest około 600× mniejszy niż poziom surowy.

Poziom 3 – Agregaty godzinowe. Przechowywane przez 3–7 lat do długoterminowej analizy kondycji floty, planowania cyklu życia i przeglądu programu utrzymania. W tej rozdzielczości 7-letnia historia dla floty 500 platform zajmuje znacznie poniżej 100 GB – trywialnie tania względem wartości operacyjnej zapisu historycznego.

Zadania downsamplingu muszą być planowane z celowym przesunięciem od granicy okna. Zadanie zaplanowane na uruchomienie dokładnie na granicy minuty będzie często odczytywać niekompletne okno – ostatnie kilka sekund danych może jeszcze nie zostać opróżnione z potoku zapisu. Przesunięcie 30 sekund gwarantuje, że okno jest kompletne przed agregacją. Ten szczegół eliminuje całą klasę subtelnych artefaktów brzegowych, które pojawiają się jako anomalne spadki lub skoki w regularnych odstępach w danych po downsamplingu.

Wzorce zapytań dla analityki telemetrii obronnej

Pięć wzorców zapytań odpowiada za większość operacyjnego i analitycznego wykorzystania obronnej TSDB telemetrycznej. Wdrożenie produkcyjne musi obsługiwać wszystkie pięć z wykonaniem wyłącznie indeksowym – bez pełnych skanowań szeregów – przy objętościach danych oczekiwanych po 6–12 miesiącach akumulacji.

Zapytania o ostatnią wartość. „Jaka jest bieżąca temperatura silnika pojazdu VH-041?” To najczęstsze zapytanie w operacyjnym pulpicie monitorowania. TSDB zoptymalizowane pod ten wzorzec utrzymują indeks ostatniej wartości na szereg, więc zapytanie zwraca się w czasie stałym niezależnie od tego, ile danych historycznych istnieje. Bez tej optymalizacji zapytania o ostatnią wartość degenerują się do skanowania szeregu surowego wstecz w czasie – akceptowalnego przy niskiej kardynalności, nieakceptowalnego w skali floty.

Agregacje zakresu czasowego. „Jakie było średnie zużycie paliwa dla wszystkich platform M1A2 w Unit-7 w ciągu ostatnich 72 godzin?” To podstawowe zapytanie analityczne: filtr tagów wybierający właściwe szeregi, skanowanie zakresu czasowego oraz funkcja agregacji stosowana zarówno w wymiarze czasu, jak i przefiltrowanych szeregach. Czas wykonania powinien być mierzony w dziesiątkach milisekund przy objętościach danych z 12 miesięcy dla poprawnie zaindeksowanego schematu; setki milisekund wskazują na problem kardynalności.

Wykrywanie przekroczenia progu. „Kiedy temperatura oleju skrzyni biegów na jakimkolwiek pojeździe we flocie po raz pierwszy przekroczyła 120°C w ciągu ostatnich 30 dni?” To zapytanie wymaga skanowania zakresu czasowego z predykatem na wartości pola. Niektóre TSDB wykonują to wydajnie dzięki kolumnowym metadanym min/max, które przycinają chunki bez wartości przekraczających próg; inne wymagają pełnego skanowania pola. Zrozumienie, której strategii wykonania używa wybrany produkt, jest krytyczne dla wymiarowania budżetów opóźnień systemu alertowania.

Porównanie wielu szeregów. „Pokaż mi zużycie paliwa dla wszystkich pojazdów typu BTR-4 w ciągu ostatniego tygodnia, pogrupowane według jednostki.” To zapytanie benchmarkingu floty używane przez planistów utrzymania do identyfikacji platform odstających. Wymaga, aby indeks tagów wydajnie wyliczył wszystkie szeregi pasujące do filtra platform_type, a następnie agreguje każdy. Wynikiem jest jeden szereg czasowy na jednostkę – niewielka liczba szeregów wyjściowych niezależnie od rozmiaru floty, jeśli schemat tagów jest poprawny.

Zapytania o pochodną. „Jaka jest szybkość zmiany amplitudy drgań na lewym silniku VH-041 w ciągu ostatnich 6 godzin?” Szybkość zmiany to podstawowa cecha do wykrywania anomalii mechanicznych – nagły wzrost pochodnej szeregu drgań lub temperatury często poprzedza awarię komponentu o godziny lub dni. Zasila to bezpośrednio potok kolejki komunikatów, który dostarcza zdarzenia anomalii do centrum operacji utrzymania. Większość TSDB obsługuje obliczanie pochodnej jako funkcję natywną; te, które nie obsługują, wymagają obliczenia na warstwie aplikacji nad wynikiem gęstego zapytania zakresu czasowego, co jest wykonalne, lecz dodaje opóźnienie.

Integracja z szerszą platformą danych

TSDB nie działa w izolacji. W obronnej platformie danych jest jednym komponentem potoku, który obejmuje także kolektory brzegowe, kolejki komunikatów do routingu zdarzeń w czasie rzeczywistym, jezioro danych do długoterminowego przechowywania wieloformatowego oraz frontendy analityki i monitoringu. Kontrakt integracyjny między TSDB a tymi komponentami musi być zdefiniowany jawnie.

Dla odbiorców końcowych potrzebujących telemetrii niemal w czasie rzeczywistym – systemów alertowania, pulpitów operacyjnych, silników fuzji – zalecanym wzorcem jest, aby kolektor brzegowy publikował każdą partię zarówno do TSDB (dla trwałości i zapytań historycznych), jak i do tematu kolejki komunikatów (dla routingu zdarzeń o niskim opóźnieniu do odbiorców). Odsprzęga to TSDB od ścieżki dostarczania w czasie rzeczywistym: odbiorcy otrzymują zdarzenia w ciągu sekund od przechwycenia przez czujnik, bez odpytywania TSDB, a TSDB obsługuje wyłącznie zapytania historyczne i agregacyjne, dla których jej układ magazynu jest zoptymalizowany.

Dla integracji z obronnym jeziorem danych odpowiednim źródłem są poziomy TSDB po downsamplingu: eksportuj migawki agregatów 1-minutowych jako Parquet lub CSV według harmonogramu i ląduj je w strefie pozyskiwania jeziora. Eksport danych surowych z TSDB do jeziora jest zbędny, jeśli kolektor brzegowy już zapisuje dane surowe do obu miejsc docelowych – ale TSDB pozostaje autorytatywnym źródłem dla zapytań zakresu czasowego nad świeżymi danymi, ponieważ jej format magazynu jest o rzędy wielkości szybszy dla tego wzorca niż kolumnowe pliki jeziora oparte na magazynie obiektowym.