Datenplattformen in Azure – sicher, skalierbar und kostenbewusst

Positionierung

Die Cloud hat die Art, wie Datenplattformen gebaut werden, grundlegend verändert. Wo früher Server beschafft, dimensioniert und über Jahre betrieben werden mussten, lassen sich heute in Microsoft Azure Speicher, Rechenleistung und Dienste in Minuten bereitstellen. Diese Freiheit ist ein Segen und ein Risiko zugleich: Eine Azure-Datenplattform kann enorm leistungsfähig, sicher und kostengünstig sein – oder zu einem unübersichtlichen, teuren Flickenteppich werden. Der Unterschied liegt in der Architektur und im Betrieb, nicht in den Diensten selbst.

Genau hier liegt mein Schwerpunkt: Ich baue Datenplattformen in Azure, die einer klaren Architektur folgen, von Anfang an sicher konzipiert sind, sich automatisiert ausrollen lassen und deren Kosten beherrschbar bleiben. Ich komme dabei nicht aus der reinen Cloud-Welt, sondern aus jahrzehntelanger Arbeit mit SQL Server, Data Warehouses und ETL-Strecken. Diese Herkunft prägt meinen Blick: Eine Cloud-Plattform ist für mich kein Selbstzweck, sondern ein Mittel, um fachliche Fragen zuverlässig zu beantworten.

In Azure-Projekten habe ich mit dem gesamten Spektrum der Datendienste gearbeitet: Azure Data Factory für die Orchestrierung, Azure Synapse für Analyse und Verarbeitung, Azure Databricks mit Parquet- und Delta-Lake-Dateien für große Datenmengen, Azure Storage als Fundament des Data Lake, Entra ID für Identität und Zugriff sowie Key Vault für die sichere Verwaltung von Geheimnissen. Ergänzt wird das durch Azure DevOps für CI/CD und durch ein konsequentes Augenmerk auf Kosten.

Auftraggeber holen mich typischerweise dann, wenn eine bestehende On-Premises-Welt in die Cloud wandern soll, wenn eine vorhandene Azure-Landschaft unübersichtlich oder zu teuer geworden ist oder wenn eine neue Plattform von Grund auf entstehen soll. In all diesen Fällen geht es weniger um einzelne Dienste als um das Zusammenspiel: Wie greifen Ingestion, Speicherung, Verarbeitung, Sicherheit und Betrieb so ineinander, dass am Ende eine verlässliche, wartbare Plattform entsteht?

Was eine Azure-Datenplattform ausmacht

Eine Datenplattform in Azure besteht aus mehreren Bausteinen, die jeweils eine klare Aufgabe haben. Wer diese Bausteine und ihr Zusammenspiel versteht, kann eine Plattform entwerfen, die zur fachlichen Anforderung passt – statt wahllos Dienste zu kombinieren, weil sie gerade verfügbar sind.

Speicherung: der Data Lake als Fundament

Im Zentrum steht meist ein Data Lake auf Basis von Azure Data Lake Storage Gen2. Hier landen Rohdaten aus allen Quellen, bevor sie verarbeitet werden. Der Lake ist günstig, praktisch unbegrenzt skalierbar und entkoppelt die Speicherung von der Rechenleistung. Genau diese Entkopplung ist einer der größten Vorteile der Cloud: Speicher und Rechenleistung lassen sich unabhängig voneinander dimensionieren und bezahlen.

Orchestrierung: Azure Data Factory

Azure Data Factory ist der Dirigent. Pipelines holen Daten aus Quellen, stoßen Verarbeitungsschritte an, behandeln Fehler und steuern den zeitlichen Ablauf über Trigger. ADF verbindet die Bausteine, ohne selbst die schwere Datenverarbeitung zu übernehmen – diese delegiert es an die dafür spezialisierten Dienste.

Verarbeitung: Synapse und Databricks

Die eigentliche Verarbeitung großer Datenmengen geschieht in Azure Synapse oder in Azure Databricks. Synapse bündelt SQL-basierte Analyse, Spark und Pipelines in einer Umgebung; Databricks ist die spezialisierte Spark-Plattform für anspruchsvolle Transformationen und für den Umgang mit Delta Lake. In meinen Projekten habe ich Daten als Parquet- und Delta-Dateien verarbeitet und dabei sowohl Synapse-Pipelines als auch Databricks-Notebooks eingesetzt.

Sicherheit und Identität: Entra ID und Key Vault

Identität und Zugriff laufen in Azure über Microsoft Entra ID (früher Azure Active Directory). Geheimnisse wie Verbindungszeichenfolgen, Schlüssel und Zertifikate gehören nicht in Code oder Konfigurationsdateien, sondern in Azure Key Vault. Diese beiden Bausteine sind das Rückgrat einer sicheren Plattform.

