Tag Archive for: Data Engineering

Data Science – Weiterbildungen mit Coursera

Anzeige

Data Science und AI sind aufstrebende Arbeitsfelder, die sich mit der Gewinnung von Wissen aus Daten beschäftigen. Die Nachfrage nach Fähigkeiten im Bereich Data Science, aber auch in angrenzenden Bereichen wie Data Engineering oder Data Analytics, ist in den letzten Jahren explodiert, da Unternehmen versuchen, die Vorteile von Big Data und künstlicher Intelligenz (KI) zu nutzen. Es lohnt sich sehr, sich in diesen Bereich weiter zu entwickeln. Dafür eignen sich die Kurse von Coursera.org.

Online-Kurse lohnen sich dann, wenn eine Karriere im Bereich der Datenanalyse oder des maschinellen Lernens angestrebt oder einfach nur ihr Wissen in diesem Bereich erweitert werden soll.

Spezialisierungskurs – Google Data Analytics

Data Science hilft dabei, Entscheidungen auf Basis von Daten zu treffen, komplexe Probleme effektiver zu lösen und Karrierechancen zu verbessern. Die Tools von Google Cloud und Jupyter Notebook sind dafür geeignet, da sie eine leistungsstarke und skalierbare Infrastruktur sowie eine interaktive Entwicklungsplattform bieten.

Google Data Analytics Zertifikatskurs

Das Google Zertifikat für Datenanalyse behandelt neben dem Handwerkszeug für jeden Data Analyst – wie etwa SQL – auch die notwendige Datenbereinigung und Datenvisualisierung mit den Tools von Google. Es werden weder Erfahrung noch Vorkenntnisse vorausgsetzt.

Spezialisierungskurs – Google Advanced Data Analytics

Der Zertifikatskurs der erweiterten Datenanalyse von Google baut auf dem zuvorgenannten Data Analytics Kurs auf, kann jedoch auch direkt besucht werden. Hier werden grundlegende Fähigkeiten wie SQL vorausgesetzt und vertiefende Fähigkeiten vermittelt, die für einen Data Analysten nützlich sind und auch in die Data Science eintauchen.

Google Advanced Data Analytics
Dieses Kursangebot zum Aufbau erweiterter Datenanalyse-Fähigkeiten von Coursera wird ebenfalls von Google angeboten. Hier werden die Tools der Datenanalyse sowie der statistischen Handwerkzeuge für Data Science eingeführt, bis hin zum ersten Einstieg in Machine Learning.


Spezialisierungskurs – SQL für Data Science (Generalistisch)

SQL ist wichtig für etablierte und angehende Data Scientists, da es eine grundlegende Technologie für die Arbeit mit Datenbanken und relationalen Datenbankmanagementsystemen ist. SQL für Data Science ermöglicht, Daten effektiv zu organisieren und schnell Abfragen zu erstellen, um Antworten auf komplexe Fragen zu finden. Es ist auch relevant für die Arbeit mit nicht-relationalen Datenbanken und hilft Data Scientists, wertvolle Erkenntnisse aus großen Datenmengen zu gewinnen.

Auch wenn Python als Skill für einen Data Scientist ganz vorne steht, ist eine Karriere als Data Scientist ohne SQL-Kenntnisse nicht vorstellbar und dieser Kurs daher der richtige, wenn Nachbolbedarf besteht.

Spezialisierungskurs – Data Analyst Zertifikat (IBM)

Eine Karriere als Data Analyst ist attraktiv, da ihr eine hohe Nachfrage am Arbeitsmarkt gegenüber steht, die Arbeit vielfältig und herausfordernd ist, viele Weiterentwicklungsmöglichkeiten (z. B. zum Data Scientist) bietet und oft flexibel ist.

Der Online-Kurs von IBM bietet die Ausbildung der beruflichen Qualifikation zum Data Analyst. Ein weiterer Vorteil dieses Kurses ist, dass er für alle geeignet ist – unabhängig von ihrem Hintergrund oder der Vorbildung. Es sind keine Abschlüsse oder Vorkenntnisse erforderlich, was bedeutet, dass jeder, der sich für das Thema interessiert, am Kurs teilnehmen und von ihm profitieren kann.

Spezialisierungskurs – Datenverarbeitung mit Python & SQL (IBM)

Dieser Kurs bietet den Teilnehmern die Möglichkeit, ihre Kenntnisse in der Datenverarbeitung zu verbessern, eine Programmiersprache wie Python zu erlernen und grundlegende Kenntnisse in SQL zu erwerben. Diese Fähigkeiten sind für die Arbeit mit Daten unerlässlich und in der heutigen Arbeitswelt sehr gefragt. Darüber hinaus bietet der Kurs für Datenverarbeitung mit Python und SQL auch Schulungen zur Analyse und Visualisierung von Daten sowie zur Erstellung von Modellen für Maschinelles Lernen. Diese Fähigkeiten sind besonders wertvoll für die Entwicklung von Anwendungen und Systemen im Bereich der KI.

Dieser Kurs ist eine großartige Möglichkeit für alle, die ihre Kenntnisse im Bereich der Datenverarbeitung und des maschinellen Lernens verbessern möchten. Zwar werden auch hier keine Vorkenntnisse vorausgesetzt, jedoch geht der Kurs inhaltlich mehr in die Richtung Data Science als der zuvorgenannte Kurs zum Data Analyst und bietet ein umfassendes Training und Schulungen zu grundlegenden Fähigkeiten, die in der heutigen Arbeitswelt gefragt sind, und ist für jeden zugänglich, unabhängig von Hintergrund oder Erfahrung.

Spezialisierungskurs – Maschinelles Lernen (DeepLearning.AI)

Das Erlernen der Grundlagen des maschinellen Lernens (Machine Learning) ist von großer Bedeutung, da es eine der am schnellsten wachsenden und wichtigsten Technologien in der heutigen Zeit ist. Maschinelles Lernen ermöglicht es Computern, aus Erfahrung zu lernen, ohne explizit programmiert zu werden. Die Teilnehmer lernen, dem Computer das lernen zu ermöglichen.

Machinelles Lernen ist der Schlüssel zur Entwicklung von Anwendungen und Systemen im Bereich der künstlichen Intelligenz (KI) und hat Anwendungen in vielen Bereichen, von der Gesundheitsversorgung und der Finanzindustrie bis hin zur Unterhaltungsbranche und der Automobilindustrie.

Der Kurs für Maschinelles Lernen ist nicht nur ein sinnvoller Einstieg in diese Materie, sondern kann darauf aufbauend mit dem Thema Deep Learning in der Qualifikation erweitert werden.

Spezialisierungskurs – Deep Learning (DeepLearning.AI)

Das Verständnis von Deep Learning ist wichtig, da es eine Unterkategorie des maschinellen Lernens ist und viele noch mächtigere Anwendungen in verschiedenen Bereichen hat. Die populäre Applikation ChatGPT ist ein Produkt des Deep Learning. Deep Learning kann mit AI gleichgesetzt werden. Es ist eine gefragte Fähigkeit auf dem Arbeitsmarkt mit Job-Garantie.

Der Spezialisierungskurs für Deep Learning steht unabhängig für sich und erfordert keine speziellen Vorkenntnisse, darf jedoch auch als sinnvolle Ergänzung zum vorgenannten Einführungskurs in Machine Learning betrachtet werden.

Weitere Kursangebote für Data & AI auf Coursera

Die Entscheidung für ein bestimmtes Thema eines Kurses in den Bereichen Data Analytics, Data Science und AI ist eine persönliche und abhängig von den eigenen Vorkenntnissen und Vorlieben, sowie den eigenen Karrierezielen. Für die Karriere des Data Analyst sind SQL sowie allgemeine Kenntnisse rund um Data Analytics bzw. Datenverarbeitung wichtig. Von einem Data Scientist wird ferner erwartet, die theoretischen Grundlagen sowie die praktische Anwendung von Machine Learning und Deep Learning als trainierte Fähigkeit abrufbar zu haben.

Weitere Kurse von Coursera zum Thema Data & AI (link).

Dieser Artikel wurde gesponsored von Coursera.
Process Mining / Process Analytics

Ist Process Mining in Summe zu teuer?

