Sommerloch in der IT-Ressourcenplanung

Wenn die halbe Firma am Strand liegt und die andere Hälfte Wunder vollbringen soll, beginnt in vielen Unternehmen eine besonders herausfordernde Zeit: das Sommerloch in der IT Ressourcenplanung!

Jedes Jahr passiert das Gleiche: Die Temperaturen steigen, die Abwesenheitsnotizen vermehren sich schneller als Jira-Tickets und die Outlook-Kalender sehen plötzlich so bunt aus wie das „Richter-Fenster“ im Kölner Dom.

Der Senior Consultant genießt Baguette und die Meeresluft in Frankreich, der Data Engineer sucht irgendwo zwischen Fjorden und Elchen nach dem besten Handyempfang und der Projektleiter blickt auf die Einsatzplanung wie auf ein Sudoku der höchsten Schwierigkeitsstufe.

Gleichzeitig erwarten Kunden selbstverständlich, dass Projekte trotzdem pünktlich geliefert werden.

Willkommen in unserem  Sommerloch

Während viele Unternehmen weiterhin hektisch Excel-Listen aktualisieren oder zusätzliche Abstimmungsmeetings ansetzen, stellt sich eigentlich eine andere Frage:

Wie bleibt die Ressourcenplanung auch dann zuverlässig, wenn gefühlt die halbe Belegschaft im Liegestuhl sitzt?

Die Antwort lautet überraschenderweise nicht „mehr Planung“.

Und auch nicht „noch ein weiteres Tool“.

Die Antwort ist ein datengetriebenes und transparentes Bild der Realität – mit Microsoft Fabric.

Das eigentliche Problem: Die Daten wissen mehr als die Planung

Es ist schon erstaunlich: In den meisten Unternehmen ist eigentlich alles da. Die Informationen sind vorhanden, die Systeme funktionieren, die Daten werden fleißig gepflegt. Nur leider führen sie ein ausgesprochen eigenständiges Leben.

Das Problem besteht allerdings darin, dass diese Informationen selten an einem Ort zusammenlaufen. Stattdessen verteilen sich die entscheidenden Daten quer durch die gesamte Systemlandschaft.

Für unser Sommerloch-Beispiel bedeutet das:

• •Projekte in Jira
• •Dokumentationen in Confluence
• •Zeiterfassungen in unterschiedlichen Anwendungen
• •Urlaubsdaten im HR-System
• •Auslastungsübersichten in Excel
• •Forecasts in Power BI
• •und die berühmten „Das weiß der Thomas aus Erfahrung“-Informationen in den Köpfen der Projektleiter

Für sich genommen funktionieren diese Systeme hervorragend. Das Problem entsteht jedoch, sobald jemand eine einfache Frage beantworten möchte:

„Haben wir nächsten Monat genügend Kapazität für das neue Projekt?“

Dann beginnt die digitale Schnitzeljagd:

Ein Blick in Jira. Ein Blick in Excel. Ein Anruf beim Projektleiter. Ein kurzer Teams-Chat. Danach noch einmal ins HR-System. Und zur Sicherheit fragt man erneut nach, weil die Excel-Datei seit drei Monaten nicht mehr aktualisiert wurde.

Technisch sprechen wir hier von klassischen Datensilos.

Jedes System kennt einen Teil der Wahrheit, aber keines kennt die gesamte Geschichte.

Solange alle verfügbar sind und Projekte weitgehend nach Plan laufen, fällt das oft kaum auf. Die Organisation kompensiert fehlende Transparenz dann mit Erfahrung, Abstimmungen und oft mit einer Prise Mut.

Doch sobald die Sommerurlaubszeit beginnt, wird aus dieser eigentlich kleinen Schwäche plötzlich eine echte Herausforderung.

Denn genau dann zeigt sich: Die Daten wissen längst, was passiert. Nur wir noch nicht…

Wenn KI plötzlich der bessere Ressourcenmanager wird

Transparenz ist wichtig. Allerdings löst eine Excel-Datei, die zeigt, dass das Problem bereits eingetreten ist, das Problem in den meisten Fällen nicht.

Der eigentliche Mehrwert entsteht erst dann, wenn Daten nicht nur gesammelt, sondern auch intelligent analysiert werden.

Genau hier spielt Microsoft Fabric seine Stärken aus.

Mit KI- und Machine-Learning-Funktionen lassen sich Muster erkennen, die im ganz normalen Projektalltag leicht untergehen. Zum Beispiel, wenn bestimmte Projekte regelmäßig mehr Ressourcen benötigen als geplant. Oder wenn sich aus Urlaubszeiten, Auslastung und offenen Aufgaben bereits heute ablesen lässt, dass es in drei Wochen eng werden könnte.

Denn Hand aufs Herz: Im Alltag jongliert niemand nur ein Projekt. Während der Projektleiter versucht, drei Prioritäten gleichzeitig zur wichtigsten zu erklären, beantwortet der Consultant noch schnell zwei Teams-Nachrichten, nimmt an einem Statusmeeting teil und wird zwischendurch gefragt, ob er „mal eben“ auf ein neues Projekt schauen kann.

Da ist es durchaus angenehm, wenn nicht auch noch die Ressourcenplanung permanent um Aufmerksamkeit bittet.

Statt erst festzustellen, dass das Sommerloch längst da ist, kann Microsoft Fabric frühzeitig darauf hinweisen, wo Engpässe entstehen, welche Teams an ihre Grenzen kommen und wo noch freie Kapazitäten vorhanden sind.

Und plötzlich wird aus einem Dashboard nicht nur ein Rückspiegel, sondern eher ein Navigationssystem.

Wiederkehrende Engpässe erkennen

Manchmal wirkt es so, als würde der Sommer jedes Jahr völlig überraschend kommen.

