In Teil 1 (Blob Storage), 2 (SQL Storage) und 3 (Cosmos DB) haben wir die verschiedenen Azure Speichermedien kennen gelernt. Auch für die Datenanalyse stellt Azure eine überwältigende Anzahl von Services zur Verfügung, für die dieser Blog eine kurze Übersicht geben soll.

Doch wozu braucht es überhaupt Analysen? Applikationen, Geräte oder auch nur Log Files erzeugen heute riesige Datenmengen, die in Azure Storage oder Event Hubs gespeichert werden. In einem weiteren Schritt konvertiert Azure Data Factory die Daten in ein für die Auswertung geeignetes Zielformat oder Streaming Analytics filtert die Daten, während sie eintreffen. Diverse Analyseverfahren werten die gespeicherten Daten aus, um Antworten auf bestimmte Businessfragen zu erhalten.

Data Processing Varianten

Generell unterscheidet man zwischen Stream Processing und Batch Processing. Azure kennt zu jedem Zweck eine Reihe von Services.

Stream Processing

Stream Processsing verarbeitet und analysiert Daten direkt nach ihrer Entstehung. Oft spricht man auch von Real-Time Analyse oder Event Processing. Typische Anwendungen finden sich im IoT Bereich.

• Azure Stream Analytics: Echtzeitanalyse von Datenströmen, z.B. aus IoT Devices.
• Storm und Spark Streaming
• Azure Time Series Insights: End-to-end-IoT Analyseplattform für Überwachung, Analyse und Visualisierung von IoT Daten.

Batch Processing

Batch Processing sammelt Daten zunächst in Datenbanken und verarbeitet sie erst nachträglich bei Bedarf. Dieses eher klassische Verfahren eignet sich für grosse Datenmengen (Big Data) oder bei Datenquellen aus Legacy Systemen, wenn Echtzeitinformationen nicht erforderlich sind.

• Azure Databricks: Apache Spark basierte Analyse als Cloud Service
• Azure Data Lake Analytics: Analyse grosser Data Sets im Data Lake Store mit U-SQL. Programmierung in Python, R oder C# Extensions.
• Azure Synapse Analytics (früher SQL Data Warehouse): Kombiniert Datenablage, Aufbereitung und Bereitstellung von Daten aus verschiedenen Quellen mit dem Tool Synapse Studio.

Kombination von Stream und Batch Processing

• HDInsight (Microsofts Implementierung von Apache Hadoop): Verwendung von Open Source Frameworks Apache Spark, Apache Storm (Stream), Apache HBase (NoSQL Datenbank), Kafka und anderen zur Analyse grosser Datenquellen.

Weitere Dienste

• Azure Data Factory: Service mit vielen Konnektoren für das Laden, Transformieren und Ablegen von Daten. Dieser Schritt ist häufig nötig, bevor die Daten analysiert werden können.
• Azure Analysis Services: Cloud Version der Analyse Werkzeuge des SQL Server. Enthält ein InMemory Datenmodell, auf das Benutzer Abfragen formulieren können, welche in BI-Tools ausgewertet werden
• Azure Log Analytics: Analyse von Logdaten aus Azure Monitor

Architekturen

Lambda Architektur

Die Lambda Architektur kombiniert die traditionelle Batch Pipeline mit einer schnellen Echtzeit Stream Pipeline für die Verarbeitung von Daten. Die Daten aus beliebigen Quellen gelangen gleichzeitig an den Batch Layer und an den Speed Layer. Im Batch Layer werden sie zunächst in einem sequentiellen Datenspeicher (z.B. Apache Hadoop) abgelegt, bevor sie vom Serving Layer in einzelnen Batches für die weitere Verarbeitung aufbereitet werden. Der Speed Layer ermöglichet eine kontinuierliche Verarbeitung der Daten und liefert schnelle Ergebnisse. Dazu eignen sich Technologien wie Apache Storm oder Stream Analytics.

Der Nachteil dieser Architektur ist, dass die beiden Datenpfade im Batch Layer und Speed Layer unnötige Komplexität bewirken. Dies wird verbessert durch die Kappa Architektur.

Kappa Architektur

Die Kappa Architektur verzichtet auf den Batch Layer, die Daten gelangen direkt in den Streaming Prozessor, der sie nach der Verarbeitung für weitere Abfragen speichert.

Anwendungsbeispiel

Eine typische Applikation könnte aussehen wie in folgendem Bild.

