Architektur Archive - arelium - Wir holen mehr aus deinen Daten

Unit Testing in C#: Sauberer Code langfristig sichern

Thomas Sobizack — Mon, 08 Dec 2025 10:00:54 +0000

Unit-Testing in C#: Die oft unterschätzte Art und Weise, langfristig sauberen Code zu garantieren

Warum eigentlich testen?

Chaos ohne Unit Tests

Hast du schon einmal ein Softwareprojekt übernommen, bei dem du Angst hattest, überhaupt eine einzige Zeile zu ändern? Einfach, weil du nicht wusstest, welche Kettenreaktionen diese Änderung auslösen könnte? Genau hier setzt Unit Testing an. Es ist nicht nur ein Werkzeug, sondern eine Denkweise.

Viele Entwickler sehen Tests leider immer noch als lästige Zusatzarbeit. Etwas, das man „macht, wenn Zeit übrig ist“. Aber genau diese Einstellung sorgt dafür, dass Projekte langfristig instabil werden und Entwickler immer unsicherer Änderungen vornehmen.

Dabei ist Unit Testing keineswegs nur für riesige Enterprise-Projekte relevant. Auch in kleinen C#-Anwendungen kann es den Unterschied machen zwischen „Wir können das Feature morgen ausrollen“ und „Wir brauchen erstmal drei Wochen, um sicher zu sein, dass nichts kaputtgeht“.

Was ist Unit Testing überhaupt?

Unit Testing bedeutet, dass du kleinste, isolierte Einheiten deiner Anwendung, meist einzelne Methoden oder Klassen, automatisiert testest. Das Ziel ist, dass jeder Teil deines Codes vorhersagbar funktioniert und Änderungen nicht unbemerkt zu Fehlern führen.

Bei der Verwendung von Unit Tests mit C# werden oft Frameworks wie xUnit, NUnit oder MSTest verwendet. Diese Tools bieten dir die Möglichkeit, Testmethoden zu definieren, die automatisch ausgeführt werden.

Warum ist Unit Testing in C# so wichtig?

Viele Entwickler unterschätzen den Wert von Tests, weil der Nutzen nicht sofort sichtbar ist. Aber die Vorteile summieren sich über die Lebenszeit eines Projekts:

Schnelles Feedback: Du merkst sofort, ob dein Code funktioniert.
Weniger Angst vor Änderungen: Refactorings werden entspannter.
Dokumentation durch Tests: Tests zeigen, wie eine Methode gedacht ist zu funktionieren.
Bessere Architektur: Unit Testing zwingt dich zu lose gekoppeltem Code.

Gerade in größeren Projekten mit mehreren Entwicklern ist Unit Testing wie ein Sicherheitsnetz.

Best Practices für Unit Testing in C#

1. Teste nur eine Sache pro Test

Ein häufiger Fehler ist, zu viel in einen einzelnen Test zu packen. Ein Test sollte klar beantworten: „Funktioniert diese eine Sache wie erwartet?“ So kannst du später leicht herausfinden, welcher Teil deiner Anwendung fehlschlägt.

Best Practices for Unit Testing

2. Nutze aussagekräftige Namen

Ein Testname sollte beschreiben, was geprüft wird und unter welchen Bedingungen. Beispiel:

CalculateDiscount_ShouldReturnZero_WhenCustomerIsInactive()

Damit ist sofort klar, was passiert.

3. Isoliere externe Abhängigkeiten

Unit Tests sollten nicht von Datenbanken, APIs oder Dateisystemen abhängen.
Nutze Mocking-Frameworks wie Moq,
um Abhängigkeiten zu simulieren:

csharp:var repoMock = new Mock(); repoMock.Setup(r => r.GetCustomer(It.IsAny())) .Returns(new Customer { IsActive = false });

var service = new DiscountService(repoMock.Object);
var discount = service.CalculateDiscount(123);

Assert.Equal(0, discount);

Unit Testing als Teil einer sauberen Codekultur

Ein guter Test-Ansatz sorgt nicht nur dafür, dass Fehler früh erkannt werden – er verbessert auch deine Codequalität. Denn: Wenn dein Code schwer zu testen ist, ist er wahrscheinlich zu komplex oder zu stark gekoppelt. Unit Testing ist also auch ein Werkzeug zur Selbstkontrolle.

Häufige Fallstricke

Auch wenn Unit Testing einfach klingt, gibt es einige typische Fehler:

Zu viele Integrationstests statt Unit Tests: Integration ist wichtig, aber Unit Tests sind schneller und isolierter.
Tests schreiben, die nie fehlschlagen: Wenn ein Test nicht sinnvoll prüft, ist er wertlos.
Tests nicht pflegen: Veraltete Tests sind schlimmer als keine Tests, weil sie falsche Sicherheit geben.
Test Coverage als Selbstzweck: 100% Coverage heißt nicht automatisch, dass alles sinnvoll getestet ist.

Unit Testing im Team verankern

Unit Testing im Team implementieren

Damit Unit Testing wirklich Wirkung entfaltet, muss es Teil des Entwicklungsprozesses sein – nicht nur „optional“. Hier ein praktischer Ablauf, der sich bewährt hat:

Tests vor dem Code schreiben (TDD – Test Driven Development) für kritische Logik.
Pull Requests nur mit erfolgreichen Tests mergen.
Automatisierte Tests in der Build-Pipeline (z. B. über Azure DevOps oder GitHub Actions).
Regelmäßige Test-Reviews im Team.