Celonis, Signavio (SAP). UiPath, Microsoft, Software AG, Mehrwerk, process.science und viele weitere Process Mining Tool-Anbieter mehr… der Markt rund um Process Mining ist stark umkämpft. Trotz der hohen Vielfalt an Tools, gilt Process Mining in der Einführung und Durchführung als teuer. Viele Unternehmen verzeichnen zwar erste Erfolge mit dieser Analysemethodik und den dafür geschaffenen Tools, hadern jedoch mit den hohen Kosten für Lizensierung und Betrieb.

Process Mining / Process AnalyticsDabei gibt es viele Hebel für Unternehmen, die Kosten für diese Analysen deutlich zu reduzieren, dabei gesamtheitlicher analysieren zu können und sich von einzelnen Tool-Anbietern unabhängiger zu machen. Denn die Herausforderung beginnt bereits mit denen eigentlichen Zielen von Process Mining für ein Unternehmen, und diese sind oft nicht einmal direkt finanziell messbar.

Process Mining bitte nicht nur auf Prozesskosten reduzieren

Tool-Anbieter werben tendenziell besonders mit der potenziellen Reduktion von Prozesskosten und und mit der Working Capital Optimierung. Bei hohen Lizenzierungskosten für die Tools, insbesondere für die Cloud-Lösungen der Marktführer, ist dies die erfolgversprechendste Marketing-Strategie. Typische Beispiele für die Identifikation von Kostensenkungspotenzialen sind Doppelarbeiten und unnötige Prozessschleifen sowie Wartezeiten in Prozessen. Working Capital- und Cash- Kosten sind in den Standardprozessen Order-to-Cash (z. B. Verspätete Zahlungen) und Procure-to-Pay (z. B. zu späte Zahlungen, nicht realisierte Rabatte) zu finden.

Diese Anwendungsfälle sind jedoch analytisch recht trivial und bereits mit einfacher BI (Business Intelligence) oder dedizierten Analysen ganz ohne Process Mining bereits viel schneller aufzuspüren. Oft bieten bereits ERP-Systeme eine eigene Erkennung hierfür an, die sich mit einfach gestrikter BI leicht erweitern lässt.

Richtige Wirkung, die so eigentlich nur Process Mining mit der visuellen Prozessanalyse erzeugen kann, zeigt sich vor allem bei der qualitativen Verbesserung von Prozessen, denn oft frustrieren eingefahrene Unternehmensprozesse nicht nur Mitarbeiter, Lieferanten und Partner, sondern auch Kunden. Dabei geht es z. B. um die Verbesserung von Prozessen in der Fertigung und Montage, in der Logistik, dem Einkauf, Sales und After Sales. Diese Anwendungszwecke dienen zur zeitlichen Beschleunigung oder Absicherung (Stabilisierung) von Prozessen, und damit zur Erhöhung des Kundennutzens. Jede qualitative Verbesserung wird sich letztendlich auch im quantitativen, finanziellen Maße auswirken, wenn auch nicht so einfach messbar.

Die Absicherung von Prozessen aus der Compliance-Perspektive ist eines der typischen Einsatzgebiete, für die Process Mining prädestiniert ist. Audit Analytics und Betrugserkennung gehören zu den häufigsten Anwendungsgebieten. Das senkt zwar grundsätzlich keine Prozesskosten, ist jedoch in Anbetracht immer komplexerer Prozessketten bittere Notwendigkeit.

Prozess Mining kann ferner auch zur Dokumentation von Geschäftsprozessen genutzt werden, als Vorlage für Sollprozesse. Die Analyse von bestehenden Prozessen kann dann dabei helfen, den aktuellen Zustand eines Prozesses zu dokumentieren und Unternehmen können diese Informationen nutzen, um Prozessdokumentationen zu aktualisieren und zu verbessern. Mit Process Mining können Vor- und Nachher-Vergleiche durchgeführt sowie situative Worst- und Best-Practise herausextrahiert werden. Dies bietet sich insbesondere vor und nach Migrationen von ERP-Systemen an.

Process Mining muss nicht (zu) teuer sein

Bei hohen Kosten für Process Mining ist der Druck einer Organisation sehr hoch, diese Kosten irgendwie mit hohen potenziellen (!) Einsparungen zu rechtfertigen. Die Prozesse mit dem höchsten Kostensenkungsversprechen erhalten dadurch den Vorzug, oft auch dann, obwohl andere Prozesse die nötige Prozesstransparenz eigentlich noch viel nötiger hätten.

Zumindest der Einstieg in Process Mining kann mit den richtigen Tools sehr leichtfüßig und günstig erfolgen, aber auch die Etablierung dieser Analysemethodik im weltweiten Konzern kann mit einigen Stellhebeln erheblich günstiger und (in Anbetracht der hohen Dynamik unter den Tool-Anbietern) nachhaltiger realisiert werden, als wie es von den größeren Anbietern vorgeschlagen wird.

Unabhängiges und Nachhaltiges Data Engineering

Die Arbeit hinter Process Mining kann man sich wie einen Eisberg vorstellen. Die sichtbare Spitze des Eisbergs sind die Reports und Analysen im Process Mining Tool. Das ist der Teil, den die meisten Analysten und sonstigen Benutzer des Tools zu Gesicht bekommen. Der andere Teil des Process Minings ist jedoch noch viel wesentlicher, denn es handelt sich dabei um das Fundament der Analyse: Die Datenmodellierung des Event Logs. Diese Arbeit ist der größere, jedoch unter der Oberfläche verborgene Teil des Eisbergs.

Jedes Process Mining Tool benötigt pro Use Case mindestens ein Event Log. Dabei handelt es sich um ein Prozessprotokoll mit universeller Mindestanforderung: Case, Activity, Timestamp

Diese Event Logs in einem Process Mining Tool zu modellieren und individuell anzupassen, ist langfristig keine gute Idee und erinnert an die Anfänge der Business Intelligence, als BI-Analysten Daten direkt in Tools wie Qlik Sense oder Power BI luden und für sich individuell modellierten.

Wie anfangs erwähnt, haben Unternehmen bei der Einführung von Process Mining die Qual der Wahl. Oft werden langwierige und kostenintensive Auswahlprozesse für die jeweiligen Tools angestoßen, damit die Wahl auf der augenscheinlich richtige Tool fällt.

Eine bessere Idee ist es daher, Event Logs nicht in einzelnen Process Mining Tools aufzubereiten, sondern zentral in einem dafür vorgesehenen Data Warehouse zu erstellen, zu katalogisieren und darüber auch die grundsätzliche Data Governance abzusichern. Die modellierten Daten können dann jedem Process Mining Tool zur Verfügung gestellt werden. Während sich Process Mining Tools über die Jahre stark verändern, bleiben Datenbanktechnologien für Data Warehousing über Jahrzehnte kompatibel und können in ihnen aufbereitete Event Logs allen Tools zur Verfügung stellen. Und übrigens lässt sich mit diesem Ansatz auch sehr gut eine gesamtheitlichere Verknüpfung realisieren und die Perspektive dynamisch verändern, was neuerdings als Object-centric Process Mining beworben wird, mit der richtigen Datenmoedellierung in einem Process Mining Data Warehouse für jedes Tool zu erreichen ist.

Nicht alles um jeden Preis in die Public Cloud

Unter der häufigen Prämisse, dass alle ERP-Rohdaten in eine Cloud geladen werden müssen, entstehen Kosten, die durchaus als überhöht und unnötig angesehen werden können. Daten-Uploads in eine Cloud-Lösung für Process Mining sollten nach Möglichkeit minimal ausfallen und lassen sich durch genaueres Anforderungsmanagement in den meisten Fällen deutlich reduzieren, verbunden mit Einsparungen bei Cloud-Kosten. Idealerweise werden nur fertige Event-Logs bzw. objekt-zentrische Datenmodelle in die Cloud geladen, nicht jedoch die dafür notwendigen Rohdaten.

Für besonders kritische Anwendungsfälle kann es von besonderem Stellenwert sein, einen Hybrid-Cloud-Ansatz anzustreben. Dabei werden besonders kritische Daten in ihrer granularen Form in einer Private Cloud (i.d.R. kundeneigenes Rechenzentrum) gehalten und nur die fertigen Event Logs in die Public Cloud (z. B. Celonis Process Mining) übertragen.

Mit AI ist mehr möglich als oft vermutet