Tatsächlich sind viele Engpässe jedoch erstaunlich vorhersehbar.

Vielleicht fehlen nicht nur im Juli Ressourcen. Vielleicht fehlen das gesamte Jahr über Data Engineers, Azure Architekten oder Power Platform Spezialisten. Der Sommer sorgt dann lediglich dafür, dass das Problem sichtbar wird.

Microsoft Fabric kann historische Projekt-, Auslastungs- und Kapazitätsdaten analysieren und  Muster sichtbar machen.

Nicht nur für den nächsten Monat, sondern über Jahre hinweg.

Oder anders gesagt:

Vielleicht haben wir gar kein Sommerproblem – sondern ein ganzjähriges Ressourcenproblem, das im Sommer lediglich sichtbarer wird.

Alle Projektmanager lieben Planbarkeit. Überraschungen wohl eher nicht.

Durch die Analyse historischer Projekt-, Zeit- und Kapazitätsdaten lassen sich mit Microsoft Fabric belastbare Forecasts erstellen. Dadurch werden Engpässe nicht erst sichtbar, wenn bereits drei Eskalationsmeetings im Kalender stehen, sondern Wochen oder im besten Fall sogar Monate vorher.

Dadurch verschiebt sich die Frage von:

„Wie lösen wir das Problem?“

zu:  „Wie verhindern wir, dass es überhaupt entsteht?“

Und wir wissen es alle, das ist die angenehmere Variante.

Versteckte Risiken sichtbar machen

Eine weitere Stärke von Microsoft Fabric besteht darin, Abhängigkeiten zwischen Projekten, Aufgaben und Mitarbeitern sichtbar zu machen.

Denn offiziell arbeiten vielleicht zehn Personen an einem Projekt. Inoffiziell hängt jedoch alles an einer einzigen Person.

Die Analyse zeigt dann häufig ein Bild wie dieses:

• •10 Personen im Projekt
• •5 aktive Teilprojekte
• •42 offene Aufgaben
• •1 Mitarbeiter mit kritischem Wissen

Die Erkenntnis daraus:

Das Projekt hängt gar nicht von zehn Personen ab.

Es hängt eigentlich nur an Rainer.

Spätestens an diesem Punkt wird klar:

Die KI ersetzt keinen Ressourcenmanager. Allerdings erkennt sie Risiken oft deutlich früher, als Menschen sie im hektischen Projektalltag erkennen können.

Und genau das kann im Sommer den entscheidenden Unterschied machen.

Warum Transparenz oft mehr bringt

Wenn Kapazitätsengpässe auftreten, reagieren viele Unternehmen erstaunlich ähnlich:

„Wir brauchen mehr Leute.“

Das klingt logisch und ist oft auch richtig. Allerdings wird dabei häufig ein entscheidender Punkt übersehen:

Man kann keine Probleme lösen, die man nicht vollständig versteht.

Oft fehlt schlicht die Transparenz darüber, wo Kapazitäten tatsächlich vorhanden sind, wo sie gebunden werden und welche Projekte wirklich Priorität haben.

Unsere Erfahrung aus Data-Analytics-Projekten zeigt immer wieder ein ähnliches Bild:

Sobald Projektverantwortliche eine vollständige Sicht auf Projektfortschritt und Verfügbarkeiten erhalten, verändern sich Entscheidungen nahezu automatisch.

Denn Hand aufs Herz:

Nicht jedes Projekt mit roter Markierung ist automatisch ein Notfall.

Manchmal hat einfach nur jemand besonders viele Ausrufezeichen in seine E-Mails eingebaut.

Transparenz schafft Effizienz

Der eigentliche Effekt entsteht häufig durch bessere Entscheidungen.

Dadurch zeigen sich meist schnell messbare Verbesserungen:

• •weniger Abstimmungsaufwand
• •schnellere Priorisierung
• •bessere Projektsteuerung
• •realistischere Forecasts
• •frühere Erkennung von Risiken
• •weniger Überraschungen in Statusmeetings

Und seien wir ehrlich:

Allein das letzte Ziel wäre für viele Projektleiter bereits ein Erfolg.

Weniger Blindflug, mehr Steuerungsfähigkeit

Sobald alle Beteiligten auf dieselbe Datenbasis schauen, verschwinden viele Diskussionen von selbst.

Manchmal braucht es einfach nur den Mut, den Daten zuzuhören. Microsoft Fabric hilft dabei.

Fazit: Das Sommerloch ist kein Feind

Seien wir ehrlich:

Das Sommerloch wird nicht verschwinden.

Und das ist auch gut so.

Urlaub ist wichtig – für Mitarbeitende, für Teams und für die mentale Gesundheit. Vor allem für diejenigen, die seit Februar versuchen, fünf Projekte, drei Eskalationen und zwölf Prioritätsänderungen gleichzeitig unter einen Hut zu bringen.

Die entscheidende Frage lautet deshalb nicht:

„Wie verhindern wir das Sommerloch?“

Sondern:

„Wie verhindern wir, dass uns das Sommerloch überrascht – obwohl es jedes Jahr zur gleichen Zeit kommt?“

Denn der Sommer bringt selten neue Probleme mit.

Er macht lediglich sichtbar, was ohnehin schon da ist:

• fehlende Transparenz
• versteckte Abhängigkeiten
• Excel-Dateien mit mehr Versionen als manche Unternehmenssoftware
• und Wissen, das sich irgendwo zwischen Projektleiter, Teams-Chat und Kaffeeküche versteckt

Genau hier setzt Microsoft Fabric an.

Durch die zentrale Zusammenführung von Daten aus operativen Systemen, Echtzeit-Analysen und KI-gestützten Prognosen entsteht ein belastbares Bild der tatsächlichen Ressourcenlage. Entscheidungen basieren nicht länger auf Bauchgefühl oder der Frage, wer gerade erreichbar ist, sondern auf einer gemeinsamen, aktuellen Datenbasis.

