Comment le stockage en colonnes accélère-t-il l’analyse des capteurs domestiques ?

Le stockage en colonnes accélère l’analyse des données de capteurs domestiques en conservant ensemble les valeurs des mêmes champs, afin que les requêtes analytiques puissent éviter de lire les données sans rapport.

Une table d’historique de maison connectée peut contenir des horodatages, des identifiants d’appareils, des pièces, des températures, l’humidité, la consommation électrique, l’état de détection de mouvement, le niveau de batterie, des indicateurs de qualité et des métadonnées pour des millions d’observations. La plupart des questions historiques n’utilisent que quelques-uns de ces champs et agrègent de nombreuses lignes, ce qui est presque l’opposé d’une application qui récupère régulièrement un enregistrement actuel complet. Les structures en colonnes optimisent ce parcours d’analyse et d’agrégation en modifiant à la fois les données à lire et la manière dont des lots de valeurs similaires parviennent au processeur.

La disposition en colonnes sépare les champs réellement nécessaires à une requête analytique

Un enregistrement orienté lignes conserve ensemble tous les champs d’une observation, ce qui est pratique lorsque l’application a besoin de l’observation complète. Une représentation orientée colonnes regroupe au contraire les valeurs par champ, ce qui permet à une requête portant sur six mois de températures de se concentrer sur l’horodatage, la pièce et la température sans faire transiter les chaînes de version du micrologiciel, les données de batterie et les états sans rapport des appareils lors de la même analyse.

Apache Parquet est un format de données orienté colonnes conçu pour stocker et récupérer efficacement de grandes quantités de données. Cette séparation physique est la première raison pour laquelle une requête analytique ciblée peut déplacer moins de données qu’une analyse complète des lignes de la même table logique.

L’avantage augmente à mesure que les enregistrements s’élargissent et que les requêtes restent sélectives. Un rapport de consommation énergétique domestique peut ne consulter que l’horodatage, les watts et l’identifiant de l’appareil, alors que le schéma d’ingestion contient de nombreux champs supplémentaires nécessaires aux tableaux de bord et à la gestion des appareils.

La projection et le filtrage poussés évitent d’introduire des données inutiles dans l’analyse

La disposition en colonnes permet d’ignorer les champs inutilisés, mais le moteur de requêtes doit transmettre cette information au lecteur de fichiers pour que les économies de stockage se transforment réellement en économies d’E/S. Si chaque colonne est d’abord chargée puis supprimée, le format physique n’a pas produit tous ses bénéfices.

DuckDB peut appliquer une projection et un filtrage poussés lors de la lecture de fichiers Parquet. Seules les colonnes nécessaires sont ainsi lues, tandis que les filtres peuvent contribuer à ignorer certaines portions du fichier. Une requête calculant l’humidité moyenne dans une pièce donnée peut donc restreindre à la fois les champs et, lorsque les métadonnées le permettent, les plages de lignes pertinentes avant l’exécution complète.

Pour un service d’analyse local, cela réduit les lectures sur disque, le travail de décompression, le trafic mémoire et le volume de données intermédiaires transmis entre les opérateurs. Le gain est maximal lors des analyses longues où les champs demandés ne représentent qu’une faible part du schéma stocké.

La transmission des filtres n’est pas automatique dans tous les pipelines. Encapsuler les données dans une transformation opaque ou utiliser un lecteur incapable d’exposer les prédicats à la couche de stockage peut forcer davantage de matérialisation que ne l’exigerait le format de fichier lui-même.

Le regroupement de valeurs similaires offre une meilleure localité aux encodeurs et aux compresseurs

Les colonnes de capteurs présentent souvent des motifs répétitifs ou évoluant lentement : les noms des pièces se répètent, les états booléens restent inchangés pendant de longues périodes, les horodatages progressent de manière monotone et les températures se situent dans une plage numérique étroite. Le regroupement de chaque type de valeur produit un flux plus régulier pour les encodeurs que l’entrelacement de tous les champs de chaque observation.

Parquet prend en charge la compression des pages de colonnes sur les pages de données encodées. Chaque bloc de colonne peut ainsi utiliser un codec de compression après l’encodage de ses valeurs. Une meilleure compression réduit le nombre d’octets qu’un serveur domestique doit conserver et lire lors de l’analyse historique.