Neben den einfachen Anwendungsfällen, die einige Tool-Anbieter bereits eingebaut haben (z. B. Matching von Zahlungsdaten zur Doppelzahlungserkennung oder die Vorhersage von Prozesszeiten), können mit Machine Learning bzw. Deep Learning auch anspruchsvollere Varianten-Cluster und Anomalien erkannt werden.

Unstrukturierte Daten können dank AI in Process Mining mit einbezogen werden, dazu werden mit Named Entity Recognition (NER, ein Teilgebiet des NLP) Vorgänge und Aktivitäten innerhalb von Dokumenten (z. B. Mails, Jira-Tickets) extrahiert und gemeinsam mit den Meta-Daten (z. B. Zeitstempel aus dem Dokument) in ein strukturiertes Event Log für Process Mining transformiert. Ähnliches lässt sich mit AI für Computer Vision übrigens auch auf Abläufe aus Videoaufnahmen durchführen. Dank AI werden damit noch viel verborgenere Prozesse sichtbar. Diese AI ist in noch keiner Process Mining Software zu finden, kann jedoch bausteinartig dem Process Mining Data Warehouse vorgeschaltet werden.

Fazit

Nicht all zu selten ist Process Mining den anwenden Unternehmen in Summe zu teuer, denn bereits einige Unternehmen sind über die Kosten gestolpert. Andere Unternehmen begrenzen die Kosten mit dem restriktiven Umgang mit Benuter-Lizenzen oder Anwendungsfällen, begrenzen damit jedoch auch den Analyseumfang und schöpfen nicht das volle Potenzial aus. Dies muss jedoch nicht sein, denn Kosten für Data Loads, Cloud-Hosting und Benutzerlizenzen für Process Mining lassen sich deutlich senken, wenn Process Mining als die tatsächliche Analyse-Methode verstanden und nicht auf ein bestimmtes Tool reduziert wird.

Zu Beginn kann es notwendig sein, Process Mining in einer Organisation überhaupt erst an den Start zu bringen und erste Erfolge zu erzielen. Unternehmen, die Process Mining und die damit verbundene Wirkung in Sachen Daten- und Prozesstransparenz, erstmals erlebt haben, werden auf diese Analysemethodik so schnell nicht mehr verzichten wollen. Schnelle erste Erfolge lassen sich mit nahezu jedem Tool erzielen. Nach Pilot-Projekten sollte der konzernweite Rollout jedoch in Sachen Performance, Kosten-Leistungsverhältnis und spätere Unabhängigkeit überdacht werden, damit Process Mining Initiativen langfristig mehr wirken als sie kosten und damit Process Mining auch bedenkenlos und ohne Budget-Engpässe qualitative Faktoren der Unternehmensprozesse verbessern kann.

Mit den richtigen Überlegungen fahren Sie die Kosten für Process Mining runter und den Nutzen hoch.

Interview Benjamin Aunkofer - Datenstrategien und Data Teams entwickeln!

Interview – Datenstrategie und Data Teams entwickeln!

Das Format Business Talk am Kudamm in Berlin führte ein drittes Interview mit Benjamin Aunkofer zum Thema “Datenstrategie und Data Team Organisation”.

In dem Interview erklärt Benjamin Aunkofer, was Unternehmen Datenstrategien entwickeln, um Ihren Herausforderungen gerecht zu werden. Außerdem gibt er Tipps, wie Unternehmen ein fähiges Data Team aufbauen, qualifizieren und halten.

Nachfolgend das Interview auf Youtube sowie die schriftliche Form zum Nachlesen:


Interview – Datenstrategien und Aufbau von Data Teams

  1. Herr Aunkofer, Sie unterstützen Unternehmen u.a. bei der Entwicklung von Datenstrategien und dem Aufbau von Data Teams. Was genau ist denn eine Datenstrategie?Eine Datenstrategie ist eine Strategie über die Nutzung von Daten zur Geschäftsoptimierung. Man kann auch sagen: Eine Datenstrategie ist ein Business Plan darüber, wie Daten richtig im Unternehmen genutzt werden sollen.Abgesehen vom Aufbau neuer eigener Geschäftsmodelle mit Daten, können grundsätzlich drei Faktoren im Unternehmen mit der Nutzung von Daten optimiert werden.1. Umsätze, also die Erhöhung der Umsätze durch bessere Produkte oder durch besseres Verständnis der Kunden
    2. Die Reduktion von Kosten und
    3. die verbesserte Risikoerkennung und -bewertung, z. B. in der Wirtschaftsprüfung.Eine Datenstrategie ist abgerichtet auf die Unternehmensziele und ist der Masterplan dafür, diese auch zu erreichen.
  2. Und was sind die typischen Ziele mit denen Kunden an Sie herantreten?Das hängt stark von der Branche ab, also Handelsunternehmen wollen vor allem die Kunden besser verstehen, Marketing besser ausrichten oder auch Produkte verbessern. Immobilienunternehmen wollen stets DIE Markttransparenz für sich und industrielle Unternehmen, also Maschinenbau, Zulieferer, Pharma usw. wollen meistens intelligente Produkte, oder mehr noch, schlanke Prozesse zur Kosteneinsparung, aber auch, um mehr Umsatz zu machen, denn Schnelligkeit heißt Wettbewerbsfähigkeit.Am Ende ist das aber auch alles sehr individuell von Unternehmen zu Unternehmen.
  3. Die Entwicklung einer Datenstrategie erfordert sicherlich ein systematisches Vorgehen. Was sind die wichtigsten Schritte?Ja genau, wir haben da eine generelle Vorgehensweise. Verkürzt erläutert, in fünf Schritten, wollen wir zu Anfang erstmal die Unternehmensvision für die nächste Zeit wissen und diese, wenn nicht schon gegeben, in klare Unternehmensziele herunter gebrochen haben. Das ist der erste und wichtigste Schritt.Weil, wenn wir das haben, dann können wir die dafür relevanten Daten und Datenquellen identifizieren. Das sind vielleicht unternehmensinterne Daten aus den IT-Systemen, ERP, CRM usw. und manchmal auch noch Daten aus unternehmensexternen Quellen, z. B. aus dem Social Media, Marktplattformen, Open Data usw. In manchen Fällen dreht sich auch alles nur um interne oder nur um externe Daten. Auch prüfen wir natürlich, ob Daten erst noch generiert oder gesammelt werden müssen und wie es um den rechtlichen Rahmen bzgl. der Nutzung steht. Das war der zweite Schritt.Wenn die relevanten Datenquellen identifiziert sind, sind im dritten Schritt die richtigen Methoden der Datennutzung auszumachen, z. B. der Aufbau einer Datenplattform, vielleicht ein Data Warehouse zur Datenkonsolidierung, Process Mining zur Prozessanalyse oder Predictive Analytics für den Aufbau eines bestimmten Vorhersagesystems, KI zur Anomalieerkennung oder je nach Ziel etwas ganz anderes.Der vierte Schritt ist die Überlegung, wie das ganze organisatorisch gelöst werden soll, also z. B. über eine zentrale verantwortliche Stelle im Unternehmen oder dezentral in bestimmten Fachabteilungen? Stehen die dafür richtigen Mitarbeiter zur Verfügung? Müssen Qualifizierungsmaßnahmen getroffen werden? Im Grunde kennt das wohl jeder, dass Unternehmen einfach z. B. ein Tool eingeführt haben, dass dann aber nicht genutzt wird. Dies müssen wir zu verwenden wissen.Tja und wenn das auch erledigt ist, muss das alles nur nochmal aufgeschrieben und in eine Planung mit Meilensteinen gebracht werden. Budgets, Staffing, Make or Buy usw. kommt da alles rein. Und voila, dann haben wir unsere Datenstrategie.
  4. Unterstützen Sie auch bei der Umsetzung der Datenstrategien?Ja klar, schon viel gemacht, sogar in verschiedensten Branchen. Diese Arbeit macht sogar großen Spaß für alle Beteiligten und es gibt nichts Spannenderes, als diesen Plan in die Zukunft zu gestalten.
  5. Sie arbeiten nicht nur als externer Dienstleister, sondern bietet auch Hilfestellung beim Aufbau und der Ausbildung eigener Data Teams. Welche Weiterbildungsformate bieten Sie an?Also wenn es hier einen Fachkräftemangel gibt, dann definitiv bei den Datenexperten. Übrigens nicht mehr so stark bei den Data Scientists, auch wenn richtig gute Mitarbeiter ebenfalls rar gesät sind, den größten Bedarf haben Unternehmen eher bei den Data Engineers. Das sind die Kollegen, die die Data Warehouses oder Data Lakes aufbauen und pflegen.Es gibt aber viele junge Leute, die da gerne einsteigen wollen. Das Problem auf der anderen Seite ist jedoch, dass Unternehmen natürlich eher erfahrene Leute suchen, die schneller und besser mit den großen Praxisproblemen klarkommen, die in den Datenarchitekturen sich nun mal so einschleichen. Diese erfahrenen Experten sind aber schwer zu finden und Stellen daher meistens sehr lange unbesetzt, oder dann mit Mitarbeitern, die kein Deutsch sprechen können.Wo wir von DATANOMIQ helfen können: Durch uns als Coach können Unternehmen auf ihrer Suche dem DEM Superexperten auch einfach günstigere, unerfahrene, aber motivierte Leute einstellen. Motivation der Mitarbeiter ist nicht zu unterschätzen! Als externer Dienstleister können wir dann unterstützen und schulen zu gleich. Und das machen wir über drei verschiedene Stufen:Trainings, Workshops und Coachings.Beim Training arbeiten wir mit Didaktik. Die Daten sind einfach gehalten und beispielhaft, denn wir möchten nicht zu lange über sie reden, sondern über die richtige Methodik der Datenaufbereitung oder Datenanalyse.Beim Workshop behandeln wir das reale Problem mit den echten Daten, mit denen der Mitarbeiter im Unternehmen konfrontiert ist. Hier schauen wir erstmal gemeinsam blöd aus der Wäsche, aber erarbeiten uns dann gemeinsam zügig die Lösung.

    Und beim Coaching schauen wir dann eigentlich nur zu und geben Ratschläge, wie man besser an die Aufgabenstellung herangehen könnte. Der Mitarbeiter hat also selbst das Zepter in der Hand und das Doing.Wir sind dann nur der Support.

    So können wir Stellen schnell besetzen und niemand muss Sorge haben, dass die Kompetenz nicht ausreicht. Auf diese Weise habe ich schon mehrere Data Teams für Kunden aufgebaut und parallel natürlich auch mein eigenes.

 