• Data Lake (Storage Gen2) als günstiges, skalierbares Fundament
• Azure Data Factory als zentrale Orchestrierung
• Synapse und Databricks für die eigentliche Verarbeitung
• Delta Lake für ACID-Transaktionen und Historisierung im Lake
• Entra ID und Key Vault für Identität, Zugriff und Geheimnisse
• Azure DevOps für automatisiertes, nachvollziehbares Deployment

Warum die Trennung in klare Bausteine zählt

Der entscheidende Unterschied zwischen einer guten und einer beliebigen Azure-Plattform liegt nicht in der Auswahl der Dienste, sondern in der Klarheit ihrer Aufgabenteilung. Jeder Baustein sollte genau eine Verantwortung tragen: Der Lake speichert, Data Factory orchestriert, die Verarbeitungsdienste rechnen, Entra ID und Key Vault sichern ab. Vermischen sich diese Rollen – etwa wenn fachliche Logik in Orchestrierungspipelines wandert oder Geheimnisse in Konfigurationen liegen – entsteht eine Plattform, die schwer zu verstehen, zu testen und zu betreiben ist. Saubere Trennung ist kein Selbstzweck, sondern die Grundlage für Wartbarkeit über Jahre.

Diese Bausteine bilden zudem kein starres Korsett. Welche Dienste tatsächlich zum Einsatz kommen, hängt vom konkreten Bedarf ab. Ein kleineres Vorhaben braucht möglicherweise weder Databricks noch dedizierte SQL-Pools, sondern kommt mit Data Factory, Lake und serverlosem SQL aus. Ein großes, datenintensives Vorhaben hingegen rechtfertigt die volle Bandbreite. Die Kunst besteht darin, nur so viel Plattform zu bauen, wie die Anforderung verlangt – und sie so zu gestalten, dass sie mitwachsen kann, wenn der Bedarf steigt.

Referenzarchitektur in Azure

Über mehrere Projekte hinweg hat sich eine Referenzarchitektur bewährt, die Daten in klar getrennten Stufen verarbeitet: von der Quelle über die Ingestion in den Lake, von dort durch die Verarbeitungsschichten bis zur Auslieferung an Berichte und Self-Service-BI. Jede Stufe hat eine definierte Aufgabe, und über allem liegen Sicherheit und Betrieb als Querschnitt.

Referenzarchitektur einer Azure-Datenplattform: Quellen, Ingestion über Data Factory, Data Lake, Verarbeitung in Synapse und Databricks, Auslieferung an DWH und Power BI – flankiert von Sicherheit und Betrieb.

Die Quellen reichen von On-Premises-Datenbanken über SaaS-Anwendungen bis zu APIs und Dateilieferungen. Azure Data Factory liest diese Quellen und legt die Rohdaten zunächst unverändert im Data Lake ab. Erst dort beginnt die eigentliche Verarbeitung, die die Daten schrittweise verfeinert, bis sie für Auswertungen geeignet sind. Das Ergebnis wird entweder in ein relationales Data Warehouse geschrieben oder direkt als kuratierte Delta-Tabellen bereitgestellt und von Power BI konsumiert.

Der entscheidende Gedanke dieser Architektur ist die Trennung von Verantwortlichkeiten. Die Ingestion kümmert sich ausschließlich darum, Daten verlässlich in den Lake zu bringen. Die Verarbeitung kümmert sich um fachliche Regeln und Qualität. Die Auslieferung kümmert sich um die optimale Form für die jeweilige Auswertung. Diese Trennung macht die Plattform verständlich, testbar und erweiterbar: Eine neue Quelle berührt nur die Ingestion, eine neue Auswertung nur die Auslieferung.

Ingestion mit Azure Data Factory

Die Ingestion ist der erste und in vielerlei Hinsicht heikelste Schritt: Hier werden Quellen angebunden, die sich nicht ändern lassen, die zu bestimmten Zeiten verfügbar sind und die nicht durch riesige Abfragen ausgebremst werden dürfen. Azure Data Factory ist das Werkzeug der Wahl, um diese Anbindung robust und nachvollziehbar zu gestalten.

Ein wiederkehrendes Muster ist die parametrisierte, metadatengetriebene Pipeline. Statt für jede Tabelle eine eigene Pipeline zu bauen, hinterlege ich die zu ladenden Objekte in einer Steuerungstabelle und durchlaufe sie mit einer einzigen, generischen Pipeline. Das reduziert den Pflegeaufwand erheblich und macht das Hinzufügen neuer Quellen zu einem reinen Konfigurationsschritt.