arelium im Sommerhoch!

Genau dabei unterstützen wir unsere Kunden: Wir verbinden Datenquellen, schaffen Transparenz über Projekte, Kapazitäten und Auslastungen und nutzen Microsoft Fabric, um aus Daten fundierte Handlungsempfehlungen zu machen.

Denn gute Ressourcenplanung sollte nicht davon abhängen, wer gerade im Büro sitzt.

Oder ganz pragmatisch:

• Die Kollegin ist in Italien.
• Der Kollege wandert durch Skandinavien.
• Die Excel-Datei wurde zuletzt vor drei Wochen aktualisiert.
• Heinz sitzt am See und wartet auf den Karpfen seines Lebens.

Und trotzdem wissen die Daten, was gerade passiert.

Das ist die Stärke von Microsoft Fabric: Während Menschen Urlaub machen oder Meetings verschieben, bleibt die Datenbasis aktuell, transparent und jederzeit auskunftsfähig.

Und ausnahmsweise macht niemand etwas falsch.

In diesem Sinne wünschen das gesamte Team der arelium GmbH und ich euch einen fantastischen Sommer!

Und wenn nach dem Urlaub die erste Tasse Kaffee leer ist und ihr euch fragt, wie Themen wie Microsoft Fabric in eurem Unternehmen sinnvoll angegangen werden können, dann sprecht uns einfach an.

Einen kostenlosen und unverbindlichen Erstberatungstermin könnt ihr natürlich schon heute vereinbaren.

Wir freuen uns darauf, mit euch über eure Daten, Herausforderungen und Ideen zu sprechen.

Bis dahin wünsche ich euch sonnige Tage, viele schöne Momente und vor allem eine erholsame Zeit.

Thomas und das gesamte Team der arelium GmbH

Der Beitrag Sommerloch in der IT: Wie Microsoft Fabric Licht in die Ressourcenplanung bringt erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Microsoft Synapse Analytics: Flexibilität und Leistung

Microsoft Synapse Analytics ist für seine Flexibilität und Leistungsfähigkeit bekannt und greift auf ein nutzungsbasiertes Abrechnungsmodell zurück, welches auf verschiedenen Komponenten aufbaut.

Einer dieser Komponente sind die SQL-Pools. Bei ihnen sind die Kosten von der Anzahl der reservierten Data Warehouse Units (DWUs) abhängig. Je mehr DWUs, desto höher die Kosten. Neben den SQL-Pools gibt es noch die Serverless SQL-Pools. Hier erfolgt die Abrechnung basierend auf der Menge der abgefragten Daten, gemessen in Terabyte (TB). Ein weiterer Kostenfaktor sind die Apache Spark-Pools. Bei diesen basieren die Kosten auf der Anzahl der vCore-Stunden, die für die Ausführung von Spark-Jobs verwendet werden. Ebenfalls entstehen Kosten bei der Data Integration. Dabei werden für Data Factory-Pipelines und Data Flows die Kosten nach der Anzahl der ausgeführten Aktivitäten und der Menge der verarbeiteten Daten berechnet. Zu guter Letzt wäre da noch der Speicher. Die Speicherung von Daten im Azure Data Lake Storage verursacht ebenfalls Kosten. Durch diese Preisgestaltung ist es möglich, nur für die tatsächlich genutzten Ressourcen zu zahlen, was besonders für variable Workloads von Vorteil ist.

Microsoft Fabric: Integration und Einfachheit

Microsoft Fabric hingegen setzt auf ein kapazitätsbasiertes Preismodell, was die Preisstruktur vereinfacht.

Zum einen wären da die kapazitätsbasierten Kosten. Dabei wählen die Benutzer eine Compute-Kapazität, die ihren Workloads entspricht. Die Preise variieren je nach Kapazitätsstufe und damit nach benötigter Leistung. Ein weiterer Aspekt ist die Power BI Premium Integration. Dabei Fabric nutzt die Power BI-Lizenzierung, was die Preisstruktur weiter vereinfacht. Die Preise hängen also an der Größe der Kapazität und den Einzellizenzen, wie in Power BI. Zusätzlich kommen minimale Kosten für Datenspeicherung hinzu. Die Kapazität wird in Microsoft Azure verwaltet und kann bei nicht Benutzung ausgeschaltet werden. Die Abrechnung basiert dann auf der tatsächlichen Nutzung von Fabric und kann z.B. über Nacht Kosten sparen.

Dieses Modell bietet eine größere Flexibilität und kann kosteneffizienter sein, insbesondere für Unternehmen, die bereits stark in Microsoft 365- und Power BI-Ökosysteme integriert sind.

Kostenvergleich von Fabric und Synapse

Microsoft Fabric bietet durch sein kapazitätsbasiertes Preismodell eine größere Flexibilität, die sich besser an die tatsächliche Nutzung anpasst. Synapse Analytics verwendet hingegen ein nutzungsbasiertes Modell, das auf spezifischen Komponenten basiert. Beide Plattformen bieten hohe Skalierbarkeit, aber Fabric ermöglicht eine nahtlose Integration mit Power BI und anderen Microsoft 365-Diensten, was die Gesamtkosten für Unternehmen senken kann. Die Gesamtkosten hängen stark von den spezifischen Anforderungen und der Nutzung ab. Fabric kann kosteneffizienter sein, wenn Unternehmen bereits stark in Microsoft 365- und Power BI-Ökosysteme integriert sind.

Fazit

