Wissen – Scalefree

Tim Voßmerbäumer In Anfänger, Künstliche Intelligenz

Wird KI Ihren Data Vault Engineer ersetzen? Wir haben Conversational Analytics auf den Prüfstand gestellt

Scalefree hat untersucht, ob KI einen Data Vault Engineer ersetzen kann. Die Genauigkeit war perfekt, doch Aufwand und Leistungslücke erzählten eine andere Geschichte.

Jedes Datenteam stellt sich derzeit die gleiche Frage: Wenn KI SQL schreiben, Dokumentationen erstellen und komplexe Strukturen eigenständig abfragen kann – welche Aufgaben bleiben dann eigentlich noch für den Data Engineer?

Kann ein KI-Agent ein Raw Data Vault selbständig abfragen? Benötigt ein Unternehmen noch erfahrene Engineers, um ein Vault zu modellieren, zu dokumentieren und zu pflegen, wenn die KI dies theoretisch selbst ermitteln könnte? Wir haben das Experiment durchgeführt. Die Ergebnisse waren unerwartet.

Conversational Analytics meistern: Ein praktischer Leitfaden für Einrichtung, Test und Optimierung

Erfahren Sie, wie Sie mit den Daten Ihres Unternehmens in Alltagssprache kommunizieren und präzise, sofortige Antworten auf Basis Ihrer individuellen Kennzahlen erhalten. Dieses praxisorientierte Webinar zeigt Ihnen eine Strategie, mit der Sie KI-Halluzinationen vermeiden und zuverlässige KI-Datenassistenten implementieren – ohne umfassende, kostspielige Umstrukturierungen. Melden Sie sich zum kommenden Webinar am 16. Juni 2026 an! (Kostenlose Registrierung)

In this article:

Kommt Ihnen das bekannt vor?
Die Einrichtung hinter den Ergebnissen
Beide auf dem Prüfstand
Die Ergebnisse
Was das für Ihr Unternehmen bedeutet
Die wichtigsten Erkenntnisse
Was als Nächstes kommt

Kommt Ihnen das bekannt vor?

Ihr LinkedIn-Feed ist voll von Aussagen wie: „KI kann SQL schreiben.“ „Stellen Sie Ihren Daten einfach eine Frage.“ „Kein Engineer erforderlich.“ Und tatsächlich: Einiges davon stimmt. KI-Agenten werden zunehmend besser darin, Datenstrukturen abzufragen, für die vor zwei Jahren noch Spezialwissen nötig war.

Die Frage ist also berechtigt: Wenn eine KI durch Raw-Data-Vault-Entitäten navigieren, Hubs mit Links und Satellites verknüpfen und eine korrekte Antwort liefern kann – welche Rolle bleibt für den Data Vault Engineer?

Scalefree wollte nicht länger über diese Frage diskutieren, sondern sie messen. Gleiche Daten, identischer KI-Agent, zwei Architekturen: eine schlanke Fact Table mit neun Spalten und ein vollständiges Raw Data Vault mit zwölf Tabellen. Zwanzig Fragen wurden jeweils beiden Systemen gestellt.

Das Ergebnis bei der Genauigkeit? Gleichstand. Das Gesamtbild? Weitaus differenzierter.

Die Einrichtung hinter den Ergebnissen

Beide Agenten basierten auf Googles Gemini Data Analytics SDK, einem sofort einsatzbereiten Python-Toolkit, das sich direkt mit BigQuery verbindet und die NL2SQL-Pipeline standardmäßig abwickelt. Doch bevor einer der Agenten eine einzige Frage beantworten konnte, benötigten beide einen detaillierten Satz von Systemanweisungen: Tabellenbeschreibungen, Felddefinitionen, Glossarbegriffe, Abfragehinweise. Hinter jeder dieser Informationen steht eine Person, die die Daten gut genug kennt, um sie präzise zu beschreiben. Diese Rolle verschwindet durch KI nicht – sie wird vielmehr noch wichtiger.

So sah dies in der Praxis aus:

Die Anweisungen für die Fact Table ließen sich in einem Durchgang erstellen. Das Raw Vault erforderte die Dokumentation jedes Join-Pfads, jeden Satellite-Filters und jeder Entitätsbeziehung, bevor der Agent korrekt schlussfolgern konnte. Das bedeutete fünfmal so viel Dokumentation für das gleiche Ergebnis.

Beide auf dem Prüfstand

Der Test war so angelegt, dass er sich in der Komplexität steigerte. Die ersten fünf Fragen waren einfach: Gesamtanzahl der Buchungen, Filterung nach Bürostandort. Dann kamen Datums- und Zeitlogik: bestimmte Tage, Monatszeiträume, tägliche Aufschlüsselungen. Die mittlere Stufe betraf die Daueranalyse: durchschnittliche Buchungslängen, das längste Zeitfenster, exakte Übereinstimmungen in Minuten. Danach folgten Muster nach Wochentagen: welcher Wochentag am häufigsten genutzt wurde, wie Montage im Vergleich abschnitten. Die letzten fünf Fragen kombinierten alle Aspekte – multidimensionale Abfragen, bei denen Standort, Zeit und Ressourcentyp in einer einzigen Antwort zusammengeführt werden mussten. Hier ein Auszug aus den letzten drei Stufen:

Auszug aus der Benchmark-Test-Suite mit 20 Fragen

Eine bewusste Designentscheidung: keine personenbezogenen Daten. Namen und E-Mail-Adressen befinden sich in einem zugriffsbeschränkten Bereich des Vaults, auf den der Agent nicht zugreifen kann. Die Fact Table wurde von Anfang an entsprechend gestaltet. Ein fairer Test und saubere Data Governance.

Die Ergebnisse

Ehrlich? Niemand hatte mit einem perfekten Genauigkeitsergebnis gerechnet. Und unter uns: Als Data Vault Engineers hatten wir gehofft, dass es nicht so kommt.

Beide Architekturen beantworteten jede einzelne Frage korrekt. Der KI-Agent bewältigte ein Vault mit zwölf Tabellen inklusive Hubs, Links und Satellites genauso souverän wie eine einzelne, flache Tabelle. Das ist beeindruckend – und ein wenig ernüchternd. Es zeigt auch: Die Modellierung und Dokumentation wurden korrekt durchgeführt. Mit einer schlecht beschriebenen Struktur sind 20 von 20 Punkten unmöglich.

Doch betrachten Sie die letzten beiden Spalten: Das Raw Vault benötigte insgesamt 33 Minuten, um das zu leisten, was die Fact Table in sechs Minuten schaffte. Das entspricht durchschnittlich 1,65 Minuten pro Frage gegenüber 0,3 Minuten bei der Fact Table. Gleiches Ziel, aber fünfmal längerer Weg.

Was das für Ihr Unternehmen bedeutet

Übertragen wir diese Zahlen auf die geschäftliche Praxis:

33 Minuten Gesamtabfragezeit gegenüber sechs Minuten. Das sind durchschnittlich 1,65 Minuten pro Frage gegenüber 0,3 Minuten bei der Fact Table. Für Business-Anwender, die schnelle Antworten erwarten, ist dieser Unterschied spürbar. Und bevor überhaupt eine Abfrage lief, benötigte das Raw Vault etwa 400 Zeilen Systemanweisungen – geschrieben von jemandem, der die Daten tief genug versteht, um sie präzise zu beschreiben.

Das bedeutet nicht, dass das Raw Data Vault die falsche Wahl ist. Für das Enterprise-Datenmanagement bleibt es der Goldstandard. Doch ein KI-Agent, der direkt darauf arbeitet – ohne Semantic Layer und erfahrene Engineers – führt zu langsamen Antworten und frustrierten Nutzern.

Bauen Sie das Vault auf, und erstellen Sie darüber eine Fact Table als KI-taugliche Schicht. Diese Kombination vereint die Vorteile beider Ansätze. Sie gibt Ihrem Data Vault Engineer eine Aufgabe, die KI nicht übernehmen kann: Jemand muss die Daten gut genug kennen, um sie zu beschreiben und so modellieren, dass die KI damit arbeiten kann. Diese Rolle wird nicht verschwinden.

Die wichtigsten Erkenntnisse

Bewerten Sie Ihr KI-Setup nicht nur anhand der Genauigkeit. Berücksichtigen Sie auch Abfragezeit und Einrichtungsaufwand.
Eine gut modellierte Fact Table liefert schnelle, zuverlässige Conversational Analytics mit minimalem Aufwand.
Ein Raw Data Vault kann diese Genauigkeit erreichen, benötigt aber fünfmal mehr Dokumentation und läuft fünfmal langsamer.
Gute Dokumentation erfordert jemanden, der die Daten versteht. KI kann das nicht für Sie übernehmen – zumindest noch nicht.
Die beste Architektur für KI-Analysen ist kein Entweder-oder: Nutzen Sie das Vault für Datenintegrität und die Fact Table als KI-Schicht.
Ihr Data Vault Engineer ist kein Kostenfaktor, den man streichen kann. Er ist der Grund, warum das alles funktioniert.

Was als Nächstes kommt

Die gesamte Geschichte erfahren Sie in unserem kommenden Webinar: Conversational Analytics meistern – Ein praktischer Leitfaden für Einrichtung, Test und Optimierung. Live-Abfragen, echte Fehlerbeispiele, ein praktischer Entscheidungsrahmen – und das alles mit echten Unternehmensdaten. (Hier kostenlos registrieren)

In der Zwischenzeit teilen Sie uns gerne Ihre Situation mit: Arbeiten Sie mit einem Raw Vault, einer Fact Table oder einem anderen Ansatz? Hinterlassen Sie einen Kommentar – wir lesen alle.

Damian Hinz In Data Vault, dbt-Blogartikel, Fortgeschrittene

CI/CD: Einblicke in die Automatisierung von Data Vault 2.0 mit dbt

CI/CD

CI/CD-Pipelines werden immer wichtiger, um sicherzustellen, dass Software-Updates kosteneffizient und bei gleichbleibend hoher Qualität veröffentlicht werden können. Aber wie genau funktionieren CI/CD-Pipelines und wie kann ein Projekt von ihrem Einsatz profitieren?

Dieser Newsletter beantwortet diese Fragen anhand des praktischen Beispiels einer CI/CD-Pipeline. Das Beispiel konzentriert sich auf eine CI/CD-Pipeline für ein GitHub-Repository, das ein Paket zur Implementierung von Data Vault 2.0 in dbt für verschiedene Datenbanken enthält. Daher befasst sich dieser Newsletter auch mit den Grundlagen von dbt und GitHub Actions.

Von Continuous Integration zu Data Vaults: Ein umfassender Workflow

In diesem Webinar wird erklärt, was CI/CD-Pipelines sind und welche Vorteile sie bieten. Wir werden Teile der CI/CD-Pipeline für das öffentliche datavault4dbt-Paket vorstellen, um zu demonstrieren, wie eine CI/CD-Pipeline genutzt werden kann. Das Webinar stellt die wichtigsten Funktionen von GitHub Actions vor und erläutert diese anhand von Beispielen. Dies zeigt, wie jede Funktion in der Praxis eingesetzt werden kann, und hebt die vielfältigen Möglichkeiten hervor, die GitHub Actions bietet. Ziel des Webinars ist es, die Vorteile von CI/CD-Pipelines zu erläutern und anhand eines praktischen Beispiels zu veranschaulichen, wie eine solche Pipeline aussehen kann.

Watch Webinar Recording

In this article:

Was ist CI/CD?
Einführung in dbt
Die Funktionen von GitHub Actions
Praktisches Beispiel: CI/CD-Pipeline für datavault4dbt
Fazit

Was ist CI/CD?

CI steht für Continuous Integration und CD steht für Continuous Delivery oder Continuous Deployment. Aber was genau bedeuten diese Begriffe?

Continuous Integration bezieht sich auf das regelmäßige Zusammenführen von Codeänderungen, bei dem automatisierte Tests durchgeführt werden, um potenzielle Fehler frühzeitig zu erkennen und sicherzustellen, dass die Software in einem funktionsfähigen Zustand bleibt.

Continuous Delivery beinhaltet die Bereitstellung des validierten Codes in einem Repository. Zu diesem Zweck sollten bereits CI-Tests in der Pipeline durchgeführt werden. Es umfasst auch weitere Automatisierungen, die für eine schnelle Bereitstellung erforderlich sind, wie beispielsweise die Erstellung eines produktionsreifen Builds. Der Unterschied zwischen Continuous Delivery und Continuous Deployment besteht darin, dass bei Continuous Deployment die erfolgreich getestete Software direkt in die Produktion überführt wird, während Continuous Delivery alles für die Freigabe vorbereitet, ohne sie automatisch bereitzustellen.

Continuous Deployment ermöglicht es, Änderungen durch viele kleine Releases statt durch ein einziges großes Release schnell zu implementieren. Die Tests müssen jedoch gut konfiguriert sein, da es keine manuelle Freigabe für den Übergang in die Produktion gibt.

CI/CD-Pipelines bieten durch Automatisierung eine immense Zeitersparnis. Auch die Kosten für Ressourcen, die für manuelle Tests benötigt werden, sind bei CI/CD-Pipelines geringer, da sie so konfiguriert werden können, dass Ressourcen nur für die Tests hochgefahren und danach wieder heruntergefahren werden. Da keine permanenten Ressourcen erforderlich sind, zahlen Sie nur für die Ressourcen, die während der Testlaufzeit benötigt werden.

Einführung in dbt

Die Abkürzung dbt steht für „data build tool“. Dbt ist ein Werkzeug, das die Datentransformation direkt in einem Data Warehouse ermöglicht. Es nutzt SQL-basierte Transformationen, die direkt in der dbt-Umgebung definiert, getestet und dokumentiert werden können.

Dies macht dbt zu einer hervorragenden Wahl für die Implementierung von Data Vault 2.0, da dbt verwendet werden kann, um die von Data Vault benötigten Hubs, Links und Satellites zu erstellen und zu verwalten.

Um diesen Prozess zu erleichtern, haben wir bei Scalefree das Paket datavault4dbt entwickelt. Datavault4dbt bietet viele nützliche Funktionen, wie vordefinierte Makros für Hubs, Links, Satellites, die Staging Area und vieles mehr.

Für ein tieferes Verständnis von dbt oder datavault4dbt finden Sie tiefergehende Informationen in unseren Artikeln zu diesem Thema.

Die Funktionen von GitHub Actions

GitHub Actions ist eine Funktion von GitHub, mit der Sie Workflows direkt in GitHub-Repositories erstellen und ausführen können. Sie können verschiedene Trigger für Workflows definieren, wie z. B. Pull Requests, Commits, Zeitpläne, manuelle Trigger und mehr.

Dies macht GitHub Actions ideal für den Aufbau von CI/CD-Pipelines sowohl für private als auch für öffentliche Repositories. Die Workflows sind in mehrere Jobs unterteilt, die jeweils aus mehreren Schritten bestehen. Jeder Job läuft auf einer anderen virtuellen Maschin

Innerhalb dieser Schritte können Sie benutzerdefinierte Aufgaben definieren oder externe sowie interne Workflows nutzen. Dies bietet den großen Vorteil, dass Sie in einem Workflow nicht jeden Schritt von Grund auf neu entwickeln müssen, sondern auf öffentliche Workflows zurückgreifen können, die von anderen erstellt wurden.

Die nahtlose Integration von Docker bietet zudem zahlreiche Möglichkeiten, wie beispielsweise das schnelle Einrichten verschiedener Testumgebungen, was die Erstellung einer CI/CD-Pipeline erheblich vereinfacht.

GitHub Actions ist das zentrale Werkzeug im folgenden Beispiel einer CI/CD-Pipeline.

Praktisches Beispiel: CI/CD-Pipeline für datavault4dbt

Für das öffentliche Repository des datavault4dbt-Pakets haben wir eine CI/CD-Pipeline aufgebaut, um sicherzustellen, dass alle Funktionen bei jedem Pull Request (PR) auf allen unterstützten Datenbanken weiterhin funktionieren. Wenn ein PR von einem externen Benutzer eingereicht wird, muss jemand aus unserem Entwicklerteam den Start der Pipeline genehmigen. Im Gegensatz dazu kann die Pipeline bei einem PR eines internen Benutzers automatisch durch das Hinzufügen eines bestimmten Labels gestartet werden.

Sobald die Pipeline ausgelöst wird, startet GitHub Actions automatisch eine separate virtuelle Maschine (VM) für jede Datenbank. Derzeit unterstützt das datavault4dbt-Paket AWS Redshift, Microsoft Azure Synapse, Snowflake, Google BigQuery, PostgreSQL und Exasol, sodass insgesamt sechs VMs gestartet werden. Da GitHub Actions serverless arbeitet, müssen diese VMs nicht manuell eingerichtet oder verwaltet werden.