{
  "name": "PL_Ingest_Generic",
  "properties": {
    "activities": [
      {
        "name": "LookupTablesToLoad",
        "type": "Lookup",
        "typeProperties": {
          // Liest die Liste der zu ladenden Tabellen aus der Steuerungstabelle
          "source": { "type": "AzureSqlSource",
            "sqlReaderQuery": "SELECT SchemaName, TableName, WatermarkColumn FROM ctrl.LoadTable WHERE IsActive = 1" },
          "firstRowOnly": false
        }
      },
      {
        "name": "ForEachTable",
        "type": "ForEach",
        "dependsOn": [ { "activity": "LookupTablesToLoad", "dependencyConditions": [ "Succeeded" ] } ],
        "typeProperties": {
          "items": { "value": "@activity('LookupTablesToLoad').output.value", "type": "Expression" },
          "isSequential": false,   // parallele Verarbeitung der Tabellen
          "batchCount": 8,
          "activities": [
            {
              "name": "CopyToLake",
              "type": "Copy",
              "typeProperties": {
                // Inkrementeller Auszug anhand der Watermark-Spalte
                "source": { "type": "AzureSqlSource",
                  "sqlReaderQuery": {
                    "value": "SELECT * FROM [@{item().SchemaName}].[@{item().TableName}] WHERE [@{item().WatermarkColumn}] > '@{pipeline().parameters.LastWatermark}'",
                    "type": "Expression" } },
                // Ziel: Bronze-Schicht im Data Lake als Parquet
                "sink": { "type": "ParquetSink" }
              }
            }
          ]
        }
      }
    ],
    "parameters": { "LastWatermark": { "type": "string" } }
  }
}

Eine einzige generische Pipeline lädt beliebig viele Tabellen inkrementell in die Bronze-Schicht. Neue Quellen werden allein über die Steuerungstabelle ergänzt – ohne Änderung an der Pipeline.

Wichtig ist mir, dass die Ingestion idempotent und wiederanlauffähig ist. Bricht ein Lauf ab, muss er sich gefahrlos wiederholen lassen, ohne doppelte Daten zu erzeugen. Die Watermark wird deshalb erst nach erfolgreichem Lauf fortgeschrieben, und die Bronze-Schicht hält fest, was tatsächlich geliefert wurde – als Audit- und Wiederanlaufpunkt.

Lakehouse, Delta Lake und Medaillon-Architektur

Das Lakehouse verbindet die Flexibilität und die niedrigen Kosten eines Data Lake mit den Garantien, die man von einem Data Warehouse kennt. Das Fundament dafür ist Delta Lake: ein offenes Speicherformat auf Basis von Parquet, das ACID-Transaktionen, Zeitreisen und eine Schemaverwaltung in den Data Lake bringt. In meinen Azure-Projekten habe ich Daten als Parquet- und Delta-Dateien aufgebaut und über Databricks verarbeitet.

Die Medaillon-Architektur verfeinert Daten schrittweise: Bronze hält Rohdaten, Silber bereinigte und konforme Daten, Gold fachlich aggregierte, für BI optimierte Daten.

Die Daten durchlaufen drei Schichten. Die Bronze-Schicht hält die Rohdaten unverändert, so wie sie geliefert wurden – das ist die auditierbare Wahrheit über das, was angekommen ist. Die Silber-Schicht enthält bereinigte, deduplizierte und vereinheitlichte Daten: Hier werden Datentypen korrigiert, Schlüssel vereinheitlicht und fachliche Plausibilitäten geprüft. Die Gold-Schicht schließlich enthält die fachlich aggregierten, für Auswertungen optimierten Daten, oft bereits als Sternschema.

# Verfeinert Rohdaten aus der Bronze-Schicht und schreibt bereinigte,
# deduplizierte Saetze idempotent in die Silber-Schicht (Delta Lake).
from pyspark.sql import functions as F
from delta.tables import DeltaTable

# 1) Nur neue Saetze aus der Bronze-Schicht lesen (inkrementell)
last_wm = (spark.sql("SELECT MAX(processed_ts) AS wm FROM ctrl.watermark WHERE entity='customer'")
                .collect()[0]["wm"])

bronze = (spark.read.format("delta").table("bronze.customer")
              .filter(F.col("ingest_ts") > F.lit(last_wm)))

# 2) Bereinigung und Vereinheitlichung
silver = (bronze
          .withColumn("email", F.lower(F.trim("email")))   # Normalisierung
          .filter(F.col("customer_id").isNotNull())         # Pflichtfeld
          .dropDuplicates(["customer_id"])                  # Deduplizierung
          .withColumn("processed_ts", F.current_timestamp()))