Die Wahl zwischen Microsoft Synapse Analytics und Microsoft Fabric hängt von den spezifischen Anforderungen und der bestehenden Infrastruktur eines Unternehmens ab. Fabric bietet eine modernere, integrierte Lösung mit flexibler Preisgestaltung. Synapse Analytics hingegen ist eine bewährte Plattform für große Datenanalysen und Data Warehousing.

Für Unternehmen, die eine nahtlose Integration mit Power BI und anderen Microsoft 365-Diensten suchen, könnte Microsoft Fabric die bessere Wahl sein. Synapse Analytics hingegen bietet eine robuste Lösung für Unternehmen mit variablen Workloads und spezifischen Anforderungen an die Datenverarbeitung.

Ein direkter Kostenvergleich von Fabric uns Synapse ist somit zwar möglich, aber individuell von den Wünschen des Kunden abhängig.

Bei weiteren Fragen zu diesem Thema stehen meine Kollegen und ich gerne mit Rat und Tat zur Seite.

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

Microsoft Fabric ist eine All-in-one Datenlösung, aber was heißt das? Das heißt, dass alles enthalten ist von der Datenbank bis zum Bericht. Dabei können verschiedene Quellen verknüpft und verwaltet werden. Fabric bietet verschiedene Tools zur Bereinigung und Weiterverarbeitung der Daten, zum Beispiel Notebooks und Pipelines. Die aufbereiteten Daten stellt man schlussendlich in einem Power BI Bericht dar. Zudem gibt es die Möglichkeit, eigene Machine Learning Algorithmen zu trainieren, alles in einer Anwendung.

Was macht Fabric besonders?

Unternehmen kämpfen mit komplexen Datenstrukturen und vielen kleinen Anwendungen. Das ist nicht nur teuer, sondern auch zeitraubend. Bei beidem hilft Fabric. Durch die einheitliche Plattform wird die Datenstruktur übersichtlicher und lässt sich von Administratoren leichter verwalten.

Bei immer größer werdenden Datenmengen verliert man schnell den Überblick. Welche Daten kommen woher? Wo werden sie von wem verwendet? Data Lineage ermöglicht es, diese Informationen für alle Arten von Daten zu visualisieren. Fabric synchronisiert Metadaten über gespeicherte Daten und Verarbeitungsprozesse. Somit ist es in der Lage, den Weg und die Nutzung von Daten in einer Art Datenflussdiagramm abzubilden.

Wer schon einmal Microsoft Purview verwendet hat, dem sollte dies bekannt vorkommen.

Wie ist Microsoft Fabric aufgebaut?

Wie schon gesagt ist Fabric eine Plattform für viele verschiedene Anwendungsfälle und deshalb gibt es auch eine Reihe von Applikationen, die eigene Aufgaben erfüllen.

OneLake

Die grundlegende Struktur ist der OneLake in welchem alle Daten zentral gespeichert und verwaltet werden können. Er ist selber keine eigene Applikation, ist jedoch die Grundlage für alle weiteren Funktionen. Alle Daten liegen an einem Ort und die Organisation erfolgt über Workspaces (Arbeitsbereiche). Das hört sich chaotischer an, als es in der Praxis ist, da die Navigation über die einzelnen Teilbereiche läuft.

Databases

Der neuste Zuwachs von Fabric, bietet jetzt auch eine klassische TSQL-Datenbank an. Die Datenbank entspricht der bekannten Azure SQL Datenbank und kann vollständig in Fabric genutzt werden. Die grundlegendste Form der Datenverwaltung hat damit ein neues Zuhause.

Data Warehouse

Dieser Teil bietet das klassische Data Warehouse an, wie es viele Unternehmen kennen. Daten können aufbereitet und strukturiert gespeichert werden.  Des Weiteren hat man hier die Möglichkeit, externe Datenbanken in Fabric zu spiegeln, Dazu zählen bspw. Azure SQL-Datenbanken, Azure Cosmos DBs und Snowflake Datenbanken. In Zukunft soll es auch die Möglichkeit geben, On-Prem SQL Server in Fabric zu spiegeln.

Data Engineering

Auch wenn andere Bereiche von Fabric ebenfalls unter Data Engineering fallen, bildet dieser Bereich die modernsten Entwicklungen ab. Hier können Lakehouses erstellt und verwaltet werden. Diese Verwaltung erfolgt über Notebooks und Pipelines.

Data Factory

Wer schon einmal mit Azure Data Factory gearbeitet hat, der wird sich hier heimisch fühlen. Die Data Factory ist die Low Code Lösung für Data Engineering in Fabric. Dabei werden vor allem Dataflows und Pipelines erstellt. Durch über 150 Out-of-the-Box Konnektoren können verschiedene Datenquellen angebunden und ohne Code Kenntnisse verarbeitet werden.

Industry Solutions

Hier gibt es Vorlagen und Out-of-the-Box Lösungen für Industrie spezifische Probleme. So kann dieser Bereich z.B. für das verwaltungsaufwändige Thema ESG Reporting verwendet werden.

Real-Time Intelligence

Echtzeitdaten sind anders als andere Daten, es muss immer eine direkte Verbindung bestehen damit Daten in Echtzeit abgerufen werden können. Damit gehen einige Besonderheiten einher. Diese Besonderheiten werde mit Real-Time Intelligence abgefangen.

Data Science

Machine Learning ist schon längst im Alltag angekommen und in der Applikation Data Science kann es genutzt werden. Hier können Modelle trainiert und optimiert werden. Seit neustem gibt es auch AutoML, um wie in Azure ML Studio automatisierte Modelle zu trainieren.

Power BI

Den meisten ist Power BI ein Begriff, da es das bekannteste Programm für Reports ist. In Fabric würde es eingegliedert und bildet den Data Analytics Teil ab. Die vorher aufbereiten Daten kommen hier an und können in einem Bericht dargestellt werden.

Was unterscheidet Microsoft Fabric von anderen Produkten?

