Item Recovery in Microsoft Fabric (Preview) – Alles, was du wissen musst

Microsoft Fabric Item Recovery: Einleitung

Hast du schon einmal versehentlich eine wichtige Datei in Microsoft Fabric gelöscht und dich gefragt, ob es eine Möglichkeit gibt, diese wiederherzustellen? So ein Fehler kann deine Projekte massiv zurückwerfen.  Und genau hier kommt die neue Item Recovery-Funktion in Microsoft Fabric  ins Spiel.

In diesem Artikel erfährst du Schritt für Schritt, wie Item Recovery in Microsoft Fabric funktioniert, welche Vorteile es bietet, welche Grenzen es gibt und wie du es optimal in deine Workflows integrierst. Dabei gehen wir auch auf verwandte Themen wie Data Governance, Sicherheit und Best Practices ein, sodass du nicht nur weißt, wie du gelöschte Items wiederherstellst, sondern auch, wie du Datenverlust von vornherein vermeidest.

Microsoft Fabric Item Recovery: Was ist Microsoft Fabric?

Microsoft Fabric ist eine integrierte Plattform für Datenanalyse, Data Engineering, Data Governance und Business Intelligence. Sie vereint Dienste wie Power BI, Data Factory, Synapse und OneLake in einer zentralen Umgebung. Dadurch kannst du Daten aus verschiedensten Quellen zusammenführen, verarbeiten und analysieren. Der größte Vorteil ist: du musst nicht zwischen Tools hin und herspringen. Alles passiert in einer integrierten Datenplattform.

Allerdings geht mit dieser Flexibilität auch eine Herausforderung einher: Je mehr Projekte und Assets du in Fabric verwaltest, desto größer wird das Risiko von Fehlern, beispielsweise versehentlichem Löschen von Dateien…

Item Recovery – Die neue Sicherheitsstufe in Fabric

Microsoft Fabric Item Recovery: Funktionsweise

Item Recovery ist eine Art „Papierkorb“-Funktion in Microsoft Fabric. Wenn du ein Asset löschst (sei es ein Dataflow, Dataset, Report oder ein Notebook), landet es nicht sofort im digitalen Nirvana. Stattdessen wird es in einen temporären Speicherbereich verschoben, aus dem du es innerhalb einer bestimmten Zeitspanne wiederherstellen kannst.

Daher musst du nicht sofort in Panik geraten, wenn du etwas löschst. Du kannst das Item einfach auswählen und zurück in seinen ursprünglichen Zustand bringen.

Anfänglich war diese Funktion nur eingeschränkt verfügbar, aber mittlerweile hat Microsoft sie in der Preview-Version für viele Fabric-Workspaces freigeschaltet. Das ist besonders hilfreich für Teams, die gemeinsam an Projekten arbeiten, da so versehentliche Löschungen schnell korrigiert werden können.

Microsoft Fabric Item Recovery: Beispiel: Gelöschte Reports zurückholen

Stell dir vor, du arbeitest an einem wichtigen Power BI-Report. Du führst eine große Bereinigung in deinem Workspace durch und entfernst dabei versehentlich den Report. Vorher wärst du wahrscheinlich in Panik ausgebrochen und das Schwitzen hätte angefangen. Dank Item Recovery kannst du ihn jetzt jedoch innerhalb weniger Klicks wiederherstellen, ohne dass du Backup-Dateien durchsuchen musst.

Weitere Informationen zu OneLake findest du hier: OneLake für Power BI Desktop: denn gerade OneLake spielt beim Datenmanagement eine zentrale Rolle.

Warum Item Recovery so wichtig ist

Schutz vor menschlichen Fehlern

Fehler passieren und zwar öfter als man denkt. Beispielsweise löscht ein Teammitglied ein Dataset in der Annahme, dass es nicht mehr benötigt wird. Anschließend stellt sich heraus, dass es doch essenziell ist. Mit Item Recovery kannst du solche Missgeschicke einfach rückgängig machen.

Verbesserte Zusammenarbeit

Andererseits ist Item Recovery auch ein Werkzeug für bessere Teamarbeit. Da mehrere Personen gleichzeitig in einem Workspace arbeiten, steigt das Risiko von Konflikten und versehentlichen Änderungen. Die Wiederherstellungsfunktion gibt allen Beteiligten Sicherheit.

Ergänzung zu Data Governance

Item Recovery ist zwar kein Ersatz für eine durchdachte Data Governance-Strategie, aber es ergänzt sie perfekt. Mehr zu Data Governance in Fabric findest du hier: Data Governance in Fabric.

Schritt-für-Schritt-Anleitung zur Wiederherstellung

1. Zugriff auf den Papierkorb

Du findest den Item Recovery-Bereich im Fabric-Workspace-Menü. Dort werden alle kürzlich gelöschten Items angezeigt.

2. Auswahl des Items

Klicke auf das Item, das du wiederherstellen möchtest. Du kannst auch mehrere Items gleichzeitig auswählen.

3. Wiederherstellung

Mit einem Klick auf „Restore“ wird das Item an seinen ursprünglichen Speicherort zurückgebracht.

4. Prüfung

Vergewissere dich, dass das wiederhergestellte Item korrekt funktioniert. Danach kannst du es wieder in deine laufenden Projekte integrieren.

Grenzen der Item Recovery-Funktion

Obwohl Item Recovery extrem nützlich ist, gibt es einige Einschränkungen:

• Items werden nur für einen begrenzten Zeitraum gespeichert (oft 30 Tage).
• Nicht alle Asset-Typen werden unterstützt! beispielsweise können sehr große Datenbanken oder externe Speicherquellen nicht immer wiederhergestellt werden.
• Änderungen am Item nach dem letzten Speichern werden nicht rückgängig gemacht.

Daher solltest du weiterhin regelmäßige Backups und Versionierungen nutzen.

Best Practices für Item Recovery in Microsoft Fabric

Versionierung nutzen

Gerade bei Reports und Notebooks ist es sinnvoll, Versionen zu speichern, damit du im Notfall nicht nur das Item, sondern auch den letzten Stand wiederherstellen kannst. Ob du dabei für die Quellcodeverwaltung Azure DevOps oder Github nutzt, bleibt dir überlassen.

Data Governance umsetzen

Eine klare Regelung für den Umgang mit Daten schützt dich vor unnötigen Löschungen. Mehr dazu hier: Security in Microsoft Fabric.

Team-Schulung

Stelle sicher, dass alle Teammitglieder wissen, wie Item Recovery funktioniert.

Item Recovery im Zusammenspiel mit anderen Fabric-Funktionen

Item Recovery ist nicht isoliert zu betrachten. Es wirkt zusammen mit verschiedenen anderen Features:

• OneLake: Zentraler Speicher, auf dem viele Fabric-Assets liegen.
• Microsoft Purview: Governance-Tool, das dir hilft, Assets zu klassifizieren und zu verwalten (Microsoft Purview).
• Copilot in Fabric: KI-gestützte Unterstützung bei der Verwaltung und Analyse deiner Daten (Microsoft Copilot in Fabric).

Dadurch ergibt sich ein umfassendes Sicherheits- und Management-System.

Fazit – Abschließend

Abschließend lässt sich sagen: Item Recovery in Microsoft Fabric (Preview) ist ein Gamechanger für alle, die mit wichtigen Daten arbeiten. Es bietet dir eine zusätzliche Sicherheitsebene, spart Zeit und reduziert Stress, wenn einmal etwas schiefgeht. Allerdings solltest du die Funktion nicht als alleinige Schutzmaßnahme betrachten, sondern sie in eine umfassende Data Governance-Strategie einbetten.

Nächste Schritte

• Teste die Item Recovery-Funktion in deinem Workspace.
• Richte klare Lösch- und Wiederherstellungsrichtlinien für dein Team ein.
• Kombiniere Item Recovery mit Microsoft Purview und OneLake für maximale Sicherheit.

Call-to-Action

Möchtest du mehr über Microsoft Fabric erfahren und lernen, wie du deine Daten optimal schützt und verwaltest? Dann schau dir unsere Artikel zu Data Governance und Security in Microsoft Fabric an – oder buche gleich einen Workshop, um dein Team fit zu machen.

Der Beitrag Neu: Microsoft Fabric Item Recovery Guide (Preview) erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

So hoppelt der Osterhase 2026 mit Microsoft Fabric effizient durch die Nacht!

Der Osterhase hatte im Jahr 2025 ein echtes Problem: zu viele Tools, zu viele Excel-Dateien und gleichzeitig viel zu wenig Transparenz in den Datenprozessen.

Daten lagen über verschiedenste Systeme verteilt und waren dadurch schwer zugänglich. Gleichzeitig wurden viele Prozesse noch manuell gesteuert, wodurch immer wieder Fehler entstanden (insbesondere durch Medienbrüche, unterschiedliche Dateiversionen sowie fehlende zentrale Datenstrukturen).

Die Folgen machten sich vor allem am Ostersonntag bemerkbar:
Manchmal landeten die falschen Eier im falschen Garten, einige Körbe waren unvollständig oder die Schokolade wurde erst entdeckt, nachdem sie bereits in der Sonne geschmolzen war.

Diese Kombination aus fragmentierten Daten, manuellen Prozessen und fehlender Transparenz führte letztlich zu Chaos und damit auch zu Unzufriedenheit im gesamten Team des Osterhasen.

Doch im Jahr 2026 ist alles anders.

Der Osterhase setzt nun dank unserer Beratung auf eine moderne Datenplattform mit Microsoft Fabric. Dadurch werden Daten zentral integriert, Prozesse automatisiert gesteuert und Informationen jederzeit transparent verfügbar gemacht.

Und was beim Osterhasen funktioniert, das klappt natürlich auch in Deinem Unternehmen.

Microsoft Fabric OneLake als zentrale Datenbasis statt Datensilos

Früher wurden die Daten des Osterhasen in Excel-Dateien, PDFs sowie auf verschiedenen Servern abgelegt. Dadurch lagen viele Informationen mehrfach vor, waren teilweise veraltet oder schlicht schwer auffindbar.

Zusätzlich kam es immer wieder zu Versionskonflikten, da mehrere Helfer gleichzeitig an unterschiedlichen Dateien arbeiteten. Die Folge: lange Suchzeiten, widersprüchliche Informationen und unnötige Abstimmungsrunden.

Manchmal wusste der Osterhase nicht einmal mehr, in welchem Dokument die aktuelle Wunschliste der Kinder gespeichert war oder welcher Garten bereits beliefert wurde.

Genau dieses Szenario kennen auch viele Unternehmen – wir nennen es das „Ostereierproblem der Daten“:
Wichtige Informationen sind irgendwo versteckt, liegen mehrfach vor oder sind nur mit großem Aufwand auffindbar.

Mit der Einführung von Microsoft Fabric und dem zentralen Datenspeicher OneLake hat sich die Situation jedoch grundlegend verändert.

Heute existiert eine einheitliche, cloudbasierte Datenbasis, in der alle Informationen zentral, strukturiert und mit klar geregelten Zugriffsrechten gespeichert sind.

Dadurch kann der Osterhase jederzeit nachvollziehen:

• welche Eier bereits versteckt wurden

• welche Gärten noch beliefert werden müssen

• welche Süßigkeiten besonders beliebt sind

• und in welchen Nachbarschaften besonders viele Kinder wohnen

Auf diese Weise konnten die alten Datensilos vollständig aufgelöst und gleichzeitig eine deutlich klarere Data Governance etabliert werden.

Der Prozessgewinn ist dabei klar messbar:
weniger Suchaufwand, keine redundanten Daten und eine konsistente Grundlage für Reporting, Analysen und Planung.

Für Unternehmen bedeutet das konkret: eine moderne Data-Lake-Architektur, die als zentrale Basis für Business Intelligence, Künstliche Intelligenz sowie Echtzeitanalysen dient.

Und genau wie beim Osterhasen gilt auch in vielen Organisationen:
Wer seine Daten nicht mehr suchen muss, kann sich endlich darauf konzentrieren, sie sinnvoll zu nutzen.

Microsoft Fabric Data Factory: Automatisierte Datenpipelines