# 3) Idempotenter Upsert in die Silber-Schicht
target = DeltaTable.forName(spark, "silver.customer")
(target.alias("t")
   .merge(silver.alias("s"), "t.customer_id = s.customer_id")
   .whenMatchedUpdateAll()
   .whenNotMatchedInsertAll()
   .execute())

Delta Lake macht den MERGE transaktionssicher und idempotent. Ein erneuter Lauf mit denselben Daten ändert nichts – genau das Verhalten, das eine verlässliche Plattform braucht.

Verarbeitung mit Synapse und Databricks

Für die eigentliche Verarbeitung stehen in Azure mehrere Wege offen. Welcher der richtige ist, hängt von Datenmenge, Team-Know-how und bestehender Landschaft ab. Ich wähle bewusst und begründe die Wahl, statt einem Trend zu folgen.

Azure Synapse

Azure Synapse bündelt mehrere Fähigkeiten in einer Umgebung: dedizierte und serverlose SQL-Pools für relationale Analyse, Spark-Pools für die verteilte Verarbeitung und integrierte Pipelines, die technisch denen von Azure Data Factory entsprechen. Synapse ist eine gute Wahl, wenn ein Team aus der SQL-Welt kommt und relationale Analyse im Vordergrund steht. Serverlose SQL-Pools erlauben es, Dateien im Lake direkt per T-SQL abzufragen, ohne sie vorher zu laden – ein mächtiges Werkzeug für Exploration und für schlanke Auslieferungsschichten.

Azure Databricks

Azure Databricks ist die spezialisierte Spark-Plattform und mein Werkzeug der Wahl für anspruchsvolle Transformationen, für große Datenmengen und für den Umgang mit Delta Lake. Databricks-Notebooks lassen sich aus Azure Data Factory heraus orchestrieren, sodass die Verarbeitung Teil der Gesamtpipeline wird. In Projekten habe ich Daten nach Databricks extrahiert, dort als Parquet- und Delta-Dateien aufbereitet und für die weitere Nutzung bereitgestellt.

Ein wichtiger Aspekt ist die Rechenleistung. Spark-Cluster kosten Geld, solange sie laufen. Deshalb achte ich darauf, dass Cluster automatisch herunterfahren, wenn sie nicht gebraucht werden, dass Aufträge auf passend dimensionierten Clustern laufen und dass unnötige Wiederholungen vermieden werden. Diese Disziplin entscheidet maßgeblich über die monatliche Rechnung.

Ein praktisches Beispiel für das Zusammenspiel: Databricks bereitet die Daten als Delta- und Parquet-Dateien im Gold-Bereich des Lake auf, und serverloses Synapse-SQL legt darauf schlanke, abfragbare Sichten, ohne die Daten noch einmal zu kopieren. So zahlt man Rechenleistung nur dann, wenn tatsächlich eine Abfrage läuft, und vermeidet eine teure, dauerhaft laufende Datenbank nur für die Auslieferung.

-- Legt eine abfragbare Sicht direkt auf die Gold-Dateien im Lake an.
-- Es werden keine Daten kopiert; die Abfrage liest die Parquet-Dateien direkt.
CREATE OR ALTER VIEW gold.SalesByMonth AS
SELECT
    -- Aggregierter Umsatz je Monat fuer die Auslieferung an Power BI
    YEAR(order_date)  AS order_year,
    MONTH(order_date) AS order_month,
    SUM(net_amount)   AS revenue
FROM OPENROWSET(
        BULK 'https://lakedataplatform.dfs.core.windows.net/gold/sales/',
        FORMAT = 'PARQUET'   -- Direkter Lesezugriff auf die Gold-Schicht
     ) AS sales
GROUP BY YEAR(order_date), MONTH(order_date);

Diese Sicht lässt sich unmittelbar aus Power BI heraus abfragen. Der Rechenaufwand entsteht nur bei der Abfrage selbst – ohne eine dauerhaft laufende Datenbank für die Auslieferung.

Sicherheit: Entra ID, Key Vault und Netzwerk

Sicherheit ist in der Cloud keine Option, sondern Voraussetzung. Eine Datenplattform verarbeitet oft sensible Daten – Personenbezug, Finanzdaten, Betriebsgeheimnisse. Ich plane Sicherheit deshalb von Beginn an mit, nicht als nachträgliche Härtung. Drei Ebenen greifen dabei ineinander: Identität, Geheimnisse und Netzwerk.

Identität und Zugriff über Entra ID