Der größte Vorteil von Fabric ist klar die Größe. Alle datenbezogenen Probleme können in einer Umgebung gelöst werden. Das heißt auch, nicht alles muss auf einmal gemacht werden.  Wenn ein Unternehmen schon eine solide Datenbasis hat, dann kann auch bspw. nur Power BI genutzt werden. Und wenn man schon Power BI nutzt, kann man Stück für Stück alle Daten nachziehen, das schafft eine ordentliche und schnelle Lösung für die gesamte Datenlandschaft.

In einigen anderen Blogbeiträgen haben wir schon diverse Vergleiche gezogen, wenn dich Azure und Microsoft Fabric interessieren ist Fabric vs Synapse etwas für dich. Sonst interessiert dich Fabric vs Databricks vielleicht. Das Thema Fabric behandeln wir zudem auf unserem YouTube Kanal regelmäßig, wenn du tiefer einsteigen möchtest, ist das der ideale Weg.

Für diejenigen unter euch denen besonders die Kosten am Herzen liegen haben wir schon einen Blogbeitrag zur Kostenstruktur geschrieben.

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

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

In modernen Unternehmen fallen täglich große Datenmengen aus verschiedenen internen und externen Quellen an. Um auf Basis dieser Daten geschäftskritische Entscheidungen treffen zu können, müssen die Daten in ein einheitliches Format gebracht werden. Dieser Prozess wird auch als ETL-Prozess bezeichnet und gliedert sich in die folgenden drei Schritte. Extract (Extraktion der Rohdaten aus verschiedenen Quellen), Transform (Überführung der Rohdaten in ein einheitliches Format) und Load (zentrale Bereitstellung der Daten). In diesem Beitrag werde ich Schritt für Schritt erläutern, wie ein ETL in Azure Synapse Analytics implementiert werden kann.

Warum Daten in der Cloud und nicht Lokal speichern?

Warum immer mehr Unternehmen den Weg in die Cloud finden, zeigt eine Reihe von Vorteilen, die die Cloud bietet:

• Skalierbarkeit: Die Cloud bietet die Möglichkeit, die Ressourcen an den eigenen Bedarf anzupassen, ohne Änderungen an der Infrastruktur vornehmen zu müssen.
• Kosteneffizienz: Da die Ressourcen an den eigenen Bedarf angepasst werden können, müssen Unternehmen keine Überkapazitäten vorhalten, um eine überdurchschnittliche Auslastung zu bewältigen. Stattdessen können die Ressourcen in solchen Fällen dynamisch erhöht werden, so dass nur die tatsächlich benötigte Kapazität bezahlt werden muss.
• Sicherheit: Microsoft hat robuste Sicherheitsmaßnahmen wie zum Beispiel VPNs implementiert, um die Daten während der Übertragung zu schützen. Darüber hinaus bietet die Azure-Cloud fortschrittliche Zugriffskontrollfunktionen, um sicherzustellen, dass nur autorisierte Benutzer auf die Daten zugreifen können.
• Flexibilität: Durch die Speicherung der Daten in der Cloud können die Mitarbeiterinnen und Mitarbeiter von überall auf die Daten zugreifen, solange sie über eine Internetverbindung verfügen. Zudem lassen sich Cloud-Dienste nahtlos in bestehende Systeme integrieren. Dadurch können Unternehmen ihre bestehenden Investitionen nutzen und neue Technologien schnell einführen, ohne komplexe Integrationen oder Anpassungen vornehmen zu müssen.

ETL in Azure Synapse

Azure Synapse ist eine Cloud-basierte Datenanalyseplattform von Microsoft, die Datenverarbeitungs- und Analysedienste in einer einzigen Umgebung vereint. Sie ermöglicht es Unternehmen, große Mengen strukturierter und unstrukturierter Daten aus verschiedenen Quellen zu sammeln, zu speichern, zu verarbeiten und zu analysieren. In diesem Blogbeitrag werde ich den ETL-Prozess in Azure Synapse Analytics (Extract, Transform, Load) in Synapse anhand einer Azure SQL-Datenbank erläutern. In diesem Beispiel arbeite ich mit den Beispieldaten der Azure SQL Datenbank, die die Geschäftsdaten eines virtuellen Fahrradladens repräsentieren.

Um einen ETL-Prozess in Azure Synapse Analytics zu implementieren, müssen wir zunächst einen Dedicated SQL Pool einrichten. Der Dedicated SQL Pool (früher auch SQL Datawarehouse genannt) ist ein sogenanntes Massively Parallel Processing oder kurz MPP. Dabei handelt es sich um eine moderne Datenbankarchitektur, bei der eine große Anzahl von Prozessoren parallel arbeitet, um die Daten in kleinere Teile aufzuteilen und diese gleichzeitig zu verarbeiten. In diesem SQL-Pool werden wir später unsere Daten speichern.

Linked Service

Nun müssen wir in Synapse eine Verbindung zu unserer Azure Datenbank herstellen. Dazu klicken wir in der linken Menüleiste auf Manage und dann auf „Linked services„. Wenn wir dann auf „New“ klicken, öffnet sich ein Menü, in dem wir auswählen können, mit welcher externen Datenquelle wir uns verbinden möchten. Für unser Beispiel wählen wir „Azure SQL Database“.

Im nächsten Fenster können wir die Anmeldedaten für unsere SQL Datenbank angeben. Dazu muss die Azure Subscription der Datenbank angegeben werden, sowie der Servername und die gewünschte Art der Authentifizierung. Für dieses Beispiel habe ich die SQL Authentication gewählt, bei der man sich mit einem Benutzernamen und einem Passwort anmeldet. Nun könnt ihr unten rechts auf den Button „Test Connection“ klicken, um zu testen, ob die Verbindung erfolgreich hergestellt werden kann. Ist dies der Fall, könnt ihr auf den „Create Button“ klicken, um die Verbindung zu erstellen.