Statt manuelle Abläufe zu pflegen, nutzt der Osterhase seit diesem Jahr konsequent die Data Factory sowie Pipelines in Microsoft Fabric. Dadurch können viele Prozesse nicht nur effizienter, sondern auch deutlich zuverlässiger gesteuert werden.

Durch diese moderne Plattform werden Abläufe regelbasiert orchestriert und vollständig automatisiert ausgeführt – angefangen beim Bestands-Update der Ostereier, über die Synchronisierung der Lagerbestände bis hin zur Planung der optimalen Hoppel-Route durch die verschiedenen Nachbarschaften.

Einige Beispiele aus dem digitalen Osterhasen-Alltag zeigen, wie leistungsfähig diese Automatisierung inzwischen ist:

• Neue Kinder-Wunschlisten werden automatisch importiert und verarbeitet

• Lagerbestände der Schokoladenfabriken werden kontinuierlich synchronisiert

• Lieferungen der fleißigen Helfer-Hasen werden automatisch eingeplant und koordiniert

• Und falls es zu Engpässen kommt, werden sofort zusätzliche Eier nachbestellt

Zusätzlich unterstützt Künstliche Intelligenz bei der Erstellung und Optimierung der Pipelines. Dadurch lassen sich viele Pipeline-Strukturen nicht nur schneller entwickeln, sondern auch deutlich einfacher anpassen. In der Praxis führt das zu einer spürbaren Reduzierung der Implementierungszeiten, während gleichzeitig die Skalierbarkeit der Datenprozesse deutlich verbessert wird.

Für Unternehmen bedeutet das konkret: automatisierte ETL-Prozesse, optimierte Lead-Übergaben, kontinuierliche Forecast-Updates oder auch operative Workflows lassen sich effizient, zuverlässig und vor allem zentral auf einer integrierten Plattform umsetzen.

Microsoft Fabric Real-Time Intelligence für Echtzeit-Analysen

Früher basierten die vom Osterhasen zu treffenden Entscheidungen auf nächtlichen Auswertungen.

Das Problem:
Wenn plötzlich mehr Kinder in einem Viertel unterwegs waren oder ein Hund im Garten patrouillierte, erfuhr der Osterhase davon oft erst zu spät.

Heute fließen die Daten in Echtzeit über Eventstreams und Streaming-Analysen ein.

Zum Beispiel:

• Sensoren melden, ob ein Garten bereits besucht wurde
• Helfer-Hasen melden live den Fortschritt der Auslieferungen
• Wetterdaten zeigen, wo Eier besser im Schatten versteckt werden sollten
• Nachfrage nach bestimmten Süßigkeiten wird sofort sichtbar

Das alles führt zu einer Verkürzung der Reaktionszeiten von Stunden auf Sekunden und schafft Transparenz über Prozesse und die gesamte Lieferketten.

Mit Real-Time Intelligence in Microsoft Fabric können Unternehmen sofort auf Veränderungen reagieren. Dashboards aktualisieren sich live, Alerts werden automatisch ausgelöst und Entscheidungen basieren auf aktuellen Daten statt auf historischen Werten.

Microsoft Fabric Lakehouse-Architektur und Direct Lake für schnelles Reporting

Die Kombination aus einer Lakehouse-Architektur und Direct Lake in Power BI ermöglicht den direkten Zugriff auf die Daten im zentralen Speicher OneLake innerhalb von Microsoft Fabric.

Der große Vorteil dabei: Die Daten können ohne aufwendige Importe und ohne doppelte Datenhaltung genutzt werden. Statt Daten regelmäßig zu replizieren oder in separate Reporting-Strukturen zu kopieren, greifen Analysen direkt auf die aktuelle Datenbasis zu.

Für den Osterhasen bedeutet das konkret: In seinem digitalen Oster-Dashboard kann er jederzeit in Echtzeit erkennen,

• welche Regionen bereits vollständig beliefert wurden

• wo noch Körbe fehlen

• wie viele Eier aktuell noch im Lager vorhanden sind

• und welche Überraschungseier besonders schnell verschwinden

Durch diese Architektur konnten die Refresh-Zeiten der Reports drastisch reduziert werden. Gleichzeitig werden Speicherbedarf sowie Wartungsaufwand deutlich gesenkt, da keine redundanten Datenstrukturen mehr gepflegt werden müssen.

Für datengetriebene Unternehmen bedeutet das einen entscheidenden Vorteil: modernes Reporting ohne klassische Batch-Fenster, ohne zeitverzögerte Datenimporte und gleichzeitig ohne Kompromisse bei Performance, Aktualität oder Skalierbarkeit.

So wird aus klassischen Reports eine echte, nahezu Echtzeit-basierte Entscheidungsgrundlage.

Copilot in Microsoft Fabric als Produktivitäts-Booster

Durch die Nutzung des Copiloten in Microsoft Fabric lassen sich Datenabfragen, Pipelines sowie Analysen KI-gestützt erstellen, erweitern und optimieren.

Der große Vorteil dabei: Viele Aufgaben können einfach über natürliche Sprache angestoßen werden, ohne dass komplexe Abfragen oder technische Konfigurationen manuell erstellt werden müssen.

Auch der Osterhase profitiert davon. Er kann dem Copiloten beispielsweise Fragen stellen wie:

• „Welche Regionen brauchen dieses Jahr mehr Schokoladeneier?“

• „Welche Route spart mir am Ostersonntag die meiste Zeit?“

• „Wo wurden im letzten Jahr die meisten Osternester entdeckt?“

Auf Basis dieser Fragen erstellt die KI automatisch passende Datenabfragen, Dashboards oder sogar Vorschläge für neue Datenpipelines. Dadurch lassen sich Analysen deutlich schneller aufbauen und bestehende Prozesse einfacher anpassen.

Das spart nicht nur Zeit, sondern reduziert gleichzeitig viele manuelle Arbeitsschritte und unterstützt das gesamte Team bei komplexeren Aufgaben.

So kann der Osterhase im Zweifel auch selbst eingreifen und kleinere Anpassungen vornehmen – sogar mitten in der Osternacht, wenn kurzfristig noch Änderungen notwendig werden.

Künstliche Intelligenz wird damit nicht zum Ersatz für Fachkräfte, sondern vielmehr zu einem effektiven Beschleuniger für Data Engineering, Reporting und Forecasting.

Für Unternehmen bedeutet das: Datenprojekte lassen sich schneller umsetzen, flexibler anpassen und deutlich effizienter betreiben.

Fazit – Effizienz durch integrierte Datenarchitektur

Im Jahr 2026 hoppelt der Osterhase nicht schneller – sondern intelligenter und effizienter.

Dank Microsoft Fabric kann er jetzt:

• Osternester deutlich besser planen

• die Wünsche der Kinder präziser erfüllen

• Lieferungen zuverlässig koordinieren

• und seine Arbeit am Ostersonntag stressfrei erledigen

Genau das ist der Kern von Microsoft Fabric: eine integrierte Datenplattform für Data Engineering, Business Intelligence und Echtzeit-Analysen mit zentraler Speicherung, Automatisierung und KI-Unterstützung.

Nicht nur der Osterhase profitiert von dieser Lösung, sondern auch Unternehmen durch:

• einer konsolidierten Datenarchitektur

• weniger Tool-Komplexität

• automatisierten Datenprozessen

• Echtzeit-Analytics

• und skalierbarer KI-Integration

Wer moderne Datenstrategien erfolgreich umsetzen möchte, schafft mit Microsoft Fabric die Grundlage für effiziente, transparente und zukunftsfähige Geschäftsprozesse.

Wir von der arelium GmbH wünschen euch ein schönes Osterfest im Kreis eurer Lieben!

Und falls du – genau wie der Osterhase – Interesse an Microsoft Fabric bekommen hast, dann buche einfach einen unverbindlichen Beratungstermin bei einem unserer Experten. So kannst du deine Datenprozesse sofort effizienter und smarter gestalten.

Der Beitrag Vom Eierchaos zur Datenstrategie: Der Osterhase entdeckt Microsoft Fabric erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Git-Integration und CI/CD für Fabric Workspaces: Der klare Leitfaden

Warum dieses Thema gerade jetzt wichtig ist

Hast du dich schon einmal gefragt, wie du Änderungen in deinem Microsoft Fabric Workspace sauber versionieren kannst, ohne Angst, dass ein Fehler dein komplettes Projekt zerschießt? Oder wie du neue Features automatisiert in deine Produktionsumgebung überträgst, ohne jede Datei mühsam von Hand zu kopieren?

Genau hier kommt die Git-Integration ins Spiel. Zusammen mit einem guten CI/CD-Setup (Continuous Integration und Continuous Deployment) kannst du deine Fabric-Workspaces so organisieren, dass Änderungen nachvollziehbar, testbar und schnell ausrollbar sind. Das ist nicht nur ein Komfortgewinn, sondern spart langfristig Zeit und Nerven. Zusätzlich minimiert es das Risiko von Daten- oder Modellfehlern.

Allerdings ist das Thema für viele, die gerade erst mit Microsoft Fabric arbeiten, noch etwas abstrakt. Daher schauen wir uns Schritt für Schritt an, wie du Git einbindest, CI/CD einrichtest und dabei Best Practices einhältst.

Was macht die Git-Integration in Microsoft Fabric so besonders?

Während viele Entwickler Git schon seit Jahren nutzen, war die Integration in Business-Intelligence-Tools und Data-Analytics-Plattformen lange Zeit eher rudimentär.

Microsoft Fabric geht hier einen Schritt weiter: Du kannst komplette Workspaces direkt mit einem Git-Repository verbinden. Inklusive aller Reports, Datasets, Dataflows und anderer Artefakte!

Das bedeutet:

• Änderungen an Berichten und Modellen landen nicht nur lokal, sondern auch im Versionsverlauf.
• Du kannst problemlos zu älteren Ständen zurückspringen.
• Mehrere Teammitglieder können parallel arbeiten, ohne sich gegenseitig zu überschreiben.

Wie funktioniert das technisch?

Im Grunde legt Fabric bei aktivierter Git-Integration eine Art „Spiegelung“ deiner Artefakte im Repository an. Jedes Mal, wenn du speicherst, kannst du diese Änderungen committen und pushen. Entweder manuell oder automatisiert. Das Repository dient dann als zentraler Punkt für Zusammenarbeit und als Basis für CI/CD-Pipelines.

Voraussetzungen für Git-Integration in Fabric

Bevor du loslegst, solltest du sicherstellen, dass folgende Punkte erfüllt sind:

• Fabric-Kapazität mit Git-Integration (nicht jede Lizenz hat den vollen Funktionsumfang)
  → Mehr dazu findest du im Fabric Überblick.

• Git-Repository (idealerweise in Azure DevOps oder GitHub)
  → Microsoft empfiehlt Azure DevOps, da die CI/CD-Integration hier besonders eng ist.

• Berechtigungen
  →  du brauchst Zugriff auf das Repository und den Fabric-Workspace.
• Klare Projektstruktur
  → bevor du Git aktivierst, solltest du überlegen, wie deine Dateien organisiert werden.

Tipps hierzu findest du auch in unserem Beitrag zur Data Governance in Fabric.

Schritt-für-Schritt: Git mit Fabric Workspaces verbinden

Schritt 1 – Verbindung zum Repository herstellen

Im Workspace-Menü gibt es den Punkt Git-Integration. Hier trägst du die Repository-URL, den Branch (oft main oder master) und deine Authentifizierungsmethode ein.

Angenommen, du nutzt Azure DevOps, sieht die URL etwa so aus:

https://dev.azure.com///_git/

Nach dem Speichern synchronisiert Fabric die aktuellen Artefakte ins Repository. Der erste Commit umfasst sämtliche vorhandenen Inhalte – das kann je nach Größe etwas dauern.

Schritt 2 – Branch-Strategie definieren

Ohne klare Branch-Strategie endet Zusammenarbeit oft im Chaos. Im BI-Kontext hat sich bewährt:

• Main: Produktionsstand
• Develop: Aktive Entwicklungsphase
• Feature-Branches: Für einzelne Reports oder Modelländerungen

Dadurch kannst du Änderungen isoliert testen, bevor sie den Hauptstand erreichen. Das ist besonders wichtig, weil Fabric-Artefakte oft komplexe Abhängigkeiten haben.

Schritt 3 – CI/CD-Pipeline einrichten

