Data Lake, Data Mesh, Data was'n das?! // deutsch

[@robertbutscher6824]

super Video, hervorragend erklärt. Die geschilderten Probleme rund um DWH und DL sehe ich im Prinzip ähnlich, weil oftmals ein Metadaten-Management in Unternehmen unterentwickelt ist. Viele Unternehmen etablieren derzeit auch Ansätze wie Data Lakehouse, was in der Theorie die Vorteile von DWH und DL kombinieren soll. Data Mesh klingt vielversprechend, aber hier sehe ich die Herausforderung, in Fachabteilungen entsprechend technisches Know-how aufzubauen, um die hohen Anforderungen an die Spezifikation eines Data Mesh umsetzen zu können. Es geht ja auch darum, hier Code mitauszuliefern, damit der Verwender möglichst schnell das Datenprodukt nutzen kann. Wenn ich es richtig verstehe, ist ein solches Datenprodukt ja ein bereits sehr gut aufbereiteter Informationsbaustein, der alles befür benötigte quasi in sich trägt. Hier finde ich übrigens auch den Data Mesh Ansatz sehr weise, Daten nicht per se als wertvoll zu sehen, sondern die darin liegende Information, die sich in Form eines Data Product manifestiert. Wie gesagt, die technischen Hürden in den Fachabteilungen sehe ich (als stemmbare) Herausforderung

[@mk2k685]

Das "Teilen mit den Kolleginnen und Kollegen" war bisher für mich ein Problem - 90% in meinem Umfeld können überhaupt kein Deutsch. Sehr gut, dass sich das nun durch euren Zweitkanal erledigt hat 🎉

[@atcen]

Und das jetzt wo KZbin doch endlich mehrere Audiospuren unterstützt

[@mk2k685]

@@atcen das wäre aber kein Use-Case für solche Videos

[@yt7042]

Danke für die interessante "Datenanalyse". Data Mesh klingt auf den ersten Blick vernünftig, allerdings wird es auch hier Überschneidungen geben und Daten die nicht eindeutig einem Bereich zuordenbar sind. Ich glaube die Datenspeicherung/-verwaltung sollte man an das Unternehmen anpassen und nicht andersherum an Buzzwords. Schöne Woche!

[@tobiasnickel3750]

hab noch mit keinem solcher architecturen gearbeitet. es hoert sich fuer mich an als ob die entscheidung fuer das eine oder andere eher eine personen und firmen entscheidung ist, als eine Technische entscheidung. ich denke das ist gut mit den mashes, denn so koennen daten zusammengefuert werden ohne sie in ein risiges Hadoop oder Cassandra monster zu schmeissen. danke fuer das Video

[@dataintelligencegmbh351]

Sehr gute Erklärung der wesentlichen Unterschiede in den Ansätzen mit dem wichigen Hinweis auf das Fach- bzw. Prozesswissen. Data Lake hat mich nie überzeugt. Erstmal alles sammeln, um erst bei Verwendung ans Strukturieren zu denken, ist viel zu aufwendig. Besser man strukturiert eine Datenquelle zuerst nach einem automatisierbaren Standardverfahren zur Einlagerung und Historisierung. Erst danach wird die Fachlogik zur Integration angesetzt. Wenn man dazu noch jede Datenquelle streng unabhängig von anderen verarbeitet, ist man nicht weit von einem Data Mesh entfernt. So gehen wir seit über 10 Jahren vor. Man könnte das Datawarehouse nennen, ich bevorzuge mittlerweile den Begriff Datenintegration.

[@aristor2926]

Sehr interessant.

[@19nik91]

ich habe den Schmerz von data lakes selber kennen lernen dürfen. Man arbeitete seit Jahren an einer Datenstruktur die alles abbilden können soll, wobei jedes Feld optional ist damit auch jeder Kunde seine individuellen Daten in das system einspielen kann. Gleichzeitig muss das Datenmodell auch jede noch so kleine Datenvariante aller Kunden abbilden können. Auf der Basis sollten Berechnungs- und Analyseprozesse laufen können. Jahre sind vergangen und es läuft immer noch nichts, zumindest nicht auf basis des data lakes ;-)

[@thomaspolzer9103]