Sehen Sie die zwei anderen Video-Interviews von Benjamin Aunkofer:

 

 

 

 

 

 


 

Jobprofil des Data Engineers

Warum Data Engineering der Data Science in Bedeutung und Berufschancen längst die Show stiehlt, dabei selbst ebenso einem stetigen Wandel unterliegt.

Was ein Data Engineer wirklich können muss

Der Data Scientist als sexiest Job des 21. Jahrhunderts? Mag sein, denn der Job hat seinen ganz speziellen Reiz, auch auf Grund seiner Schnittstellenfunktion zwischen Technik und Fachexpertise. Doch das Spotlight der kommenden Jahre gehört längst einem anderen Berufsbild aus der Datenwertschöpfungskette – das zeigt sich auch bei den Gehältern.

Viele Unternehmen sind gerade auf dem Weg zum Data-Driven Business, einer Unternehmensführung, die für ihre Entscheidungen auf transparente Datengrundlagen setzt und unter Einsatz von Business Intelligence, Data Science sowie der Automatisierung mit Deep Learning und RPA operative Prozesse so weit wie möglich automatisiert. Die Lösung für diese Aufgabenstellungen werden oft vor allem bei den Experten für Prozessautomatisierung und Data Science gesucht, dabei hängt der Erfolg jedoch gerade viel eher von der Beschaffung valider Datengrundlagen ab, und damit von einer ganz anderen entscheidenden Position im Workflow datengetriebener Entscheidungsprozesse, dem Data Engineer.

Data Engineer, der gefragteste Job des 21sten Jahrhunderts?

Der Job des Data Scientists hingegen ist nach wie vor unter Studenten und Absolventen der MINT-Fächer gerade so gefragt wie nie, das beweist der tägliche Ansturm der vielen Absolventen aus Studiengängen rund um die Data Science auf derartige Stellenausschreibungen. Auch mangelt es gerade gar nicht mehr so sehr an internationalen Bewerben mit Schwerpunkt auf Statistik und Machine Learning. Der solide ausgebildete und bestenfalls noch deutschsprachige Data Scientist findet sich zwar nach wie vor kaum im Angebot, doch insgesamt gute Kandidaten sind nicht mehr allzu schwer zu finden. Seit Jahren sind viele Qualifizierungsangebote für Studenten sowie Arbeitskräfte am Markt auch günstig und ganz flexibel online verfügbar, ohne dabei Abstriche bei beim Ansehen dieser Aus- und Fortbildungsmaßnahmen in Kauf nehmen zu müssen.

Was ein Data Scientist fachlich in Sachen Expertise alles abdecken muss, hatten wir ganz ausführlich über Betrachtung des Data Science Knowledge Stack besprochen.

Doch was bringt ein Data Scientist, wenn dieser gar nicht über die Daten verfügt, die für seine Aufgaben benötigt werden? Sicherlich ist die Aufgabe eines jeden Data Scientists auch die Vorbereitung und Präsentation seiner Vorhaben. Die Heranschaffung und Verwaltung großer Datenmengen in einer Enterprise-fähigen Architektur ist jedoch grundsätzlich nicht sein Schwerpunkt und oft fehlen ihm dafür auch die Berechtigungen in einer Enterprise-IT. Noch konkreter wird der Bedarf an Datenbeschaffung und -aufbereitung in der Business Intelligence, denn diese benötigt für nachhaltiges Reporting feste Strukturen wie etwa ein Data Warehouse.

Das Profil des Data Engineers: Big Data High-Tech

Auch wenn Data Engineering von Hochschulen und Fortbildungsanbietern gerade noch etwas stiefmütterlich behandelt werden, werden der Einsatz und das daraus resultierende Anforderungsprofil eines Data Engineers am Markt recht eindeutig skizziert. Einsatzszenarien für diese Dateningenieure – auch auf Deutsch eine annehmbare Benennung – sind im Kern die Erstellung von Data Warehouse und Data Lake Systeme, mittlerweile vor allem auf Cloud-Plattformen. Sie entwickeln diese für das Anzapfen von unternehmensinternen sowie -externen Datenquellen und bereiten die gewonnenen Datenmengen strukturell und inhaltlich so auf, dass diese von anderen Mitarbeitern des Unternehmens zweckmäßig genutzt werden können.

Enabler für Business Intelligence, Process Mining und Data Science

Kein Data Engineer darf den eigentlichen Verbraucher der Daten aus den Augen verlieren, für den die Daten nach allen Regeln der Kunst zusammengeführt, bereinigt und in das Zielformat gebracht werden sollen. Klassischerweise arbeiten die Engineers am Data Warehousing für Business Intelligence oder Process Mining, wofür immer mehr Event Logs benötigt werden. Ein Data Warehouse ist der unter Wasser liegende, viel größere Teil des Eisbergs der Business Intelligence (BI), der die Reports mit qualifizierten Daten versorgt. Diese Eisberg-Analogie lässt sich auch insgesamt auf das Data Engineering übertragen, der für die Endanwender am oberen Ende der Daten-Nahrungskette meistens kaum sichtbar ist, denn diese sehen nur die fertigen Analysen und nicht die dafür vorbereiteten Datentöpfe.

Abbildung 1 - Data Engineering ist der Mittelpunkt einer jeden Datenplattform. Egal ob für Data Science, BI, Process Mining oder sogar RPA, die Datenanlieferung bedingt gute Dateningenieure, die bis hin zur Cloud Infrastructure abtauchen können.

Abbildung 1 – Data Engineering ist der Mittelpunkt einer jeden Datenplattform. Egal ob für Data Science, BI, Process Mining oder sogar RPA, die Datenanlieferung bedingt gute Dateningenieure, die bis hin zur Cloud Infrastructure abtauchen können.

Datenbanken sind Quelle und Ziel der Data Engineers

