Effizientes Handling von IoT-Daten

Verwaltung von Sensordaten

26. April 2023, 12:00 Uhr | Stefan Käser/am

Fortsetzung des Artikels von Teil 1

Automatische Aggregation

Während das Einfügen von Millionen von Zeilen pro Sekunde für ClickHouse kein Problem darstellt, ergibt es zeitgleich keinen Sinn, Milliarden von Zeilen zu scannen, nur um einfache Abfragen zu beantworten. Das ist zwar möglich, und ClickHouse kann Anfragen über Milliarden von Zeilen verarbeiten. Es ist jedoch nicht sinnvoll, all diese Zeilen von der Festplatte zu holen und sie jedes Mal zu lesen, um täglich Antworten abzurufen.

Zusammenfassen als Lösung

Da sich vergangene Daten nicht ändern können, kommt hier die Aggregation ins Spiel. Ebenso könnte das Unternehmen eine eigene Aggregationspipeline aufbauen, zum Beispiel in MySQL, aber ClickHouse hat integrierte Funktionen, die hier hilfreich sind.
Nun gilt es, die Aggregationstabellen und eine so genannte materialisierte Ansicht zu definieren, um die Aggregation durchzuführen, wann immer neue Daten in die Quelltabelle kommen. Diese materialisierten Ansichten können sogar aufeinander aufbauen, um komplette Aggregations-Pipelines innerhalb von ClickHouse ohne Aufwand für die Anwendung zu erstellen.

Angenommen, es geht darum, die Daten alle fünf Minuten zu aggregieren, da dies für komplexe Analysen des Stromverbrauchs detailliert genug sein sollte. Ebenso wäre aber auch eine tägliche Aggregation erforderlich, da die meisten Anfragen pro Tag erfolgen. Dies wäre der erste Trigger. Er aggregiert alle neuen Daten, die eingegeben werden, gruppiert sie in Fünf-Minuten-Blöcke und speichert das Aggregationsergebnis. Zudem fügt er automatisch entsprechende Werte hinzu, wenn bereits einige aggregierte Werte in der Tabelle für diesen spezifischen Sensor und diese Zeit vorhanden sind. Jedes Mal, wenn Daten in der Fünf-Minuten-Tabelle hinzukommen, ist auch die tägliche Aggregation zu aktualisieren.

Aktueller Stand

Jetzt steht eine Aggregationstabelle zur Verfügung, die Abfragen innerhalb eines Tages und über einen langen Zeitraum hinweg beschleunigt. Aber wie sieht es mit dem aktuellen Stand der Sensordaten aus? Wenn ein Benutzer sehen möchte, wie hoch der Stromverbrauch in seinem Haus ist, während er unterwegs ist, ist er nicht an langfristigen Analysen oder Intraday-Diagrammen interessiert, er möchte nur den aktuellen Zustand sehen. Natürlich ließen sich einfach die letzten Datenpunkte aus der Tabelle abrufen, aber dazu würde der Benutzer immer noch eine Menge Daten durchlesen müssen, da er den genauen Zeitpunkt nicht kennt. Auch hier können materialisierte Ansichten helfen. Hierzu ist eine weitere Tabelle zu erstellen, die den aktuellen Status aller Sensoren enthält. Jedes Mal, wenn ein neuer Datenpunkt in der Rohdaten-Tabelle hinzukommt, ist der Status in dieser Tabelle zu aktualisieren.

Nun ist alles eingerichtet, um alle Arten von Anfragen schnell zu beantworten, doch es bleibt ein Problem: Daten zu speichern kostet Geld. Dies gilt insbesondere für alte Daten, die man nur selten benötigt, jedoch genauso viel Speicherplatz beanspruchen wie frische Daten – nur, dass sie nicht mehr so viel Wert liefern. Es gibt jedoch Möglichkeiten, dieses Problem mit verwaltetem ClickHouse mit einer modernen Managed-Database-Lösung auf einfache Weise zu überwinden.

Entfernen von Daten mit TTL

Zunächst gilt es, zu entscheiden, ob wirklich alle Daten erforderlich sind, die vorhanden sind. Die günstigste Art, Daten zu speichern, ist, sie loszuwerden. Da im vorliegenden Beispiel die Daten automatisch auf fünf Minuten und tägliche Aggregationen verdichtet sind, stellt sich die Frage, ob eine Datengranularität von wenigen Sekunden wirklich nötig ist, also bespielsweise wie viel Strom ein Kühlschrank um 7:00:05 Uhr verbraucht hat. Es ist davon auszugehen, dass ein Datenpunkt alle fünf Minuten für Langzeitanalysen mehr als ausreichend ist. Im Fall eines Fehlers könnte es jedoch interessant sein, sekundengenaue Daten für einige Tage zu haben.

Eine Option wäre, die Rohdaten nach sieben Tagen loszuwerden. Dies erfolgt in ClickHouse einfach durch Hinzufügen einer TTL (Time to Live). Dies reicht aus, um alte Daten nach sieben Tagen automatisch zu löschen. Zu beachten ist, dass aggregierte Daten nicht von der Löschung von Daten in der Quelltabelle betroffen sind. Die Aggregation findet nur zum Zeitpunkt des Einfügens statt.

Hybride Speicherung

Durch die Aggregation und die Verwendung der TTL würden sich im vorliegenden Anwendungsfall die Daten in der Größenordnung eines Faktors 60 reduzieren. Es wären aber immer noch fast eine halbe Milliarde Zeilen zu speichern, wenn die Granularität der Daten von fünf Minuten für spezielle analytische Anfragen nötig ist, auch wenn die meiste Zeit nur ein Bruchteil dieser Daten regelmäßig erforderlich sein dürfte.

Die meisten Benutzer werden sich Diagramme für heute oder gestern ansehen. Vielleicht schauen sie auch ein paar Tage in die Vergangenheit, aber eine Granularität von fünf Minuten bei einem Zeitraum von mehr als vor einem Monat dürfte nicht oft nötig sein. Trotzdem gilt es, die Daten für diese Fälle aufzubewahren, und es wird genauso viel Geld kosten wie für die Daten der letzten zwei Tage. Oder doch nicht?

Kalte und warme Daten

ClickHouse hat speziell hierfür eine Lösung: Tiered Storage. Benutzer können innerhalb einer Tabelle festlegen, ob gewisse Daten als „warm“ oder „kalt“ anzusehen sind. Warme Daten lassen sich so speichern, wie sie sind, aber kalte Daten kann man in S3 (Amazon Simple Storage Service) exportieren. Dort lassen sie sich viel kostengünstiger vorhalten und dennoch bei Bedarf abrufen. Bei der Verwendung von ClickHouse mit einer entsprechenden Managed-Database-Lösung ist dies einfach einzurichten. Der Benutzer ändert hierfür zunächst die Speicherrichtlinie für die Fünf-Minuten-Tabelle, um verschiedene Speicherebenen zu aktivieren. Nun muss er nur noch entscheiden, welche Art von Daten er als kalt betrachtet. Will er Daten als warme Daten 40 Tage aufbewahren, muss er nur eine weitere TTL hinzufügen, die ClickHouse anweist, die Daten nicht zu löschen, sondern sie nach S3 zu verschieben.

Stefan Käser ist Solution Architect bei DoubleCloud.


  1. Verwaltung von Sensordaten
  2. Automatische Aggregation

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Ionos

Weitere Artikel zu Daten-Analyse

Weitere Artikel zu Conrad Electronic SE

Matchmaker+