Le taux de compression dépend de la charge de travail et n’est pas garanti par le simple fait d’utiliser un format « en colonnes ». Les données chiffrées à forte cardinalité ou les valeurs binaires déjà compressées peuvent offrir peu de gains, tandis que les libellés répétés et les séries numériques structurées présentent généralement davantage de redondance exploitable.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Les métadonnées des groupes de lignes permettent au lecteur d’ignorer les plages qui ne peuvent pas correspondre

Les requêtes historiques incluent souvent des conditions sélectives, comme une plage de dates, une catégorie d’appareils ou des relevés supérieurs à un seuil. Si les métadonnées du fichier ou du groupe de lignes prouvent qu’une région ne peut pas satisfaire le prédicat, lire et décoder cette région serait un travail inutile.

DuckDB peut utiliser les métadonnées min/max de Parquet comme mécanisme d’exclusion de fichiers fondé sur les zonemaps lors de la transmission des filtres. Parquet définit également des filtres de Bloom facultatifs, qui peuvent aider à déterminer si des valeurs sont susceptibles d’être présentes dans un bloc de colonne. Ces structures accélèrent les requêtes en évitant les plages dont la pertinence est exclue, et non en rendant moins coûteux le calcul des lignes correspondantes après leur chargement.

L’ordre des données influence l’efficacité de cet élagage. Des fichiers regroupés approximativement par date, pièce ou appareil peuvent produire des plages de métadonnées plus étroites que des données entrelacées aléatoirement. Une organisation d’écriture cohérente peut donc amplifier les bénéfices du stockage en colonnes.

L’exclusion fondée sur les métadonnées est probabiliste ou prudente selon la structure utilisée, et des faux positifs peuvent toujours entraîner des lectures supplémentaires. La garantie essentielle est que l’élagage ne doit pas supprimer des plages susceptibles de contenir des correspondances valides.

Les lots en colonnes s’adaptent bien à l’exécution vectorisée par le processeur

Une fois les colonnes sélectionnées chargées en mémoire, les opérateurs analytiques appliquent de manière répétée le même calcul à de nombreuses valeurs : comparaisons, sommes, moyennes, clés de regroupement ou transformations. Des valeurs contiguës facilitent ce travail pour les caches du processeur et pour les instructions capables de traiter plusieurs valeurs en une seule opération.

Apache Arrow décrit une disposition mémoire en colonnes qui améliore la localité et permet un calcul vectorisé sur des processeurs compatibles SIMD. Un moteur de requêtes local peut ainsi traiter des lots de températures ou de relevés de consommation au lieu de décomposer répétitivement des enregistrements hétérogènes complets, ligne par ligne.

Cet avantage concerne le parcours d’exécution analytique, et pas uniquement la compression sur disque. Même un SSD rapide peut consacrer une bande passante inutile à des champs que le processeur ignore immédiatement, tandis qu’un pipeline en colonnes réduit ce déplacement avant le début des calculs.

Le stockage en colonnes favorise davantage les analyses historiques que l’état actuel mutable

La même disposition, efficace pour les analyses étendues, n’est pas automatiquement la meilleure représentation pour les mises à jour ponctuelles fréquentes, les petites transactions ou la récupération de l’état complet d’un appareil. La domotique et l’analyse à long terme peuvent donc bénéficier de chemins de stockage différents, même lorsqu’elles décrivent les mêmes capteurs.

Arrow échange explicitement une forte localité analytique contre des opérations de modification plus coûteuses, ce qui illustre une limite plus générale : les systèmes en colonnes excellent lorsque de nombreuses valeurs sont analysées ensemble, tandis que la réécriture continue de petits enregistrements peut favoriser une autre structure.

Une architecture domestique pratique peut conserver une base de données orientée lignes ou orientée état pour l’état actuel des appareils, puis écrire périodiquement les observations historiques dans des fichiers en colonnes pour l’analyse. La séparation entre contrôle et analyse locale de ZimaSpace reflète la même idée architecturale : le chemin qui doit réagir à un événement en direct n’a pas besoin de partager la disposition physique utilisée pour plusieurs mois d’analyse rétrospective.

La bonne question n’est donc pas de savoir si le stockage en colonnes est universellement plus rapide. Il faut déterminer si la charge de travail dominante analyse un sous-ensemble de champs sur de nombreuses lignes historiques, car c’est ce schéma d’accès qui transforme la séparation des colonnes en réduction des E/S et en traitement par lots plus efficace.