In unterschiedlichen Ausprägungen sind sie Teil nahezu aller unsere Welt durchziehenden Systeme. Egal ob im Finanzbereich, im Transportwesen oder im Energiesektor hinter jeder Anwendung steht eine Datenbank. Je nach Anwendungsgebiet eignet sich das eine Modell besser als das andere. In all den zuvor genannten Branchen kann es jedoch von zentraler Bedeutung sein, zu wissen, wie sich eine bestimmte Variable über einen längeren Zeitraum verhält. Es spielt dabei keine Rolle, ob es sich um Aktienkurse, Telemetriedaten oder Stromfrequenzen handelt, überall müssen Werte zu kontinuierlichen Zeitpunkten gemessen werden.

Für diesen Zweck eigenen sich Zeitreihendatenbanken besonders, da sie auch in der Lage sind, bestimmte Trends zu erkennen. Immer dann, wenn Serien von Messungen, Beobachtungen sowie Zuständen zu bestimmten Zeitpunkten benötigt werden, ist es sinnvoll, auf Zeitreihendatenbanken zurückzugreifen. Nicht nur die Organisation der Daten nach Zeit, sondern auch die hohe Anzahl an Schreibvorgängen und Abfragen sowie der Zugriff auf parallele Datenquellen sind Vorteile einer Zeitreihendatenbank. Darüber hinaus bietet sie große Flexibilität bei der Definition/Typisierung von Daten und verfügt über Funktionen zum automatisierten Löschen und Komprimieren dieser.

Gerade in unseren Energieprojekten haben wir uns immer wieder mit den Vorteilen von Zeitreihendatenbanken wie InfluxDB auseinandergesetzt. Gemeinsam mit marktführenden Energieversorgern haben wir Anwendungen zur Steuerung und Prognose von Energieengpässen und -überschüssen Virtueller Kraftwerke entwickelt. Unsere Kunden bieten Strom aus erneuerbaren Energien auf dem Regelleistungsmarkt an. Energieversorger sind verpflichtet, Prognosen über ihre Einspeisung und Entnahme abzugeben, um die Normalfrequenz im deutschen Stromnetz bei 50 Hertz halten zu können. Da die Stromproduktion erneuerbarer Energien von unterschiedlichen Faktoren abhängt, kommt es häufig zu Schwankungen, die ausgeglichen werden müssen. Um diese Schwankungen auswerten zu können, haben wir für unsere Kunden an Anwendungen mit InfluxDB und Telegraf gearbeitet.

InfluxDB

InfluxDB wurde von InfluxData eigens für Zeitreihendaten entwickelt und ist darauf ausgelegt, mit enormen Mengen zeitgestempelter Daten zu arbeiten. Einzelne Datenpunkte in einer Datenreihe werden in InfluxDB automatisch durch einen Zeitstempel identifiziert. Die auf hohe Schreib- und Abfragevorgänge zugeschnittene Datenbank ist ein verlässliches Tool für den kontinuierlichen Betrieb. Vor allem in der Verwaltung der Daten bietet InfluxDB mit seinen Funktionen Daten zusammenzufassen (Continuous Query) und zu löschen (Retention Policy) effiziente Lösungen. Bevor wir uns jedoch damit befassen, möchten wir erst einmal einige Begriffe, die zum Verständnis wie Zeitreihendaten in InfluxDB organisiert und gespeichert werden, klären.

Struktur

Die oberste Ebene bildet dabei die Database. Sie fungiert als Container für eine oder mehrere Zeitreihen, die in InfluxDB als Measurements bezeichnet werden. Measurements sind Strings und ihr Name bestimmt in der Regel, welche Daten aufgezeichnet werden (bspw. Temperatur, Geschwindigkeit) Sie beinhalten Tags, Fields sowie die Zeitspalte. Alle Daten in InfluxDB werden zwingend und automatisch mit einer Zeitspalte versehen, die wiederum den Zeitstempel, der den Zeitpunkt der Messung mit Datum und Uhrzeit angibt, enthält.

Fields sind wie die Zeitspalte zwingend erforderlich in einer InfluxDB-Datenstruktur. Sie bilden das Schlüssel-Wert-Paar, das Metadaten (Field Keys) sowie den eigentlichen Datenwert (Field Values) aufzeichnet. Field Keys sind Strings und können bspw. die Energieproduktion sein, während Field Values die tatsächlichen Messwerte bezeichnen, die an den Zeitstempel gebunden sind.

Fields werden im Gegensatz zu Tags von der InfluxDb nicht automatisch indiziert. Da jeder Index aktualisiert werden muss, wirkt sich das nachteilig auf die Schreibvorgänge aus. Daher empfiehlt es sich, nur jene Fields zu indizieren, die für Abfragen und Aggregationen häufig verwendet werden.

Für Metadaten, die die Datenpunkte beschreiben, verwendet man am besten Tags. Wie Fields sind sie ein Schlüssel-Wert-Paar und setzten sich aus Tag Key und Tag Value zusammen. Sie sind kein zwingender Bestandteil der InfluxDB-Datenstruktur, werden aber indexiert, weshalb diese sich auch vorrangig zum Speichern für Abfragen eignen.

