Datenarchitekturen E-Book

James Serra

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch

Seitenzahl: 419

Veröffentlichungsjahr: 2024

Beschreibung

Gewinnen Sie Klarheit über verbreitete Datenarchitektur-Konzepte - Alle Konzepte im Überblick: Der erste Leitfaden für die verschiedenen Ansätze, der hilft, eine Architektur auszuwählen, die zu den eigenen Anforderungen passt - Beschreibt die populärsten Datenarchitekturen, zeigt Vor- und Nachteile und wie sich Theorie und Praxis unterscheiden - Inkl. zahlreicher Schaubilder und vergleichender Tabellen Data Fabric, Data Lakehouse und Data Mesh sind als praktikable Alternativen zum Modern Data Warehouse in den Fokus der Unternehmen gerückt. Diese neuen Architekturen haben solide Vorteile, aber ihre fachliche Einordnung ist auch von Missverständnissen und Übertreibungen geprägt. Dieses praxisorientierte Buch bietet eine gut verständliche Einführung in jeden dieser Architekturansätze und hilft damit Datenexpertinnen und -praktikern, die jeweiligen Vor- und Nachteile zu verstehen. James Serra erläutert die Konzepte gängiger Datenarchitekturen und zeigt dabei auch, wie sich Data Warehouses weiterentwickeln mussten, um mit Data-Lake-Funktionen arbeiten zu können. Sie erfahren, was Sie mit Data Lakehouses erreichen können und wie Sie Hype und Realität bei Data Meshs unterscheiden. Nach der Lektüre dieses Buchs werden Sie in der Lage sein, die für Ihre Zwecke am besten geeignete Datenarchitektur zu bestimmen. - Entwickeln Sie ein grundlegendes Verständnis für die verschiedenen Datenarchitekturen - Informieren Sie sich über die Stärken und Schwächen der einzelnen Ansätze - Verstehen Sie die Unterschiede zwischen Data Warehouses und Data Lakes - Profitieren Sie von der langjährigen Erfahrung von James Serra und erfahren Sie, wie Theorie und Praxis der jeweiligen Datenarchitekturen voneinander abweichen - Wählen Sie die beste Architektur für Ihren Anwendungsfall aus - Lernen Sie, wie man eine Architektur-Design-Sitzung durchführt, das Team organisiert und was die Erfolgsfaktoren für ein Projekt sind

Leseprobe

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Stimmen zum Buch Datenarchitekturen

In Datenarchitekturen leistet James Serra einen tollen Job, indem er die Entwicklung der führenden Datenarchitekturen und die Kompromisse zwischen ihnen erläutert. Dieses Buch sollte zur Pflichtlektüre für derzeitige und angehende Datenarchitektinnen und -architekten werden.

– Bill Anton, Data Geek, Opifex Solutions

James hat über 30 Jahre Wissen und Weisheit über Datenarchitekturen in diesem umfassenden und sehr lesenswerten Buch zusammengefasst. Für diejenigen, die die eigentliche Arbeit bei der Bereitstellung von Analysen leisten müssen, anstatt Lobeshymnen darüber anzustimmen, ist dieses Buch ein Muss.

– Dr. Barry Devlin, Gründer und Direktor, 9sight Consulting

Diese Referenz sollte im Bücherregal eines jeden Datenarchitekten stehen. Mit klaren und aufschlussreichen Beschreibungen der aktuellen und geplanten Technologien werden die Leserinnen und Leser ein gutes Gefühl dafür bekommen, wie sie ihre Unternehmen steuern, um die Herausforderungen der sich ständig weiterentwickelnden Datenlandschaft zu meistern. Dies ist eine für Neueinsteiger und erfahrene Datenarchitekten gleichermaßen unschätzbare Referenz.

– Mike Fung, Master Principal Cloud Solution Architect, Oracle

Das Marketing-Getöse und das Gerede von Vordenkern der Branche haben viel Verwirrung über Datenarchitekturmuster gesät. Mit seiner umfassenden Erfahrung und seinen Kommunikationsfähigkeiten durchbricht James Serra die Störgeräusche und verschafft Klarheit sowohl über altbewährte Datenarchitekturmuster als auch über die neuesten Methoden in der Branche, die sowohl Datenpraktikern als auch Datenverantwortlichen helfen werden. Legen Sie es auf Ihren Schreibtisch – Sie werden es oft zurate ziehen.

– Sawyer Nyquist, Inhaber, Autor und Consultant, The Data Shop

Die Welt der Datenarchitekturen ist komplex und voller Störgeräusche. Dieses Buch bietet eine frische, praktische Perspektive, die auf jahrzehntelanger Erfahrung aufbaut. Egal ob Sie Einsteiger oder Expertin sind, jeder mit einem Interesse an Daten muss dieses Buch lesen!

– Piethein Strengholt, Autor von »Data Management at Scale«

Ein lehrreiches Juwel! Datenarchitekturen schafft ein perfektes Gleichgewicht zwischen Einfachheit und Tiefe, sodass Technologieexpertinnen und -experten aller Ebenen die entscheidenden Datenkonzepte erfassen und die wesentlichen Kompromissentscheidungen verstehen, die bei der Planung einer Datenreise wirklich wichtig sind.

– Ben Reyes, Mitbegründer und Managing Partner, ZetaMinusOne LLC

Ich empfehle Datenarchitekturen als Quelle, die das Wissen liefert, um die verfügbaren Optionen zu verstehen und sich darin zurechtzufinden, wenn es darum geht, eine Datenarchitektur zu entwickeln.

– Mike Shelton, Cloud Solution Architect, Microsoft

Datenmanagement ist entscheidend für den Erfolg eines jeden Unternehmens. Das Buch Datenarchitekturen zerlegt die Schlagwörter in einfache und verständliche Konzepte sowie praktische Lösungen, um Ihnen zu helfen, die richtige Architektur für Ihren Datensatz zu finden.

– Matt Usher, Director, Pure Storage

Als Berater und Community-Leiter verweise ich oft auf das Blog von James Serra, um aktuelle und ausführliche Informationen über moderne Datenarchitekturen zu erhalten. Dieses Buch ist eine großartige Sammlung, die Serras Reichtum an herstellerneutralem Wissen verdichtet. Mein Favorit ist Teil III, in dem James die Vor- und Nachteile der einzelnen Architekturen diskutiert. Ich glaube, dass dieses Buch jedem Unternehmen, das seinen Datenbestand modernisieren will, ungemein nützen wird.

– Teo Lachev, Consultant, Prologika

Das Blog von James ist meine erste Anlaufstelle, wenn es darum geht, Architekturkonzepte zu entmystifizieren, technische Fachbegriffe zu verstehen und sich im Leben eines Lösungsarchitekten oder Dateningenieurs zurechtzufinden. Seine Fähigkeit, komplexe technische Konzepte in klare, leicht verständliche Erklärungen zu verwandeln, ist wirklich bemerkenswert. Dieses Buch ist eine unschätzbare Sammlung seiner Arbeit und dient als umfassendes Nachschlagewerk, um Architekturen zu entwerfen und nachzuvollziehen.

– Annie Xu, Senior Data Customer Engineer, Google

James hatte schon immer die Superkraft, komplexe Themen aufzugreifen und sie auf einfache Weise zu erklären. In diesem Buch trifft er alle wichtigen Punkte, um Ihnen zu helfen, die richtige Datenarchitektur auszuwählen und häufige (und teure!) Fehler zu vermeiden.

– Rod Colledge, Senior Technical Specialist (Daten und KI), Microsoft

Dieses Buch ist ein großer Meilenstein in der Entwicklung unseres Umgangs mit Daten in der Technologiebranche, und zwar über mehrere Jahrzehnte hinweg, was für die meisten wohl einer ganzen Karriere entspricht. Der Inhalt bietet großartige Einblicke für die nächste Generation von Datenexperten in Bezug darauf, was sie bei der Entwicklung zukünftiger Lösungen bedenken müssen.

– Paul Andrew, CTO, Cloud Formations Consulting

Ein fantastischer Leitfaden für Datenarchitekten, dieses Buch ist vollgepackt mit Erfahrungen und Einsichten. Die umfassende Abdeckung sich entwickelnder Trends und verschiedene Ansätze machen es zu einem unverzichtbaren Nachschlagewerk für alle, die ihr Verständnis des Fachgebiets erweitern möchten.

– Simon Whiteley, CTO, Advancing Analytics Limited

Es gibt niemanden, dem ich mit seinem Wissen über Datenarchitekturen und Datenprozesse mehr vertraue als James Serra. Dieses Buch bietet nicht nur eine umfassende und klare Beschreibung der wichtigsten architektonischen Prinzipien, Ansätze und Fallstricke, sondern befasst sich auch mit den überaus wichtigen menschlichen, kulturellen und organisatorischen Problemen, die Datenprojekte allzu oft gefährden, bevor sie in Gang kommen. Dieses Buch ist dazu prädestiniert, ein Grundlagenwerk für die Branche zu werden, und zwar sowohl für Hochschulstudentinnen und -studenten als auch für Geschäftsleute, die zum ersten Mal mit Daten in Berührung kommen (und vielleicht auch zum zweiten und dritten Mal)!