The VMs then connect to the required cloud systems. For instance, the VM for Google BigQuery connects to Google Cloud, while the VM for AWS Redshift connects to AWS. Subsequently, the necessary resources for each database are generated, which can be done via API calls or using tools like Terraform.

Nach der Erstellung der Ressourcen werden zusätzliche, für die Tests benötigte Dateien generiert und auf die VM geladen. In unserer Beispiel-Pipeline gehören dazu Dateien wie die profiles.yml, die alle für die dbt-Verbindung zu den Datenbanken erforderlichen Informationen enthält.

Als Nächstes wird auf jeder VM ein Dockerfile verwendet, um ein Image zu erstellen, das automatisch alle Abhängigkeiten für die jeweilige Datenbank installiert. In dieser Phase wird auch Git auf jedem Image installiert, damit in einem separaten Git-Repository gespeicherte Tests auf das Image geladen werden können.

Das Laden der Tests aus einem Repository ermöglicht eine zentrale Verwaltung der Tests und stellt sicher, dass alle Änderungen beim nächsten Pipeline-Durchlauf für jede Datenbank ausgeführt werden. Sobald die Images erstellt sind, werden aus diesen Images Container erstellt, in denen Tests mit verschiedenen Parametern durchgeführt werden. Nach Abschluss aller Tests werden die Container heruntergefahren und die Ressourcen bei den jeweiligen Cloud-Anbietern standardmäßig gelöscht.

Die Testergebnisse sind in GitHub Actions vollständig sichtbar, wobei erfolgreiche und fehlgeschlagene Tests klar gekennzeichnet sind.

Wenn die Pipeline manuell gestartet wird, besteht zusätzlich die Möglichkeit festzulegen, ob nur bestimmte ausgewählte Datenbanken getestet werden sollen und ob die Ressourcen in den Cloud-Systemen nach den Tests erhalten bleiben sollen. Dies ermöglicht es Entwicklern, die Daten in den Datenbanken im Fehlerfall genauer zu untersuchen.

Diese Pipeline bietet zahlreiche Vorteile für die Entwicklung des datavault4dbt-Pakets. Sie ermöglicht es, bei jeder Änderung auf allen unterstützten Datenbanken nach Fehlern zu suchen, ohne viel Zeit für die Erstellung von Testressourcen aufwenden zu müssen. Gleichzeitig spart sie Kosten, da alle Ressourcen nur so lange wie nötig laufen und nach den Tests sofort heruntergefahren werden.

Die Verwaltung der Pipeline wird auch durch GitHub vereinfacht, da alle Variablen und Secrets direkt in GitHub gespeichert werden können, wodurch alle Konfigurationen an einem zentralen Ort gebündelt sind. Sobald die Pipeline eingerichtet ist, kann sie problemlos um zusätzliche Datenbanken erweitert werden, die in Zukunft unterstützt werden könnten.

Letztendlich ist dies nur ein Beispiel dafür, wie eine CI/CD-Pipeline aussehen kann. Solche Pipelines sind so vielfältig wie die Software, für die sie konzipiert sind. Wenn wir Ihr Interesse geweckt haben und Sie weitere Fragen zu einer möglichen Pipeline für Ihr Unternehmen haben, können Sie uns gerne kontaktieren.

Fazit

Dieser Newsletter beleuchtet die Vorteile und Funktionsweisen von CI/CD-Pipelines in der agilen Softwareentwicklung. Veranschaulicht an einem praktischen Beispiel mit einem GitHub-Repository und einem dbt-Paket zur Implementierung von Data Vault 2.0, zeigt er, wie Werkzeuge wie GitHub Actions die Automatisierung und Effizienz in Bereitstellungsprozessen steigern können.

Ole Bause In Anfänger, Data Warehouse, Künstliche Intelligenz

KI im Data Warehousing: Prinzipien und Anwendungen

KI im Data Warehousing

Die Fähigkeit, Daten effizient zu speichern, zu verwalten und zu analysieren, ist für jedes Unternehmen zu einem kritischen Erfolgsfaktor geworden. Der Bereich des Data Warehousing ist ein integraler Bestandteil dieses Prozesses, da er eine strukturierte, zentralisierte Speicherung großer Datenmengen bietet und ein wichtiges Element der Business Intelligence darstellt. Die zunehmende Menge und Komplexität der Daten stellt das Management jedoch vor immer größere Herausforderungen. Dennoch prägt KI bereits viele Prozesse in den unterschiedlichsten Bereichen, einschließlich des Data Warehousing.

Dieser Artikel untersucht die grundlegenden Prinzipien und Anwendungen der Künstlichen Intelligenz und wie KI in ein Enterprise Data Warehouse integriert werden kann. Dabei wird beleuchtet, wie sie zur Verbesserung des Designs und des Betriebs von Data Warehouses eingesetzt werden kann und gleichzeitig die Entwicklung anspruchsvollerer Data-Science-Anwendungen wie Machine Learning oder Predictive Analytics ermöglicht.

KI im Data Warehousing: Prinzipien und Anwendungen

Dieses Webinar befasst sich mit den wesentlichen Prinzipien der Künstlichen Intelligenz (KI) und ihrer transformativen Rolle im Data Warehousing. Wir untersuchen, wie KI und Machine Learning (ML) nicht nur den Aufbau und den Betrieb von Data Warehouses verbessern, sondern auch die darin gespeicherten riesigen Datenmengen nutzen, um leistungsstarke Anwendungen zu entwickeln, z. B. für Predictive Analytics.

Sie lernen die grundlegenden KI-Technologien kennen, die diese Fortschritte vorantreiben, und erfahren, wie sie sich mit Data Science und Machine Learning überschneiden, um die Datenspeicherung zu optimieren, die Entscheidungsfindung zu verbessern und neue geschäftliche Erkenntnisse zu gewinnen. Dieses Webinar bietet wertvolle Perspektiven für die Integration dieser Technologien in Ihre Data-Warehousing-Methoden.

Watch webinar recording

In this article:

Grundlegende Prinzipien der KI
Die Rolle der KI beim Aufbau von Data Warehouses
- Verbesserung von Design und Struktur
- Automatisierung von Datenintegration, -bereinigung und -transformation
Nutzung eines Data Warehouse für KI-Anwendungen
- Verbesserung der KI-Fähigkeiten mit Data Vault
Fazit

Grundlegende Prinzipien der KI

Lassen Sie uns zunächst den Begriff der Künstlichen Intelligenz sowie andere Begriffe wie Machine Learning, Deep Learning oder Generative KI einordnen, um den Kontext zu verdeutlichen und zu klären, was sich genau hinter diesen Begriffen verbirgt.

Künstliche Intelligenz ist heute eher ein Oberbegriff und repräsentiert ein breites Feld. Im Allgemeinen umfasst der Begriff KI Techniken, die es Computern ermöglichen, menschliches Verhalten nachzuahmen, sodass sie lernen, Sprache zu verstehen, Entscheidungen zu treffen, Muster zu erkennen und komplexe Probleme auf eine Weise zu lösen, die der menschlichen Intelligenz ähnelt.

Machine Learning (ML) als Teilbereich der KI

Machine Learning ist ein Teilbereich der Künstlichen Intelligenz und, auch wenn der Begriff weniger präsent sein mag, einer der wichtigsten. Machine Learning nutzt fortschrittliche Techniken und Algorithmen, um Muster in großen Datenmengen zu erkennen. Dies ermöglicht es Maschinen, autonom zu lernen und sich anzupassen, um auf Basis der Daten Rückschlüsse oder Vorhersagen zu treffen. Im Gegensatz zur traditionellen Programmierung, bei der Aufgaben auf der Grundlage klarer und definierter Anweisungen ausgeführt werden, stützt sich Machine Learning auf statistische Analysen von Eingabedaten, um Ergebnisse innerhalb eines erwarteten Bereichs auszugeben. Im Wesentlichen ermöglicht es Machine Learning Computern, aus Daten zu lernen und diese zu interpretieren, ohne für jeden einzelnen Fall explizit programmiert zu werden.

Deep Learning (DL) – Ein tieferer Einblick in ML

Deep Learning ist ein spezialisierter Teilbereich des Machine Learning und der KI und nutzt tiefe neuronale Netze, um tiefgehende Datenverarbeitungsaufgaben zur Erkennung komplexer Muster durchzuführen.

Deep Learning nutzt viele Schichten, um komplexe Merkmale aus Rohdaten als Eingabe zu extrahieren, was in gewisser Weise die Funktionsweise des menschlichen Gehirns simuliert.

In dieser Hinsicht ist Deep Learning besonders leistungsfähig bei der Verarbeitung sehr großer Datenmengen, um komplexe Muster zu erlernen und so die unterschiedlichsten Aufgaben zu lösen. Bekannte Beispiele hierfür sind Aufgaben wie die Bild- oder Spracherkennung, die heute jedes moderne Smartphone beherrscht.

Generative KI – Der kreative Aspekt des Deep Learning

Generative KI ist ein Begriff, der in letzter Zeit vor allem durch ChatGPT sehr bekannt geworden ist. Generative KI ist ein Teilbereich des Deep Learning und umfasst Deep-Learning-Modelle, die neue Inhalte wie Texte, Bilder, Code oder sogar Videos auf Basis der Daten generieren, mit denen sie trainiert wurden. Sie sind in der Lage, ohne explizite Anweisungen neuartige Ergebnisse zu erzeugen, die die Trainingsdaten nicht direkt replizieren. Dies eröffnet völlig neue Möglichkeiten, wie beispielsweise die Erstellung langer Texte, komplexer Bilder oder sogar Musik.

Die Rolle der KI beim Aufbau von Data Warehouses

KI verändert alles, auch das Data Warehousing. Dabei kann sie dazu beitragen, die Effizienz und Effektivität Ihres Data Warehouses von Grund auf zu steigern. Vom Design und der Struktur bis hin zu den laufenden Datenmanagementprozessen gibt es viele Möglichkeiten, bei denen KI helfen kann.

KI hat das Potenzial, die größten Herausforderungen eines Data Warehouses zu bewältigen: Performance, Governance und Benutzerfreundlichkeit. Dies ist gelebte Data Intelligence, die die Art und Weise, wie Sie Ihre Daten abfragen, verwalten, steuern und visualisieren, revolutionieren wird.

Verbesserung von Design und Struktur

Die Architektur eines Data Warehouses ist von entscheidender Bedeutung, da sie eine effiziente Datenabfrage und Skalierbarkeit bei gleichbleibender Performance unterstützen muss. Durch die Analyse von Nutzungs- und Abfragemustern können KI-Algorithmen optimale Datenmodelle und Indizierungsstrategien vorschlagen. Dies beschleunigt nicht nur den Abruf von Informationen, sondern sorgt auch für eine agilere Datenhandhabung bei der Skalierung oder der Integration neuer Datenquellen.

Automatisierung von Datenintegration, -bereinigung und -transformation

Indem KI Routineaufgaben übernimmt, können sich Data Engineers auf anspruchsvollere Aufgaben wie den Entwurf von Datenmodellen, das Trainieren von Machine-Learning-Algorithmen und die Erstellung von Datenvisualisierungen konzentrieren. Beispielsweise nutzt The Coca-Cola Company KI-gestützte ETL-Tools, um Datenintegrationsaufgaben in ihrer gesamten globalen Lieferkette zu automatisieren und so die Beschaffungs- und Einkaufsprozesse zu optimieren.

Darüber hinaus kann KI auch die Entwickler selbst bei ihrer Arbeit unterstützen, sodass sie schneller und effizienter arbeiten können. Entwickler können KI nutzen, um Probleme in ihrem Code schneller zu beheben, indem sie auf KI-basierte Codegenerierung und -analyse wie GitHub Copilot zurückgreifen. Dieser vervollständigt, refaktoriert und debuggt Code in Echtzeit direkt in der IDE.

Auch das Performance-Tuning von Data-Warehouse-Workloads lässt sich durch prädiktive Optimierungen automatisieren, was erhebliche Kosten einsparen kann.

KI kann auch die Governance skalieren und automatisieren, indem sie automatisiertes Tagging, eine lückenlose Dokumentation und die Suche in natürlicher Sprache über alle Daten und Assets eines Unternehmens hinweg ermöglicht.

Dies reicht bis hin zu der Möglichkeit für Business-Anwender, natürliche Sprache zu nutzen, um mit Daten zu interagieren, Fragen zu stellen und Dashboards zu erstellen. Die Möglichkeiten sind nahezu unbegrenzt, und wir stehen erst am Anfang dieser Entwicklung.

Nutzung eines Data Warehouse für KI-Anwendungen

Die Struktur eines Data Warehouses – ein strukturiertes und zentralisiertes Repository, das Daten aus mehreren Quellen innerhalb eines Unternehmens aggregiert – macht es zur perfekten Grundlage für den Aufbau und das Trainieren von KI-Anwendungen. KI-Modelle benötigen große Mengen gut strukturierter und variabler Daten von hoher Qualität. Ein Data Warehouse bietet hierfür die perfekte Basis, um unternehmenseigene KI-Modelle zu trainieren.

Beispielsweise könnte ein Data Warehouse im Einzelhandel die jahrelange Historie von Käufen, demografischen Daten und Produktinformationen speichern. Diese Daten können genutzt werden, um KI-Modelle zu trainieren, die zukünftige Einkaufstrends vorhersagen oder personalisierte Produktempfehlungen aussprechen.

Verbesserung der KI-Fähigkeiten mit Data Vault

Insbesondere Data Vault 2.0 schafft die optimalen Voraussetzungen für das Trainieren eigener KI-Modelle durch sein strukturiertes und zuverlässiges Daten-Framework.

Hier sind einige Beispiele, wie diese Integration KI-gestützten Analysen zugutekommen kann:

Verbesserte Datenqualität: Die organisierte und auditierbare Struktur von Data Vault 2.0 sorgt für eine höhere Datenqualität und -konsistenz, was für das Trainieren präziser KI-Modelle unerlässlich ist. Saubere, gut strukturierte Datenmodelle verkürzen den Zeitaufwand für die Datenaufbereitung und erhöhen die Zuverlässigkeit von KI-Vorhersagen.
Verbesserte historische Analyse: Die umfassenden historischen Daten, die von Data Vault 2.0 erfasst werden, ermöglichen es KI-Modellen, präzisere Trendanalysen und Prognosen durchzuführen. Diese Fähigkeit ist besonders in Branchen wie dem Finanzwesen und dem Einzelhandel wertvoll, da die Analyse langfristiger Trends strategische Entscheidungen erheblich beeinflussen kann.
Datenzuverlässigkeit und Lineage: Das robuste Framework von Data Vault 2.0 gewährleistet die Datenzuverlässigkeit durch seine einzigartige Architektur, die Daten aus verschiedenen Quellen erfasst und gleichzeitig deren Lineage beibehält. Dies bedeutet, dass jeder Datenpunkt im System bis zu seinem Ursprung zurückverfolgt werden kann, was Transparenz schafft und das Vertrauen in die für KI-Modelle genutzten Daten stärkt.

Fazit

Die Integration von Künstlicher Intelligenz (KI) in das Data Warehousing steigert die Effizienz und Effektivität der Datenspeicherung, -verwaltung und -analyse erheblich. Durch den Einsatz von KI-Technologien können Unternehmen Prozesse zur Datenintegration, -bereinigung und -transformation automatisieren, was zu präziseren und schnelleren Erkenntnissen führt. Darüber hinaus sorgt die KI-gestützte Optimierung von Design und Struktur des Data Warehouses für eine verbesserte Performance und Skalierbarkeit. Der Einsatz von KI im Data Warehousing rationalisiert nicht nur die Abläufe, sondern ermöglicht es Unternehmen auch, fortschrittliche Analysen wie Machine Learning und Predictive Analytics zu nutzen, um tiefere Erkenntnisse zu gewinnen und fundierte Entscheidungen zu treffen.

Tim Kirschke In Datenwerkzeuge, dbt-Webinar, Fortgeschrittene

Skalieren Sie Ihr Data Vault-Projekt – mit dbt Mesh

dbt Mesh

Erfahren Sie, wie dbt Mesh Data Vault-Projekte in dbt Cloud optimiert, indem es eine effizientere Data Mesh-Architektur ermöglicht. Je größer ein Data-Warehouse-Projekt wird, desto mehr Personen verlassen sich auf die bereitgestellten Daten und arbeiten mit ihnen. Diese Arbeit kann im Anwenden von Geschäftsregeln, dem Modellieren von Fakten und Dimensionen oder anderen typischen Aufgaben innerhalb einer Datenumgebung bestehen. In einer großen Organisation verteilt sich diese Nutzerschaft oft über verschiedene Abteilungen, und die verarbeiteten Daten gehören möglicherweise zu unterschiedlichen Fachbereichen (Business Domains). An einem bestimmten Punkt steht die gesamte Organisation vor der Herausforderung, Data-Sharing- und Governance-Richtlinien umzusetzen, die beispielsweise verhindern, dass Benutzer aus der Vertriebsabteilung auf Daten der Finanzabteilung zugreifen. Ein Data Mesh bietet hierfür eine passende Lösung, die Organisationen bei der Bewältigung dieser Herausforderungen unterstützt. Wenn Sie mehr über Data Mesh erfahren möchten, lesen Sie hier unseren neuesten Blogartikel über Data Vault und Data Mesh hier.

