Data science & Data Engineering
Kundenmanagement
Erfolgreiches Kundenmanagement ist umfassend und wurde vielfach von Unternehmen aufgrund des damit verbundenen Aufwands vernachlässigt. Kundenzufriedenheit ist jedoch häufig ein elementarer Bestandteil des Unternehmenserfolgs und sollte daher die entsprechende Anerkennung erhalten. Mit den eigenen Kunden effizient, transparent und vertrauensvoll zusammenarbeiten ist dabei essenziell. Data-Science kann dabei Prozesse automatisieren und wesentlich erleichtern ohne dass Kunden ihre Geschäftsgeheimnisse preisgeben müssten. Entgegen den Datenkraken aus dem Web 2.0, bei denen Kunden freiwillig ihre Daten preisgeben sollten, empfiehlt cusy, die Daten für die Data-Science-Auswertung beim Kunden zu belassen und dort auszuwerten. cusy unterstützt Unternehmen dabei, wie Kundendaten aus unterschiedlichsten Quellen konsolidiert und zusammengeführt werden können, Produktarten eines Unternehmens zusammengeführt und das gesammelte Wissen optimal u.a. mit Text Mining- und Sentiment-Analyse ausgewertet werden können.
Prognosen
Doch nicht nur im Kundenmanagement bietet Data-Science fortschrittliche Lösungen, sondern z.B. auch bei der Auftragsprognose: Schwankende Eingänge und heterogenes Lieferverhalten einzelner Lieferanten erschweren die Planbarkeit enorm. Machine-Learning-Modelle können Muster im Lieferantenverhalten erkennen um dann Voraussagen über die zukünftigen Wareneingangsmengen zu treffen. Die besseren Prognosen erlauben nun nicht nur eine bessere Planung von Personal und Lagerflächen sondern auch eine intelligentere Steuerung der Lieferanten, bei der Auslastungsspitzen vorausgeahnt und durch Neuverteilung der Aufträge ausgeglichen werden können.
Logistik
Wenn Zeit Geld ist, dann ist die Reduzierung von Arbeitsaufwänden sehr verlockend. Dabei kann cusy mit Routenoptimierungen unterstützen, sowohl bei der dynamischen Routenoptimierung wie auch bei der Last-Mile-Disposition.
Meldet euch
Ich berate euch gerne und erstelle ein passgenaues Angebot für euer Data-Science-Projekt.
Ich rufe euch auch gerne an!
Daten und deren Herkunft finden mit DataHub
Traditionell wurde diese Funktion von aufgeblähten Datenkatalogisierungslösungen bereitgestellt. In den letzten Jahren kamen einige Open-Source-Projekte hinzu, die die Developer Experience (DX) sowohl beim Anbieten als auch beim Konsumieren von Daten verbessern, z.B. Metacat von Netflix , WhereHows von LinkedIn, Amundsen der LF AI & Data Foundation und Marquez von WeWork. Gleichzeitig änderte sich auch das Verhalten der Data Provider, die weggehen von den aufgeblähten Datenkatalogisierungslösungen hin zu Werkzeugen, die partielle Metadateninformationen aus unterschiedlichen Datenquellen ableiten können.
So hat auch LinkedIn WhereHows weiterentwickelt zu DataHub. Diese Plattform ermöglicht das Auffinden von Daten über ein erweiterbares Metadatensystem. Anstatt Metadaten zu crawlen und zu pullen, verwendet DataHub ein Push-Modell, bei dem die einzelnen Komponenten des Datenökosystems Metadaten über eine REST-API oder einen Kafka-Stream auf der zentralen Plattform veröffentlichen. Diese Push-basierte Integration verlagert die Verantwortung von der zentralen Einheit auf die einzelnen Teams, die damit für ihre Metadaten verantwortlich sind. Da immer mehr Unternehmen versuchen, datengesteuert zu werden, ist ein System, das bei der Datenerkennung und dem Verständnis der Datenqualität und -herkunft hilft, von entscheidender Bedeutung.
Dabei erlaubt die Generalized Metadata Architecture (GMA) von DataHub verschiedene Speichertechnologien, die angefragt werden können mit
- dokumentenbasiertem CRUD (Create, Read, Update, Delete)
- komplexen Abfragen auch verschachtelter Tabellen
- Graph-Traversierung
- Volltextsuche inkl. Autovervollständigung
Es stehen Plugins bereit u.a. für Dateien, BigQuery, dbt, Hive, Kafka, LDAP, MongoDB, MySQL, PostgreSQL, SQLAlchemy, und Snowflake. Darüberhinaus könnt ihr Metadaten an das DataHub übertragen via Konsole, REST-API und Dateien.
Mit der GMA kann auch jedes Team eigene Metadatendienste, sog. GMS, bereitstellen um ihre Daten über Graphen und Suchindizees erschließen zu können.
Um auch die Software, die zum Erstellen der Daten verwendet wurde, erschließen zu können, verwenden wir aktuell Git2PROV und importieren die PROV-Daten anschließend mit file sink.
Schließlich verwendet DataHub Apache Gobblin um den Lebenszyklus der Daten zu erschließen.
Auswahl der richtigen NoSQL-Datenbank
NoSQL-Datenbanken sollten die folgenden Probleme lösen:
- Überbrücken der internen Datenstruktur der Anwendung und der relationalen Datenstruktur der Datenbank
- Abkehr von der Integration verschiedenster Datenstrukturen in ein einheitliches Datenmodell
- Die wachsende Anzahl an Daten erforderte zunehmend Cluster zur Datenspeicherung
Aggregierte Datenmodelle
Die relationale Datenbankmodellierung unterscheidet sich erheblich von den Arten von Datenstrukturen, die Anwendungsentwickler verwenden. Die Verwendung der von Entwickler*innen modellierten Datenstrukturen zur Lösung verschiedener Problemdomänen hat zu einer Abkehr von der relationalen Modellierung hin zu aggregierten Modellen geführt. Der größte Teil davon wird von Domain Driven Design angetrieben. Ein Aggregat ist eine Sammlung von Daten, mit denen wir als Einheit interagieren. Diese Aggregate bilden die Grenzen für ACID-Operationen, wobei die Schlüsselwerte, Dokumente und Column Family als Formen einer aggregatorientierten Datenbank angesehen werden können.
Aggregate erleichtern der Datenbank die Verwaltung der Datenspeicherung auf einem Cluster, da sich die Dateneinheit jetzt auf jedem Computer befinden kann. Aggregatorientierte Datenbanken funktionieren am besten, wenn die meisten Dateninteraktionen mit demselben Aggregat durchgeführt werden, z.B. wenn ein Profil mit allen Details abgerufen werden muss. Es ist besser, das Profil als Aggregationsobjekt zu speichern, und diese Aggregate zu verwenden, um Profildetails abzurufen.
Distributionsmodelle
Aggregatorientierte Datenbanken erleichtern die Verteilung von Daten, da der Verteilungsmechanismus nur das Aggregat verschieben muss und sich nicht um verwandte Daten kümmern muss, da alle verwandten Daten im Aggregat selbst enthalten sind. Dabei gibt es im Wesentlichen zwei Arten der Datenverteilung:
- Sharding
- Sharding verteilt unterschiedliche Daten auf mehrere Server, sodass jeder Server als einzige Quelle für eine Teilmenge von Daten fungiert.
- Replikation
Replikation kopiert Daten über mehrere Server hinweg, sodass jedes Datum an mehreren Stellen gefunden werden kann. Die Replikation erfolgt in zwei Formen:
Die Master-Slave-Replikation macht einen Knoten zur autorisierenden Kopie, die Schreibvorgänge verarbeitet, während Slaves mit dem Master synchronisiert werden und möglicherweise Lesevorgänge verarbeiten.
Die Peer-to-Peer-Replikation ermöglicht Schreibvorgänge auf jeden Knoten. Die Knoten koordinieren sich um ihre Kopien der Daten zu synchronisieren.
Die Master-Slave-Replikation verringert zwar die Wahrscheinlichkeit von Aktualisierungskonflikten, aber die Peer-to-Peer-Replikation vermeidet das Schreiben allerVorgänge auf einen einzelnen Server, wodurch ein einzelner Fehlerpunkt vermieden wird. Ein System kann eine oder beide Techniken verwenden.
CAP-Theorem
In verteilten Systemen sind die folgenden drei Aspekte wichtig:
- Konsistenz (engl.: Consistency)
- Verfügbarkeit (engl.: Availability)
- Ausfalltoleranz (engl.: Partition tolerance)
Eric Brewer hat das CAP-Theorem aufgestellt, das besagt, dass wir in jedem verteilten System nur zwei der drei Optionen auswählen können. Viele NoSQL-Datenbanken versuchen, Optionen bereitzustellen, bei denen ein Setup gewählt werden kann, die Datenbank entsprechend dein Anforderungen aufzusetzen. Wenn ihr beispielsweise Riak als verteilte Schlüssel-Werte-Datenbank betrachtet, gibt es im Wesentlichen die drei Variablen
- r
- Anzahl der Knoten, die auf eine Leseanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
- w
- Anzahl der Knoten, die auf eine Schreibanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
- n
- Anzahl der Knoten, auf denen die Daten repliziert werden, auch Replikationsfaktor genannt
In einem Riak-Cluster mit 5 Knoten können wir die Werte für r, w und n so anpassen, dass das System sehr konsistent ist indem wir r = 5 und w = 5 setzen. Damit haben wir jedoch den Cluster für Netzwerkpartitionen anfällig gemacht, da kein Schreibvorgang möglich ist wenn nur ein Knoten nicht antwortet. Wir können denselben Cluster für Schreib- oder Lesevorgänge hoch verfügbar machen, indem wir r = 1 und w = 1 setzen. Jetzt kann jedoch die Konsistenz beeinträchtigt werden, da einige Knoten möglicherweise nicht über die neueste Kopie der Daten verfügen. Das CAP-Theorem besagt, dass ihr, wenn ihr eine Netzwerkpartition erhaltet, die Verfügbarkeit von Daten gegen die Konsistenz von Daten abwägen müsst. Auch die Haltbarkeit kann gegen die Latenz abgewogen werden, insbesondere wenn ihr Fehler mit replizierten Daten überstehen möchtet.
Häufig benötigtet ihr bei relationalen Datenbanken kaum ein Verständnis für diese Anforderungen; nun werden diese wieder wichtig. So dürftet ihr gewöhnt gewesen sein, in relationalen Datenbanken Transaktionen zu verwenden. In NoSQL-Datenbanken stehen euch diese jedoch nicht mehr zur Verfügung und ihr müsst selbst überlegen, wie diese implementiert werden sollen. Muss das Schreiben transaktionssicher sein? Oder ist es auch akzeptabel, dass mal Daten verlorengehen? Schließlich kann manchmal auch ein externer Transaktionsmanager wie ZooKeeper hilfreich sein.
Verschiedene Arten von NoSQL-Datenbanken
NoSQL-Datenbanken können grob in vier Typen eingeteilt werden:
Schlüssel-Werte-Datenbanken
Schlüssel-Werte-Datenbanken sind aus API-Sicht die einfachsten NoSQL-Datenspeicher. Der Client kann entweder den Wert für den Schlüssel abrufen, einen Wert für einen Schlüssel eingeben oder einen Schlüssel aus dem Datenspeicher löschen. Der Wert ist ein Blob, den der Datenspeicher nur speichert, ohne sich darum zu kümmern oder zu wissen, was sich darin befindet. Es liegt ausschließlich in der Verantwortung der Anwendung, zu verstehen, was gespeichert wurde. Da Schlüssel-Werte-Datenbanken immer den Primärschlüsselzugriff verwenden, weisen sie im Allgemeinen eine hohe Leistung auf und können leicht skaliert werden.
Einige der beliebtesten Schlüsselwertdatenbanken sind
- Riak KV
- Home | GitHub | Docs
- Redis
- Home | GitHub | Docs
- Memcached
- Home | GitHub | Docs
- Berkeley DB
- Home | GitHub | Docs
- Upscaledb
- Home | GitHub | C API Docs
Ihr müsst sie sorgfältig auswählen da es große Unterschiede zwischen ihnen gibt. Während Riak z.B. die Daten persistent speichert ist dies bei Memcached üblicherweise nicht der Fall.
Dokumentendatenbanken
Diese Datenbanken speichern und rufen Dokumente ab, bei denen es sich um XML, JSON, BSON usw. handeln kann. Diese Dokumente sind hierarchische Baumdatenstrukturen, die aus Karten, Sammlungen und Skalarwerten bestehen können. Dokumentendatenbanken bieten umfangreiche Abfragesprachen und Konstrukte wie Datenbanken, Indizes usw., die einen einfacheren Übergang von relationalen Datenbanken ermöglichen.
Einige der beliebtesten Dokumentendatenbanken sind
Column Family Stores
Diese Datenbanken speichern Daten in Column Families als Zeilen, die einem Zeilenschlüssel zugeordnet sind. Sie sind hervorragend geeignet für Gruppen verwandter Daten, auf die häufig zusammen zugegriffen wird. Dies können beispielsweise alle Profilinformationen einer Person sein, nicht jedoch deren Aktivitäten.
Zwar kann jede Column Family mit der Zeile in einer RDBMS-Tabelle verglichen werden, in dem der Schlüssel die Zeile identifiziert und die Zeile aus mehreren Spalten besteht; aber in Column Family Stores müssen die verschiedene Zeilen nicht dieselben Spalten haben.
Einige der beliebtesten Column Family Stores sind
Cassandra kann als schnell und einfach skalierbar beschrieben werden, da Schreibvorgänge über den Cluster verteilt sind. Der Cluster verfügt nicht über einen Masterknoten, sodass Lese- und Schreibvorgänge von jedem Knoten im Cluster ausgeführt werden können.
Graphdatenbank
In Graphdatenbanken könnt ihr Entitäten mit bestimmten Eigenschaften und Beziehungen zwischen diesen Entitäten speichern. Entitäten werden auch als Knoten bezeichnet. Stellt euch einen Knoten als Instanz eines Objekts in einer Anwendung vor; Beziehungen können dann als Kanten bezeichnet werden, die ebenfalls Eigenschaften haben können und gerichtet sind.
Graph-Modelle
- Labeled-Property-Graph
- In einem Labeled-Property-Graph können sowohl Knoten als auch Kanten Eigenschaften (engl.: Properties) besitzen.
- Resource Description Framework (RDF)
- Im RDF werden Graphen mit Hilfe von Triplen repräsentiert. Ein Triple besteht aus drei Elementen in der Form Knoten-Kante-Knoten Subjekt --Prädikat-> Objekt, die als Ressourcen in Form einer weltweit eindeutigen URI oder als anonyme Ressource definiert werden. Um innerhalb einer Datenbank verschiedene Graphen verwalten zu können, werden diese als Quads gespeichert wobei ein Quad jedes Triple um eine Referenz auf den zugehörigen Graphen erweitert. Aufbauend auf RDF wurde mit RDF-Schema ein Vokabular entwickelt, um schwache Ontologien zu formalisieren und darüber hinaus mit der Web Ontology Language auch vollständig entscheidbare Ontologien beschreiben.
Algorithmen
Wichtige Algorithmen zur Abfrage von Knoten und Kanten sind:
- Breitensuche, Tiefensuche
- Breitensuche (engl.: breadth-first search, BFS) ist ein Verfahren zum Durchlaufen der Knoten eines Graphen verwendet. Im Gegensatz zur Tiefensuche (engl.: depth-first search, DFS) werden zunächst alle Knoten beschritten, die vom Ausgangsknoten direkt erreichbar sind. Erst danach werden Folgeknoten beschritten.
- Kürzester Pfad
- Pfad zwischen zwei unterschiedlichen Knoten eines Graphen, welcher minimale Länge bezüglich einer Kantengewichtsfunktion hat.
- Eigenvektor
- In der linearen Algebra ein vom Nullvektor verschiedener Vektor, dessen Richtung durch die Abbildung nicht verändert wird. Ein Eigenvektor wird also nur skaliert und der Skalierungsfaktor wird als Eigenwert der Abbildung bezeichnet.
Abfragesprachen
- Blueprints
- eine Java-API für Eigenschaftsgraphen, die zusammen mit verschiedenen Graphdatenbanken verwendet werden kann.
- Cypher
- eine Abfragesprache entwickelt von Neo4j.
- GraphQL
- eine SQL-artige Abfragesprache
- Gremlin
- eine Open-Source-Graphen-Programmiersprache, die mit verschiedenen Graphdatenbanken (Neo4j, OrientDB) genutzt werden kann.
- SPARQL
- vom W3C spezifizierte Abfragesprache für RDF-Datenmodelle.
Abgrenzung zu relationalen Datenbanken
Wenn wir Graphen in relationalen Datenbanken speichern wollen, geschieht dies meist nur für spezifische Bedingungen, z.B. für die Beziehungen zwischen Menschen. Das Hinzufügen weiterer Beziehungsarten ist dann normalerweise mit vielen Schemaänderungen verbunden.
In Graphdatenbanken ist das Durchlaufen der Verknüpfungen oder Beziehungen sehr schnell, da die Beziehung zwischen Knoten nicht erst zur Abfragezeit berechnet werden muss.
Einige der beliebtesten Graphdatenbanken sind
Auswahl der NoSQL-Datenbank
Allen NoSQL-Datenbanken ist gemein, dass sie kein bestimmtes Schema erzwingen. Im Gegensatz zu relationalen Datenbanken mit starkem Schema müssen Schemaänderungen nicht zusammen mit dem Quellcode, der auf diese Änderungen zugreift, gespeichert werden. Schemalose Datenbanken können Änderungen im implizierten Schema tolerieren, sodass sie keine Downtime zur Migration benötigen; sie sind daher vor allem bei Systemen, die 24/7 zur Verfügung stehen sollen, sehr beliebt.
Wie wählen wir nun aber unter so vielen NoSQL-Datenbanken die richtige aus? Im Folgenden können wir Ihnen nur einige allgemeine Kriterien nennen:
- Schlüssel-Werte-Datenbanken
- sind im Allgemeinen nützlich zum Speichern von Sessions, Benutzerprofilen und Einstellungen. Wenn jedoch Beziehungen zwischen den gespeicherten Daten abgefragt oder mehrere Schlüssel gleichzeitig bearbeitet werden sollen, würden wir Schlüsselwertdatenbanken vermeiden.
- Dokumentendatenbanken
- sind im Allgemeinen nützlich für Content-Management-Systeme und E-Commerce-Anwendungen. Wir würden die Verwendung von Dokumentdatenbanken jedoch vermeiden, wenn komplexe Transaktionen benötigt odermehrere Vorgänge oder Abfragen für unterschiedliche Aggregatstrukturen gestellt werden sollen.
- Column Family Stores
- sind im Allgemeinen nützlich für Content-Management-Systeme und für hohe Schreibvolumen wie z.B. bei der Protokollaggregation. Wir würden die Verwendung von Datenbanken für Column Family Stores vermeiden, die sich in der frühen Entwicklung befinden und deren Abfragemuster sich noch ändern können.
- Graphdatenbanken
- eignen sich sehr gut für Problembereiche, in denen wir Daten wie soziale Netzwerke, Geodaten, Routing-Informationen sowie Empfehlungssystem miteinander verbunden werden sollen.
Fazit
Der Aufstieg der NoSQL-Datenbanken führte nicht zum Niedergang der relationalen Datenbanken. Sie können gut nebeneinander existieren. Häufig werden unterschiedliche Datenspeichertechnologien verwendet um die Daten passend zu ihrer Struktur und erforderlichen Abfrage zu speichern.
»Versionskontrolle für Machine-Learning-Projekte« in Informatik Aktuell vom 11. August 2020
Cusy schreibt in Informatik Aktuell in loser Reihe Artikel über Data Science Workflows. Als erster Beitrag ist nun Versionskontrolle für Machine-Learning-Projekte am 11. August 2020 erschienen.
In diesem Artikel erfahrt ihr, wie die Modellentwicklung für maschinelles Lernen (ML) systematisch organisiert werden kann. So kann die Leistung eines Modells verbessert werden, wenn ihr die Parameter feiner abgestimmt oder wenn mehr Trainingsdaten verfügbar werden. Um die Verbesserung messen zu können, sollte nachverfolgt werden können, welche Daten für das Training in welcher Modelldefinition und -konfiguration (Parameter etc.) verwendet und welche Modellleistungen damit erzielt wurden. Dabei werden sowohl die Daten wie auch der zugehörige Programmcode in einer Version erfasst werden.
DVC-Workflow
Anhand eines Beispielprojekts führt der Artikel durch die folgenden Phasen:
- Repositories erstellen
- Datenpipelines definieren
- Reproduzieren
- Pipeline visualisieren
- Daten teilen
Unser Fazit ist ,dass mit DVC sprachunabhängig reproduzierbare ML-Pipelines definiert und zusammen mit den zugehörigen Trainingsdaten, Konfigurationen, Leistungsmetriken usw. versioniert gespeichert werden können. Dabei arbeitet DVC mit allen modernen Versionsverwaltungen zusammen und unterstützt viele verschiedene Speicherarten wie S3, Google Cloud, Azure, SSH usw. DVC strukturiert so nicht nur die Datenhaltung, sondern durch einzelne, atomare Phasen der DVC-Pipeline bleiben Änderungen in den Daten auch transparent und nachvollziehbar. Insgesamt erleichtert und effektiviert dies die Arbeit an ML-Projekten erheblich.
Beuth Hochschule: Prototyp Medikamenten-App
Für die Beuth Hochschule entwickeln wir den Prototypen einer Medikamenten-App. Dabei soll die Sicherheit für Patienten bei der Medikation verbessert werden, und zwar insebsondere
- das Monitoring des Einnahmerhythmus
- die Warnung vor Nebenwirkungen und wechselseitigen Beeinflussungen.
Zudem sollte die App nicht nur von Patienten selbst genutzt werden können, sondern auch für Angehörige Und Pflegekräfte möglich sein.
Tatsächlich gibt es bereits viele Apps, die versprechen, die Anforderungen zu erfüllen. Bei einer genaueren Recherche wiesen sie jedoch erhebliche Mängel auf.
Fachliche Qualität
Die fachliche Qualität der meisten Apps ist nur selten erkennbar und dürfte, wenn die wenigen Überprüfungen zugrundegelegt werden, meist sehr gering sein. Dies ist umso problematischer, wenn Apps versprechen, auf Wechselwirkungen und doppelte Verordnungen ähnlich wirkender Medikamente hinzuweisen. Für Kunden, die sich darauf verlassen, dass ihre App sie schon auf Gefahren, z.B. bei ihren Selbstmedikationswünschen hinweisen wird, dürften massiv gefährdet sein.
Nutzergruppen
Die bereits existierenden Apps machen auch ganz selten Angaben zu ihren Nutzergruppen, weder zur
- Eignung für spezifische Erkrankungen/Leiden
- Eignung für Geschlecht, spezielle Altersgruppen (bzw. -bereiche) etc.
- Eignung für bestimmte Gesundheitsberufe bzw. Berufsgruppen und Settings: klinisch, ambulant, zu Hause, …
- Eignung bei physiologischen und körperlichen Beeinträchtigungen, auch nicht die Unterstützung für TalkBack für Android und VoiceOver für iPhone.
- Unterstützung länderspezifischer Arzneimittel und Packungsgrößen
Datenschutz
Auch der Umgang mit Nutzerdaten ist meist mangelhaft. Die Datenschutzerklärungen lassen Kunden meist im Unklaren, was mit ihren Angaben geschieht. Dies ist umso problematischer, da über 80% der Apps Daten an Infrastrukturanbieter wie Google, Facebook etc. übertragen. Noch nicht einmal die verschlüsselte Übertragung von Nutzerdaten war immer gewährleistet, dies vor allem dann nicht, wenn Daten per E-Mail übertragen werden. Die wenigen unabhängigen Testverfahren dürften hier kaum zu einer Klärung beitragen, da sie sich meist auf die Selbstauskunft verlassen.
elena international: Webbasiertes Planungswerkzeug für Microgrids
elena international GmbH ist ein Startup, das maßgeschneiderte Lösungen für verschiedene Phasen der Netzplanung liefert.
Als erstes realisieren wir ein Walking Skeleton eines webbasierten Planungswerkzeug für Microgrids.
Die gewählte Software-Architektur erlaubt elena, ihre Julia-Bibliotheken weiterzuentwickeln. Die Übernahme neuer Features in das Webtool erfolgt dann mit PyJulia in IPython-Notebooks. In diesen Notebooks können auch die voila-vuetify-Widgets für die Interaktion mit den NutzerInnen definiert werden. Schließlich werden diese Notebooks mit Voilà in ein interaktives Dashboard umgewandelt:
Um die Notebooks für die Produktion zu härten sind die Methoden einerseits mit Tests versehen, die mit GitLab CI/CD regelmäßig durchlaufen werden, andererseits erleichtert Logging die Fehlerdiagnose und das Monitoring.
Damit beantworten wir nicht nur die Frage Sind Jupyter Notebooks produktionsreif? sondern erweitern die Möglichkeiten von Notebooks noch: sie dienen hier als umfassendes Editorensystem, in dem nicht nur Texte verfasst und Medien hinzugefügt werden können, sondern auch die Darstellungslogik wissenschaftlicher Berechnungen und interaktive Widgets definiert werden können.
Sind Jupyter Notebooks produktionsreif?
In den letzten Jahren gab es einen rasanten Anstieg in der Verwendung von Jupyter Notebooks, s.a. Octoverse: Growth of Jupyter Notebooks, 2016-2019. Hierbei handelt es sich um eine von Mathematica inspirierte Anwendung, die Text, Visualisierung und Code in einem Dokument kombiniert. Jupyter-Notebooks werden von unseren Kunden häufig für das Prototyping und die Erforschung von Analysen und maschinellem Lernen verwendet. Wir haben jedoch auch gesehen, dass die wachsende Popularität auch dazu beigetragen hat, dass Jupyter-Notebooks in anderen Bereichen der Datenanalyse verwendet wird und zusätzliche Werkzeuge genutzt wurden, um mit ihnen auch umfangreiche Berechnungen durchzuführen.
Zum Erstellen von skalierbarem, wartbarem und langlebigem Produktionscode erscheinen uns Jupyter Notebooks jedoch meist ungeeignet. Zwar lassen sich mit einigen Tricks Notebooks sinnvoll versionieren und es lassen sich auch automatisierte Tests ausführen, bei komplexeren Projekten wird die Vermischung von Code, Kommentaren und Tests jedoch zum Hindernis: Jupyter Notebooks lassen sich nur unzureichend modularisieren. Zwar können Notebooks als Module importiert werden, diese Möglichkeiten sind jedoch äußerst beschränkt: so müssen die Notebooks zunächst vollständig in den Speicher geladen und ein neues Modul erstellt werden, bevor jede Zelle in diesem ausgeführt werden kann.
In der Folge kam es zum ersten Notebook-Krieg, s. The First Notebook War, der im Wesentlichen ein Konflikt zwischen Data Scientists und Software Engineers war.
Wie können die Gräben überwunden werden?
Notebooks erfreuen sich bei Data Scientists rasch wachsender Beliebtheit und werden zum De-facto-Standard für rapid Prototyping und explorative Analysen. Vor allem Netflix hat jedoch ein umfangreiches Ökosystem von zusätzlichen Tools und Services erstellt, wie z.B. Genie und Metacat. Diese Tools vereinfachen die Komplexität und unterstützen einen breiteren Anwenderkreis von Analysten über Wissenschaftler bis hin zu Informatikern. Im Allgemeinen hängt jede dieser Rollen von verschiedenen Tools und Sprachen ab. Oberflächlich betrachtet scheinen die Workflows unterschiedlich, wenn nicht komplementär zu sein. Auf einer abstrakteren Ebene jedoch haben diese Workflows mehrere überlappende Aufgaben:
- Datenexploration
tritt früh in einem Projekt auf
Dies kann das Anzeigen von Beispieldaten, die statistische Profilerstellung sowie die Datenvisualisierung umfassen
- Datenaufbereitung
iterative Aufgabe
kann das Bereinigen, Standardisieren, Transformieren, Denormalisieren und Aggregieren von Daten umfassen
- Datenvalidierung
wiederkehrende Aufgabe
kann das Anzeigen von Beispieldaten, das Ausführen von Abfragen zur statistischen Profilerstellung und aggregierten Analyse sowie das Visualisieren von Daten umfassen
- Produkterstellung
tritt spät in einem Projekt auf
Dies kann das Bereitstellen von Code für die Produktion, Schulungsmodelle und das Planen von Workflows umfassen
Ein JupyterHub kann hier schon gute Dienste leisten um diese Aufgaben möglichst einfach und überschaubar zu gestalten. Dabei ist es skalierbar und reduziert die Anzahl der Tools erheblich.
Um zu verstehen, warum Jupyter-Notebooks für uns so überzeugend sind, heben wir noch einmal ihre Kernfunktionalitäten hervor:
- Ein Messaging-Protokoll zum Prüfen und Ausführen von sprachunabhängigem Code
- Ein bearbeitbares Dateiformat zum Beschreiben und Erfassen von Code, Code-Ausgabe und Markdown-Notes
- Eine webbasierte Benutzeroberfläche zum interaktiven Schreiben und Ausführen von Code sowie zur Datenvisualisierung
Use Cases
Von unseren zahlreichen Anwendungsfällen verwenden wir Notebooks heute am häufigsten für Datenzugriffe, Parametrisierung und Workflow-Planung.
Datenzugriffe
Notebooks wurden von uns erstmals eingeführt, um Data-Science-Workflows zu unterstützen. Als die Akzeptanz zunahm, sahen wir die Möglichkeit, die Vielseitigkeit und Architektur von Jupyter-Notebooks auch für den allgemeinen Datenzugriff nutzen zu können. Mitte 2018 begannen wir damit, die Notebooks von einem Nischenprodukt zu einer universellen Datenplattform auszubauen.
Aus Sicht der Benutzer bieten Notebooks eine komfortable Oberfläche für die iterative Ausführung von Code, das Durchsuchen und Visualisieren von Daten – alles in einer einzigen Entwicklungsplattform. Aufgrund dieser Kombination aus Vielseitigkeit, Leistung und Benutzerfreundlichkeit haben wir eine schnelle Akzeptanz für viele Benutzergruppen auf der gesamten Plattform festgestellt.
Paremtrisierte Notebooks
Einhergehend mit der zunehmenden Akzeptanz haben wir weitere Funktionen für weitere Anwendungsfälle eingeführt. Aus dieser Arbeit gingen einfach parametrisierbare Notebooks hervor. Dies bot unseren Nutzern einen einfachen Mechanismus um Notizbücher als wiederverwendbare Vorlagen zu definieren.
Workflow-Planung
Als weiteren Einsatzbereich von Notebooks haben wir die Planung von Workflows entdeckt. Sie haben u.a. folgende Vorteile:
- Notebooks erlauben einerseits interaktives Arbeiten und rapid Prototyping, um anschließend fast reibungslos in den Produktivbetrieb überführt werden zu können. Evtl. werden die Notebooks modularisiert und als vertrauenswürdig gekennzeichnet.
- Ein weiterer Vorteil von Notebooks sind die unterschiedlichen Kernel, sodass die sich Benutzer die jeweils passende Ausführungsumgebung auswählen können.
- Zudem sind Fehler in Notebooks einfacher nachzuvollziehen da sie bestimmten Zellen zugeordnet sind und die Ausgaben gespeichert werden können.
Logging
Um Notebooks nicht nur für Rapid Prototyping sondern auch dauerhaft produktiv verwenden zu können, müssen bestimmte Prozesseereignisse protokolliert werden, sodass z.B. Fehler einfacher diagnostiziert und der Gesamtprozess überwacht werden kann. Hierfür kann in IPython Notebboks das logging-Modul der Python-Standardbibliothek oder loguru verwendet werden, s.a. Jupyter-Tutorial: Logging.
Tests
Es gab schon früher einige Ansätze, mit denen sich Notebooks automatisiert testen ließen, z.B. nbval, aber erst mit ipytest wurde das Schreiben von Tests für Notebooks deutlich vereinfacht, siehe auch Jupyter-Tutorial: ipytest.
Resümee
In den letzten Jahren förderten wir die enge Zusammenarbeit von Software Engineers mit Data Scientists um zu skalierbarem, wartbarem und produktionsfähigem Code zu gelangen. Gemeinsam haben wir Lösungen gefunden, die produktionsreife Modelle auch für Machine Learning-Projekte bereitstellen können.
Domain-Driven Datenarchitektur
Wir arbeiten seit zwei Jahren am Aufbau eines Computercluster für das Fraunhofer ISE.
Dabei wurde von uns häufig erwartet, dass wir diesen zentralisiert, monolithisch und domänenunabhängig aufbauen, also als sog. Data Lake.
Die größte Herausforderung besteht nicht darin, einen Datensee zu erstellen, sondern die sich daraus ergebenden Chancen zu nutzen.
– Sean Martin, CTO Cambridge Semantics
Wir konnten jedoch bereits früher zusammen mit anderen Kunden erkennen, dass diese Chancen kaum genutzt werden konnten. Hier deswegen zunächst ein kurzer Überblick über frühere Architektur-Generationen:
Historie
Generation: Enterprise Data Warehouse (EDW)
Vor einem Jahrzehnt waren Daten meist ein Synonym für relationale Datenbanken. Meist führte dies jedoch zu hohen technischen Schulden in Form von tausenden nicht zu überarbeitenden ETL (extract, transform, load)-Jobs, die nur eine kleine Gruppe von Fachleuten versteht. Damit blieben jedoch die erhofften positiven Auswirkungen unerfüllt.
Generation: Big-Data-Ökosystem mit einem Data Lake
Jetzt können Daten eine erstaunliche Vielfalt von Formen annehmen einschließlich NoSQL, Zeitreihen und SQL. Dies ist auf den Wunsch zurückzuführen, immer schneller auf immer größere, vielfältigere und schnellere Datenquellen zu reagieren. Forscher werden jedoch mit dem Verstehen unterschiedlicher Arten der Datenhaltung vor zusätzliche Herausforderungen gestellt. Aktuell bekommen wir also zusätzliche Möglichkeiten, ohne dass jedoch die grundlegenden Probleme der vorgehenden Generation gelöst worden wären. Diese Ökosysteme mit lange laufenden Batch-Jobs werden mit all ihren Auswirkungen meist nur von hochspezialisierten Fachleuten verstanden. Zwar führte dies theoretisch zu einer Fülle von möglichen Analysen und Simulationen, diese konnten aber wegen ihres Umfangs und ihrer Komplexität praktisch nur selten realisiert werden.
CockRoachDB und Spanner bieten darüberhinaus globale Konsistenz und Event stream processing (ESP) mit Abfragemöglichkeiten für aggregierte Log-Dateien.
Ein Nachteil dieses Ansatzes besteht jedoch darin, dass er eher an low-level Database Events als an Geschäftsereignisse auf höherer Ebene gebunden ist, die für uns die Grundlage einer ereignisorientierten Architektur sein sollte – Ereignisse sollten in ihren Domänen explizit erfasst werden oder Statusübergänge sollten nicht impizit erschlossen werden müssen.
Beiden Generationen sind jedoch die folgenden Architekturfehler gemeinsam:
- zentral und monolithisch
- sequenzierte Pipeline
- spezialisiertes Eigentum
Ad 1. Zentral und monolithisch
Alle zugänglichen Daten wurden erfasst und dem ETL (extract, transform, load)-Dreischritt unterworfen:
Extract
Möglichst alle Daten wurden erfasst, unabhängig davon, ob sie für eine spezifische Fachdomäne benötigt wurden oder nicht.
Transform
Die Transformation der Daten erfolgte üblicherweise ebenfalls nicht in Hinblick auf die konkreten Erfordernisse sondern vielmehr in Hinblick auf eine möglichst universelle Verwendbarkeit. Häufig wurden die Daten auch noch mit Informationen aus anderen Datenquellen angereichert um prinzipiell noch umfassendere Analysen machen zu können.
Load
In diesem Schritt wurde darauf geschaut, dass die Daten für eine Vielzahl von Fachdomänen über die gewünschten Protokolle bereitgestellt werden können.
Während wir bei der Anwendungsentwicklung in den letzten Jahren darauf achteten, dass das Design spezifisch für die jeweilige Domäne ist und auch nur in diesem spezifischen Kontext funktionieren muss, wurde Domain Driven Design bei den Datenplattformen weitgehend ignoriert. Dies führte dann zu den bekannten Problemen:
- Die Aufwände, diese domänenunspezifischen Daten zu harmonisieren, nahmen zu.
- In vielen Fällen war zu sehen, dass die Integration neuer Datenquellen verzögert oder blockiert wurde, weil sie nicht in das universelle Schema passen wollen.
Die von uns vorgeschlagene Alternative wird nicht zu fragmentierten, isolierten und domänenorientierten Daten führen, die schwer zu entdecken sind sowie spezifisches Wissen zum Verstehen und verarbeiten benötigen. Dies wären dann auch nur wieder fragmentierte Data Warehouses, wie sie sich häufig zur Umgehung der oben genannten Probleme angestaut haben und die nun als technische Schulden weitere Innovationen behindern.
Ad 2: Sequenzierte Pipeline
Der ETL (extract, transform, load)-Dreischritt offenbart jedoch noch weitere Schwierigkeiten, die sich aus der sequentiellen Aufteilung der Funktionen ergeben. Die Motivation für das Sequenzieren der Datenverarbeitung lag in der bestehenden Arbeitsteilung der Forschungsteams.
Organisationen, die Systeme entwerfen, … sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.
– Melvyn E. Conway: Conway’s Law, 1967
Obwohl diese Gliederung ein gewisses Maß an Skalierung zu bietet scheint, da Teams verschiedenen Phasen der Verarbeitungspipeline zugewiesen werden, kommt dieser Effekt jedoch meist nicht zum Tragen, da bei neuen Features meist alle Sequenzen der Pipeline überarbeitet werden müssen.
So müssten z.B. für die Ergänzung der Strom-Ex- und Import-Daten um geplante und ungeplante Kraftwerksausfälle alle drei ETL-Bereiche angepasst werden.
Ad 3: Spezialisiertes Eigentum
Das dritte Problem hängt damit zusammen, wie die Teams strukturiert sind, die die Plattform erstellen und betreiben. Meist sind diese Teams isoliert von denjenigen, die diese Plattform für ihre Analysen und Simulationen nutzen. Sie erlangen also meist keine Kenntnis von den Datenquellen und deren Verwendung; sie sollen nur betriebliche und analytische Anforderungen erfüllen, ohne jedoch jemals ein klares Verständnis für eine konkrete Anwendung der Daten zu erhalten.
Die nächste Generation von Datenplattformen
Aus den oben angesprochenen Problemen wird deutlich, dass ein Paradigmenwechsel erforderlich ist. Ein Paradigmenwechsel, der in anderen IT-Bereichen bereits stattgefunden hat und dort bereits die Erprobungsphase verlassen hat: Domain-Driven Architecture, Self-Service-Plattforms und Product Thinking führen zu ubiquitous computing in einem vermaschten Netz (engl. Mesh).
Domain-Driven Architektur
Domänenorientierte Aufteilung und Eigentum der Datensätze
Eric Evans Buch Domain-Driven Design hat nicht nur die moderne Software-Architektur tiefgreifend beeinflusst, sondern auch die Organisationsentwicklung: Nicht nur wurden monolithische Systeme in Microservices zerlegt, auch die um Technologieschichten (Datenbank, Anwendungslogik, UI) organisierten Teams wurden umgewandelt in domänenspezifische Teams.
Bei einem solchen dezentralen Datenmanagement ist dann die Herausforderung, wie diese domänenspezifischen Daten gemeinsam genutzt werden können. Dies ist gut in Ben Stopfords Data Dichotomy-Artikel beschrieben.
Um nun eine monolithische Datenplattform zu dezentralisieren, müssen wir auch unsere Einstellung zu Ort und Eigentum dieser Daten überdenken: statt fleißig Daten in unseren eigenen, zentral gelegenen Data Lake zu übernehmen, müssen nun die Fachdomänen selbst für das Hosting dieser Daten sorgen und sie in einfach zu verarbeitender Weise zur Verfügung stellen. Dies kann dann zur Folge haben, dass wir dieselben Daten, jedoch für jede der Fachdomänen unterschiedlich aufbereitet, so auch in verschiedenen Domänen speichern.
Damit verlagert sich der Datenfluss von einem sequenzierten Pipeline-Prozess hin zu einer domänenspezifischen Aufbereitung.
Quelldomän-Datensätze
Einige Domänen richten sich natürlich nach der Herkunft der Datensätze. Meist entstehen diese Datensätze sehr nahe an der Quelle, an der die Daten entstehen. Idealerweise übernehmen die Lieferanten dieser Datensätze auch die Gewähr, dass diese hinreichend integer sind.
Note
Diese Datensätze enthalten meist nur Rohdaten, die zum Zeitpunkt der Erstellung möglichst genau wiedergeben und nicht für einen bestimmten Konsumenten angepasst oder modelliert sind.
Verbraucherorientierte und gemeinsam genutzte Datensätze
Einige Domänen bestimmen sich nicht aus der Herkunft sondern dem Ziel, das erreicht werden soll. Auch ansonsten unterscheiden sich diese Datensätze erheblich von denjenigen der Quelldomäne: Sie werden jedoch transformiert, um einen möglichst einfachen Zugriff darauf zu erlauben. Hier entsteht also eine Pipeline zur Bereinigung, Aufbereitung, Aggregation und Bereitstellung der Daten.
Self-Service-Platforms
Es gibt jedoch nicht nur innerhalb der Domänen von verbraucherorientierten Datensätzen Verarbeitungspipelines, sondern auch bereits bei Quelldomän-Datensätzen: Dort müssen die Daten auf Vollständigkeit überprüft werden und frei von Dubletten sein.
Um die Komplexität solcher Pipelines jedoch so gering wie möglich zu halten, werden sie immer nur innerhalb ihrer eigenen Domäne behandelt. Dort können dann auch Service-Levels für die Daten dieser Domäne definiert werden wie Aktualität, Fehlerraten etc.
Product Thinking
In anderen Bereichen wurden Produkte schon viel früher über Projekte gestellt, s.a. Products over Projects. Zukünftig werden die Teams einer Datendomäne den Forschungsteams ihre Funktionen als APIs zur Verfügung stellen und liefern so einen Baustein für die Schaffung höherer Funktionalitäten und Auftragswerte. Damit ein solches Produkt erfolgreich wird, müssen die Daten folgende Eigenschaften aufweisen:
Ein Datenprodukt muss leicht auffindbar sein
Eine übliche Implementierung besteht in einer Registrierung und einem Datenkatalog aller Datenprodukte mit ihren Metainformationen. Diese zentrale Anlaufstelle ermöglicht Datenkonsumenten, die Datensätze ihres Interesses leicht zu finden.
Jedes Datenprodukt muss eine eindeutige Adresse haben
Diese Adresse muss einer globalen Konvention folgen und anderen Benutzern erleichtern, programmatisch auf diese Daten zuzugreifen. Und auch wenn die zugrundeliegenden Speicher und Datenformate unterschiedlich sind, z.B. Events als Stream von Kafka Topics oder Kolumnen in Apache Parquet, so müssen diese Daten doch einheitlich adressierbar sein um Reibungsverluste beim Auffinden und Zugreifen auf diese Daten gering zu halten.
Die Daten müssen vertrauenswürdig und wahrheitsgemäß sein
Hierfür werden Service-level Objectives (SLOs) definiert und überwacht. Hierfür werden die Daten bereinigt, Dubletten entfernt und automatisiert Integritätstests durchgeführt.
Ebenso sollte die Datenherkunft (engl.: Data Lineage) als Metadaten bereitgestellt werden um die Eignung für spezielle Bedürfnisse ermitteln zu können.
Die SLOs können jedoch zwischen den einzelnen Datenprodukten variieren.
Die Semantik und Syntax sollte leicht zugänglich sein
Datenschemata sind häufig der Ausgangspunkt für die Bereitstellung von Self-Service-Datenbeständen. Daher werden sie üblicherweise zusammen mit Beispieldatensätzen leicht zugänglich veröffentlicht.
Die Daten sollten interoperabel sein
Auch wenn die Daten in einzelnen Fachdomänen verwaltet werden, so ist jedoch erklärtes Ziel, die Daten domänenübergreifend korrelieren zu können. Voraussetzung für effektive Korrelationen sind das Einhalten bestimmter Standards und Harmonisierungsregeln. Dies wird z.B. über die Definition von Feldtypen, die Identifizierung bestimmter Polyseme in verschiedenen Domänen, Adresskonventionen für Datensätze, gemeinsame Metadatenfelder, Event-Formate wie z.B. in der CloudEvents Specification) festgelegt etc.
Der Zugriff auf Produktdatensätze muss sicher sein und sollte einer globalen Zugriffskontrolle unterliegen
Hierfür können Single Sign On und Role Based Access Control verwendet werden.
Vermaschtes Netz
Domain-Driven Architecture, Self-Service-Plattforms und Product Thinking kommen zusammen in einem vermaschten Netz. Einerseits besteht dieses aus verteilten Datenprodukten, die sich an Domänen orientieren und die im Besitz unabhängiger und funktionsübergreifender Teams sind; andererseits nutzen sie eine gemeinsame Dateninfrastruktur mit einer Hosting-Plattform und ETL-Bibliotheken. Darüberhinaus wird die Vereinheitlichung von batch- und streaming-Jobs, z.B. mit Apache Beam, die problemlose Verarbeitung adressierbarer polyglotter Datensätze ermöglichen. Das Beam-Modell basiert auf dem Dataflow-Modell, mit dem sich die Logik elegant ausdrücken lässt. Zudem werden von Beam auch verschiedenste Runner unterstützt, u.a. Apache Flink, Apache Spark und Apache Samza, s.a. Beam Capability Matrix. Es ist jedoch zu beachten, dass die Runner unterschiedlichste Fähigkeiten haben und die Bereitstellung einer übergreifenden API ein schwieriges Unterfangen bleibt.
Beam hat darüberhinaus ein umfangreiches Set an eingebauten I/O-Transformationen, die einen großen Teil der Daten-Pipeline-Anforderungen abdecken dürfte. Und falls diese nicht ausreichen sollten, können auch benutzerdefinierte Transformationen definiert werden.
Zum Weiterlesen
- Eric Evans: Domain-Driven Design
ein nicht einfach zu lesendes Buch, aber die kanonische Quelle für Domain-Driven Design.
In Kapitel IV wird das Ermitteln der Domänengrenzen beschrieben.
- Vaughn Vernons: Implementing Domain-Driven Design
- konzentriert sich auf strategisches Design und erläutert in Kapitel 2 ausführlich, wie eine Domäne in begrenzte Kontexte untergliedert wird.
- William Kent: Data and Reality
- und auch wenn das Buch etwas in die Jahre gekommen ist, so ist es doch weiterhin relevant für das Datenmanagement.