– Wayne Eckerson, Präsident der Eckerson Group

Das Buch Datenarchitekturen ist ein unverzichtbarer herstellerneutraler Leitfaden für die Datenexperten von heute. Es vergleicht aufschlussreich historische und moderne Architekturen. Hervorgehoben werden dabei die wichtigsten Kompromisse und Nuancen der Entscheidungsfindung bei der Auswahl einer geeigneten Architektur für die sich entwickelnde datengesteuerte Landschaft.

– Stacia Varga, Autorin und Data Analytics Consultant, Data Inspirations

Mit tiefgehender Praxiserfahrung ausgestattet, haben die neuesten Szenarien auf dem heutigen Markt eine anbieterspezifische Ausrichtung, inklusive Terminologie und Verkaufsoptionen. James nutzt seine jahrelange Expertise, um anbieterunabhängige, Cloud-übergreifende und branchenübergreifende Ansätze für kleine bis große Unternehmen zu zeigen.

– Jordan Martz, Senior Sales Engineer, Fivetran

Data Lake, Data Lakehouse, Data Fabric, Data Mesh … Es ist nicht einfach, die Spreu vom Weizen zu trennen. Das Wissen und die Erfahrung von James Serra sind eine großartige Ressource für alle, denen Verantwortung für die Datenarchitektur übertragen wurde.

– Dave Wells, Industry Analyst, eLearningcurve

Zu oft findet man in Büchern Anleitungen ohne Hintergrund oder Logik – dieses Buch löst dies. Mit einem umfassenden Überblick darüber, warum Daten auf eine bestimmte Art und Weise angeordnet sind, erfahren Sie mehr über den richtigen Weg, das »Wie« zu implementieren.

– Buck Woody, Principal Data Scientist, Microsoft

Datenarchitekturen ist nicht nur gründlich und detailliert, sondern bietet auch eine kritische Perspektive auf das, was funktioniert, und – was vielleicht noch wichtiger ist – auf das, was vielleicht nicht gut funktioniert. Egal ob ältere Datenansätze oder neuere wie Data Mesh diskutiert werden, das Buch bietet Weisheiten und Erkenntnisse, die jedem Datenpraktiker helfen, seine Datenreise zu beschleunigen.

– Eric Broda, Unternehmer, Data Consultant, Autor von »Implementing Data Mesh« (O’Reilly)

Kein anderes Buch, das ich kenne, erklärt so umfassend Data Lake, Warehouse, Mesh, Fabric und Lakehouse! Es ist Pflichtlektüre für alle Datenarchitektinnen und -ingenieure.

– Vincent Rainardi, Datenarchitekt und Autor

Zum liebevollen Andenken an meine Großeltern – Dolly, Bill, Martha und Bert

Datenarchitekturen

Modern Data Warehouse, Data Fabric, Data Lakehouse und Data Mesh richtig einsetzen

James Serra

Übersetzung von Frank Langenau

James Serra

Lektorat: Alexandra Follenius

Übersetzung: Frank Langenau

Copy-Editing: Sibylle Feldmann, www.richtiger-text.de

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Karen Montgomery, Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-96009-254-4

PDF

978-3-96010-874-0

ePub

978-3-96010-875-7

1. Auflage 2025

Translation Copyright für die deutschsprachige Ausgabe © 2025 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of Deciphering Data Architectures, ISBN 9781098150761 © 2024 James Serra. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«.

O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Übersetzer noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buchs stehen.

Inhalt

Vorwort

Einführung

Teil I: Grundlagen

1Big Data

Was ist Big Data, und wie kann Big Data Ihnen helfen?

Data Maturity

Stufe 1: Reaktiv

Stufe 2: Informativ

Stufe 3: Prädiktiv

Stufe 4: Transformativ

Self-Service Business Intelligence

Zusammenfassung

2Arten von Datenarchitekturen

Entwicklung von Datenarchitekturen

Relationales Data Warehouse

Data Lake

Modern Data Warehouses

Data Fabric

Data Lakehouse

Data Mesh

Zusammenfassung

3Die Architektur-Design-Sitzung

Was ist eine ADS?

Warum eine ADS abhalten?

Vor der ADS

Vorbereiten

Teilnehmerinnen und Teilnehmer einladen

Die ADS leiten

Einführungen

Erkundung

Whiteboarding

Nach der ADS

Tipps für die Durchführung einer ADS

Zusammenfassung

Teil II: Allgemeine Datenarchitekturkonzepte

4Das relationale Data Warehouse

Was ist ein relationales Data Warehouse?

Was ein Data Warehouse nicht ist

Der Top-down-Ansatz

Warum ein relationales Data Warehouse verwenden?

Nachteile bei Verwendung eines relationalen Data Warehouse

Ein Data Warehouse füllen

Wie oft sollen die Daten extrahiert werden?

Extraktionsmethoden

Wie man feststellt, welche Daten sich seit der letzten Extraktion geändert haben

Der Tod des relationalen Data Warehouse wurde übertrieben dargestellt

Zusammenfassung

5Data Lake

Was ist ein Data Lake?

Warum einen Data Lake verwenden?

Bottom-up-Ansatz

Best Practices für das Design von Data Lakes

Mehrere Data Lakes

Vorteile

Nachteile

Zusammenfassung

6Lösungen und Prozesse zur Datenspeicherung

Datenspeicherlösungen

Data Marts

Operational Data Stores

Data Hubs

Datenprozesse

Stammdatenverwaltung

Datenvirtualisierung und Datenföderierung

Datenkataloge

Datenmarktplätze

Zusammenfassung

7Ansätze für das Design

OLTP vs. OLAP

Operative und analytische Daten

Symmetrisches Multiprocessing und massive Parallelverarbeitung

Lambda-Architektur

Kappa-Architektur

Polyglotte Persistenz und polyglotte Datenspeicher

Zusammenfassung

8Ansätze zur Datenmodellierung

Relationale Modellierung

Schlüssel

Entity-Relationship-Diagramme

Normalisierungsregeln und -formen

Änderungen verfolgen

Dimensionale Modellierung

Fakten, Dimensionen und Schlüssel

Änderungen verfolgen

Denormalisierung

Common Data Model

Data Vault

Die Methodiken von Kimball und Inmon für das Data Warehousing

Die Top-down-Methodik von Inmon

Die Bottom-up-Methodik von Kimball

Eine Methodik auswählen

Hybride Modelle

Mythen über die Methodiken

Zusammenfassung

9Ansätze für die Datenaufnahme

ETL vs. ELT

Reverse ETL

Stapel- vs. Echtzeitverarbeitung

Stapelverarbeitung – Vor- und Nachteile

Echtzeitverarbeitung – Vor- und Nachteile

Data Governance

Zusammenfassung

Teil III: Datenarchitekturen

10Das Modern Data Warehouse

Die MDW-Architektur

Die MDW-Architektur – Vor- und Nachteile

RDW und Data Lake kombinieren

Data Lake

Relationales Data Warehouse

Schritt für Schritt zum MDW

EDW-Erweiterung

Temporärer Data Lake plus EDW

All-in-one

Fallstudie: Die strategische Umstellung bei Wilson & Gunkerk auf ein MDW

Herausforderung

Lösung

Ergebnis

Zusammenfassung

11Data Fabric

Die Data-Fabric-Architektur

Datenzugriffsrichtlinien

Metadatenkatalog

Stammdatenverwaltung

Datenvirtualisierung

Echtzeitverarbeitung

APIs

Dienste

Produkte

Weshalb von einem MDW auf eine Data-Fabric-Architektur umsteigen?

Potenzielle Nachteile

Zusammenfassung

12Data Lakehouse

Delta-Lake-Features

Performanceverbesserungen

Die Data-Lakehouse-Architektur

Was, wenn man das RDW überspringt?

Relationale Serving-Schicht

Zusammenfassung

13Data-Mesh-Grundlagen

Eine dezentralisierte Architektur

Der Hype um Data Mesh

Dehghanis vier Prinzipien des Data Mesh

Prinzip #1: Domain Ownership

Prinzip #2: Data-as-a-Product

Prinzip #3: Self-Serve-Infrastructure-as-a-Platform

Prinzip #4: Federated Computational Governance

Das »reine« Data Mesh

Datendomains

Logische Data-Mesh-Architektur

Verschiedene Topologien

Data Mesh vs. Data Fabric

Anwendungsfälle

Zusammenfassung

14Data Mesh einführen? – Mythen, Bedenken und die Zukunft

Mythen

Mythos: Data Mesh ist eine Silberkugel, mit der sich alle Datenprobleme schnell lösen lassen

Mythos: Ein Data Mesh ersetzt Ihren Data Lake und Ihr Data Warehouse

