Hur påskyndar kolumnlagring analys av hemsensorer?

Kolumnlagring påskyndar analys av sensordata i hemmet genom att hålla värden från samma fält tillsammans, så att analytiska frågor kan undvika att läsa orelaterade data.

En historiktabell för ett smart hem kan innehålla tidsstämplar, enhets-ID:n, rum, temperaturer, luftfuktighet, effekt, rörelsestatus, batterinivå, kvalitetsflaggor och metadata från miljontals observationer. De flesta historiska frågor använder bara några få av dessa fält och aggregerar många rader, vilket nästan är motsatsen till en applikation som upprepade gånger hämtar en komplett aktuell post. Kolumnlayouter optimerar denna sök- och aggregeringsväg genom att förändra både vad som måste läsas och hur batcher med liknande värden når processorn.

Kolumnlayout separerar de fält som en analytisk fråga faktiskt behöver

En radorienterad post håller alla fält för en observation tillsammans, vilket är praktiskt när applikationen behöver hela observationen. En kolumnorienterad representation grupperar i stället värden efter fält, så att en temperaturfråga för sex månader kan fokusera på tidsstämpel, rum och temperatur utan att samtidigt läsa in strängar från fast programvara, batteridata och orelaterade enhetstillstånd.

Apache Parquet är ett kolumnorienterat dataformat som är utformat för effektiv lagring och hämtning av stora datamängder. Denna fysiska separation är det första skälet till att en smal analytisk fråga kan flytta mindre data än en fullständig radskanning över samma logiska tabell.

Fördelen växer när posterna blir bredare och frågorna förblir selektiva. En energirapport för hemmet kanske bara använder tidsstämpel, watt och enhets-ID, trots att inmatningsschemat innehåller många ytterligare fält som behövs för instrumentpaneler och enhetshantering.

Projicering och filterpushdown hindrar onödiga data från att komma in i skanningen

Kolumnlayout skapar möjligheten att hoppa över oanvända fält, men frågemotorn måste skicka ned denna information till filläsaren för att lagringsbesparingarna ska bli verkliga I/O-besparingar. Om alla kolumner först läses in och sedan kasseras har det fysiska formatet inte gett full effekt.

DuckDB kan tillämpa projicering och filterpushdown när Parquet läses, så att endast nödvändiga kolumner läses in och filter kan bidra till att hoppa över delar av filen. En fråga efter genomsnittlig luftfuktighet i ett rum kan därför begränsa både fälten och, när metadata tillåter det, de relevanta radintervallen innan hela körningen utförs.

För en lokal analystjänst minskar detta diskläsningar, dekomprimeringsarbete, minnestrafik och mängden mellanliggande data som skickas mellan operatorer. Vinsten är störst vid långa skanningar där de begärda fälten utgör en liten del av det lagrade schemat.

Pushdown sker inte automatiskt i alla pipelines. Om data bäddas in i en ogenomskinlig transformation eller om en läsare används som inte kan exponera predikat för lagringslagret kan det krävas mer materialisering än vad filformatet i sig skulle behöva.

Liknande värden som lagras tillsammans ger kodare och komprimerare bättre lokalitet

Sensorkolumner har ofta repetitiva eller långsamt föränderliga värdemönster: rumsnamn upprepas, booleska tillstånd förblir oförändrade under långa perioder, tidsstämplar ökar monotont och temperaturer ligger inom ett snävt numeriskt intervall. Genom att gruppera varje typ av värde tillsammans får kodare en mer regelbunden dataström än när varje fält från varje observation flätas samman.

Parquet stöder komprimering av kolumnsidor för kodade datasidor, så att varje kolumnblock kan använda en komprimeringskod efter att värdena har kodats. Bättre komprimering minskar mängden byte som en hemserver måste lagra och läsa under historisk analys.