Wir bieten außerdem ein Webinar genau zu diesem Thema an. Verpassen Sie es nicht und sehen Sie sich die Aufzeichnung kostenlos an!

Data Mesh-Unterstützung in dbt Cloud

Viele Organisationen tun sich schwer damit, einen Data Mesh-Ansatz in ihre Data Vault-Landschaft einzuführen. In diesem Webinar tauchen wir tief in dbt Mesh ein und zeigen Ihnen, wie Sie es in einem Data Vault-Projekt gewinnbringend einsetzen können.

Watch Webinar Recording

In this article:

Was ist dbt Mesh?
Warum sollten Sie auf andere dbt-Projekte verweisen?
Wie können Sie dbt Mesh in einem Data Vault-basierten Data Mesh nutzen?
Fazit

Was ist dbt Mesh?

dbt Mesh ist eine Funktion, mit der dbt Cloud noch effizienter mit einem Data Mesh-Ansatz funktioniert. Die bereits bekannte {{ ref() }}-Funktion ist nicht mehr nur auf Modelle innerhalb eines einzelnen dbt-Projekts beschränkt, sondern kann nun auch auf Modelle anderer dbt-Projekte verweisen.

Warum sollten Sie auf andere dbt-Projekte verweisen?

Stellen Sie sich eine große Organisation vor, die dbt Cloud für ihre Data Vault-Implementierung nutzt. Das Projekt umfasst beispielsweise 400 definierte Quellen, 2.000 implementierte Modelle und wird von 30 Entwicklern aktiv genutzt. Von diesen 30 Entwicklern arbeiten vielleicht 5 Personen gezielt an den Schichten des Business Data Vault und der Information Marts für finanzbezogene Objekte. Weitere 5 Entwickler arbeiten an denselben Schichten, jedoch für vertriebsbezogene Objekte.

Ab einem gewissen Punkt möchten Sie verhindern, dass Personen aus dem Finanzbereich Modifikationen an den vertriebsbezogenen dbt-Modellen vornehmen, weshalb eine Data Mesh-Architektur implementiert werden soll. Dies ermöglicht es der Organisation, Richtlinien bezüglich Data Sharing, Data Ownership und weiterer Governance-Maßnahmen festzulegen.

Mit dbt Mesh erhalten sowohl das Sales- als auch das Finance-Team ein jeweils eigenes dbt-Projekt. Da beide auf demselben Raw Data Vault aufbauen sollen, wird ein zusätzliches Basis-dbt-Projekt exklusiv für Staging- und Raw Data Vault-Objekte erstellt. Beide domänenspezifischen dbt-Projekte (Sales und Finance) können nun auf Raw Vault-Objekte innerhalb des Basis-dbt-Projekts verweisen, ohne die Daten physisch duplizieren zu müssen.

Wie können Sie dbt Mesh in einem Data Vault-basierten Data Mesh nutzen?

Data Contracts definieren

dbt-Modelle oder Gruppen von Modellen können nun so konfiguriert werden, dass sie Data Contracts enthalten. In den bereits bekannten .yml-Dateien lässt sich festlegen, dass Modelle öffentlich verfügbar sind (innerhalb einer Organisation), ihnen Data Owner zugewiesen werden und Tabellenschemata gesperrt werden.

Ein Basis-dbt-Projekt erstellen

In einer Data Mesh-Architektur besteht der gängigste Weg zur Implementierung von Data Vault 2.0 darin, einen gemeinsam genutzten Raw Vault als Grundlage zu nutzen, während Business Vault und Information Marts nach Fachbereichen (Business Domains) aufgeteilt sind. In dbt Mesh spiegelt sich dies in einem Basis-dbt-Projekt wider, das alle Staging- und Raw Data Vault-Objekte enthält. Nur die Raw Data Vault-Objekte werden so konfiguriert, dass andere dbt-Projekte auf sie zugreifen können, da Staging-Modelle nicht außerhalb von Raw Data Vault-Modellen verwendet werden sollten.

dbt-Projekte auf Domänenebene hinzufügen

Aufbauend auf dem Basis-dbt-Projekt des Raw Vaults kann jedes Domänenteam nun in einem eigenen dbt-Projekt arbeiten. Die Teams greifen über die erweiterte {{ ref() }}-Funktion auf den Raw Data Vault zu und müssen sich nicht um die Wartung dieser Raw Vault-Objekte kümmern. Zudem können sie definieren, welche ihrer Artefakte für andere Domänen nützlich sein könnten, und diese über eigene Data Contracts bereitstellen.

Verantwortlichkeiten verteilen

Typischerweise erstellt ein Fachanwender keine Hubs, Links und Satellites und es liegt auch nicht in seiner Verantwortung, für einen verlässlichen Raw Data Vault als Grundlage für Transformationen zu sorgen. Daher ist es wichtig, die Verantwortlichkeiten innerhalb jedes dbt-Projekts klar zu definieren. Insbesondere Objekte, die außerhalb eines Projekts geteilt werden, sollten immer über Data Contracts und definierte Owner verfügen. Dies stellt sicher, dass sich die Nutzer dieser gemeinsam genutzten Objekte darauf verlassen können.

Fazit

Alles in allem bietet dbt Mesh eine hervorragende Möglichkeit, einen echten Data Mesh-Ansatz gewinnbringend umzusetzen. Dies ist besonders relevant, wenn verschiedene Fachbereiche einer Organisation in dbt zusammenarbeiten, um verlässliche Ergebnisse zu liefern. In den meisten Szenarien ist es sinnvoll, bereits frühzeitig mit der Nutzung von dbt Mesh zu beginnen, selbst wenn Ihr Projekt noch nicht übermäßig groß ist. Klare Verantwortlichkeiten und Data Contracts helfen stets dabei, das Vertrauen in Ihre Daten zu stärken und die Transparenz zu wahren.

Hernan Revale In Anfänger, Data Vault

Konzeption des Business Vault: Schlüsselstrategien für eine effektive Datenorganisation

Konzeption des Business Vault

Data Vault 2.0 hat sich als umfassendes Framework etabliert, das Agilität, Skalierbarkeit und Anpassungsfähigkeit bietet. Im Zentrum dieses Frameworks steht der Business Vault, eine entscheidende Komponente für die effektive Datenorganisation und -analyse in modernen Unternehmen.

In diesem Artikel betrachten wir die wichtigsten Prinzipien und Strategien für die Konzeption eines robusten Business Vaults im Kontext von Data Vault 2.0.

Konzeption des Business Vault: Schlüsselstrategien für eine effektive Datenorganisation

Nehmen Sie an unserem informativen Webinar zum Thema „How to design the Business Vault?“ teil, in dem wir die entscheidende Rolle des Business Vaults innerhalb des Data-Vault-2.0-Frameworks untersuchen. Erfahren Sie, wie der Business Vault als zentrale Komponente dient, um Rohdaten in handlungsrelevante Erkenntnisse zu übersetzen. Zudem zeigen wir Ihnen, wie Sie Soft Business Rules anwenden, um die Erstellung von Endanwenderstrukturen zu rationalisieren und eine effiziente Befüllung der Information Marts sicherzustellen.

Watch webinar recording

In this article:

Data Vault 2.0 verstehen
Die Bedeutung des Business Vault
Kernkonzepte des Business Vault
Fazit

Data Vault 2.0 verstehen

Data Vault 2.0 repräsentiert einen Paradigmenwechsel in der Datenarchitektur und unterscheidet sich deutlich von traditionellen Data-Warehousing-Methoden. Seine Flexibilität und Skalierbarkeit machen das Framework ideal für Unternehmen, die sich in den komplexen Strukturen moderner Datenökosysteme bewegen.

Die Data-Vault-2.0-Architektur folgt einem mehrschichtigen Ansatz, der aus dem Staging-Layer, dem Enterprise-Data-Warehouse-Layer und dem Information-Marts-Layer besteht. Durch die Aufteilung der Datenarchitektur in mehrere Schichten können wir sowohl auf die Bedürfnisse der technischen Teams (wie Historisierung, Revisionssicherheit und Datenintegration) als auch auf die Anforderungen der Fachanwender (wie schneller Zugriff auf relevante, gut organisierte Informationen) eingehen. Dieser integrierte Ansatz gewährleistet eine harmonische Synergie zwischen technischen und geschäftlichen Zielen.

Um all diese Ziele zu erreichen, sieht Data Vault 2.0 eine Unterteilung innerhalb des Enterprise-Data-Warehouse-Layers vor: den Raw Vault und den Business Vault. Der Raw Vault empfängt und integriert die unveränderten Daten aus den Quellsystemen, während der Business Vault diese Rohdaten in aussagekräftige Erkenntnisse für eine fundierte Entscheidungsfindung übersetzt.

Die Bedeutung des Business Vault

Der Business Vault dient als Bindeglied zwischen dem Raw Vault und den Information-Mart-Schichten. Er ist ein optionaler Vault, der bedarfsgerecht auf dem Raw Vault aufbaut und in der Regel virtualisiert wird. Im Gegensatz zum Raw Vault wenden wir im Business Vault Soft Business Rules an, also Regeln, welche die Daten verändern.

Diese Schicht wird erstellt, um die Fachbereiche auf vielfältige Weise zu unterstützen, wie beispielsweise durch die Generierung von Query-Assistance-Entitäten oder durch die Vorberechnung kalkulierter Felder, die später in nachgelagerten Schichten verwendet werden. Mit anderen Worten: Der Business Vault beherbergt Daten, die durch Business-Regeln verändert wurden, um die Erstellung von Endanwenderstrukturen zu erleichtern.

Kernkonzepte des Business Vault

Ein Business Vault wird nach den Designprinzipien von Data Vault 2.0 modelliert. Dennoch muss er nicht zwangsläufig den strengen Revisionssicherheitsanforderungen des Raw Vaults folgen, da die Business-Vault-Entitäten jederzeit verworfen und neu erstellt werden können. Um eine einfachere und effizientere Befüllung der Information Marts zu ermöglichen, werden die Entitäten nur dann erstellt, wenn sie für die Fachbereiche notwendig sind. Dies ist auch der Grund, warum der Business Vault in der Regel wiederverwendbare Business-Logik enthält.

Zu den Entitätstypen, die typischerweise in einem Business Vault zu finden sind, gehören Point-in-Time- (PIT) und Bridge-Tabellen zur Query-Unterstützung, Computed Satellites oder Links zur Speicherung berechneter Daten sowie Exploration Links zur Verbindung von Hubs, die im Raw Vault nicht direkt miteinander verknüpft sind. Darüber hinaus gehören alle anderen Entitäten zum Business Vault, die auf dem Raw Vault basieren, Business-Logik nutzen und von der Information-Marts-Schicht abgefragt werden. Beispielsweise wird Business-Logik benötigt, um Instanzen desselben Objekts abzubilden, wodurch ein Business Same-as-Link entsteht.

Fazit

Im Datenmanagement umfasst Data Vault 2.0 verschiedene Aspekte wie Datenmodellierung, Methodik und Architektur. Dieses Framework zeichnet sich durch seine Vielseitigkeit aus und legt großen Wert auf Agilität und Anpassungsfähigkeit. In diesem Sinne bildet der Business Vault ein zentrales Element der Data-Vault-2.0-Architektur – er ist ein Hauptakteur für die effiziente Datenorganisation und -analyse in modernen Unternehmen.

Als flexible, optionale Schicht übersetzt der Business Vault Rohdaten unter Anwendung von Soft Business Rules in handlungsrelevante Erkenntnisse. Sein Ziel ist es, die Erstellung von Endanwenderstrukturen durch die Bereitstellung aufbereiteter Daten zu vereinfachen. Entitäten werden selektiv erstellt, wodurch wiederverwendbare Business-Logik erhalten bleibt. Im Wesentlichen stellt der Business Vault die effiziente Befüllung von Information Marts sicher, indem er sich auf geschäftskritische Daten konzentriert.

Möchten Sie mehr erfahren? Sehen Sie sich die Webinar-Aufzeichnung hier kostenlos an!

Marc Winkelmann In Data Warehouse, Fortgeschrittene

Data Vault im Data-Mesh-Ansatz

Data Vault & Data Mesh

Tauchen Sie ein in die Integration von Data Vault im Kontext von Data Mesh. Beginnen Sie die Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen mit unserem Data Vault 2.Go-Newsletter – Ihrer zentralen Anlaufstelle für (fast) alles rund um die zukunftsweisende Welt der Daten.

In dieser Ausgabe befassen wir uns eingehend mit der Integration von Data Vault 2.0 im Kontext eines Data-Mesh-Ansatzes. Begleiten Sie uns auf dieser Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen.

Data Vault im Data-Mesh-Ansatz

Dieses Webinar untersucht die Integration von Data Vault in einen Data-Mesh-Ansatz und beleuchtet die Synergie zwischen den Data-Mesh-Prinzipien und der Skalierbarkeit, Flexibilität, Resilienz sowie Interoperabilität von Data Vault. Wir betrachten die Integration von Data Vault im Kontext eines Data-Mesh-Ansatzes im Detail – eine Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen.

Watch webinar recording

In this article:

Data Mesh verstehen: Eine kurze Zusammenfassung
Data Vault im Mesh: Eine synergetische Allianz
Fazit

Data Mesh verstehen: Eine kurze Zusammenfassung

Bevor wir uns mit der Rolle von Data Vault befassen, lassen Sie uns kurz rekapitulieren, was ein Data Mesh ist. Der von Zhamak Dehghani geprägte Begriff Data Mesh beschreibt ein Architekturparadigma, das darauf abzielt, die Herausforderungen bei der Skalierung von Daten in großen Unternehmen zu bewältigen. Es fördert einen dezentralen Ansatz für das Dateneigentum (Data Ownership) und den Datenzugriff, indem es Daten als Produkt behandelt und eine domänenorientierte Self-Service-Dateninfrastruktur etabliert.

Data Vault im Mesh: Eine synergetische Allianz

Lassen Sie uns nun über Data Vault sprechen. Data Vault ist seit Langem als robuste Methodik für den Aufbau von Enterprise Data Warehouses anerkannt und hat seinen Wert bei der Erstellung skalierbarer, flexibler und resilienter Datenarchitekturen unter Beweis gestellt. Seine Integration in einen Data-Mesh-Ansatz fügt jedoch eine neue Ebene der Agilität und Effizienz hinzu.

Skalierbarkeit

Data Mesh betont die Notwendigkeit eines dezentralen Dateneigentums, was eine horizontale Skalierung der Dateninfrastruktur entscheidend macht. Data Vault fügt sich mit seiner modularen und skalierbaren Architektur nahtlos in diese Anforderung ein. Durch die Aufteilung des Data Warehouses in kleinere, überschaubare Komponenten stellt Data Vault sicher, dass das System mühelos mit steigendem Datenvolumen und zunehmender Komplexität skalieren kann.

Flexibilität

In einem Data Mesh ist jede Domäne oder Geschäftseinheit für ihre eigenen Datenprodukte verantwortlich. Hier glänzt die Anpassungsfähigkeit von Data Vault, da verschiedene Teams ihre Daten unabhängig voneinander modellieren und verwalten können. Diese Flexibilität ermöglicht schnellere Entwicklungszyklen, reduziert die Abhängigkeiten von einem zentralen Datenteam und befähigt die Domänenteams, in ihrem eigenen Tempo Innovationen voranzutreiben und zu iterieren.

Resilienz

Data Mesh führt das Konzept von Datenprodukten und -services ein und betont die Notwendigkeit von Resilienz in Datenarchitekturen. Data Vault spielt mit seinem Fokus auf die Erfassung und Verwaltung historischer Datenänderungen eine entscheidende Rolle bei der Gewährleistung der Zuverlässigkeit und Integrität von Datenprodukten. Diese historische Datenhaltung erweist sich als unschätzbar wertvoll für Audits, Compliance und das Verständnis der Datenentwicklung im Laufe der Zeit.

Interoperabilität

Ein Data Mesh befürwortet eine föderierte Datenarchitektur, in der Datenprodukte nahtlos miteinander interagieren können. Die standardisierten Modellierungstechniken und klar definierten Schnittstellen von Data Vault erleichtern es verschiedenen Domänen, zusammenzuarbeiten und Daten auszutauschen, während gleichzeitig Konsistenz und Kohärenz im gesamten Ökosystem gewahrt bleiben.