Daten liegen selten direkt in einer einzigen CSV-Datei strukturiert vor, sondern entstammen einer oder mehreren Datenbanken, die ihren eigenen Regeln unterliegen. Geschäftsdaten, beispielsweise aus ERP- oder CRM-Systemen, liegen in relationalen Datenbanken vor, oftmals von Microsoft, Oracle, SAP oder als eine Open-Source-Alternative. Besonders im Trend liegen derzeitig die Cloud-nativen Datenbanken BigQuery von Google, Redshift von Amazon und Synapse von Microsoft sowie die cloud-unabhängige Datenbank snowflake. Dazu gesellen sich Datenbanken wie der PostgreSQL, Maria DB oder Microsoft SQL Server sowie CosmosDB oder einfachere Cloud-Speicher wie der Microsoft Blobstorage, Amazon S3 oder Google Cloud Storage. Welche Datenbank auch immer die passende Wahl für das Unternehmen sein mag, ohne SQL und Verständnis für normalisierte Daten läuft im Data Engineering nichts.

Andere Arten von Datenbanken, sogenannte NoSQL-Datenbanken beruhen auf Dateiformaten, einer Spalten- oder einer Graphenorientiertheit. Beispiele für verbreitete NoSQL-Datenbanken sind MongoDB, CouchDB, Cassandra oder Neo4J. Diese Datenbanken exisiteren nicht nur als Unterhaltungswert gelangweilter Nerds, sondern haben ganz konkrete Einsatzgebiete, in denen sie jeweils die beste Performance im Lesen oder Schreiben der Daten bieten.

Ein Data Engineer muss demnach mit unterschiedlichen Datenbanksystemen zurechtkommen, die teilweise auf unterschiedlichen Cloud Plattformen heimisch sind.

Data Engineers brauchen Hacker-Qualitäten

Liegen Daten in einer Datenbank vor, können Analysten mit Zugriff einfache Analysen bereits direkt auf der Datenbank ausführen. Doch wie bekommen wir die Daten in unsere speziellen Analyse-Tools? Hier muss der Engineer seinen Dienst leisten und die Daten aus der Datenbank exportieren können. Bei direkten Datenanbindungen kommen APIs, also Schnittstellen wie REST, ODBC oder JDBC ins Spiel und ein guter Data Engineer benötigt Programmierkenntnisse, bevorzugt in Python, diese APIs ansprechen zu können. Etwas Kenntnis über Socket-Verbindungen und Client-Server-Architekturen zahlt sich dabei manchmal aus. Ferner sollte jeder Data Engineer mit synchronen und asynchronen Verschlüsselungsverfahren vertraut sein, denn in der Regel wird mit vertraulichen Daten gearbeitet. Ein Mindeststandard an Sicherheit gehört zum Data Engineering und darf keinesfalls nur Datensicherheitsexperten überlassen werden, eine Affinität zu Netzwerksicherheit oder gar Penetration-Testing ist positiv zu bewerten, mindestens aber ein sauberes Berechtigungsmanagement gehört zu den Grundfähigkeiten. Viele Daten liegen nicht strukturiert in einer Datenbank vor, sondern sind sogenannte unstrukturierte oder semi-strukturierte Daten aus Dokumenten oder aus Internetquellen. Mit Methoden wie Data Web Scrapping und Data Crawling sowie der Automatisierung von Datenabrufen beweisen herausragende Data Engineers sogar echte Hacker-Qualitäten.

Dirigent der Daten: Orchestrierung von Datenflüssen

Eine der Kernaufgaben des Data Engineers ist die Entwicklung von ETL-Strecken, um Daten aus Quellen zu Extrahieren, zu in das gewünschte Zielformat zu Transformieren und schließlich in die Zieldatenbank zu Laden. Dies mag erstmal einfach klingen, wird jedoch zur echten Herausforderung, wenn viele ETL-Prozesse sich zu ganzen ETL-Ketten und -Netzwerken zusammenfügen, diese dabei trotz hochfrequentierter Datenabfrage performant laufen müssen. Die Orchestrierung der Datenflüsse kann in der Regel in mehrere Etappen unterschieden werden, von der Quelle ins Data Warehouse, zwischen den Ebenen im Data Warehouse sowie vom Data Warehouse in weiterführende Systeme, bis hin zum Zurückfließen verarbeiteter Daten in das Data Warehouse (Reverse ETL).

Hart an der Grenze zu DevOp: Automatisierung in Cloud-Architekturen

In den letzten Jahren sind Anforderungen an Data Engineers deutlich gestiegen, denn neben dem eigentlichen Verwalten von Datenbeständen und -strömen für Analysezwecke wird zunehmend erwartet, dass ein Data Engineer auch Ressourcen in der Cloud managen, mindestens jedoch die Datenbanken und ETL-Ressourcen. Darüber hinaus wird zunehmend jedoch verlangt, IT-Netzwerke zu verstehen und das ganze Zusammenspiel der Ressourcen auch als Infrastructure as Code zu automatisieren. Auch das automatisierte Deployment von Datenarchitekturen über CI/CD-Pipelines macht einen Data Engineer immer mehr zum DevOp.

Zukunfts- und Gehaltsaussichten

Im Vergleich zum Data Scientist, der besonders viel Methodenverständnis für Datenanalyse, Statistik und auch für das zu untersuchende Fachgebiet benötigt, sind Data Engineers mehr an Tools und Plattformen orientiert. Ein Data Scientist, der Deep Learning verstanden hat, kann sein Wissen zügig sowohl mit TensorFlow als auch mit PyTorch anwenden. Ein Data Engineer hingegen arbeitet intensiver mit den Tools, die sich über die Jahre viel zügiger weiterentwickeln. Ein Data Engineer für die Google Cloud wird mehr Einarbeitung benötigen, sollte er plötzlich auf AWS oder Azure arbeiten müssen.

Ein Data Engineer kann in Deutschland als Einsteiger mit guten Vorkenntnissen und erster Erfahrung mit einem Bruttojahresgehalt zwischen 45.000 und 55.000 EUR rechnen. Mehr als zwei Jahre konkrete Erfahrung im Data Engineering wird von Unternehmen gerne mit Gehältern zwischen 50.000 und 80.000 EUR revanchiert. Darüber liegen in der Regel nur die Data Architects / Datenarchitekten, die eher in großen Unternehmen zu finden sind und besonders viel Erfahrung voraussetzen. Weitere Aufstiegschancen für Data Engineers sind Berater-Karrieren oder Führungspositionen.

Wer einen Data Engineer in Festanstellung gebracht hat, darf sich jedoch nicht all zu sicher fühlen, denn Personalvermittler lauern diesen qualifizierten Fachkräften an jeder Ecke des Social Media auf. Gerade in den Metropolen wie Berlin schaffen es längst nicht alle Unternehmen, jeden Data Engineer über Jahre hinweg zu beschäftigen. Bei der großen Auswahl an Jobs und Herausforderungen fällt diesen Datenexperten nicht schwer, seine Gehaltssteigerungen durch Jobwechsel proaktiv voranzutreiben.

6 Steps of Process Mining – Infographic

Many Process Mining projects mainly revolve around the selection and introduction of the right Process Mining tools. Relying on the right tool is of course an important aspect in the Process Mining project. Depending on whether the process analysis project is a one-time affair or daily process monitoring, different tools are pre-selected. Whether, for example, a BI system has already been established and whether a sophisticated authorization concept is required for the process analyzes also play a role in the selection, as do many other factors.

Nevertheless, it should not be forgotten that process mining is not primarily a tool, but an analysis method, in which the first part is about the reconstruction of the processes from operational IT systems in a resulting process log (event log), the second step is about a (core) graph analysis to visualize the process flows with additional analysis/reporting elements. If this perspective on process mining is not lost sight of, companies can save a lot of costs because it allows them to concentrate on solution-oriented concepts.

However, completely independent of the tools, there is a very general procedure in this data-driven process analysis you should understand and which we would like to describe with the following infographic:

DATANOMIQ Process Mining - 6 Steps of Doing Process Mining Analysis

6 Steps of Process Mining – Infographic PDF Download.

Interested in introducing Process Mining to your organization? Do not hesitate to get in touch with us!

DATANOMIQ is the independent consulting and service partner for business intelligence, process mining and data science. We are opening up the diverse possibilities offered by big data and artificial intelligence in all areas of the value chain. We rely on the best minds and the most comprehensive method and technology portfolio for the use of data for business optimization.

Die 6 Schritte des Process Mining – Infografik