Auf die gleiche Weise können wir nun eine Verbindung zu unserem soeben erstellten SQL-Pool herstellen. Dazu erstellen wir wieder einen neuen Linked Service, wählen aber diesmal „Azure Synapse Analytics“ aus der Liste der möglichen Verbindungen aus. Unter „Azure subscription“ wählen wir wieder unsere Subscription und unter „Server name“ unseren Synapse Workspace aus, in den wir die Daten schreiben wollen. Bei „SQL Pool“ sollte automatisch unser gerade angelegter Dedicated SQL Pool erscheinen. Unter „Authentication Type“ wählen wir nun die Option „System Assigned Managed Identity„. Dabei handelt es sich um einen Mechanismus in Microsoft Azure, mit dem Ressourcen innerhalb eines Azure Service eine Identität erhalten können. Diese Identität kann verwendet werden, um sicher auf andere Azure Ressourcen zuzugreifen, ohne Anmeldeinformationen wie Benutzername und Passwort einbinden zu müssen.

Copy Data Task

Nun können wir wieder mit dem „Test connection Button“ testen, ob die Verbindung erfolgreich war. Ist dies der Fall, können wir wieder auf Create klicken, um den Linked Service zu erstellen. Nachdem der Linked Service erstellt wurde, kehren wir zum Ausgangsbildschirm zurück und können im linken Menü den Punkt „Integrate“ und dann das Plus-Symbol auswählen, um eine neue „Copy Data Task“ zu erstellen.

Im folgenden Assistenten können wir im zweiten Menüpunkt die Quelle angeben, aus der die Daten kopiert werden sollen. Dazu geben wir unter „Source type“ wieder „Azure SQL Database“ an und wählen unter „Connection“ unseren zuvor erstellten „Linked service“ aus. Wenn die Verbindung zur Datenbank erfolgreich war, werden nun im unteren Fenster alle Tabellen der Datenbank aufgelistet. Hier wähle ich nun alle Tabellen aus, die ich aus der Datenbank in Synapse importieren möchte. Auf der nächsten Seite kann nun unser zuvor erstellter Azure Synapse Linked Service als Ziel für unsere Daten ausgewählt werden.

Quell- und Zieltabellen mappen

Unter dem Punkt Dataset können nun die Tabellen ausgewählt werden, in die die Daten geschrieben werden sollen. Standardmäßig legt Synapse hier automatisch Tabellen im Ziel an, die genau so heißen wie in der Datenquelle und die gleichen Spaltentypen haben. Unter dem Punkt „Konfiguration“ können nun die einzelnen Spalten aufeinander abgebildet werden. Auch hier legt Synapse automatisch die gleichen Spalten wie in der Quelltabelle an und mappt die passenden Spalten aufeinander. Wichtig ist hier, dass wir die Option „Type conversion“ deaktivieren. Nachdem wir dies getan haben, können wir mit dem „Next Button“ zum „Settings“-Bildschirm gelangen.

Auf diesem Bildschirm kann unter anderem die Kopiermethode ausgewählt werden, mit der die Daten in die Quelle kopiert werden sollen. Mit der Option „Data consistency verification“ werden nach dem Import der Daten zusätzliche Überprüfungsfunktionen angewendet, um sicherzustellen, dass alle Daten erfolgreich kopiert wurden. Unter anderem werden die Dateigrößen und die Anzahl der Zeilen in Quelle und Ziel verglichen. Da wir jedoch als Kopiermethode „Copy command“ gewählt haben, können wir die Option „Data consistency verification“ nicht aktivieren. Unter „Logging settings“ können die Einstellungen für die Protokollierung während des Kopiervorgangs vorgenommen werden. Mit der Option „Storage connection name“ können wir den Linked Service angeben, der die Verbindung zum Storage speichert, in dem die Logdateien gespeichert werden. Wenn ich auf „New“ klicke, öffnet sich ein Fenster, in dem ich die Verbindung zum Storage erstellen kann.

Azure Blob Storage

In diesem Fenster wird die Verbindung zu einem Azure Blob Storage definiert. Dazu wähle ich wieder meine Azure Subscription und einen Standard Storage Account meiner Subscription aus. Anschließend teste ich die Verbindung erneut und klicke auf „Create“.

Anschließend aktiviere ich noch die Option „Enable staging“. Dies ist der Storage account in dem die Staging Tabellen gespeichert werden und bei der Option „Storage connection name“ kann der Linked Service für den „Staging Storage“ angegeben werden. Die Staging Area ist ein temporärer Speicherbereich, in dem Daten vorübergehend zwischengespeichert werden, um sie zu transformieren oder zu überprüfen, bevor sie in die endgültige Datenbank geschrieben werden. Für das Staging wähle ich den gleichen Linked Service wie für die Speicherung der Logfiles. Wie oben beschrieben, wähle ich als Kopiermethode „Copy command“. Danach wähle ich „Next“ und komme zum „Review and finish“ Screen, wo wir unsere Einstellungen noch einmal überprüfen können. Danach können wir unser „Copy Data Tool“ starten. Auf dem nächsten Bildschirm können wir sehen, welche Schritte des Deployments gerade ausgeführt werden und ob sie erfolgreich waren.

Wenn alle Schritte erfolgreich waren, haben wir unsere Pipeline erstellt, mit der wir Daten von einem Azure SQL Server in unseren Synapse Studio Workspace schreiben können. Der nächste Schritt wäre nun, einen Trigger für die Pipeline zu erstellen. Ein Trigger kann eine Pipeline automatisch starten. Zum Beispiel könnten wir für unsere neue Pipeline einen Trigger einrichten, der die Pipeline automatisch einmal am Tag durchlaufen lässt. Und mit dieser Pipeline können wir einen automatischen ETL-Prozess in Azure Synapse Analytics abbilden.