Fazit – Sauberer Code bleibt kein Zufall

Abschließend lässt sich sagen: Unit Testing ist nicht nur ein technisches Werkzeug, sondern ein Mindset.

Es sorgt dafür, dass du langfristig Vertrauen in deinen Code hast, egal, wie groß oder komplex dein Projekt wird.

Für eine detaillierte Anleitung und Best Practices kannst du dich jederzeit an uns wenden. Wir bei der arelium GmbH verfügen über ein fundiertes Wissen und helfen dir gerne. Nimm doch einfach mal unverbindlcih Kontakt zu uns auf!!

Der Beitrag Unit Testing in C#: Sauberer Code langfristig sichern erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Cloud-Datenbanken – Dein Guide zu den besten Optionen in Azure

Thomas Sobizack — Fri, 16 May 2025 09:47:17 +0000

Azure-Datenbanken

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:

Es gibt ganz viele Datenbank-Typen in Microsoft Azure!

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

Microsoft Azure Datenbank

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?

Welche Azure Datenbank soll ich nehmen?

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.

Semantisches Modell in Microsoft Fabric

Martin Kopp — Thu, 13 Feb 2025 10:54:39 +0000

Das Semantische Modell in Microsoft Fabric kommt immer wieder zur Sprache, wenn du dich mit Microsoft Fabric beschäftigst. Aber was ist das überhaupt? Ich bringe ein wenig Licht in die „dunkle semantische“ Welt.

Stell dir vor, du hast riesige Mengen an Daten, die aus verschiedenen Quellen kommen – aus verschiedenen Abteilungen, Systemen oder externen Datenquellen. Diese Daten liegen oft in verschiedenen Formaten vor, in verschiedenen Tabellen und Datenbanken, und es ist nicht immer klar, wie sie miteinander zusammenhängen.

In einem ersten Schritt solltest du die Daten in ein Stern-Schema überführen und das am Besten mit Hilfe der Medaillon-Architektur.

Im Idealfall hast du dann deine Daten im Gold-Layer als Stern-Schema (oder als Snowflake) vorliegen. Genau an dieser Stelle setzt das semantische Modell an. Du kannst es dir wie ein intelligentes Schichtensystem vorstellen, das die Gold-Layer-Daten nimmt und sie in eine klare, strukturierte Form bringt, die für jeden verständlich ist.

Wie funktioniert das?

Ich erkläre es dir anhand einiger Sichtweisen:

Daten verstehen und strukturieren: Du hast vielleicht viele Daten, aber ohne Kontext weiß niemand, was sie wirklich bedeuten. In einem semantischen Modell definierst du Beziehungen zwischen den Daten. Zum Beispiel, wenn du Daten zu Kunden, Bestellungen und Produkten hast, sorgt das semantische Modell dafür, dass klar ist: Ein Kunde kann viele Bestellungen haben, und jede Bestellung kann mehrere Produkte enthalten. Das Modell macht also klar, wie sich die Daten zueinander verhalten. Hier sei nochmal erwähnt, dass du sie vorher am besten in ein Stern-Schema überführt hast.
Komplexe Daten vereinfachen: Ohne ein semantisches Modell würdest du dich durch Dutzende von Tabellen kämpfen müssen, um zu verstehen, was zusammengehört. Mit dem semantischen Modell kannst du eine einheitliche Sicht auf die Daten bekommen. Es bündelt die Informationen, die du brauchst, und blendet das aus, was nicht relevant ist.
Einheitliche Begriffe und Definitionen: Ein weiterer Vorteil ist, dass alle im Team die gleichen Begriffe und Definitionen verwenden. Es gibt keine Verwirrung mehr, weil jeder unterschiedliche Namen für dieselben Dinge verwendet. Du kannst zum Beispiel sagen, „Kunde“ bedeutet immer „ein individueller Käufer“.
Mehr Menschen können mit den Daten arbeiten: Ein semantisches Modell macht die Daten zugänglicher – nicht nur für die IT-Experten oder Datenwissenschaftler, sondern für jeden im Unternehmen. Das bedeutet, auch nicht-technische Benutzer können mit den Daten arbeiten und wertvolle Erkenntnisse gewinnen, ohne tief in der Technik oder den Datenstrukturen drin zu sein. Die Komplexität wird also herausgenommen, und jeder sieht nur das Wesentliche.
Verbesserte Berichterstattung und Analysen: Wenn du mit einem klar strukturierten Modell arbeitest, wird es viel einfacher, Berichte und Dashboards zu erstellen. Die Daten sind nicht nur durcheinander, sondern du kannst sie so aufbereiten, dass jeder schnell die wichtigen Kennzahlen (KPIs) versteht und analysieren kann, ohne die Daten mehrfach prüfen zu müssen.

Ein Beispiel in Fabric

In Microsoft Fabric habe ich einen Editor für das Semantische Modell. Einige werden die Sicht aus Power BI kennen. Ich habe hier ein Bild aus einem einfachen Modell eingefügt.

In dem Beispiel ist gut das Stern-Schema zu erkennen. Die Faktentabelle in der Mitte und die zugehörigen Dimensionen drumherum. Hier kann ich (identisch zu Power BI) Attribute oder ganze Tabellen ausblenden. Mit Hilfe von DAX können Kennzahlen definiert werden und für alle Benutzer zur Verfügung gestellt werden.