Beliebige Datenquellen liefern Aktualisierungen in regelmässigen Abständen in einen Blob Storage. Data Factory bereinigt und transformiert die Daten und überträgt sie in Azure Synapse Analytics. PolyBase kann diesen Prozess für umfangreiche Datasets parallelisieren. Nachdem ein neuer Datenbatch im Warehouse zur Verfügung steht, aktualisiert Analysis Services das zuvor erstellte Tabellenmodell und überreicht die Daten an Power BI zur Visualisierung der Ergebnisse.

PolyBase

PolyBase ist ein Datenvirtualiserungsfeature für SQL Server, das ohne Treiber für die entsprechende Datenbank (z.B. Oracle, MongoDB, Hadoop, Azure Storage) auskommt. Dabei verbleiben die Daten im Quellformat an ihrem ursprünglichen Speicherort. Die SQL Server Instanz virtualisiert diese externen Daten und stellt sie wie andere Tabellen für die Auswertung zur Verfügung.

Dies reduziert aufwendige Datentransferoperationen.

Almost everyone who works with sensor data, processs and stores time series data. This post contains some of my experiences with Azure Time Series Insights, gained by migrating an existing application to Time Series Insights.

The “Pre Time Series Insights” era

In the past days it was difficult to store the time series data in suitable way to retreive it later on without much delay. We used all kinds of tricks to improve the query performance on the frontend.

A typical pattern, which I used in the past, was to aggregate the data over slots of several minutes, hours and days and store the im different tables or collections. But even with the support of windowing functions in Azure Stream Analytics, the resulting query performance while reading the data was not overwhelming.

The following picture shows such an example:

The example uses Stream Analytics with window functions to aggreagte the data over time and puts it to different storage collections containing the aggregates. This requires much memory and performance and Stream Analytics is restricted to 5 outputs. The type of storage can range from CosmosDB with collections for the aggrgates, Azure SQL (DWH) with tables for the aggregates or even table storages. The Query API represents a web service which queries the data, typically a backend API service for a single page web app or mobile apps.

Another drawback of these approaches is the high coupling between the writer (Stream Analytics) and the reader (Query API). Each side needs logic to manage the different aggreates, which clutters the logic in the components around the data store and makes it hard to maintain the solution. The Query API in the picture above is restricted to the granularity of the aggregations which are provided by the Stream Analytics Job. Changes on the granularity require changes in two components and migration or recalculation of the stored aggregates.

Migrating to Time Series Insights

The migration from the previous solution to Time Series Insights, went very smooth. We changed the implementation of the query API service, which is responsibel for querying an retreiving the time series data for mobile apps. It was amazing how much code became obsolete and was dropped. We got a much cleaner imlementation. And the best: The performance boost was amazing!

As a starting point we used the code from the article Query data from the Azure Time Series Insights environment using C#. The only drop of bitterness was the buggy documentation of the Query API and the Query Syntax especially the part realted to aggregates. From a developers perspective, a swagger API would be a huge benefit. If you agree with that, you can vote for my suggestion for a Swagger API for Time Series Insights

Where Time Series Insights shines

The most important advantage of Time Series Insights is its query performance. Especially important four our cases is the ability to retreive data aggregated over time using a dateHistogram aggregate without noticable delays. Here Time Series Insights shines! This is a common use case for apps which can only display a chart with a certain amount of data points independent of the chosen time span.

The integrated Time Series Insights explorere is very useful tool for testing and debugging the incomimng data, which saves a lot of time.

The decoupling of the input API from the output API improves maintainability of the whole solution. This goes into the direction of CQRS where separate model for writing and reading (querying) exist.

The picture below shows a typical example with Time Series insights.

In this example the Stream Analytics Job contains only the logic to reshape the data. No aggregation is required. Therefore the performance requirements are considerably lower. It might be even possible to completly omit the Stream Analytics Job if the data already has the apropriate format and no additional logic for example for alarming, is required. The preprocessed data is forwarded to an Event Hub which is attached to the Time Series Insights by an Event Source (not shown in the picture).Time Series Insights stores the data in an appropriate format which facilitats fast retreival. Time Series Insigths already contains an API which can be used to query aggregates and raw events. The Query API here is much smaller and acts more like a serving layer which hides the technical details of the Time Series Insights API from the public API for single page web apps or mobile apps and returns data combined from Time Series Insights and other data sources.

Conclusions

Due to the restrictions of the amount of data and the retention time of currently max 400 days, Time Series Insights is not intendend to store data over a long term. For those familiar with the lambda architecture pattern, Time Series Insights is a good storage for data at speed, between the speed and the serving layer. For long term data storage there are other solutions such as Data Lake Storage or simple blob storages which can be processed by HDInsight.

The real benefit of Time Series Insights is suitable to give the clients high performance access to the most recent data aggregated over any time range and granularity.

This post first appeared on: martin-weber.github.io