Mythos: Data-Warehouse-Projekte scheitern alle – ein Data Mesh löst dieses Problem

Mythos: Ein Data Mesh aufbauen bedeutet, absolut alles zu dezentralisieren

Mythos: Mit Datenvirtualisierungen lässt sich ein Data Mesh erstellen

Bedenken

Philosophische und konzeptionelle Fragen

Daten in einer dezentralisierten Umgebung kombinieren

Andere Probleme der Dezentralisierung

Komplexität

Duplizierung

Machbarkeit

Mitarbeiterinnen und Mitarbeiter

Hürden auf Domainebene

Organisatorische Bewertung: Sollten Sie ein Data Mesh einführen?

Empfehlungen für die Implementierung eines erfolgreichen Data Mesh

Die Zukunft von Data Mesh

Blick über den Tellerrand: Datenarchitekturen und ihre Anwendungen

Zusammenfassung

Teil IV: Menschen, Prozesse und Technologien

15Menschen und Prozesse

Teamorganisation: Rollen und Verantwortlichkeiten

Rollen für MDW, Data Fabric oder Data Lakehouse

Rollen für Data Mesh

Warum Projekte scheitern: Fallstricke und Prävention

Fallstrick: Führungskräfte denken, dass BI »einfach« ist

Fallstrick: Die falschen Technologien verwenden

Fallstrick: Zu viele Geschäftsanforderungen sammeln

Fallstrick: Zu wenige Geschäftsanforderungen sammeln

Fallstrick: Berichte präsentieren, ohne ihren Inhalt zuvor zu validieren

Fallstrick: Unerfahrene Berater beauftragen

Fallstrick: Eine Beratungsfirma beauftragen, die die Entwicklung an Offshore-Arbeiter outsourct

Fallstrick: Projektbesitz an Berater abgeben

Fallstrick: Den notwendigen Wissenstransfer zurück in die Organisation vernachlässigen

Fallstrick: Das Budget auf halbem Weg durch das Projekt kürzen

Fallstrick: Von einem Enddatum aus rückwärts arbeiten

Fallstrick: Das Data Warehouse so strukturieren, dass es die Quelldaten und nicht die Geschäftsbedürfnisse widerspiegelt

Fallstrick: Endbenutzern eine Lösung mit langen Reaktionszeiten oder anderen Performanceproblemen präsentieren

Fallstrick: Zu viel (oder zu wenig) Design Ihrer Datenarchitektur

Fallstrick: Mangelnde Kommunikation zwischen IT und Businessdomains

Tipps für den Erfolg

Knausern Sie nicht mit Ihren Investitionen

Benutzer und Benutzerinnen einbeziehen, ihnen Ergebnisse zeigen und sie begeistern

Mehrwert für neue Berichte und Dashboards

Die Endbenutzer bitten, einen Prototyp zu erstellen

Einen Projektchampion/Sponsor finden

Einen Projektplan erstellen, der auf 80% Effizienz abzielt

Zusammenfassung

16Technologien

Eine Plattform auswählen

Open-Source-Lösungen

On-Premises-Lösungen

Cloud-Provider-Lösungen

Cloud-Service-Modelle

Große Cloud-Provider

Multi-Cloud-Lösungen

Software-Frameworks

Hadoop

Databricks

Snowflake

Zusammenfassung

Index

Vorwort

Noch nie in der Geschichte des modernen, technologiegestützten Unternehmens hat sich die Datenlandschaft so schnell entwickelt. Da sich das Tempo des Wandels weiter beschleunigt, wird das Datenökosystem immer komplexer – insbesondere die Wertschöpfungsketten, die Zulieferer und Kunden mit dem Unternehmen verbinden. Daten scheinen überall zu fließen. Sie sind zu einem der strategischsten Vermögenswerte eines jeden Unternehmens geworden und bilden die Grundlage für die digitale Transformation, Automatisierung, künstliche Intelligenz, Innovation und vieles mehr.

Dieses zunehmende Tempo des Wandels macht es umso wichtiger, die Datenarchitektur Ihres Unternehmens zu optimieren, um kontinuierliche Anpassungsfähigkeit, Interoperabilität und Wartungsfreundlichkeit zu gewährleisten. In diesem Buch stellt James Serra eine Reihe klarer Entscheidungen für den Datenarchitekten vor, unabhängig davon, ob Sie ein belastbares Design erstellen oder einfach die technische Schuld reduzieren möchten.

Scheinbar jeder Wissensarbeiter kennt eine Geschichte eines Meetings mit Dateningenieuren und -architekten, das sich wie ein Dilbert-Cartoon anfühlte, in dem niemand die gleiche Sprache zu sprechen schien und die Entscheidungen zu kompliziert und undurchsichtig waren. Indem er Konzepte definiert, Bedenken ausräumt, Mythen aufklärt und Workarounds für Fallstricke vorschlägt, vermittelt James den Leserinnen und Lesern brauchbare Kenntnisse über Datenarchitekturen und das nötige Vertrauen, um fundierte Entscheidungen zu treffen. Als Führungskraft bin ich sehr zufrieden damit, wie gut die Inhalte des Buchs dazu beitragen, die Ausrichtung meines Datenteams zu stärken, indem sie ihnen ein gemeinsames Vokabular und Referenzen an die Hand geben.

Als ich James vor etwa 15 Jahren kennenlernte, überlegte er, sein Fachwissen über die Datenbankadministration hinaus auf Business Intelligence und Analytik auszuweiten. Sein unstillbares Verlangen, Neues zu lernen und das Gelernte mit anderen zu teilen, um dem Allgemeinwohl zu dienen, hat mich stark beeindruckt. Das treibt ihn auch heute noch an. Die unzähligen Blogposts, Präsentationen und Vorträge, in denen er seine tiefgreifenden Erfahrungen weitergibt, kulminieren nun in dieser umfassenden Ressource. Dieses Buch wird uns allen, die wir mit Daten umgehen, auf dem Weg in eine ungewisse Zukunft von Nutzen sein.

Wenn Sie die Grundprinzipien der Datenarchitektur verstehen, können Sie auf den Wellen des Wandels reiten, wenn neue Datenplattformen, Technologieprovider und Innovationen auftauchen. Dankenswerterweise hat James eine grundlegende Ressource für uns alle geschaffen. Dieses Buch wird Ihnen helfen, das große Ganze zu sehen und eine strahlende Zukunft zu gestalten, in der Ihre Daten den Wettbewerbsvorteil schaffen, den Sie suchen.

– Sean McCall, Chief Data Officer, Oceaneering International

Houston, Dezember 2023

Einführung

Seit fast 40 Jahren bin ich in der Informationstechnologie (IT) unterwegs. Ich habe in Unternehmen aller Größenordnungen gearbeitet, war als Berater tätig und habe mein eigenes Unternehmen gegründet. Ich arbeite seit neun Jahren als Datenarchitekt bei Microsoft, und in den letzten 15 Jahren habe ich mich mit Data Warehousing beschäftigt. Ich habe schon Tausende Male vor Kunden und Gruppen über Daten gesprochen.

Im Laufe meiner Karriere habe ich viele Datenarchitektinnen und -architekten kommen und gehen sehen. Ich habe zu viele Unternehmen gesehen, die sich über den besten Ansatz streiten und am Ende die falsche Datenarchitektur aufbauen – ein Fehler, der sie Millionen von Dollar und Monate an Zeit kosten kann und sie weit hinter ihre Konkurrenten zurückwirft.

Hinzu kommt, dass Datenarchitekturen sehr komplex sind. Ich habe aus erster Hand erfahren, dass den meisten Menschen die damit verbundenen Konzepte nicht klar sind, sofern sie sie überhaupt kennen. Jeder scheint mit Begriffen wie Data Mesh, Data Warehouse und Data Lakehouse um sich zu werfen – aber wenn Sie zehn Menschen fragen, was ein Data Mesh ist, werden Sie elf verschiedene Antworten erhalten.

Wo soll man da überhaupt anfangen? Handelt es sich dabei nur um Schlagwörter mit viel Hype, aber wenig Substanz, oder sind es praktikable Ansätze? In der Theorie mögen sie toll klingen, aber wie praktisch sind sie? Was sind die Vor- und Nachteile der einzelnen Architekturen?

Keine der in diesem Buch besprochenen Architekturen ist »falsch«. Alle haben ihre Berechtigung, aber nur in bestimmten Anwendungsfällen. Es gibt keine Architektur, die für jede Situation geeignet ist. Daher geht es in diesem Buch nicht darum, Sie davon zu überzeugen, eine bestimmte Architektur den anderen vorzuziehen. Stattdessen erhalten Sie ehrliche Meinungen zu den Vor- und Nachteilen der einzelnen Architekturen. Bei allen gibt es Kompromisse, und es ist wichtig, diese zu verstehen und sich nicht einfach für eine Architektur zu entscheiden, die mehr als die anderen angepriesen wird. Außerdem kann man von jeder Architektur viel lernen, auch wenn man sie nicht nutzt. Wenn Sie zum Beispiel verstehen, wie ein Data Mesh funktioniert, werden Sie über Datenbesitz nachdenken, ein Konzept, das sich auf jede Architektur anwenden lässt.