Hier kommt der spannende Teil: Mit der Git-Integration kannst du Änderungen aus dem Repository automatisiert in andere Fabric-Workspaces deployen, etwa von einer Entwicklungs- in eine Produktionsumgebung. Hier zu gibt es zwei Möglichkeiten:

Zum einen haben wir die in Fabric fest implementierten Deployment-Pipelines. Diese sind per einfachem User Interface recht einfach zusammenzuklicken.

Zum anderen gibt es die Möglichkeit, das Ganze über Azure DevOps zu machen.

Beispiel mit Azure DevOps YAML-Pipeline:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: PowerShell@2
    inputs:
      targetType: 'inline'
      script: |
        # Fabric CLI-Befehle (fiktiv, Beispiel)
        fabric login --token $(FabricToken)
        fabric deploy --workspaceId $(ProdWorkspaceId) --sourceRepo .

Dieser einfache Pipeline-Job reagiert auf Änderungen im
main-Branch und führt ein Deployment in den Produktions-Workspace durch. In der Realität würdest du hier noch Tests, Validierungen und vielleicht sogar automatisierte Report-Checks einbauen.

Best Practices für Git und CI/CD in Fabric

1. Kleine Commits statt großer „Monster-Updates“

Damit Änderungen nachvollziehbar bleiben, solltest du lieber häufiger committen. Das erleichtert den Review-Prozess und macht Fehlerquellen sichtbar.

2. Automatisierte Tests einbauen

Bevor ein Deployment läuft, sollten Tests sicherstellen, dass Berichte und Modelle korrekt laden. Das kann im CI-Schritt geschehen, indem etwa Power BI Deployment Pipelines oder Fabric-eigene Validierungen genutzt werden.

3. Sensible Daten schützen

Falls dein Repository sensible Daten enthalten könnte, solltest du diese entweder entfernen oder mit Tools wie Microsoft Purview klassifizieren und schützen.

4. Deployment-Pfade klar definieren

Gerade bei mehreren Workspaces ist es wichtig, genau zu wissen, welche Artefakte wohin gehen. Das spart Zeit und verhindert ungewollte Überschreibungen.

Verknüpfung mit anderen Fabric-Funktionen

Die Git-Integration ist kein isoliertes Feature. Sie spielt perfekt mit anderen Fabric-Komponenten zusammen. Wenn du beispielsweise OneLake nutzt, kannst du deine Datenhaltung und Berichte gemeinsam versionieren. Mehr dazu im Beitrag OneLake für Power BI Desktop.

Auch bei Themen wie Security in Microsoft Fabric (Link) ist Git relevant, denn durch die Versionskontrolle dokumentierst du Änderungen an Berechtigungen und kannst sie im Zweifelsfall zurücksetzen.

Häufige Stolperfallen

• Nicht synchronisierte Branches
  → wenn du versehentlich im falschen Branch arbeitest, kann das zu Konflikten führen.
• Fehlende Berechtigungen
  → gerade in größeren Teams ist es wichtig, dass jeder die nötigen Rechte hat.
• CI/CD-Fehler durch fehlende Artefakte
  → wenn ein Deployment scheitert, liegt das oft an fehlenden Abhängigkeiten.

Warum sich der Aufwand lohnt

Git-Integration und CI/CD in Microsoft Fabric sind keine „Nice-to-have“-Features, sondern echte „Lebensretter“. Sie machen deine Arbeit planbarer, sicherer und skalierbarer. Zwar kostet die Einrichtung anfangs etwas Zeit, aber die langfristigen Vorteile sind enorm. Vor allem dann , wenn dein Team wächst oder Projekte komplexer werden.

Call-to-Action

Wenn du Lust hast, deine Fabric-Workspaces mit Git und CI/CD aufzuwerten:

1. Richte ein Test-Repository ein.
2. Verbinde es mit einem nicht-produktiven Workspace.
3. Experimentiere mit einer einfachen Pipeline in Azure DevOps.

Du wirst schnell merken, wie viel entspannter die Arbeit wird und wie klar du den Überblick behältst.

Falls du tiefer einsteigen willst, empfehle ich dir unseren Artikel zu Medallion-Architektur in Microsoft Fabric oder den Beitrag Das ändert sich mit Microsoft Fabric.

Und wenn du direkt loslegen möchtest: Schau in die Microsoft Docs zur Git-Integration in Fabric oder in Community-Beiträge. Dort findest du viele Praxisbeispiele.

Der Beitrag Microsoft Fabric Git Integration – Git & CI/CD für Fabric Workspaces – Ultimativer Guide erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Der Karneval lebt von Tradition, Emotionen und einem gesunden Maß an Chaos. Doch selbst der jeckste Prinz weiß: Ein bisschen Struktur hat noch keiner Session geschadet. Während früher Entscheidungen mit Bauchgefühl, Glaskugel oder dem bewährten 3. Artikel des rheinischen Grundgesetztes „Et hätt noch emmer joot jejange“ getroffen wurden, steht der Prinz von heute vor einer neuen Realität. Willkommen im Zeitalter von Microsoft Fabric – dort, wo Alaaf auf Analytics trifft.

Vom Bierdeckel zum OneLake – Datenhaltung im Karneval

Noch vor wenigen Jahren wurden wichtige Informationen rund um den Karneval auf allem gespeichert, was gerade greifbar war: Zettel, Excel-Listen mit kreativen Dateinamen wie „Ordensliste_V3.0_Stand_01.2023_aktuellsteVersion_letzter_Stand_28.01.2026.xlsx“ oder eben Bierdeckeln.

Microsoft Fabric macht damit Schluss. Alle relevanten Daten – vom Kamelle-Verbrauch über Auftrittszeiten der Tanzgruppen bis hin zu Getränkebeständen und Ordenslisten – landen zentral im OneLake. Für den Prinzen bedeutet das eine verlässliche „Single Source of Truth“. Egal ob Sitzung, Umzug oder Aftershow-Party: Die Daten sind konsistent, aktuell und sogar an Weiberfastnacht noch auffindbar. Die Tradition bleibt erhalten, aber die Daten sind werden jetzt erwachsen.

Echtzeit-Analytics statt „Boochjeföhl“ – Der Prinz blickt aufs Dashboard

Besonders mächtig wird Microsoft Fabric im laufenden Betrieb. Während die Kapelle spielt und der Saal kocht, wirft der Prinz einen Blick auf sein Dashboard. In Echtzeit sieht er, wie sich die Stimmung entwickelt, oder ob im Elferrat langsam ein kritischer Füllstand erreicht wird. Statt hektischer Zurufe und spontaner Entscheidungen heißt es dann ganz sachlich: „Trinkt zwischendurch auch mal ein Wasser.“

Das klingt unromantisch, funktioniert aber erstaunlich gut. Der Karneval bleibt jeck, wird aber plötzlich planbarer.

Kamelle-Logistik mit Fabric Data Factory

Die Frage „Haben wir genug Kamelle?“ ist für den Prinz Karneval nicht trivial. Mit Fabric könntest du ein Supply-Chain-Management aufbauen, das Lagerbestände, Lieferzeiten und Verteilungspunkte im Blick behält. Die Fabric Data Factory erlaubt es, Daten aus verschiedenen Quellen (etwa Lieferantenlisten, Bestellportalen und Fahrzeugtracking-Systemen) zu integrieren.

Anschließend lassen sich diese Daten im Lakehouse-Format speichern, wodurch sie sowohl für Analyse als auch für operative Entscheidungen nutzbar sind. Mehr zu den Möglichkeiten einer Lakehouse-Architektur findest du übrigens im Beitrag Lakehouse vs Warehouse.

KI, Automatisierung und Eskalationsstufen „Alaaf++“

Richtig modern wird es, wenn künstliche Intelligenz ins Spiel kommt. Mit Copilot und Machine Learning erkennt Microsoft Fabric Muster, die früher nur erfahrene Karnevalisten im Gefühl hatten. Das System weiß, wann Reden zu lang werden, welche Musik garantiert für Stimmung sorgt und ab welchem Zeitpunkt der Elferrat statistisch nicht mehr voll entscheidungsfähig ist. Parallel laufen automatisierte Workflows im Hintergrund. Orden werden zur richtigen Zeit verteilt, Benachrichtigungen gehen raus, wenn die Tanzfläche überfüllt ist, und selbst der Strüßche-Nachschub lässt sich ereignisbasiert steuern. Sinkt der Bestand unter einen definierten Wert, wird automatisch nachbestellt.

Zero Downtime im Karnevalsbetrieb – selbst nach dem dritten Kölsch oder Alt.

Das klingt nach Zukunftsmusik, ist aber schon Realität – mehr dazu im Beitrag Microsoft Copilot in Fabric.

Nach dem Alaaf ist vor dem Dashboard – Lernen aus den Daten

Nach der Session beginnt die eigentliche Stärke von Microsoft Fabric. Statt vager Erinnerungen gibt es belastbare Zahlen. Welche Programmpunkte kamen besonders gut an? Wo war die Aufmerksamkeit am höchsten? Wie viele Kamelle „pro Jeck“ wurden tatsächlich verteilt?

Diese Erkenntnisse können direkt in die Planung der nächsten Session einfließen. Das berühme Bauchgefühl wird dabei nicht abgeschafft – es bekommt lediglich eine Erweiterung. Durch Historisierung wird dafür gesorgt, dass jede neue Session ein bisschen besser wird als die Letzte.

 

Fazit: Ein Prinz regiert – ein moderner Prinz regiert datengetrieben

Der Prinz der Zukunft regiert nicht nur mit Zepter, Orden und Charisma, sondern auch mit Dashboards, Pipelines und KI.

Microsoft Fabric macht den Karneval skalierbar, hochverfügbar und datengetrieben, ohne ihm die Jeckheit zu nehmen. Denn eines bleibt trotz aller Technologie gleich:

„Denn wenn et Trömmelche jeht, dann stonn mer all parat…“

Wer schon auf Microsoft Fabric umgestiegen ist, kann dieses Jahr ganz entspannt Kamelle werfen und „Alaaf“ oder  „Helau“ rufen – das Dashboard kümmert sich ums Chaos, die KI ums Elferrat-Management, und ihr genießt einfach den Karneval.

 

Wir von der arelium GmbH wünschen euch eine großartige, sorgenfreie und rundum närrische Fastelovendszick!

Falls Du Interesse an Microsoft Fabric bekommen hast, dann buche doch einfach einen unverbindlichen Beratungstermin bei einem unserer Fachleute.

Der Beitrag Prinz Karneval 4.0 – Wie Microsoft Fabric den Karneval revolutioniert erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Infrastructure as Code für Fabric + Azure: Was heute möglich ist und was nicht

Hast du dich schon mal gefragt, ob du deine komplette Microsoft Fabric-Umgebung genauso automatisiert und reproduzierbar aufsetzen kannst wie eine klassische Azure-Infrastruktur? Also wirklich von Null auf, ohne ins Portal zu klicken, nur mit ein paar Zeilen Code? Das klingt verlockend, vor allem wenn du schon mit Infrastructure as Code (IaC) in Azure vertraut bist. Aber wie sieht das in der Praxis aus, wenn Fabric ins Spiel kommt? Genau darum geht’s in diesem Artikel: Wir schauen uns an, welche Möglichkeiten es aktuell gibt, wo noch Lücken sind und wie du trotzdem schon heute einen guten Teil deiner Fabric- und Azure-Umgebungen automatisieren kannst.

Microsoft Fabric und Azure: ein kurzer Überblick

Bevor wir ins Detail gehen, lass uns kurz klarstellen, worüber wir sprechen.

Microsoft Fabric ist eine integrierte Data- und Analytics-Plattform, die Services wie Data Engineering, Data Science, Real-Time Analytics, Data Warehouse und natürlich Power BI in einer einheitlichen Umgebung bündelt.

Dank OneLake als zentralem Datenspeicher kannst du Daten aus verschiedensten Quellen zusammenführen. Falls du noch nicht so tief im Thema bist: Lies dir gerne unseren Überblick zu OneLake für Power BI Desktop durch. Dort bekommst du schnell ein Gefühl, wie der zentrale Speicher funktioniert.