Ein weiterer wichtiger Bestandteil zum besseren Verständnis der InfluxDB-Struktur, die im Übrigen auch Schema genannt wird, sind Datenpunkte. Sie bezeichnen den einzelnen Datensatz und setzen sich aus Measurement, Tag Set, Field Set sowie dem Zeitstempel zusammen. Datenpunkte erhalten ihre Einzigartigkeit durch den Zeitstempel und der Series, der sie angehören. Bei einer Series handelt es sich um eine Sammlung von Datenpunkten, die Measurement, Tag Set und Field Key gemeinsam haben.

Um diese Struktur auch praktisch zu veranschaulichen, haben wir einen kurzen Anwendungsfall für einen Energieproduzenten mit Biogasanalge mit fiktiven Daten erarbeitet.

Das Measurement (engine) sammelt in diesem Beispiel Daten zu den Generatoren. Unter Tag Key (engine_id) werden im Tag Value alle Generatoren angezeigt, die Strom produzieren. Da sich Tag Keys hervorragend zum Abfragen von Metadaten eignen, haben wir noch zwei weitere hinzugefügt. Einen Tag Key (malo_id) zur Identifikation der Marktlokation, um zu wissen, für welche Marktlokation der jeweilige Generator den Strom produziert und den anderen Tag Key (unit) für die Einheit, in der die Energieproduktion gemessen wird. Die eigentlichen Messwerte finden sich in den Field Values. Auch hier haben wir drei Field Keys gesetzt. Der erste Field Key (power_production) misst die Energieproduktion, der zweite Field Key (rpm) die Drehzahl des Generators und der letzte Field Key (max_delta) bestimmt, wie viel kWh zusätzlich der Generator bis zur maximalen Energieerzeugung noch liefern könnte.

Retention Policy und Continuous Query

Für die Verwaltung und Organisation der Daten, insbesondere großer Datenmengen, liefert InfluxDB mit der Retention Policy (Daten löschen) sowie der Continuous Query (Daten zusammenfassen) zwei wertvolle Hilfsmittel.

Retention Policys sind einzigartig für jede Datenbank und beschreiben, wie lange die Daten aufbewahrt werden sollen. InfluxDB vergleicht dazu den Zeitstempel des Servers mit dem Zeitstempel der Daten und löscht alle Daten, die älter sind, als es von der Retention Policy definiert wurde.

Continuous Querys sind Abfragen, die automatisch und regelmäßig ausgeführt werden und die Ergebnisse in einem neuen Measurement speichern. Um eine Continuous Query auszuführen, erfordern diese eine Funktion in der SELECT clause und müssen eine GROUP BY()time clause beinhalten. InfluxQL bietet eine Vielzahl an Funktionen, die unter den Begriffen Aggregate, select, transform und predict zusammengefasst sind.

Die nachfolgende Grafik veranschaulicht die Auswirkungen einer Retention Policy sowie Continuous Query. Der Zeitraum der Datenpunkte, die von der Retention Policy gelöscht werden sollen, wird kontinuierlich erweitert. Für die Continuous Query wird die Aggregat-Funktion mean() zur Verdichtung der Datenpunkte angewendet, die immer mehr Daten zu einem Datenpunkt zusammenfasst.

Um Daten zu sammeln bzw. an InfluxDB übermitteln zu können, benötigt es jedoch eine eigene Anwendung. Hierfür eignet sich bspw. Telegraf, eine Software, die auch von InfluxData eigens dafür entwickelt wurde.

Telegraf

Telegraf ist ein Plug-in-gesteuerter Server-Agent zum Sammeln und Senden von Metriken und Ereignissen aus Datenbanken, Systemen und IoT-Sensoren. Die Anwendung ist in Go geschrieben und wird zu einer einzigen Binärdatei ohne externe Abhängigkeiten kompiliert. Das Plug-in-System deckt eine Vielzahl an Möglichkeiten ab, Daten zu beziehen (third-party APIs, StatsD, Kaftka, MQTT etc.) bzw. auszugeben (InfluxDB, OpenTSDB, Kafka, MQTT etc.).

Abschließend möchten wir noch einmal auf unser Beispiel mit der Biogasanlage eingehen und das Zusammenwirken von Datenquelle, Telegraf, Datenbank (InfluxDB) sowie Ausgabe veranschaulichen.

Architektur

Am Beginn steht die Anlage zur Energieerzeugung bzw. dem -verbrauch, welche die Daten für InfluxDB liefert. Mittels spezieller Hard- (Sensoren, Drehzahlmesser) und Software werden die Messungen (Energieproduktion, Motordrehzahl, Delta zur maximalen Energieproduktion) abgenommen und an einen MQTT Broker übermittelt. Telegraf wird so programmiert, dass die Anwendung sich die Daten holt und im Anschluss an die InfluxDB weitergibt. Über bspw. ein Portal können dem Energieproduzenten die Daten in unterschiedlichen Formen wie bspw. Diagrammen angezeigt werden. Hierfür benötigt es nicht immer eine eigene Anwendung, auch Tools wie bspw. Grafana sind in der Lage, die Daten visuell darzustellen.

Die Anwendungsgebiete von InfluxDB sind vielseitig. Aufgrund ihrer Struktur und Funktionen, die darauf ausgelegt sind, mit einer großen Anzahl von Zeitreihen zu arbeiten, lohnt es sich, InfluxDB oder eine andere Zeitreihendatenbank für das ein oder andere Projekt einmal auszuprobieren.

Quellen:

www.influxdata.com