Fazit

Die Verbindung von Data Vault und Data Mesh stellt einen großen Fortschritt in der Evolution von Datenarchitekturen dar. Sie kombiniert die bewährte Zuverlässigkeit von Data Vault mit der Agilität und Skalierbarkeit eines dezentralen Data Mesh und bietet Unternehmen eine leistungsstarke Lösung für die Verwaltung ihrer stetig wachsenden und vielfältigen Datenlandschaft.

Obwohl die Integration von Data Vault in einen Data-Mesh-Ansatz zahlreiche Vorteile mit sich bringt, ist es wichtig, auch potenzielle Herausforderungen zu berücksichtigen. Die Steuerung des dezentralen Dateneigentums, die Gewährleistung einheitlicher Standards über Domänen hinweg und die Bereitstellung einer angemessenen Governance sind entscheidende Aspekte, die sorgfältig bedacht werden müssen.

Sehen Sie sich unbedingt die Webinar-Aufzeichnung zu „Data Mesh in einem Data-Vault-2.0-Ansatz“ an, um noch tiefer in das Thema einzusteigen.

Julian Brunner In Anfänger, Data Warehouse

Sicherstellung der Datenqualität in Ihrem Data Warehouse

Sicherstellung der Datenqualität

Mangelhafte Datenqualität kann zu ungenauen Erkenntnissen, fehlerhaften Entscheidungen und letztendlich zu Beeinträchtigungen des Geschäftserfolgs führen. Im Zeitalter von Big Data verlassen sich Unternehmen stark auf Data Warehouses, um riesige Informationsmengen zu speichern, zu verwalten und zu analysieren. Die Effektivität eines Data Warehouse hängt jedoch von der Qualität der darin enthaltenen Daten ab. Wie lässt sich eine hohe Datenqualität sicherstellen?

In diesem Blogartikel gehen wir auf die Bedeutung der Datenqualität in einem Enterprise Data Warehouse ein und liefern Ihnen praktische Strategien, um präzise, zuverlässige und qualitativ hochwertige Daten mit Data Vault 2.0 zu gewährleisten.

Vielleicht möchten Sie sich auch die Webinar-Aufzeichnung genau zu diesem Thema ansehen. Sehen Sie sie sich hier kostenlos an!

Sicherstellung der Datenqualität in Ihrem Data Warehouse

In der heutigen datengetriebenen Kultur verlassen sich Unternehmen stark auf ihre Data Warehouses, um fundierte Entscheidungen zu treffen. Die Effektivität eines Data Warehouse hängt jedoch von der Qualität der darin enthaltenen Daten ab. In diesem Artikel gehen wir auf die Bedeutung der Datenqualität ein und stellen praktische Strategien vor, um mit Data Vault 2.0 genaue, zuverlässige und hochwertige Daten zu gewährleisten.

Watch webinar recording

In this article:

Was sind die Ursachen für schlechte Daten?
Techniken zur Sicherstellung der Datenqualität
- Der Nutzen des Data-Vault-2.0-Ansatzes
- Gängige Datenqualitätstechniken
Fazit

Was sind die Ursachen für schlechte Daten?

Datenqualität bezieht sich auf die Genauigkeit, Vollständigkeit, Konsistenz und Zuverlässigkeit von Daten. Im Kontext eines Data Warehouse ist die Aufrechterhaltung einer hohen Datenqualität entscheidend, um aussagekräftige Erkenntnisse zu gewinnen und fundierte Entscheidungen zu treffen. Verschiedene Faktoren tragen zum Vorhandensein von schlechten oder fehlerhaften Daten bei. Das Erkennen und Verstehen dieser Ursachen ist essenziell für die Implementierung effektiver Strategien zum Datenqualitätsmanagement. Hier sind einige häufige Gründe für schlechte Daten in einem Data Warehouse:

Unvollständige oder fehlende Quelldaten
Fehlende Standardisierung
Probleme bei der Datentransformation
Mangelhafte Data Governance
Unzureichende Validierung und Qualitätsprüfungen
Fehlende Anwenderschulung und mangelndes Bewusstsein

Techniken zur Sicherstellung der Datenqualität

Es gibt eine Vielzahl von Datenqualitätstechniken, und es gibt keine universelle Ideallösung für alle Probleme. Die Schwierigkeit besteht darin, die aktuelle Situation sowie die Stärken und Schwächen der verfügbaren Techniken zu verstehen. Tatsächlich variiert die Effektivität der Techniken je nach Kontext. Eine bestimmte Technik passt in manchen Situationen gut, in anderen weniger. Scott Ambler hat fünf Vergleichsfaktoren entwickelt, mit denen sich die Effektivität einer Datenqualitätstechnik beurteilen lässt. Diese nachfolgend gezeigten Faktoren sollen Ihnen helfen, die passende DQ-Technik für Ihre jeweilige Situation auszuwählen:

Data Quality graphic technique comparison for a data warehouse

Quelle: https://agiledata.org/essays/dataqualitytechniquecomparison.html

Rechtzeitigkeit (Timeliness): Reagieren Sie auf ein entdecktes DQ-Problem oder wenden Sie die Technik an, um DQ-Probleme proaktiv zu vermeiden oder zu reduzieren?
Automatisierungsgrad (Level of automation): Inwieweit ist eine Automatisierung möglich? Eine kontinuierliche Technik würde je nach Bedarf automatisch aufgerufen werden.
Auswirkung auf die Quelle (Effect on source): Hat die Technik Auswirkungen auf die eigentliche Datenquelle?
Nutzenrealisierung (Benefit realization): Tritt der Nutzen der Qualitätsverbesserung sofort ein oder ist ein langfristiger Nutzen zu erwarten?
Erforderliche Fähigkeiten (Required skills): Erfordert die Technik anspruchsvolle Fähigkeiten, die erst durch Schulung/Erfahrung erworben werden müssen, oder ist die Technik leicht zu erlernen?

Der Nutzen des Data-Vault-2.0-Ansatzes

Wenn schlechte Daten erkannt werden, besteht der erste Schritt in einer Ursachenanalyse. Was aber, wenn die schlechten Daten aus dem Quellsystem stammen? Der beste Ansatz wäre, die Fehler direkt im Quellsystem zu beheben. Diese Methode wird jedoch häufig abgelehnt, da sie als zu kostspielig gilt. Da die Quellsysteme nicht im Verantwortungsbereich des Data-Warehouse-Teams liegen, müssen wir einen Weg finden, die fehlerhaften Daten an einer anderen Stelle in unserer Architektur zu bereinigen. In Data Vault 2.0 betrachten wir eine Datenbereinigungsroutine als Business Rule (Soft Rule), wobei diese Regeln im Business Vault implementiert werden.

In der gezeigten Architektur (Abbildung 1) ist ein Quality Layer in den Business Vault integriert, in dem die Datenbereinigungsroutinen ausgeführt werden. Ziel ist es, die bereinigten Daten für nachgelagerte Business-Vault- und Information-Mart-Objekte in hohem Maße wiederverwendbar zu machen. Wenn sich die Datenqualitätsregeln ändern oder neue Erkenntnisse über die Daten gewonnen werden, können die Regeln angepasst werden, ohne dass bisherige Rohdaten neu geladen werden müssen.

Nun stehen die Daten für die Verwendung in jedem Dashboarding- oder Reporting-Tool bereit. Es ist auch möglich, die bereinigten Daten in die Quelle zurückzuschreiben. Zu diesem Zweck werden die Daten einem Interface Mart bereitgestellt, der wiederum die Daten an das Quellsystem selbst zurücksendet. Auf diese Weise können Fachanwender die qualitativ hochwertigen Daten auch in ihren Quellanwendungen nutzen. Beim nächsten Laden der Rohdaten in den Raw Data Vault sind die Daten somit bereits bereinigt.

Der zweite in Abbildung 1 beschriebene Anwendungsfall ist das Monitoring von schlechten Daten durch einen sogenannten Quality Mart. Der Quality Mart ist Teil des Information Delivery Layer und wählt alle fehlerhaften Daten anstelle der bereinigten Daten aus. Darauf aufbauend können Berichte oder grafische Benutzeroberflächen für den Data Steward erstellt werden. Darüber hinaus kann der Data Steward Kommentare zu bestimmten Datensätzen hinterlassen, die nicht als schlechte Daten eingestuft werden sollten oder Ausnahmen von den Regeln darstellen. Diese Benutzeroberfläche speichert alle hinzugefügten Daten (Kommentare, Flags etc.) in einer Datenbank, die wiederum als Quelle für den Data Vault dient. Diese Daten können genutzt werden, um die Business Rules zu erweitern – insbesondere, um Ausnahmen von den Datenbereinigungsregeln herauszufiltern.

Ein weiterer Vorteil von Data Vault 2.0 sind die stark musterbasierten und standardisierten Entitäten. Dies ermöglicht eine einfache und automatisierte Entwicklung technischer Tests. Einmal für jede Data-Vault-Entität erstellt, können diese Tests sowohl auf die Raw-Data-Vault-Entitäten als auch auf die Business-Vault-Entitäten angewendet werden. Dies stellt ein konsistentes und auditierbares Data Warehouse sicher. Lesen Sie diesen Blogartikel, wenn Sie detailliertere Informationen zu technischen Tests in Data Vault benötigen.

Gängige Datenqualitätstechniken

Im letzten Abschnitt haben wir bereits einige Techniken zur Sicherstellung einer hohen Datenqualität in einer Data-Vault-2.0-Architektur beschrieben. Selbstverständlich gibt es eine Reihe weiterer Techniken, die unabhängig davon sind, welcher Modellierungsansatz verwendet wird. Darüber hinaus konzentrieren sich einige Techniken nicht in erster Linie auf die Datenqualität, haben aber dennoch einen positiven Einfluss darauf. Schauen wir uns einige davon im Folgenden genauer an:

Validierung von Business Rules: An dieser Stelle müssen wir zwischen Datenqualität und Informationsqualität unterscheiden. Datenqualität konzentriert sich auf die intrinsischen Eigenschaften der Daten und adressiert Probleme wie Fehler, Inkonsistenzen und Unvollständigkeit auf granularer Ebene. Informationsqualität ist ein breiteres Konzept, das nicht nur die Qualität einzelner Datenelemente umfasst, sondern auch den Gesamtwert und den Nutzen der aus diesen Daten abgeleiteten Informationen. Darüber hinaus kann das, was für den einen Anwendungsfall nützliche Informationen sind, für einen anderen unzureichend sein. Aus diesem Grund müssen die Fachanwender stark in diesen Prozess eingebunden werden, beispielsweise durch User Acceptance Tests.
Data Governance umfasst die Definition von Rollen, Verantwortlichkeiten und Rechenschaftspflichten für die Datenqualität, um sicherzustellen, dass Daten als wertvolles Unternehmensgut behandelt werden. Entwickeln Sie Data-Governance-Frameworks einschließlich Datenqualitätsstandards, Data-Stewardship-Verantwortlichkeiten sowie Dokumentationen und setzen Sie diese konsequent um.
Data Guidance und Standardisierung stellen die Einheitlichkeit von Formaten, Einheiten und Werten über das gesamte Data Warehouse hinweg sicher und reduzieren so das Risiko von Fehlern, die durch unterschiedliche Darstellungen verursacht werden. Etablieren Sie standardisierte Benennungskonventionen, Maßeinheiten, Formatierungsregeln sowie Konventionen für Datensicherheit und Datenschutz und setzen Sie diese konsequent um. Data Vault 2.0 ist in dieser Hinsicht sehr hilfreich, da alle Entitäten stark standardisiert und automatisierbar sind.
Data Steward: Als Teil der Data-Governance-Praxis ist ein Data Steward eine Überwachungs- und Governance-Rolle innerhalb einer Organisation, die für die Sicherstellung der Qualität und der Zweckmäßigkeit der Unternehmensdaten verantwortlich ist.
Continuous Integration (CI) ist eine Entwicklungspraxis, bei der Entwickler ihre Arbeit häufig integrieren. Erfolgreiche Tests sollten eine zwingende Voraussetzung für die Einführung neuer Änderungen in Ihre EDW-Codebasis sein. Dies lässt sich durch den Einsatz von DevOps-Tools und die Aktivierung von Continuous Integration in Ihrem Entwicklungslebenszyklus erreichen.
Die Ausführung automatisierter Tests bei jedem Code-Check-in oder -Merge stellt sicher, dass Konsistenzprobleme oder Bugs frühzeitig erkannt und vor dem Go-Live behoben werden.
Ein Review ist eine Peer-Review der Implementierung (Quellcode, Datenmodelle etc.). Die Entwicklung eines starken Review-Prozesses schafft die Grundlage für eine kontinuierliche Verbesserung und sollte Teil des Workflows eines Entwicklungsteams werden, um die Qualität zu steigern und sicherzustellen, dass jeder Codeabschnitt von einem anderen Teammitglied geprüft wurde.
Anwenderschulung und Bewusstseinsbildung: Schulen Sie Anwender in der Bedeutung der Datenqualität und bieten Sie Trainings zu den notwendigen Themen und Fähigkeiten an. Fördern Sie eine Kultur des Datenqualitätsbewusstseins innerhalb der Organisation, um die proaktive Identifikation und Behebung von Datenqualitätsproblemen zu unterstützen.

Fazit

Es steht außer Frage, dass eine hohe Datenqualität für ein erfolgreiches Data-Warehousing-Projekt unerlässlich ist. Der Weg zu hoher Datenqualität ist keine einmalige Anstrengung, sondern eine kontinuierliche Verpflichtung. Es handelt sich um einen vielschichtigen Prozess, der eine Kombination von Techniken, teamübergreifende Zusammenarbeit und die Förderung einer Kultur der Data Stewardship umfasst.

In diesem Artikel sind wir auf die Ursachen für schlechte Daten eingegangen und haben verschiedene Techniken für den Umgang mit diesen Problemen diskutiert. Genauer gesagt haben wir beschrieben, wie Datenqualitätstechniken innerhalb einer Data-Vault-2.0-Architektur implementiert werden können.

Wenn Sie tiefer in das Thema Datenqualität eintauchen möchten, denken Sie daran, sich die kostenlose Webinar-Aufzeichnung anzusehen.

Dmytro Polishchuk In Anfänger, Datenwerkzeuge

Das Potenzial von Microsoft Fabric für Business Intelligence

Microsoft Fabric für Business Intelligence

Microsoft Fabric ist eine cloudbasierte All-in-One-Analyseplattform, die eine einheitliche Umgebung für Datenexperten und Geschäftsanwender bietet, um gemeinsam an Datenlösungen zu arbeiten. Diese leistungsstarke Plattform unterstützt Unternehmen dabei, Workflows zu automatisieren, die Produktivität zu steigern und wertvolle Erkenntnisse aus ihren Daten zu gewinnen.

In der heutigen datengesteuerten Welt setzen Unternehmen zunehmend auf Business-Intelligence-Lösungen (BI), um fundierte Erkenntnisse aus ihren Daten zu generieren. BI-Lösungen helfen Unternehmen dabei, ihre Entscheidungsfindung zu verbessern, ihre Abläufe zu optimieren und sich einen nachhaltigen Wettbewerbsvorteil zu verschaffen.

Das Potenzial von Microsoft Fabric für Business Intelligence -Lösungen

Microsoft Fabric ist eine neue, innovative Datenanalyseplattform, welche die Art und Weise, wie Unternehmen Entscheidungen treffen, revolutionieren kann. Mit Fabric können Organisationen all ihre Daten an einem einzigen Ort erfassen, speichern, verarbeiten und analysieren, indem sie ein einheitliches Portfolio an Tools und Diensten nutzen. Dies ermöglicht es, schneller und einfacher als je zuvor Erkenntnisse aus Daten zu gewinnen. In diesem Beitrag untersuchen wir das Potenzial von Microsoft Fabric für Business-Intelligence-Lösungen. Wir erörtern, wie Fabric genutzt werden kann, um die Datenqualität zu verbessern, Analyse-Workflows zu optimieren und Anwendern passgenaue Erkenntnisse bereitzustellen. Dieses Webinar ist für alle interessant, die mehr darüber erfahren möchten, wie sie mit Microsoft Fabric einen maximalen Mehrwert aus ihren Daten ziehen können. Besonders wertvoll ist es für Data Engineers, Analysten, Business-Intelligence-Experten sowie IT-Entscheidungsträger. Registrieren Sie sich jetzt für dieses kostenlose Webinar und erfahren Sie, wie Microsoft Fabric Ihnen helfen kann, Ihre Business-Intelligence-Lösungen auf ein neues Niveau zu heben!

Watch webinar recording

In this article:

Was Sie erwartet
Was ist Microsoft Fabric?
Workloads of Microsoft Fabric
Data Lake
Welche Potenziale bietet Microsoft Fabric also?
Fazit