Am Ende ist wichtig zu verstehen, dass Anwender oder Berichtsentwickler nur diese Sicht zur Verfügung gestellt bekommen. Damit können sie dann arbeiten. So habe ich die Möglichkeit Frontend und Backend und damit auch verschiedene Teams zu trennen. Das semantische Modell hilft mir dabei, die Daten in eine klar verständliche Sprache zu übersetzen, sodass alle Beteiligten im Unternehmen die richtigen Entscheidungen treffen können.

Fazit – Semantisches Modell in Microsoft Fabric

Ein Semantisches Modell in Microsoft Fabric hilft dir, Daten zu organisieren, zu verbinden und so aufzubereiten, dass jeder im Team damit arbeiten kann – ohne sich in den Details zu verlieren. Es sorgt für klare Beziehungen zwischen den Daten, eine einheitliche Sprache und einfachere Analysen. So wird das Arbeiten mit Daten nicht nur einfacher, sondern auch schneller und weniger fehleranfällig.

Ich werde in einem kommenden Blogartikel auch auf die Fähigkeit von Direct Lake im semantischen Modell eingehen. In einem anderen Beitrag habe ich bereits erwähnt, dass das inzwischen auch in Power BI Desktop geht. Ich finde aber der Direct Lake-Modus ist das absolute Killer-Feature in Microsoft Fabric und sollte daher nochmal explizit beschrieben werden.

Der Beitrag Semantisches Modell in Microsoft Fabric erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Ein Kostenvergleich von Fabric und Synapse Analytics

Kevin Taxweiler — Fri, 20 Dec 2024 09:04:35 +0000

In der Welt der Datenanalyse und -verarbeitung stehen Unternehmen vor der Wahl zwischen verschiedenen Plattformen, die ihre spezifischen Bedürfnisse erfüllen sollen. Dabei ist der Übergang von On-Premise in die Cloud ist ein bedeutender Schritt. So manches Unternehmen wird somit vor diverse Herausforderungen gestellt. Obwohl die zahlreichen Vorteile eines Umzuges in die Cloud mittlerweile hinreichend bekannt...

Der Beitrag Ein Kostenvergleich von Fabric und Synapse Analytics erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Schneller zum Data Warehouse mit der Cloud

Thomas Sobizack — Mon, 07 Oct 2024 05:25:06 +0000

In den letzten Jahren ist unsere Geschäftswelt immer schnelllebiger geworden. Der Zugriff auf aktuelle und genaue Daten ist für ein modernes Unternehmen inzwischen unerlässlich. Die Geschwindigkeit, mit der Daten gesammelt, verarbeitet und analysiert werden, kann den entscheidenden Unterschied zwischen Erfolg und Misserfolg eines Projektes ausmachen. Traditionelle On-Premise Data Warehouses stoßen dabei immer öfter an ihre Grenzen. Um diese Herausforderungen zu meistern und deinem Unternehmen den Weg zu schnelleren, flexibleren und kosteneffizienteren Datenlösungen bereiten zu können, sind Cloud-basierte Data Warehouses eine -wie ich finde- vielversprechende Alternative.

Was sind die Vorteile von Cloud-basierten Data Warehouses?

Einer der größten Vorteile der Cloud ist die nahezu unbegrenzte Skalierbarkeit. Ihr könnt eure Speicherkapazitäten und Rechenressourcen je nach Bedarf erhöhen oder jederzeit reduzieren. Das Ganze erfolgt in der Cloud, ohne in teure Hardware investieren zu müssen. Diese gewonnene Flexibilität ermöglicht es euch, auf unvorhergesehene Datenmengen und Spitzenlasten kurzfristig reagieren zu können.

Die meisten Cloud-basierten Data Warehouses arbeiten nach einem Pay-as-you-go-Modell. Das bedeutet, ihr zahlt nur für die tatsächlich genutzten Ressourcen. Dabei entfallen notwendige Anfangsinvestitionen vollständig. Eine vollständige Einrichtung eines On-Premise Data Warehouses kann Monate oder sogar Jahre dauern. Im Gegensatz dazu ermöglichen Cloud-Lösungen, wie es Microsoft z.B. mit Azure anbietet, eine deutlich schnellere Implementierung. Hier könnt ihr euer Warehouse innerhalb weniger Stunden oder Tage ans Laufen bekommen. So kommen wir viel schneller zum Data Warehouse!

Für die Verwaltung und Aktualisierung eurer Dateninfrastruktur müssen keinerlei Ressourcen eingeplant werden. Der Cloud-Anbieter übernimmt die Wartung der Infrastruktur, einschließlich Sicherheitsupdates und Performance-Optimierungen. Dadurch könnt ihr euch vollständig auf eure Kernkompetenzen konzentrieren und müsst keine Ressourcen für die Verwaltung und Aktualisierung der Dateninfrastruktur aufwenden.

Was sind die Herausforderungen und Lösungsansätze beim Erstellen eines Cloud-basierten Data Warehouses?

Welche Herausforderungen gibt es beim Thema Sicherheit und Datenschutz?

Eine der großen Herausforderungen bei der Nutzung von Cloud-Diensten ist das Thema Security. Dabei muss sichergestellt sein, dass die Daten sowohl während der Übertragung als auch im Data Warehouse selbst jederzeit vor fremden Zugriffen geschützt sind. Die Cloud-Anbieter, und insbesondere Microsoft Azure, bieten hier umfangreiche Sicherheitszertifizierungen und Compliance-Programme.

