Jak pamięć kolumnowa przyspiesza analizę danych z czujników domowych?

Magazynowanie kolumnowe przyspiesza analizę danych z domowych czujników, przechowując wartości z tych samych pól razem, dzięki czemu zapytania analityczne mogą pomijać niepowiązane dane.

Tabela historii inteligentnego domu może zawierać znaczniki czasu, identyfikatory urządzeń, pomieszczenia, temperaturę, wilgotność, pobór mocy, stan wykrywania ruchu, poziom naładowania baterii, flagi jakości i metadane obejmujące miliony obserwacji. Większość pytań dotyczących historii wykorzystuje tylko kilka z tych pól i agreguje wiele wierszy, co jest niemal przeciwieństwem aplikacji, która wielokrotnie pobiera jeden kompletny bieżący rekord. Układy kolumnowe optymalizują ścieżkę skanowania i agregacji, zmieniając zarówno zakres odczytywanych danych, jak i sposób, w jaki partie podobnych wartości trafiają do procesora.

Układ kolumnowy oddziela pola faktycznie potrzebne zapytaniu analitycznemu

Rekord zorientowany wierszowo przechowuje wszystkie pola jednej obserwacji razem, co jest wygodne, gdy aplikacja potrzebuje całej obserwacji. Reprezentacja zorientowana kolumnowo grupuje natomiast wartości według pól, pozwalając sześciomiesięcznemu zapytaniu o temperaturę skupić się na znaczniku czasu, pomieszczeniu i temperaturze, bez przeciągania przez to samo skanowanie ciągów znaków z oprogramowaniem układowym, danych o baterii i niepowiązanych stanów urządzeń.

Apache Parquet to zorientowany kolumnowo format danych zaprojektowany z myślą o wydajnym przechowywaniu i pobieraniu dużych zbiorów danych. To fizyczne rozdzielenie jest pierwszym powodem, dla którego wąskie zapytanie analityczne może przenieść mniej danych niż pełne skanowanie wierszy tej samej logicznej tabeli.

Korzyść rośnie, gdy rekordy stają się szersze, a zapytania pozostają selektywne. Raport zużycia energii w domu może korzystać tylko ze znacznika czasu, mocy w watach i identyfikatora urządzenia, mimo że schemat pozyskiwania danych zawiera wiele dodatkowych pól potrzebnych pulpitom nawigacyjnym i zarządzaniu urządzeniami.

Wypychanie projekcji i filtrów zapobiega wczytywaniu niepotrzebnych danych do skanowania

Układ kolumnowy umożliwia pomijanie nieużywanych pól, ale silnik zapytań musi przekazać tę informację do czytnika plików, aby oszczędność miejsca na nośniku przełożyła się na rzeczywiste ograniczenie operacji wejścia-wyjścia. Jeśli każda kolumna jest najpierw wczytywana, a dopiero później odrzucana, format fizyczny nie zapewnił pełni swoich korzyści.

DuckDB może stosować wypychanie projekcji i filtrów podczas odczytu Parquet, dzięki czemu odczytywane są tylko wymagane kolumny, a filtry mogą uczestniczyć w pomijaniu części pliku. Zapytanie o średnią wilgotność w jednym pomieszczeniu może więc zawęzić zarówno zakres pól, jak i — jeśli pozwalają na to metadane — odpowiednie zakresy wierszy przed rozpoczęciem pełnego wykonania.

W przypadku lokalnej usługi analitycznej ogranicza to liczbę odczytów z dysku, pracę związaną z dekompresją, ruch danych w pamięci oraz ilość danych pośrednich przekazywanych między operatorami. Zysk jest największy przy długich skanowaniach, gdy żądane pola stanowią niewielką część przechowywanego schematu.

Wypychanie filtrów nie jest automatyczne w każdym potoku. Owijanie danych w nieprzejrzystą transformację lub użycie czytnika, który nie potrafi udostępnić predykatów warstwie magazynowania, może wymusić większą materializację, niż wymagałby sam format pliku.

Wspólne przechowywanie podobnych wartości zapewnia lepszą lokalność koderom i kompresorom

Kolumny z danymi czujników często wykazują powtarzalne lub powoli zmieniające się wzorce wartości: nazwy pomieszczeń się powtarzają, stany logiczne pozostają niezmienione przez długi czas, znaczniki czasu rosną monotonicznie, a temperatury mieszczą się w wąskim zakresie liczbowym. Grupowanie każdego typu wartości razem zapewnia koderom bardziej regularny strumień niż przeplatanie każdego pola każdej obserwacji.

Parquet obsługuje kompresję stron kolumnowych w zakodowanych stronach danych, dzięki czemu każda porcja kolumny może używać kodeka kompresji po zakodowaniu wartości. Lepsza kompresja zmniejsza ilość danych, które serwer domowy musi przechowywać i odczytywać podczas analizy historii.