Wie immer auf diesem qualitativ hochwertigen Kanal ein sehr interessanter Beitrag. Allerdings bin ich in diversen Punkten anderer Meinung. Ich persönlich habe nicht den Eindruck, dass der Trend zum Data Lake bereits vorüber ist. Im Gegenteil: Sehr viele Enterprise-Kunden überführen gerade ihr Data Warehouse in ein Data-Lake-Konstrukt in der Cloud und gehen vom ETL- in den ELT-Ansatz über. Der Trend geht eher dahin, Data Lake und DW zu kombinieren ("Data Lakehouse"), wobei hier Anbieter wie Databricks eine große Rolle spielen. Und es gibt durchaus Mechanismen, die verhindern, dass im Data Lake der Business-Kontext verlorengeht, der Überblick zu den Daten fehlt oder Berechtigungen unklar sind. Es gibt hierzu Software-Produkte mit integriertem Data Catalog und Lineage, die genau das verhindern. Viele Kunden unterschätzen allerdings diesen Aspekt bei einem Data-Lake/DW-Projekt und werden dann später mit solchen Problemen konfrontiert - mit dem Data Lake an sich hat das aber in der Regel wenig zu tun. Zu Data Mesh: Ein durchaus interessanter Ansatz. Allerdings steht dieser nicht im Widerspruch zum Data Lake, sondern kann mit diesem kombiniert werden (zentrale Datenerfassung und Ablage im Raw Layer, spätere dezentrale Ablage und Übergabe der Ownership an die Fachbereiche). Data Mesh stellt allerdings sehr hohe Anforderungen an die IT-Skills der Fachbereiche und den Reifegrad der dortigen IT-Organisation. Die Zukunft wird zeigen, ob sich der Ansatz durchsetzt. Bislang gibt es meines Wissens nach nur sehr wenige Kunden, die einen Data Mesh bereits produktiv im Einsatz haben.

[@robertbutscher6824]

das war ein sehr schön fundierter Kommentar - meines Wissens nach setzen Zalando und adidas auf Data Mesh, zumindest wurden diese Unternehmen als Beispiele genannt. Ich halte auch das hohe IT-Skill-Level in der Fachabteilung für eine zentrale Herausforderung bei der Umsetzung von Data Mesh. Das muss jetzt kein Hinderungsgrund sein, aber der damit einhergehende Paradigmen-Wechsel ist nicht zu unterschätzen, insbesondere auch, weil etliche Unternehmen ihre IT-Abteilungen eher herunterfahren wollen als neue Entwickler:innen einzustellen

[@WittRaider]

Wenn ich es richtig verstanden habe bedeutet ein DataMesh auch immer dass das jeweilige Team mit fachlicher Kenntnis der Daten diese nun über einen einheitlichen Mechanismus bereitstellt und in der Art welche Abfragen gestellt werden können die Interpretationsarbeit macht die ansonsten „fachfremde“ Personen machen müssen. Glaubt ihr, dass das wirklich von den Fachteams geleistet werden kann? Also rein zeitlich? In der Regel werden ja „fachfremde“ die Fragen haben und deshalb Daten mehrerer Fachbereiche zusammenbringen müssen. Liegt da nicht genauso viel Interpretation drin? Ich finde die Idee gut, kann mir aber noch nicht ganz vorstellen wie eine Organisation als gesamtes ticken muss um das erfolgreich umzusetzen.

[@T0kwe]

Üblicherweise baut man seine Teams ja nach dem Spotify-Modell auf. Also jedes Team besteht aus Menschen mit verschiedenen Skills, sodass alle Rollen ausgefüllt werden. Man kann also das Team einfach um die Rolle des Datenanalysten erweitern, der dann genau diese Auswertungen für das eigene und für andere Teams übernimmt

[@WittRaider]

@@T0kwe : was funktioniert Deiner Meinung nach besser: eher als zusätzliche Rolle im bestehenden Team oder dediziert über Einstellung. Klar kommt es drauf an, wie nahe der Skill bereits im Team vorhanden ist, aber wie siehst Du es in der Praxis?

[@T0kwe]

In der Praxis nutzt noch niemand Data Mesh soweit ich weiß. Deswegen kann ich hier nicht aus Erfahrung sprechen. Üblicherweise gibt es ja aber schon jetzt ein Data-Team und das würde ich auflösen oder stark in der Größe reduzieren und die Leute dann in die jeweiligen fachlichen Entwicklungsteams integrieren.

[@philippkunz4263]