Jeder Zugriff – ob durch Menschen oder durch Dienste – läuft über Microsoft Entra ID. Dienste wie Data Factory oder Databricks erhalten eine verwaltete Identität (Managed Identity), mit der sie sich gegenüber Storage, SQL und Key Vault ausweisen. Der große Vorteil: Es müssen keine Passwörter oder Schlüssel gespeichert werden, die kompromittiert werden könnten. Der Zugriff folgt dem Prinzip der minimalen Rechte – jede Identität erhält nur, was sie tatsächlich braucht.

Geheimnisse in Key Vault

Verbindungszeichenfolgen, API-Schlüssel und Zertifikate gehören in Azure Key Vault, nicht in Code oder Konfigurationsdateien. Pipelines und Notebooks holen Geheimnisse zur Laufzeit aus dem Vault, abgesichert über die verwaltete Identität. So liegt kein Geheimnis offen im Repository oder in einer Konfiguration.

# Liest ein Geheimnis aus Azure Key Vault ueber die verwaltete Identitaet.
# Es wird kein Passwort und kein Schluessel im Code oder in einer Datei gespeichert.
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

VAULT_URL = "https://kv-dataplatform-prod.vault.azure.net/"

# Die verwaltete Identitaet weist sich automatisch gegenueber Entra ID aus
credential = DefaultAzureCredential()
client = SecretClient(vault_url=VAULT_URL, credential=credential)

# Verbindungszeichenfolge erst zur Laufzeit aus dem Vault holen
sql_conn = client.get_secret("sql-dwh-connection").value

# ... das Geheimnis wird nur im Speicher gehalten, nie persistiert ...

Über die verwaltete Identität entfällt jedes gespeicherte Passwort. Das ist nicht nur sicherer, sondern vereinfacht auch den Betrieb, weil keine Schlüssel manuell rotiert werden müssen.

Netzwerk und Datenabschottung

Auf Netzwerkebene sorgen private Endpunkte dafür, dass der Datenverkehr zwischen den Diensten das öffentliche Internet nicht berührt. Storage, SQL und Key Vault lassen sich so absichern, dass sie nur aus dem definierten virtuellen Netzwerk erreichbar sind. In regulierten Umfeldern – etwa im Finanz- oder öffentlichen Sektor – ist diese Abschottung oft zwingend.

CI/CD und Infrastruktur als Code

Eine Cloud-Plattform ist Software – und Software gehört unter Versionskontrolle und in eine automatisierte Auslieferung. Ich habe in mehreren Projekten Azure-DevOps-Pipelines aufgebaut, die sowohl Code als auch Infrastruktur automatisch und nachvollziehbar ausrollen. Das Ergebnis: Jede Änderung ist dokumentiert, wiederholbar und in jeder Umgebung gleich.

Bei einem Industrieunternehmen habe ich SSIS-Strecken migriert und Azure-DevOps-Pipelines für den automatischen Build aufgebaut. Bei einem Beratungs- und MDM-Projekt habe ich Azure Data Factory und Key Vault über automatisierte Abläufe bereitgestellt. Das Prinzip ist immer dasselbe: Manuelle Klicks in Portalen sind die Quelle von Fehlern und von Unterschieden zwischen Umgebungen. Wer Infrastruktur als Code beschreibt, beseitigt diese Fehlerquelle.

# Rollt Data-Factory-Artefakte und die zugrunde liegende Infrastruktur
# automatisiert in die Zielumgebung aus.
trigger:
  branches: { include: [ main ] }

variables:
  - group: dataplatform-prod   # Variablen/Geheimnisse kommen aus Key Vault

stages:
- stage: Deploy_Infra
  jobs:
  - job: Bicep
    pool: { vmImage: 'ubuntu-latest' }
    steps:
    - task: AzureCLI@2
      displayName: 'Infrastruktur als Code (Bicep) ausrollen'
      inputs:
        azureSubscription: 'sc-dataplatform'
        scriptType: bash
        scriptLocation: inlineScript
        inlineScript: |
          az deployment group create \
            --resource-group rg-dataplatform-prod \
            --template-file infra/main.bicep \
            --parameters env=prod

- stage: Deploy_ADF
  dependsOn: Deploy_Infra
  jobs:
  - job: ADF
    pool: { vmImage: 'ubuntu-latest' }
    steps:
    - task: AzurePowerShell@5
      displayName: 'Data-Factory-Pipelines veroeffentlichen'
      inputs:
        azureSubscription: 'sc-dataplatform'
        ScriptType: 'InlineScript'
        Inline: |
          # Veroeffentlicht die ARM-Vorlagen der Data Factory in die Zielumgebung
          ./deploy/Publish-AdfFromArm.ps1 -Environment 'prod'

Infrastruktur und Artefakte werden in derselben Pipeline ausgerollt. So ist garantiert, dass die Data Factory immer zu der Infrastruktur passt, in der sie läuft.

