Im Dezember 2020 veröffentlichte Microsoft im Zusammenhang mit ihrer modernen Data Warehouse Technologie Azure Synapse Analytics (Synapse) zwei getrennte Ressourcenmodelle zur Nutzung der integrierten SQL Engine – ein dediziertes und ein serverloses Ressourcenmodell, den SQL-Pool und den serverlosen SQL-Pool.

Der dedizierte SQL-Pool reserviert eine ausgewählte Menge an Rechenressourcen in Form von sogenannten Data Warehouse Units (DWUs) zur Abfragebearbeitung und stellt die eigentliche Data-Warehouse-Komponente in Synapse dar. DWUs sind ein „abstraktes, normalisiertes Maß für Rechenressourcen und Leistung“, die „CPU, Arbeitsspeicher und E/A bündeln.” [1] Pools auf der anderen Seite sind eine „einfache, kostengünstige Lösung für die Verwaltung und Skalierung mehrerer Datenbanken, die unterschiedliche und unvorhersehbare Nutzungsanforderungen haben.” [1] Der dedizierte SQL-Pool kann nach seiner anfänglichen Erstellung pausiert und wieder fortgesetzt werden, ohne dass die persistent gespeicherten Daten davon betroffen sind. Diese Funktionalität ist wichtig, da die von Microsoft bereitgestellten Rechenressourcen auf Stundenbasis abgerechnet werden und die Kosten von der Menge der bereitgestellten DWUs und der Zeit abhängen, in der der dedizierte SQL-Pool in Betrieb ist. [2]

Der serverlose SQL-Pool stellt das serverlose Ressourcenmodell dar, das pro Terabyte verarbeiteter Daten berechnet wird. Anders als beim dedizierten SQL-Pool fallen also keine Kosten für die Bereitstellung der Rechenressourcen an. Somit ist der serverlose SQL-Pool ein wahres „Pay-per-Use“-Modell. [3]

In der folgenden Tabelle sind die Hauptmerkmale beider Modelle gegenübergestellt:

Dedizierter SQL-PoolServerloser SQL-PoolOption zum Pausieren und Fortsetzen der RechenressourcenRechenressourcen stehen jederzeit verfügbarRessourcen werden in Form so genannter DWUs reserviertRechenressourcen können nicht reserviert werdenSehr gut für berechenbare Arbeitsbelastungen und Performance geeignetSehr gut für unvorhersehbare Arbeitsbelastungen geeignetSpeichert Daten in relationalen Tabellen mit spaltenweiser Speicherung, um Data Warehousing-Funktionen in Azure Synapse Analytics bereitzustellen. Sobald die Daten gespeichert sind, können mithilfe einer Massive Parallel Processing (MPP) Engine groß angelegte Analysen durchgeführt werdenBietet eine relationale Abstraktion auf den Rohdaten, die es einfach macht, die Daten im Data Lake zu erkunden, ohne sie vorher in BI-Tools oder relationale Datenspeicher laden zu müssenSpeichert Daten persistent im Data Warehouse sowie Metadatenobjekte externer TabellenSpeichert nur Metadatenobjekte externer Tabellen, da es keinen lokalen SpeicherAbrechnung auf Stundenbasis pro bereitgestellten DWUsAbrechnung pro Terabyte verarbeiteter Daten

Tabelle 1: Vergleich des dedizierten und des serverlosen Ressourcenmodells

Eine Übersicht über den vollständigen Feature-Vergleich der serverlosen und dedizierten SQL-Pools findet ihr hier [4].

Anwendungsfälle des serverlosen SQL-Pools

Die Anwendungsfälle eines dedizierten SQL-Pools sind relativ klar: SQL-Abfragen in gewünschter Leistung und Performance durchführen und Data Warehousing betreiben. Dagegen erscheinen die Anwendungsfälle des serverlosen SQL-Pools zunächst eingeschränkt und vor allem für grundlegende explorative Datenanalysen, Datenabfragen und Datenaufbereitungen geeignet.