Azure hingegen ist der Cloud-Baukasten von Microsoft. Hier findest du alles von virtuellen Maschinen über Datenbanken bis hin zu KI-Diensten. In Azure ist Infrastructure as Code schon lange etabliert. Mit Tools wie ARM Templates, Bicep oder Terraform kannst du Ressourcen definieren, versionieren und automatisiert bereitstellen.

Was bedeutet Infrastructure as Code (IaC) im Kontext von Fabric?

IaC heißt, dass du deine Infrastruktur nicht manuell über Klicks im Portal aufbaust, sondern sie als Code beschreibst. Das bringt gleich mehrere Vorteile: Du kannst Änderungen nachvollziehen, Umgebungen reproduzieren und Deployments automatisieren.

In Azure funktioniert das mit Bicep oder Terraform hervorragend, aber bei Fabric sieht es aktuell noch etwas anders aus. Fabric ist zwar technisch eng mit Azure verwoben, allerdings gibt es, Stand heute, keine vollständige API- oder Template-Abdeckung, um jeden Aspekt einer Fabric-Umgebung per Code zu erstellen.

Was heute schon möglich ist

Lass uns positiv anfangen: Es gibt einige Bereiche, die du bereits automatisieren kannst – teilweise direkt über Azure-Mechanismen, teilweise über Workarounds.

1. Kapazitäten und Workspaces in Fabric

Über die Power BI REST API kannst du Workspaces anlegen, verwalten und Nutzerberechtigungen setzen. Da Fabric auf derselben Workspace-Logik wie Power BI aufsetzt, funktioniert dieser Weg auch hier. Mit einem Skript, das die REST API nutzt, kannst du z. B. automatisch ein Workspace-Gerüst für ein neues Projekt erstellen.

Kurzes Beispiel in PowerShell:

$token = Get-PowerBIAccessToken

Invoke-RestMethod `
  -Uri "https://api.powerbi.com/v1.0/myorg/groups" `
  -Headers @{ Authorization = "Bearer $token" } `
  -Method Post `
  -Body @{ name = "Projekt_X_Fabric_Workspace" }

2. Azure-Ressourcen für Fabric-Datenintegration

Fabric nutzt im Hintergrund Azure-Ressourcen wie Data Lake Storage oder (je nach Szenario) Synapse-Elemente. Diese kannst du weiterhin per IaC in Azure bereitstellen. Ein Beispiel: Du kannst einen Azure Data Lake Storage Gen2 mit Bicep anlegen und ihn anschließend als Speicher im Fabric-Workspace konfigurieren.

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'fabricstorage${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    isHnsEnabled: true
  }
}

Mehr zu Speicheroptionen in Fabric findest du auch in unserem Artikel zu
Speichermöglichkeiten in Fabric.

3. Data Pipelines und Dataflows

Fabric Data Factory (vergleichbar mit Azure Data Factory) erlaubt es, Pipelines zu erstellen. Allerdings kannst du diese aktuell nicht vollständig per IaC aufsetzen. Es gibt aber Export/Import-Mechanismen. Du kannst eine Pipeline als JSON exportieren und dann über die API oder das Portal importieren. Das ist zwar nicht so elegant wie ein reines IaC-Deployment, aber immerhin reproduzierbar.

Was (noch) nicht möglich ist

Hier kommen wir zum spannenden Teil, und vielleicht auch zu deinem größten Aha-Moment.

Fehlende API-Abdeckung

Viele Fabric-spezifische Objekte wie Lakehouses, Warehouses oder Real-Time-Analytics-Knoten lassen sich derzeit nicht einfach per API oder Template erstellen. Zwar gibt es Ansätze über Microsoft Graph oder Power BI REST, doch die sind oft auf Metadaten beschränkt. Das heißt: Du kannst zwar sehen, welche Objekte existieren, aber nicht jedes davon per Code anlegen.

Komplettes „Greenfield“-Deployment

Ein vollautomatisiertes Setup „von Null auf Fabric“ – also inklusive Kapazität, Workspaces, Datenobjekte, Pipelines und Sicherheitseinstellungen – ist Stand heute nicht möglich. Du wirst immer einen Teil manuell im Portal ergänzen müssen. Das ist ein klarer Unterschied zu Azure, wo du theoretisch eine komplette Umgebung mit einem einzigen Terraform-Apply hochziehen kannst.

Sicherheit und Governance

Fabric bringt spannende Governance-Features, etwa über Microsoft Purview. Diese lassen sich über IaC nur eingeschränkt konfigurieren. Zwar kannst du Purview in Azure automatisieren (mehr dazu in unserem Beitrag Microsoft Purview – Data Governance), aber die Anbindung an Fabric muss aktuell noch manuell erfolgen.

Workarounds und Best Practices

Nur weil nicht alles geht, heißt das nicht, dass du auf Automatisierung verzichten musst. Hier ein paar Ideen, wie du heute schon effizient arbeiten kannst:

• Hybrid-Ansatz: Automatisiere alles, was in Azure geht, und kombiniere das mit Skripten für Fabric-Workspaces.
• Template-Libraries: Halte deine Pipeline- und Dataflow-Definitionen als JSON-Versionen vor, um sie bei Bedarf schnell wieder einzuspielen.
• API-Wrapper: Nutze eigene Skripte, die REST-Calls bündeln, um wiederkehrende Aufgaben zu vereinfachen.
• Dokumentation als Code: Auch wenn du manuell klickst, dokumentiere jeden Schritt in Markdown – so kannst du ihn später leichter automatisieren, wenn die API verfügbar wird.26.

Ausblick: Was Microsoft in Zukunft liefern könnte

Microsoft entwickelt Fabric rasant weiter. Daher ist es vermutlich nur eine Frage der Zeit, bis wir mehr API-Endpunkte und IaC-Unterstützung sehen. Gerade die Integration mit Azure DevOps oder GitHub Actions für CI/CD-Deployments wäre ein Gamechanger. Wenn dich das Thema DevOps interessiert, schau dir auch unseren Artikel Was bedeutet eigentlich DevOps? an.

Schluss

Unterm Strich lässt sich sagen: Mit Microsoft Fabric kannst du heute schon einen Teil deiner Infrastruktur per Code aufbauen. Vor allem in den Bereichen, in denen Fabric auf klassische Azure-Ressourcen setzt. Vollautomatisierte End-to-End-Deployments sind jedoch noch nicht drin, da APIs und Templates fehlen. Aber genau hier liegt die Chance: Wer jetzt anfängt, erste Automatisierungen aufzubauen, ist bereit, sobald Microsoft die fehlenden Puzzlestücke liefert.

Call-to-Action

Wenn du direkt loslegen willst, schnapp dir ein paar Azure-Bicep-Templates und bau die Grundinfrastruktur für deine Fabric-Projekte. Experimentiere mit der Power BI REST API für Workspaces und teste den Import/Export von Pipelines. Schau auch in unseren Beitrag Security in Microsoft Fabric rein, um deine Deployments von Anfang an sicher zu gestalten.

Der Beitrag Infrastructure as Code mit Microsoft Fabric und Azure erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

In unserer schnelllebigen und mobilen Welt sind Cloud-Datenbanken das Herzstück moderner IT-Architekturen. Egal ob für Webanwendungen, Analysen, IoT- Szenarien oder unternehmenskritische Systeme – Microsoft bietet in seiner Cloud-Umgebung Azure eine breite Palette an Datenbankdiensten. Versprochen, hier findest du für jede Anforderung die perfekte Lösung!

In diesem Beitrag bekommst du einen Überblick über die wichtigsten Azure-Datenbanken, ihre Anwendungsfälle und Vorteile.

Azure SQL-Datenbank (Cloud-Datenbanken)

Die Azure SQL-Datenbank ist Microsofts vollständig verwaltete relationale Cloud-Datenbank, die auf dem SQL Server basiert.
Sie eignet sich besonders für moderne Cloud-Anwendungen, die sowohl Zuverlässigkeit als auch Skalierbarkeit erfordern, und das bei minimalem Wartungsaufwand.
Zudem profitiert man von automatischem Performance-Tuning, regelmäßigen Sicherheitsupdates sowie integrierter Hochverfügbarkeit, wodurch sie ideal für Entwickler ist, die sich nicht mit der zugrunde liegenden Infrastruktur beschäftigen wollen.

Merkmale:

• Vollständig verwaltet (PaaS)
• Automatische Backups
• Nahezu unbegrenzte Skalierung
• Hochverfügbarkeit
• Verschiedene Bereitstellungsmodelle: Single Database, Elastic Pool, Hyperscale

Einsatzszenarien:

• Webanwendungen
• SaaS-Plattformen
• Unternehmensdatenbanken mit kleinen bis hohen Anforderungen

Azure Cosmos DB Cloud-Datenbanken

Bei der Azure Cosmos DB handelt es sich um Microsofts hoch skalierbare, global verteilte NoSQL-Datenbank, die speziell für Anwendungen entwickelt wurde, die sowohl eine niedrige Latenz als auch eine hohe Verfügbarkeit erfordern. Weil sie verschiedene APIs wie MongoDB oder Cassandra unterstützt, lässt sie sich flexibel in bestehende Systeme integrieren, sodass Entwickler je nach Bedarf auf vertraute Technologien zurückgreifen können.
Zudem ermöglicht die weltweite Verteilung der Daten eine konsistente Nutzererfahrung – unabhängig davon, wo sich die Nutzer befinden.

Merkmale:

• Unterstützung verschiedener APIs: SQL (DocumentDB), MongoDB, Cassandra, Gremlin, Table
• Niedrige Latenz bei Lese- und Schreiboperationen
• Globale Verteilung und Echtzeit-Replikation

Einsatzszenarien:

• Globale Web- oder Mobilanwendungen
• IoT-Anwendungen
• E-Commerce und Echtzeitanalysen

Azure-Datenbank für PostgreSQL

Die Azure-Datenbank für PostgreSQL bietet eine vollständig verwaltete PostgreSQL-Umgebung auf Azure, wodurch sie ideal für Standardanwendungen sowie für hochskalierende Datenverarbeitung ist. Da PostgreSQL ein beliebtes Open-Source-Datenbanksystem mit einer großen Community ist, profitieren Nutzer von kontinuierlicher Weiterentwicklung und einer umfangreichen Unterstützung durch die Community.

Merkmale:

• Open-Source
• Hochverfügbarkeit mit Zonen-Redundanz
• Skalierbare Leistung und Speicher
• Unterstützung von Citus (massiv parallele Verteilung)

Einsatzszenarien:

• Geodatenverarbeitung (GIS)
• Analyse- und Reporting-Szenarien

Azure-Datenbank für MySQL

Auch für MySQL bietet Azure einen vollständig verwalteten Dienst, der sich insbesondere auf die Themen Einfachheit, Sicherheit und Skalierbarkeit fokussiert.

Da MySQL im Webbereich besonders beliebt ist – insbesondere, wenn es um CMS- und E-Commerce-Systeme geht – findet es in diesen Bereichen eine entsprechend intensive Anwendung.

Somit eignet sich der Azure-Dienst ideal für Entwickler, die eine vertraute Datenbanktechnologie mit den Vorteilen einer Cloud-Plattform kombinieren möchten.

Merkmale:

• Kompatibel mit MySQL 5.7 und 8.0
• Skalierbarkeit und automatische Patches
• Flexible Server-Architektur mit mehr Kontrolle

Einsatzszenarien:

• WordPress-Hosting
• Webanwendungen kleiner bis mittlerer Größe

Azure-Datenbank für MariaDB (Hinweis: wird eingestellt)

Bei Azure MariaDB handelt es sich um ein Fork (eine „Kopie“ die unabhängig vom Original weiterentwickelt wurde) von MySQL das jedoch mit zusätzlichen Features ausgestattet ist. Microsoft stellt MariaDB jedoch schrittweise ein. Bestehende Nutzer sollten zur Azure-Datenbank für MySQL oder einer VM (Virtuelle Maschine) -basierten Lösung migrieren.

Merkmale:

• Basiert auf MySQL
• Integrierte Skalierung und Backup-Funktionen
• Unterstützung für bekannte Tools

Einsatzszenarien:

• Bestehende MariaDB-Anwendungen
• Kleinere relationale Workloads
• Web-Apps mit Open-Source-Stack