Was Sie erwartet

Dieser Newsletter zeigt Ihnen die transformative Kraft von Microsoft Fabric für Business-Intelligence-Lösungen. Sie lernen die verschiedenen Workloads und Experiences kennen, die Microsoft Fabric bietet, und erlangen ein umfassendes Verständnis seiner Funktionen. Zudem entdecken Sie die Vorteile, die Microsoft Fabric für die datengesteuerte Entscheidungsfindung bietet, um fundierte Entscheidungen zu treffen, die Ihr Unternehmen voranbringen. Schließlich tauchen Sie tief in das Potenzial ein, das Microsoft Fabric für die Verbesserung von Business-Intelligence-Lösungen bereithält, und erfahren, wie Sie neue Dimensionen von Erkenntnissen und Entscheidungsprozessen erschließen können.

Um noch tiefer in das Thema einzusteigen, können Sie sich die Webinar-Aufzeichnung kostenlos ansehen. Klicken Sie hier, um sich zu registrieren.

Was ist Microsoft Fabric?

Microsoft Fabric ist eine cloudbasierte All-in-One-Analyseplattform, die eine einheitliche Umgebung für Datenexperten und Geschäftsanwender bietet, um gemeinsam an Datenlösungen zu arbeiten. Fabric bietet eine Suite integrierter Dienste, mit denen Sie Daten auf einer einzigen Plattform erfassen, speichern, verarbeiten und analysieren können, die auf Software-as-a-Service (SaaS) basiert.

Microsoft Fabric bietet Tools für Anwender aller Erfahrungsstufen im Datenbereich und lässt sich nahtlos mit den Tools verbinden, die Unternehmen für ihre Entscheidungsfindung nutzen.
Fabric selbst fungiert als Dach für die folgenden cloudbasierten Microsoft-Dienste, die das Microsoft-Analytics-Portfolio bilden:

Azure Data Factory
Azure Event Hubs
Azure Data Explorer
Azure Artificial Intelligence
Azure Databricks
Azure Synapse Spark Pools
Azure Synapse Analytics
and Microsoft Power BI

Die oben genannten Komponenten wurden innerhalb von Microsoft Fabric vollständig überarbeitet und auf ein neues Niveau gehoben.

Workloads of Microsoft Fabric

Fabric umfasst die folgenden Workloads und Experiences:

Datenintegration
Data Engineering
Data Warehousing
Data Science
Real-Time Analytics
Business Intelligence
Insight to Action

Das Fundament dieser Experiences in Fabric ist der Data Lake, der als OneLake bezeichnet wird. Die folgende Abbildung veranschaulicht das Konzept von Microsoft Fabric.

Betrachten wir die einzelnen Komponenten von Fabric im Detail.

Datenintegration

Die Workload für Datenintegration in Microsoft Fabric, genannt Data Factory, bringt Datenbewegungsfunktionen sowohl in Dataflows als auch in Data Pipelines.

Dataflows bieten flexible und benutzerfreundliche Möglichkeiten zur Transformation von Daten mit über 300 Transformationsoptionen. Sie basieren auf der vertrauten Power-Query-Experience, die in verschiedenen Microsoft-Produkten und -Diensten wie Excel, Power BI, Power Platform und anderen verfügbar ist.
Data Pipelines ermöglichen es Ihnen, flexible Daten-Workflows zu erstellen, um Ihre organisatorischen Ziele zu erreichen. Sie können die integrierten Datenorchestrierungsfunktionen nutzen, um Ihre Dataflows zu aktualisieren, große Datensätze zu verarbeiten und komplexe Kontrollfluss-Pipelines zu definieren.

Data Engineering

Die Data-Engineering-Experience oder Synapse Data Engineering bietet eine erstklassige Spark-Plattform mit umfassenden Entwicklungsumgebungen. Dies ermöglicht es Data Engineers, umfangreiche Datentransformationen durchzuführen, und erleichtert den breiten Zugriff auf Daten über das Lakehouse.

Microsoft Fabric bietet verschiedene Data-Engineering-Funktionen, um sicherzustellen, dass Ihre Daten leicht zugänglich, gut organisiert und von hoher Qualität sind. Auf der Data-Engineering-Startseite haben Sie die folgenden Optionen:

Lakehouse
Erstellen und Verwalten von Lakehouses. Ein Lakehouse ist ein logischer Speicherort in OneLake, an dem Sie strukturierte und unstrukturierte Daten mithilfe verschiedener Tools und Frameworks speichern und verwalten. Mit der Shortcut-Funktion können Sie sogar ein externes Speicherkonto in Ihr Lakehouse einbinden. Sie können den SQL-Endpunkt verwenden, um Lakehouse-Tabellen abzufragen, wobei dieser jedoch nur schreibgeschützte Abfragen unterstützt.
Notebook
Schreiben und Ausführen von Code in gängigen Programmiersprachen wie Python, R und Scala. Nutzen Sie Notebooks für die Datenerfassung, -transformation, -analyse und andere Datenverarbeitungsaufgaben.
Environment
Innerhalb eines Environments haben Sie die Flexibilität, aus einer Vielzahl von Spark-Runtimes zu wählen, Ihre Rechenressourcen zu konfigurieren und Bibliotheken zu integrieren, entweder aus öffentlichen Repositories oder durch das Hochladen lokal erstellter, benutzerdefinierter Bibliotheken. Die Zuweisung dieser Umgebungen (Environments) zu Ihren Notebooks und Spark-Jobdefinitionen ist ein nahtloser Prozess.
Spark-Jobdefinition
Definieren, planen und verwalten Sie Spark-Jobs, um Big Data in Ihrem Lakehouse zu verarbeiten, Transformationslogik auf die Daten anzuwenden und vieles mehr.
Data Pipeline
Entwerfen und orchestrieren Sie Pipelines, um Daten in Ihr Lakehouse zu kopieren, Spark-Jobs und Notebooks zur Verarbeitung großer Datenmengen zu planen und Daten-Workflows durch die Integration mit Data Factory zu automatisieren.

Data Warehousing

Das Data Warehouse oder Synapse Data Warehouse ist ein Lake-zentriertes Repository zur Speicherung und Analyse strukturierter Daten, das auf einer verteilten Verarbeitungs-Engine basiert. Die Data-Warehousing-Workload profitiert von den umfassenden Funktionen der SQL-Engine über ein offenes Delta-Lake-Format. Dabei handelt es sich um Parquet-Dateien, die als Delta-Lake-Logs veröffentlicht und in OneLake gespeichert werden. Delta-Lake-Logs ermöglichen ACID-Transaktionen. Ein Warehouse kann nur strukturierte Daten enthalten. Hier können Sie Daten mit SQL nicht nur lesen, sondern auch Schreib- und Aktualisierungsvorgänge (Inserts und Updates) ausführen.

Data Science

Die Data-Science-Experience oder Synapse Data Science ermöglicht die Erstellung, Bereitstellung und Operationalisierung von Machine-Learning-Modellen. Data Scientists werden in die Lage versetzt, Unternehmensdaten mit Vorhersagen anzureichern, und Business-Analysten können diese Vorhersagen direkt in ihre BI-Berichte integrieren. Data Science in Fabric bietet Ihnen die folgenden Optionen:

ML-Modell
Nutzen Sie Machine-Learning-Modelle, um Ergebnisse vorherzusagen und Unregelmäßigkeiten in Datensätzen zu identifizieren.
Experiment
Steigen Sie in die Experimentierphase ein, indem Sie verschiedene Modelle erstellen, ausführen und deren Entwicklung überwachen, um Hypothesen zu validieren.
Notebook
Nutzen Sie die Notebook-Funktion, um in die Datenexploration einzutauchen und Machine-Learning-Lösungen über Apache-Spark-Anwendungen zu erstellen.
Environment
Diese Option dient demselben Zweck wie in der Data-Engineering-Experience.

Real-Time Analytics

Real-Time Analytics in Fabric oder Synapse Real-Time Analytics ist eine vollständig verwaltete Big-Data-Analyseplattform, die für Streaming- und Zeitreihendaten optimiert ist. Sie nutzt die Kusto Query Language (KQL), eine Engine mit außergewöhnlicher Performance für die Suche in strukturierten, semistrukturierten und unstrukturierten Daten. Real-Time Analytics ist vollständig in die gesamte Palette der Fabric-Produkte für Datenlade-, Datentransformations- und erweiterte Visualisierungsszenarien integriert. Es gibt drei Komponenten von Real-Time Analytics in Fabric:

KQL-Datenbank
Der Ort zum Speichern von Streaming-Daten. Sie nutzt OneLake als zugrunde liegendes Speichersystem.
KQL-Queryset
Führen Sie Abfragen auf Ihren Daten aus, um teilbare Tabellen und Visualisierungen zu erstellen. Speichern, verwalten, exportieren und teilen Sie KQL-Abfragen. Ein KQL-Queryset ist das Pendant zu SSMS für eine SQL-Datenbank.
Eventstream
Erfassen, transformieren und leiten Sie Echtzeit-Event-Streams im gewünschten Format an verschiedene Ziele weiter, ganz ohne Programmieraufwand (No-Code). Es ist eine zentrale Drehscheibe für Streaming-Daten, an der mehrere Quellen (einschließlich Event Hub) und verschiedene Ziele (einschließlich KQL-Datenbank) eingerichtet werden können.

Business Intelligence

Auf der BI-Seite bietet Fabric mit Power BI eine der weltweit führenden Business-Intelligence-Plattformen. Power BI vereint eine Reihe von Diensten, Tools und Konnektoren, die Ihre Daten in interaktive visuelle Berichte und Dashboards verwandeln. In Fabric gibt es einige neue Funktionen und Erweiterungen für die Arbeit mit Fabric-Objekten und -Experiences. Dazu gehören:

Der Direct-Lake-Modus, eine Verbindung, die auf dem direkten Laden von Dateien im Parquet-Format aus einem Data Lake basiert, ohne dass die Daten in ein Dataset importiert werden müssen.
Die Integration mit Synapse Real-Time Analytics zur Erstellung von Berichten nahezu in Echtzeit.
Semantic Link, der das Laden von Daten aus Power-BI-Datasets in die Data-Science-Experience und andere Umgebungen ermöglicht..

Insight to Action

Insight to Action in Fabric bietet den Data Activator, eine Experience zur automatischen Auslösung von Aktionen, sobald bestimmte Bedingungen in den eingehenden Daten erfüllt sind. Der Data Activator arbeitet mit Eventstreams für Echtzeitdaten und mit Power BI für Batch-Daten. Es gibt drei mögliche Aktionen, die nach dem Erkennen der Bedingungen konfiguriert werden können:

E-Mail: Lassen Sie sich per E-Mail benachrichtigen.
Teams-Nachricht: Senden Sie eine Benachrichtigung an eine Person oder einen Kanal in Teams.
Benutzerdefinierte Aktion: Führen Sie eine benutzerdefinierte Aktion aus, um einen Power-Automate-Workflow aufzurufen.

Data Lake

OneLake ist die zentrale Komponente aller Fabric-Dienste. Es ist ein integrierter, einheitlicher Data Lake, der alle Organisationsdaten speichert und von allen Fabric-Experiences genutzt wird. OneLake verwendet ADLS Gen2 als zugrunde liegenden Speicher.

Um die Verwaltung im gesamten Unternehmen zu vereinfachen, ist OneLake hierarchisch organisiert. Jeder Tenant besitzt genau eine OneLake-Instanz, die einen einzigen Namensraum bereitstellt, der sich über Benutzer, Regionen und sogar Clouds erstreckt. Zur einfachen Handhabung sind die Daten in OneLake in überschaubare Container unterteilt.

Ähnlich wie bei Microsoft OneDrive kann jeder Entwickler oder jede Geschäftseinheit innerhalb des Tenants eigene Arbeitsbereiche (Workspaces) in OneLake erstellen. Sie können Daten in ihre eigenen Lakehouses laden und mit der Verarbeitung, Analyse und gemeinsamen Bearbeitung der Daten beginnen. Alle Fabric-Experiences sind an OneLake gebunden und arbeiten darauf aufbauend.

Welche Potenziale bietet Microsoft Fabric also?

Microsoft Fabric hat das Potenzial, die Art und Weise, wie Unternehmen Business-Intelligence-Lösungen entwickeln und bereitstellen, grundlegend zu verändern. Hier sind einige der wichtigsten Aspekte:

Einheitliche Datenplattform: Microsoft Fabric bietet eine einheitliche Datenplattform für die Speicherung und Analyse aller Datentypen, einschließlich strukturierter, semistrukturierter und unstrukturierter Daten. Dies bedeutet, dass Unternehmen ein einziges Toolset nutzen können, um alle Aspekte ihrer Datenpipeline zu verwalten – von der Datenerfassung und -aufbereitung bis hin zur Datenanalyse und -visualisierung. Dies trägt maßgeblich dazu bei, die Komplexität zu reduzieren und die Effizienz zu steigern.
End-to-End-Analysen: Microsoft Fabric bietet ein vollständiges Spektrum an Funktionen für die Erstellung und Bereitstellung von End-to-End-Analyselösungen. Dies umfasst Data Engineering, Data Science, Data Warehousing und Business Intelligence. Dies vereinfacht die Entwicklung sowie Bereitstellung von Analyselösungen und reduziert den Bedarf an spezialisiertem Fachwissen.
KI-gestützte Erkenntnisse: Microsoft Fabric integriert KI- und Machine-Learning-Funktionen auf der gesamten Plattform. Diese können genutzt werden, um Aufgaben zu automatisieren, Erkenntnisse zu generieren und die Genauigkeit von Vorhersagen zu verbessern. So können Unternehmen schneller fundierte Entscheidungen treffen.
Eine einheitliche Plattform für unterschiedliche Fachbereiche: Datenexperten mit verschiedenen Hintergründen können ihre Fähigkeiten einbringen, um gemeinsam an einer einzigen Datenlösung zu arbeiten. Diese integrative Umgebung ermöglicht es Personen aus unterschiedlichen Disziplinen und mit verschiedenen Qualifikationsstufen, ihr Fachwissen in ein gemeinsames Datenprojekt einzubringen.
Reduzierung von Datensilos: Da Daten nicht mehr zwischen verschiedenen Systemen verschoben werden müssen, wird eine ganzheitliche Sicht auf das Unternehmen erheblich erleichtert.
Kostensenkung: Microsoft Fabric hilft Unternehmen dabei, die mit der Entwicklung und Bereitstellung von Business-Intelligence-Lösungen verbundenen Kosten zu senken. Da die Anschaffung und Wartung mehrerer Einzelsysteme entfällt, wird eine Reihe von Funktionen bereitgestellt, die Aufgaben automatisieren und die Effizienz steigern können.

Im Wesentlichen verspricht Microsoft Fabric, die Entwicklung und Bereitstellung robuster Business-Intelligence-Lösungen zu vereinfachen und sie für Unternehmen jeder Größenordnung zugänglicher und kostengünstiger zu machen.

Fazit

Microsoft Fabric stellt einen Paradigmenwechsel im Bereich der Business-Intelligence-Lösungen dar. Mit seiner einheitlichen Datenplattform, den End-to-End-Analysefunktionen und den KI-gestützten Erkenntnissen optimiert Fabric das Datenmanagement von der Erfassung bis zur Visualisierung. Die Fähigkeit der Plattform, verschiedene Fachbereiche und Kompetenzen zusammenzuführen, Datensilos zu reduzieren und Aufgaben zu automatisieren, verdeutlicht das bemerkenswerte Potenzial, die Branche nachhaltig zu revolutionieren.

Durch seine Komponenten wie Data Factory, Data Engineering, Data Warehousing, Data Science, Real-Time Analytics, Power BI, Data Activator und das solide Fundament von OneLake verspricht Microsoft Fabric eine Zukunft, in der Unternehmen die Macht der Daten effizient nutzen können, um fundierte Entscheidungen zu treffen und Innovationen voranzutreiben. Letztendlich hat es das Potenzial, leistungsstarke Business-Intelligence-Lösungen zu demokratisieren und sie für Unternehmen aller Größenordnungen zugänglicher und wirtschaftlicher zu machen.

Dmytro Polishchuk In Data Warehouse, Fortgeschrittene

Technische Tests eines Data Vault-gestützten EDW

Data Vault-gestütztes EDW

In diesem Newsletter stellen wir Ihnen verschiedene Methoden und Ansätze zur Durchführung technischer Tests eines Data Vault-gestützten EDW vor und geben Ihnen einen Überblick darüber.

Die unten beschriebenen Testansätze zielen darauf ab, die Integrität, Zuverlässigkeit, Genauigkeit, Konsistenz und Revisionssicherheit (Auditability) der in Ihre Data-Vault-Entitäten geladenen Daten sowie der darauf aufbauenden Information-Marts sicherzustellen. Dies stellt sicher, dass Ihr Unternehmen auf der Grundlage dieser Daten fundierte Entscheidungen treffen kann.