Viele Process Mining Projekte drehen sich vor allem um die Auswahl und die Einführung der richtigen Process Mining Tools. Egal ob mit Celonis, Signavio, UiPath oder einem anderem Software-Anbieten, Process Mining ist nicht irgendein Tool, sondern eine Methodik der Aufbereitung und Analyse der Daten. Im Kern von Process Mining steckt eigentlich eine Graphenanalyse, die Prozessschritte als Knoten (Event) und Kanten (Zeiten) darstellt. Hinzu kommen weitere Darstellungen mit einem fließenden Übergang in die Business Intelligence, so bieten andere Tool-Anbieter auch Plugins für Power BI, Tableau, Qlik Sense und andere BI-Tools, um Process Mining zu visualisieren.

Unternehmen können Event Logs selbst herstellen und in ein Data Warehouse speisen, die dann alle Process Mining Tools mit Prozessdaten versorgen können. Die investierten Aufwände in Process Mining würden somit nachhaltiger (weil länger nutzbar) werden und die Abhängigkeit von bestimmter Software würde sich auf ein Minimum reduzieren, wir riskieren keinen neuen Aufwand für Migration von einem Anbieter zum nächsten. Übrigens können die Event Logs dann auch in andere Tools z. B. für Business Intelligence (BI) geladen und anderweitig analysiert werden.

Jedoch ganz unabhängig von den Tools, gibt es eine ganz generelle Vorgehensweise in dieser datengetriebenen Prozessanalyse, die wir mit der folgenden Infografik beschreiben möchten.

DATANOMIQ Process Mining - 6 Steps of Doing Process Mining Analysis

6 Steps of Process Mining – Infographic PDF Download.

DATANOMIQ ist der herstellerunabhängige Beratungs- und Service-Partner für Business Intelligence, Process Mining und Data Science. Wir erschließen die vielfältigen Möglichkeiten durch Big Data und künstliche Intelligenz erstmalig in allen Bereichen der Wertschöpfungskette. Dabei setzen wir auf die besten Köpfe und das umfassendste Methoden- und Technologieportfolio für die Nutzung von Daten zur Geschäftsoptimierung.

5 Apache Spark Best Practices

Already familiar with the term big data, right? Despite the fact that we would all discuss Big Data, it takes a very long time before you confront it in your career. Apache Spark is a Big Data tool that aims to handle large datasets in a parallel and distributed manner. Apache Spark began as a research project at UC Berkeley’s AMPLab, a student, researcher, and faculty collaboration centered on data-intensive application domains, in 2009. 

Introduction

Spark’s aim is to create a new framework that was optimized for quick iterative processing, such as machine learning and interactive data analysis while retaining Hadoop MapReduce’s scalability and fault-tolerant. Spark outperforms Hadoop in many ways, reaching performance levels that are nearly 100 times higher in some cases. Spark has a number of components for various types of processing, all of which are based on Spark Core. Today we will be going to discuss in brief the Apache  Spark and 5 of its best practices to look forward to-

What is Apache Spark?

Apache Spark is an open-source distributed system for big data workforces. For fast analytic queries against another size of data, it uses in-memory caching and optimised query execution. It is a parallel processing framework for grouped computers to operate large-scale data analytics applications. This could handle packet and real-time data processing and predictive analysis workloads.

It claims to support code reuse all over multiple workloads—batch processing, interactive queries, real-time analytics, machine learning, and graph processing—and offers development APIs in Java, Scala, Python, and R. With 365,000 meetup members in 2017, Apache Spark is becoming one of the most renowned big data distributed processing frameworks. Explore for Apache Spark Tutorial for more information.

5 best practices of Apache Spark

1. Begin with a small sample of the data.

Because we want to make big data work, we need to start with a small sample of data to see if we’re on the right track. In my project, I sampled 10% of the data and verified that the pipelines were working properly. This allowed me to use the SQL section of the Spark UI to watch the numbers grow throughout the flow while not having to wait too long for it to complete.

In my experience, if you attain your preferred runtime with a small sample, scaling up is usually simple.

2. Spark troubleshooting

For transformations, Spark seems to have a lazy loading behaviour. That is, it will not initiate the transformation computation; instead, it will keep records of the transformation requested. This makes it difficult to determine where in our code there are bugs or areas that need to be optimised. Splitting the code into sections with df.cache() and then using df.count() to force Spark to calculate the df at every section was one practise that we found useful.

Spark actions seem to be keen in that they cause the underlying action to perform a computation. So, if you’ve had a Spark action which you only call when it’s required, pay attention. A Spark action, for instance, is count() on a dataset. You can now inspect the computation of each section using the spark UI and identify any issues. It’s important to note that if you don’t use the sampling we mentioned in (1), you’ll probably end up with a very long runtime that’s difficult to debug.

Check out Apache Spark Training & Certification Course to get yourself certified in Apache Spark with industry-level skills.

3. Finding and resolving Skewness is a difficult task.

Having to look at the stage specifics in the spark UI and looking for just a major difference between both the max and median can help you find the Skewness:

Let’s begin with a definition of Skewness. As previously stated, our data is divided into partitions, and the size of each partition will most likely change as the progress of transformation. This can result in a large difference in size between partitions, indicating that our data is skew. This implies that a few of the tasks were markedly slower than the rest.

Why is this even a bad thing? Because it may cause other stages to stand in line for these few tasks, leaving cores idle. If you understand where all the Skewness has been coming from, you can fix it right away by changing the partitioning.

4. Appropriately cache

Spark allows you to cache datasets in memory. There are a variety of options to choose from:

  • Since the same operation has been computed several times in the pipeline flow, cache it.
  • To allow the required cache setting, use the persist API to enable caching (persist to disc or not; serialized or not).
  • Be cognizant of lazy loading and, if necessary, prime cache up front. Some APIs are eager, while others aren’t.
  • To see information about the datasets you’ve cached, go to the Storage tab in the Spark UI.
  • It’s a good idea to unpersist your cached datasets after you’ve finished using them to free up resources, especially if other people are using the cluster.

5. Spark has issues with iterative code.

It was particularly difficult. Spark uses lazy evaluation so that when the code is run, it only creates a computational graph, a DAG. Once you have an iterative process, however, this method can be very problematic so because DAG finally opens the prior iteration and then becomes extremely large, we mean extremely large. This may be too large for the driver to remember. Because the application is stuck, this makes it appear in the spark UI as if no jobs are running (which is correct) for an extended period of time — until the driver crashes.

This seems to be presently an obvious issue with Spark, and the workaround that worked for me was to use df.checkpoint() / df.reset() / df.reset() / df.reset() / df.reset() / df. every 5–6 iterations, call localCheckpoint() (find your number by experimenting a bit). This works because, unlike cache(), checkpoint() breaks the lineage and the DAG, saves the results and starts from a new checkpoint. The disadvantage is that you don’t have the entire DAG to recreate the df if something goes wrong.

Conclusion

Spark is now one of the most popular projects inside the Hadoop ecosystem, with many companies using it in conjunction with Hadoop to process large amounts of data. In June 2013, Spark was acknowledged into the Apache Software Foundation’s (ASF) entrepreneurial context, and in February 2014, it was designated as an Apache Top-Level Project. Spark could indeed run by itself, on Apache Mesos, or on Apache Hadoop, which is the most common. Spark is used by large enterprises working with big data applications because of its speed and ability to connect multiple types of databases and run various types of analytics applications.

Learning how to make Spark work its magic takes time, but these 5 practices will help you move your project forward and sprinkle some spark charm on your code.

Data Vault 2.0 – Flexible Datenmodellierung

Was ist Data Vault 2.0?

Data Vault 2.0 ist ein im Jahr 2000 von Dan Linstedt veröffentlichtes und seitdem immer weiter entwickeltes Modellierungssystem für Enterprise Data Warehouses.

Im Unterschied zum normalisierten Data Warehouse – Definition von Inmon [1] ist ein Data Vault Modell funktionsorientiert über alle Geschäftsbereiche hinweg und nicht themenorientiert (subject-oriented)[2]. Ein und dasselbe Produkt beispielsweise ist mit demselben Business Key sichtbar für Vertrieb, Marketing, Buchhaltung und Produktion.