Komprimeringsgraden beror på arbetsbelastningen och garanteras inte bara av ordet ”kolumnär”. Krypterade nyttolaster med hög kardinalitet eller redan komprimerade binära värden kan ge liten vinst, medan upprepade etiketter och strukturerade numeriska serier vanligtvis innehåller mer utnyttjbar redundans.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Metadata för radgrupper gör att läsaren kan hoppa över intervall som inte kan matcha

Historiska frågor innehåller ofta selektiva villkor, till exempel ett datumintervall, en enhetsklass eller avläsningar över ett tröskelvärde. Om metadata på fil- eller radgruppsnivå visar att ett område inte kan uppfylla predikatet vore det bortkastat arbete att läsa och avkoda området.

DuckDB kan använda Parquets minimi-/maximimetadata för filöverhoppning baserad på zonkartor under filterpushdown. Parquet definierar dessutom valfria Bloom-filter som kan hjälpa till att avgöra om värden kan finnas i ett kolumnblock. Dessa strukturer påskyndar frågor genom att undvika intervall som bevisligen är irrelevanta, inte genom att göra beräkningen av matchande rader billigare efter att de har lästs in.

Dataordningen påverkar hur effektiv denna gallring blir. Filer som ungefär grupperas efter tid, rum eller enhet kan skapa snävare metadataintervall än slumpmässigt blandade data, så en genomtänkt skrivlayout kan förstärka fördelarna med kolumnlagring.

Metadataöverhoppning är probabilistisk eller konservativ beroende på strukturen, och falska positiva resultat kan fortfarande orsaka extra läsningar. Den viktiga garantin är att gallringen inte får kasta bort intervall som kan innehålla giltiga träffar.

Kolumnbatcher passar väl för vektoriserad CPU-körning

När valda kolumner finns i minnet tillämpar analytiska operatorer upprepade gånger samma beräkning på många värden: jämförelser, summor, medelvärden, grupperingsnycklar eller transformationer. Sammanhängande värden passar bättre för CPU-cacheminnen och instruktioner som behandlar flera värden i en enda operation.

Apache Arrow beskriver en kolumnär minneslayout som förbättrar lokaliteten och möjliggör vektoriserad beräkning med processorer som stöder SIMD. En lokal frågemotor kan därför bearbeta batcher av temperaturer eller effektmätningar i stället för att upprepade gånger packa upp fullständiga heterogena poster, en rad i taget.

Denna fördel gäller den analytiska körningsvägen, inte bara komprimering på disk. Även en snabb SSD kan använda onödig bandbredd för att mata fram fält som processorn omedelbart ignorerar, medan en kolumnär pipeline minskar denna dataförflyttning innan beräkningarna börjar.

Kolumnlagring gynnar historiska skanningar mer än föränderligt aktuellt tillstånd

Samma layout som är effektiv för breda skanningar är inte automatiskt den bästa representationen för frekventa punktuppdateringar, små transaktioner eller hämtning av ett komplett aktuellt enhetstillstånd. Hemautomation och långsiktig analys kan därför dra nytta av olika lagringsvägar även när de beskriver samma sensorer.

Arrow gör uttryckligen avkall på stark analytisk lokalitet till förmån för dyrare ändringsoperationer, vilket illustrerar den bredare gränsdragningen: kolumnära system är som bäst när många värden skannas tillsammans, medan kontinuerlig omskrivning av små poster kan gynnas av en annan struktur.

En praktisk hemmaservermiljö kan behålla en radorienterad eller tillståndsorienterad databas för aktuella enhetstillstånd och med jämna mellanrum skriva historiska observationer till kolumnära filer för analys. ZimaSpaces separering av styrning och lokal analys återspeglar samma arkitektoniska idé: den väg som måste reagera på en livehändelse behöver inte dela fysisk datalayout med den som används för flera månaders efterhandsanalys.

Den relevanta frågan är därför inte om kolumnlagring universellt är snabbare. Frågan är om den dominerande arbetsbelastningen skannar ett urval av fält över många historiska rader, eftersom det är åtkomstmönstret som omvandlar kolumnseparation till mindre I/O och effektivare batchbearbetning.