Azure Synapse Analytics (Cloud-Datenbanken)

Azure Synapse Analytics ist ein cloudbasierter Dienst, der Datenintegration, Big Data-Analyse und Data Warehousing kombiniert, wodurch eine umfassende Plattform für datengetriebene Anwendungen entsteht.
Synapse ermöglicht es, schnell Erkenntnisse aus großen Datenmengen zu gewinnen, indem es leistungsstarke Tools wie SQL, Apache Spark sowie den Data Explorer bereitstellt. Darüber hinaus kannst du mit Azure Synapse Daten aus verschiedenen Quellen integrieren, transformieren und analysieren, sodass du fundierte Entscheidungen auf Basis konsistenter und aktueller Informationen treffen kannst. Weil alle Komponenten eng miteinander verknüpft sind, lässt sich der gesamte Datenfluss effizient steuern und automatisieren. Für einen tieferen Einblick in Synapse empfehle ich den Beitrag meines Kollegen Tobias Adler: Azure Synapse Analytics

Merkmale:

• T-SQL-basiertes MPP-Data Warehouse ( Massively Parallel Processing)
• Integration mit Data Lake, Spark, Power BI
• Serverless SQL und dedizierte Pools

Einsatzszenarien:

• Datenanalyse
• Echtzeitdatenintegration
• Reporting und Business Intelligence

Azure Data Explorer (Kusto) Cloud-Datenbanken

Azure Data Explorer (Kusto) ist eine leistungsstarke Datenanalyseplattform, die speziell für schnelle Abfragen auf großen Datensätzen entwickelt wurde.
Dabei nutzt die Plattform die Kusto Query Language (KQL) – eine Sprache, die nicht nur einfach zu erlernen, sondern auch sehr effizient ist (hier findest du einen Vergleich zwischen SQL und KQL). Mit dem Azure Data Explorer kannst du Daten in Echtzeit verarbeiten und diese analysieren, wodurch er sich besonders für das Monitoring, die Sicherheitsanalyse sowie die Analyse von Nutzerverhalten eignet.
Außerdem integriert sich die Plattform nahtlos in andere Azure-Dienste wie Event Hubs, IoT Hub und Azure Monitor, sodass umfassende End-to-End-Szenarien realisierbar sind.

Merkmale:

• Kusto Query Language für große Datensätze
• Echtzeitverarbeitung
• Schnelle Abfragen über strukturierte und semi-strukturierte Daten

Einsatzszenarien:

• Anwendungsüberwachung (App Insights)
• IoT-Telemetrie
• Security- und Log-Analytik

SQL Server auf Azure Virtual Machines

Wenn du vollständige Kontrolle über deine Datenbankumgebung brauchst, dann ist der SQL Server auf Azure Virtual Machines eine gute Wahl. Diese IaaS-Option bietet eine Umgebung, die deiner On-Premises-Struktur gleicht und unterstützt alle SQL Server-Features.

Merkmale:

• Vollständige Admin-Kontrolle über Betriebssystem und SQL Server
• Unterstützung aller SQL Server-Versionen
• Integration in Azure Backup, Monitor etc.

Einsatzszenarien:

• Legacy-Anwendungen
• Komplexe SQL Server-Features (SSRS, SSIS)
• Hybrid-Cloud-Szenarien

Fazit: Welche Azure-Datenbank passt zu mir?

Die Auswahl der passenden Cloud-Datenbank hängt von verschiedenen Faktoren ab. Dazu zählen zum Beispiel die Art der Anwendung, das Datenvolumen und die benötigte Geschwindigkeit. Auch Anforderungen an Sicherheit, Skalierbarkeit und Wartungsaufwand spielen eine wichtige Rolle.

Je nach Einsatzzweck bieten sich unterschiedliche Azure SQL-Datenbanklösungen an:

Anforderung	Empfehlung
Relationale Web-App	Azure SQL-Datenbank
Migration von SQL Server	SQL Managed Instance oder Azure VM
Globale NoSQL-Anwendung	Azure Cosmos DB
Open-Source Stack (PostgreSQL)	Azure-Datenbank für PostgreSQL
Analytische Workloads	Azure Synapse Analytics
Log- und Telemetriedaten	Azure Data Explorer

Ganz gleich, ob du eine Beratung brauchst oder bereits konkrete Anforderungen hast – nimm einfach Kontakt zu uns auf.

Wir von der arelium GmbH helfen dir gern.

Der Beitrag Cloud-Datenbanken – Dein Guide zu den besten Optionen in Azure erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Datengetriebene Welt

In der datengetriebenen Welt ist eine effiziente Analyse der Verkaufszahlen und auch der Lagerbestände entscheidend. Dies ist für den Unternehmenserfolg unerlässlich. Unser Kunde aus dem Handel hat mit uns eine Analyseplattform für die visuelle Aufbereitung seiner Verkaufsbestände entwickelt.

Sein Ziel bestand in der Verbesserung der Umsätze und in der Vorhersage von Nachfrageschwankungen. Gleichzeitig erreichten wir eine Optimierung der Lagerbestände.

Herausforderungen in der Verkaufs- und Lageranalyse

In den folgenden Zeilen zeige ich anhand unseres Kundenbeispiels, wie unser Einzelhändler Microsoft Fabric für Data Analytics benutzt.

Dabei steht der Unternehmer mit mehreren Filialen und einem Online-Shop vor verschiedenen Herausforderungen:

• Die zur Verfügung stehenden Daten stammen aus unterschiedlichsten Quellen: POS-Systeme, Lieferantendaten und IoT-Sensoren (zum Beispiel Temperaturmessung).
• In den meisten Fällen haben die Unternehmen eine Verzögerung bei den Bestandsupdates, die zu Engpässen oder Überbeständen führen können.
• Echtzeit-Analysen sind nicht möglich. Daher ist eine schnelle Reaktion auf Marktveränderungen nicht möglich.

Wir haben unserem Kunden Microsoft Fabric empfohlen. Damit hat er seine Probleme auf eine vernünftige Art und Weise in den Griff bekommen. Das Interessante daran ist, dass dies alles auf einer einzigen Plattform umsetzbar ist.

Betrachtung der vorhandenen Daten

Unser Einzelhändler bekommt die Daten aus den folgenden Systemen:

• Die Verkaufsdaten aus den Filialen, sowie aus dem Online-Shop werden in einer SQL-Datenbank in Azure gehalten.
• Die Lieferantendaten werden über eine SFTP-Schnittstelle als CSV-Dateien zur Verfügung gestellt.
• Die verschiedenen Temperaturdaten und Feuchtigkeitsdaten in den Lagern und Verkaufsräumen werden von IoT-Sensoren erfasst und bereitgestellt.

Datenintegration mit Microsoft Fabric

Der Einzelhändler hat die arelium GmbH um Unterstützung gebeten. Unser Team hat gemeinsam mit ihm die folgende Lösung als die für ihn Beste herausgearbeitet:

• Das Beladen mit SQL und CSV-Dateien erfolgt vollständig automatisiert mit einer Data Factory Pipeline. Dabei speichert die Pipeline die Daten in einem OneLake.
  • Eine Azure Data Factory Pipeline ist eine Pipeline mit der Daten aus verschiedenen Quellen extrahiert, transformiert und anschließend in ein Zielsystem geladen werden können (ETL/ELT). Dabei gibt es Aktivitäten wie Kopiervorgang, Datentransformation oder Skriptausführung. Trigger oder Zeitpläne können diese automatisch ausführen.
  • Ein OneLake ist ein zentrales Datenspeicher- und Managementsystem innerhalb von Microsoft Fabric, das sich wie ein „OneDrive für Daten“ verhält. Es ermöglicht die einfache Speicherung und den Zugriff auf Daten aus verschiedenen Fabric-Analyse-Services. Durch die Verwendung des optimierten Delta-Parquet-Formats kann direkt auf integrierte Analyse-Engines zugegriffen werden.
• Event Streams erfassen Sensordaten in Echtzeit und speichern diese im Lakehouse.
  • Ein Event Stream ist eine kontinuierliche Abfolge von Events (Ereignissen), die nahezu in Echtzeit erfasst, verarbeitet und analysiert werden. Diese Events aus verschiedenen Quellen stammen beispielsweise aus IoT-Sensoren, Logs oder Benutzerinteraktionen.
• Alle Komponenten sind Microsoft Fabric Bestandteile.

Datenanalyse mit Microsoft Fabric

Für die Analyse und Verarbeitung der Daten bietet es sich an, die verfügbaren Daten mittels Notebooks zu bereinigen und zu aggregieren.

Ein Notebook ist eine interaktive Umgebung zur Datenverarbeitung, die Code, Text und Visualisierungen in einer Komponente kombiniert. Dabei wird eine Vielzahl an Sprachen wie PySpark, SQL und SparkR unterstützt. Notebooks sind tief in die Fabric-Datenarchitektur integriert. Nutzer können damit große Datenmengen analysieren, Transformationen durchführen und maschinelles Lernen anwenden, indem sie direkt auf den OneLake oder andere Fabric-Dienste zugreifen.

Anschließend werden die Daten in einem Data Warehouse oder Data Lake für schnelle SQL-Abfragen zur Verfügung gestellt.

Ein Data Warehouse ist eine zentrale, für die Speicherung und Analyse großer Mengen an strukturierten Daten optimierte Datenbank. Hier werden Daten aus verschiedenen Quellen integriert. Die Inhalte können für Berichte, Analysen und Business Intelligence bereitgestellt werden. Moderne Cloud-Data-Warehouses, wie das Microsoft Fabric Data Warehouse, bieten eine skalierbare Leistung und eine perfekte nahtlose Integration.

Bei der Auswertung der Fragen ergeben sich für den Geschäftsführer die typischen Fragen wie:

• Welche Produkte werden in welcher Filiale am besten verkauft?
• Welche saisonalen Änderungen an der Produktnachfrage gibt es?
• Gibt es Lagerbedingungen, die zu Warenverlusten führen?

Bei der Beantwortung der Fragen können in Microsoft Fabric die verschiedensten Komponenten unterstützend für Data Analytics eingesetzt werden.

Nach einem intensiven Austausch mit unseren Beratern hat sich unser Kunde dazu entschieden, AutoML für die KI-gestützte Analyse der Daten zu verwenden. Dadurch ist es möglich Absatzprognosen basierend auf historischen Daten vorherzusagen.

Visualisierung und Reporting mit Power BI

Auch beim Visualisieren und beim Reporting bietet Microsoft Fabric durch die Integration von Power BI eine hervorragende Lösung. Mein Kollege Joel Galla hat in einem ausführlichen Beitrag aufgezeigt, was Power BI auszeichnet.

Fazit: Warum setze ich auf Microsoft Fabric?

Microsoft Fabric bietet dir eine hervorragende End-to-End-Lösung für die Datenanalyse. Mit Fabric kann unser Einzelhändler Auswertungen fahren. Diese ermöglichen ihm Bestellungen zu optimieren, Lagerkosten zu senken und seine Umsätze zu steigern. Dazu braucht er nicht mehr verschiedene Plattformen einzusetzen.

Falls du tiefer in das Thema Microsoft Fabric eintauchen möchtest, schau dir einfach die anderen Blog-Beiträge an, die meine Kollegen und ich für euch zur Verfügung stellen.

Sprich uns gerne direkt an. Wir bei der arelium GmbH unterstützen dich gerne bei deinen Vorhaben und Projekten.

Der Beitrag Verkaufsanalyse mit Microsoft Fabric erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

So war das mal

In meinem Studium der Wirtschaftsinformatik hatte ich den betriebswirtschaftlichen Schwerpunkt Controlling. Damals war der Lehrstuhl an der Uni Köln ganz neu. Heute kaum vorstellbar, dass es den nicht schon viel früher gegeben hat. In meinem Studium standen Ansätze wie Shareholder Value im Vordergrund. Aber natürlich war die Interne Rechnungslegung auch ein großer Teil der Vorlesungen. Es gab aber auch schon sehr viele Kennzahlen, die für den Controller interessant waren: Return on Investment, Cash Flow, … oder Economic Value Added (EVA). Gerade der letzte Ansatz ist schon sehr mathematisch. Nicht kompliziert zu berechnen, aber doch mit einer Menge an Kennzahlen, die man berechnen kann. Fast alle Kennzahlen schauen dabei in die Vergangenheit. Wurden Budgets eingehalten, stimmt die Buchhaltung, haben wir Ziele erreicht etc.