Gibt es Probleme und Lösungen, wenn man schneller zum Data Warehouse migriert?

Die Erfahrung zeigt, dass die Migration bestehender Daten in die Cloud komplex und zeitaufwendig sein kann. Eine sorgfältige Planung und die Nutzung von ETL-Tools (Extract, Transform, Load) können diesen Prozess erheblich vereinfachen. Unsere Erfahrung hat gezeigt, dass es sinnvoll ist, auf eine schrittweise Migration zu setzen. So werden Risiken minimiert und der laufende Geschäftsbetrieb wird kaum gestört. Auch hier bietet Microsoft mit Azure hervorragende Lösungen.

Gibt es Fallstricke bei der Integration und Kompatibilität?

Die Integration eines Cloud-basierten Data Warehouses in die bestehende IT-Infrastruktur kann eine nicht unerhebliche Herausforderung darstellen. Hierbei ist es wichtig, dass die gewählte Cloud-Lösung nahtlos mit anderen Systemen und Anwendungen zusammenarbeitet. Moderne Cloud-Datenplattformen wie Microsoft Azure bieten häufig eine Vielzahl von Integrationsmöglichkeiten und API-Schnittstellen, um diese Kompatibilität zu gewährleisten.

Folgende Punkte sollten also beim Erstellen eines Microsoft Cloud Data Warehouses berücksichtigt werden:

Planung: Bestimmt den Umfang und die Anforderungen eurer Data Warehouses. Das bedeutet, dass ihr euch Gedanken machen müsst, welche Datenquellen integriert und welche Art von Analysen durchgeführt werden sollen.
Azure-Dienste auswählen: Für den Aufbau eines Data Warehouses in Azure stehen eine große Anzahl von Diensten zur Verfügung. Dies sind bspw. Azure Data Lake, Azure SQL-Datenbank und Azure Synapse Analytics. Seit einiger Zeit steht mit Microsoft Fabric ein mächtiges Tool zur Verfügung, welches alle in Microsoft Azure vorhandenen Datenverarbeitungs-Möglichkeiten auf einer eigenen Plattform zusammenfasst. Schau dir dazu gerne in den Beitrag meines Kollegen Christopher Münch an: Microsoft Fabric.
Datenmigration: Mithilfe von Azure Synapse Pipelines kann ein bestehendes Data Warehouses in Azure migriert werden.
Datenintegration: Integriert eure strukturierte, unstrukturierte und semistrukturierte Daten aus ihren verschiedenen Quellen in ein Azure Data Lake Storage.
Datenverarbeitung: Verwendet Microsoft Fabric oder Apache Spark-Pools in Azure Synapse, um die Daten zu bereinigen, zu transformieren und dauerhaft zu speichern.
Analyse und Berichterstattung: Stellen Sie die verarbeiteten Daten für operative Berichte und analytische Dashboards zur Verfügung. Auch hier sollte in den meisten Fällen Microsoft Fabric das Mittel ihrer Wahl darstellen. Bei der Berichtserstellung stellt Microsoft mit Power BI ein sehr umfangreiches Berichtstool zur Verfügung.
Sicherheit und Governance: Implementieren Sie Sicherheits- und Governance-Maßnahmen, um Ihre Daten zu schützen und Compliance-Anforderungen zu erfüllen.
Monitoring und Optimierung: Überwachen Sie die Leistung Ihres Data Warehouses und optimieren Sie es kontinuierlich, um die Effizienz zu steigern.

Fazit schneller zum Data Warehouse

Cloud-basierte Data Warehouses bieten eine vielversprechende Lösung für euer Unternehmen. Die Vorteile in Bezug auf Skalierbarkeit, Kostenersparnis, Implementierungsgeschwindigkeit und automatisierte Wartung überwiegen deutlich gegenüber den eventuellen Hindernissen und Herausforderungen bei dem Umzug in die Cloud. Mit einer sorgfältigen Planung und den richtigen Sicherheitsmaßnahmen könnt ihr die Potenziale der Cloud voll ausschöpfen, und die Wettbewerbsfähigkeit in der heute stark datengetriebenen Wirtschaft sichern und sich sogar den entscheidenden Vorsprung gegenüber den Mitbewerbern verschaffen. Cloud-basierte Data Warehouses sind ein richtiger Schritt in die Zukunft, denn durch deren Verwendung erlangst du einen strategischen Vorteil, der euch dabei hilft, schneller und effektiver auf Marktveränderungen zu reagieren und Entscheidungen zu treffen. Wie oben erläutert, kommen wir schneller zum Data Warehouse. Falls es euch interessiert, haben wir auch nochmal die Unterschiede zwischen einem Lakehouse und einem Warehouse zusammengefasst.

Für eine detaillierte Anleitung und Best Practices kannst du dich jederzeit an uns wenden. Wir bei der arelium GmbH verfügen über ein fundiertes Wissen bei der Erstellung von Data Warehouses in Microsoft Azure. Egal ob du auf der grünen Wiese beginnen oder ein bestehendes On-Premise Data Warehouse migrieren möchtet, wir finden immer die beste Lösung für euer Projekt.

Der Beitrag Schneller zum Data Warehouse mit der Cloud erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Data Vault kurz und knapp erklärt!

Thomas Sobizack — Fri, 26 Jul 2024 11:11:15 +0000

