Lass schwimmen im Data Lake // deutsch

Es gibt zahllose Konzepte zur Datenanalyse: Vom Data-Warehouse über den Data-Mart und den Data-Lake bis hin zum Data-Mesh. Doch was ist was? Was haben die einzelnen Konzepte gemeinsam? Was hat sich bewährt, und wo liegen die Unterschiede?

Genau das erkläre ich Dir in diesem Video: Du lernst, was es mit den einzelnen Konzepten auf sich hat, und wo deren jeweilige Vor- und Nachteile liegen. Außerdem erfährst Du, wo der Zusammenhang zu Themen aus der Entwicklung besteht, und warum all diese Konzepte für Dich als Entwicklerin oder als Entwickler relevant sind.

Und wenn Du oder Dein Team Unterstützung bei der Konzeption, Architektur oder Entwicklung von Daten-getriebenen Anwendungen benötigst, dann melde Dich gerne bei uns:

────────────────────

Willst Du wissen, welche Videos es noch von uns gibt oder suchst Du eines zu einem bestimmten Thema? Hier findest Du die perfekte Übersicht über alle unsere Videos:

────────────────────

Möchtest Du demnächst den Job wechseln, hast aber Angst vor den technischen Fragen im Bewerbungsgespräch? Wir können Dir helfen! Werde Mitglied in unserem Coding-Circle und erhalte jede Woche exklusive Videos:

────────────────────

Hast Du Fragen zu diesem Video oder willst Du Dich mit Gleichgesinnten aus der Community austauschen? Dann komm auf unseren Discord-Server:

────────────────────

00:00 – Einleitung
01:10 – Was ist ein Data-Warehouse?
02:18 – Warum ein Data-Warehouse nicht (gut) funktioniert
03:51 – Das Data-Warehouse – eine Utopie?
04:44 – Ein einziges Data-Warehouse ist nicht genug
05:42 – Ohne fachliches Verständnis wird's schwierig
06:59 – Der Data-Lake als (vermeintliche) Lösung
08:48 – Die tatsächliche Lösung
09:44 – Vor allem heiße Luft?

────────────────────

[christianbaer]

Zwei "Storys" dazu.
1. Wir hatten das erste Mal etwas Event-Driven umgesetzt. Dann kam das BI-Team und wollte Daten.
Wir meinten: "Klar, was denn?"
"Na Zugriff auf eure DB-Tabellen um die Entitäten täglich abfragen zu können und ins DWH zu importieren"
"Also 1. geben wir euch sicher keinen Zugriff auf die Produktionsdatenbank, damit ihr da Querys abschicken könnt und 2. haben wir so eine Tabelle nicht."
Die Verwirrung auf den Gesichtern war unbeschreiblich. Wir haben dann versucht zu erklären, dass wir Events hätten und wir ihnen die im Zweifel geben könnten, aber sie ja dann das ganze Verarbeiten von Events selbst implementieren müssten. Das haben sie eingesehen, dass das nicht so gut ist. Wir haben uns dann drauf geeinigt, dass sie uns sagen können welche Metriken sie brauchen und wir liefern die über einen HTTP-Endpunkt im JSON-Format (man kann das jetzt REST nennen oder auch nicht) und wenn sie irgendwann andere oder weitere Metriken bräuchten, wären wir auch dazu bereit das zu implementieren. Ging.
Learning: Direkt auch BI-Leute in Planungen miteinbeziehen und das nicht alles erst nachgelagert machen.

2. Mobile App. Wir sollten die Geräteverteilung tracken (Android/iOS, Version, Gerätebezeichnung, etc.)
Da war meine Frage dann: "Wie braucht ihr die Daten?"
"Mach dir darum keine Sorgen. Speicher einfach die Daten als JSON dort hin und wir machen den Rest."
Dieses Mal war meine Verwirrung auf meinem Gesicht zu sehen. Dank Homeoffice und ausgeschalteten Kameras, hat das aber niemand gesehen. Da wurde auch von Data-Lakes geredet und dass das BI-Team (andere Firma als Story oben) das dann auswertet und verknüpfen kann und ich stand nur da und dachte mir so "Wie zur Hölle wollen die das machen, wenn die vorher nicht wissen wie die Daten aussehen werden?" Nun... Stellt sich raus, dass mein Bauchgefühl gar nicht so falsch war. Das ist keine sonderlich schlaue Idee...
Learning: Keins... Außer vielleicht, dass mein Bauch gar nicht so falsch liegt, wenn er grummelt ;-)

Was will ich sagen: Keine Ahnung... Ich fand meine Storys einfach spannend genug um sie in diesem Kontext hier zu teilen 🙂
Manchmal lerne ich in den Videos mit Golo inhaltlich nichts Neues, lerne aber wie ich das, was ich in meinem Kopf habe, in Worte fassen kann. Das ist auch viel wert und wenn mir das nächste Mal jemand sagt "Tu deine Daten bitte in diesen Data-Lake hier", kann ich "Das klingt nach einer sau dummen Idee" ein bisschen eloquenter ausdrücken.

[oliverkramer]

Das ein Data-Warehouse ab einer gewissen Firmen größe zu kompliziert wirkt sehe ich aus der Praxis niicht. Wir bauen seit vielen jahren DWHs mit anhängenden Marts und auch DataLakes unter anderen für die größten deutschen Finanzdienstleister. und hatten da die beschreibenen Probleme nicht heufiger als in anderen Software Projekten. Aber ja das wichtigste in einem solchen Kontext sind die Kommunikation und der Wille der Projekttreiber.

[valeridause]

Data Lake ist keine Lösung, sondern die 'neue Sau', die durch das Dorf getrieben wird. Danke fürs Video!

[woife]

Ich danke Dir vielmals für die Aufklärung. Ich weis nicht, ob es nur mir so geht, aber ich finde, dass heutzutage immer erst ein besonderer Name/Logo erfunden wird und man es erst hinterher versucht, mit Inhalt zu füllen. In meinem Umfeld redet jeder von "Data Lakes" und dass wir es unbedingt brauchen. Was das aber ist und welche Probleme es genau lösen soll, kann meist nicht eindeutig beantwortet werden.
Ich fühle mich eher auf der technischen Ebene zuhause. Es muss am Ende funktionieren (das schließt die Qualität explizit mit ein). Ob man es dann Lake, Swamp oder wie auch immer nennt, ist mir dabei herzlichst egal.

[ministerstein]

Kurz offtopic: kommt noch ein Followup zum Thema HTMX? In den Kommentaren ging es ja heiß her und einige hatten wirklich gute Argumente pro HTMX 🙂

[markusschmidt]

Auch die Aufteilung der Daten in die Teams: dann hat man halt nur die Daten aus z.B. dem Vertrieb und nicht auch die Daten aus dem System foo. Außerdem geht es bei "gleichem Format" oft nicht um gleiche Felderstrukturen (Personen und Foo Daten in die Gleiche Tabellen) sondern um z.B Historienverfahren vereinheitlichen und Zeitstrahlen syncronisieren. in einem DWH sindie Daten aber auch anders abgelegt als im Online System usw.
Aber einige Punkte habe ich bei DWH Projekte auch schon gehabt und die DWH Truppe kennt oftmals die Systeme besser als die Entwickler der Abteilungen.