ETL oder ELT?

ETL (Extract, Transform, Load) und ELT (Extract, Load, Transform) sind zwei unterschiedliche Ansätze zur Datenintegration, die in Datenintegrationsprojekten verwendet werden. Der ETL-Transformationsprozess ermöglicht es Unternehmen, Daten zu bereinigen, zu harmonisieren und zu verbessern, um sie für die Verwendung in Data Warehouses oder anderen Zielspeichermedien vorzubereiten. Dazu gehört auch das Entfernen von Dubletten, so dass überflüssige Daten gar nicht erst in den Zielspeicher geladen werden müssen.

Beim ELT hingegen werden die Rohdaten in den Zielspeicher geladen, was das sogenannte Massively Parallel Processing oder kurz MPP ermöglicht. Dabei handelt es sich um eine moderne Architektur, bei der eine große Anzahl von Prozessoren parallel arbeitet. Dadurch werden die Daten in kleinere Teile aufgeteilt und können so gleichzeitig verarbeitet werden. Ein weiterer Vorteil von ELT ist die Flexibilität bei der Datentransformation. Da die Daten direkt in das Zielspeichermedium geladen werden, können Transformationen und Datenverarbeitungsschritte direkt auf die geladenen Daten angewendet werden. Dies ermöglicht es Unternehmen, komplexe Analysen und Berichte direkt auf den Rohdaten durchzuführen, ohne dass separate Transformationsschritte erforderlich sind.

Insgesamt bieten sowohl der ETL- als auch der ELT-Ansatz Vorteile für Datenintegrationsprojekte. Die Wahl zwischen beiden hängt von den spezifischen Anforderungen, der Arbeitslast und den Zielen eines Unternehmens ab. ETL bietet die Möglichkeit, Daten vor dem Laden in das Zielspeichermedium zu transformieren und zu bereinigen. ELT hingegen ermöglicht das direkte Laden von Daten, gefolgt von flexiblen Transformationen auf den Rohdaten. Letztendlich ist es wichtig, den Anwendungsfall sorgfältig zu prüfen, um die beste Lösung für die jeweiligen Anforderungen auszuwählen.

Der Beitrag ETL in Azure Synapse Analytics erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Die Unterschiede von Azure Synapse Analytics und Azure Data Factory

Kunden fragen oft, welche der beiden Azure Cloud-Produkte, Azure Synapse Analytics oder Azure Data Factory, verwendet werden sollte. Es ist jedoch schwierig, diese Frage zu beantworten, da es stark von den spezifischen Anforderungen des Datamanagements und der Umgebung abhängt. Es gibt keine klare Antwort, ob eines dieser Produkte besser ist als das Andere. Beide Technologien können Unternehmen sowohl Kosten sparen, als auch völlig neue Möglichkeiten beim Verarbeiten ihrer Daten bieten. Um Ihnen bei Ihrer Entscheidungsfindung zu helfen, vergleichen wir hier deshalb die beiden Produkte.

Synapse vs ADF: Ein kurzer Überblick

Was ist Azure Synapse Analytics?

Azure Synapse Analytics ist eine umfassende Analyseplattform von Microsoft, die Data Warehousing und Big Data-Analyse in einer einzigen Lösung integriert. Früher als SQL Data Warehouse bekannt, bietet Synapse Analytics massiv parallele Verarbeitung (MPP), um schnelle und skalierbare Abfragen im Data Warehouse-Kontext zu ermöglichen. Es ermöglicht auch die nahtlose Integration von Big Data, so dass Unternehmen verschiedene Datentypen für umfassende Analysen kombinieren können. Mit Synapse Analytics können Benutzer komplexe Analysen durchführen und gleichzeitig die Flexibilität eines Data Lake nutzen.

Was ist Azure Data Factory?

Die Azure Data Factory (ADF) ist ein Cloud-basierter Dienst von Microsoft, der Unternehmen bei der effizienten Integration und Transformation von Daten unterstützen soll. Mit der ADF können Nutzer Datenpipelines erstellen, die verschiedene Datenquellen nahtlos verbinden und transformieren. Dies ermöglicht einen reibungslosen Datentransfer zwischen verschiedenen Systemen und Plattformen. ADF bietet eine benutzerfreundliche grafische Oberfläche, die es auch Nicht-Entwicklern ermöglicht, komplexe ETL-Aufgaben (Extract, Transform, Load) durchzuführen. Durch die Integration mit anderen Azure-Diensten können Nutzer umfassende Datenlösungen erstellen und verwalten.

Vorteile Synapse gegenüber ADF

Azure Synapse Analytics zeichnet sich durch seine massiv-parallele Verarbeitung (MPP) aus, die schnelle Analysen im Data-Warehouse-Kontext ermöglicht. Es bietet auch eine hervorragende Skalierbarkeit und Leistung, insbesondere in Umgebungen, in denen große Datenmengen verarbeitet werden müssen. Die nahtlose Integration von Big Data ermöglicht es Unternehmen, umfassende Analysen über mehrere Datenquellen hinweg durchzuführen, was Synapse zu einer leistungsstarken Lösung für fortgeschrittene Analyseanforderungen macht.

Vorteile ADF gegenüber Synapse

Azure Data Factory zeichnet sich durch seine Flexibilität bei der Datenintegration aus. Sie ermöglicht die Verbindung verschiedener Datenquellen und die einfache Implementierung von Datenpipelines. Die einfache Benutzeroberfläche ermöglicht es auch technisch weniger versierten Anwendern, Datenintegrationsaufgaben durchzuführen. Die ADF eignet sich besonders für Unternehmen, die eine flexible und skalierbare Lösung für die Datenintegration benötigen, ohne auf die umfangreichen Analysefunktionen eines Data Warehouse zurückgreifen zu müssen.