Technische Tests und Monitoring eines Data Vault-gestützten EDW

In diesem Webinar geben Ihnen unsere Experten einen Überblick über verschiedene Methoden und Ansätze für technische Tests und das Monitoring eines Data Vault-gestützten EDW. Die vorgestellten Testansätze eignen sich für verschiedene Schichten (Layers) Ihrer EDW-Lösung – von der Extraktion der Daten aus den Quellen in die Landing Zone/Staging Area (Extract and Load) bis hin zu den Information-Marts, die von den Endanwendern in ihren BI-Berichten genutzt werden. Der Hauptfokus unseres Webinars liegt jedoch auf dem Testen der Data-Vault-2.0-Entitäten in den Raw-Vault- und Business-Vault-Schichten. Das Monitoring konzentriert sich darauf, Einblicke in die Performance Ihres EDW zu geben. Ausgehend vom Modellierungsansatz des Metrics-Vault und der Metrics-Marts werden die Quelldatenbereiche dieser Entitäten abgedeckt. Diese erfassten Daten liefern Informationen über die Prozessausführung Ihrer ELT-Prozesse sowie Fehlerinformationen. Durch die Analyse der Error-Marts können Sie Fehler nachverfolgen, deren Ursachen ermitteln und die Performance durch die Berücksichtigung von Performance-Metriken steigern.

Watch Webinar Part 1 Watch Webinar Part 2

In this article:

Was Sie erwartet
Testen des Datenextraktionsprozesses
Testen von Data Vault
Testautomatisierung und Continuous Integration
Fazit

Was Sie erwartet

Sie erhalten einen Überblick über Testansätze, die für verschiedene Schichten Ihrer EDW-Lösung geeignet sind – angefangen bei der Extraktion von Daten aus Quellen in die Landing Zone/Staging Area (Extract and Load) bis hin zu Information-Marts, die von Endanwendern in ihren BI-Berichten verwendet werden. Darüber hinaus thematisieren wir die Testautomatisierung und ihre Bedeutung für die Continuous Integration Ihres Data-Vault-basierten EDW. Der Hauptfokus dieses Newsletters liegt jedoch auf dem Testen der Data-Vault-Entitäten in den Raw-Vault- und Business-Vault-Schichten.

Testen des Datenextraktionsprozesses

Unabhängig davon, wo die Datenextraktion stattfindet – Datenquelle, Persistent Staging oder Transient Staging – besteht das Hauptziel der Tests in dieser Phase darin, nachzuweisen, dass beim Transport oder Staging der Daten kein Datenverlust (Data Leakage) auftritt. Der Vergleich der Eingangsdaten mit den Zieldaten stellt sicher, dass die Daten nicht versehentlich oder unbefugt aufgrund von Problemen im Extraktionsprozess gelöscht, hinzugefügt oder geändert wurden. Prüfsummen (Checksums), Hash-Summen (Hash Totals) und die Anzahl der Datensätze (Record Counts) sollten verwendet werden, um sicherzustellen, dass die Daten unverändert geblieben sind:

Stellen Sie sicher, dass die Prüfsummen (Checksums) zwischen dem Quelldatensatz und der Ziel-Staging-Tabelle übereinstimmen.
Stellen Sie sicher, dass die numerische Summe eines oder mehrerer Felder in einem Quelldatensatz (auch bekannt als Hash Total) mit der Summe der entsprechenden Spalten in der Zieltabelle übereinstimmt. Eine solche Summe kann Daten enthalten, die normalerweise nicht für Berechnungen verwendet werden (z. B. numerische ID-Werte, Kontonummern usw.).
Stellen Sie sicher, dass die Zeilenanzahl (Row Count) zwischen der Quelle und der Ziel-Staging-Tabelle übereinstimmt.

Testen von Data Vault

Das Herzstück Ihrer Data-Vault-gestützten EDW-Lösung ist der Raw Data Vault. Dieser enthält rohe und ungefilterte Daten aus Ihren Quellsystemen, die aufgeteilt und basierend auf Business-Keys in Hubs, Links, Satelliten und andere Data-Vault-spezifische Entitäten geladen werden. Dies ist der erste Punkt in der Datenpipeline, an dem die Daten in den gemäß Data Vault modellierten Entitäten landen. Daher sind spezifische Tests erforderlich, um die Konsistenz und Revisionssicherheit der Daten nach dem Befüllen des Raw Data Vault sicherzustellen. Die folgenden Testansätze gelten gleichermaßen für Business-Vault-Entitäten.

Testen von Hubs

Hubs speichern Business-Keys, indem sie diese vom Rest des Modells trennen. Für jedes Geschäftsobjekt (Business Object) wird ein Hub erstellt. Er enthält eine eindeutige Liste von Schlüsseln, die ein Geschäftsobjekt repräsentieren und dieselbe semantische Bedeutung sowie Granularität aufweisen. Auf die in einem Hub befindlichen Geschäftsobjekte wird anschließend von anderen Data-Vault-Entitäten über Hash-Keys verwiesen, die während der Staging-Phase berechnet werden.

Daher müssen an Hubs folgende Tests durchgeführt werden, um deren Konsistenz zu gewährleisten. Für einen Hub mit einem einzelnen Business-Key sollten Tests sicherstellen, dass:

der Hub eine eindeutige Liste von Business-Keys enthält (Primary-Key- (PK-) Test).
eine Business-Key-Spalte keine NULL- oder leeren Werte enthält (außer wenn der Business-Key zusammengesetzt ist).

Wenn ein Hub einen zusammengesetzten Business-Key hat, stellen Sie sicher, dass:

die Kombination der Werte in den Business-Key-Spalten eindeutig ist (PK-Test).
die Business-Key-Spalten nicht alle gleichzeitig NULL- oder leere Werte enthalten.

Die Gültigkeit des letztgenannten Punktes hängt von der Natur des Geschäftsobjekts selbst ab. Es kann auch sein, dass in keiner der Business-Key-Spalten NULL- oder leere Werte zulässig sind.

Stellen Sie für beide Arten von Hubs sicher, dass:

die Hash-Key-Spalte eine eindeutige Liste
- eine eindeutige Liste von Werten enthält (PK-Test)
- keine NULL- oder leeren Werte vorhanden sind.

Testen von Links

Ein typischer Link definiert Beziehungen zwischen Geschäftsobjekten, indem er eindeutige Kombinationen von Hash-Keys der verbundenen Hubs speichert. Der Primary-Key des Links oder der Link-Hash-Key identifiziert eine solche Kombination eindeutig. Daher sollten Link-Tests Folgendes prüfen:

dass die Kombination der verbundenen Hub-Referenzen (Hub-Hash-Keys) eindeutig ist (PK-Test).
dass jeder Hub-Hash-Key-Wert im referenzierten Hub existiert.
dass Hub-Referenzen keine NULL- oder leeren Werte enthalten.

Beachten Sie bezüglich des letzten Aufzählungspunkts, dass NULL- und leere Werte in Hub-Referenzen sowie in Hash-Key-Spalten anderer Data-Vault-Entitäten durch Zero-Keys ersetzt werden. Für transaktionale (nicht historisierte) Daten sollten transaktionale Schlüsselspalten zusätzlich zu den Spalten mit Hub-Hash-Keys in die Eindeutigkeitstests einbezogen werden. Stellen Sie sicher, dass auch transaktionale Schlüssel befüllt sind. Solche transaktionalen Schlüssel werden in der Regel nicht gehasht, da im Regelfall keine Hubs für Transaktionen erstellt werden.
Zudem sollten Sie, wie bei den Hubs, sicherstellen, dass die Link-Hash-Key-Spalte eindeutige Werte enthält und keine NULL- oder leeren Werte vorhanden sind.

Testen von Satellites

Satelliten speichern beschreibende Informationen (Attribute) für Geschäftsobjekte (die sich in Hubs befinden) oder Beziehungen zwischen Geschäftsobjekten (die sich in Links befinden). Ein Satellit referenziert entweder einen Hub oder einen Link. Da sich beschreibende Informationen für Geschäftsobjekte und deren Beziehungen im Laufe der Zeit ändern können, wird der Primary-Key eines Satelliten um den Load-Date-Timestamp des Satellitendatensatzes ergänzt.

Vor diesem Hintergrund sollten Tests für einen Satelliten sicherstellen, dass:

die Kombination aus einer Hub-/Link-Referenz (dem Hash-Key) und dem Load-Date-Timestamp eines Datensatzes eindeutig ist (PK-Test).
jeder Hub- oder Link-Hash-Key-Wert im referenzierten Hub oder Link existiert.
Hub- oder Link-Referenzen keine NULL- oder leeren Werte enthalten.

Multi-Active-Satelliten enthalten mehrere aktive Datensätze zur gleichen Zeit. Daher sind zusätzliche Schlüsselspalten (z. B. Type Code, Sequence usw.) erforderlich, um einen Datensatz eindeutig zu identifizieren. Diese zusätzlichen Schlüsselspalten müssen Teil des Eindeutigkeitstests eines Multi-Active-Satelliten sein. Darüber hinaus sollten sie auf das Fehlen von NULL- und leeren Werten getestet werden. Der Ansatz zum Testen eines Non-Historized-Satelliten unterscheidet sich ebenfalls geringfügig vom Testen seines Standard-Pendants. Ein Non-Historized-Satellit ist ein spezieller Entitätstyp, der beschreibende Attribute für jeden entsprechenden Datensatz in einem Non-Historized-Link enthält. Der Primary-Key eines Non-Historized-Satelliten ist ein Link-Hash-Key. Daher ist es nicht erforderlich, einen Load-Date-Timestamp in die Prüfung des Primary-Keys einzubeziehen. Stellen Sie bei einem Non-Historized-Satelliten zusätzlich sicher, dass er eine 1:1-Beziehung mit dem entsprechenden Non-Historized-Link aufweist. Die Anzahl der Datensätze (Record Counts) in beiden Entitäten sollte exakt übereinstimmen.

Testen anderer Data Vault-Entitäten

Es gibt weitere spezielle Entitätstypen in Data Vault, die im Hinblick auf das Testen erwähnenswert sind:

Reference-Hubs und Reference-Satelliten: Die Testansätze ähneln denen von Standard-Hubs und -Satelliten. Der einzige Unterschied besteht darin, dass keine Hash-Keys vorhanden sind und Business-Keys direkt verwendet werden.
Record-Source-Tracking-Satelliten: Dem Primary-Key-Test wird eine Spalte hinzugefügt, die einen statischen Quellnamen repräsentiert.
PIT-Table (Business Vault)
- PK-Test – die Kombination aus dem Hub-/Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig.
- Überprüfen Sie für jede Satelliten-Referenz, ob das Paar aus Hub-/Link-Hash-Keys und dem Load-Date-Timestamp im referenzierten Satelliten existiert.
- Die Hub-/Link-Referenz enthält keine NULL- oder leeren Werte.
Bridge-Table (Business Vault):
- PK-Test – die Kombination aus einem Basis-Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig.
- Überprüfen Sie für jede Hub- und Link-Referenz, ob das Hub-/Link-Hash-Key-Paar im referenzierten Hub oder Link existiert.

Allgemeine Tests für alle Data Vault-Entitäten

Es gibt einige Tests, die für alle Data-Vault-Entitäten anwendbar sind.
Stellen Sie sicher, dass alle Data-Vault-Entitäten:

Zero-Keys anstelle von NULL-Schlüsseln enthalten.
Record-Source-Spalten haben, die befüllt sind und dem definierten Muster (z. B. Regex) entsprechen. Prüfen Sie beispielsweise, ob sie den Dateipfad enthalten, bei dem der Name des Ordners auf oberster Ebene den Namen des Quellsystems darstellt und der Dateiname den Zeitstempel der Datenextraktion enthält.
Keine NULL-Werte in ihren Load- (bzw. Snapshot-) Date-Timestamp-Spalten aufweisen

Testen von Source Marts

Der Source-Mart ist eine der Facetten des Information-Mart-Konzepts in Data Vault. Es handelt sich um ein virtualisiertes Modell auf dem Raw Data Vault mit dem Ziel, die ursprünglichen Quellstrukturen zu replizieren. Er eignet sich hervorragend für Ad-hoc-Berichte, bietet vielen Data Scientists und Power-Usern einen hohen Mehrwert und kann auch verwendet werden, um die Konsistenz und Revisionssicherheit des Ladeprozesses in ein Data-Vault-gestütztes EDW zu testen.

Source-Mart-Objekte sollen genauso aussehen wie die jeweiligen Quelltabellen (einschließlich der Spaltennamen). Wenn Sie Source-Marts in Ihrem EDW implementiert haben, stellen Sie sicher, dass Sie diese nach dem Datenladeprozess mit den jeweiligen Quelltabellen in der Staging Area vergleichen. Werte und Zeilenanzahlen (Row Counts) der Quellstrukturen sollten exakt mit den jeweiligen Source-Mart-Objekten übereinstimmen. In der Data-Vault-Community ist diese Art von Test auch als „Jedi-Test“ bekannt.

Es ist relativ einfach, einen solchen Vergleich zu automatisieren und ihn in den Ladeprozess zu integrieren.

Testen von Hash Key- und Hash Diff-Berechnungen

Hash-Keys in Data Vault ermöglichen es, Business-Keys auf deterministische Weise aus mehreren Quellen parallel zu integrieren. Sie sind das Bindeglied, das verschiedene Data-Vault-Entitäten miteinander verbindet.

Hash-Diffs hingegen werden auf die Satelliten angewendet und helfen dabei, Unterschiede in beschreibenden Attributen während des Datenladeprozesses zu identifizieren.

Es ist wichtig, Unit-Tests für die in Ihrem EDW verwendeten Hash-Key- und Hash-Diff-Berechnungen einzuführen, um sicherzustellen, dass die gehashten Werte gemäß den definierten Hashing-Standards berechnet werden. Lesen Sie hier mehr über Anforderungen und Vorlagen für das Hashing. Testfälle für solche Unit-Tests sollten so viele Kombinationen verschiedener Datentypen und Werte (z. B. NULL- und leere Werte) wie möglich abdecken, um eine konsistente Berechnung zu gewährleisten.

Falls Ihr EDW auf verschiedenen DBMS-Plattformen existiert (z. B. während eines Migrationsprozesses oder aufgrund von Datensicherheitsvorschriften), können die oben genannten Testfälle verwendet werden, um sicherzustellen, dass Ihre Hash-Berechnungen plattformunabhängig (platform-agnostic) sind – was bedeutet, dass sie auf verschiedenen Plattformen das gleiche Ergebnis liefern. Ein typischer Anwendungsfall ist, wenn ein Link auf einer On-Premises-DBMS-Plattform auf einen Hub verweist, der bereits auf eine Cloud-Plattform migriert wurde. Solche Unit-Tests können auf beiden Plattformen ausgeführt werden, um die Konsistenz des Hashings während einer Migration sicherzustellen.

Testen von Business Rules

Im Gegensatz zu Hard-Rules, welche die Inhalte der Daten nicht verändern oder unterbrechen und so die Revisionssicherheit wahren, setzen Soft-Rules oder Business-Rules die von den Geschäftsanwendern (Business Users) definierten geschäftlichen Anforderungen um. Beispiele für Business-Rules sind:

Verkettung (Nachname und Vorname)
Standardisierung von Telefonnummern
Berechnung des Gesamtumsatzes (Aggregation)
Coalescing (Zusammenführung) usw.

Neben den oben aufgeführten, relativ einfachen Beispielen kann es auch komplexere Business-Rules geben, die anspruchsvolle Berechnungen, Datentransformationen und komplexe Joins beinhalten. Je nach Anwendungsfall landen die Ergebnisse dieser Regeln im Business Vault (z. B. in einem Business-Satelliten) und später in der Information-Mart-Schicht, wo sie von den Geschäftsanwendern konsumiert werden. Daher ist das Testen von Business-Rules ein wichtiger Teil des Informationsbereitstellungsprozesses (Information Delivery Process).

Business-Rules sind in der Regel auch Gegenstand von Unit-Tests, die kontinuierlich während des Entwicklungs- und CI-Prozesses durchgeführt werden müssen. Um einen solchen Unit-Test durchzuführen, werden bestimmte Erwartungswerte benötigt, die im besten Fall vom Fachbereich (Business) bereitgestellt werden – beispielsweise ein erwarteter Nettoumsatzwert für ein bestimmtes Produkt oder eine Reihe von Produkten in einer bestimmten Filiale an einem bestimmten Tag auf der Grundlage realer Daten. Die Nettoumsatzberechnung aus dem Business Vault wird dann gegen das vorgegebene erwartete Ergebnis getestet.

Testautomatisierung und Continuous Integration