Und woher kommen die Zahlen?

Ich habe mich damals schon gefragt, wo alle die Werte herkommen sollen, die in die Formeln einfließen. Später habe ich in der Praxis gelernt, dass es die Kennzahlen überall gibt, aber diese tatsächlich oft viel Arbeit mit sich bringen. Die Arbeit besteht dann meist aus Excel, Excel und noch ein wenig Data Warehouse mit Excel. Kann man so machen. Ist aber doch sehr fehleranfällig und ein echter Zeitfresser. Ein Blick in die Zukunft fällt da meist vollkommen herunter. Dabei ist doch gerade das so wichtig. Die Vergangenheit hilft mir nicht mehr. Ich will doch vorher schon steuernd eingreifen können.

An meiner Vorgeschichte kannst du schon erkennen, wohin ein datengetriebenes Controlling gehen soll. Heute reicht es einfach nicht mehr, nur zu wissen, was letzte Woche oder letzten Monat passiert ist. Unternehmen erwarten, dass das Controlling Entwicklungen proaktiv erkennt, Zusammenhänge aufzeigt und konkrete Handlungsempfehlungen liefert. Kurz gesagt: Es geht nicht mehr nur um Berichte, sondern um Entscheidungen. Wie komme ich aber dahin?

Von der Rückschau zur Steuerung in Echtzeit

Die größte Veränderung im Controlling der letzten Jahre liegt in der Art und Weise, wie mit Daten gearbeitet wird. Statt einmal im Monat einen Report zu erstellen, geht es darum, laufend relevante Kennzahlen im Blick zu haben und die richtigen Maßnahmen frühzeitig einzuleiten. Das war schon immer die Idee vom Controlling. Nur kommt es meist nicht dazu, eben weil sich Controller mit Kennzahlen, der Aufbereitung und der Vergangenheit beschäftigen.

Datengetriebenes Controlling

Genau hier kommt das datengetriebene Controlling. Weniger manuelle Datenauswertung, mehr Automatisierung – Routinetätigkeiten werden reduziert, sodass mehr Zeit für Analysen bleibt. Von statischen Reports zu dynamischen Dashboards – anstatt lange Tabellen zu durchforsten, lassen sich Daten flexibel visualisieren. Bessere Vorhersagen statt reiner Vergangenheitsanalysen – Künstliche Intelligenz und Algorithmen helfen, Muster zu erkennen und Entwicklungen zu prognostizieren. Echtzeit-Informationen statt Monatsberichte. Am Ende können Unternehmen schneller auf Veränderungen reagieren. Das hört ich alles toll an und sollte jeden Unternehmer dazu bringen sich mit dem Thema zu beschäftigen. Nur die meisten tun sich schwer, datengetrieben zu arbeiten. Meist liegt es an den folgenden Hürden:

• Datensilos und fragmentierte Systeme
  Viele Unternehmen haben Daten in unterschiedlichen Systemen (ERP, CRM, Buchhaltung, Produktion, Lagerverwaltung). Diese Daten sind oft nicht miteinander verknüpft und erschweren eine ganzheitliche Analyse. Viele haben natürlich ein Data Warehouse, aber das ist oft nicht komplett oder übergreifend oder es fehlen einfach immer wieder wichtige Informationen.
• Mangelnde Datenqualität
  Fehlerhafte oder unvollständige Daten führen zu falschen Analysen. Häufig fehlen klare Prozesse zur Datenpflege, was den Wert der Analysen mindert.
• Komplexe IT-Infrastrukturen
  Viele Unternehmen nutzen gewachsene Systeme, die nicht flexibel genug sind, um moderne Analysemethoden zu unterstützen.
• Fehlendes Know-how und Akzeptanz im Unternehmen
  Datengetriebenes Arbeiten erfordert neue Kompetenzen – sowohl im Controlling als auch in den Fachbereichen. Oft fehlt das Wissen, wie man Daten effizient nutzt, oder die Bereitschaft, neue Tools einzusetzen.

Microsoft Fabric als Lösungsansatz

Natürlich kann ein Tool alleine hier keine Wunder wirken. Es kann aber sehr wohl dabei helfen. Du benötigst eine Plattform, die Daten aus verschiedenen Quellen zusammenführt, automatisiert verarbeitet und einfach analysierbar macht. Microsoft Fabric ist ein Lösungsansatz, der genau hier ansetzt.

Anders als klassische BI-Systeme vereint Fabric Datenintegration, Analyse, Automatisierung und KI-gestützte Prognosen in einer zentralen Umgebung. Und genau hier arbeitet es an den Hürden aus dem letzten Abschnitt.

Das bedeutet:

• Alle Daten an einem Ort: Verknüpfung von ERP, CRM, Buchhaltung, Supply Chain und weiteren Systemen.
• Echtzeit-Dashboards mit Power BI: Controlling kann aktuelle Entwicklungen jederzeit verfolgen und gezielt analysieren.
• Automatisierte Datenverarbeitung: Routineaufgaben wie die Zusammenführung und Bereinigung von Daten laufen automatisch.
• KI-gestützte Prognosen: Statt nur rückblickend zu analysieren, lassen sich Wahrscheinlichkeiten und Entwicklungen berechnen.

Mit einem datengetriebenen Ansatz kann dein Unternehmen:

• Daten aus Einkauf, Lager und Produktion in Echtzeit zusammenführen.
• Preisentwicklungen analysieren und Muster erkennen.
• Prognosen für zukünftige Kostensteigerungen erhalten.
• Frühzeitig alternative Lieferanten oder Einsparpotenziale identifizieren.

Durch den Einsatz von Fabric lassen sich diese Schritte automatisieren und visuell in Power BI-Dashboards darstellen, sodass die Unternehmenssteuerung nicht im Nachgang reagieren muss, sondern vorausschauend handeln kann.

Fazit oder warum datengetriebenes Controlling die Zukunft ist

Datengetriebenes Controlling ist mehr als nur eine technische Veränderung – es bedeutet einen neuen Anspruch an die Steuerung von Unternehmen. Statt nur Zahlen aufzubereiten, geht es darum, Entscheidungen aktiv zu unterstützen.

Wer sich heute mit echtzeitfähigen, integrierten und KI-gestützten Lösungen auseinandersetzt, kann schneller auf Veränderungen reagieren und sich einen klaren Wettbewerbsvorteil verschaffen.

Der Wandel ist nicht immer einfach – aber die Frage ist nicht, ob datengetriebenes Controlling kommt, sondern wann Unternehmen sich darauf einstellen.

Um nochmal auf mein Studium zurückzukommen: So habe ich mir das damals vorgestellt. Die vielen blumigen Worte unseres Professors zum Controlling („Der Steuermann im Wind“ oder „Ohne Controller kein Neugeschäft“) ergeben mit datengetriebenem Controlling viel mehr Sinn. Ich wünschte mir das wäre schon damals ein großer Bestandteil vom Controlling gewesen und ich wäre vielleicht in dem Bereich geblieben und hätte nicht doch wieder in die IT gewechselt.

Der Beitrag Datengetriebenes Controlling erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Viele benutzen bereits Azure SQL Datenbanken und fragen sich: „Warum sollte ich eine SQL Datenbank in Fabric nutzen?“ Aber die meisten verstehen garnicht, dass es die falsche Frage ist. Azure SQL vs Fabric SQL gibt es nicht, denn beide sind das exakt selbe. Das entscheidende ist nicht die Technologie, sondern die Umgebung.

Um das zu verstehen, muss klar sein, dass eine SQL Datenbank in Fabric nicht in Fabric liegt. Wie im Bild zu sehen ist die SQL Datenbank in Fabric nur eine Azure SQL Datenbank welche in Echtzeit in den OneLake und damit Fabric gespiegelt wird. Die Technologie ist die gleich, wie beim Spiegeln einer schon existierenden Datenbank. Nur weil die Technik dieselbe ist, ist das Ergebnis nicht dasselbe.

Azure SQL vs Fabric SQL – Ein Kostenvergleich

Der erste Unterschied sind sie Kosten. Azure SQL Datenbanken kosten im laufenden Betrieb und die Datenmengen werden ebenfalls abgerechnet. Datenbanken in Fabric kosten ebenfalls eine Kleinigkeit für den Speicher, aber nichts im Betrieb. Es entstehen keine Zusatzkosten und alles ist mit den Fabric Lizenzen abgedeckt. Klingt nach einem eindeutigen Gewinner, oder? Falsch.

Der wichtigste Unterschied sind nicht die Kosten. Dafür musst du verstehen, wofür beide Datenbanken gedacht sind. Eine Azure SQl Datenbank kann überall eingesetzt werden. Eine Fabric Datenbank kann das auch, sollte es aber nicht. Azure ist viel weit laufender als Fabric. Eine Webapp sollte keine Fabric Datenbank nutzen, aber eine Azure SQL Datenbank ist genau das Richtige.

Microsoft Fabric ist eine Datenverarbeitungs- und Analyseplattform. Wenn Unternehmensdaten in einer gemeinsamen Plattform verarbeitet und verwaltet werden sollen, dann ist Fabric das Mittel der Wahl. Die SQL Datenbank in Fabric ist dann optimal. Alle Daten sind sauber, zentral und kostengünstig vereint. Das heißt nicht, dass eine Azure SQL Datenbank das nicht auch kann, aber die Fabric Datenbank ist hier überlegen. Eine Azure Datenbank kann immer noch in Fabric gespiegelt werden.

Vorteile einer Fabric SQL Datenbank

Wenn das Ziel Fabric ist, dann hat es noch einen weiteren Vorteil, die Datenbank direkt in Fabric anzulegen. Eine Azure SQL Datenbank hat eigene Rollen- und Sicherheitskonzepte. Diese Regeln werden auf dem Server eingerichtet und zusätzlich werden die Fabric Regeln angewendet. Aber wenn die Datenbank in Fabric angelegt wird, dann können alle Regeln in Fabric verwaltet werden. Es greifen immer noch die Microsoft Fabric Regeln, aber zusätzlich können die gleichen Regeln wie in Azure SQL eingerichtet werden. Aber das ist nicht das beste Feature.

Eine Fabric SQL Datenbank kann noch mehr. Die zugrundeliegende Technik ist dieselbe, aber die Einbindung ist es nicht. Mit der Einbindung meine ich, dass z.B. automatisch ein semantisches Modell erstellt werden kann, welches auch direkt in einem Power BI Bericht endet. Das Gleiche gilt für den Analyseendpunkt. Damit ist eine Fabric SQL Datenbank vollständig in Fabric integriert.

Hier Whitepaper downloaden

Name *

Email *

*Mit dem Download dieser Datei, stimmen Sie zu, den arelium Newsletter zu erhalten. Sie können die Newsletter jedezeit wieder abbestellen.

Übersichtstabelle

Azure	Fabric
Verwendbar für Alles	Spezialisiert für Datenauswertung
Es wird Azure benötigt	Es wird Azure und Fabric benötigt
Kosten für Speicher und Erreichbarkeit	Nur Kosten für zusätzlichen OneLake Speicherplatz

Falls du dich generell für das Thema Azure und Fabric interessierst, haben wir das Thema in einem YouTube Video behandelt. In diesem Video reden wir über die Unterschiede von Azure Synapse Analytics und Microsoft Fabric. In anderen Blogbeiträgen haben wir auch über die unterschiedlichen Kosten von Synapse und Fabric geschrieben.

Der Beitrag Azure SQL vs Fabric SQL erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Einführung in Azure Databricks

Azure Databricks ist eine leistungsstarke Cloud-basierte Datenanalyse- und KI-Plattform, die auf Apache Spark basiert und in Zusammenarbeit von Microsoft und Databricks entwickelt wurde. Die Plattform richtet sich an Unternehmen, die große Datenmengen effizient verarbeiten und maschinelles Lernen einsetzen wollen. Als Teil der Azure Cloud ist Databricks nahtlos in Dienste wie Azure Data Lake Storage, Azure Synapse Analytics und Power BI integriert. Vor allem der Data Engineering- bzw. der Data Science-Part sind sehr gut in Databricks implementiert.