Wenn von Data Vault gesprochen wird, dann sprechen wir über einen Modellierungsansatz für den Aufbau eines Data Warehouses. Der Grundgedanke zu diesem Modell wurde bereits in den 1990er Jahren von Dan Linstedt entworfen. Dabei lag der Fokus auf Agilität, Skalierbarkeit und der Anpassungsfähigkeit des Modells.

In der heutigen Zeit müssen Unternehmen ihr Geschäftsmodel in immer kürzer werdenden Zyklen anpassen und sich ständig den sich ändernden Marktbedürfnissen oder auch regulatorischen Anforderungen anpassen. Die Verantwortlichen stehen deshalb ständig unter Druck, die häufig sehr komplexgestalteten, bestehenden Datenstrukturen anzupassen. Dies ist mit unter äußerst anstrengend und teuer.

Dafür bietet der Ansatz des Data Vault eine Lösungsmöglichkeit, indem es die Eigenschaften aus der dimensionalen (Sternschema) und normalisierten Modellierungswelt miteinander verbindet. Dadurch kann eine Beschleunigung bei der Befüllung des Warehouses erreicht werden. Der wesentliche Vorteil liegt jedoch darin, dass wir bei der Erweiterbarkeit wesentlich flexibler sind als bei den klassischen Methoden. Durch die andere Art der Modellierung müssen bei Änderungen, meistens Regel, keine bestehenden Tabellen angepasst werden. Es reicht einfach neue Tabellen z.B. zusätzliche Satelliten (s.u.) ergänzt werden.

Beim Data Vault handelt es sich nicht um einen Ersatz des erprobten Sternschema, sondern um eine Ergänzung, indem es zur Modellierung des Data Warehouses (zentrale Datenbank zur Integration und Historisierung von Daten) verwendet wird.

Was sind die Bausteine von Data Vault?

Hub:

Das eigentliche Kernobjekt der Geschäftslogik, indem eindeutige Business Keys gespeichert werden, die ein Geschäftsobjekt identifizieren (z. B. Kundennummer, Rechnungsnummer oder Artikelnummer).

Link:

Mit den Links werden die Geschäftsobjekte (Hubs) miteinander verbunden. So werden die Beziehung zwischen den Informationen abgebildet (z. B. von einer Rechnungsnummer zu einer Kundennummer).

Satelliten:

Hier werden zusätzliche Attribute und historische Informationen in Hubs und Links gespeichert.

Inzwischen gibt es zwei „Versionen“ von Data Vault

Mit Data-Vault 2.0 wird eine Verbesserung bezüglich der Agilität und der Flexibilität gegenüber dem klassischen Modell erreicht. Zusätzlich werden dabei auch Big-Data, NoSQL-Datenbanken und Cloud-Technologien mitberücksichtigt. Ohne hier allerdings tiefer in das Thema einzusteigen, sei gesagt, dass Data Vault sich vor allem für Data Warehouses eignet und weniger für Lakehouses.

Fazit

Data Vault bietet eine hohe Flexibilität bei Erweiterungen, eine vollständige Historisierung der Daten und erlaubt eine starke Parallelisierung der Datenladeprozesse. Es ist eine moderne Architektur für agiles Data Warehousing und ermöglicht es ihrem Unternehmen, die Daten effizient zu verwalten und zu nutzen.

Allerdings ist Data Vault nicht für alle Szenarien die beste Wahl. Neben dem initialen Aufwand bei der Erstellung des Models, erfordert Data Vault ein grundlegendes tiefes Verständnis des Ansatzes sowie der vorhandenen Geschäftslogik.

Wir, die arelium GmbH, verfügen über ein fundiertes Wissen in diesem Bereich. Sollten Sie Interesse an dem Thema Data Vault und deren Einsatzmöglichkeiten haben, dann nehmen Sie gerne mit uns Kontakt auf. Wir beraten sie gerne.

Der Beitrag Data Vault kurz und knapp erklärt! erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Speichermöglichkeiten in Fabric

Joel Galla — Mon, 22 Jul 2024 05:30:46 +0000

Daten speichern in Fabric

Sie haben beschlossen, Fabric ist das Richtige für Sie. Aber nun wissen Sie nicht, wie Sie anfangen wollen? Welche Speichermöglichkeiten gibt es in Fabric? Sollen die Daten jetzt in ein Warehouse oder in ein Lakehouse? Und was ist dieses Eventhouse oder ein Datamart?

Klar, um anfangen zu können müssen Sie erst einmal verstehen, wie Sie Ihre Daten speichern wollen. Dabei kommt es allerdings nicht nur auf Ihre Daten an, sondern besonders auch auf Ihr Team. Denn auch Ihr Team hat besondere Fähigkeiten, die bei der Auswahl der richtigen Technologie nicht Außen vor gelassen werden sollten. Vorweg genommen sind die beiden wahrscheinlichsten Fälle für Ihre Anwendung entweder das Lakehouse oder das Warehouse, als Speichermöglichkeiten in Fabric.

Zuerst sollten wir aber einmal geklärt haben, was eigentlich was ist. Alle vier Möglichkeiten sind Architekturentscheidungen. Grundlegend speichern all diese Optionen die Daten in unterschiedlicher Weise organisiert im OneLake. Das heißt am Ende ist alles in Microsoft Fabric und alles ist nur auf unterschiedliche Art strukturiert am selben Ort.

Eventhouse und Datamart

