Category

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.

Der 2. Teil dieser Blog Serie hat die Möglichkeiten gezeigt, wie strukturierte Daten gespeichert werden.

Dieser Teil beschreibt die vielfältigen Möglichkeiten der Azure Cosmos DB (früher DocumentDB genannt).

Cosmos DB ist ein global verteilter, multi-model Datenbank Service, insbesondere für NoSQL Daten. Grosse Datenmengen (Big Data) lassen sich nicht in SQL Datenbanken verwalten, diese skalieren zu schlecht. Cosmos DB speichert Items in Containern (vergleichbar mit Tabellen) und gruppiert diese in „Datenbanken“. Eine Datenbank innerhalb einer Cosmos DB verhält sich wie ein Namespace.

Cosmos DB Paradigmen

Folgende Paradigmen werden unterstützt:

• Table API: Speichert Items in einer Table. Daten aus dem Table Storage lassen sich einfach in die Cosmos DB übertragen.
• SQL: Ein JSON-freundlicher SQL Dialekt erzeugt, aktualisiert und löscht Items und Container.
• MongoDB: speichert Dokumente in Collections
• Gremlin: für Graphdatenbanken, z.B. Speichern von Organisationsstrukturen. Speichert Graphen als Nodes und Edges.
• Cassandra: Interaktion mit der Datenbank mit der Cassandra Query Language (CQL). Ist ein Table Row Storage.

Die verschiedenen Paradigmen vereinfachen die  Migration bestehender Datenbanken in die Cosmos DB. Der Entwickler wählt das Modell beim Anlegen der Cosmos DB und kann es später nicht mehr ändern.

Relationale Datenbanken zeichnen sich durch eine strenge ACID-Semantik aus und garantieren so jederzeit einen konsistenten Datenzustand. Dafür erleiden sie Einschränkungen bezüglich Parallelität, Latenz und Verfügbarkeit. Die hohen Konsistenzanforderungen sind nicht für jede Art von Applikation gefordert. Die bekannten Social Media Plattformen oder auch Suchmaschinen sind gute Beispiele, wo Konsistenz kein Kriterium ist. Dokumentenorientierte Datenbanken passen zudem hervorragend zu den objektorientieren Ansätzen in der Programmierung. Die Herstellung komplexer Beziehungen in relationalen Daten über Joins kann sehr teuer werden, da die Daten physikalisch nicht beieinander liegen. So ist es z.B. effizienter, alle Daten zu einem Mitarbeiter in einem einzigen JSON Dokument hierarchisch abzulegen, als sie über viele Tabellen zu verteilen. Beziehungen werden als „First-class Citizens“ in der Datenbank abgelegt und auch Objekthierarchien sind einfach abzubilden.

Eine Cosmos DB anlegen

Nachdem man in Azure eine Cosmos DB angelegt hat, erzeugt man zunächst einen Container. Ein Container braucht einen Partition Key zur Strukturierung der Daten (z.B. /address/zipCode). Zudem definiert man einen Throughput in Request Units (RU) pro Sekunde, der die Performance der Datenbank steuert.

Cosmos DB verteilt die Daten aufgrund des Partition Key automatisch auf verschiedene physische Partitionen und kann so gut skalieren. Die richtige Wahl des Partition Key ist also wichtig, er soll die Daten möglichst gleichmässig verteilen, wie wir im folgenden sehen.

Partitionierung der Daten

Ein zentrales Element des Datenbankdesigns von NoSQL Datenbanken ist die Partitionierung. Wir unterschieden zwischen logischen und physischen Partitionen.

• Eine logische Partition ist ein Set von Items in einem Container mit dem gleichen Partition Key. Ein Container enthält so viele logische Partitionen wie nötig, aber deren Grösse ist auf 20 GB limitiert.
• Eine oder mehrere logische Partitionen liegen in einer physischen Partition. Eine physische Partition enthält zudem mehrere Kopien der Daten, Replica Set genannt. All dies wird von Cosmos DB verwaltet. Die vorhandenen RU’s werden gleichmässig über die physischen Partitionen verteilt. Wenn wir z.B. 20’000 RU’s für 2 phys. Partitionen haben und sich 95% der Daten in der einen Partition befinden, können wir faktisch nur gut 10’000 RU’s nutzen.

