Handbuch Data Engineering: Robuste Datensysteme planen und erstellen

Von Joe Reis und Matt Housley

Der praxisnahe Überblick über die gesamte Data-Engineering-Landschaft

- Das Buch vermittelt grundlegende Konzepte des Data Engineering und beschreibt Best Practices für jede Phase des Datenlebenszyklus
- Mit dem Data-Engineering-Lifecycle bietet es einen konzeptionellen Rahmen, der langfristig Gültigkeit haben wird
- Es unterstützt Sie - jenseits des Hypes - bei der Auswahl der richtigen Datentechnologien, Architekturen und Prozesse und verfolgt den Cloud-First-AnsatzData Engineering hat sich in den letzten zehn Jahren rasant weiterentwickelt, so dass viele Softwareentwickler, Data Scientists und Analysten nach einer zusammenfassenden Darstellung grundlegender Techniken suchen. Dieses praxisorientierte Buch bietet einen umfassenden Überblick über das Data Engineering und gibt Ihnen mit dem Data-Engineering-Lifecycle ein Framework an die Hand, das die Evaluierung und Auswahl der besten Technologien für reale Geschäftsprobleme erleichtert. Sie erfahren, wie Sie Systeme so planen und entwickeln, dass sie den Anforderungen Ihres Unternehmens und Ihrer Kunden optimal gerecht werden.
Die Autoren Joe Reis und Matt Housley führen Sie durch den Data-Engineering-Lebenszyklus und zeigen Ihnen, wie Sie eine Vielzahl von Cloud-Technologien kombinieren können, um die Bedürfnisse von Datenkonsumenten zu erfüllen. Sie lernen, die Konzepte der Datengenerierung, -aufnahme, -orchestrierung, -transformation, -speicherung und -verwaltung anzuwenden, die in jeder Datenumgebung unabhängig von der verwendeten Technologie von entscheidender Bedeutung sind. Darüber hinaus erfahren Sie, wie Sie Data Governance und Sicherheit in den gesamten Datenlebenszyklus integrieren.

• Sprache: Deutsch
• Herausgeber: O'Reilly
• Erscheinungsdatum: 1. Aug. 2023
• ISBN: 9783960107699

Buchvorschau

TEIL I

Grundlagen und Bausteine

KAPITEL 1

Data Engineering – eine Beschreibung

Wenn Sie in der Daten- oder Softwarebranche tätig sind, haben Sie vielleicht schon bemerkt, dass Data Engineering aus seinem Schattendasein herausgetreten ist und sich nun die Bühne mit Data Science teilt. Data Engineering ist eines der angesagtesten Themen im Bereich Daten und Technologie, und das aus gutem Grund. Es bildet die Grundlage für Data Science und Analytik. In diesem Kapitel erfahren Sie, was Data Engineering ist, wie es entstanden ist, wie es sich entwickelt hat, welche Fähigkeiten Data Engineers benötigen und mit wem sie zusammenarbeiten.

Was ist Data Engineering?

Trotzder aktuellen Popularität von Data Engineering herrscht häufig Unklarheit darüber, was Data Engineering wirklich bedeutet und was Data Engineers tun. Data Engineering gibt es in der einen oder anderen Form, seit Unternehmen mit Daten arbeiten – z.B. bei prädiktiven Analysen, deskriptiven Auswertungen und Reports –, und trat mit dem Aufkommen von Data Science in den 2010ern in den Vordergrund. Für die Zwecke dieses Buchs ist es wichtig zu definieren, was die Begriffe Data Engineering und Data Engineer bedeuten.

Lassen Sie uns zunächst einen Blick darauf werfen, wie Data Engineering beschrieben wird, und einige Begriffe erarbeiten, die in diesem Buch verwendet werden. Für Data Engineering gibt es unzählige Definitionen. Anfang 2022 lieferte eine Google-Suche mit dem genauen Wortlaut »what is data engineering?« mehr als 91.000 eindeutige Ergebnisse. Bevor wir Ihnen unsere Definition vorstellen, hier ein paar Beispiele dafür, wie einige Experten auf dem Gebiet Data Engineering definieren:

Data Engineering bezeichnet eine Reihe von Vorgängen, die darauf abzielen, Schnittstellen und Mechanismen für den Informationsfluss und -zugriff zu schaffen. Es bedarf Spezialisten – Data Engineers –, um Daten so zu pflegen, dass sie für andere verfügbar und nutzbar bleiben. Kurz gesagt, richten Data Engineers die Dateninfrastruktur des Unternehmens ein und betreiben sie, um sie für weitere Analysen durch Data Analysts und Data Scientists vorzubereiten.

– Aus »Data Engineering and Its Main Concepts« von AltexSoft¹

Die erste Form des Data Engineering ist SQL-lastig. Die Verarbeitung und Speicherung der Daten erfolgen in relationalen Datenbanken. Die gesamte Datenverarbeitung wird mit SQL oder einer SQL-gestützten Sprache durchgeführt. Manchmal wird diese Datenverarbeitung auch mit einem ETL-Tool durchgeführt.² Die zweite Form ist auf Big Data ausgelegt. Die Verarbeitung und Speicherung der Daten erfolgt in Big-Data-Technologien wie Hadoop, Cassandra und HBase. Die gesamte Datenverarbeitung findet in Big-Data-Systemen wie MapReduce, Spark und Flink statt. Zwar wird SQL verwendet, die Verarbeitung erfolgt aber hauptsächlich in Programmiersprachen wie Java, Scala und Python.

– Jesse Anderson³

In Anbetracht der bereits bestehenden Rollen könnte man Data Engineering als eine Obermenge von Business Intelligence und Data Warehousing betrachten, die weitere Elemente aus der Softwareentwicklung enthält. Diese Disziplin umfasst auch eine Spezialisierung auf den Betrieb sogenannter verteilter »Big Data«-Systeme sowie Konzepte im Zusammenhang mit dem erweiterten Hadoop-Ökosystem, der Verarbeitung von Streams und skalierbaren Berechnungen.

– Maxime Beauchemin⁴

Beim Data Engineering dreht sich alles um die Weitergabe, Bearbeitung und Verwaltung von Daten.

– Lewis Gavin⁵

Wow! Völlig verständlich, wenn Sie Data Engineering verwirrend finden. Das ist nur eine Handvoll der Definitionen davon, die eine große Bandbreite an Meinungen zu Data Engineering enthalten.

Data Engineering – eine Definition

Wenn wir die Gemeinsamkeiten der verschiedenen Definitionen von Data Engineering aufschlüsseln, ergibt sich folgendes Muster: Ein Data Engineer bezieht Daten, speichert sie und bereitet sie für die Nutzung durch Data Scientists, Analysten und Dritte vor. Wir definieren Data Engineering und Data Engineer wie folgt:

Data Engineering ist die Entwicklung, Implementierung und Wartung von Systemen und Prozessen, die Rohdaten aufnehmen und hochwertige, konsistente Informationen erzeugen, die nachgelagerte Anwendungsfälle wie Analysen und Machine Learning unterstützen. Data Engineering ist die Schnittstelle zwischen Sicherheit, Datenmanagement, DataOps, Datenarchitektur, Orchestrierung und Softwareentwicklung. Der Data Engineer verwaltet den Data Engineering Lifecycle von der Übertragung der Daten aus Quellsystemen bis hin zur Bereitstellung der Daten für Anwendungen wie Auswertungen oder Machine Learning.

Der Data Engineering Lifecycle

Es ist allzu leicht, sich auf die Technologie zu fixieren und dabei das Gesamtbild zu übersehen. Den Mittelpunkt dieses Buchs bildet eine Leitidee: der Data Engineering Lifecycle (siehe Abbildung 1-1). Diese Idee bietet Data Engineers unserer Meinung nach einen ganzheitlichen Kontext für ihre Arbeit.

Abbildung 1-1: Der Data Engineering Lifecycle

Der Data Engineering Lifecycle verlagert das Augenmerk weg von der Technologie und hin zu den Daten selbst und den damit verbundenen Zielsetzungen. Sie besteht aus den folgenden Phasen:

Generierung

Speicherung

