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.
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.
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.
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.
Punkt1 : Prod System liefert die Metriken aus: das mag bei manchen Auswertungen funktionieren, aber nicht bei "richtigen" DWH Aufgaben Wenn man z.B. alle Verträge und das Wetter zeitlich verbinden will kann man nicht auf Just in Time Datenbeschaffung zurückgreifen. Da muss man alles "vor Ort" haben
@@markusschmidt9425 Wir haben einen Endpunkt bereitgestellt, damit sich das BI/DWH-Team Daten abholen kann. Die haben diese Daten dann natürlich in ihr DWH integriert. Es ging nie darum, dass sie die Daten nicht haben oder speichern dürfen. Sie durften nur nicht direkt in die Prod-DB greifen.
Data Lake ist keine Lösung, sondern die 'neue Sau', die durch das Dorf getrieben wird. Danke fürs Video!
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.
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.
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 🙂
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.
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.
Punkt1 : Prod System liefert die Metriken aus: das mag bei manchen Auswertungen funktionieren, aber nicht bei "richtigen" DWH Aufgaben Wenn man z.B. alle Verträge und das Wetter zeitlich verbinden will kann man nicht auf Just in Time Datenbeschaffung zurückgreifen. Da muss man alles "vor Ort" haben
@@markusschmidt9425 Wir haben einen Endpunkt bereitgestellt, damit sich das BI/DWH-Team Daten abholen kann. Die haben diese Daten dann natürlich in ihr DWH integriert. Es ging nie darum, dass sie die Daten nicht haben oder speichern dürfen. Sie durften nur nicht direkt in die Prod-DB greifen.