Databricks Home Bildschirm

Kostenstruktur von Azure Databricks

Wie bei jedem Tool, spielen die Kosten eine große Rolle bei der Technologieauswahl. Die Kosten von Azure Databricks setzen sich aus mehreren Faktoren zusammen, wobei die wichtigsten Komponenten die Virtuellen Maschinen (VMs), die Databricks Units (DBUs) und der Cluster-Typ sind. Auch die Wahl des Arbeitsbereichs (Standard, Premium, Enterprise) beeinflusst die Gesamtkosten. Schauen wir uns die einzelnen Posten etwas genauer an.

Kostenübersicht Databricks Workspace

Über einen Zeitraum von 3 Monaten mit sehr sporadischer Nutzung

Virtuelle Maschinen (VMs)

Virtuelle Maschinen (VMs) stellen die Rechenressourcen bereit, die für das Ausführen von Databricks-Clustern erforderlich sind. Bei der Erstellung eines Clusters wird eine oder mehrere VMs für die Ausführung des Clusters benötigt.

• Preis pro VM-Stunde: Der Preis variiert je nach VM-Typ und Region, in der der Cluster ausgeführt ist. Azure bietet eine Vielzahl von VM-Typen, darunter Standard DS3 v2, Standard D4s v3, Standard F2s, etc. Der Preis für eine VM hängt von ihrer Größe und ihrer Region ab.
• Abrechnungseinheit der VM-Stunden: Ein VM-Cluster rechnet auf Stundenbasis ab, wobei der Preis je nach Größe und Art der VM variiert.
• Regionale Unterschiede: Die Kosten können in verschiedenen Azure-Regionen unterschiedlich sein. Einige Regionen bieten günstigere Preise, während andere aufgrund von Nachfrage oder zusätzlichen Dienstleistungen teurer sein können.

Databricks Units (DBUs)

Eine Databricks Unit (DBU) ist eine Abrechnungseinheit für Rechenressourcen, die in Azure Databricks verwendet werden. DBUs messen die Leistung von Databricks-Clustern in Bezug auf den Verbrauch von Rechenressourcen.
DBUs werden auf Stundenbasis berechnet, basierend auf der Art des Clusters und dessen Nutzung.

Standard-Cluster: Diese Cluster sind für allgemeine Anwendungen und Datenverarbeitungsaufgaben gedacht. Der Preis liegt in der Regel bei etwa 0,20 USD pro DBU pro Stunde.

Premium-Cluster: Diese Cluster bieten erweiterte Funktionen wie bessere Sicherheitskontrollen und höherwertige Rechenressourcen. Der Preis für Premium-Cluster liegt normalerweise bei 0,40 USD pro DBU pro Stunde.

DBUs werden auf der Grundlage der Größe und Art des Clusters berechnet. Ein größeres Cluster oder ein Cluster mit mehr Rechenressourcen verbraucht mehr DBUs.

Cluster-Typen und Größe

Die Art und Größe des Clusters, dass du verwendest, beeinflusst direkt die Kosten. Azure Databricks bietet verschiedene Cluster-Typen:

Standard-Cluster: Diese Cluster bieten eine gute Leistung zu einem günstigeren Preis und eignen sich gut für allgemeine Workloads.

Premium-Cluster: Diese Cluster bieten zusätzliche Sicherheitsfunktionen, wie z. B. das Verschlüsseln von Daten im Speicher und erweiterte Netzwerksicherheitsfunktionen.

High-Concurrency Clusters: Diese Cluster sind für den gleichzeitigen Zugriff durch mehrere Benutzer oder Prozesse optimiert. Sie werden häufig in produktiven Umgebungen eingesetzt, wenn mehrere Benutzer gleichzeitig auf dieselben Daten zugreifen müssen.

Menü zur Cluster Erstellung in Databricks

Workspaces

Azure Databricks bietet verschiedene Arbeitsbereichsoptionen, welche unterschiedliche Preise und Funktionen mit sich bringen.

Standard-Arbeitsbereich: Dies ist der Basistarif und ist für viele Benutzer ausreichend. Die Kosten in einem Standard-Arbeitsbereich sind die niedrigsten.

Premium-Arbeitsbereich: Premium-Arbeitsbereiche bieten erweiterte Funktionen wie bessere Sicherheitskontrollen, API-Zugriff und mehr.

Enterprise-Arbeitsbereich: Dieser Bereich richtet sich an Unternehmen, die große und komplexe Datenumgebungen verwalten und skalierbare Datenlösungen benötigen. Der Enterprise-Arbeitsbereich bietet die vollständige Palette von Funktionen und Sicherheitsoptionen, ist jedoch auch teurer.

Automatisierte Jobs und Workflows

Azure Databricks ermöglicht es dir, automatisierte Jobs für Datenverarbeitungsaufgaben zu erstellen. Man kann festlegen, wie oft der Job ausführt, welche Ressourcen man dafür benötigt.

Jobs, die regelmäßig ausgeführt werden (z. B. täglich oder wöchentlich), verursachen zusätzliche Kosten, da sie Cluster und DBUs verbrauchen. Diese Kosten sind jedoch abhängig von der Häufigkeit der Ausführung und der Größe der genutzten Ressourcen.

Speicher

Azure Databricks verwendet standardmäßig das Databricks File System (DBFS), ein verteiltes Dateisystem. Dieses nutzt man für die Speicherung von Daten und Dateien in Databricks. Daten, die in DBFS gespeichert werden, werden im Azure Blob Storage oder Azure Data Lake Storage abgelegt. Die Kosten für diese Speicherlösungen hängen vom verwendeten Speichertyp und der Speicherregion ab.

Sowohl der Azure Blob Storage als auch der Azure Data Lake Storage bieten günstige Optionen für die Speicherung von Daten, wobei die Kosten je nach Speichermenge und Zugriffsfrequenz variieren. Dieser Punkt sollte nicht vernachlässigt werden. Bei einer hohen Anzahl von Datenanforderungen aus dem Speicher (z. B. beim Trainieren von Modellen) entstehen höhere Kosten. Grund dafür ist, in welchem Segment die Daten in der Cloud gespeichert werden (Hot, Cold, Archive).

Netzwerkkosten

Wenn man Azure Databricks mit anderen Azure-Diensten wie Azure SQL Database, Azure Data Lake Storage oder Azure Synapse Analytics integriert, können Netzwerkkosten entstehen, die auf den Datentransfer und die Datenübertragung zwischen den Diensten zurückzuführen sind. So ist ein Thema dabei die Datenübertragungsgebühren. Es fallen Kosten für den Datentransfer zwischen verschiedenen Azure-Diensten oder über das Internet an. Diese Gebühren sind abhängig von der Menge an übertragenen Daten und der Region, in der die Daten verarbeitet werden.

Überwachung und Logging

Das Überwachen und Protokollieren von Aktivitäten in Databricks kann zusätzliche Kosten verursachen, insbesondere wenn umfangreiche Logs gespeichert oder wenn externe Überwachungsdienste (z. B. Azure Monitor) verwendet werden.

Automatisiertes Machine Learning

Azure Databricks bietet auch AutoML-Funktionen für die Automatisierung des Trainings von Machine-Learning-Modellen (mehr dazu später im Artikel). Die Nutzung dieser Funktionen kann zusätzliche Rechenressourcen (z. B. Cluster) beanspruchen, was die Kosten erhöht.

Menü vom AutoML in Databricks

Beispiel für ein Klassifizierungsproblem

Es gibt einige Kniffe, mit denen man Kosten sparen kann. Ein Beispiel dazu:

Wenn es ein Data-Team gibt, was in einem gemeinsamen Databricks Workspace arbeitet, können mehrere Personen ein und dasselbe Compute-Cluster nutzen. Somit kann man mit einer geschickten Cluster-Allokation, die Kosten an der Stelle reduzieren.

Hauptmerkmale von Azure Databricks

Azure Databricks bietet eine Vielzahl leistungsstarker Funktionen für die Verarbeitung großer Datenmengen und die Entwicklung von Machine-Learning-Modellen.

Im folgendem gehen wir auf die Hauptmerkmale von Databricks ein. Hier geht es vor allem um:

• Machine Learning
• Datenverwaltung
• Unity Catalog Metastore
• Databricks Genie
• Zugriffssteuerung

Ein Punkt, der zwar schnell abgehakt werden kann, jedoch eine Erwähnung verdient, ist die kollaborative Notebookumgebung. Sie erlaubt die direkte Ausführung von Code in Python, Scala, R und SQL. Im Hintergrund liegt eine auf Apache Spark basierende Engine, die eine verteilte Verarbeitung großer Datenmengen ermöglicht.

Machine Learning und Modelbereitstellung

Modellentwicklung

In Databricks gibt es zwei Möglichkeiten, ein Modell zu entwickeln. Die manuelle und die automatische. Bei der manuellen Entwicklung geht es darum, ein Machine-Learning-Modell mit Code zu trainieren. Welche Programmiersprache man dafür nutzt, ist de Engine egal. Dabei bleiben alle Komponenten eines ML-Laufs an einem selbst hängen. Das bedeutet: Standardisierung/Normalisierung, Skalierung, Kodierung, Hyperparameter Tuning etc. Ohne fundierte Kenntnisse auf diesem Gebiet ist es sehr schwierig, diesen Prozess manuell durchzuführen.

Die automatische Variante hingegen, das Automated Machine Learning (AutoML), ist ein Prozess, der die Modellentwicklung erheblich vereinfacht. Wie der Name schon sagt, wird einem hier viel Arbeit abgenommen. Alle manuellen Schritte werden beim AutoML durch automatische Schritte ersetzt. Diese Funktion ist ähnlich wie AutoML im Azure Machine Learning Studio. Wichtig zu erwähnen ist, dass der wichtigste Schritt, um ein gutes Modell zu erhalten, nicht von AutoML übernommen wird. Nämlich Daten von extrem hoher Qualität zu haben. Der Data Engineering Prozess davor muss also stattfinden, sonst gibt es im schlimmsten Fall Verzerrungen in den Ergebnissen, die das Modell am Ende ausspuckt.

Modellbereitstellung

Nach dem Training können Modelle über REST-APIs als Endpunkte zur Verfügung gestellt werden. (Wie oben bereits erwähnt, entstehen für ein bereitgestelltes Modell Kosten). Das Bereitstellen ermöglicht eine einfache Integration von Maschine-Learning-basierten Vorhersagen in externe Anwendungen und Echtzeitsysteme. Der Zugriff auf die Modelle erfolgt über normale Requests. Man benötigt lediglich den Access Token, welchen man in Databricks als Workspace Admin konfigurieren kann.

Datenverwaltung in Azure Databricks

Das Databricks File System (DBFS) ist ein zentrales Speichersystem innerhalb von Azure Databricks, das speziell für den Umgang mit großen Datenmengen und die nahtlose Integration mit Apache Spark entwickelt wurde. DBFS dient als verteiltes Dateisystem und ermöglicht den Zugriff auf Dateien und Verzeichnisse innerhalb von Databricks-Notebooks, Jobs und Clustern. Es wird typischerweise verwendet, um Daten zu speichern und zu organisieren, die in Apache Spark verarbeitet werden sollen. Das DBFS ist sehr umfangreich und einer der wichtigsten Bestandteile von Databricks. Von daher gehen wir hier etwas intensiver drauf ein.

Zugriffsarten und Speicherorte

DBFS stellt ein vereinfachtes Abstraktionsmodell für den Zugriff auf Dateien zur Verfügung. Es ermöglicht den Zugriff auf Dateien über Pfade, ähnlich wie bei herkömmlichen Dateisystemen. Beispielsweise kann eine Datei unter /dbfs/tmp/datei.csv abgelegt und von einem Notebook aus genutzt werden.

Obwohl DBFS intern in Azure Databricks verwendet wird, können Dateien auch im Azure Blob Storage oder Azure Data Lake Storage gespeichert werden. DBFS bietet einen abstrahierten Zugang zu diesen Speichern. Tatsächlich ist DBFS nicht nur eine eigene physische Speicherlösung, sondern ein Layer über Cloud-Speicher. Dies bedeutet, dass im Hintergrund immer ein Speicherkonto liegt. Ob es ein Blob Storage oder ein Data Lake Storage sind, spielt dabei keine Rolle.