Da wir nun geklärt haben, dass alles erstmal nur Datenspeichermöglichkeiten sind müssen wir nun natürlich klären: „Warum sollte ich mich für eins entscheiden, wenn am Ende alles am selben Ort ist?“ Die Antwort darauf ist, dass die einzelnen Architekturen unterschiedliche Vorteile für unterschiedliche Anwendungsbereiche bieten. Die beiden einfachsten Fälle zuerst. Ein Eventhouse hat einen klaren Fokus auf Streamingdaten. Das heißt, wenn Sie dauerhaft Daten erhalten von z.B. IoT Geräten dann ist ein Eventhouse das Richtige. Andere Beispiele sind Zeitreihen und Finanzdaten oder auch Telemetrie und Protokolldaten. Dabei können die Daten mit KQL und SQL verwaltet werden und sind auch mit Power BI abrufbar. Die Verwendung vom Eventhouse ermöglicht auch unbegrenzt große Datenmengen.

Die zweite schnell erklärte Architektur ist der Power BI Datamart. Hier handelt es sich um einen Spezialfall. Ein Power BI Datamart ist für Power BI Berichte gedacht und ist keine allgemeine Datenspeicherung für alle Anwendungen. Deshalb ist der Power BI Datamart auch auf 100 GB begrenzt. Für die Bearbeitung des Datamarts sind dabei auch vor allem No Code und SQL Kenntnisse wichtig. Der Datamart in dieser Form ist für Power BI Entwickler gedacht, die eine größere Menge an Daten speichern und bearbeiten wollen. Das Ziel ist es Daten für Power BI bereitzustellen.

Warehouse oder Lakehouse

Damit sind wir auch schon bei den beiden letzten Architekturen angekommen. Das Warehouse ist die klassische SQL Lösung, dabei werden nur strukturierte Daten verarbeitet. Die Organisation erfolgt mit Hilfe von Schemata und Tabellen. Dabei ist die Hauptsprache ganz klar T-SQL. Außerdem ist ein Warehouse auch für alle Datenmengen vorgesehen, sodass es hier keine Obergrenze gibt.

Ähnliches gilt auch für das Lakehouse auch hier gibt es keine Obergrenze. Die wichtigsten Unterschiede sind, dass andere Fähigkeiten wichtig sind und dass nicht nur strukturierte Daten gespeichert werden können. Im Lakehouse werden unstrukturierte, semistrukturierte und strukturierte Daten aufbewahrt. Dabei werden die Daten in Ordnern und Dateien gespeichert. Ebenso kann man Daten auch in Tabellen organisieren, wie in einem Warehouse. Das Lakehouse ist damit flexibler, was aber nicht notwendigerweise besser ist. Ein weiterer wichtiger Unterschied ist, dass die Entwicklung mit Spark stattfindet. Was genau Spark ist, ist hier erstmal nicht relevant. Wichtig ist nur, dass die Entwickler hier mit Scala, Python (PySpark), SQL (Spark SQL) und R arbeiten. Wenn Ihr Team schon Erfahrung mit diesen Sprachen hat, können Sie hierbei schneller Erfolge erzielen.

Fazit

Natürlich gibt es noch weitere Details, aber dieser Beitrag soll einen Überblick über die wichtigsten Unterschiede von verschiedenen Speichermöglichkeiten in Fabric geben. Zusammengefasst lässt sich sagen, dass die richtige Wahl vor allem vom Team und den Anforderungen abhängt. Jede Architektur hat ihre Berechtigung, nur ist nicht jede immer geeignet.

Wenn Sie weitere Hilfe brauchen, lesen Sie doch den Artikel Lakehouse vs. Warehouse oder kontaktieren Sie uns und lassen sich beraten. Wir bauen seit über einem Jahrzehnt Datenarchitekturen und können auf viele erfolgreiche Projekte zurückblicken.

Der Beitrag Speichermöglichkeiten in Fabric erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Data Mesh in Microsoft Fabric

Emil Vincazovic — Mon, 10 Jun 2024 10:00:13 +0000

Über den Data Mesh Ansatz haben wir bereits in der Vergangenheit geschrieben. Hier eine kurze Zusammenfassung: Die Data Mesh Architektur ist ein innovativer Ansatz für das Datenmanagement. Dabei steht die Dezentralisierung der Daten im Vordergrund. Jedes Datenteam ist für sein Datenprodukt und damit auch für die damit verbundene Datenqualität verantwortlich. Die Vor- und Nachteile sowie ein Anwendungsbeispiel finden sich in unserem Übersichtsartikel Data Mesh.

Implementierung von Data Mesh in Microsoft Fabric

Microsoft hat die vielen Vorteile des Data Mesh Ansatzes erkannt und eine Funktion in Microsoft Fabric implementiert, die die Implementierung massiv vereinfacht. Diese Funktion sind die „Domains“. Damit haben wir in Microsoft Fabric die Möglichkeit, Domänen anzulegen. Diese Domänen können mit bestimmten Arbeitsbereichen (Workspaces) verknüpft werden. Wie schon im Übersichtsartikel zum Thema Data Mesh gehe ich hier von drei Domänen bzw. Datenprodukten aus: Vertriebs-, Kunden- und Supply-Chain-Daten.

Aber fangen wir einmal bei Null an. Wie erstelle ich eine Domäne in Microsoft Fabric? Dies kann im Admin Portal von Microsoft Fabric erfolgen. Wenn man in die Einstellungen von Fabric geht, sieht man als vorletzten Punkt das Admin Portal. Auf der linken Seite erscheinen dann die „Domains“. Wie man sehen kann, sind diese ein neues Feature in Microsoft Fabric.