Ingestion

Transformation

Bereitstellung

Der Data Engineering Lifecycle wird von einer Reihe von Unterströmungen, wichtigen Themen aus anderen Bereichen, beeinflusst, die für den gesamten Lebenszyklus wichtig sind. Dazu gehören Sicherheit, Datenmanagement, DataOps, Datenarchitektur, Orchestrierung und Softwareentwicklung. Der Data Engineering Lifecycle und die ihn prägenden Unterströmungen werden in Kapitel 2 ausführlicher behandelt. Wir stellen ihn dennoch hier vor, da er für unsere Definition von Data Engineering und die anschließende Diskussion in diesem Kapitel wichtig ist.

Nun, da Sie eine kurze Einführung in Data Engineering und dessen Lebenszyklus haben, lassen Sie uns einen Blick in die Vergangenheit werfen.

Die Entwicklung des Data Engineers

History doesn’t repeat itself, but it rhymes.

– Ein berühmtes Sprichwort, das oft Mark Twain zugeschrieben wird

Um Data Engineering heute und zukünftig zu verstehen, muss man wissen, wie sich diese Branche entwickelt hat. Dieser Abschnitt ist keine Geschichtslektion, aber ein Blick in die Vergangenheit ist unverzichtbar, um zu verstehen, wo wir heute stehen und was die Zukunft bringen könnte. Ein Phänomen zieht sich wie ein roter Faden durch die Geschichte: Alte Trends werden wieder populär.

Die Anfänge: 1980 bis 2000, vom Data Warehousing zum Web

Die Ursprünge des Data Engineers liegen wohl im Data Warehousing, das bis in die 1970er-Jahre zurückreicht, wobei das Business Data Warehouse in den 1980ern Gestalt annahm und Bill Inmon 1989 offiziell den Begriff Data Warehouse prägte. Nach der Entwicklung der relationalen Datenbank und der Structured Query Language (SQL) durch IBM machte Oracle die Technologie populär. Mit dem Wachstum der aufkommenden Datensysteme benötigten die Unternehmen spezielle Tools und Datenpipelines für das Reporting und die Business Intelligence (BI). Um die korrekte Modellierung der Geschäftslogik im Data Warehouse zu unterstützen, entwickelten Ralph Kimball und Inmon ihre gleichnamigen Methoden zur Datenmodellierung, die auch heute noch sehr verbreitet sind.

Das Data Warehousing läutete das erste Zeitalter der skalierbaren Analytik ein, als neue Datenbanken mit massiver Parallelverarbeitung (MPP) auf den Markt kamen, die mehrere Prozessoren zur Verarbeitung großer Datenmengen nutzten und noch nie da gewesene Datenmengen unterstützen konnten. BI-Engineers, ETL-Entwickler und Data-Warehouse-Engineers befassten sich mit den verschiedenen Anforderungen des Data Warehouse. BI-Engineering und Data Warehouse Engineering waren Vorläufer des heutigen Data Engineering und spielen immer noch eine zentrale Rolle in diesem Bereich.

Das Internet etablierte sich Mitte der 1990er und brachte eine ganz neue Generation von Unternehmen hervor, die sich auf das Onlinegeschäft spezialisiert hatten, wie AOL, Yahoo! und Amazon. Der Dotcom-Boom führte zu einer starken Nachfrage nach Webanwendungen und den sie unterstützenden Backend-Systemen (Server, Datenbanken und Speicher). Ein Großteil der entsprechenden Infrastruktur war teuer, monolithisch und stark lizenziert. Die Anbieter, die diese Backend-Systeme verkauften, ahnten damals wahrscheinlich nicht, welche enormen Datenmengen Webanwendungen produzieren würden.

Die frühen 2000er: die Geburt des heutigen Data Engineering

In den frühen 2000ern brach der Dotcom-Boom der späten 1990er zusammen und hinterließ eine kleine Gruppe von Unternehmen, die die Krise überstanden. Einige dieser Firmen, wie Yahoo!, Google und Amazon, entwickelten sich zu mächtigen Technologiekonzernen. Zunächst nutzten diese Unternehmen weiterhin die traditionellen monolithischen relationalen Datenbanken und Data Warehouses der 1990er, bis diese an die Grenzen ihrer Leistungsfähigkeit stießen. Nun wurden neue Ansätze benötigt, um das Datenwachstum zu bewältigen. Die neue Generation der Systeme musste kostengünstig, skalierbar, zugänglich und zuverlässig sein.

Zeitgleich mit der Datenexplosion wurde auch Standardhardware – wie Server, RAM, Festplatten und Flash-Laufwerke – billig und verbreitete sich stark. Mehrere Innovationen ermöglichten die verteilte Berechnung und Speicherung auf massiven Computerclustern. Diese Innovationen begannen, traditionell monolithische Dienste zu dezentralisieren und aufzulösen. Das Zeitalter von »Big Data« hatte begonnen.