Alle oben beschriebenen Tests sollten so weit wie möglich automatisiert und von den EDW-Entwicklern während des Entwicklungsprozesses ausgeführt werden. Erfolgreiche Tests sollten eine zwingende Voraussetzung für die Integration neuer Änderungen in Ihre EDW-Codebasis sein. Dies lässt sich durch den Einsatz von DevOps-Tools und die Aktivierung von Continuous Integration (CI) in Ihrem EDW-Entwicklungslebenszyklus erreichen. Die Ausführung automatisierter Tests bei jedem Einchecken oder Zusammenführen (Mergen) von Code stellt sicher, dass Probleme mit der Datenkonsistenz oder Fehler frühzeitig erkannt und behoben werden, bevor sie in die Produktion übergeben werden. In der Regel wird für die Durchführung automatisierter Tests eine separate Test- (oder CI-) Umgebung erstellt.

Hier sind einige allgemeine Empfehlungen für das Erstellen und Betreiben einer Testumgebung:

Gestalten Sie die CI-Umgebung so ähnlich wie möglich zur Produktionsumgebung.
Erstellen Sie Test-Quelldatenbanken und Quelldateien, die von realen Daten abgeleitet sind.
Die Test-Quelldateien und -Quelldatenbanken sollten klein sein, damit die Tests schnell ausgeführt werden können.
Die Test-Quelldateien und -Quelldatenbanken sollten zudem statisch sein, damit die erwarteten Ergebnisse im Voraus bekannt sind.
Testen Sie Full-Load- und Incremental-Load-Muster, da sich die Logik beider Muster in den meisten Fällen unterscheidet.
Führen Sie Tests nicht nur für die zusammenzuführenden Änderungen aus, sondern auch für alle nachgelagerten Abhängigkeiten (Downstream Dependencies) oder sogar für den gesamten Ladeprozess im Allgemeinen, um Regressionen zu vermeiden.

Fazit

In diesem Newsletter haben wir Ihnen einen Überblick über verschiedene Methoden und Ansätze für das technische Testen eines Data-Vault-gestützten EDW gegeben.

Wir haben das Testen verschiedener Phasen des EDW-Ladeprozesses behandelt, einschließlich der Extraktion von Daten aus Datenquellen, dem Laden von Data-Vault-Entitäten und dem Informationsbereitstellungsprozess (Information Delivery Process), wobei der Hauptfokus auf dem Laden von Data-Vault-Entitäten lag.

Wir haben auch das Unit-Testing von Hash-Key- und Hash-Diff-Berechnungen behandelt.

Es ist wichtig, sicherzustellen, dass Ihre Hashing-Lösung plattform- und werkzeugunabhängig (platform-/tool-agnostisch) ist, insbesondere während des Migrationsprozesses.

Wir haben auch gelernt, dass das Testen von Business-Rules ein wesentlicher Bestandteil des Informationsbereitstellungsprozesses ist, da diese die Daten interpretieren und definieren, was Geschäftsanwender in ihren Berichten sehen. Wir haben die Bedeutung von Unit-Tests für die Business-Rules und die Zusammenarbeit mit dem Fachbereich (Business) bei der Definition von Testfällen und erwarteten Ergebnissen hervorgehoben.

Darüber hinaus haben wir die Bedeutung der Testautomatisierung während der Entwicklungsphase sowie für die Ermöglichung von Continuous Integration betont und Empfehlungen für die Erstellung und den Betrieb einer Testumgebung gegeben.

In unserem Webinar gehen wir noch tiefer auf dieses Thema ein. Nutzen Sie die Gelegenheit und sehen Sie sich die Aufzeichnung kostenlos an!

Ole Bause In Data Warehouse, Experte

Metadaten meistern: Datenkataloge im Data Warehousing mit DataHub

Perfektes Metadatenmanagement im Data Warehousing

In der heutigen datengesteuerten Welt ist es essenziell, große Datenmengen effizient zu verwalten und zu organisieren. Unternehmen aller Branchen stehen vor der Herausforderung, mehr Daten als je zuvor zu bewältigen. Die Einführung und Entwicklung eines Enterprise Data Warehouse spielt naturgemäß eine zentrale Rolle, löst jedoch eine wesentliche Herausforderung nicht: Wie lassen sich die Daten, insbesondere die Metadaten, im Data Warehouse effektiv organisieren und verwalten? Hier kommen Datenkataloge ins Spiel und Tools wie DataHub werden unverzichtbar.

Ein Datenkatalog dient als umfassendes Inventar der Datenbestände (Data Assets) einer Organisation und liefert Kontext, Anmerkungen sowie Metadaten, um das Verständnis und das Auffinden von Daten zu erleichtern. Er funktioniert wie eine Landkarte für Ihre Daten und hilft Anwendern, sich in der komplexen Datenlandschaft zurechtzufinden und genau die benötigten Informationen zu identifizieren.

Ein Datenkatalog unterstützt Nutzer dabei zu verstehen, wo im Data Warehouse spezifische Daten liegen, die ihren Anforderungen entsprechen, woher diese Daten stammen und wie sie mit anderen Datensätzen verknüpft sind. Dies vereinfacht Aufgaben wie Datenanalyse und Reporting erheblich und macht das Data Warehouse für jeden im Unternehmen zugänglicher und nutzbarer.

Metadaten meistern: Datenkataloge im Data Warehousing mit DataHub

Verpassen Sie nicht unser bevorstehendes Webinar zum Thema Datenkataloge! Diese Session beleuchtet im Detail die entscheidende Rolle von Datenkatalogen im Data Warehousing – mit einem exklusiven Fokus auf das leistungsstarke Tool DataHub. Sie erhalten praktische Einblicke zur Optimierung von Data Discovery, Metadatenmanagement, Data Lineage und Data Governance. Melden Sie sich noch heute an und verwandeln Sie Ihre Datenmanagement-Strategie in einen echten Wettbewerbsvorteil.

Watch webinar recording

In this article:

Datenkataloge verstehen
- Was ist ein Datenkatalog?
- Rolle eines Datenkatalogs im Data Warehousing
Einführung in DataHub
- Hauptmerkmale und Funktionen von DataHub
Fazit

Datenkataloge verstehen

Was ist ein Datenkatalog?

Allgemein ist ein Datenkatalog ein Metadaten-Inventar, das aus organisierten und strukturierten Metadaten zu allen Data Assets einer Organisation besteht. Er bildet den zentralen Ort, an dem sämtliche Metadaten gespeichert, kombiniert und kategorisiert werden. Das erleichtert das Auffinden und Verstehen der entsprechenden Daten erheblich, beispielsweise innerhalb eines Data Warehouse. Ein Datenkatalog bietet zudem gezielte Suchfunktionen, um spezifische Daten aus den indexierten Datensätzen zu filtern. Er dient als Single Source of Truth für Ihre Metadaten und sorgt dafür, dass Nutzer den Daten vertrauen können, die sie für Analysen und Geschäftsentscheidungen heranziehen.

Rolle eines Datenkatalogs im Data Warehousing

Im Kontext des Data Warehousing bringt ein Datenkatalog zahlreiche Vorteile mit sich. Er bietet eine zentrale Möglichkeit, alle im Data Warehouse gespeicherten Daten zu erkunden und zu durchsuchen. Sowohl technische Anwender als auch Business User können relevante Daten entdecken, deren Kontext verstehen und sicherstellen, dass diese aktuell, verlässlich und präzise sind. Die folgende Abbildung zeigt, wo Datenkataloge im Data Warehousing mit Data Vault 2.0 zum Einsatz kommen. Ein Datenkatalog sollte die gesamte Enterprise-BI-Lösung abdecken. Dies gilt beispielsweise auch für einen Data Lake, sofern vorhanden, sowie für den Information Delivery Layer.

Nachdem wir die Grundlagen eines Datenkatalogs beleuchtet haben, betrachten wir nun die Rolle der einzelnen Komponenten genauer und untersuchen, wie ein Tool wie DataHub Organisationen bei diesen Aufgaben unterstützt.

Einführung in DataHub

In der Welt der Datenkataloge sticht DataHub als eine immer beliebtere Wahl für Unternehmen hervor. DataHub ist ein etabliertes Open-Source-Tool, das ursprünglich von LinkedIn entwickelt wurde, um den steigenden Bedarf an einer dynamischen und skalierbaren Datenmanagement-Lösung zu decken. Es entstand aus der Erkenntnis, dass bestehende Werkzeuge den wachsenden Anforderungen von LinkedIn nicht mehr gewachsen waren.

Mit dem Wachstum von LinkedIn stiegen auch Datenvolumen, Datenvielfalt und Datengeschwindigkeit (Volume, Variety, Velocity). LinkedIn erkannte die Notwendigkeit einer effizienteren Verwaltung seiner Daten und veröffentlichte DataHub im Jahr 2020 als Open-Source-Software. Dies ermöglichte es anderen Organisationen, von diesem fortschrittlichen Werkzeug zu profitieren. Seitdem haben zahlreiche Unternehmen DataHub als moderne, skalierbare Datenkataloglösung adaptiert.

DataHub unterstützt sowohl Push- als auch Pull-basierte Metadaten-Ingestion und bietet eine breite Palette an Integrationen, wie z. B. Airflow, BigQuery, Databricks, dbt, Hive, Kafka, Looker, MSSQL, MongoDB, Oracle, S3, Power BI, Snowflake, Spark und viele mehr. Eine vollständige Liste finden Sie hier. Dies verleiht DataHub die Fähigkeit, Metadaten aus mehreren Quellen zu denselben Daten zu kombinieren und anzuzeigen – beispielsweise eine dbt-Modelldefinition und das Ergebnis erfolgreicher Tests direkt neben dem Datenbankschema und den Spaltenstatistiken.

Hauptmerkmale und Funktionen von DataHub

Als Metadaten-Plattform geht DataHub über traditionelle Datenkataloge hinaus. DataHub bietet folgende Kernfunktionen:

1. Skalierbarkeit: DataHub ist darauf ausgelegt, Metadaten von Tausenden Datensätzen zu verarbeiten, was es zu einer hervorragenden Wahl für große Organisationen macht.

2. Flexibles und erweiterbares Datenmodell: Das zugrunde liegende technische Datenmodell ist flexibel gestaltet, sodass Organisationen es gezielt auf ihre spezifischen geschäftlichen Anforderungen abstimmen können.

3. Leistungsstarke Suche und Data Discovery: Unter Nutzung von Elasticsearch bietet DataHub eine robuste Suchfunktion, die es Anwendern ermöglicht, Datensätze anhand verschiedener Attribute wie Herkunft, Schema und Nutzung schnell zu finden.

4. Umfassende Metadaten: Im Gegensatz zu herkömmlichen Datenkatalogen erfasst und präsentiert DataHub eine Vielzahl an Metadaten, einschließlich Data Lineage, operativer Metadaten und Business-Metadaten. Dies verschafft Anwendern ein ganzheitliches Verständnis ihrer Daten.

5. Data Lineage und Beziehungsanalyse: DataHub erfasst und visualisiert automatisch die Data Lineage und zeigt auf, wie Daten durch verschiedene Systeme fließen. Zudem werden Beziehungen zwischen Datensätzen dargestellt, sodass Nutzer nachvollziehen können, wie verschiedene Data Assets miteinander interagieren.

Fazit

Die Nutzung eines Datenkatalogs bringt entscheidende Vorteile mit sich:

Verbesserte Data Discovery: Dank der Such- und Kategorisierungsfunktionen eines Datenkatalogs finden Nutzer genau die benötigten Daten schnell, ohne langwierig große Datensätze durchsuchen zu müssen.
Besseres Datenverständnis: Die Metadaten in einem Datenkatalog liefern den notwendigen Kontext, was die korrekte Interpretation und Nutzung der Daten erleichtert.
Bessere Compliance und Governance: Ein Datenkatalog unterstützt Data-Governance-Initiativen, indem er sicherstellt, dass Daten konsistent, präzise und konform mit relevanten Vorschriften sind.
Erhöhtes Datenvertrauen: Durch Transparenz über die Data Lineage schafft ein Datenkatalog Vertrauen in die Daten, da Anwender deren Ursprung nachvollziehen und Qualität sowie Zuverlässigkeit überprüfen können.
Zeit- und Ressourceneffizienz: Indem ein Datenkatalog das Auffinden und Verstehen von Daten erleichtert, spart er wertvolle Ressourcen im Unternehmen, beschleunigt datengestützte Prozesse und entlastet Datenmanagement-Teams.

Zusammenfassend bietet DataHub eine flexible, funktionsreiche und umfassende Lösung für Datenkataloge in einer Data-Warehousing-Umgebung. Durch die Bereitstellung leistungsstarker Funktionen für Data Discovery, Metadatenmanagement, Data Lineage und Data Governance ermöglicht DataHub es Unternehmen, den maximalen Wert aus ihren Daten zu schöpfen.

Wenn Sie mehr über Datenkataloge erfahren möchten, können Sie sich die Aufzeichnung hier kostenlos ansehen.

Marc Winkelmann In Datenwerkzeuge, Fortgeschrittene

Data Vault 2.0 mit Hadoop und Hive/Spark

Hadoop und Hive/Spark in Data Vault 2.0

In diesem Artikel erhalten Sie einen Überblick darüber, was Hadoop und Hive sind und warum sie als Alternative zu traditionellen Datenbanken eingesetzt werden können.

Data Vault 2.0 mit Hadoop und Hive/Spark

Dieses Webinar befasst sich eingehend mit den Details von Hadoop und Hive, einschließlich ihrer Funktionsweise und ihrer Kommunikation untereinander. Der zweite Teil der Präsentation konzentriert sich auf eine Data Vault 2.0-Beispielarchitektur unter Verwendung von Batch-Loading und bietet den Teilnehmern Einblicke, wie ein solches Szenario in der Praxis aussehen kann, um in realen Projekten einen echten Mehrwert zu schaffen. Unabhängig davon, ob Sie ein erfahrener Datenprofi sind oder gerade erst am Anfang stehen, ist dieses Webinar eine wertvolle Ressource für jeden, der mehr über Hadoop erfahren möchte. Wenn Sie also Ihr Wissen über diese Technologien erweitern und deren Potenzial in der Welt der Datenanalyse erkunden möchten, sollten Sie dieses Webinar nicht verpassen.

Watch webinar recording

In this article:

Hadoop
HIVE
- Was sind die Komponenten?
Fazit

Hadoop

Hadoop wird verwendet, um große Datenmengen effizient zu verarbeiten und zu analysieren, indem die Arbeitslast auf einen Cluster aus Standardhardware (Commodity Hardware) verteilt wird. Dies ermöglicht eine parallele Verarbeitung und bietet Fehlertoleranz durch ein verteiltes Dateisystem und ein flexibles Ressourcenmanagement-Framework.

HDFS – Hadoop Distributed File System

HDFS ist ein verteiltes Dateisystem, das zuverlässigen und skalierbaren Speicher für Big Data bietet. Es zerlegt große Dateien in Blöcke und verteilt diese über einen Cluster aus Standardhardware. HDFS stellt die Zuverlässigkeit und Verfügbarkeit von Daten durch kontinuierliche Datenreplikation sicher.

Yet Another Resource Negotiator – YARN

YARN bietet ein flexibles, skalierbares Ressourcenmanagement-Framework für Hadoop, das es einer Vielzahl von Anwendungen und Workloads ermöglicht, nebeneinander zu existieren und die Ressourcen des Clusters effizient zu nutzen. Es abstrahiert die zugrunde liegende Infrastruktur und ermöglicht die dynamische Zuweisung von Ressourcen basierend auf den Anforderungen der jeweiligen Anwendung.

MapReduce – MR

MapReduce ist ein Programmiermodell und Verarbeitungs-Framework für die verteilte Datenverarbeitung in Hadoop. Es ermöglicht die parallele Verarbeitung großer Datensätze, indem es die Arbeitslast in Map- und Reduce-Aufgaben aufteilt. Map-Aufgaben verarbeiten die Daten parallel, woraufhin die Ausgabe kombiniert und reduziert wird, um das Endergebnis zu erzielen.

Hadoop Common

Hadoop Common stellt Bibliotheken, Hilfsprogramme und die nötige Infrastruktur für die anderen Komponenten von Hadoop bereit. Es umfasst allgemeine Dienstprogramme, Authentifizierungsmechanismen und Schnittstellen, die von verschiedenen Hadoop-Modulen genutzt werden.

Welche Vorteile bietet Hadoop?

Skalierbarkeit
Hadoop ermöglicht die Speicherung und Verarbeitung riesiger Datenmengen durch horizontale Skalierung über einen Cluster von Standardhardware. Es kann Petabytes an Daten verarbeiten, ohne dass die Leistung beeinträchtigt wird.