Wenn man zum Domänen-Menü navigiert ist, kann man dort nun eigene Domänen anlegen. Man muss lediglich den Namen und einen Domänen-Admin bestimmen.

Ich habe dies für die oben genannten Bereiche getan.

Anhand des Bereiches Verkauf zeige ich nun, wie die Data Mesh Architektur in Fabric weiter umgesetzt werden kann. Wenn wir in die Verkaufsdomäne navigieren, können wir einen Arbeitsbereich mit der Domäne verknüpfen. Wir haben sogar die Möglichkeit, Subdomains anzulegen.

Wir haben die Möglichkeit Arbeitsbereiche nach verschiedenen Kategorien zu verknüpfen. Entweder nach Kapazität, nach Arbeitsbereich Admin oder nach dem Arbeitsbereich Namen.

Diese Auswahl ist z.B. wichtig, wenn man Kapazitäten pro Arbeitsbereich buchen möchte und nicht eine große für die gesamte Organisation. Zum Thema Skalierung von Fabric-Kapazitäten bzw. Lizenzmodelle in Fabric haben wir bereits geschrieben. Daher gehen wir hier nicht weiter darauf ein.

Ich habe mich hier entschieden, testweise einen einzelnen Workspace hinzuzufügen.

Meine Domäne „Verkauf“ ist nun also mit dem Arbeitsbereich „Verkaufs Arbeitsbereich“ verknüpft. Alle Fabric Items, die mit dem Verkauf zu tun haben, sollten nun nur noch in diesem Arbeitsbereich deployed werden. Bereits in anderen Workspaces vorhandene Fabric Items können in den neu verknüpften Workspace verschoben werden.

Der Vorgang der Verknüpfung von Domänen mit Arbeitsbereichen muss natürlich im nächsten Schritt wiederholt werden. So haben am Ende alle Domänen einen eigenen Arbeitsbereich. Erweitert man das Thema, kann man noch Unterdomänen hinzufügen. Dies verkompliziert die Architektur, kann aber zu einer besseren Datenqualität führen.

Kontakt

Data Mesh ist ein vielversprechender Ansatz für das Datenmanagement, aber nicht für jedes Unternehmen geeignet. Unternehmen sollten die Vor- und Nachteile sorgfältig gut abwägen, bevor sie sich für eine Implementierung entscheiden. Microsoft hat in Fabric das Framework für eine Implementierung geschaffen.
Falls Sie Hilfe bei der Umsetzung der Architektur oder weitere Fragen haben, melden Sie sich gerne bei uns. Wir freuen uns darauf, Ihnen zu helfen und Data Mesh auch in Ihrem Unternehmen erfolgreich zu implementieren.

Der Beitrag Data Mesh in Microsoft Fabric erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Data Mesh

Emil Vincazovic — Mon, 03 Jun 2024 10:00:14 +0000

2020

Was ist Data Mesh?

Data Mesh ist ein innovativer Ansatz für die Datenverwaltung, der auf einer dezentralen Architektur basiert. Im Gegensatz zu traditionellen, zentralisierten Systemen, wo Daten an einem Ort gespeichert und verwaltet werden, verteilt Data Mesh die Verantwortung auf verschiedene Teams.
Jedes Team ist für die Daten eines bestimmten Geschäftsbereichs verantwortlich. Diese Domänenexperten besitzen tiefgreifendes Wissen über ihre Daten und sind dafür zuständig, diese in Form von Datenprodukten aufzubereiten und bereitzustellen.
Datenprodukte sind klar definierte Datensätze, die mit Metadaten angereichert und für den Zugriff durch andere Teams oder Anwendungen freigegeben werden.

Die Vorteile von Data Mesh

Der Ansatz bietet Unternehmen zahlreiche Vorteile. Durch die dezentrale Datenhaltung kann der Ansatz problemlos mit wachsenden Datenmengen umgehen, da die Skalierbarkeit einfach zu handhaben ist. Die Experten einer Domäne können sehr schnell auf neue Datenanforderungen reagieren. Dies führt zu einer deutlich schnelleren Entscheidungsfindung, da man nicht auf zentrale Prozesse angewiesen ist. Dies erhöht zugleich auch die Flexibilität der Data Engineers bzw. Data Owner. Ein weiterer großer Vorteil ist die Zuverlässigkeit. Die dezentrale Datenarchitektur führt dazu, dass Ausfälle schneller erkannt und behoben werden können. Ein letzter großer Vorteil ist die Datensicherheit. Durch die Kontrolle der Daten auf Domänenebene kann Data Mesh die Datensicherheit und -governance verbessern. Dies liegt daran, dass die verantwortlichen Personen ganz klar definiert sind.

Die Nachteile von Data Mesh

Neben den Vorteilen hat Data Mesh auch einige Nachteile, die berücksichtigt werden sollten. So kann die Architektur bei unsauberer Ausführung komplex werden. Dies liegt daran, dass ein hohes Maß an Zusammenarbeit und Koordination erforderlich ist, um die Architektur aufzubauen. Problematisch könnte es auch werden, wenn die verschiedenen Datenteams eine verschiedene Datenqualität liefern. Dies kann natürlich zu Verzerrungen innerhalb der Entscheidungsfindung basierend auf Daten führen. Ein zusätzlicher Nachteil ist der Bedarf an verschiedenen Tools. Der Nachteil wirkt nicht so groß, allerdings macht es einen großen Unterschied, ob man ein oder drei Tools nutzt, um die Daten zu managen bzw. zu überwachen.
Sollte man überlegen, die vorhandene Datenarchitektur aufzubrechen und zu Data Mesh wechseln zu wollen, muss man im Blick behalten, dass so eine Umstellung, ein tiefgreifender Veränderungsprozess in der Unternehmenskultur ist.