Aus diesem Grund ist die Wahl eines geeigneten Partition Key essentiell, weil dieser eine Anfrage zur korrekten Partition leitet. Es muss ein Wert sein, der sich für ein Item nie ändert, und soll viele unterschiedliche und gleich verteilte Werte haben. Zudem sollen Cross-Partition Abfragen minimiert werden. Cosmos DB verwendet einen Hash-Code für den Partition Key. Der Partition Key muss beim Anlegen eines Containers definiert werden. Gute Kandidaten sind Properties, die häufig als Filterparameter in Abfragen erscheinen. Geeignete Partition Keys sind z.B. TenantId, ZipCode, etc.

Konsistenzlevels

Für bessere Verfügbarkeit und geringere Latenz repliziert Cosmos DB seine Daten auf Wunsch rund um den Globus. Ein Update benötigt deshalb eine gewisse Zeit, bis die Daten auf alle Knoten verteilt sind. Während dieser Zeit sind die Daten nicht überall konsistent. Der Konsistenzlevel steuert, wie sich eine Datenbank in solchen Fällen verhalten soll.

Cosmos DB kennt 5 verschiedene Konsistenzlevels

• Eventual: höchste Verfügbarkeit und geringste Latenz. Inkosistenz ist akzeptiert, aber es dauert eine Weile, bis geänderte Daten zu allen Nodes repliziert sind. Es ist auch nicht garantiert, dass die eigenen Writes bereits gelesen werden.
• Consistent prefix: Updates liefern einen Prefix aller Updates. Dies garantiert, dass beim Lesen nie ein ausserordentliches Write gesehen wird. Die Updates werden in der korrekten Reihenfolge gelesen.
• Session: Konsistent für den eigenen Client
• Bounded staleness: Konsistent für Clients der gleichen Region. Eine Lese Operationen hat eine maximale Verzögerung (Anzahl Versionen oder Zeit).
• Strong: Garantie, das Leseoperationen stets die letzten Daten liefern. Ein Benutzer sieht immer die zuletzt geschriebenen Daten. Höhere Latenzen

Konsistenzlevel greifen entweder auf Account Level (Default Wert) oder sind Request-spezifisch. Strong und Bounded Staleness erfordern die doppelte Menge an Request Units (RU) für einen Request.

Request Units

Die Kosten für eine Cosmos DB sind bestimmt durch den gewünschten Datendurchsatz, gemessen in Request Units (RU). Die Kosten einer Leseoperation von einem kByte Daten entspricht 1 RU. Der Durchsatz lässt sich auf Datenbank oder Container-Level einstellen. Ein Minimum von 10 RU pro GByte Speicher ist erforderlich, das Minimum beträgt 400 RU’s/s. Wenn die eingestellte Anzahl RU aufgebraucht ist, schlagen nachfolgende Operationen fehl. Deshalb macht es Sinn, dafür Autoscaling mit einem Maximalwert einzustellen. Der minimale Durchsatz beträgt 10% des Maximums.

Eine neue Option ist Cosmos DB Serverless: Dabei zahlt man nur für die verbrauchten RU’s und den Speicher. Das ist ideal für On/Off Workloads und Entwicklungsdatenbanken. Im Moment ist diese Einstellung nur für das SQL API verfügbar. Wichtig ist eine Strategie für gleichmässig verteilte Partitionen.

Programmierung der Cosmos DB

Cosmos DB unterstützt auch Stored Procedures, Triggers und benutzerdefinierte Funktionen. Als Programmiersprache gibt es nur JavaScript. Eine Stored Procedure kann nur auf Daten innerhalb desselben Partition Key zugreifen. Dieser muss der Prozedur bekannt sein, bevor sie ausgeführt wird.

Triggers können vor (pre) oder nach (post) der Datenbankaktion laufen. Pre Trigger machen Datentransformationen oder Validierungen, während Post Trigger Aggregationen oder Änderungsnotifikationen erledigen.

In Teil 4 dieser Blogserie werden die verschiedenen Technologien zur Analyse von Daten betrachtet.