Dieses Buch bietet eine grundlegende Einführung in gängige Datenarchitekturkonzepte. Es gibt so viele Konzepte, dass es einschüchternd sein kann, sich für eines zu entscheiden und herauszufinden, wie es zu implementieren ist. Ich möchte Ihnen helfen, all diese Konzepte und Architekturen auf einem hohen Niveau zu verstehen, damit Sie ein Gefühl für die Optionen bekommen und erkennen können, welche für Ihre Situation am besten geeignet ist. Das Ziel des Buchs ist es, Ihnen zu ermöglichen, auf intelligente Weise über Datenkonzepte und -architekturen zu sprechen und sich dann mit denjenigen zu befassen, die für die Lösung, die Sie aufbauen, relevant sind.

Es gibt keine Standarddefinitionen von Datenkonzepten und Architekturen. Andernfalls wäre dieses Buch überflüssig. Meine Hoffnung ist, Standarddefinitionen zur Verfügung zu stellen, damit alle auf Augenhöhe miteinander diskutieren können. Allerdings mache ich mir keine Illusionen darüber, dass meine Definitionen allgemein akzeptiert werden, aber ich möchte uns allen einen Ausgangspunkt für Gespräche darüber geben, wie wir diese Definitionen anpassen können.

Ich habe dieses Buch für jeden geschrieben, der daran interessiert ist, Nutzen aus Daten zu ziehen, egal ob Sie Datenbankentwickler oder -administratorin, Datenarchitekt, CTO oder CIO oder sogar jemand in einer Rolle außerhalb der IT sind. Sie können am Anfang Ihrer Karriere stehen oder ein erfahrener Veteran sein. Die einzigen Fähigkeiten, die Sie benötigen, sind ein wenig Vertrautheit mit Daten aus Ihrer Arbeit und ein gewisses Maß an Neugierde.

Für Leserinnen und Leser, die weniger Erfahrung mit diesen Themen haben, biete ich einen Überblick über Big Data (Kapitel 1) und Datenarchitekturen (Kapitel 2) sowie über grundlegende Datenkonzepte (Teil II). Wenn Sie schon eine Weile mit Daten zu tun haben, aber neue Architekturen verstehen müssen, könnte Ihnen Teil III von großem Nutzen sein, in dem ich auf die Details bestimmter Datenarchitekturen eingehe und einige der Grundlagen wiederhole. Diesen Teil können Sie auch überfliegen – überspringen Sie einfach die Abschnitte mit dem Material, das Sie bereits gut kennen. Der Schwerpunkt liegt zwar auf Big Data, doch gelten die Konzepte und Architekturen auch für »kleine« Daten.

Dies ist ein anbieterneutrales Buch. Die Architekturen und Konzepte, die Sie hier lernen, sollten Sie also auch bei jedem Cloud-Provider anwenden können. An dieser Stelle möchte ich erwähnen, dass ich bei Microsoft beschäftigt bin. Die hier geäußerten Meinungen sind jedoch allein meine und spiegeln nicht die Ansichten meines Arbeitgebers wider.

Ich habe dieses Buch geschrieben, weil ich eine angeborene Neugier habe, die mich dazu antreibt, Dingen auf den Grund zu gehen und sie dann so weiterzugeben, dass sie jeder verstehen kann. Dieses Buch ist die Summe meines bisherigen Schaffens. Ich hoffe, es wird ein wertvolles Arbeitsmittel für Sie.

Konventionen in diesem Buch

In diesem Buch werden die folgende typografische Konventionen verwendet:

Kursiv

Kennzeichnet neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Schreibmaschinenschrift

Wird in Programmlistings verwendet und im Fließtext für Programmelemente wie zum Beispiel Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

Dieses Element kennzeichnet einen Tipp oder Vorschlag.

Danksagungen

Dieses Buch wäre ohne die unermüdliche Unterstützung und Geduld meiner Frau Mary nicht möglich gewesen. Ihre Ermutigung war in den langen Nächten, die ich mit dem Schreiben verbracht habe, ein entscheidender Antrieb, selbst wenn das bedeutet hat, dass ich auf Kartenspiele mit Familie und Freunden verzichten musste. Ihre Anwesenheit war eine ständige Quelle des Trostes und der Motivation.

Meine Reise wurde durch die Unterstützung meiner Familie bereichert: meine Eltern Jim und Lorraine, meine Schwestern Denise, Michele und Nicole und meine inzwischen erwachsenen Kinder Lauren, RaeAnn und James, die eine Quelle der Inspiration waren, obwohl sie keine Ahnung hatten, worum es in dem Buch geht!

Ein herzliches Dankeschön geht an meine Mentoren und Kollegen aus meinen Jahren bei Microsoft. Menschen wie Steve Busby, Eduardo Kassner und Martin Lee haben meine Karriere geprägt und mir Ratschläge mit auf den Weg gegeben, die an vielen Stellen in dieses Buch eingeflossen sind.

Mein Dank gilt auch denjenigen, die mir ihr kritisches Auge und konstruktives Feedback geschenkt haben, insbesondere Piethein Strengholt, Barry Devlin, Bill Inmon und Mike Shelton. Ihre Einblicke waren unschätzbar.

Besonders dankbar bin ich Sean McCall, der mich vor vielen Jahren in die Welt des Data Warehousing eingeführt hat, aber auch ein treuer Freund ist und sich bereit erklärt hat, das Vorwort zu diesem Buch zu schreiben.

Schließlich möchte ich all den großartigen Menschen bei O’Reilly danken, die dieses Buch möglich gemacht haben: Sarah Grey, deren großartiges Lektorat und deren Vorschläge dieses Buch so viel besser gemacht haben, als wenn ich nur auf mich selbst gestellt gewesen wäre, Aaron Black, der mir geholfen hat, den Abstract zum Buch zu erstellen und ihn bestätigen zu lassen, Paula Fleming für ihr außergewöhnliches Copyediting, Katie Tozer, die die Herstellung des Buchs geleitet hat, Kristen Brown, die dafür gesorgt hat, dass alles reibungslos gelaufen ist, und Suzanne Huston für ihre wunderbare Vermarktung des Buchs.

Ich möchte Ihnen, den Leserinnen und Lesern, meine tiefe Dankbarkeit aussprechen, denn Ihr Interesse und Ihr Engagement für dieses Werk machen die unzähligen Stunden, die ich mit dem Schreiben zugebracht habe, nicht nur lohnenswert, sondern zutiefst erfüllend.

Während ich dieses Kapitel meines Lebens abschließe und mich auf die neuen Horizonte freue, die vor mir liegen, bin ich zutiefst dankbar für die Reise, auf die mich dieses Buch geführt hat, und für die unglaublichen Menschen, die daran teilgenommen haben.

TEIL I

Grundlagen

In Teil I dieses Buchs geht es um die Grundlagen für die Entschlüsselung von Datenarchitekturen. Zunächst beschreibt Kapitel 1, was man unter Big Data versteht, während Kapitel 2 einen Überblick über die Arten von Datenarchitekturen und deren Entwicklung gibt. Kapitel 3 zeigt, wie Sie eine Architektur-Design-Sitzung (Architecture Design Session) durchführen können, um die beste Datenarchitektur für Ihr Projekt zu bestimmen.

Dieser Teil des Buchs bietet Ihnen einen guten Ausgangspunkt, um den Wert von Big Data und die Geschichte der Architekturen, die diese Daten erfasst haben, zu verstehen. In den späteren Kapiteln befassen wir uns dann ausgiebiger mit den Details.

KAPITEL 1

Big Data