Versionsverwaltung nutze ich projektabhängig mit Git in den Ausprägungen Azure DevOps, GitHub, GitLab und Bitbucket. Branch-Strategien, Pull Requests und automatische Tests sorgen dafür, dass Änderungen geprüft werden, bevor sie in produktionsnahe Umgebungen gelangen.

Der praktische Gewinn dieser Disziplin zeigt sich spätestens dann, wenn eine Änderung rückgängig gemacht werden muss. Wo Infrastruktur als Code beschrieben und jede Auslieferung versioniert ist, lässt sich ein früherer, funktionierender Stand jederzeit wiederherstellen – ohne Detektivarbeit daran, wer wann was im Portal verstellt hat. Diese Reproduzierbarkeit ist in regulierten Umfeldern nicht nur bequem, sondern oft zwingende Voraussetzung, weil jede Änderung nachvollziehbar und revisionssicher dokumentiert sein muss.

Kostensteuerung und FinOps

Die Cloud rechnet nach Verbrauch ab. Das ist fair, aber unbarmherzig: Eine vergessene Rechenressource, ein unnötiger Full Load oder ein überdimensionierter Cluster schlagen sich unmittelbar in der Rechnung nieder. In meinen Azure-Projekten habe ich gezielt Maßnahmen zur Kostenreduktion umgesetzt – nicht als einmalige Aktion, sondern als laufende Disziplin.

• Inkrementelle Beladung statt wiederholter Full Loads – weniger verarbeitete Daten, weniger Kosten
• Automatisches Pausieren und Herunterfahren von Rechenressourcen außerhalb der Ladefenster
• Passende Dimensionierung von Clustern und SQL-Pools statt pauschaler Überdimensionierung
• Lebenszyklusregeln im Storage: kalte Daten in günstigere Speicherklassen verschieben
• Serverlose Dienste dort, wo Last unregelmäßig anfällt
• Kostentransparenz über Tags, Budgets und Auswertungen pro Bereich

Ein konkretes Beispiel: Bei einem Textil- und Servicedienstleister habe ich Ladeprozesse über Azure Synapse und Data Factory aufgebaut und gezielt Maßnahmen zur Reduzierung der Azure-Kosten umgesetzt. Der Hebel lag selten in einem einzelnen großen Posten, sondern in der Summe vieler kleiner Entscheidungen: Was muss wirklich jede Stunde laufen? Welche Daten müssen wirklich vollständig neu geladen werden? Welche Cluster sind nachts wirklich nötig?

Kostentransparenz schafft Vertrauen

Der wirksamste Hebel gegen ausufernde Kosten ist nicht Sparsamkeit, sondern Sichtbarkeit. Solange niemand weiß, welcher Bereich, welche Pipeline oder welche Auswertung welche Kosten verursacht, bleibt jede Sparmaßnahme Stochern im Nebel. Deshalb versehe ich Ressourcen konsequent mit Tags – nach Bereich, Umgebung und Zweck –, sodass sich die monatliche Rechnung verursachungsgerecht aufschlüsseln lässt. Erst diese Transparenz ermöglicht eine sachliche Diskussion darüber, ob ein Posten gerechtfertigt ist oder nicht.

Budgets und automatische Warnungen ergänzen dieses Bild. Wenn eine Umgebung ihr Monatsbudget zu einem ungewöhnlich frühen Zeitpunkt erreicht, ist das ein Signal, dem nachzugehen ist – oft steckt ein vergessener Cluster, ein versehentlich angestoßener Full Load oder eine fehlkonfigurierte Wiederholung dahinter. So wird aus der monatlichen Überraschung eine steuerbare Größe. Kosten werden damit nicht zum Tabuthema, sondern zu einer gemeinsam verantworteten Kennzahl, die genauso selbstverständlich beobachtet wird wie Laufzeiten oder Fehlerquoten.

Betrieb, Monitoring und Governance

Eine Plattform, die gebaut, aber nicht betrieben wird, verfällt. Deshalb plane ich Betrieb, Monitoring und Governance von Anfang an mit. Es geht darum, dass die Plattform auch nach Jahren noch verständlich, überwachbar und kontrollierbar bleibt.

Monitoring und Alerting

Jeder Lauf wird protokolliert, jeder Fehler erzeugt eine nachvollziehbare Meldung. Azure Monitor und Log Analytics sammeln die Telemetrie der Dienste, sodass sich auf einen Blick erkennen lässt, welche Pipelines erfolgreich waren, wie lange sie gedauert haben und wo es hakt. Im Fehlerfall greift ein Alerting, das die richtigen Personen rechtzeitig erreicht.

Governance und Datenkatalog