Beispielanwendung der Architektur

Ein Beispiel für die Anwendung von Data Mesh ist ein großes Einzelhandelsunternehmen. Das Unternehmen kann die Architektur verwenden, um verschiedene Arten von Datenprodukten bereitzustellen. So hätten wir bspw.:

Verkaufsdaten

Diese Daten können von Analysten genutzt werden, um Trends zu erkennen und Marketingkampagnen zu optimieren.

Kundendaten

Diese Daten können vom Kundendienst genutzt werden, um personalisierte Angebote und Unterstützung bereitzustellen.

Lieferkettendaten

Diese Daten können vom Logistikteam genutzt werden, um Lieferprozesse zu optimieren und Lagerbestände zu verwalten.

Die Architektur bietet Unternehmen eine innovative Möglichkeit, ihre Daten zu verwalten und zu nutzen. Durch die Dezentralisierung des Datenmanagements und die Fokussierung auf Datenprodukte können Unternehmen ihre Agilität, Skalierbarkeit und Datensicherheit verbessern.

Kontakt

Data Mesh ist ein vielversprechender Ansatz für das Datenmanagement, aber nicht für jedes Unternehmen geeignet. Unternehmen sollten die Vor- und Nachteile sorgfältig gut abwägen, bevor sie sich für eine Implementierung entscheiden.
Falls Sie Hilfe bei der Implementierung oder weitere Fragen haben, melden Sie sich gerne bei uns. Wir freuen uns darauf, Ihnen zu helfen und Data Mesh auch in Ihrem Unternehmen erfolgreich zu implementieren.

Der Beitrag Data Mesh erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Skalierbarkeit von Fabric Kapazitäten

Joel Galla — Mon, 22 Apr 2024 11:50:02 +0000

Die Umstellung auf Fabric ist für die meisten Firmen in den nächsten Wochen und Monaten gesetzt. Dabei stellt sich die Frage: „Wie kann ich die Kapazitäten optimal nutzen?“ Natürlich spielt dabei auch eine Rolle, ob ich eine Lizenz skalieren kann und wie man Kosten spart.

Welche Kapazitäten gibt es?

Für Fabric gibt es grundlegend zwei Arten von Kapazitäten. Beide Kapazitäten bestehen aus SKU’s (Stock Keeping Unit). Diese SKU’s sind für die Rechenleistung der Kapazitäten verantwortlich. Die verschiedenen Arten von Kapazitäten sind:

Microsoft 365
Azure

Viele werden die Microsoft 365 Kapazität vor allem als P-SKU kennen, da sie sich auch auf Power BI beziehen. Zu der Zukunft dieser Kapazitäten haben wir schon einen Blogbeitrag geschrieben, welcher ausführlich beschreibt, wie Microsoft den künftigen Umgang plant.

Wie funktioniert die Skalierbarkeit von Fabric Kapazitäten?

Für uns in diesem Blog interessanter sind die Azure SKU’s, die auch als F-SKU’s bekannt sind. Wie die meisten bereits vermutet haben, werden diese SKU’s in Azure angelegt und im Anschluss mit Fabric verbunden. Die Fabric Kapazitäten in Azure sind auch die einzigen Lizenzen, die sich skalieren lassen. Denn für die Skalierbarkeit von Fabric Kapazitäten kann in zwei Arten verstanden werden. Zuerst die von Microsoft als Skalierbarkeit beschriebene Variante. Denn Microsoft erlaubt ein schnelles Auf- und Abskalieren. Dabei kann im Azure Portal die Kapazität angepasst werden. Dazu gehen Sie folgende Schritte durch:

Einloggen im Azure Portal
Geben Sie Microsoft Fabric in der Suchleiste ein und wählen Sie den Microsoft Fabric Service aus, um Ihre Kapazität zu sehen
Wählen Sie dann die Kapazität aus, die Sie skalieren möchten. Tipp: Unter SKU können Sie Ihre derzeitige Lizenz sehen, z.B. F64
Klicken Sie dann auf Skalieren und wählen Sie Größe ändern aus
Sie wählen jetzt eine Skalierung und klicken dann Größe ändern
Nachdem Sie bestätigt haben, können Sie den aktuellen Tarif sehen

Die Alternative, die mit Skalierbarkeit gemeint sein kann, ist die optimale Bezahlung. Denn die Skalierbarkeit von Fabric Kapazitäten bedeutet auch Pay-as-you-go. Sie können also jederzeit Ihre SKU anhalten, wenn Sie diese nicht mehr brauchen. Dabei bewirbt Microsoft die Bezahlung als sekundengenau. Praktisch heißt das aber, dass jede angefangene Minute wird bezahlt.

Fazit

Microsoft bietet eine einfache Möglichkeit, nur die Kapazität zu kaufen, die auch wirklich benötigt wird. Zudem kann die Lizenz augenblicklich angehalten werden, um unnötige Kosten zu sparen. Wenn Sie Unterstützung bei der Einrichtung von Microsoft Fabric in der Praxis brauchen, kontaktieren Sie uns gerne.

Der Beitrag Skalierbarkeit von Fabric Kapazitäten erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.