Gemeinsamkeiten

Azure Data Factory (ADF) und Azure Synapse Analytics haben trotz unterschiedlicher Schwerpunkte einige Gemeinsamkeiten. Beide Dienste sind integraler Bestandteil der Microsoft Azure Cloud und bieten eine nahtlose Integration mit anderen Azure-Diensten. Darüber hinaus unterstützen sie skalierbare Architekturen, die es Unternehmen ermöglichen, wachsende Datenmengen zu bewältigen. Beide Plattformen bieten auch Sicherheitsfunktionen und -mechanismen, um den Schutz sensibler Daten zu gewährleisten. Des Weiteren sind viele der Datenkonnektoren, welche von Microsoft zur Verfügung gestellt werden, gleich. Diese Gemeinsamkeiten erleichtern die Integration beider Dienste in umfassende Datenlösungen für Unternehmen.

Unterschiede

Die Unterschiede zwischen Azure Data Factory und Azure Synapse Analytics liegen vor allem in ihrem Fokus und ihren Hauptfunktionen. Während ADF sich auf die flexible Datenintegration konzentriert und die Möglichkeit bietet, Datenpipelines zu erstellen, konzentriert sich Synapse Analytics auf die umfassende Datenanalyse und Massively Parallel Processing (MPP) für Data Warehousing. Die Skalierbarkeit und Performance von Synapse Analytics ist speziell für anspruchsvolle Analysen optimiert, während ADF durch seine einfache Benutzeroberfläche und Vielseitigkeit in der Datenintegration punktet. Außerdem gibt es einige Datenkonnektoren in der ADF, welche in Synapse nicht gegeben sind.

Kostenvergleich

Faktoren wie Datenvolumen, Verarbeitungsgeschwindigkeit und benötigte Analysefunktionen beeinflussen die Kosten. Unternehmen sollten ihre Anforderungen genau analysieren und die Preismodelle beider Dienste verstehen, um eine fundierte Entscheidung zu treffen und die Kosten effektiv zu managen.
Hier finden Sie mehr Informationen zu den Preisen der ADF.
Hier finden Sie mehr Informationen zu den Preisen von Synapse.

Wann sollte welcher Dienst genutzt werden?

Die Wahl zwischen Azure Data Factory und Azure Synapse Analytics hängt von den spezifischen Anforderungen eines Unternehmens ab. ADF eignet sich gut für flexible Datenintegrationsaufgaben und bietet eine benutzerfreundliche Oberfläche. Wenn jedoch erweiterte Analysefunktionen, massiv parallele Verarbeitung und die Integration von Big Data erforderlich sind, ist Synapse Analytics die bevorzugte Wahl. Eine genaue Analyse der Geschäftsanforderungen und eine klare Definition der Ziele sind entscheidend, um die richtige Entscheidung für die Datenverarbeitung in der Azure-Cloud zu treffen.

Der Beitrag Azure Synapse Analytics vs Azure Data Factory erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Der Beitrag SQL Server 2022 erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.

Die Unterschiede von Azure Synapse Analytics und Azure Databricks

Synapse vs Databricks: Ein kurzer Überblick

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

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

Die moderne Geschäftswelt hängt zunehmend von Daten und vor allem von Datenverarbeitung ab. Das Wissen mit Daten zu arbeiten und sinnvolle Rückschlüsse ziehen zu können ist ungemein wichtig und gewinnt sogar noch an Bedeutung. Wie im letzten Blogbeitrag schon erwähnt, bietet die arelium Schulungen an, um genau dieses Wissen zu erwerben. Dafür arbeiten wir mit unserem Partner Microsoft zusammen. Microsoft bietet genau dafür den Microsoft Marketplace an. Hier kann man einige verschiedene Angebote finden und vor allem auch die Schulungen von arelium. Der Zeit sind z.B. Kurse zur Benutzung des Azure Portals vorhanden. Azure ist die Cloud Lösung von Microsoft für die Verarbeitung von Daten. Innerhalb des Azure Universums existiert auch Azure Synapse. Über diesen Kurs haben wir im letzten Blogbeitrag schon informiert. Diesen Beitrag finden Sie unter dem Link:

https://arelium.de/azure-synapse-workshop-for-free/. Hier haben wir alles wichtige zu dieser kostenlosen Schulung beschrieben. Um es kurz zusammenzufassen: Synapse ist Eine Lösung von Microsoft, um Daten auf- und vorzubereiten. Weitere Kurse behandeln z.B. das Thema der Berichtserstellung mit Microsofts Power BI. Mit uns lernen Sie auch wie sie Business Intelligence Lösungen kreieren. Wenn Sie dann mit Synapse die Daten vorbereitet haben, bringen wir Ihnen auch bei, wie Sie diese in einem Berichten verwenden können.  Mit den Microsoft Technologies ist es Ihnen Möglich dies zu erlernen.

Suche im Marketplace

Um auf diese Kurse zuzugreifen googlen Sie Microsoft Marketplace und klicken auf die entsprechende Seite. Im folgenden, tippen Sie arelium in die Suchleiste ein und schon haben Sie vollen Zugriff auf all unsere Schulungsangebote. Um die Suche einzuschränken können Sie auch nach Deutschland filtern und ebenso den entsprechenden Kursen. Sie werden sehen das eine ganze Reihe an Angeboten verfügbar ist. Wir freuen uns schon auf Ihre Anfragen. Schließlich können Sie mit uns lernen wie Sie moderne Lösungen für Ihre Anwendungen implementieren können.

Der Beitrag Microsoft Marketplace erschien zuerst auf arelium - Wir holen mehr aus deinen Daten.