Dieser Umstand ist darin begründet, dass der serverlose SQL-Pool vor allem externe Tabellen, Schemas und Views erzeugen sowie Daten über SELECT-Statements abfragen kann. Die Daten können dabei in den verschiedensten Dateiformaten wie beispielsweise CSV, PARQUET oder auch JSON vorliegen und außerhalb von Synapse in einem Data Lake gespeichert sein. Beim Lesen wird das Konzept „Schema-on-read“ angewandt, das zur Laufzeit das Dateiformat bestimmt und die Daten ausliest.

Neben der Datenexploration nennt Microsoft noch einen weiteren Anwendungsfall für den serverlosen SQL-Pool: ein logisches Data Warehouse, das eine relationale Abstraktionsschicht auf den verschiedenen, unstrukturierten Daten aus dem Data Lake bietet, ohne diese transformieren oder verschieben zu müssen. [3]

Eigenschaften des serverlosen SQL-Pools

Direkte Abfrageausführung

Eine nennenswerte Eigenschaft, die im Zusammenhang mit dem serverlosen SQL-Pool genannt werden sollte, ist die direkte Abfrageausführung, ohne zunächst auf die Bereitstellung eines Clusters warten zu müssen. Dieser Umstand ist besonders, da beim serverlosen SQL-Pool – anders als beim dedizierten SQL-Pool – nicht für die Bereitstellung der Rechenressourcen gezahlt wird.

Kostenkontrolle

Der serverlose SQL-Pool wird pro Abfrage und der darin verarbeiteten Datenmenge abgerechnet. Genau genommen, fallen pro 1 Terabyte (TB) verarbeiteter Daten etwa 4,22 Euro an. Die Abfragedauer und die Anzahl der genutzten Rechenressourcen werden bei der Kostenberechnung nicht betrachtet, da der Endanwender auf diese auch gar keinen Einfluss hat. Microsoft managet die Cluster-Bereitstellung und Abfrageausführung vollautomatisch im Hintergrund. Damit Kosten nicht unvorhergesehen in die Höhe steigen, gibt es die Möglichkeit einer Kostenkontrolle innerhalb des serverlosen SQL-Pools, die Abfragen ab einer gewissen Kosten- bzw. Datengrenze nicht mehr ausführen lässt. Laut Microsoft fallen für „reine Metadatenabfragen (DDL-Anweisungen) […] keine Kosten an.” [5]

Logisches Data Warehouse mit dem serverlosen SQL-Pool

An dieser Stelle soll nochmals der Blick auf den Anwendungsfall des logischen Data Warehouse auf Basis eines Data Lakes – oder auch Data Lakehouse – gelegt werden. [6] Dieses dient aufgrund seiner positiven Eigenschaften, wie

• einer sehr günstigen Speicherung von Daten in der Cloud,
• der Unterstützung vielfältiger Dateiformate für strukturierte, semistrukturierte und unstrukturierte Daten sowie
• seiner Flexibilität hinsichtlich der Erweiterung von Speicherkapazität,

schon lange nicht mehr nur als reiner Datenspeicher für jegliche Art von Rohdaten innerhalb eines Unternehmens. Um einen Data Lake zur Datengrundlage eines logischen DWH machen zu können, muss dieses durch saubere ETL-Prozesse integriert sowie die Datenqualität sichergestellt werden.[7] [8]

Views als Data Warehouse Layer

Zur Datenabstraktion können beispielsweise Views genutzt werden, die bestimmte Sichten auf die Daten im Data Lake ermöglichen. Diese Sichten müssen nicht der physischen Struktur der Daten entsprechen.
Der serverlose SQL-Pool ist für den Anwendungsfall eines data-lake-basierten Data Warehouses gut geeignet, da er problemlos relationale Abfragen auf externen Datenquellen ausführen sowie Views und externe Tabellen erstellen kann. Der Vorteil hierbei ist, dass nur Kosten für verarbeitete Daten anfallen und somit – gegenüber dem dedizierten SQL-Pool – eine sehr günstige, verschlankte Data-Warehouse-Lösung möglich ist.