Mit wachsender Plattform wird Übersicht wichtig: Welche Datasets gibt es? Woher stammen sie? Wer darf sie nutzen? Microsoft Purview und ein konsequenter Umgang mit Namenskonventionen, Tags und Dokumentation sorgen dafür, dass die Plattform nicht zum undurchschaubaren Datenfriedhof wird. In Verbindung mit Master Data Management – etwa über MDS oder Profisee, mit denen ich in mehreren Projekten gearbeitet habe – entsteht ein verlässliches Fundament an Stammdaten.

Governance ist dabei kein Bürokratie-Selbstzweck. Sie ist die Voraussetzung dafür, dass Daten vertraut und genutzt werden. Eine Zahl, deren Herkunft niemand kennt, wird zu Recht angezweifelt. Eine Zahl, die bis zur Quelle zurückverfolgbar ist und deren Berechnung dokumentiert ist, schafft Vertrauen.

Betriebsfähigkeit als Lieferziel

Betrieb beginnt nicht nach der Auslieferung, sondern wird mitgebaut. Ich lege Wert darauf, dass eine Plattform selbsterklärend genug ist, um von einem Team übernommen zu werden, das nicht an ihrem Aufbau beteiligt war. Dazu gehören einheitliche Namenskonventionen über alle Dienste hinweg, ein nachvollziehbares Schema für Ressourcengruppen und Umgebungen sowie eine klare Trennung zwischen Entwicklung, Test und Produktion. Wer eine Ressource sieht, soll an ihrem Namen erkennen, wozu sie gehört, in welcher Umgebung sie liegt und wer sie verantwortet.

Ein wiederkehrendes Thema ist die Wiederanlauffähigkeit nach Störungen. Cloud-Dienste sind zuverlässig, aber nicht unfehlbar: Eine Quelle ist kurzzeitig nicht erreichbar, ein Dienst antwortet langsamer als sonst, ein Lauf wird abgebrochen. Eine gut gebaute Plattform fängt das ab, statt daran zu zerbrechen. Pipelines sind so gestaltet, dass sie sich gefahrlos erneut starten lassen, ohne Daten doppelt zu schreiben. Idempotenz ist hier das Stichwort: Derselbe Lauf darf zweimal ausgeführt werden und muss zum selben Ergebnis führen.

Schließlich gehört zur Betriebsfähigkeit auch ein realistisches Bild davon, was im Ernstfall zu tun ist. Ich halte fest, welche Strecken geschäftskritisch sind, in welcher Reihenfolge sie nach einem Ausfall wieder anlaufen müssen und welche Daten sich notfalls neu erzeugen lassen. Diese Nüchternheit erspart im Ernstfall hektische Improvisation.

Migration von On-Premises nach Azure

Viele Projekte beginnen nicht auf der grünen Wiese, sondern mit einer gewachsenen On-Premises-Landschaft, die in die Cloud wandern soll. Diese Migration ist anspruchsvoll, weil der laufende Betrieb nicht stehenbleiben darf und weil Jahre an fachlicher Logik nicht verlorengehen dürfen. Meine jahrzehntelange Erfahrung mit SQL Server, SSIS und Data Warehouses ist hier ein echter Vorteil: Ich verstehe sowohl die Welt, aus der migriert wird, als auch die Welt, in die migriert wird.

Ich habe SSIS-Pakete von älteren auf neuere SQL-Server-Versionen migriert und bestehende Strecken Schritt für Schritt in die Cloud überführt. Bewährt hat sich ein schrittweises Vorgehen statt eines riskanten Big-Bang-Umzugs: Zunächst werden Quellen parallel auch in den Lake geladen, dann wird die Verarbeitung schrittweise in die Cloud verlagert, schließlich werden Auswertungen umgestellt. So bleibt der alte Stand jederzeit als Rückfalloption erhalten.

• Bestandsaufnahme der Quellen, Strecken, Berichte und fachlichen Regeln
• Zielarchitektur in Azure entwerfen und mit den Beteiligten abstimmen
• Schrittweise Migration mit Parallelbetrieb statt riskantem Big Bang
• Abgleich von Ergebnissen alt gegen neu als fachliche Absicherung
• Umstellung der Auswertungen erst nach nachgewiesener Gleichheit
• Abschaltung der Altlandschaft als letzter, kontrollierter Schritt

Was bei einer Migration wirklich Arbeit macht

Die technische Überführung von Strecken ist selten der schwierigste Teil einer Migration. Die eigentliche Arbeit steckt in der über Jahre gewachsenen fachlichen Logik, die oft nirgends vollständig dokumentiert ist. In gewachsenen SSIS-Paketen und Stored Procedures verbergen sich Sonderfälle, Ausnahmen und stillschweigende Annahmen, die im laufenden Betrieb funktionieren, aber niemandem mehr präsent sind. Diese Logik freizulegen, zu verstehen und sauber in die neue Welt zu überführen, ist der eigentliche Wert einer durchdachten Migration.