Data Vault ist eine Kombination aus Sternschema und dritter Normalform[3] mit dem Ziel, Geschäftsprozesse als Datenmodell abzubilden. Dies erfordert eine enge Zusammenarbeit mit den jeweiligen Fachbereichen und ein gutes Verständnis für die Geschäftsvorgänge.

Die Schichten des Data Warehouses:

Data Warehouse mit Data Vault und Data Marts

Data Warehouse mit Data Vault und Data Marts

Die Daten werden zunächst über eine Staging – Area in den Raw Vault geladen.

Bis hierher werden sie nur strukturell verändert, das heißt, von ihrer ursprünglichen Form in die Data Vault Struktur gebracht. Inhaltliche Veränderungen finden erst im Business Vault statt; wo die Geschäftslogiken auf den Daten angewandt werden.

Die Information Marts bilden die Basis für die Reporting-Schicht. Hier müssen nicht unbedingt Tabellen erstellt werden, Views können hier auch ausreichend sein. Hier werden Hubs zu Dimensionen und Links zu Faktentabellen, jeweils angereichert mit Informationen aus den zugehörigen Satelliten.

Die Grundelemente des Data Vault Modells:

Daten werden aus den Quellsystemen in sogenannte Hubs, Links und Satelliten im Raw Vault geladen:

Data Vault 2.0 Schema

Data Vault 2.0 Schema

Hub:

Hub-Tabellen beschreiben ein Geschäftsobjekt, beispielsweise einen Kunden, ein Produkt oder eine Rechnung. Sie enthalten einen Business Key (eine oder mehrere Spalten, die einen Eintrag eindeutig identifizieren), einen Hashkey – eine Verschlüsselung der Business Keys – sowie Datenquelle und Ladezeitstempel.

Link:

Ein Link beschreibt eine Interaktion oder Transaktion zwischen zwei Hubs. Beispielsweise eine Rechnungszeile als Kombination aus Rechnung, Kunde und Produkt. Auch ein Eintrag einer Linktabelle ist über einen Hashkey eindeutig identifizierbar.

Satellit:

Ein Satellit enthält zusätzliche Informationen über einen Hub oder einen Link. Ein Kundensatellit enthält beispielsweise Name und Anschrift des Kunden sowie Hashdiff (Verschlüsselung der Attribute zur eindeutigen Identifikation eines Eintrags) und Ladezeitstempel.

Herausforderungen bei der Modellierung

Die Erstellung des vollständigen Data Vault Modells erfordert nicht nur eine enge Zusammenarbeit mit den Fachbereichen, sondern auch eine gute Planung im Vorfeld. Es stehen oftmals mehrere zulässige Modellierungsoptionen zur Auswahl, aus denen die für das jeweilige Unternehmen am besten passende Option gewählt werden muss.

Es ist zudem wichtig, sich im Vorfeld Gedanken um die Handhabbarkeit des Modells zu machen, da die Zahl der Tabellen leicht explodieren kann und viele eventuell vermeidbare Joins notwendig werden.

Obwohl Data Vault als Konzept schon viele Jahre besteht, sind online nicht viele Informationen frei verfügbar – gerade für komplexere Modellierungs- und Performanceprobleme.

Zusätzliche Elemente:

Über die Kernelemente hinaus sind weitere Tabellen notwendig, um die volle Funktionalität des Data Vault Konzeptes auszuschöpfen:

PIT Tabelle

Point-in-Time Tabellen zeigen einen Snapshot der Daten zu einem bestimmten Zeitpunkt. Sie enthalten die Hashkeys und Hashdiffs der Hubs bzw. Links und deren zugehörigen Satelliten. So kann man schnell den jeweils aktuellsten Satelliteneintrag zu einem Hashkey herausfinden.

Referenztabellen

Zusätzliche, weitgehend feststehende Tabellen, beispielsweise Kalendertabellen.

Effektivitätssatellit

Diese Satelliten verfolgen die Gültigkeit von Satelliteneinträgen und markieren gelöschte Datensätze mit einem Zeitstempel. Sie können in den PIT Tabellen verarbeitet werden, um ungültige Datensätze herauszufiltern.

Bridge Tabelle

Bridge Tabellen sind Teil des Business Vaults und enthalten nur Hub- und Linkhashkeys. Sie ähneln Faktentabellen und dienen dazu, von Endanwender*innen benötigte Schlüsselkombinationen vorzubereiten.

Vorteile und Nachteile von Data Vault 2.0

Vorteile:

  • Da Hubs, Links und Satelliten jeweils unabhängig voneinander sind, können sie schnell parallel geladen werden.
  • Durch die Modularität des Systems können erste Projekte schnell umgesetzt werden.
  • Vollständige Historisierung aller Daten, denn es werden niemals Daten gelöscht.
  • Nachverfolgbarkeit der Daten
  • Handling personenbezogener Daten in speziellen Satelliten
  • Einfache Erweiterung des Datenmodells möglich
  • Zusammenführung von Daten aus unterschiedlichen Quellen grundsätzlich möglich
  • Eine fast vollständige Automatisierung der Raw Vault Ladeprozesse ist möglich, da das Grundkonzept immer gleich ist.

Nachteile:

  • Es sind verhältnismäßig wenige Informationen, Hilfestellungen und Praxisbeispiele online zu finden und das Handbuch von Dan Linstedt ist unübersichtlich gestaltet.
    • Zusammenführung unterschiedlicher Quellsysteme kaum in der verfügbaren Literatur dokumentiert und in der Praxis aufwendig.
  • Hoher Rechercheaufwand im Vorfeld und eine gewisse Anlauf- und Experimentierphase auch was die Toolauswahl angeht sind empfehlenswert.
  • Es wird mit PIT- und Bridge Tabellen und Effektivitätssatelliten noch viel zusätzlicher Overhead geschaffen, der verwaltet werden muss.
  • Business Logiken können die Komplexität des Datemodells stark erhöhen.
  • Eine Automatisierung des Business Vaults ist nur begrenzt möglich.

Praxisbeispiel Raw Vault Bestellung:

Das Design eines Raw Vault Modells funktioniert in mehreren Schritten:

  1. Business Keys identifizieren und Hubs definieren
  2. Verbindungen (Links) zwischen den Hubs identifizieren
  3. Zusätzliche Informationen zu den Hubs in Satelliten hinzufügen

Angenommen, man möchte eine Bestellung inklusive Rechnung und Versand als Data Vault modellieren.

Hubs sind alle Entitäten, die sich mit einer eindeutigen ID – einem Business Key – identifizieren lassen. So erstellt man beispielsweise einen Hub für den Kunden, das Produkt, den Kanal, über den die Bestellung hereinkommt (online / telefonisch), die Bestellung an sich, die dazugehörige Rechnung, eine zu bebuchende Kostenstelle, Zahlungen und Lieferung. Diese Liste ließe sich beliebig ergänzen.

Jeder Eintrag in einem dieser Hubs ist durch einen Schlüssel eindeutig identifizierbar. Die Rechnung durch die Rechnungsnummer, das Produkt durch eine SKU, der Kunde durch die Kundennummer etc.

Eine Zeile einer Bestellung kann nun modelliert werden als ein Link aus Bestellung (im Sinne von Bestellkopf), Kunde, Rechnung, Kanal, Produkt, Lieferung, Kostenstelle und Bestellzeilennummer.

Analog dazu können Rechnung und Lieferung ebenso als Kombination aus mehreren Hubs modelliert werden.

Allen Hubs werden anschließend ein oder mehrere Satelliten zugeordnet, die zusätzliche Informationen zu ihrem jeweiligen Hub enthalten.

Personenbezogene Daten, beispielsweise Namen und Adressen von Kunden, werden in separaten Satelliten gespeichert. Dies ermöglicht einen einfachen Umgang mit der DSGVO.

Data Vault 2.0 Beispiel Bestelldatenmodell

Data Vault 2.0 Beispiel Bestelldatenmodell

Fazit

Data Vault ist ein Modellierungsansatz, der vor allem für Organisationen mit vielen Quellsystemen und sich häufig ändernden Daten sinnvoll ist. Hier lohnt sich der nötige Aufwand für Design und Einrichtung eines Data Vaults und die Benefits in Form von Flexibilität, Historisierung und Nachverfolgbarkeit der Daten kommen wirklich zum Tragen.

Quellen

[1] W. H. Inmon, What is a Data Warehouse?. Volume 1, Number 1, 1995