Verteiltes Rechnen (Distributed Computing)
Hadoop verteilt Daten und Verarbeitungsaufgaben auf mehrere Knoten in einem Cluster, was eine parallele Verarbeitung und eine schnellere Datenanalyse ermöglicht. Dieses verteilte Rechenmodell sorgt für eine effiziente Ressourcennutzung und eine hochperformante Datenverarbeitung.

Fehlertoleranz
Hadoop bietet eine hohe Fehlertoleranz, indem Daten über mehrere Knoten im Cluster hinweg repliziert werden. Wenn ein Knoten ausfällt, kann weiterhin auf die Daten von anderen Replikaten zugegriffen werden, was die Zuverlässigkeit und Verfügbarkeit der Daten garantiert.

Kosteneffizienz
Hadoop ist für den Betrieb auf kostengünstiger Standardhardware ausgelegt, was es zu einer wirtschaftlichen Lösung für die Speicherung und Verarbeitung großer Datenmengen macht. Dadurch erübrigt sich der Einsatz teurer Spezialhardware.

Flexibilität und Erweiterbarkeit
Die modulare Architektur von Hadoop ermöglicht die nahtlose Integration verschiedener Tools und Frameworks innerhalb des Hadoop-Ökosystems. Sie unterstützt eine Vielzahl von Datenverarbeitungsaufgaben, einschließlich Batch-Verarbeitung, Echtzeitverarbeitung, maschinellen Lernens und vielem mehr.

Datenlokalität (Data Locality)
Das verteilte Dateisystem von Hadoop, HDFS, zielt darauf ab, die Berechnung so nah wie möglich an die Daten zu bringen. Durch die Verarbeitung der Daten direkt an ihrem Speicherort minimiert Hadoop die Datenbewegung über das Netzwerk, was die Latenz verringert und die Gesamtleistung verbessert.

Ökosystem und Community
Hadoop verfügt über ein reichhaltiges Ökosystem mit einer Vielzahl von Tools, Bibliotheken und Frameworks, die seine Funktionalität für verschiedene Anwendungsfälle erweitern. Zudem gibt es eine große und aktive Community von Nutzern, Entwicklern und Mitwirkenden, die kontinuierliche Verbesserungen und Support bereitstellen.

Diese Vorteile machen Hadoop zu einer leistungsstarken und bewährten Lösung für den Umgang mit Big Data, die es Unternehmen ermöglicht, riesige Mengen strukturierter und unstrukturierter Daten effizient zu speichern, zu verarbeiten und wertvolle Erkenntnisse daraus zu gewinnen. Das gesamte Ökosystem kann auch lokal (On-Premises) betrieben werden, was es zu einer hervorragenden Alternative macht, wenn die Cloud keine Option darstellt.

HIVE

Hive ist eine Data-Warehouse-Infrastruktur, die auf Hadoop aufbaut und eine höhere, SQL-ähnliche Abfragesprache namens HiveQL für die Abfrage und Analyse großer Datensätze bereitstellt.

Was sind die Komponenten?

Datenspeicherung
Hive nutzt das Hadoop Distributed File System (HDFS) als zugrunde liegendes Speichersystem. Es speichert Daten im HDFS auf verteilte und fehlertolerante Weise, was eine skalierbare und zuverlässige Datenspeicherung ermöglicht.

Schemadefinition
Hive ermöglicht es Benutzern, ein Schema für ihre Daten mithilfe einer Sprache namens Hive Data Definition Language (DDL) zu definieren. Dies erlaubt es den Anwendern, Tabellen, Partitionen, Spalten, Datentypen und andere mit den Daten verknüpfte Metadaten festzulegen.

Abfrageoptimierung
Hive optimiert Abfragen durch moderne Abfrageplanung und Optimierungstechniken. Ziel ist es, effiziente Ausführungspläne zu erstellen, um Datenbewegungen zu minimieren, die Ressourcennutzung zu optimieren und die Abfrageleistung zu maximieren.

Hive Metastore
Hive unterhält ein Metadaten-Repository namens Hive Metastore. Es speichert Informationen über Tabellen, Partitionen, Schemata und andere Metadaten, die mit den im HDFS gespeicherten Daten verknüpft sind. Der Metastore ermöglicht eine effiziente Verwaltung und den schnellen Abruf von Metadaten während der Abfrageverarbeitung.

Erweiterbarkeit:
Hive bietet eine hohe Flexibilität durch benutzerdefinierte Funktionen wie User-Defined Functions (UDFs), User-Defined Aggregations (UDAs) und User-Defined Table Functions (UDTFs). Diese ermöglichen es Entwicklern, eigene Logiken und Operationen in Programmiersprachen wie Java, Python oder anderen unterstützten Sprachen zu implementieren

Integration mit anderen Tools
Hive lässt sich nahtlos in verschiedene andere Tools und Frameworks im Hadoop-Ökosystem integrieren. Beispielsweise kann es zusammen mit Apache Spark, Apache Pig, Apache HBase und anderen Komponenten eingesetzt werden, um eine vollständige Datenverarbeitungs- und Analyselösung bereitzustellen.

Partitionierung und Bucketing
Hive unterstützt Datenpartitionierung und Bucketing, was eine strukturierte Organisation und Speicherung der Daten ermöglicht. Die Partitionierung teilt Daten basierend auf bestimmten Kriterien in logische Partitionen auf, während Bucketing die Daten anhand von Hash-Werten in gleich große Buckets unterteilt.

SerDe
Hive verwendet ein Serialisierungs- und Deserialisierungs-Framework namens SerDe (Serializer/Deserializer), um Daten in verschiedenen Formaten wie CSV, JSON, Avro und anderen zu lesen und zu schreiben. Benutzer können das passende SerDe für ihr jeweiliges Datenformat angeben, um eine reibungslose Datenverarbeitung zu gewährleisten

Insgesamt vereinfacht Hive die Abfrage und Analyse von Daten in Hadoop durch die Bereitstellung einer vertrauten, SQL-ähnlichen Schnittstelle. Es abstrahiert die Komplexität des Schreibens von Low-Level-MapReduce- oder Tez-Jobs und bietet einen deklarativen und benutzerfreundlichen Ansatz für die Interaktion mit großen Datenmengen.

Fazit

Hadoop ist eine robuste und funktionsreiche Umgebung, deren Verwaltung und Administration durchaus eine Herausforderung darstellen kann. Seine zahlreichen Vorteile machen es jedoch zu einer äußerst attraktiven Wahl, je nach den individuellen Anforderungen und dem im Unternehmen vorhandenen Fachwissen. Wenn Sie mehr darüber erfahren möchten, sehen Sie sich gerne die folgende Aufzeichnung an.

Deniz Polat In Datenwerkzeuge, Fortgeschrittene

Echtzeitverarbeitung in Data Vault 2.0 auf Microsoft Azure

Data Vault 2.0 auf Microsoft Azure

In diesem Newsletter erhalten Sie einen Überblick darüber, was Echtzeitverarbeitung ist und welche Möglichkeiten sie für Ihre Data Vault 2.0-Implementierung bietet.

Echtzeitverarbeitung mit Data Vault 2.0 auf Azure

In diesem Webinar erörtern wir die neuen Data-Warehouse-Anforderungen an Daten und gehen auf die Echtzeitverarbeitung (Real-Time Processing) ein. Für einen ersten Überblick behandeln wir verschiedene Architekturen zur Echtzeitverarbeitung. Der zweite Teil konzentriert sich auf die Echtzeit-Datenarchitektur mit Data Vault 2.0 und beinhaltet einen kurzen Überblick über Microsoft Azure. Zudem sehen Sie eine Implementierung der Echtzeitverarbeitung mit Data Vault 2.0 in Azure. Dieses Webinar richtet sich an alle, für die Echtzeitdaten in Data Vault 2.0 neu sind und die an einem Überblick sowie der Implementierung in Azure interessiert sind.

Watch Webinar Part 1 Watch Webinar Part 2

In this article:

Was Sie erwartet
Der traditionelle Weg – Batch-Loading
Der neue Weg – Echtzeitdaten
Verschiedene Arten von Echtzeitdaten
Implementierung der Echtzeitverarbeitung
Nutzung von Microsoft Azure für die Echtzeitverarbeitung
Fazit

Was Sie erwartet

Sie erfahren, wie Ihnen die Echtzeitverarbeitung ermöglicht, schneller Wert aus Daten zu schöpfen, stets die aktuellsten Daten in Ihren Reporting-Tools zur Verfügung zu haben und präzisere datenbasierte Entscheidungen zu treffen. Dadurch ist Ihr Unternehmen in der Lage, sich schneller an Marktveränderungen anzupassen, indem Entwicklungen anhand neuester Daten sofort sichtbar werden.

Zudem können Sie Kosten sparen, indem Sie sich vom klassischen Batch-Loading verabschieden: Die normalerweise dafür benötigte Spitzenrechenleistung wird reduziert und gleichmäßiger über den Tag verteilt. Dies gilt insbesondere bei der Nutzung von Cloud-Umgebungen, da dort starre beziehungsweise zugesagte Umgebungen ersetzt werden und die benötigte Rechenleistung bedarfsgerecht bereitgestellt werden kann.

Der traditionelle Weg – Batch-Loading

Batch-Loading ist eine traditionelle Methode, um Daten in großen Blöcken (Batches) – meist über Nacht – in ein Data-Warehouse-System zu laden. Die Daten aus den Datenquellen werden bis zu einem bestimmten Zeitpunkt in der Nacht geliefert, um anschließend transformiert und in den Core-Data-Warehouse-Layer geladen zu werden.

Diese Methode führt über Nacht zu einer Spitze (Peak) bei der Datenverarbeitung. Unternehmen müssen ihre Infrastruktur entsprechend auslegen, um diese erwartete maximale Spitze an benötigter Rechenleistung bewältigen zu können.

Der neue Weg – Echtzeitdaten

Echtzeitdaten werden sofort verarbeitet und bereitgestellt, sobald sie entstehen, anstatt über Nacht schubweise geladen zu werden. Bei der Nutzung von Echtzeit-Ansätzen erweitert sich das Ladefenster auf 24 Stunden. Damit entfallen die nächtlichen Lastspitzen und deren Nachteile.
Bei der Nutzung von Echtzeitdaten werden diese stets als Non-Historized Link oder als Satellite modelliert.

Mögliche Anwendungsfälle für Echtzeitdaten sind das Vitaldaten-Monitoring im Gesundheitswesen, die Bestandsverfolgung (Inventory Tracking), das Nutzerverhalten in sozialen Medien oder die Überwachung von Produktionslinien.

Verschiedene Arten von Echtzeitdaten

Es gibt verschiedene Arten von Echtzeitdaten, basierend auf der Ladefrequenz sowie dem Grad der Dringlichkeit beziehungsweise Unmittelbarkeit der Daten.

„Near Real-Time Data“ (nahezu in Echtzeit) bezieht sich auf Daten, die mindestens alle fünfzehn Minuten in Mini-Batches geladen werden, wobei die Daten bis zum Laden in die Datenanalyseplattform in einem Cache gespeichert werden.
Echte Echtzeitdaten („Actual Real-Time Data“), auch Message Streaming genannt, beinhalten das direkte Laden jeder einzelnen Nachricht in die Datenanalyseplattform ohne Cache.
Diese Art von Echtzeitdaten ist nützlich, wenn Daten sofort nach ihrer Erzeugung für Dashboards oder weiterführende Analysen verfügbar sein müssen.

Die akzeptable Verzögerung bei der Verarbeitung von Echtzeitdaten wird in der Regel durch die Konsequenzen eines versäumten Zeitfensters (Deadline) definiert. Zudem gibt es drei Arten von Echtzeitsystemen: Hard Real-Time, Soft Real-Time und Firm Real-Time.

Implementierung der Echtzeitverarbeitung

Wie implementiert man also Echtzeit-Datenverarbeitung in eine Data-Warehouse-Lösung? Es gibt hierfür viele Architekturen, wir werden uns jedoch auf die Lambda- und die Data Vault 2.0-Architektur konzentrieren.

Generic real-time processing architecture

Die Lambda-Architektur unterteilt die Datenverarbeitung in einen Speed Layer und einen Batch Layer. Der Speed Layer verarbeitet Echtzeit-Nachrichten mit Fokus auf Geschwindigkeit und Durchsatz, während der Batch Layer durch die Verarbeitung großer Datenmengen in regelmäßigen Batches Genauigkeit und Vollständigkeit gewährleistet. Der Serving Layer integriert die Daten aus beiden Layern für Präsentationszwecke.

Auf den ersten Blick ähnelt die Data Vault 2.0-Architektur der Lambda-Architektur, behandelt jedoch einige Aspekte anders. Aus der Perspektive von Data Vault 2.0 weist die Lambda-Architektur Schwachstellen auf, wie etwa die Implementierung einer einzelnen Schicht in jedem Datenfluss sowie das Fehlen einer definierten Schicht zur Erfassung unveränderter Rohdaten für Revisionszwecke (Auditing).

Die Data Vault 2.0-Architektur erweitert die bestehende batch-getriebene Architektur um einen Echtzeit-Teil namens „Message Streaming“. Dabei werden mehrere Schichten zur Erfassung und Verarbeitung von Echtzeitdaten implementiert, die an mehreren Punkten mit dem batch-getriebenen Fluss integriert werden. Nachrichten werden vom Publisher downstream zum Subscriber gepusht, in den Raw Data Vault geladen und in den Data Lake abgezweigt. Der Hauptprozess ist jedoch der Push innerhalb des Message-Streaming-Bereichs. Die Architektur ist in der Lage, Daten aus Batch-Feeds zu integrieren oder die Echtzeitdaten direkt in das Dashboard zu streamen.

Nutzung von Microsoft Azure für die Echtzeitverarbeitung

Microsoft Azure ist eine Cloud-Computing-Plattform sowie eine Sammlung von Diensten von Microsoft. Die Plattform bietet eine Vielzahl von Services, darunter virtuelle Maschinen, Datenbanken, Analysen, Speicher und Netzwerke. Diese Dienste können genutzt werden, um Web- und mobile Anwendungen zu erstellen, hochvolumige Datenverarbeitungsaufgaben auszuführen, Daten zu speichern und zu verwalten, Websites zu hosten und vieles mehr.

Microsoft Azure for real-time processing

Die Abbildung beschreibt eine typische Echtzeit-Architektur, wie sie von den Beratern von Scalefree verwendet wird und der konzeptionellen Data Vault 2.0-Architektur folgt.

Datenquellen liefern Daten entweder in Batches oder in Echtzeit. Diese werden in den Azure Data Lake geladen oder vorab vom Event Hub entgegengenommen. Der Raw Data Vault Loader trennt Business Keys, Beziehungen (Relationships) und beschreibende Daten (Descriptive Data) mittels Stream Analytics und leitet die Nachricht an den Business Vault Processor weiter. Der Business Vault Processor wendet Transformationen und weitere Geschäftsregeln an, um die Ziel-Nachrichtenstruktur für die Nutzung durch die (Dashboarding-)Anwendung zu erzeugen. Die Ergebnisse können in physische Tabellen im Business Vault auf Synapse geladen oder in Echtzeit ohne weitere Materialisierung in der Datenbank bereitgestellt werden. Die Zielnachricht wird generiert und an den Real-Time Information Mart Layer gesendet, der durch ein Streaming-Dataset implementiert ist und von Power BI genutzt wird.

Der Cache des Dashboard-Dienstes läuft schnell ab, jedoch stehen in der Synapse-Datenbank alle Daten für weitere Verwendungszwecke, einschließlich des strategischen, langfristigen Reportings, zur Verfügung.

Fazit

Zusammenfassend bietet die Echtzeit-Datenverarbeitung zahlreiche Vorteile gegenüber traditionellen Batch-Loading-Methoden. Dazu gehören die Möglichkeit, schneller Wert aus Daten zu generieren, die aktuellsten Informationen in Reporting-Tools bereitzustellen und präzisere Entscheidungen zu treffen. Durch eine schnellere Anpassung an Marktveränderungen können Unternehmen ihren Wettbewerbsvorsprung sichern. Die Abkehr vom Batch-Loading kann zudem Kosten sparen, da Spitzen bei der benötigten Rechenleistung reduziert werden.

Wie bereits erwähnt, zeigt die letzte Abbildung eine Architektur, die von den Scalefree-Beratern implementiert wurde, um Echtzeitdaten zu nutzen.

Lesen Sie mehr dazu in unserem kürzlich veröffentlichten Microsoft-Blogartikel.

Wie sind Ihre aktuellen Erfahrungen mit der Echtzeit-Datenverarbeitung?
Denken Sie darüber nach, Ihr Data Vault durch den Einsatz von Echtzeitdaten auf das nächste Level zu heben?
Oder nutzen Sie diese bereits und möchten sie weiter optimieren?

Teilen Sie uns Ihre Gedanken gerne im Kommentarbereich mit!