Hier zahlt sich mein langer Hintergrund mit SQL Server, SSIS und Data Warehouses unmittelbar aus. Ich kann gewachsenen Code lesen, seine Absicht rekonstruieren und beurteilen, welche Eigenheiten fachlich begründet und welche historisch gewachsene Altlasten sind. Eine Migration ist immer auch eine Gelegenheit, aufzuräumen – aber nur dort, wo das Aufräumen das Ergebnis nicht verfälscht. Der Ergebnisabgleich alt gegen neu ist dabei die Sicherung, die verhindert, dass beim Umzug stillschweigend Zahlen kippen.

Der Parallelbetrieb kostet zwar zeitweise doppelten Aufwand, ist diese Investition aber fast immer wert. Solange alte und neue Welt nebeneinander laufen, lässt sich jede Abweichung untersuchen, bevor sie produktiv wird. Erst wenn die neue Plattform über mehrere Ladezyklen hinweg nachweislich dieselben Ergebnisse liefert, wird umgeschaltet – und die Altlandschaft kontrolliert abgeschaltet, nicht hastig abgerissen.

Vorgehen in der Zusammenarbeit

Eine gute Azure-Plattform beginnt mit Verständnis, nicht mit Diensten. Bevor ich etwas baue, verschaffe ich mir ein klares Bild der Quellen, der fachlichen Anforderungen, der Sicherheitsvorgaben und des Budgets. Erst daraus ergibt sich die richtige Architektur.

• Analyse: Quellen, Anforderungen, Sicherheitsvorgaben und Budget verstehen
• Architektur: Dienste, Schichten, Sicherheit und Kostenrahmen festlegen
• Umsetzung: Plattform iterativ aufbauen, von Anfang an automatisiert ausgerollt
• Sicherheit und Tests: Identität, Geheimnisse, Netzwerk und Datenqualität absichern
• Betrieb: Monitoring, Governance, Kostensteuerung und Dokumentation

Ich arbeite remote, hybrid und vor Ort, allein oder als Teil eines bestehenden Teams. Über die Jahre habe ich in sehr unterschiedlichen Branchen gearbeitet – öffentlicher Sektor, Finanzdienstleistung, Industrie, Handel und Dienstleistung. Diese Vielfalt hilft, weil sich bewährte Muster übertragen lassen, ohne die Eigenheiten jedes Unternehmens zu ignorieren.

Typische Leistungen rund um Azure

Je nach Projektphase und Bedarf übernehme ich unterschiedliche Aufgaben rund um die Azure-Datenplattform – von der Architektur über die Umsetzung bis zum Betrieb.

• Architektur und Aufbau von Datenplattformen in Azure
• Ingestion mit Azure Data Factory, metadatengetrieben und wiederanlauffähig
• Lakehouse und Medaillon-Architektur mit Delta Lake
• Verarbeitung mit Azure Synapse und Azure Databricks (Parquet, Delta, PySpark)
• Sicherheit über Entra ID, verwaltete Identitäten, Key Vault und private Endpunkte
• CI/CD und Infrastruktur als Code mit Azure DevOps
• Kostenanalyse und gezielte Kostenreduktion (FinOps)
• Migration bestehender On-Premises-Strecken nach Azure
• Monitoring, Governance und technische Dokumentation
• Anbindung von Power BI und Auslieferung an Self-Service-BI

Ob es um einen ersten Entwurf, eine konkrete Umsetzung oder die Stabilisierung einer bereits laufenden Plattform geht – ich steige dort ein, wo der Bedarf am größten ist. In manchen Projekten beginne ich mit einer Architektur auf dem Reissbrett, in anderen übernehme ich eine halbfertige Plattform und führe sie zu einem belastbaren Stand. Diese Flexibilität ist gerade für Vorhaben wertvoll, die nicht bei null anfangen, sondern auf Bestehendem aufsetzen.

Was alle diese Aufgaben verbindet, ist ein durchgängiges Verständnis der gesamten Strecke – von der Quelle bis zum fertigen Bericht. Genau dieses Ende-zu-Ende-Verständnis unterscheidet eine Plattform, die auf dem Papier funktioniert, von einer, die im Alltag trägt. Wer nur einen Ausschnitt kennt, optimiert leicht an der falschen Stelle; wer die ganze Kette überblickt, erkennt, wo der eigentliche Engpass liegt und wo sich Aufwand wirklich lohnt.

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zur Azure-Datenplattform