Die Anzahl der Firmen, die Datenarchitekturen erstellen, ist in den 2020er-Jahren sprunghaft gestiegen. Es ist unwahrscheinlich, dass sich dieses Wachstum in absehbarer Zeit verlangsamt, vor allem weil mehr Daten als je zuvor zur Verfügung stehen: angefangen bei sozialen Medien über IoT-Geräte (Internet der Dinge) bis hin zu selbst entwickelten Anwendungen und Software von Drittanbietern, um nur einige Quellen zu nennen. Laut einer BCG-Studie aus dem Jahr 2023 (https://oreil.ly/hpOPt) »hat sich der Umfang der generierten Daten von 2019 bis 2021 auf etwa 84 ZB ungefähr verdoppelt, wobei zu erwarten ist, dass es mit dieser Wachstumsrate weitergeht«. Die Forscher »schätzen, dass der Umfang der generierten Daten mit einer jährlichen Wachstumsrate (Compound Annual Growth Rate, CAGR) bei 21% von 2021 bis 2024 auf 149 ZB ansteigen wird. Die Unternehmen wissen, dass sie Millionen Dollar sparen und den Umsatz erhöhen können, indem sie diese Daten sammeln und anhand der Vergangenheits- und Gegenwartsdaten Vorhersagen über die Zukunft treffen – doch um das zu tun, brauchen sie eine Möglichkeit, um alle diese Daten zu speichern.

Überall in der Geschäftswelt wird versucht, so schnell wie möglich Datenarchitekturen aufzubauen. Diese Architekturen müssen auch in der Lage sein, zukünftig zu erfassende Daten – unabhängig von ihrer Größe, Geschwindigkeit oder Art – zu verarbeiten und ihre Genauigkeit zu gewährleisten. Und diejenigen von uns, die mit Datenarchitekturen arbeiten, müssen genau wissen, wie sie funktionieren und welche Möglichkeiten sie bieten. Genau hier setzt dieses Buch an. Ich habe aus erster Hand erfahren, was passiert, wenn man die Konzepte der Datenarchitektur nicht richtig versteht. Ein mir bekanntes Unternehmen hat in zwei Jahren eine Datenarchitektur für 100 Millionen Dollar aufgebaut, nur um dann festzustellen, dass die Architektur die falsche Technologie verwendet hat, zu schwierig in der Anwendung und nicht flexibel genug war, um bestimmte Datentypen zu verarbeiten. Sie musste verworfen und von Grund auf neu aufgebaut werden. Lassen Sie nicht zu, dass Ihnen das passiert! Es geht darum, die richtigen Informationen zur richtigen Zeit und im richtigen Format an die richtigen Personen weiterzugeben. Dazu benötigen Sie eine Datenstruktur, mit der Sie die Daten erfassen, speichern, umwandeln und modellieren können (Big-Data-Verarbeitung), damit sie präzise und einfach genutzt werden können. Sie benötigen eine Architektur, die es jedem Endbenutzer, selbst einem mit sehr geringem technischem Wissen, ermöglicht, die Daten zu analysieren und Berichte und Dashboards zu erstellen, anstatt sich darauf zu verlassen, dass IT-Mitarbeiter mit profundem technischem Wissen dies für sie tun.

Kapitel 1 führt in Big Data und einige seiner grundlegenden Ideen ein. Anschließend erörtere ich, wie Unternehmen ihre Daten nutzen, wobei der Schwerpunkt auf Business Intelligence liegt, und wie diese Nutzung zunimmt, wenn die Datenstruktur eines Unternehmens reift.

Was ist Big Data, und wie kann Big Data Ihnen helfen?

Auch wenn Big Data das Adjektiv big (groß) enthält, geht es nicht nur um die Größe der Daten. Vor allem geht es um alle Daten, egal ob groß oder klein, die in Ihrem Unternehmen existieren, sowie alle Daten außerhalb Ihres Unternehmens, die für Sie hilfreich sein könnten. Die Daten können in jedem Format vorliegen und mit beliebiger Regelmäßigkeit gesammelt werden. Um Big Data zu definieren, betrachtet man sie am besten als die Daten in ihrer Gesamtheit, unabhängig von ihrer Größe (Volume), Geschwindigkeit (Velocity) oder Vielfalt (Variety). Neben diesen Kriterien gibt es drei weitere Faktoren, mit denen Sie Daten beschreiben können: Wahrhaftigkeit (Veracity), Variabilität (Variability) und Wert (Value). Nach den Anfangsbuchstaben der englischen Bezeichnungen sind sie allgemein als »die sechs Vs« von Big Data bekannt, wie Abbildung 1-1 zeigt.

Sehen wir uns jedes einzelne V genauer an:

Volume (Datenvolumen)

Das Datenvolumen ist die schiere Menge der erzeugten und gespeicherten Daten. Das Volumen kann von Terabyte bis Petabyte reichen, und die Daten können aus einer Vielzahl von Quellen stammen, darunter soziale Medien, E-Commerce-Transaktionen, wissenschaftliche Experimente, Sensordaten von IoT-Geräten und viele mehr. Beispielsweise können die Daten von einem Auftragseingabesystem pro Tag mehrere Terabyte ausmachen, während IoT-Geräte Millionen von Ereignissen pro Minute streamen und Hunderte von Terabytes an Daten pro Tag erzeugen können.

Abbildung 1-1:Die sechs Vs von Big Data (Quelle: The Cloud Data Lake von Rukmani Gopalan [O’Reilly, 2023])

Variety (Datenvielfalt)

Die Datenvielfalt bezieht sich auf das breite Spektrum an Datenquellen und -formaten. Diese lassen sich weiter unterteilen in strukturierte Daten (aus relationalen Datenbanken), teilstrukturierte Daten (wie zum Beispiel Protokolle und Daten in den Formaten CSV, XML und JSON), unstrukturierte Daten (wie E-Mails, Dokumente und PDFs) und binäre Daten (Bilder, Audio, Video). Zum Beispiel wären Daten aus einem Auftragseingabesystem strukturierte Daten, da sie aus einer relationalen Datenbank stammen, während Daten von einem IoT-Gerät wahrscheinlich im JSON-Format vorliegen.

Velocity (Geschwindigkeit)

Die Geschwindigkeit gibt an, wie schnell Daten erzeugt und verarbeitet werden. Wenn Daten eher selten erfasst werden, spricht man oft von Stapelverarbeitung (Batch Processing). Zum Beispiel könnten die tagsüber eingegangenen Bestellungen jede Nacht zusammengefasst und verarbeitet werden. Es ist aber auch üblich, dass Daten sehr häufig oder sogar in Echtzeit erfasst werden, insbesondere wenn sie mit hoher Geschwindigkeit entstehen, wie es beispielsweise bei Daten von sozialen Medien, IoT-Geräten und mobilen Anwendungen der Fall ist.

Veracity (Wahrhaftigkeit)

Mit Wahrhaftigkeit sind Genauigkeit und Zuverlässigkeit der Daten gemeint. Die Quellen für Big Data könnten unterschiedlicher nicht sein. Unzuverlässige oder unvollständige Daten beeinträchtigen gegebenenfalls die Qualität der Daten. Wenn die Daten zum Beispiel von einem IoT-Gerät kommen, etwa von einer Sicherheitskamera vor Ihrem Haus, die auf die Einfahrt gerichtet ist, und die Ihnen eine Textnachricht sendet, wenn eine Person erkannt wird, ist es durchaus möglich, dass Umgebungseinflüsse wie zum Beispiel das Wetter dazu führen, dass eine Person statt einer Katze erkannt wird, und das Überwachungsgerät somit verfälschte Daten sendet. Daher ist es unumgänglich, die Daten zu validieren, sobald sie empfangen werden.

Variability (Variabilität)

Variabilität meint die Konsistenz (oder Inkonsistenz) von Daten hinsichtlich ihres Formats, ihrer Qualität und ihrer Bedeutung. Strukturierte, teilstrukturierte und unstrukturierte Datenformate zu verarbeiten, verlangt verschiedene Tools und Techniken. So können beispielsweise Art, Häufigkeit und Qualität der Sensordaten von IoT-Geräten sehr unterschiedlich sein. Temperatur- und Luftfeuchtigkeitssensoren können Datenpunkte in regelmäßigen Intervallen erzeugen, während Bewegungssensoren möglicherweise nur dann Daten liefern, wenn sie eine Bewegung erkennen.

Value (Wert)

Das wichtigste V steht für Value, d.h. den Wert, der sich auf die Nützlichkeit und Relevanz der Daten bezieht. Unternehmen nutzen Big Data, um Erkenntnisse zu gewinnen und Entscheidungen zu treffen, die zu einem geschäftlichen Nutzen führen können, zum Beispiel zu höherer Effizienz, zu Kosteneinsparungen oder zu neuen Einnahmequellen. So können Unternehmen das Verhalten, die Vorlieben und die Bedürfnisse ihrer Kunden besser verstehen, indem sie die Kundendaten analysieren. Anhand dieser Informationen sind sie in der Lage, zielgerichtete Marketingkampagnen zu entwickeln, die Kundenzufriedenheit zu verbessern und den Umsatz zu steigern.

Mithilfe von Big Data können Unternehmen Erkenntnisse gewinnen, die ihnen helfen, bessere Geschäftsentscheidungen zu treffen. Die prädiktive Analyse ist eine Art der Datenanalyse, die statistische Algorithmen und Machine Learning einbezieht, um historische Daten zu analysieren und Vorhersagen über zukünftige Ereignisse und Trends zu treffen. Dadurch können Unternehmen proaktiv und nicht nur reaktiv handeln.

Viele Unternehmen bezeichnen Daten als »das neue Öl«, denn sie sind in der heutigen digitalen Wirtschaft zu einer unglaublich wertvollen Ressource geworden, ähnlich wie es das Öl in der industriellen Wirtschaft war. In vielerlei Hinsicht ähneln Daten Öl, denn sie …

sind ein Rohstoff, der extrahiert, verfeinert und verarbeitet werden muss, um nützlich zu sein. Im Fall der Daten bedeutet dies, dass sie gesammelt, gespeichert und analysiert werden müssen, um Erkenntnisse zu gewinnen, die für Geschäftsentscheidungen von Bedeutung sind.

sind unglaublich wertvoll. Unternehmen, die große Datenmengen sammeln und analysieren, können sie nutzen, um ihre Produkte und Dienste aufzuwerten, bessere Geschäftsentscheidungen zu treffen und sich einen Wettbewerbsvorteil zu verschaffen.

können auf vielfältige Art und Weise genutzt werden. Wenn Sie beispielsweise Daten heranziehen, um Algorithmen für maschinelles Lernen zu trainieren, können Sie diese Algorithmen dann einsetzen, um Aufgaben zu automatisieren, Muster zu erkennen und Prognosen zu treffen.

sind eine mächtige Ressource mit einer Wirkung, die die Gesellschaft verändert. Die weitverbreitete Nutzung von Öl hat das Wachstum von Industrien vorangetrieben und neue Technologien ermöglicht, während Daten zu Fortschritten in Branchen wie künstliche Intelligenz, Machine Learning und prädiktive Analytik geführt haben.

können dank aller Vorhersagefaktoren eine Quelle von Macht und Einfluss sein.

Zum Beispiel können Sie mithilfe von Big Data Berichte und Dashboards erstellen, die Ihnen zeigen, wo die Umsätze zurückbleiben, und im Nachhinein Maßnahmen zur Verbesserungen dieser Umsätze ergreifen. Zudem lässt sich mithilfe von Machine Learning vorhersagen, wo der Umsatz in Zukunft zurückgehen wird. So kann man proaktive Schritte einleiten, um diesen Rückgang zu verhindern. Hierbei handelt es sich um die sogenannte Business Intelligence (BI): den Prozess, Daten zu sammeln, zu analysieren und zu verwenden, um Unternehmen zu helfen, fundierte Entscheidungen zu treffen.

Wie Abbildung 1-2 zeigt, kann man Daten aus neuen Quellen generieren, wie zum Beispiel IoT-Geräten, Weblogs und sozialen Medien, sowie aus älteren Quellen, etwa Branchen- oder Unternehmensressourcenplanung (Enterprise Resource Planning, ERP) und Anwendungen für Kundenbeziehungen (Customer Relationship Management, CRM). Diese Daten können in mehreren Formaten vorliegen, beispielsweise als CSV-Dateien, JSON-Dateien und Parquet-Dateien. Übertragen werden sie in Stapeln, beispielsweise einmal pro Stunde, oder mehrmals pro Sekunde in Streams (genannt Echtzeit-Streaming).

Abbildung 1-2:Verarbeitung von Big Data (Quelle: The Cloud Data Lake by Rukmani Gopalan [O’Reilly, 2023])

Unternehmen müssen wissen, wo sie sich im Vergleich zu anderen Unternehmen auf ihrem Weg zur Datennutzung befinden. Dies wird als Data Maturity (Datenreife) bezeichnet. Der nächste Abschnitt erläutert die Stufen der Datenreife, damit Sie verstehen können, wo Ihr Unternehmen steht.

Data Maturity

Vielleicht ist Ihnen in der IT-Branche schon einmal der Begriff digitale Transformation (Digital Transformation) begegnet. Er bezieht sich darauf, wie Unternehmen Technologien in ihr gesamtes Unternehmen einbinden, um die Art und Weise, wie sie Daten nutzen und wie sie einen Mehrwert für den Kunden kreieren, grundlegend zu verändern. Prinzipiell geht es darum, von herkömmlichen manuellen oder papierbasierten Prozessen auf digitale Prozesse umzustellen und dabei die Technologie auszunutzen, Effizienz, Produktivität und Innovation zu verbessern. Ein großer Teil dieser Transformation nutzt in der Regel Daten, um das Geschäft eines Unternehmens zu verbessern. Hier wird gegebenenfalls ein 360-Grad-Kundenprofil (https://oreil.ly/rSF6P) erstellt, um die Kundenerfahrung zu verbessern oder mithilfe von Machine Learning die Geschwindigkeit und Genauigkeit von Fertigungsstraßen zu erhöhen.

Diese digitale Transformation lässt sich in vier Stufen unterteilen, die sogenannten Reifegrade einer Organisation im Umgang mit Unternehmensdaten, wie sie Abbildung 1-3 zeigt. Obwohl dieser Begriff in der IT-Branche sehr verbreitet ist, habe ich meine eigene Vorstellung davon, wie diese Stufen aussehen. Sie beschreiben den Entwicklungs- und Reifegrad, den ein Unternehmen bei der Verwaltung, Nutzung und Wertschöpfung seiner Daten erreicht hat. Anhand dieses Modells lassen sich die Datenverwaltungsfähigkeiten eines Unternehmens und die Bereitschaft für erweiterte Analysen, künstliche Intelligenz und andere datengesteuerte Initiativen beurteilen. Jede Stufe verkörpert einen Fortschritt bei der Nutzung von Daten für den Unternehmenswert und die Entscheidungsfindung. Der Rest dieses Abschnitts beschreibt jede Stufe im Einzelnen.

Abbildung 1-3:Reifegrade einer Organisation im Umgang mit Unternehmensdaten

Stufe 1: Reaktiv

In der ersten Phase liegen die Daten in einem Unternehmen an vielen Plätzen verstreut vor, wahrscheinlich in einigen Excel-Tabellen und/oder Desktop-Datenbanken auf mehreren verschiedenen Dateisystemen, wobei sie überallhin per E-Mail versendet werden. Datenarchitekten nennen dies den Spreadmart (kurz für »Spreadsheet Data Mart«): eine formlose, dezentralisierte Datensammlung, die man häufig in einer Organisation antrifft, die sich auf Kalkulationstabellen stützt, um Daten zu speichern, zu verwalten und zu analysieren. Einzelpersonen oder Teams erstellen und pflegen Spreadmarts in der Regel unabhängig vom zentralisierten Datenverwaltungssystem oder vom offiziellen Data Warehouse des Unternehmens. Bei Spreadmarts müssen Sie allerdings mit inkonsistenten Daten, fehlender Koordinierung, beschränkter Skalierbarkeit und Ineffizienz rechnen (da sie oftmals zu einem erheblichen Mehraufwand führen).

Stufe 2: Informativ

Unternehmen erreichen den zweiten Reifegrad, wenn sie ihre Daten zentralisieren, was Analysen und das Berichtswesen erheblich erleichtert. Die Stufen 1 und 2 dienen der Berichterstattung im herkömmlichen Sinne oder dem Erkennen von Trends und Mustern aus der Vergangenheit, weshalb sie in Abbildung 1-3 auch als Rückspiegel betitelt werden. In diesen Stufen reagieren Sie auf etwas, das bereits geschehen ist.

In Stufe 2 ist die Lösung, die zur Erfassung der Daten entwickelt wurde, in der Regel nicht sehr skalierbar. Im Allgemeinen sind Umfang und Art der Daten, die sie verarbeiten kann, begrenzt, und nur selten (zum Beispiel jede Nacht) können Daten eingelesen werden. Die meisten Unternehmen befinden sich auf Stufe 2, insbesondere wenn ihre Infrastruktur lokal zugänglich ist.1

Stufe 3: Prädiktiv

In Stufe 3 sind die Unternehmen in die Cloud umgezogen und haben ein System aufgebaut, das größere Datenmengen, unterschiedliche Arten von Daten sowie Daten, die häufiger (stündlich oder per Stream) eingelesen werden, verarbeiten kann. Außerdem haben sie ihre Entscheidungsfindung verbessert, indem sie Machine Learning (fortgeschrittene Analytik) einbeziehen, um Entscheidungen in Echtzeit zu treffen. Wenn sich eine Benutzerin beispielsweise in einem Onlinebuchladen befindet, kann das System auf der Kassenseite zusätzliche Bücher empfehlen, die auf früheren Käufen der Benutzerin basieren.

Stufe 4: Transformativ

Auf Stufe 4 hat das Unternehmen schließlich eine Lösung entwickelt, die mit allen Daten umgehen kann, unabhängig von ihrer Größe, Geschwindigkeit oder Art. Neue Daten lassen sich mit einer kürzeren Vorlaufzeit einbinden, da die Architektur sie verarbeiten kann und über entsprechende Infrastrukturkapazität verfügt, um sie zu unterstützen. Mit dieser Lösung können auch technisch nicht versierte Benutzer problemlos Berichte und Dashboards mit den Tools ihrer Wahl erstellen.

Die Stufen 3 und 4 stehen im Mittelpunkt dieses Buchs. Insbesondere wenn Benutzer ihre eigenen Berichte erstellen, bezeichnet man diese Aktivität als Self-Service Business Intelligence, die das Thema des folgenden Abschnitts ist.

Self-Service Business Intelligence

Wenn früher jemand in einer Organisation einen Bericht oder ein Dashboard benötigte, musste er viele Jahre lang alle geforderten Daten zusammenstellen (die benötigten Quelldaten sowie eine Beschreibung, wie der Bericht oder das Dashboard aussehen sollte), ein IT-Anforderungsformular ausfüllen und warten. Die IT-Abteilung erstellte dann den Bericht, d.h., sie extrahierte die Daten, lud sie in das Data Warehouse, entwickelte ein Datenmodell und erstellte schließlich den Bericht oder das Dashboard. Der Endbenutzer prüfte den Bericht und gab ihn entweder frei oder forderte Änderungen an. Oftmals resultierte dies in einer langen Warteschlange von IT-Anfragen, sodass die IT-Abteilung zu einem regelrechten Flaschenhals wurde. Es dauerte Tage, Wochen oder sogar Monate, bis der Endbenutzer die Daten in einen Wert überführen konnte. Man nennt diesen Prozess heute »herkömmliche Business Intelligence«, denn in den letzten Jahren hat sich etwas Besseres entwickelt: Self-Service Business Intelligence oder Self-Service BI.

Das Ziel jeder Datenarchitekturlösung, die Sie entwickeln, sollte sein, dass jeder Endbenutzer unabhängig von seinen oder ihren technischen Fähigkeiten die Daten schnell und einfach abfragen und damit Berichte und Dashboards erstellen kann. Für keine dieser Aufgaben sollten die Nutzer die IT-Abteilung einschalten müssen – vielmehr sollten sie in der Lage sein, alles in eigener Regie abzuwickeln.

Dieses Ziel verlangt etwas mehr Aufwand bei der Vorbereitung: Die IT muss sich mit allen Endbenutzern in Verbindung setzen, um herauszufinden, welche Daten sie benötigen, und dann die Datenarchitektur unter Berücksichtigung ihrer Bedürfnisse aufbauen. Allerdings wird dieser Mehraufwand durch die Zeitersparnis beim Erstellen der Berichte allemal wettgemacht. Außerdem entfallen bei diesem Ansatz die Warteschlange und das Hin und Her mit der IT-Abteilung, deren Mitarbeitende in der Regel wenig Ahnung von den Daten haben. Stattdessen greift der Endbenutzer, der die Daten am besten kennt, direkt auf die Daten zu, bereitet sie auf, entwickelt das Datenmodell, erstellt die Berichte und prüft, ob die Berichte korrekt sind. Dieser Arbeitsablauf ist viel produktiver.

Die Schaffung dieser einfach zu nutzenden Datenlösung führt zu Self-Service BI. Ein Bericht sollte leicht zu erstellen sein, indem man Felder in einen Arbeitsbereich zieht und dort platziert. Endbenutzer müssen nicht wissen, wie man Daten aus verschiedenen Tabellen zusammenführt, oder sich Sorgen machen, dass ein Bericht zu langsam läuft. Wenn Sie eine Datenlösung erstellen, sollten Sie sich immer fragen: Wie einfach wird es für die Mitarbeitenden sein, ihre eigenen Berichte zu erstellen?

Zusammenfassung

In diesem Kapitel haben Sie erfahren, was Big Data ist und wie Big Data Ihnen und Ihrem Unternehmen helfen kann, bessere Entscheidungen zu treffen, insbesondere in Kombination mit Machine Learning. Sie haben gesehen, wie Big Data mithilfe der sechs Vs beschrieben werden kann, und Sie haben gelernt, was Datenreife bedeutet und wie man ihre Stufen identifiziert. Schließlich haben Sie den Unterschied kennengelernt zwischen herkömmlicher BI und Self-Service BI, bei der das Ziel darin besteht, dass jeder die Daten verwenden kann, um schnell und einfach Berichte zu erstellen und Erkenntnisse zu gewinnen.

Lassen Sie mich Ihnen nun einen Überblick darüber geben, was Sie in den folgenden Kapiteln erwartet. Kapitel 2 geht darauf ein, was eine Datenarchitektur ist, und vermittelt im Überblick, wie sich die Arten von Datenarchitekturen im Laufe der Jahre verändert haben. Kapitel 3 zeigt, wie Sie eine Architektur-Design-Sitzung durchführen können, um die bestmögliche Datenarchitektur zu ermitteln.

Teil II, »Allgemeine Datenarchitekturkonzepte«, geht näher auf die verschiedenen Architekturen ein. Kapitel 4 beschreibt, was ein Data Warehouse ist, was es nicht ist und warum Sie ein solches nutzen sollten. Ich erörtere den Top-down-Ansatz, stelle die Frage, ob das relationale Data Warehouse tot ist, und gehe auf die Möglichkeiten ein, ein Data Warehouse zu füllen. Kapitel 5 beschreibt, was ein Data Lake ist und weshalb Sie einen solchen verwenden sollten. Außerdem wird der Bottom-up-Ansatz erläutert. Dabei gehe ich auf das Data-Lake-Design ein und zeige, wann mehrere Data Lakes verwendet werden sollten.

Kapitel 6 befasst sich mit allgemeinen Datenarchitekturkonzepten, die sich auf Datenspeicher beziehen. Das betrifft unter anderem Data Marts, operative Datenspeicher, das Stammdatenmanagement und die Datenvirtualisierung. Thema von Kapitel 7 sind allgemeine Datenarchitekturkonzepte, die sich auf den Entwurf beziehen. Hierzu gehören OLTP vs. OLAP, operative vs. analytische Daten, SMP vs. MPP, Lambda-Architektur, Kappa-Architektur und Polyglot-Persistenz. Kapitel 8 ist der Datenmodellierung gewidmet, einschließlich relationaler und dimensionaler Modellierung, der Komball- vs. Inmon-Debatte, dem allgemeinen Datenmodell und Datentresoren. Und in Kapitel 9 erfahren Sie mehr über Datenerfassung in den Abschnitten zu ELT vs. ETL, Reverse-ELT, Batch- vs. Echtzeitverarbeitung und Data Governance.

Teil III konzentriert sich auf spezifische Datenarchitekturen. Kapitel 10 beschreibt das Modern Data Warehouse und die fünf Phasen seines Aufbaus. Kapitel 11 behandelt die Data-Fabric-Architektur und ihre Anwendungsfälle. Kapitel 12 liefert Ihnen einen Überblick über die Data-Lakehouse-Architektur und die Kompromisse, die man eingehen muss, wenn man auf ein relationales Data Warehouse verzichtet.

In Kapitel 13 und 14 geht es um Data-Mesh-Architekturen – darüber gibt es viel zu sagen! Kapitel 13 konzentriert sich auf den dezentralisierten Ansatz und die vier Prinzipien eines Data Mesh. Außerdem beschreibt es, was Datendomains und Datenprodukte sind. Kapitel 14 befasst sich mit den Bedenken und Herausforderungen beim Aufbau eines Data Mesh und räumt mit einigen verbreiteten Mythen zum Thema Data Mesh auf. Es dürfte hilfreich sein, wenn Sie überprüfen, ob Sie bereit sind, ein Data Mesh einzuführen. Abschließend wird dargelegt, wie die Zukunft von Data Mesh aussehen könnte.

Kapitel 15 befasst sich mit der Frage, warum Projekte erfolgreich sind und warum sie scheitern. Zudem beschreibt es die Teamorganisation, die Sie für den Aufbau einer Datenarchitektur benötigen. Schließlich beschäftigt sich Kapitel 16 mit Open Source, den Vorteilen der Cloud, den wichtigsten Cloud-Anbietern, was Multi-Cloud bedeutet und welche Software-Frameworks es gibt.

Mein Plan ist es, Ihre Datenwelt zu revolutionieren. Sind Sie bereit?

KAPITEL 2

Arten von Datenarchitekturen

Es ist absolut wichtig, im Vorfeld Zeit in die Entwicklung und den Aufbau der richtigen Datenarchitektur zu investieren. Diese Erkenntnis habe ich schon früh in meiner Karriere auf die harte Tour erfahren. Ich war so begeistert, mit dem Aufbau meines Projekts zu beginnen, dass ich wichtige Entscheidungen über das Design der Architektur und die zu verwendenden Produkte übergangen habe. Drei Monate nach Projektbeginn wurde mir klar, dass die Architektur einige der erforderlichen Datenquellen nicht unterstützen würde. Wir mussten das Projekt von Grund auf neu angehen und eine andere Architektur und andere Produkte entwickeln, was eine Menge Geld und Zeit gekostet hat. Ohne die richtige Planung werden die Endanwenderinnen und Endanwender keinen Nutzen aus Ihrem Projekt ziehen, sie werden verärgert sein, über die verpassten Deadlines und Ihr Unternehmen läuft Gefahr, immer weiter hinter seine Konkurrenten zurückzufallen.

Wenn Sie ein Datenprojekt aufbauen, brauchen Sie einen gut durchdachten Plan, an dem Sie sich orientieren können. Hier kommt eine Datenarchitektur ins Spiel. Eine Datenarchitektur definiert einen High-Level-Architekturansatz und ein Konzept, das zu befolgen ist, umreißt eine Reihe von zu verwendenden Technologien und legt den Datenfluss fest, der für den Aufbau Ihres Datenprojekts maßgebend ist, um Big Data zu erfassen. Die Entscheidung für eine Datenarchitektur kann eine große Herausforderung sein, da es keine allgemeingültige Einheitsarchitektur gibt. Man kann nicht in einem Buch blättern, um eine Liste von Architekturansätzen mit den zu verwendenden Produkten zu finden. Es gibt kein einfaches Flussdiagramm mit Entscheidungsbäumen, das Sie zur perfekten Architektur führt. Ihr Architekturansatz und die von Ihnen verwendeten Technologien werden sich von Kunde zu Kunde und von Anwendungsfall zu Anwendungsfall stark unterscheiden.

Die wichtigsten Arten von High-Level-Architekturansätzen und -konzepten sind genau das, worum es in diesem Buch geht. Es ist keine vollständige Liste, aber sie vermittelt Ihnen zumindest einen Eindruck davon, worum es geht. Es ist zwar sinnvoll, Datenarchitekturen anhand ihrer Merkmale in verschiedene Typen zu unterteilen (was ich in diesem Buch auch tun werde), doch ist das nicht dasselbe wie, aus einer Reihe von vordefinierten Einheitsvorlagen, die für alles passen, auszuwählen. Jede Datenarchitektur ist einzigartig und erfordert einen maßgeschneiderten Ansatz, um die spezifischen Geschäftsanforderungen zu erfüllen.

Datenarchitektur bezieht sich auf den Gesamtentwurf und die Organisation von Daten innerhalb eines Informationssystems. Vordefinierte Vorlagen für Datenarchitekturen scheinen eine einfache Möglichkeit zu sein, ein neues System schnell einzurichten. Allerdings berücksichtigen Architekturvorlagen oftmals keine spezifischen Anforderungen und Beschränkungen des Systems, auf das sie angewendet werden, was zu Problemen mit Datenqualität, Systemleistung und Wartung führen kann. Hinzu kommt, dass sich die Anforderungen des Unternehmens und die Datensysteme im Laufe der Zeit wahrscheinlich ändern werden, was Updates und Anpassungen der Datenarchitektur erforderlich macht. Eine standardisierte Vorlage ist möglicherweise nicht flexibel genug, um diese Änderungen zu berücksichtigen. Die Folge können ineffiziente und eingeschränkte Systeme sein.

Dieses Kapitel gibt einen kurzen Überblick über die wichtigsten Arten von Datenarchitekturen, die in diesem Buch behandelt werden: relationales Data Warehouse, Data Lake, Modern Data Warehouse, Data Fabric, Data Lakehouse und Data Mesh. Jeder Art ist später im Buch ein eigenes Kapitel mit vielen Details gewidmet.

Entwicklung von Datenarchitekturen

Eine relationale Datenbank speichert Daten in einer festgelegten Struktur, wobei Beziehungen zwischen den Datenelementen durch Schlüssel definiert sind. Die Daten sind in der Regel in Tabellen organisiert, wobei jede Tabelle aus Zeilen und Spalten besteht. Jede Zeile repräsentiert eine einzelne Instanz von Daten, während jede Spalte ein bestimmtes Attribut der Daten darstellt.

Relationale Datenbanken sind für den Umgang mit strukturierten Daten konzipiert und bieten ein Framework, um Daten mithilfe einer standardisierten Sprache – der Structured Query Language (SQL) – erstellen, ändern und abfragen zu können. Das relationale Modell wurde erstmals 1970 von Edgar F. Codd vorgeschlagen1 und hat sich Mitte der 1970er-Jahre als vorherrschendes Modell für Datenbankverwaltungssysteme etabliert. Die meisten operativen Anwendungen müssen Daten dauerhaft speichern, und eine relationale Datenbank ist für die große Mehrheit das Mittel der Wahl.

In relationalen Datenbanken, bei denen Konsistenz und Datenintegrität von größter Bedeutung sind, werden die Daten in der Regel mit einem als Schema-on-Write genannten Ansatz organisiert. Hierbei bezieht sich Schema auf die formale Struktur, die die Organisation von – und die Beziehungen zwischen – Tabellen, Feldern, Datentypen und Einschränkungen definiert. Es dient als Vorlage für das Speichern und Verwalten von Daten und gewährleistet Konsistenz, Integrität und effiziente Organisation innerhalb der Datenbank. Relationale Datenbanken (und relationale Data Warehouses) erfordern ein wenig Vorarbeit, bevor sie tatsächlich Daten aufnehmen können. Zunächst müssen Sie die Datenbank mit ihren Tabellen, Feldern und dem Schema erstellen und dann den Code schreiben, um die Daten in die Datenbank zu übertragen. Bei einem Schema-on-Write-Ansatz wird das Datenschema definiert und durchgesetzt, wenn die Daten geschrieben oder in die Datenbank aufgenommen werden. Die Daten müssen dem vordefinierten Schema einschließlich dessen Datentypen, Einschränkungen und Beziehungen entsprechen, bevor sich Daten speichern lassen.

Im Gegensatz dazu wird bei einem Schema-on-Read-Ansatz das Schema angewendet, wenn die Daten gelesen oder wenn auf sie zugegriffen wird, und nicht beim Schreiben der Daten. Daten können in das Speichersystem eingetragen werden, ohne dass sie einem strengen Schema entsprechen. Die Struktur wird erst definiert, wenn die Daten abgefragt oder konsumiert werden. Dieser Ansatz ist flexibler bei der Speicherung unstrukturierter oder halb strukturierter Daten und kommt häufig zum Einsatz in Data Lakes, auf die dieses Kapitel später eingeht.

Im Großen und Ganzen bieten Datenarchitekturen ein Framework für die Organisation und Verwaltung von Daten auf eine Art und Weise, die den Bedürfnissen eines Unternehmens entspricht. Dabei wird unter anderem definiert, wie Daten erfasst, gespeichert, verarbeitet und abgerufen werden und wie sich die Datenqualität, die Sicherheit und der Datenschutz gewährleisten lassen. Auch wenn Datenarchitekturen viele verschiedene Formen annehmen können, gibt es einige gemeinsame Elemente:

Datenspeicherung

Alle Datenarchitekturen müssen festlegen, wie Daten gespeichert werden, einschließlich des physischen Speichermediums (zum Beispiel Festplattenlaufwerke oder Cloud-Speicher) und der Datenstrukturen, in denen die Daten organisiert sind.

Datenverarbeitung

Datenarchitekturen müssen definieren, wie Daten verarbeitet werden, einschließlich aller Transformationen oder Berechnungen an den Daten, bevor sie gespeichert oder analysiert werden.

Datenzugriff

Datenarchitekturen müssen Mechanismen für den Datenzugriff bereitstellen, einschließlich UI (User Interface, Benutzeroberfläche) und APIs (Application Program Interfaces, Anwendungsprogrammierschnittstellen), über die sich Daten abfragen und analysieren lassen.

Datensicherheit und Datenschutz

Datenarchitekturen müssen Mechanismen vorsehen, um Sicherheit und Datenschutz zu gewährleisten, beispielsweise Zugriffskontrollen, Verschlüsselung und Datenmaskierung.

Data Governance

Datenarchitekturen müssen Frameworks bereitstellen, um Daten zu verwalten, einschließlich Qualitätsstandards, Nachverfolgung der Herkunft und Aufbewahrungsrichtlinien.

Insgesamt besteht das Hauptziel einer Datenarchitektur darin, ein Unternehmen in die Lage zu versetzen, seine Datenbestände effektiv zu verwalten und zu nutzen, um seine Geschäftsziele und Entscheidungsprozesse zu unterstützen.

In Tabelle 2-1 sehen Sie einen umfangreichen High-Level-Vergleich der Eigenschaften von Datenarchitekturen, die ich in diesem Buch behandle. Er soll Ihnen als Orientierungshilfe dienen bei der Entscheidung, welche Architektur für Ihren Anwendungsfall am besten geeignet ist.

Tabelle 2-1:Vergleich von Datenarchitekturen

Relationales Data Warehouse

Relationale Datenbanken waren mehrere Jahrzehnte lang die Hauptstütze der Datenspeicherung. Das erste in der Produktion eingesetzte relationale Data Warehouse war das Teradata-System, das an der Stanford University von Dr. Jack E. Shemer entwickelt wurde, der 1979 die Teradata Corporation gründete. Wells Fargo Bank installierte das erste Teradata-System 1983 (https://oreil.ly/BMbzc) und nutzte es, um Finanzdaten zu analysieren.

Als die Unternehmen immer größere Datenmengen erzeugten, wurde es schwieriger, diese Daten ohne eine lange Verzögerung zu verarbeiten und zu analysieren. Die Einschränkungen relationaler Datenbanken führten zur Entwicklung relationaler Data Warehouses2, die in den späten 1980er-Jahren3