Managed vs. Unmanaged (External) Tables

Beginnen wir mit den Managed Tables. Wenn Daten in DBFS gespeichert werden und als Managed Tables verwendet werden, werden sowohl die Daten als auch die Metadaten vom Databricks-System verwaltet. Das bedeutet, dass beim Löschen der Tabelle sowohl die Daten als auch die Metadaten aus dem System entfernt werden.

Wenn Daten aus externen Quellen wie Azure Data Lake Storage (ADLS) oder Azure Blob Storage in DBFS eingebunden werden, bleiben die Daten an ihrem Ursprungsort gespeichert, und Databricks verwaltet nur die Metadaten. Dies bedeutet im Umkehrschluss: Beim Löschen einer Tabelle werden die Metadaten gelöscht, jedoch nicht die Daten, welche extern gespeichert werden.

Für die Anwender bedeutet das im Umkehrschluss, dass man bei jeder Tabelle abwägen sollte: Sollen meine Daten unter keinen Umständen gelöscht werden? Dann wählt man eine external Table. Hat man irgendwelche temporäre Tabellen, die nicht so wichtig sind, kann man auch Managed Tables wählen.

Lesen, Schreiben und Verwalten von Dateien

DBFS erlaubt den einfachen Zugriff auf Dateien, die in Notebooks verarbeitet werden. Dateien können über Python, Scala oder SQL-Befehle gelesen und geschrieben werden. Mit dem dbutils-Toolkit können Benutzer direkt mit DBFS interagieren, um Dateien zu erstellen, zu löschen oder zu verschieben. (Zum Beispiel können Dateien in DBFS mit Spark-API oder Python-Methoden wie dbutils.fs.cp(), dbutils.fs.rm(), und dbutils.fs.mv() verwaltet werden.) Dies ist besonders nützlich in Automatisierungsszenarien und für das Management von Daten innerhalb von Databricks-Notebooks.

Verwendung von DBFS für Datenverarbeitung und Persistenz

DBFS wird häufig als temporärer Speicherort für Daten in Spark-Anwendungen verwendet. Es kann auch verwendet werden, um große Mengen an Zwischen- und Endergebnissen von bspw. Machine-Learning-Modellen oder Analyseprozessen zu speichern. Aufgrund der Integration von Delta Lake kann DBFS auch als Speicherort für Delta-Tabellen genutzt werden, die ACID-Transaktionen und Zeitreisen unterstützen.

Der Unity Catalog Metastore

Der Unity Catalog ist eine der zentralen Komponenten des Datenmanagements. Dort werden die die Metadaten über Tabellen, Schemata und Berechtigungen verwaltet. Der Metastore ermöglicht eine zentrale Steuerung von Datenzugriffsrechten und Policies, was insbesondere in komplexen Datenlandschaften von Vorteil ist.

Um einen Metastore in Azure Databricks einzurichten, benötigt man sehr hohe Berechtigungen innerhalb der Azure und Databricks Landschaft. Man muss Workspace Admin in Databricks und Super (Global) Admin in Azure sein. Wenn man diese Berechtigungen besitzt, kann man zunächst einen Azure Data Lake Storage Gen2 Account anlegen. Innerhalb dieses Storage wird ein Container als zentraler Datenspeicher definiert. Nach der Einrichtung der entsprechenden Zugriffsrechte über eine Managed Identity oder einen Service Principal wird der Metastore im Azure Databricks Account Portal angelegt und mit den gewünschten Workspaces verknüpft. Dies bedeutet: Die Daten des Unity Catalog werden nicht innerhalb von Databricks, sondern extern gespeichert! Somit kann man die Zugriffsberechtigung zusätzlich über Azure steuern.

Genie: Natürliche Sprachverarbeitung für Datenanalysen

Ein weiteres innovatives Feature von Azure Databricks ist Genie, eine KI-basierte, codefreie Schnittstelle für die Datenanalyse. Fachanwender können Datenabfragen in natürlicher Sprache stellen, die von Genie in SQL-Abfragen umgewandelt werden.

Genie unterstützt nicht nur einfache Abfragen, sondern ermöglicht auch die Erstellung komplexer Visualisierungen und Berichte direkt aus den Daten. Darüber hinaus können Fachexperten sogenannte Trusted Assets erstellen, d.h. geprüfte, vordefinierte Abfragen, um die Konsistenz der Ergebnisse sicherzustellen. Dies spielt vor allem für große Unternehmen eine Rolle, die ein One-Reporting einführen wollen.

Grundsätzlich ist Genie also ein Chatbot, welcher uns Auskunft über unsere eigenen Daten gibt.

Fehlermeldung bei Benutzung von Genie

Um Genie nutzen zu können, muss der Unity Catalog aktiviert sein

Zugriffssteuerung

Der Zugriff auf Azure Databricks ist gut strukturiert und basiert auf verschiedenen Sicherheits- und Berechtigungsebenen. Diese Ebene der Kontrolle gewährleistet, dass nur autorisierte Benutzer auf Ressourcen zugreifen können, und ermöglicht eine feingranulare Verwaltung von Berechtigungen. Der Zugriff in Azure Databricks wird in mehreren Bereichen geregelt. Da dies ein wichtiger Punkt der Datensicherheit ist, gehen wir auf die Zugriffssteuerung intensiver ein.

Azure Active Directory (Entra ID) Integration

Azure Databricks ist vollständig in Microsoft Entra ID, ehemals Azure Active Directory (AAD) integriert, was bedeutet, dass die Benutzeridentität und -authentifizierung durch Entra verwaltet werden. Benutzer müssen sich mit ihren Entra-Konten anmelden, um auf Databricks-Arbeitsbereiche zuzugreifen. Dies bietet eine zentrale Möglichkeit zur Verwaltung von Identitäten und zur Durchsetzung von Sicherheitsrichtlinien.

Durch die Entra Integration können Unternehmen dann Single Sign-On (SSO) oder auch Benutzer- und Gruppenzugriffsverwaltung benutzen. Somit ist die Authentifizierung vereinfacht.

Zugriffssteuerung auf Arbeitsbereiche

Der Zugriff auf Azure Databricks ist in Arbeitsbereichen (Workspaces) organisiert. Arbeitsbereiche sind die primären Container, in denen alle Databricks-Ressourcen wie Notebooks, Cluster, Jobs und Daten gespeichert sind.

Arbeitsbereichsrollen

Innerhalb eines Arbeitsbereichs gibt es verschiedene Berechtigungsstufen, die man auf Benutzer oder Gruppen anwenden kann:

Admin: Benutzer mit Administratorrechten haben vollständigen Zugriff auf alle Funktionen im Arbeitsbereich, einschließlich der Möglichkeit, Benutzer hinzuzufügen oder zu entfernen und Berechtigungen zu ändern.

Member: Mitglieder können Notebooks, Cluster und Jobs erstellen und verwalten, aber keine administrativen Aufgaben durchführen.

Viewer: Benutzer mit Viewer-Rechten können nur Notebooks und Dashboards anzeigen, aber keine Änderungen vornehmen.

Arbeitsbereichs-ACLs (Access Control Lists)

Access Contol Lists ermöglichen die feingranulare Steuerung von Berechtigungen auf Ressourcen wie Notebooks, Bibliotheken, Clustern und Jobs. ACLs sind ähnlich zu Gruppen, welche man in Azure anlegen kann.

Unity Catalog für feingranulare Berechtigungen

Wie oben bereits beschrieben, ist der Unity Catalog eine zentralisierte Metadatenverwaltung für Databricks. Man verwendet diese insbesondere für den Zugriff auf Daten und Datenressourcen. Er ermöglicht eine präzise Steuerung des Zugriffs auf Daten auf der Ebene von Tabellen, Schemata und Datenbanken. Unity Catalog unterstützt die Verwaltung von Berechtigungen für Datenressourcen und Rollenbasierte Zugriffskontrollen.

• Datenressourcen: Benutzer können detaillierte Zugriffssteuerungen auf Tabellen, Datenbanken und andere Datenressourcen definieren.
• Rollenbasierte Zugriffskontrolle (RBAC): Unity Catalog nutzt RBAC, um den Zugriff auf Daten basierend auf Benutzerrollen zu steuern. Es können Rollen für Administratoren, Data Scientists, Data Engineers und andere definiert werden, um genau festzulegen, wer welche Daten sehen und bearbeiten darf.

Cluster- und Notebook-Berechtigungen

Databricks bietet die Möglichkeit, Berechtigungen auf einzelne Notebooks zu setzen. Benutzer können ein Notebook zum Lesen, Schreiben oder Bearbeiten freigeben. Dies hilft, die Zusammenarbeit zu erleichtern und gleichzeitig den Zugriff auf sensible Daten zu steuern.

Auch für Cluster gibt es detaillierte Berechtigungen. Benutzer können Cluster erstellen, starten oder stoppen, je nach den ihnen zugewiesenen Rechten. Die Berechtigungen werden auf Benutzer- oder Gruppenbasis gewährt.

Beispiel für Berechtgungsvergabe in Databricks

Hier wird gleich ein ganzer Ordner zur Berechtigung freigegeben

Datenzugriffsrichtlinien und Verschlüsselung

Alle Daten, die in Azure Databricks gespeichert und verarbeitet werden, sind standardmäßig verschlüsselt. Dies umfasst sowohl die Daten im ruhenden Zustand als auch die Daten während der Übertragung. Somit sind die hohen Sicherheitsstandards die Microsoft bietet, auch hier gegeben.

Zugriff auf Databricks kann zusätzlich auf Netzwerkebene durch Virtual Networks (VNets) und Network Security Groups (NSGs) eingeschränkt werden. Dies bedeutet, dass der Zugang zu Databricks von bestimmten IP-Adressen oder Subnetzen aus erfolgen kann.

Audit Logs und Überwachung

Azure Databricks stellt umfassende Audit Logs bereit, die es Administratoren ermöglichen, den Zugriff und die Nutzung von Ressourcen innerhalb der Plattform zu überwachen. Wie im Abschnitt Kosten schon erwähnt, umfassen diese Logs Informationen zu Benutzeranmeldungen, Ressourcenzugriffen und Änderungen an Databricks-Ressourcen.

API- und Programmzugriff

Azure Databricks bietet umfangreiche REST APIs, die es ermöglichen, Programme zu integrieren und Databricks-Operationen wie das Erstellen von Clustern, das Starten von Jobs oder das Hochladen von Dateien automatisch auszuführen. Die API-Authentifizierung erfolgt über ein Personal Access Token (PAT), der für jede API-Anforderung erforderlich ist.

Für automatisierte Prozesse und Integrationen empfiehlt es sich, Service Principals oder Managed Identities zu verwenden, um den Zugriff auf Databricks-Ressourcen zu steuern, ohne dass Benutzeranmeldeinformationen erforderlich sind.

Fazit: Ist Azure Databricks die richtige Wahl?

Zusätzlich zu den oben genannten Features gibt es noch viele weitere, die hier keine Nennung finden. Bspw. das automatische Cluster-Management, welches die Rechenleistung dynamisch an die aktuelle Datenlast anpasst, was sowohl die Effizienz als auch die Kostenkontrolle verbessert. Als Überblick reicht dieser Artikel jedoch erstmal aus.

Zusammenfassend kann man sagen, dass Azure Databricks eine leistungsstarke Plattform für datengetriebene Unternehmen ist, die Big Data Processing, Machine Learning und komplexe Datenanalysen auf einer zentralen Plattform vereinen möchten. Die Integration von Delta Lake, AutoML und Unity Catalog sorgt für Effizienz und Skalierbarkeit.

Für größere Unternehmen mit komplexen Datenlandschaften bietet die Plattform durch ihre Flexibilität und Rechenleistung viele Vorteile. Kleinere Unternehmen oder Projekte mit geringem Datenvolumen sollten jedoch die Kostenstruktur genau prüfen, um sicherzustellen, dass die Plattform den eigenen Anforderungen entspricht.

Falls Sie Hilfe bei der Implementierung in Databricks oder bei der Technologieauswahl haben, kontaktieren Sie uns gerne.

Der Beitrag Azure Databricks erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.