[2] Dan Linstedt, Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault. CreateSpace Independent Publishing Platform 2011

[3] Vgl. Linstedt 2011

Weiterführende Links und

Blogartikel von Analytics Today

Häufig gestellte Fragen

Einführung in Data Vault von Kent Graziano: pdf

Website von Dan Linstedt mit vielen Informationen und Artikeln

„Building a Scalable Data Warehouse with Data Vault 2.0“ von Dan Linstedt (Amazon Link)

6 Ways to Optimize Your Database for Performance

Knowing how to optimize your organization’s database for maximum performance can lead to greater efficiency, productivity, and user satisfaction. While it may seem challenging at first, there are a few easy performance tuning tips that you can get started with.

1. Use Indexing

Indexing is one of the core ways to give databases a performance boost. There are different ways of approaching indexing, but they all have the same goal: decreasing query wait time by making it easier to find and access data.

Indexes have a search key attached to a value or data reference. The index file will direct a query to a record, “bucket” of data, or group of data, depending on the indexing method used. Choosing a good indexing method for your specific needs will reduce strain on your system by making it much easier for data to be located, since a uniform, systematic organization is applied to the entire database.

2. Avoid Using Loops

Many coders learn early on that loops can be both useful and dangerous. It is all too easy to accidentally create an infinite loop and crash your whole system.

Loops are problematic when it comes to database performance because they often are looping redundantly. That is not to say that loops should never be used; they are useful sometimes. It simply depends on the specific case, and removing or minimizing unnecessary loops will help increase performance.

For example, having SQL queries inside of loops is not generally advised, because the system is running the same query numerous times rather than just once. A good rule of thumb is that the more data you have in a loop, the slower it is going to be.

3. Get a Stronger CPU

This fix is a classic in computer science. A CPU with better specs will increase system performance. There are ways, like those above, to increase performance within your system’s organization and coding. However, if you find that your database is consistently struggling to keep up, your hardware might be in need of an upgrade.

Even if the CPU you have seems like it should be sufficient, a CPU that is more powerful than your minimum requirements will be able to handle waves of queries with ease. The more data you are working with and the more queries you need to manage, the stronger your CPU needs to be.

4. Defragment Data

Data defragmentation is a common solution for performance issues. When data gets accessed, written, and rewritten many times, it can get fragmented from all that copying. It is good practice to go in and clean things up on a regular basis.

One symptom of fragmented data is clogged memory, where tables are taking up more room than they should. Crammed memory, as discussed below, is another common cause of a low-performing database.

5. Optimize Queries

There are many ways to go about optimizing queries, depending on the indexing method and the specific needs of your database. When queries aren’t being handled efficiently, the whole system can get backed up, leading to longer wait times for query results. Causes may include duplicate or overlapping indexes and keys or queries that return data that isn’t relevant.

Optimizing queries can be a complex process, but there are some easy steps you can take to work out the best plan for your database and identify its specific inefficiencies.

6. Optimize Memory

Another hardware fix that may help under-performing databases is additional memory space. Databases need some memory “wiggle room” to operate quickly. When your memory is nearly or completely full, things get backed up while the system struggles to find room for creating temporary files and moving things around. It’s a bit like trying to reorganize a living room that is packed floor-to-ceiling with boxes. You need plenty of empty floor space to maneuver and shuffle things around.

Databases work the same way. Increasing your database’s memory capacity will allow it more flexibility and operating room, reducing stress on the system so it can run more efficiently.

Keep It Simple

Many of the tips above focus on simplifying and cleaning up your database. Keep your coding as straightforward and easy-to-navigate as possible. Databases are all about accessing information, so your main priority should simply be to have a well-organized system. Keeping these tips in mind will help you do just that and get your database running at top-notch performance!

ACID vs BASE Concepts

Understanding databases for storing, updating and analyzing data requires the understanding of two concepts: ACID and BASE. This is the first article of the article series Data Warehousing Basics.

The properties of ACID are being applied for databases in order to fulfill enterprise requirements of reliability and consistency.

ACID is an acronym, and stands for:

  • Atomicity – Each transaction is either properly executed completely or does not happen at all. If the transaction was not finished the process reverts the database back to the state before the transaction started. This ensures that all data in the database is valid even if we execute big transactions which include multiple statements (e. g. SQL) composed into one transaction updating many data rows in the database. If one statement fails, the entire transaction will be aborted, and hence, no changes will be made.
  • Consistency – Databases are governed by specific rules defined by table formats (data types) and table relations as well as further functions like triggers. The consistency of data will stay reliable if transactions never endanger the structural integrity of the database. Therefor, it is not allowed to save data of different types into the same single column, to use written primary key values again or to delete data from a table which is strictly related to data in another table.
  • Isolation – Databases are multi-user systems where multiple transactions happen at the same time. With Isolation, transactions cannot compromise the integrity of other transactions by interacting with them while they are still in progress. It guarantees data tables will be in the same states with several transactions happening concurrently as they happen sequentially.
  • Durability – The data related to the completed transaction will persist even in cases of network or power outages. Databases that guarante Durability save data inserted or updated permanently, save all executed and planed transactions in a recording and ensure availability of the data committed via transaction even after a power failure or other system failures If a transaction fails to complete successfully because of a technical failure, it will not transform the targeted data.

ACID Databases

The ACID transaction model ensures that all performed transactions will result in reliable and consistent databases. This suits best for businesses which use OLTP (Online Transaction Processing) for IT-Systems such like ERP- or CRM-Systems. Furthermore, it can also be a good choice for OLAP (Online Analytical Processing) which is used in Data Warehouses. These applications need backend database systems which can handle many small- or medium-sized transactions occurring simultaneous by many users. An interrupted transaction with write-access must be removed from the database immediately as it could cause negative side effects impacting the consistency(e.g., vendors could be deleted although they still have open purchase orders or financial payments could be debited from one account and due to technical failure, never credited to another).

The speed of the querying should be as fast as possible, but even more important for those applications is zero tolerance for invalid states which is prevented by using ACID-conform databases.

BASE Concept

ACID databases have their advantages but also one big tradeoff: If all transactions need to be committed and checked for consistency correctly, the databases are slow in reading and writing data. Furthermore, they demand more effort if it comes to storing new data in new formats.

In chemistry, a base is the opposite to acid. The database concepts of BASE and ACID have a similar relationship. The BASE concept provides several benefits over ACID compliant databases asthey focus more intensely on data availability of database systems without guarantee of safety from network failures or inconsistency.

The acronym BASE is even more confusing than ACID as BASE relates to ACID indirectly. The words behind BASE suggest alternatives to ACID.

BASE stands for:

  • Basically Available – Rather than enforcing consistency in any case, BASE databases will guarantee availability of data by spreading and replicating it across the nodes of the database cluster. Basic read and write functionality is provided without liabilityfor consistency. In rare cases it could happen that an insert- or update-statement does not result in persistently stored data. Read queries might not provide the latest data.
  • Soft State – Databases following this concept do not check rules to stay write-consistent or mutually consistent. The user can toss all data into the database, delegating the responsibility of avoiding inconsistency or redundancy to developers or users.
  • Eventually Consistent –No guarantee of enforced immediate consistency does not mean that the database never achieves it. The database can become consistent over time. After a waiting period, updates will ripple through all cluster nodes of the database. However, reading data out of it will stay always be possible, it is just not certain if we always get the last refreshed data.

All the three above mentioned properties of BASE-conforming databases sound like disadvantages. So why would you choose BASE? There is a tradeoff compared to ACID. If databases do not have to follow ACID properties then the database can work much faster in terms of writing and reading from the database. Further, the developers have more freedom to implement data storage solutions or simplify data entry into the database without thinking about formats and structure beforehand.

BASE Databases

While ACID databases are mostly RDBMS, most other database types, known as NoSQL databases, tend more to conform to BASE principles. Redis, CouchDB, MongoDB, Cosmos DB, Cassandra, ElasticSearch, Neo4J, OrientDB or ArangoDB are just some popular examples. But other than ACID, BASE is not a strict approach. Some NoSQL databases apply at least partly to ACID rules or provide optional functions to get almost or even full ACID compatibility. These databases provide different level of freedom which can be useful for the Staging Layer in Data Warehouses or as a Data Lake, but they are not the recommended choice for applications which need data environments guaranteeing strict consistency.