Stopień kompresji zależy od charakterystyki obciążenia i nie jest gwarantowany samym użyciem formatu „kolumnowego”. Szyfrowane dane o dużej różnorodności lub już skompresowane wartości binarne mogą zyskać niewiele, podczas gdy powtarzające się etykiety i uporządkowane serie liczbowe zwykle ujawniają więcej możliwej do wykorzystania nadmiarowości.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Metadane grup wierszy pozwalają czytnikowi pomijać zakresy, które nie mogą pasować

Zapytania dotyczące historii często zawierają selektywne warunki, takie jak jeden zakres dat, jedna klasa urządzeń lub odczyty powyżej określonego progu. Jeśli metadane na poziomie pliku lub grupy wierszy dowodzą, że dany obszar nie może spełnić predykatu, jego odczytywanie i dekodowanie byłoby zmarnowaną pracą.

DuckDB może używać metadanych min./maks. Parquet jako pomijania plików na podstawie zonemap podczas wypychania filtrów, a Parquet definiuje również opcjonalne filtry Blooma, które mogą pomóc określić, czy wartości mogą występować w porcji kolumny. Struktury te przyspieszają zapytania przez pomijanie zakresów, które można uznać za nieistotne, a nie przez obniżanie kosztu obliczania pasujących wierszy po ich wczytaniu.

Uporządkowanie danych wpływa na skuteczność tego przycinania. Pliki pogrupowane w przybliżeniu według czasu, pomieszczenia lub urządzenia mogą tworzyć węższe zakresy metadanych niż dane przeplatane losowo, dlatego przemyślany układ zapisu może wzmocnić korzyści z magazynowania kolumnowego.

Pomijanie na podstawie metadanych jest probabilistyczne lub zachowawcze, zależnie od struktury, a fałszywe trafienia nadal mogą powodować dodatkowe odczyty. Najważniejsza gwarancja polega na tym, że przycinanie nie może odrzucić zakresów, które mogą zawierać prawidłowe wyniki.

Kolumnowe partie dobrze współpracują z wektorowym wykonywaniem na procesorze

Po umieszczeniu wybranych kolumn w pamięci operatory analityczne wielokrotnie stosują te same obliczenia do wielu wartości: porównań, sum, średnich, kluczy grupowania lub transformacji. Ciągłe wartości lepiej wykorzystują pamięci podręczne procesora oraz instrukcje przetwarzające kilka wartości w jednej operacji.

Apache Arrow opisuje kolumnowy układ pamięci, który poprawia lokalność i umożliwia obliczenia wektorowe z użyciem procesorów obsługujących SIMD. Lokalny silnik zapytań może więc przetwarzać partie temperatur lub odczytów mocy, zamiast wielokrotnie rozpakowywać kompletne, heterogeniczne rekordy po jednym wierszu.

Ta korzyść dotyczy analitycznej ścieżki wykonywania, a nie tylko kompresji na dysku. Nawet szybki dysk SSD może niepotrzebnie zużywać przepustowość na dostarczanie pól, które procesor natychmiast ignoruje, podczas gdy potok kolumnowy ogranicza ten transfer jeszcze przed rozpoczęciem obliczeń.

Magazynowanie kolumnowe lepiej nadaje się do skanowania historii niż do często zmienianego bieżącego stanu

Ten sam układ, który jest wydajny przy szerokich skanowaniach, nie musi być najlepszą reprezentacją dla częstych aktualizacji punktowych, małych transakcji ani pobierania jednego kompletnego stanu urządzenia. Sterowanie automatyką domową i długoterminowa analityka mogą więc korzystać z różnych ścieżek przechowywania, nawet jeśli opisują te same czujniki.

Arrow wyraźnie poświęca silną lokalność analityczną na rzecz droższych operacji modyfikacji, co pokazuje szerszą granicę: systemy kolumnowe sprawdzają się, gdy wiele wartości jest skanowanych razem, natomiast ciągłe przepisywanie małych rekordów może lepiej pasować do innej struktury.

Praktyczny stos domowy może przechowywać bieżący stan urządzeń w bazie zorientowanej wierszowo lub stanowo, a następnie okresowo zapisywać historyczne obserwacje w plikach kolumnowych do celów analitycznych. Rozdzielenie sterowania i lokalnej analityki w ZimaSpace odzwierciedla tę samą ideę architektoniczną: ścieżka, która musi reagować na zdarzenie w czasie rzeczywistym, nie musi współdzielić fizycznego układu danych używanego do wielomiesięcznej analizy retrospektywnej.

Użyteczne pytanie nie brzmi więc, czy magazynowanie kolumnowe jest uniwersalnie szybsze. Chodzi o to, czy dominujące obciążenie skanuje podzbiór pól w wielu historycznych wierszach, ponieważ właśnie ten wzorzec dostępu zamienia rozdzielenie kolumn na mniejszą liczbę operacji wejścia-wyjścia i wydajniejsze przetwarzanie wsadowe.