Nachteile der logischen Data-Warehouse-Sichten

Inwieweit das logische Data Warehouse den dedizierten SQL-Pool als Data Warehouse ersetzen kann, kommt wohl auf den Anwendungsfall an. Denn der serverlose SQL-Pool hat den Nachteil, dass er keine persistente Speicherung von Daten ermöglicht und von der Datenspeicherung in der externen Datenquelle – in unserem Fall dem Data Lake – abhängig ist. Wenn Daten im Data Lake geändert, verschoben oder gelöscht werden, kann dies zu Fehlern in der logischen Data-Warehouse-Sicht führen. Somit ist ein Data Warehouse basierend auf dem serverlosen SQL-Pool fehleranfälliger bei Änderungen im Data Lake als ein persistentes Data Warehouse basierend auf einem dedizierten SQL-Pool. Zudem ist fraglich, wie gut der serverlose SQL-Pool skaliert, wenn große Data-Warehouse-Lösungen gebaut und später auch intensiv genutzt werden sollen.

Zusammenfassend kann festgehalten werden, dass der serverlose SQL-Pool interessante Anwendungsfälle bietet, die über bloße Datenexploration hinausgehen und neben dem dedizierten SQL-Pool nicht unbeachtet bleiben sollten. Und gerade mit einem Blick auf die Kosten kann der serverlose SQL-Pool mit seinem „Pay-per-Use“-Modell durchaus punkten. Hinzu kommt die Möglichkeit einer Kostenkontrolle, die verhindert, dass ungeachtet hohe Abrechnungsbeträge entstehen. Alles in allem ist der serverlose SQL-Pool mehr als ein alternatives Ressourcenmodell, das anstatt stündlich pro TB verarbeiteter Daten abgerechnet wird.

Verweise

[1] Microsoft Corp, ‘Elastic pools help you manage and scale multiple databases in Azure SQL Database’, 2020. https://docs.microsoft.com/de-de/azure/azure-sql/database/elastic-pool-overview (accessed Jan. 05, 2021).
[2] Microsoft Azure, ‘Schnellstart: Erstellen eines serverlosen Apache Spark-Pools mithilfe von Synapse Studio – Azure Synapse Analytics’, 2021. https://docs.microsoft.com/de-de/azure/synapse-analytics/quickstart-create-apache-spark-pool-studio (accessed Mar. 12, 2021).
[3] Microsoft Corp, ‘Serverloser SQL-Pool – Azure Synapse Analytics’, 2020. https://docs.microsoft.com/de-de/azure/synapse-analytics/sql/on-demand-workspace-overview (accessed Dec. 10, 2020).
[4] Microsoft Corp, ‘In Azure Synapse SQL unterstützte Transact-SQL-Funktionen’, 2020. https://docs.microsoft.com/de-de/azure/synapse-analytics/sql/overview-features (accessed Dec. 03, 2020).
[5] Microsoft Azure, ‘Pricing – Azure Synapse Analytics’, 2021. https://azure.microsoft.com/en-ca/pricing/details/synapse-analytics/ (accessed Mar. 02, 2021).
[6] ‘Können Lakehouses einen Paradigmenwechsel anstossen?’, Informatik an der Hochschule Luzern, Jun. 24, 2020. https://hub.hslu.ch/informatik/koennen-lakehouses-einen-paradigmenwechsel-anstossen/ (accessed Mar. 30, 2021).
[7] P. Vakil and F. Patano, ‘Why Cloud Centric Data Lake is the future of EDW’, Databricks, Nov. 03, 2020. https://databricks.com/de/blog/2020/11/03/why-cloud-centric-data-lake-is-the-future-of-edw.html (accessed Mar. 29, 2021).
[8] D. T. Anderson and K. Graziano, ‘Aufbau eines verwalteten Data Lake in der Cloud – Talend’, Talend Real-Time Open Source Data Integration Software. https://www.talend.com/de/resources/building-governed-data-lake-cloud/ (accessed Mar. 29, 2021).