Das Konzept des Data Mesh ist mir soweit klar, macht auch irgendwo Sinn. Es ist aber meiner Meinung nach nichts anderes, als der "holistischere" Ansatz vom zehn Jahre alten (demokratischen) Self Service BI Ansatz; Man nutzt im Unternehmen quasi ein Self-Service BI Tool, mit dem der Fachbereich (nach erfolgter Schulung) modulare Data Products (Kundenstamm, Artikelstamm, Etc. im Sinne eines Datenkatalogs) zu einem Datenmodell (Data Mart) verknüpft und dieses dann auch für die Dashboards nutzt. Für den Mittelstand absolut ausreichend. Bei Enterprise Kunden wird das Ganze mit einer "Data Fabric" als technische Plattform halt zusätzlich umspannt, damit ich bei Bedarf neben dem BI Tool auch Datenintegrationslösungen, ETL-Tools, etc. einsetzen kann. Alter Wein in neuen Schläuchen...

[@markusbreitinger5508]

Genau wegen der Spannung aus unflexibler Semantik bei SQL bis hin zur fehlenden Semantik beim Data Lake, habe ich mich vor 6 Jahren Graph DBs zugewandt. Dort kann ich alle Varianten von Semantik gleichzeitig haben und können Prozesse eine passende Abbildung finden und Prozesse zur Analyse entwickeln.

[@realrlg]

Gibt es eigentlich Begriffe, die "eigene Daten" (Produktmerkmale, Preise, Artikelnummern, ...) und "statistische Daten" (Wie oft wurde Produkt X angeklickt/angesehen, wie oft wurde Y gekauft, wie haben sich die Verkaufszahlen verändert nach Einführung von Z) unterscheiden? Data Warehouse hatte ich in der Vergangenheit für diese "eigenen Daten" ganz praktisch gefunden, wobei ich irgendwann dachte, dass man den Aufwand sich sparen könnte, wenn man einen GraphQL Layer drüberlegen würde. Vor ein paar Wochen mussten wir einen Prototypen in der Richtung basteln, da fand ich dann "GraphQL Mesh" - kannte den Begriff Data Mesh davor aber noch nicht 😅

[@maxjung6845]

bzgl der Begriffe: "Daten" und "Meta-Daten" sind gebräuchlich zumindest in meiner Bubble. Ich mag auch diese Erklärung von "Meta-Daten" gern: M.D. sind Daten über Daten. Wobei du eben auch schon in Richtung "statistischer bzw. aggreggierter Meta-Daten" beschreibst. War das die Frage?

[@realrlg]

@@maxjung6845 d.h. Daten sagt man zu den Produkt-/Featuredaten und Meta-Daten zu den erhobenen Daten? 🤔 Hätte das eher andersherum vermutet...

[@maxjung6845]

@@realrlg ja, das würd ich so bestätigen. Im Kontext "(Big) Data (Warehouse, Lake, Mesh)" sind vielleicht auch die Abkürzungen OLTP, OLAP eine Erwähnung wert. Unter OLTP stell *ich* mir die "normalen Daten", OLAP sind die Daten zu Analyse-Zwecken.

[@BenjaminWagener]

Da ich bisher nur mit kleineren Anwendungen zu tun hatte, hatte ich noch nie mit Data Warehouse oder Data Lakes zu tun. Es ist aber erschreckend, dass da überhaupt jemand mal dachte, dass derartige Architekturen sinnvoll seien. Es ist doch eigentlich eine klare Grundlage der Informationsverarbeitung, dass Informationen ohne den Kontext kaum etwas bis gar nichts wert sind. Das Data Mesh klingt hingegen sinnvoll.

[@suikast420]

I am with you

[@FilmfanOliver1992]

Automatisch generierte Untertitel, haben was von English for insiders - Englisch für reingefallene ;-)

[@devchannel5232]

Top!

[@jonasbehringer3859]

Hab’s eben im masterstudium gehört 😅

[@bsdooby]

Data Lakes machen aber doch schon Sinn, wenn man denn die nötige Rechenpower hat, um damit zu arbeiten. Es finden sich in jedem Fall statistische Muster, die abgegriffen werden können (LLMs werden ja so trainiert).

[@jeyt436]

Toller Videotitel

[@thenativeweb]

[gr] Danke schön 😊 (War nicht meine Idee, aber ich geb's weiter!)

[@jeyt436]

'Data Lake" aufbDeutsch: Finde die Nadel im Heuhaufen (so jlhabe ich es zumindest durch dich verstanden)

[@marcello4258]

Oh oh oh.. du weißt ich liebe deinen Kanal, aber bei diesem Video hast du viele Sachen durcheinander gebracht und Begriffe falsch verwendet 🙈 Ich will nicht sagen, dass du dich dazu nicht äußern solltest, aber ich denke du solltest das Video noch mal komplett überarbeiten. :/