Das Oxford English Dictionary beschreibt Big Data (https://oreil.ly/8IaGH) als »besonders große Datensätze, die computergestützt analysiert werden können, um Muster, Trends und Assoziationen zu erkennen, insbesondere in Bezug auf menschliches Verhalten und Interaktionen«. Des Weiteren wird Big Data prägnant beschrieben als die drei Vs der Daten: Velozität, Vielfalt und Volumen.

Google veröffentlichte 2003 einen Artikel über das Google File System und 2004 einen Artikel über MapReduce, ein hochskalierbares Paradigma für die Datenverarbeitung. Big Data hatte zwar schon Vorläufer in MPP-Data-Warehouses und im Datenmanagement für Projekte der Experimentalphysik, aber die Veröffentlichungen von Google stellten einen Paukenschlag für Informationstechnologien und die Wurzeln des Data Engineering dar, wie wir es heute kennen. Mehr über MPP-Systeme und MapReduce erfahren Sie in den Kapiteln 3 bzw. 8.

Die Artikel von Google inspirierten Yahoo! zur Entwicklung von Apache Hadoop, das 2006 als Open Source veröffentlicht wurde.⁶ Der Einfluss von Hadoop kann gar nicht hoch genug eingeschätzt werden. Softwareentwickler, die sich für komplexe Datenprojekte interessierten, wurden von den Möglichkeiten dieses neuen Open-Source-Systems angezogen. Als Unternehmen aller Art ihre Daten auf viele Terabytes und sogar Petabytes anwachsen sahen, war die Geburtsstunde des Big Data Engineer gekommen.

Etwa zur gleichen Zeit musste Amazon mit seinem eigenen rapide ansteigenden Datenbedarf Schritt halten und schuf elastische Rechenumgebungen (Amazon Elastic Compute Cloud, auch EC2), unbegrenzt skalierbare Speichersysteme (Amazon Simple Storage Service, auch S3), hochgradig erweiterbare NoSQL-Datenbanken (Amazon DynamoDB) und viele weitere Komponenten.⁷ Amazon begann damit, diese Dienste für den internen und externen Gebrauch über Amazon Web Services (AWS) anzubieten, und wurde so zur ersten populären öffentlichen Cloud. AWS hat durch die Virtualisierung und den Weiterverkauf riesiger Mengen an gängiger Hardware einen äußerst flexiblen Marktplatz für IT-Ressourcen geschaffen, bei der die Bezahlung entsprechend der tatsächlichen Nutzung erfolgt (pay-as-you-go). Anstatt Rechenzentren und Server zu kaufen, konnten Entwickler einfach Rechen- und Speicherkapazität von AWS mieten.

AWS entwickelte sich für Amazon zu einem äußerst profitablen Geschäft, und kurz darauf folgten weitere Anbieter öffentlicher Clouds, wie Google Cloud, Microsoft Azure und DigitalOcean. Die öffentliche Cloud ist wohl eine der bedeutendsten Innovationen des 21. Jahrhunderts und hat eine Revolution in der Entwicklung und Bereitstellung von Software- und Datenanwendungen ausgelöst.

Die ersten Anwendungen für Big Data und die öffentliche Cloud legten den Grundstein für das heutige Daten-Ökosystem. Die moderne Datenlandschaft – und Data Engineering, wie wir es heute kennen – würde ohne diese Innovationen nicht existieren.

Die 2000er und 2010er: Big Data Engineering

Die Entwicklung von Big-Data-Tools mit Open Source im Hadoop-Ökosystem ging schnell voran und verbreitete sich vom Silicon Valley aus in technikbegeisterte Unternehmen auf der ganzen Welt. Zum ersten Mal hatte jedes Unternehmen Zugang zu denselben hochmodernen Datentools, die von den führenden Technologiekonzernen verwendet wurden. Eine weitere Revolution war der Übergang vom Batch-Computing zum Event-Streaming, der eine neue Ära großer »Echtzeitdaten« einläutete. In diesem Buch erfahren Sie alles über Batch- und Event-Streaming.

Entwicklerinnen und Entwickler konnten sich für das Neueste und Beste entscheiden – Hadoop, Apache Pig, Apache Hive, Dremel, Apache HBase, Apache Storm, Apache Cassandra, Apache Spark, Presto und zahlreiche weitere aufkommende Technologien. Herkömmliche, kommerziell ausgerichtete und GUI-basierte Software war plötzlich überholt, und mit dem Aufkommen von MapReduce gewann Code first an Bedeutung. Wir (die Autoren) waren in dieser Zeit dabei, und es schien, als würden alte Doktrinen einen jähen Tod auf dem Altar von Big Data sterben.

Die explosionsartige Zunahme von Data-Tools in den späten 2000ern und 2010ern hat den Big Data Engineer hervorgebracht. Um diese Technologien und Methoden – namentlich das Hadoop-Ökosystem mit Hadoop, YARN, Hadoop Distributed File System (HDFS) und MapReduce – effektiv nutzen zu können, mussten Big Data Engineers die Softwareentwicklung und das Einrichten von Infrastrukturen beherrschen, allerdings mit einem anderen Schwerpunkt. Üblicherweise warteten Big Data Engineers massive Hardwarecluster, um Daten in großem Umfang bereitzustellen. Zwar reichten sie vereinzelt Pull Requests für den zentralen Hadoop-Code ein, doch verlagerte sich ihr Schwerpunkt von der Entwicklung der Kerntechnologie auf die Datenbereitstellung.

Big Data wurde schnell zum Opfer seines eigenen Erfolgs. Als Schlagwort gewann Big Data in den frühen 2000ern bis Mitte der 2010er an Popularität. Big Data beflügelte die Fantasie der Unternehmen, die versuchten, die ständig wachsenden Datenmengen sinnvoll zu nutzen, und die schamlose Werbung von Unternehmen, die Tools und Dienste für Big Data verkauften. Angesichts des immensen Hypes war es üblich, dass Unternehmen für kleine Datenprobleme manchmal einen Hadoop-Cluster aufbauten, um nur wenige Gigabyte zu verarbeiten. Es schien, als wolle jeder bei Big Data mitmischen. Dan Ariely twitterte (https://oreil.ly/cpL26): »Big Data ist wie Teenager-Sex: Jeder redet darüber, niemand weiß wirklich, wie man es macht, jeder denkt, dass alle anderen es machen, also behauptet jeder, dass er es macht.«

Abbildung 1-2 zeigt eine Momentaufnahme von Google Trends für den Suchbegriff »big data«, um einen Eindruck vom Aufstieg und Fall von Big Data zu vermitteln.

Abbildung 1-2: Google Trends für »big data« (Stand März 2022)

Entgegen der Popularität des Begriffs hat Big Data an Bedeutung verloren. Was ist passiert? In einem Wort: Vereinfachung. Trotz der Leistungsfähigkeit und Raffinesse von Open-Source-Big-Data-Tools war ihre Verwaltung mit viel Arbeit verbunden und erforderte ständige Kontrolle. Oftmals beschäftigten Unternehmen ganze Teams von Big Data Engineers, die jedes Jahr Millionen von Dollar für die Betreuung dieser Plattformen ausgaben. Big Data Engineers verbrachten häufig unverhältnismäßig viel Zeit mit der Wartung komplizierter Systeme, statt Erkenntnisse und Mehrwert für das Unternehmen zu schaffen.

Open-Source-Entwickler, Clouds und Drittanbieter suchten nach Möglichkeiten, Big Data zu abstrahieren, zu vereinfachen und verfügbar zu machen, ohne dass der hohe Verwaltungsaufwand und die Kosten für die Betreuung ihrer Cluster sowie für Installation, Konfiguration und Aktualisierung ihres Open-Source-Codes anfielen. Der Begriff Big Data ist im Grunde ein Relikt aus vergangener Zeit, das ein bestimmtes Konzept für den Umgang mit großen Datenmengen beschreibt.

Heutzutage sind Daten schneller in Bewegung denn je und werden immer umfangreicher, aber die Verarbeitung von Big Data ist so alltäglich geworden, dass sie keinen eigenen Begriff mehr verdient; jedes Unternehmen ist bestrebt, seine Datenprobleme zu lösen, unabhängig von der tatsächlichen Datengröße. Big Data Engineers sind heute schlicht Data Engineers.

Die 2020er: Engineering für den Datenlebenszyklus

Nach wie vor entwickelt sich die Rolle des Data Engineers rasant weiter. Wir erwarten, dass sich diese Entwicklung in absehbarer Zukunft fortsetzen wird. Während sich Data Engineers in der Vergangenheit um die Details monolithischer Systemsoftware wie Hadoop, Spark oder Informatica kümmerten, geht der Trend zu dezentralisierten, modularisierten, verwalteten und stark abstrahierten Tools.

In der Tat haben sich die Datenanwendungen in erstaunlichem Tempo weiterentwickelt (siehe Abbildung 1-3). Zu den beliebten Trends der frühen 2020er gehört der Modern Data Stack, eine Sammlung von Open-Source-Produkten und Produkten von Drittanbietern, die das Leben von Analysten erleichtern sollen. Gleichzeitig werden die Datenquellen und Datenformate immer vielfältiger und umfangreicher. Data Engineering ist zunehmend eine Disziplin der Interoperation, in der unterschiedliche Technologien wie LEGO-Bausteine kombiniert werden, um Geschäftsziele zu erreichen.

Abbildung 1-3: Matt Turck’s Datenlandschaft (https://oreil.ly/TWTfM) in 2012 versus 2021

Der Data Engineer, den wir in diesem Buch vorstellen, kann besser beschrieben werden als Data Lifecycle Engineer. Durch die größere Abstraktion und Vereinfachung ist ein Data Lifecycle Engineer nicht mehr mit den Details der Big-Data-Frameworks von einst belastet. Während Data Engineers ihre Fähigkeiten in der Programmierung beibehalten und diese bei Bedarf einsetzen, konzentriert sich ihre Rolle zunehmend auf Dinge, die in der Wertschöpfungskette weiter oben angesiedelt sind: Sicherheit, Datenmanagement, DataOps, Datenarchitektur, Orchestrierung und allgemeines Management des Lebenszyklus von Daten.⁸

Im Zuge der Vereinfachung von Tools und Arbeitsabläufen haben wir einen spürbaren Wandel in der Mentalität von Data Engineers festgestellt. Statt sich darauf zu konzentrieren, wer die »meisten Daten« hat, geht es bei Open-Source-Projekten und -Diensten zunehmend darum, Daten zu verwalten und zu steuern, ihre Nutzung und Auswertung zu erleichtern und ihre Qualität zu verbessern. Data Engineers sind mittlerweile mit Akronymen vertraut wie CCPA und GDPR,⁹ da sie sich bei der Entwicklung von Pipelines Gedanken über Datenschutz, Anonymisierung, Data Garbage Collection und die Einhaltung von Richtlinien machen.

Alte Trends werden wieder populär. Während »betriebliche« Aspekte wie Datenmanagement (einschließlich Datenqualität und Governance) in der Zeit vor Big Data in großen Unternehmen gang und gäbe waren, wurden sie in kleineren Unternehmen kaum eingesetzt. Jetzt, da viele der herausfordernden Probleme der Datensysteme von einst gelöst, sauber produziert und gebündelt sind, haben Technologen und Unternehmer den Schwerpunkt wieder auf die »betrieblichen« Aspekte verlagert, allerdings mit dem Fokus auf Dezentralisierung und Agilität, was im Kontrast zu traditionellen Befehls- und Kontrollstrukturen der Unternehmen steht.

Wir halten die Gegenwart für ein goldenes Zeitalter des Data-Lifecycle-Managements. Data Engineers, die den Lebenszyklus von Daten verwalten, verfügen über bessere Tools und Techniken als je zuvor. Im nächsten Kapitel werden der Data Engineering Lifecycle und seine Unterströmungen eingehender erörtert.

Data Engineering und Data Science

Wie passen Data Engineering und Data Science zusammen? Die Debatte ist nicht ganz unumstritten. Einige vertreten die Auffassung, dass Data Engineering eine Unterdisziplin von Data Science ist. Unserer Meinung nach ist Data Engineering unabhängig von Data Science und Analytics. Zwar ergänzen sie sich gegenseitig, sind aber eindeutig verschieden. Data Engineering ist Data Science vorgelagert (siehe Abbildung 1-4), d.h., Data Engineers liefern die Daten, die von Data Scientists (nachgelagert zum Data Engineering) verwendet werden, die wiederum diese Informationen in etwas Verwertbares umwandeln.

Abbildung 1-4: Data Engineering ist Data Science vorgelagert.

Betrachten Sie die Data Science Hierarchy of Needs (siehe Abbildung 1-5). Dieses Modell wurde 2017 von Monica Rogati in einem Artikel (https://oreil.ly/pGg9U) veröffentlicht, der aufzeigte, wo künstliche Intelligenz (KI) und Machine Learning (ML) in Beziehung zu »alltäglicheren« Bereichen wie Datenübertragung und -speicherung, Datenerfassung sowie Dateninfrastruktur stehen.

Abbildung 1-5: Die KI-Bedürfnispyramide (https://oreil.ly/pGg9U) – Data Science Hierarchy of Needs (https://oreil.ly/pGg9U)

Obwohl viele Data Scientists darauf erpicht sind, ML-Modelle zu erstellen und zu optimieren, verbringen sie in Wirklichkeit schätzungsweise 70 % bis 80 % ihrer Zeit mit den unteren drei Teilen der Hierarchie – Datenerfassung, Datenbereinigung, Datenverarbeitung – und nur einen winzigen Teil ihrer Zeit mit Analyse und ML. Rogati argumentiert, dass Unternehmen zunächst eine solide Datengrundlage (die unteren drei Ebenen der Hierarchie) schaffen müssen, bevor sie sich mit Bereichen wie KI und ML befassen.

Data Scientists sind in der Regel nicht dafür ausgebildet, produktionsreife Datensysteme zu entwickeln, und sie erledigen diese Arbeit nur, weil ihnen die Unterstützung und die Ressourcen eines Data Engineers fehlen. In einer idealen Welt sollten Data Scientists mehr als 90 % ihrer Zeit mit den obersten Schichten der Pyramide verbringen: Analytik, Experimentieren und ML. Wenn sich Data Engineers auf diese unteren Teile der Hierarchie konzentrieren, schaffen sie eine solide Grundlage für den Erfolg von Data Scientists.

Während Data Science fortschrittliche Analysen und ML vorantreibt, schließt Data Engineering die Lücke zwischen der Beschaffung und der Nutzbarmachung von Daten (siehe Abbildung 1-6). Wir glauben, dass Data Engineering genauso wichtig und sichtbar ist wie Data Science, wobei Data Engineers eine entscheidende Rolle dabei spielen, Data Science in der Produktion erfolgreich zu machen.

Abbildung 1-6: Ein Data Engineer beschafft Daten und macht sie nutzbar.

Data Engineering – Fähigkeiten und Tätigkeiten

Zu den Fähigkeiten eines Data Engineers zählen die Unterströmungen des Data Engineering: Sicherheit, Datenmanagement, DataOps, Datenarchitektur und Softwareentwicklung. Diese Fähigkeiten erfordern ein Verständnis dafür, wie Datentools zu bewerten sind und wie sie im Laufe des Data Engineering Lifecycle zusammenpassen. Außerdem ist es wichtig zu wissen, wie die Daten in den Quellsystemen erzeugt werden und wie Analysten und Data Scientists nach der Verarbeitung und Aufbereitung der Daten diese nutzen und einen Mehrwert schaffen können. Letztendlich muss ein Data Engineer mit einer Vielzahl komplexer, beweglicher Komponenten gleichzeitig umgehen und diese ständig in Bezug auf Kosten, Agilität, Skalierbarkeit, Einfachheit, Wiederverwendbarkeit und Interoperabilität optimieren (siehe Abbildung 1-7). Wir werden diese Themen in den nächsten Kapiteln ausführlicher behandeln.

Abbildung 1-7: Der Balanceakt im Data Engineering

Wie bereits erwähnt, wurde in der jüngeren Vergangenheit von einem Data Engineer erwartet, dass er weiß und versteht, wie man eine kleine Handvoll leistungsstarker und monolithischer Technologien (Hadoop, Spark, Teradata, Hive und viele andere) verwendet, um eine Datenlösung zu entwickeln. Die Nutzung dieser Technologien erfordert oft ein detailliertes Verständnis von Softwaretechnik, Netzwerken, verteilten Systemen, Speicherung und anderen systemnahen Segmenten. Ihre Arbeit würde sich unter anderem auf die Clusterverwaltung und -wartung, die Verwaltung des Overheads und das Schreiben von Pipeline- und Transformationsaufträgen konzentrieren.

Heutzutage ist die Verwaltung und Bereitstellung von Datentools wesentlich weniger kompliziert. Moderne Datentools verallgemeinern und vereinfachen die Arbeitsabläufe erheblich. Folglich konzentrieren sich Data Engineers nunmehr darauf, die einfachsten und kosteneffektivsten Best-of-Breed-Dienste zusammenzustellen, die einen Mehrwert für das Unternehmen bieten. Von Data Engineers wird außerdem erwartet, dass sie flexible Datenarchitekturen erstellen, die sich neuen Trends entsprechend weiterentwickeln.

Was tun Data Engineers nicht? Üblicherweise erstellt ein Data Engineer weder ML-Modelle noch Berichte oder Dashboards, er führt auch keine Datenanalysen durch, erstellt keine Leistungsindikatoren (KPIs) und entwickelt keine Softwareanwendungen. Ein Data Engineer sollte jedoch über ein gutes Verständnis dieser Bereiche verfügen, um die Beteiligten bestmöglich unterstützen zu können.

Datenreife und der Data Engineer

Der Grad der Komplexität des Data Engineering eines Unternehmens hängt in hohem Maße von seiner Datenreife ab. Dies hat erhebliche Auswirkungen auf die täglichen Aufgaben eines Data Engineers und seine berufliche Entwicklung. Was genau aber ist Datenreife?

Datenreife ist die Entwicklung hin zu einer höheren Datennutzung, zu mehr Datenpotenzial und besserer Datenintegration im gesamten Unternehmen, aber die Datenreife hängt nicht unbedingt vom Alter oder dem Umsatz eines Unternehmens ab. Ein Start-up in der Frühphase kann eine höhere Datenreife aufweisen als ein 100 Jahre altes Unternehmen mit einem Jahresumsatz in Milliardenhöhe. Entscheidend ist die Art und Weise, wie Daten als Wettbewerbsvorteil genutzt werden.

Data-Maturity-Modelle gibt es in vielen Varianten, z.B. Data Management Maturity (DMM) (https://oreil.ly/HmX62), und es ist schwer, eines auszuwählen, das sowohl einfach als auch nützlich für das Data Engineering ist. Daher werden wir unser eigenes, vereinfachtes Datenreifemodell erstellen. Unser Data-Maturity-Modell (Abbildung 1-8) hat drei Stufen: mit Daten beginnen, mit Daten skalieren und mit Daten führen. Wir schauen uns jede dieser Stufen genauer an und erläutern, welche Tätigkeiten ein Data Engineer jeweils ausübt.

Abbildung 1-8: Unser vereinfachtes Datenreifemodell für ein Unternehmen

Stufe 1: Mit Daten beginnen

Ein Unternehmen, das mit der Nutzung von Daten beginnt, befindet sich definitionsgemäß in einem sehr frühen Stadium seiner Datenreife. Das Unternehmen hat möglicherweise ungenaue, lose definierte Ziele oder gar keine Ziele. Datenarchitektur und -infrastruktur befinden sich in einem sehr frühen Stadium der Planung und Entwicklung. Akzeptanz und Nutzung sind wahrscheinlich gering oder gar nicht vorhanden. Das Datenteam ist klein, oft mit einer Mitarbeiterzahl im einstelligen Bereich. In diesem Stadium ist ein Data Engineer meist ein Generalist und übernimmt in der Regel mehrere andere Rollen, z.B. die eines Data Scientists oder eines Softwareentwicklers. Data Engineers sind bestrebt, Fortschritte zu machen, sich durchzusetzen und Mehrwert zu schaffen.

Die praktische Umsetzung der Wertschöpfung aus Daten wird in der Regel nur unzureichend verstanden, aber der Wunsch danach ist vorhanden. Berichten oder Analysen fehlt eine formale Struktur, und die meisten Datenanfragen erfolgen ad hoc. Es ist zwar verlockend, sich in diesem Stadium direkt in ML zu stürzen, aber wir raten davon ab. Wir haben schon unzählige Datenteams erlebt, die nicht weiterkamen und scheiterten, wenn sie versuchten, ML zu nutzen, ohne zunächst eine solide Datengrundlage zu schaffen.

Das soll nicht heißen, dass Sie in diesem Stadium keine Erfolge mit ML erzielen können – das ist zwar selten, aber möglich. Ohne eine solide Datengrundlage haben Sie jedoch wahrscheinlich weder die Daten, um zuverlässig ML-Modelle zu trainieren, noch die Mittel, um diese Modelle auf skalierbare und wiederholbare Weise in der Produktion einzusetzen. Wir bezeichnen uns selbst scherzhaft als »Recovering Data Scientists« (https://oreil.ly/2wXbD), hauptsächlich aufgrund persönlicher Erfahrungen in unausgereiften Data-Science-Projekten ohne angemessene Datenreife oder Data-Engineering-Unterstützung.

Ein Data Engineer sollte sich in Unternehmen, die damit beginnen, mit Daten zu arbeiten, auf Folgendes konzentrieren:

Holen Sie sich die Zustimmung der wichtigsten Interessengruppen, einschließlich der Geschäftsleitung. Idealerweise sollte der Data Engineer einen Ansprechpartner für kritische Initiativen zur Entwicklung und zum Aufbau einer für die Ziele des Unternehmens geeigneten Datenarchitektur haben.

Definieren Sie die richtige Datenarchitektur (vermutlich im Alleingang, da ein Datenarchitekt wahrscheinlich nicht verfügbar ist). Das bedeutet, dass Sie die Geschäftsziele und den Wettbewerbsvorteil, den Sie mit Ihrer Dateninitiative erreichen wollen, bestimmen müssen. Arbeiten Sie auf eine Datenarchitektur hin, die diese Ziele unterstützt. In Kapitel 3 finden Sie unsere Ratschläge für eine »gute« Datenarchitektur.

Identifizieren und prüfen Sie Daten, die wichtige Initiativen unterstützen und innerhalb der von Ihnen entworfenen Datenarchitektur funktionieren.

Schaffen Sie eine solide Datengrundlage für künftige Analysten und Data Scientists, damit diese Berichte und Modelle erstellen können, die einen Wettbewerbsvorteil bieten. Bis zur Zusammenstellung dieses Teams müssen möglicherweise Sie solche Berichte und Modelle erstellen.

Dies ist ein heikles Stadium mit vielen Fallstricken. Hier sind einige Tipps für diese Phase:

Die Motivation im Unternehmen kann schwinden, wenn keine sichtbaren Erfolge mit Daten erzielt werden. Schnelle Erfolge machen die Relevanz von Daten innerhalb der Organisation deutlich. Bedenken Sie jedoch, dass solche Erfolge technische Schulden verursachen können. Erstellen Sie daher einen Plan, um diese Altlasten abzubauen, da sie andernfalls die zukünftige Bereitstellung beeinträchtigen könnten.

Gehen Sie raus und sprechen Sie mit den Leuten, statt abgeschottet zu arbeiten. Wir sehen oft, dass das Datenteam in einer Blase arbeitet, nicht mit Menschen außerhalb der eigenen Abteilung kommuniziert und weder Perspektiven noch Feedback von den Interessengruppen des Unternehmens einholt. Die Gefahr ist, dass Sie viel Zeit damit verbringen, an etwas zu arbeiten, das den Beteiligten wenig nützt.

Vermeiden Sie unnötige Anstrengungen. Verzichten Sie auf überflüssige technische Komplexität. Verwenden Sie, wo immer möglich, gebrauchsfertige Lösungen.

Erstellen Sie maßgeschneiderte Lösungen und Code nur dort, wo dies einen Wettbewerbsvorteil darstellt.

Stufe 2: Mit Daten skalieren

An diesem Punkt ist ein Unternehmen von Ad-hoc-Datenanfragen abgerückt und verfügt über formale Datenpraktiken. Jetzt besteht die Herausforderung darin, skalierbare Datenarchitekturen zu schaffen und für eine Zukunft zu planen, in der das Unternehmen wirklich datengesteuert ist. Die Funktionen im Data Engineering entwickeln sich von Generalisten zu Spezialisten, die sich auf bestimmte Aspekte des Data Engineering Lifecycle konzentrieren.

In Unternehmen, die sich in Stufe 2 der Datenreife befinden, verfolgt ein Data Engineer die diese Ziele:

Einrichten offizieller Datenverfahren.

Schaffung skalierbarer und robuster Datenarchitekturen.

Anwenden von DevOps- und DataOps-Verfahren.

Systeme aufbauen, die ML unterstützen.

Vermeiden Sie weiterhin unnötige Anstrengungen und entwickeln Sie individuelle Lösungen nur dann, wenn sich daraus ein Wettbewerbsvorteil ergibt.

Wir werden auf jedes dieser Ziele später im Buch zurückkommen.

Zu beachten sind unter anderem die folgenden Punkte:

Da wir im Umgang mit Daten immer versierter werden, besteht die Gefahr, dass wir die Spitzentechnologien der Unternehmen aus dem Silicon Valley einsetzen wollen. Dies ist selten ein guter Einsatz von Zeit und Energie. Alle technologischen Entscheidungen sollten sich an dem Wert orientieren, den sie für Ihre Kunden haben werden.

Der kritischste Punkt bei der Skalierung ist nicht die Technologie, die Anzahl der Clusterknoten oder der Speicher, sondern das Team. Konzentrieren Sie sich auf Lösungen, die einfach zu implementieren und zu verwalten sind, um den Leistungsumfang Ihres Teams zu erhöhen.

Sie werden versucht sein, sich als Technologe darzustellen, als ein Datengenie, das wundersame Leistungen erbringen kann. Konzentrieren Sie sich stattdessen auf die pragmatische Führung und beginnen Sie mit dem Übergang zur nächsten Reifegradstufe; tauschen Sie sich mit anderen Teams über den praktischen Nutzen von Daten aus. Bringen Sie dem Unternehmen bei, wie es Daten nutzen und einsetzen kann.

Stufe 3: Mit Daten führen

In diesem Stadium ist das Unternehmen datengesteuert. Die automatisierten Pipelines und Systeme, die von Data Engineers entwickelt wurden, ermöglichen den Mitarbeitenden im Unternehmen, Analysen und ML selbst durchzuführen. Die Einführung neuer Datenquellen erfolgt reibungslos, und es wird ein messbarer Mehrwert geschaffen. Data Engineers implementieren angemessene Kontrollen und Methoden, um sicherzustellen, dass die Daten für Belegschaft und Systeme immer verfügbar sind. Die Spezialisierung von Data-Engineering-Funktionen nimmt gegenüber Stufe 2 weiter zu.

In Unternehmen, die sich in Stufe 3 der Datenreife befinden, wird ein Data Engineer auf den vorherigen Stufen aufbauen und zusätzlich Folgendes umsetzen:

Entwicklung von Automatismen für die reibungslose Einführung und Nutzung neuer Daten.

Aufbau maßgeschneiderter Tools und Systeme, die Daten als Wettbewerbsvorteil nutzen.

Konzentration auf die »unternehmerischen« Aspekte von Daten, wie Datenmanagement (einschließlich Data Governance und Qualität) und DataOps.

Bereitstellung von Tools, die Daten im gesamten Unternehmen zugänglich machen und verbreiten, einschließlich Datenkatalogen, Tools für die Datenherkunft und Systemen zur Verwaltung von Metadaten.

Effiziente Zusammenarbeit mit Softwareentwicklern, ML-Engineers, Analysten und anderen.

Schaffung einer Atmosphäre und eines Umfelds, in dem Menschen zusammenarbeiten und offen sprechen können, unabhängig von ihrer Rolle oder Position.

Zu beachten sind unter anderem die folgenden Punkte:

In dieser Phase ist Selbstzufriedenheit eine große Gefahr. Sobald Unternehmen die Stufe 3 erreicht haben, müssen sie sich ständig auf die Instandhaltung und Weiterentwicklung konzentrieren, oder sie riskieren, auf eine niedrigere Stufe zurückzufallen.

Technologische Ablenkungen stellen hier eine größere Gefahr dar als in den anderen Phasen. Die Versuchung ist groß, teure Hobbyprojekte zu verfolgen, die dem Unternehmen keinen Nutzen bringen. Setzen Sie maßgeschneiderte Technologie nur dort ein, wo sie einen Wettbewerbsvorteil bietet.

Der berufliche Werdegang und die Kompetenzen eines Data Engineers

Data Engineering ist ein Bereich, der sich schnell entwickelt, und es sind bisher viele Fragen darüber noch nicht geklärt, wie man ein Data Engineer wird. Da es sich um eine relativ neue Disziplin handelt, gibt es nur wenige formale Ausbildungsmöglichkeiten für den Einstieg in diesen Bereich. An den Universitäten findet man keinen einheitlichen Studiengang für Data Engineering. Zwar gibt es eine Handvoll Bootcamps und Onlinetutorials zum Thema Data Engineering, aber einen gemeinsamen Lehrplan für dieses Fach gibt es noch nicht.

Menschen, die mit Data Engineering beginnen, bringen unterschiedliche Vorkenntnisse in den Bereichen Ausbildung, Beruf und Fähigkeiten mit. Jeder, der in dieses Gebiet einsteigt, sollte damit rechnen, dass er einen beträchtlichen Teil seiner Zeit in das Selbststudium investieren wird. Die Lektüre dieses Buchs ist ein guter Ausgangspunkt; eines der Hauptziele des Buchs ist es, Ihnen eine Grundlage für das Wissen und die Fähigkeiten zu vermitteln, die unserer Meinung nach notwendig sind, um als Data Engineer erfolgreich zu sein.

Wenn Sie Ihre Karriere in Richtung Data Engineering lenken möchten, ist es unserer Erfahrung nach am einfachsten, wenn Sie aus einem angrenzenden Bereich wie Softwareentwicklung, ETL-Entwicklung, Datenbankadministration, Data Science oder Datenanalyse kommen. Diese Disziplinen sind in der Regel »datenorientiert« und bieten einen guten Kontext für die Aufgaben in einem Unternehmen. Außerdem verfügen sie über die relevanten technischen Fähigkeiten und den nötigen Hintergrund, um Probleme des Data Engineering zu lösen.

Trotz des Fehlens eines geregelten Ausbildungswegs gibt es eine Reihe von Kenntnissen, die ein Data Engineer beherrschen sollte, um erfolgreich zu sein. Per definitionem muss ein Data Engineer sowohl Daten als auch Technologie verstehen. In Bezug auf Daten bedeutet dies, dass er über das Wissen zu verschiedenen bewährten Methoden bei der Handhabung von Daten verfügt. Was die Technologie betrifft, so muss ein Data Engineer verschiedene Anwendungen, ihr Zusammenspiel und ihre Wechselwirkungen kennen. Dies erfordert ein gutes Verständnis von Softwareentwicklung, DataOps und Datenarchitektur.

Bei näherer Betrachtung muss ein Data Engineer auch die Anforderungen der Datennutzerinnen und -nutzer (Analysten und Data Scientists) sowie die umfassenderen Auswirkungen der Daten auf das gesamte Unternehmen verstehen. Data Engineering ist eine ganzheitliche Tätigkeit; die besten Data Engineers sehen ihre Aufgaben aus geschäftlicher und technischer Sicht.

Geschäftliche Verantwortlichkeiten

Die hier aufgeführten Zuständigkeiten sind nicht nur für Data Engineers wichtig, sondern für jeden, der in einem technischen oder datenbasierten Umfeld arbeitet. Da eine einfache Google-Suche tonnenweise Informationsquellen zu diesen Bereichen liefert, werden wir sie der Kürze halber lediglich auflisten:

Sie wissen, wie Sie mit nicht technischen und technischen Personen kommunizieren.

Kommunikation ist entscheidend, und Sie müssen in der Lage sein, Beziehungen und Vertrauen zu den Menschen im gesamten Unternehmen aufzubauen. Wir empfehlen Ihnen, genau darauf zu achten, welche Hierarchien im Unternehmen bestehen, wer wem unterstellt ist, wie die Mitarbeitenden miteinander umgehen und welche Trennungen es gibt. Diese Beobachtungen werden für Ihren Erfolg von unschätzbarem Wert sein.

Sie verstehen, wie man Geschäfts- und Produktanforderungen erfasst und einbezieht.

Sie müssen wissen, was Sie aufbauen wollen, und sicherstellen, dass Ihre Ansprechpartner mit Ihrer Einschätzung einverstanden sind. Außerdem müssen Sie ein Gefühl dafür entwickeln, wie sich Daten- und Technologieentscheidungen auf das Unternehmen auswirken.

Sie kennen die kulturspezifischen Grundlagen von Agile, DevOps und DataOps.

Viele Technologen glauben fälschlicherweise, dass diese Methoden in Form von Technologie umgesetzt werden können. Unserer Meinung nach ist das ein großer Irrtum. Agile, DevOps und DataOps sind von Grund auf kulturell geprägt und erfordern eine unternehmensweite Akzeptanz.

Sie haben die Kosten im Griff.

Sie werden erfolgreich sein, wenn Sie die Kosten niedrig halten und gleichzeitig einen enormen Mehrwert bieten können. Sie wissen, wie Sie die Zeit bis zur Wertschöpfung, die Gesamtbetriebskosten und die Opportunitätskosten optimieren können. Lernen Sie, die Kosten zu überblicken, um Überraschungen zu vermeiden.

Lebenslanges Lernen.

Der Datensektor verändert sich mit Lichtgeschwindigkeit. Diejenigen, die in diesem Bereich Erfolg haben, sind sehr gut darin, neue Dinge aufzuschnappen und gleichzeitig ihr Grundlagenwissen zu vertiefen. Sie sind auch gut darin, zu erkennen, welche neuen Entwicklungen für ihre Arbeit am wichtigsten sind, welche noch unausgereift sind und welche nur eine Modeerscheinung darstellen. Bleiben Sie auf dem Laufenden und lernen Sie, wie man lernt.

Ein erfolgreicher Data Engineer ist immer bestrebt, das große Ganze zu verstehen und zu erkennen, wie er oder sie einen Mehrwert für das Unternehmen erzielen kann. Kommunikation ist entscheidend, sowohl für technische als auch für nicht technische Beteiligte. Wir sehen oft, dass der Erfolg von Datenteams auf ihrer Kommunikation mit anderen Beteiligten beruht; Erfolg oder Misserfolg ist selten eine Frage der Technologie. Wenn Sie wissen, wie man sich in einem Unternehmen zurechtfindet, wie man Anforderungen festlegt und sammelt, wie man Kosten überblickt und kontinuierlich lernt, werden Sie sich von den Data Engineers unterscheiden, die sich ausschließlich auf ihre technischen Fähigkeiten verlassen, um ihre Karriere voranzutreiben.

Technische Verantwortlichkeiten

Sie müssen wissen, wie Sie Architekturen aufbauen sowie Leistung und Kosten auf hohem Niveau optimieren, indem Sie vorgefertigte oder selbst erstellte Lösungen verwenden. Letztlich sind Architekturen und die sie bildenden Technologien Bausteine, die den Data Engineering Lifecycle unterstützen. Rufen Sie sich die Phasen des Data Engineering Lifecycle in Erinnerung:

Generierung

Speicherung

Ingestion

Transformation

Bereitstellung

Zu den Unterströmungen des Data Engineering Lifecycle gehören:

Sicherheit

Datenmanagement

DataOps

Datenarchitektur

Orchestrierung

Softwareentwicklung

In diesem Abschnitt gehen wir etwas näher auf einige der Daten- und Technologiekenntnisse ein, die Sie als Data Engineer benötigen; diese werden in den folgenden Kapiteln ausführlicher behandelt.

Oft wird gefragt, ob ein Data Engineer programmieren können sollte. Klare Antwort: Ja. Ein Data Engineer sollte über fundierte Kenntnisse in der Softwareentwicklung verfügen. Wir stellen fest, dass sich die Art der von Data Engineers durchgeführten Projekte im Bereich der Softwareentwicklung in den letzten Jahren grundlegend verändert hat. Vollständig verwaltete Dienste ersetzen jetzt einen großen Teil der systemnahen Programmierarbeit, die früher von Data Engineers erwartet wurde, die wiederum jetzt verwaltete Open-Source- und einfache Plug-and-play-Software-as-a-Service-Angebote (SaaS) nutzen. Beispielsweise konzentrieren sich Data Engineers nunmehr auf anwendungsorientierte Abstraktionen oder das Programmieren von Pipelines innerhalb eines Orchestrierungsframeworks.

Selbst in einer weniger abstrakten Welt bedeuten Kenntnisse in der Softwareentwicklung einen Wettbewerbsvorteil, und Data Engineers, die die architektonischen Details einer Codebasis verstehen können, verschaffen ihren Unternehmen einen Vorteil, wenn spezifische technische Probleme auftreten. Kurz gesagt, ein Data Engineer, der keinen produktionsreifen Code schreiben kann, wird ernsthaft in seiner Arbeit behindert, und wir gehen nicht davon aus, dass sich dies in naher Zukunft ändern wird. Data Engineers bleiben, zusätzlich zu ihren vielen anderen Funktionen, Softwareentwickler.

Welche Sprachen sollte ein Data Engineer beherrschen? Wir unterteilen die Programmiersprachen im Data Engineering in Primär- und Sekundärsprachen. Gegenwärtig sind die primären Sprachen im Data Engineering SQL, Python, eine Sprache der Java Virtual Machine (JVM, meist Java oder Scala) und Bash:

SQL

Die am häufigsten zu findende Schnittstelle für Datenbanken und Data Lakes. Nachdem sie kurzzeitig durch die Notwendigkeit, eigens für die Verarbeitung von Big Data MapReduce-Code zu schreiben, in den Hintergrund gedrängt wurde, hat sich SQL (in verschiedenen Formen) wieder als Lingua franca der Datenverarbeitung etabliert.

Python

Das Bindeglied zwischen Data Engineering und Data Science. Eine wachsende Zahl von Programmen im Data Engineering ist in Python geschrieben oder verfügt über Python-APIs. Es ist bekannt als »die zweitbeste Sprache für alles«. Python liegt beliebten Datentools wie pandas, NumPy, Airflow, scikitlearn, TensorFlow, PyTorch und PySpark zugrunde. Python verbindet die einzelnen Bestandteile und ist häufig eine erstklassige API-Sprache für die Verbindung zu einem Framework.

JVM-Sprachen wie Java und Scala

Weit verbreitet für Open-Source-Projekte von Apache wie Spark, Hive und Druid. Die JVM ist im Allgemeinen leistungsfähiger als Python und kann Zugang zu komplexeren Funktionen als eine Python-API bieten (dies ist beispielsweise bei Apache Spark und Beam der Fall). Java- oder Scala-Kenntnisse sind von Vorteil, wenn Sie ein verbreitetes Open-Source-Daten-Framework verwenden.

Bash

Die Kommandozeilenschnittstelle für Linux-Betriebssysteme. Die Kenntnis der Bash-Befehle und der sichere Umgang mit der Kommandozeile wird Ihre Produktivität und Ihren Arbeitsablauf bei der Erstellung von Skripten oder der Durchführung von Betriebssystemoperationen deutlich verbessern. Auch heute noch verwenden Data Engineers häufig Befehle wie awk oder sed, um Dateien in einer Datenpipeline zu verarbeiten oder Bash-Befehle aus Orchestrierungsframeworks aufzurufen. Unter Windows kann Bash durch PowerShell ersetzt werden.

Die irrationale Effizienz von SQL

Mit dem Aufkommen von MapReduce und Big Data wurde SQL in den Hintergrund gedrängt. Seitdem haben zahlreiche Entwicklungen den Nutzen von SQL im Data Engineering Lifecycle deutlich erhöht. Spark SQL, Google BigQuery, Snowflake, Hive und viele andere Datentools können große Datenmengen verarbeiten, indem sie eine deklarative, mengentheoretische SQL-Semantik verwenden. SQL wird auch von vielen Streaming-Frameworks unterstützt, z.B. von Apache Flink, Beam und Kafka. Unserer Meinung nach sollten gute Data Engineers sehr versiert in SQL sein.

Wollen wir damit sagen, dass SQL das A und O der Sprachen ist? Ganz und gar nicht. SQL ist ein leistungsstarkes Tool, mit dem sich komplexe Analyse- und Transformationsprobleme schnell lösen lassen. Da der Zeitfaktor für die Leistung von Data-Engineering-Teams eine wichtige Rolle spielt, sollten Tools eingesetzt werden, die sowohl einfach zu bedienen als auch leistungsstark sind. Data Engineers tun ebenfalls gut daran, sich Kenntnisse über die Kombination von SQL mit anderen Prozessen anzueignen, entweder innerhalb von Frameworks wie Spark und Flink oder durch den Einsatz von Orchestrierung zur Kombination mehrerer Tools. Außerdem sollten sie die moderne SQL-Semantik für den Umgang mit Java-Script Object Notation (JSON) und verschachtelten Daten beherrschen und den Einsatz eines SQL-Management-Frameworks wie dbt (Data Build Tool) (https://www.getdbt.com) in Betracht ziehen.

Ein erfahrener Data Engineer erkennt auch, wann SQL nicht das richtige Werkzeug für die Aufgabe ist, und kann eine geeignete Alternative auswählen und programmieren. Eine SQL-Spezialistin könnte wahrscheinlich eine Query für das Stemming und die Tokenisierung von Rohtext in einer Pipeline zur Verarbeitung natürlicher Sprache (NLP) schreiben, würde aber auch erkennen, dass die Programmierung in nativem Spark eine weitaus bessere Alternative darstellt.

Möglicherweise müssen Data Engineers darüber hinaus Fertigkeiten in sekundären Programmiersprachen entwickeln, wie R, JavaScript, Go, Rust, C/C++, C# und Julia. Die Programmierung in diesen Sprachen ist oft notwendig, wenn diese unternehmensweit verbreitet sind oder in Verbindung mit fachspezifischen Datentools verwendet werden. So hat sich beispielsweise JavaScript als Sprache für benutzerdefinierte Funktionen in Cloud Data Warehouses bewährt. Gleichzeitig sind C# und PowerShell in Unternehmen, die Azure und Microsoft nutzen, unerlässlich.

Mithalten in einem dynamischen Geschäftsfeld

Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.

– Stewart Brand

Wie können Sie Ihre Fähigkeiten in einem sich ständig verändernden Bereich wie dem Data Engineering auf dem neuesten Stand halten? Sollten Sie sich auf die neuesten Tools konzentrieren oder die Grundlagen beherrschen? Unser Rat: Setzen Sie sich mit den Grundlagen auseinander, um zu verstehen, was sich nicht ändern wird; achten Sie auf die laufenden Entwicklungen, um zu erkennen, wohin sich das Feld bewegt. Ständig werden neue Paradigmen und Verfahren eingeführt, und es ist Ihre Aufgabe, auf dem Laufenden zu bleiben. Sie sollten verstehen, wie neue Technologien von Nutzen sein können.

Das Kontinuum der Rollen im Data Engineering – von A nach B

Obwohl Stellenanzeigen einen Data Engineer als »Einhorn« darstellen, das über alle nur denkbaren Kompetenzen im Datenbereich verfügen muss, haben nicht alle Data Engineers die gleiche Art von Arbeit oder die gleichen Fähigkeiten. Die Datenreife ist ein hilfreicher Leitfaden, um die verschiedenartigen Herausforderungen zu verstehen, mit denen ein Unternehmen konfrontiert wird, wenn es seine Datenkapazität ausbaut. Es ist von Vorteil, einige wichtige Unterschiede in der Art der Arbeit von Data Engineers zu betrachten. Diese Unterscheidungen sind zwar grob vereinfacht, aber sie verdeutlichen, was Data Scientists und Data Engineers tun, und verhindern, dass beide Rollen in einen Topf geworfen werden.

In der Data Science gibt es den Begriff des Typs A und des Typs B der Data Scientists.¹⁰ Data Scientists vom Typ A – wobei das A für Analyse steht – konzentrieren sich darauf, Daten zu verstehen und aus ihnen Erkenntnisse zu gewinnen. Data Scientists vom Typ B – wobei das B für Building (Entwicklung) steht – haben einen ähnlichen Lebenslauf wie Data Scientists vom Typ A und verfügen über gute Programmierkenntnisse. Der Data Scientist vom Typ B entwickelt Systeme, die Data Science in der Produktion ermöglichen. In Anlehnung an dieses Kontinuum treffen wir eine ähnliche Einteilung für zwei Arten von Data Engineers:

Data Engineers vom Typ A

A bedeutet Abstraction (Abstraktion). Hier vermeidet der Data Engineer allzu komplexe Aufgaben, hält die Datenarchitektur so abstrakt und einfach wie möglich und erfindet das Rad nicht neu. Data Engineers vom Typ A verwalten den Data Engineering Lifecycle hauptsächlich durch den Einsatz von Standardprodukten, Managed Services und Tools. Data Engineers vom Typ A arbeiten in Unternehmen aller Branchen und auf allen Ebenen der Datenreife.

Data Engineers vom Typ B

B bedeutet build (entwickeln). Data Engineers vom Typ B entwickeln Datentools und -systeme, die skalierbar sind und die Kernkompetenzen und Wettbewerbsvorteile eines Unternehmens nutzen. Im Bereich der Datenreife ist ein Data Engineer des Typs B eher in Unternehmen der Stufen 2 und 3 zu finden (Skalierung und Führung mit Daten) oder wenn ein anfänglicher Datenanwendungsfall so einzigartig und unternehmenskritisch ist, dass maßgeschneiderte Datentools erforderlich sind.

Data Engineers der Typen A und B können im selben Unternehmen arbeiten und möglicherweise sogar ein und dieselbe Person sein! In der Regel wird zunächst ein Data Engineer des Typs A eingestellt, um die Grundlagen zu schaffen. Die Fähigkeiten des Data Engineers des Typs B werden entweder erlernt oder bei Bedarf im Unternehmen neu eingestellt.

Data Engineers innerhalb eines Unternehmens

Data Engineers arbeiten nicht isoliert. Je nachdem, woran sie arbeiten, interagieren sie mit technischen und nicht technischen Kollegen und sind mit verschiedenen (internen und externen) Parteien konfrontiert. Im Folgenden werden wir untersuchen, was Data Engineers innerhalb einer Organisation tun und mit wem sie interagieren.

Nach innen gerichtete versus nach außen gerichtete Data Engineers

Ein Data Engineer ist für mehrere Nutzerinnen und Nutzer tätig und sieht sich vielen internen und externen Anweisungen gegenüber (siehe Abbildung 1-9). Da nicht alle Aufgaben und Verantwortlichkeiten im Data Engineering gleich sind, ist es wichtig zu verstehen, für wen der Data Engineer arbeitet. Je nach Endanwendung sind die vorrangigen Aufgaben eines Data Engineers nach außen oder nach innen gerichtet oder eine Mischung aus beidem.

Abbildung 1-9: Die Ausrichtung eines Data Engineers

Ein nach außen gerichteter Data Engineer arbeitet in der Regel mit den Nutzern von nach außen gerichteten Anwendungen wie Social-Media-Apps, Internet-of-Things-Geräten (IoT) und E-Commerce-Plattformen zusammen. Dieser Data Engineer entwirft, erstellt und verwaltet die Systeme, die Transaktions- und Ereignisdaten aus diesen Anwendungen erfassen, speichern und verarbeiten. Diese Systeme haben eine Rückkopplungsschleife von der Anwendung zur Datenpipeline und dann zurück zur Anwendung (siehe Abbildung 1-10).

Abbildung 1-10: Nach außen gerichtete Systeme

Nach außen gerichtete Systeme bringen eine Reihe spezifischer Probleme mit sich. Nach außen gerichtete Query Engines bewältigen oft viel mehr gleichzeitige Ausführungen als interne Systeme. Die Entwickler müssen auch in Betracht ziehen, die Anzahl der Abfragen, die ein Benutzer ausführen kann, stark einzuschränken, um die Auswirkungen eines einzelnen Benutzers auf die Infrastruktur zu begrenzen. Darüber hinaus ist die Sicherheit bei externen Abfragen ein viel komplexeres und heikleres Problem, insbesondere wenn die abgefragten Daten mehrmandantenfähig sind (Daten von vielen Kunden in einer einzigen Tabelle).

Ein nach innen gerichteter Data Engineer konzentriert sich in der Regel auf Aktivitäten, die für die Bedürfnisse des Unternehmens und der internen Interessengruppen entscheidend sind (siehe Abbildung 1-11). Einige Beispiele hierfür sind die Erstellung und Pflege von Datenpipelines und Data Warehouses für BI-Dashboards, Berichte, Geschäftsprozesse, Data Science und ML-Modelle.

Abbildung 1-11: Ein nach innen gerichteter Data Engineer

Die Zuständigkeiten nach außen und nach innen werden oft vermischt. In der Praxis sind die internen Daten in der Regel eine Voraussetzung für die nach außen gerichteten Daten. Der Data Engineer hat zwei Benutzergruppen mit sehr unterschiedlichen Anforderungen an die Gleichzeitigkeit von Abfragen, die Sicherheit und vieles mehr.

Data Engineers und andere technische Rollen

In der Praxis erstreckt sich der Data Engineering Lifecycle über viele Verantwortungsbereiche. Data Engineers sitzen an der Schnittstelle zwischen verschiedenen Rollen und interagieren entweder direkt oder über ihre Manager mit vielen Abteilungen.

Lassen Sie uns nun einen Blick darauf werfen, auf wen ein Data Engineer Einfluss haben kann. In diesem Abschnitt werden die technischen Rollen im Zusammenhang mit Data Engineering erläutert (siehe Abbildung 1-12).

Der Data Engineer stellt eine Verbindung dar zwischen Datenproduzenten, wie Softwareentwicklern, Datenarchitekten und DevOps oder Site Reliability Engineers (SREs), und Datennutzern, wie Datenanalysten, Data Scientists und ML-Engineers. Darüber hinaus interagieren Data Engineers mit Personen in operativen Rollen, wie DevOps-Engineers.

Abbildung 1-12: Wichtige Beteiligte im Data Engineering

In Anbetracht des Tempos, in dem neue Datenfunktionen in Mode kommen (man denke nur an Analytiker und ML-Engineers), ist diese Liste keineswegs vollständig.

Vorgelagerte Akteure

Um als Data Engineer erfolgreich