#45 Datengetriebene Entscheidungen und der perfekte Dashboard Stack

Datengetriebene Entscheidungen oder auch "Glaube keiner Statistik, die du nicht selbst gefälscht hast".

Entscheidungen treffen und die nächsten Schritte planen ist nicht einfach. Relevante Daten können einem die Entscheidung erleichtern. Doch wie fängt man mit datengetriebenen oder daten-unterstützenden Entscheidungen eigentlich an? Woher weiß man, ob man die richtigen Daten hat? Was wird zur entsprechenden Aufbereitung benötigt und wie kann ich die Daten entsprechend visualisieren?

In dieser Episode geben wir einen Einblick in das Feld der datengetriebenen Entscheidungen. Wir beantworten, warum Tortendiagramme blödsinn sind, wie die Architektur aussehen kann, ob das Bauchgefühl überhaupt noch relevant ist und warum man nicht mehr sein eigenes JavaScript Frontend mehr bauen muss.

Bonus: Was warmes Bier mit Husten zu tun hat und wie das Oktoberfest unsere Podcast-Statistiken beeinflusst.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Sprungmarken

(00:00:00) Intro

(00:01:00) Cloud vs. On-Premise im Wartungsfenster Podcast

(00:04:32) Das heutige Thema: Datengetriebene und Daten unterstützende Entscheidungen

(00:05:16) Was verstehen wir unter datengetriebenen Entscheidungen?

(00:08:18) Gefälschte Statistiken und die richtige Daten-Visualisierung

(00:10:25) Wer hat Zugang zu den Daten und wie sieht die Daten-Transparenz aus?

(00:14:05) Muss jeder Mitarbeiter SQL-Abfragen erstellen können?

(00:15:55) Die Architektur für datengetriebene Entscheidungen

(00:18:53) Pre-Processing, OLAP, OLTP und Datenbank-Normalformen

(00:21:46) Was ist Clickhouse und welche Tools gibt es auf dem Markt?

(00:22:59) Sind Tortendiagramme Blödsinn?

(00:23:46) Die Visualisierung: Wie finde ich heraus, welche Fragen wir eigentlich aus den Daten beantwortet haben wollen?

(00:25:53) Wie verwende ich Datenvisualisierung, ohne ein eigenes Team?

(00:28:30) Schnelle Dashboards und Performance von Queries

(00:29:28) Was ist bei Datenbanken in Bezug auf Analytics optimiert?

(00:31:03) Muss man noch sein eigenes Dashboard-Frontend mit JavaScript bauen?

(00:36:21) Welche Tipps würdest du Neulingen zur Dashboards-Erstellungen geben?

(00:39:17) Ist das Bauchgefühl noch relevant?

(00:41:30) Ab wann sind Daten aussagekräftig (statistisch signifikant)?

(00:45:51) Welche Firmen sind Vorreiter im Bereich datengetriebene Entscheidungen?

(00:47:29) Kann man zu datengetrieben sein?

(00:48:21) Woher weiß ich, auf welche Daten ich gucke?

(00:50:10) Outro: Podcast-Statistiken

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:00 - 00:00:54)

Hey, cool, dass du bei einer weiteren Episode vom Engineering Kiosk dabei bist. Aus der DevOps und Cloud-Ecke kennen wir alle Dashboards mit technischen Metriken wie Response-Zeit oder Memory-Usage. Aber habt ihr auch eine ähnliche Einsicht in eure Side Projects? Zum Beispiel, wie viele User ihr habt, wie viele Leute sich im letzten Monat eingeloggt haben oder auch komplexere Businessmetriken? In dieser Episode sprechen wir über datengetriebene Entscheidungen, Dashboards und Analytics und wie diese heutzutage ohne viel Aufwand umgesetzt werden können. Denn wofür man früher ein ganzes Team benötigt hat, reicht heute ein guter Open Source Deck. Dabei erklären wir auch das warum, wie die Architektur aussehen kann, ob jeder nun SQL lernen muss, wie schöne Dashboards in Minuten erstellt werden können und ob das gute alte Bauchgefühl für Entscheidungen überhaupt noch eine Relevanz hat. Viel Spaß!

Wolfi Gassler (00:01:01 - 00:01:09)

Andi, ich sag's dir gleich, du musst heute reden. Meine Stimme ist irgendwo im Keller, dank meiner Verkühlung oder, damit du es auch verstehst, Erkältung. Also du musst heute reden.

Andy Grunwald (00:01:09 - 00:01:18)

Keller ist ein gutes Stichwort. Und zwar wollen wir uns mal ganz kurz bei einem anderen technischen Podcast, dem Wartungsfenster, bedanken. Und zwar sind... Moment, wie ist das.

Wolfi Gassler (00:01:18 - 00:01:28)

Denn immer mit dem Keller zu verbinden? Es ist ja erstaunlich. Ich wirf dir irgendwelche Wörter hin und du findest einen Konnex. Aber wenn du jetzt Wartungsfenster mit Keller verbindest, dann ist es wirklich komisch.

Andy Grunwald (00:01:29 - 00:02:34)

Nee, du bist wieder zu ungeduldig. Und zwar erinnert mich Keller immer an Serverraum, Serverraum erinnert mich an Datacenter, Datacenter erinnert mich an Cloud und so bin ich wieder beim Wartungsfenster, die in ihrer aktuellen Episode, nämlich ebenfalls das Thema unserer Episode 43, Cloud vs. On-Premise, die Entscheidungshilfe aufgegriffen haben. Wir haben da natürlich immer nur über Geh mal nach Amazon, Geh mal nach GCP, Geh mal nach Azure und was skaliert und was skaliert nicht. Und die beiden haben das sehr sehr schön gemacht, weil deren professionelles Umfeld ist etwas anders als unser in unserer puren Internet Bubble. Und die beiden arbeiten primär mit dem Mittelstand und dem produzierenden Gewerbe, wo es dann ziemlich viel um Netzwerktechnik geht und Sie beleuchten das ganze Thema Cloud versus On-Premise mal, ich würd fast sagen, von einer anderen Perspektive, was sehr, sehr schön ist, wo man dann wirklich drüber spricht, ist das jetzt ein Rechenzentrum oder eher eine Besenkammer? Ich musste schon stark lachen teilweise. Aber so sieht halt die Realität aus. Vielen Dank dafür, Claudia und Patrick. Hat mir sehr viel Spaß gemacht, diese Episode von euch zu hören.

Wolfi Gassler (00:02:35 - 00:02:46)

Ja, ist wirklich cool. Es sind auch ein paar ganz interessante Details dabei, wie zum Beispiel, was so ein Rack heutzutage kostet, wenn man es in einem Datacenter mietet, mit einem Uplink. Günstiger, als ich mir, ehrlich gesagt, erwartet habe.

Andy Grunwald (00:02:46 - 00:03:01)

Oder dass manche Leute beim Bau eines Serverraums, Besenkammers oder was weiß ich nicht, auf die Löschanlage verzichten. Da muss ich auch sehr stark lachen. Aber, nun gut. Ich glaube, jeder hat ein anderes Verständnis von Disaster Recovery und Incident, was?

Wolfi Gassler (00:03:02 - 00:03:34)

Auf jeden Fall war auch interessant. Sie haben die Folge Make and Buy genannt. Wir haben ja auch mal eine Make and Buy-Folge, also Make oder Buy-Folge gemacht, und zwar die Folge 12. Und wir haben das natürlich viel mehr von der Software-Seite betrachtet und wir sind halt im Web zu Hause, Web-Applikationen. Und nachdem die Claudia und der Patrick eher so im Rack-and-Stack-Business unterwegs sind, wie sie das eben genannt haben, können die das von einer ganz anderen Seite beleuchten, wo wir einfach wenig Ahnung haben und wenig Einblick. Ich war in meinem Leben noch nie in einem richtigen Datacenter. Keine Ahnung, wie es dir geht. Insofern, hört doch mal rein. Wirklich interessante Episode.

Andy Grunwald (00:03:34 - 00:04:15)

Ich war schon mal in einem Datacenter, als ich das erste Mal in einem Datacenter war, fand ich so stark faszinierend, weil du hast halt ein bisschen über die Racks und die Schränke geguckt und du hast halt wirklich Fußballfeld große Infrastrukturen und siehst halt einfach nur überall Kabel und es ist einfach super laut wegen den ganzen Lüftern. Also wir standen, glaube ich, in zwei, drei Meter auseinander und haben uns dann eigentlich nicht normal verstanden. Aber auch die Zugangskontrolle war schon hart. Also vorher Pass hinsenden, Erlaubnis und blabliblub, ne, mit allem, was dazugehört. War schon sehr beeindruckend, war aber schon so vor zehn oder zwölf Jahren. Da war ich noch etwas jünger, war natürlich dann, die Rax dann vielleicht noch etwas größer.

Wolfi Gassler (00:04:15 - 00:04:16)

Bist du gewogen worden?

Andy Grunwald (00:04:17 - 00:04:21)

Gewogen? Ob ich, wenn ich rausgehe, mehr wiege oder was?

Wolfi Gassler (00:04:22 - 00:04:26)

Ja, scheinbar ist das ziemlicher Standard mittlerweile bei den Datacentern, dass man da auch gewogen wird, ja.

Andy Grunwald (00:04:27 - 00:05:09)

Nee, ich wurde nicht gewogen. Ich muss auch zugeben, das war jetzt auch kein Datacenter, wo meines Erachtens nach Google oder Amazon zu Hause war, sondern eher ... war jetzt kein kleines Data Center, war mitten in Düsseldorf, aber nun gut. Aber wirklich passend zum letzten Thema, Cloud oder On-Premise, und zwar war ja da sehr oft der finanzielle Vergleich. Und zwar, was ist eigentlich günstiger? Ist Cloud günstiger oder ist On-Premise günstiger? Und was wir da gemacht haben und was auch Claudio und Patrick gemacht haben, die haben sich erstmal Daten geholt und haben anhand von Daten entschieden. Und genau das ist heute unser Thema. Analytics und datengetriebene Entscheidungen.

Wolfi Gassler (00:05:09 - 00:05:12)

Du hast wieder eine super schöne Überleitung gebastelt.

Andy Grunwald (00:05:12 - 00:05:17)

Wenn ihr den Stream jetzt gerade sehen könntet, der Wolfgang grinst wirklich, weil ich denke, er meint das wirklich ernst.

Wolfi Gassler (00:05:18 - 00:05:31)

Natürlich, meine ich das ernst. Du schaffst es, in jedes Thema überzuleiten. Vom Keller direkt in die fünfte Etage zu Analytics. Aber um ganz ketzerisch mal zu fragen, was verstehst du unter datengetriebene Entscheidungen?

Andy Grunwald (00:05:31 - 00:05:45)

Wenn ich hungrig in den Supermarkt gehe, dann wird mein Einkaufskorb mit hoher Wahrscheinlichkeit nicht datengetrieben gefüllt. Mache ich mir aber vorher eine Einkaufsliste, könnte mein Einkaufswagen deutlich datengetriebener gefüllt werden, weil ich ja vorher Daten habe.

Wolfi Gassler (00:05:46 - 00:08:27)

Ja, ist auf jeden Fall eine interessante Definition. Ich persönlich würde ja datengetriebene Entscheidungen einfach so definieren, dass man eben nicht aus dem Bauch heraus entscheidet, sondern irgendwelche fundierten Daten, Informationen hat, auf die man die Entscheidung basiert. Natürlich auch Bauchentscheidungen haben meistens mit Erfahrung zu tun, sind eigentlich auch irgendwie Daten, aber bei datengetriebenen Entscheidungen spricht man halt meistens wirklich von Hard Facts. Man hat zum Beispiel AB-Testing auf einer Webseite getestet, ob der rote Kaufen-Button oder der blaue Kaufen-Button am Ende zu mehr Umsatz führt. Das ist so der ganz klassische Weg. Wir testen zwei Varianten aus, bekommen dann die Information, der blaue Button ist besser und dann stellt man auf den blauen Button um. Also das ist die ganz klassische Data-Driven-Seite. Der Nachteil an dieser Data-Driven-Decision ist eigentlich, dass man nur auf die Daten vertraut und gar nicht mehr dieses Bauchgefühl oder die Erfahrung, die man hat zum Beispiel, wenn es um ein Produkt geht, mit einfließen lässt. Und aus dem Grund ist man jetzt immer mehr übergegangen zu Data-Supported-Decisions. Das heißt, man verwendet die Daten und Informationen, die man zur Verfügung hat, Aber die eigene Erfahrung, die man zum Beispiel hat, die lässt man natürlich auch mit einfließen in die Entscheidungen. Und das ist vor allem wichtig, weil man eigentlich nie alle nötigen Daten zur Verfügung haben kann. Also ich kann mich erinnern, wir hatten einmal bei Trivago so einen Test, den hat man immer wieder probiert durchzuführen und der hat aber immer schlechtere Performance gehabt. Also man hat immer weniger Umsatz gehabt, wenn man das durchgeführt hat. Aber trotzdem, von der User-Sicht war der eigentlich von der Usability viel viel besser. Und man hätte sagen können, eigentlich ist es gut für den User, weil der kann sich dann besser durch die Webseite bewegen. Aber auf der Umsatzseite war es immer schlechter. Und so ist der Test eigentlich nie durchgesetzt worden, weil man halt immer auf die Daten vertraut hat. Bis man dann eben nach, ich glaube wirklich ein, zwei Jahren einfach gesagt hat, okay, wir machen das jetzt trotzdem und am Ende war es dann eine Verbesserung für den Benutzer. Also da sieht man auch, wenn man nicht alle Daten zur Verfügung hat, weil es ist natürlich viel, viel schwerer zu messen, hat eine Änderung Auswirkungen auf die Besucherinnen, auf das Besucherverhalten und vielleicht die Loyalität auf lange Sicht oder ist es jetzt eben nur eine Änderung auf der Umsatzseite und wir machen eine Entscheidung nur auf diesen Hard Facts, die wir gerade jetzt im Moment haben. Und darum ist es eben wichtiger, dass man Data Supported Decisions macht. Im Deutschen würde ich sagen, datengetriebene Entscheidungen geht eh auch in die Richtung, weil getrieben heißt ja, man vertraut nicht 100 Prozent auf die Daten. Aber im Englischen wird auf jeden Fall sehr stark unterschieden zwischen Data Driven und Data Supported Decisions.

Andy Grunwald (00:08:27 - 00:09:34)

Du hast gerade das Wort fundierte Daten genannt. Immer wenn ich irgendwelche Grafen in irgendwelchen PowerPoint-Präsentationen oder generell Grafen sehe, dann erinnere ich mich an ein Sprichwort, glaube niemals an eine Statistik, die du nicht selbst gefälscht hast. Und wenn du jetzt von Data Supportive-Entscheidungen und Hard Facts sprichst, frage ich mich, die Leute schauen sich ja keine Rohdaten an. die leute schauen sich schon irgendwelche torten graph diagramme plots von irgendwas an irgendeine kurve die hoch oder runter geht oder wird dieses sprichwort dann nicht viel wichtiger dass du dann dir die grafen so legst wie du sie haben möchtest weil ich bin mal ganz ehrlich die richtige visualisierung die richtige daten visualisierung zu finden und anzuwenden ist unglaublich schwierig ich hatte zum beispiel mal Ein sehr starken Lead einer Business Intelligence Abteilung, der sagte zu mir, ich kenne keinen einzigen validen Anwendungsfall, warum man ein Tortendiagramm machen sollte. Der sagte, das ist einfach nur irreführend, das sagt einfach viel zu wenig aus. Also er war halt fest der Meinung, dass Tortendiagramme eigentlich vom Markt verschwinden sollten.

Wolfi Gassler (00:09:35 - 00:10:36)

Ja, ich glaube, das ist auch eine Frage immer, wer du bist. Wenn du ein Data Analyst bist, ein Data Scientist, jemand, der sich tagtäglich mit Zahlen beschäftigt, für den ist ein Totendiagramm absolut sinnlos, würde ich auch so sehen. Und ehrlich gesagt, in einem Totendiagramm sieht man meistens ein, zwei Zahlen, aber es schaut halt einfach viel netter aus, so ein Totendiagramm. Und wenn man das in irgendeiner Präsentation hat, zum Beispiel von einer Public Company, einer Aktiengesellschaft, und da ist halt ein nettes Totendiagramm, wo dann irgendwie steht, was man wieder für eine Zahl irgendwie übertroffen hat, dann schaut es halt gleich vertrauenswürdiger aus, so ein Datendiagramm. Und darum macht man wahrscheinlich diese Diagramme auch. Ob die sinnvoll sind, ist eine andere Frage, aber das ist halt immer, wie weit Richtung Rohdaten willst du gehen und wer bist du? Und da sind wir auch, glaube ich, schon bei einem wichtigen Punkt, dass man die Daten jeweils aufbereiten muss für eine gewisse Zielgruppe. Data-Analysts greifen sicher anders auf Daten zu und schauen sich Daten sicher anders an als irgendein CEO oder du über unsere Podcast-Statistiken zum Beispiel.

Andy Grunwald (00:10:36 - 00:10:47)

Daten getriebene Entscheidungen, Daten-Geschütze-Unterscheidungen, Zielgruppe, habe ich alles verstanden. Jetzt ist es nun mal so, dass Daten ja das neue Gold sind, das neue Öl, oder ist das schon wieder ein Spruch von letzter Dekade?

Wolfi Gassler (00:10:47 - 00:10:49)

Ja, das ist schon wieder veraltet. Das ist schon wieder vorbei.

Andy Grunwald (00:10:50 - 00:11:23)

Ich frage mich halt gerade so ein bisschen, innerhalb einer Firma, wer macht denn die ganzen Sachen, also wer macht denn die ganzen Visualisierungen, macht das nur Data-Analysten und Data-Scientists oder kann irgendwie jeder vollkommen auf die Daten zugreifen, irgendwie mit Lesezugriff, weil ich kann mir schon vorstellen, dass da ab und zu auch je nach daten und je nach firmen kontext halt sensible daten drin sein könnten oder daten die gegebenenfalls gar nicht jedem zugänglich sein sollten also also wie wie ist das mit daten trans nimmt man das datentransparenz.

Wolfi Gassler (00:11:24 - 00:14:12)

Ja, ist natürlich ein wichtiger und guter Punkt, den du da ansprichst und ich glaube, da hat sich historisch auch extrem viel getan. Also gerade früher hatte man diese Spezialisten, diese Data Analysts, damals hatten sie nicht mal Data Analysts geheißen, vielleicht Business Intelligence Mitarbeiterinnen, die hatten so die Macht und die einzige Möglichkeit, sich irgendwie mit diesen Daten zu beschäftigen. Und meistens war es dann so, dass irgendwie die Geschäftsführung oder auch ein Team irgendwie gesagt hat, okay, wir brauchen diese Daten, wir wollen verstehen, wie dieses Produkt, dieses neue Feature performt, wie viel Umsatz da generiert wird, wir wollen irgendwie monatlichen Umsatz, jährlichen Umsatz, wir wollen da Sachen aufgeschlüsselt haben. Und dann haben sich irgendwelche Data Analysts hingesetzt und haben da SQL Queries geschrieben und haben da dieses klassische Reporting gemacht und dann bekommt der CEO oder das Team einfach so monatlich, wöchentlich, täglich so BDF Reports zum Beispiel gesendet. Das war früher so gang und gäbe, ist wahrscheinlich immer noch gang und gäbe in ganz vielen Firmen. Was man jetzt aber natürlich in den letzten fünf, würde ich mal sagen, bis zehn Jahren eigentlich so gemacht hat, ist, dass man immer mehr diese Daten zugänglich gemacht hat, dass die Teams und eigentlich fast jeder Zugriff oder mehr Zugriff bekommt, auf die eigentlichen Daten und Selbstauswertungen machen kann. Weil auch von Product-Ownern zum Beispiel wird erwartet, dass die vielleicht SQL schreiben können, aber zumindest grundsätzliche Datenauswertungen machen können. Natürlich passiert das meistens in irgendeinem Tool, dass das Ganze erleichtert, aber die Personen sollen selber Reports erstellen können, sollen auch einfach vielleicht interaktiv mit so Graphen interagieren können, wenn das Tool das jeweils unterstützt, dass man vielleicht so in die Tiefe gehen kann, dass man eben nicht nur so einen statischen PDF-Report hat. Und je nachdem, wenn jetzt zum Beispiel in diesem Monat vielleicht irgendein neues Produkt eingeführt worden ist, dass ich dann auch schnell checken kann, okay, wie schaut denn dieses Produkt aus, wie performt ist dieses Produkt. Und nicht, dass ich wieder extra einen Data-Analyst fragen muss, bitte, wir haben da ein neues Produkt, kannst du jetzt bitte einen Report auf dieses Produkt auch noch schreiben. Also da hat sich glaube ich viel gewandelt und da haben sich vor allem die Tools auch gewandelt, was heutzutage möglich ist. Google oder so große Firmen haben damit angefangen, dass die wirklich alle Daten zentral zur Verfügung gestellt haben in einem einheitlichen Modell. Aber das war natürlich nur möglich, weil die so groß waren. Mittlerweile ist das ganze Toolset so fortgeschritten und macht den Zugriff auf Daten eigentlich so einfach, dass das mittlerweile eigentlich fast jeder in einer Firma eigentlich machen sollte. Natürlich hat man dann vielleicht Zugriffseinschränkungen nochmal und gerade wieder bei Aktiengesellschaften oder so wird es natürlich schwierig, dass man auf irgendwelche Umsatzzahlen zugreifen kann oder jeder in der Firma. Das muss man dann natürlich dementsprechend abbilden, aber ehrlich gesagt in den meisten Firmen spielt es gar nicht so große Rolle und da ist es wichtiger, wenn man einfach agil und schnell sich weiterentwickeln will, dass man Zugriff auf Daten hat und dementsprechend auch Ausweitungen machen kann.

Andy Grunwald (00:14:12 - 00:15:12)

Das ist aber jetzt interessant. Du sagtest gerade, eigentlich sollte jeder in der Firma in der Lage sein, eigene Dashboards zu erstellen, eigene Daten zuziehen und so weiter und so fort. Bedeutet das in der Praxis, dass jeder irgendwie SQL lernen muss? Weil ich kann mir schon vorstellen, dass diese Daten ja in irgendwelche Datenbanken sind. In einer MySQL, in einer Postgre, oder ähnliches. Du hast gerade Google erwähnt. Vielleicht auch in einer BigQuery. Keine Ahnung, was es da inzwischen jetzt alles gibt. Und diese daten die haben ja jetzt oft keine wirklich beschreibenden namen ja also datenbankfelder sind ja keine ganzen sätze oder ähnliches sondern und die daten sind ja auch in tabellen organisiert und allem drum und dran also muss jetzt jeder in der firma der irgendwie ein bisschen zu viel daten hat sql lernen weil ich mein klar das selektion von tableware fu gleichbar kriegt jeder vielleicht noch hin aber, Besonders wenn es so um Summenbildung geht, Prozentzahlen, Gruppierungen, Crossjoins über Endtabellen, Unionstatements, Havings. Also ich meine, da sind wir ja schon dann im Bereich wirklich, wirkliche Softwareentwicklung in SQL.

Wolfi Gassler (00:15:12 - 00:16:02)

Also ich glaube, dass mittlerweile sehr viele Leute SQL können. Ich glaube, auch in einem Wirtschaftsstudium gehen wir davon aus, dass vielleicht so Grundlagen in SQL auch gelehrt werden. Aber die Tools haben sich so weiterentwickelt, dass du eigentlich auch ohne SQL imstande bist, grundlegende Abfragen zu schreiben, zusammen zu klicken eigentlich nur. Und wenn du da jetzt in der Management-Ebene zum Beispiel bist, dann funktioniert das auch mit den heutigen Tools super einfach und das sollte eigentlich jeder können und imstande dazu sein. Aber wenn man natürlich tiefer gehen will, dann muss man vielleicht mehr SQL können, beziehungsweise kann man halt auch dementsprechend andere Data-Analysts fragen. Oder die Data-Analysts oder Data-Scientists bereiten Daten auf, dass die in einem einfachen Format zur Verfügung stehen, auch erklärt sind. Und darauf operieren dann die eigentlichen End-User, wenn ich sie mal so nennen kann.

Andy Grunwald (00:16:02 - 00:16:19)

Du hast es jetzt schon das zweite Mal erwähnt, Daten aufbereiten. Und vorher hat es, glaube ich, Daten reinigen genannt. Aber was heißt das denn? Also, ich krieg jetzt irgendwelche Daten, ich krieg jetzt, sagen wir mal, Userlogs oder ... Ist ja egal was. Was ist denn ... Was muss denn da gereinigt werden? Was muss denn da aufbereitet werden?

Wolfi Gassler (00:16:19 - 00:18:53)

Ja, vielleicht gehen wir mal gleich direkt in die Architektur, wie so ein System aufgebaut ist. Also, grundsätzlich hat man üblicherweise einfach eine zentrale Datenbank, ein zentrales Repository, wo man alle Daten abspeichert. Das kann die klassische Datenbank sein, das kann eine spezielle Datenbank sein. Das können Analytics-Datenbanken sein, wie, keine Ahnung, Clickhouse zum Beispiel, oder wenn man jetzt in der Cloud ist, irgendwie BigQuery. Auf jeden Fall hat man ein zentrales System, wo man wirklich die Daten abspeichert. Natürlich ist es gar nicht so leicht, alle Daten dort reinzubekommen. Wenn man natürlich jetzt nur eine Datenbank in der gesamten Firma hat, eine große Oracle, eine große Postgres Datenbank, dann hat man eh schon alle Daten dort drin. Dann ist es natürlich einfacher, aber heutzutage hat man üblicherweise Daten in fünf verschiedenen Instanzen, vielleicht in MySQL, in Postgres, manche in Oracle, dann verwendet man irgendeine Cloud-Lösung, dann verwendet man irgendeine Software-as-a-Service und überall hat man Daten. Das heißt, man muss zuerst diese ganzen Daten exportieren über die Schnittstellen, und in eine zentrale Datenbank reinbekommen. Und dann hat man mal grundsätzlich die Rohdaten in dieser zentralen Datenbank vorliegen. Früher hat man das Data Warehouse genannt oder heute so ein typisches Schlagwort Data Lakes oder in der fancy Business Welt heißt dann halt Business Analytics Platform oder Business Intelligence. Also diese ganzen Begriffe, die sind halt Buzzwords, die eigentlich alle etwas ähnliches beschreiben, dass man halt in einer zentralen Datenbank oder Repository alle Daten zur Verfügung hat und ansprechen kann. Und wenn man diese Daten alle dann in diesem zentralen System hat, dann muss man die eben aufbereiten. Das kann, wie du jetzt gesagt hast, Cleaning sein, dass man irgendwie Ausreiser oder irgendwelche falschen Daten oder irgendwelche Daten, die keine Nullwerte beinhalten, die man vielleicht nicht für die Auswertungen haben will, dass man die vielleicht rausfiltert, dass man so gewisse Filterprozesse macht, aber dann vielleicht auch schon Gruppierungen macht, zum Beispiel so wie du gesagt hast, wenn man da dann irgendwelche komplizierten Joins machen muss. Im Idealfall hat man ja, wenn man jetzt als End-User auf das Ganze drauf schaut, dann hat man die Daten schon in einer schönen Form vorliegen. Und um eben die Rohdaten in diese schöne Form zu bekommen, vielleicht ein paar Joins zu machen, eben wenn da ein Artikel drinsteht, nicht nur die Artikelnummer hat, sondern auch den Namen des Artikels oder irgendeine Artikelbeschreibung, dann muss man da meistens einen Join machen, dass man einfach gewisse Joins macht. um die Daten dann möglichst einfach in einer schönen Form an den End-User schon weitergeben kann. Und das ist eben diese Aufbereitung, die man davor macht.

Andy Grunwald (00:18:53 - 00:19:12)

Okay, verstehe ich. Du machst dann also so eine Art Pre-Processing. Aber jetzt ist es ja so, dass du für ordentliches Pre-Processing ja schon irgendwelche Use-Cases im Sinn haben musst, oder? Weil ich mein, Beispiel, wenn du jetzt Summen bildest oder so, dann solltest du natürlich schon wissen, okay, über welche Zeiträume wird denn gefiltert oder Ähnliches.

Wolfi Gassler (00:19:12 - 00:20:27)

Die Summenbildung ist dann schon eigentlich für den End-User gedacht, aber zum Beispiel eben, dass man diese zentrale Tabelle der Käufe, wenn wir jetzt von einem Webshop zum Beispiel sprechen, wo nur irgendwelche IDs drinnen steht, dass man die einfach schon vorjoint, dass man die mit den Produkten joint, mit den User-Daten joint, um dann eine große Tabelle zu bekommen, wo man das schon schön aufgelöst hat, wo dann steht Produktname, Stadt des Kunden oder Land, wo der Kunde ist, dass man diese Sachen schon automatisch hat, dass man nicht da wieder selber 5 Joint schreiben muss, okay, ich habe jetzt Country 5, was ist denn eigentlich Country 5? Ah, Country 5 ist Deutschland, okay und der User 8, woher kommt der jetzt eigentlich und solche Sachen, dass also das wirklich schon pre-processed ist, damit das einfach zur Verfügung steht, aber die Summen bildest du dann drauf, also Die Idee ist schon, dass man diesen Würfel, man spricht ja oft von so einem Olap-Würfel, wenn man sich den bildlich vorstellt, wo man so mehrere Dimensionen hat, zum Beispiel eben die Zeit als eine Dimension, die Kunden als eine Dimension und die Produkte als eine Dimension, das ist so das klassische Beispiel immer, dann hat man so einen dreidimensionalen Würfel und jeder Punkt in diesem Würfel ist ein Einkauf von einem Produkt von einem Benutzer zu einem gewissen Zeitpunkt. Und diesen riesen Würfel, den verwendet man dann, um die eigentlichen Anfragen zu machen.

Andy Grunwald (00:20:28 - 00:20:29)

Wofür steht OLAP?

Wolfi Gassler (00:20:29 - 00:20:58)

OLAP und OLTP ist das Gegenstück. Das ist Online Analytic Processing. Das sind OLAP Queries und OLTP ist Online Transactional Processing. Das eine sind die Analytics-Datenbanken. OLAP-Anfragen macht man in der Analytics-Datenbank und OLTP ist die klassische Datenbank, wo es mehr um Transaktionen geht. Schnelle, kurze Transaktionen, viele Queries, die da gesendet werden. zu der Live-Betrieb eigentlich. So hat man die zwei Sachen früher unterschieden. Heutzutage macht man eh fast beides automatisch immer im selben Datenbanksystem.

Andy Grunwald (00:20:58 - 00:21:10)

Okay, wir preprocessen die Daten jetzt und joinen irgendwelche relevanten Beschreibungstexte für Menschen dagegen und so weiter und so fort. Bedeutet das dann auch, dass wir eine Kopie von den Daten anlegen? Dass wir diese dann doppelt vorhalten?

Wolfi Gassler (00:21:10 - 00:21:28)

Es kommt natürlich auf das System drauf an, aber meistens sind da im Hintergrund einfach nur die Queries, die dann dynamisch so wie ein View, also man kann auch ein View verwenden im Prinzip, der dann im Hintergrund dynamisch ausgeführt wird. Also man speichert nicht alles doppelt, aber manchmal kann es auch Sinn machen, das unter Umständen zu duplizieren.

Andy Grunwald (00:21:28 - 00:21:32)

Das bedeutet, so Themen wie Datenbanken Normalform haben da gar nichts zu suchen, oder?

Wolfi Gassler (00:21:33 - 00:21:44)

Man optimiert das dann je für den Anwendungsfall und wenn der Anwendungsfall Analytics ist und in dem Fall das gerechtfertigt ist, dann optimiere ich das für diesen Anwendungsfall und dann kann ich Normalformeln einfach mal weglassen oder ignorieren.

Andy Grunwald (00:21:45 - 00:21:58)

Du hast zum Beispiel vorhin einmal ganz kurz eine spezielle Datenmarktechnologie erwähnt, Clickhouse. Was ist Clickhouse und warum ist die toll oder ist die toll überhaupt oder ist das jetzt einfach nur vor auf deinem Screen durchgeflogen?

Wolfi Gassler (00:21:58 - 00:22:55)

Clickhouse ist ein MySQL Drop-In Replacement, das vor allem für Analytics Queries optimiert ist, also dass die typischen analytischen Anfragen schneller sind, eben auf diese OLAP Queries optimiert ist und nicht auf die OLTP Queries optimiert sind. Aber da gibt es jede Menge. Also Clickhouse ist halt jetzt eine Datenbank, aber es gibt natürlich auch in der Cloud ganz viele Produkte, kommerzielle Produkte. Clickview ist ein bekanntes Tableau. Microsoft hat natürlich was mit Power BI, AWS und GCP haben beides natürlich auch Produkte dafür. QuickSight heißt es bei AWS, Data Studio bei GCP. Auf der Datenbankebene wäre es dann BigQuery im Hintergrund in Google Cloud. Looker wäre auch nur so ein Produkt, das die Visualisierung ermöglicht. Also die haben dann meistens auch Visualisierung eingebaut. Das sind nicht nur Datenbanken. Clickhouse wäre jetzt nur eine Datenbank. Aber darüber baut man sich dann ein Visualisierungslayer, der dann eben deine beliebten Totendiagramme auch zeichnet.

Andy Grunwald (00:22:56 - 00:23:02)

Du hattest gerade gesagt, für Leute, die sich mit Visualisierung professionell beschäftigen, sind Tortendiagramme auch Blödsinn. Warum?

Wolfi Gassler (00:23:02 - 00:23:41)

Also keine Ahnung, ob das jetzt alle professionellen Leute auch befürworten, dass die wenig sinnvoll sind, aber wenn ich es mir so überlege, ich habe auch in meinem Leben selten irgendwelche Tortendiagramme gemalt und habe auch wenig aus Tortendiagrammen bisher herausgelesen. Wie gesagt, das sind meistens zwei, drei Werte, die du da rauslesen kannst, wenn du die Werte einfach in einer Tabelle hast oder nebeneinander stehen, dann hast du das im Prinzip auch. Und die ganzen kleinen Bereiche, wie da die Aufschlüsselung ist, das kann man dann meistens eh nicht mehr lesen, dann gibt es irgendwelche Linien zu den Prozenten, die eben nicht mehr lesbar sind in dem Datendiagramm und sowas. Also persönlich bevorzuge ich da eine Tabelle, aber vielleicht arbeite ich auch zu viel mit Daten, dass ich den Sinn in Datendiagrammen nicht sehe.

Andy Grunwald (00:23:42 - 00:24:19)

Okay, ich habe jetzt die Daten in meinem Data Storage, habe da ein paar Schritte zur Datenbereinigung gemacht, vielleicht auch schon zur Vorkalkulierung. So und jetzt kommt ja meines Erachtens nach vielleicht sogar die Königsdisziplin. Lass uns mal irgendwie Sinn aus diesen Daten machen. Das bedeutet, Lass mich mal auf einen schönen Graphen gucken, der HockeyStickGrowth von unserem Podcast ausdrückt. Das bedeutet, lass uns mal in die Visualisierung einsteigen oder erklär mir doch vielleicht auch mal, wie finde ich denn auf Basis dieser Daten heraus, welche Fragen ich eigentlich stellen möchte.

Wolfi Gassler (00:24:20 - 00:25:49)

Also dieses Tool, das uns den Hockeystick-Growth anzeigt, das gibt es leider noch nicht. Also zur Erklärung, wer das jetzt nicht weiß, Hockeystick-Growth ist dieses Wachstum, diese Kurve, die aussieht wie ein Hockeyschläger, die am Anfang ganz flach ist und dann plötzlich nach oben schießt. Aber vielleicht kommen wir ja noch dazu. Also wir sind derzeit noch im unteren Bereich von dem Hockeyschläger, aber zum nächsten Bereich kommen wir dann erst. Aber um auf die Visualisierung zu kommen, die Visualisierung ist natürlich die schwierige Sache, und zwar nicht diese Graphen zu erstellen, weil die Tools, um jetzt irgendwie einen Graph zu erstellen, das ist nicht so schwierig, sondern einen sinnvollen Graphen zu erstellen und auch zu wissen, was man denn überhaupt darstellen will. Und da gibt es ja auch die Unterscheidung zum Beispiel, du hast es mal erwähnt, zwischen Data Scientist und Data Analyst. Die einen bekommen die Frage schon gestellt und probieren dann die Frage zu beantworten und die anderen probieren eine Frage überhaupt zu finden aus den Daten, also mehr so explorativ zu arbeiten. Was kann ich denn aus den Daten wirklich rauslesen? Im Gegenzug, wenn der CEO jetzt einfach fragt, okay, was ist unser Umsatz dieses Monat? Ist eine klare Frage, kann ich dann relativ schnell abbilden. und dem kann ich eine schnelle Visualisierung bauen. Wenn es dann aber darum geht, wo sollen wir uns hin entwickeln, was haben wir denn da für Möglichkeiten, was haben wir überhaupt für Daten, wie können wir die Daten sinnvoll verarbeiten, das ist dann halt, wie du sagst, die Königsklasse und es ist nicht umsonst, dass es da in dem Bereich viele Jobs gibt und auch viele Profiles, was man heutzutage eben machen kann, Data Analyst, Data Scientist und Senior Data Scientist und was es nicht alles so gibt.

Andy Grunwald (00:25:49 - 00:26:12)

Wolfgang, so wie du es beschreibst, hört sich die ganze Sache aber ziemlich teuer und sehr professionell an. Also das bedeutet, wir heben jetzt Daten, speichern die in irgendwelchen komplexen Datenbanken, von denen ich noch nie gehört habe, dann müssen die gereinigt werden und dann müssen da irgendwie Joins gemacht werden, um einen Artikeltext zu einer Artikelnummer zu joinen zur Vorbereitung. Muss ich jetzt zwei Leute einstellen, nur damit ich ein paar Graphen haben kann oder wie sieht sowas heutzutage aus?

Wolfi Gassler (00:26:12 - 00:28:25)

Wie ich schon eingangs erwähnt habe, war das früher wahrscheinlich so. Und früher hast du da wirklich ein, zwei Leute gebraucht, die sich nur um die Daten gekümmert haben. Und klar, in großen Firmen brauchst du da auch Teams, die das Ganze näher betrachten. Aber mittlerweile ist das Toolset eigentlich so gut, dass das wirklich super easy ist und auch in einem kleinen Site-Project zum Beispiel gemacht werden kann. Überhaupt kein Problem. Weil du hast die Datenbank üblicherweise, wo die Daten drin sind. Also du hast die Daten schon. Gehen wir mal davon aus, dass jetzt nicht unbedingt das Cleaning oder so so wichtig ist und von uns kann jetzt jeder SQL. Und dann gibt es eine Menge Visualisierungs- und Exploration-Tools, die man verwenden kann. Da gibt es auch Open-Source-Tools, super einfach zum Installieren. Und die greifen einfach direkt auf deine Datenbank zu und du kannst dort drinnen SQL-Query schreiben. siehst die Daten, siehst die sofort visualisiert und manche Tools gehen eben so weit, dass man nicht mal SQL schreiben muss, sondern da gibt es Wizards, die dir ein clicky-bunty Interface zur Verfügung stellen und dir SQL im Hintergrund dann schreiben und du da wirklich visuell mit den Daten arbeiten kannst und reintauchen kannst. Das sind mittlerweile super Tools, die das Leben stark vereinfachen und da kannst du auch bei einem einfachen Site-Project einfach dieses Tool aufsetzen, um sie mal zu erwähnen, das ist zum Beispiel Metabase, Superset, Redash gibt's da, oder auch ganz klassisch kennen vielleicht viele, Grafana eignet sich eigentlich dafür auch ganz gut, dass man sich kleine Dashboards baut und einfach ein bisschen historisch betrachtet, okay, wie gut performt, mein Side-Project, aber kann natürlich auch im professionellen Umfeld sein, wenn es darum geht, Umsatzzahlen rauszubekommen und da wirklich zu wissen, welches Produkt performt wie. Wir verwenden das selbst für unseren Podcast auch, beziehungsweise für das Open-Podcast-Projekt, wo es darum geht, Podcast-Daten zu visualisieren. Also diese Tools sind sehr, sehr mächtig und da kann man viel rauslesen. Man muss sich natürlich mit den Daten beschäftigen. Also von selber passiert natürlich nichts, dass jetzt automatisch irgendwelche tollen Erkenntnisse daraus gewonnen werden können. Aber wenn man sich mal dafür interessiert und so grundsätzliche Daten visualisieren will, dann ist das sehr, sehr einfach möglich. Was man früher vielleicht irgendwie kompliziert mit Excel oder so gemacht hat oder mit Report Generator kann man so in einem dynamischen Weg ganz einfach mit diesen Visualisierungstools machen.

Andy Grunwald (00:28:25 - 00:28:54)

Ich stelle mir gerade die Frage, du hast gerade gesagt, okay, die meisten Tools bieten dir irgendwie so eine grafische Oberfläche an, um dir Queries und Dashboards zusammen zu klicken. Und da stelle ich mir halt die Frage, okay, immer wenn ich von sowas höre, datengetriebene Entscheidungen, verbinde ich auch irgendwie mit vielen Daten vielleicht, wartet man dann auf jedes Dashboard eine Minute? Weil ich kann mir schon vorstellen, dass ein User-Interface jetzt nicht gerade die höchste Rate der Performance-Optimierung an deinen SQL-Query legt. Das ist natürlich auch limitiert in irgendeiner Art und Weise.

Wolfi Gassler (00:28:55 - 00:29:25)

Also wenn du wirklich so groß bist, dass du so viele Daten hast, dann kannst du dir wahrscheinlich auch ein paar Leute leisten oder ein ganzes Team, die dir das optimieren und die Plattform natürlich noch besser zur Verfügung stellen. Aber ich würde mal sagen, heutzutage die Datenbanken sind alle so leistungsstark, dass wenn du da auch komplexere Queries ausführst und wenn wir da jetzt von ein paar Gigabyte an Daten sprechen, dann hat man normalerweise kaum das Problem, dass man da irgendwie Performance-Probleme hat. Und im schlimmsten Fall braucht dann halt mal ein Dashboard 30 Sekunden oder so. Aber wenn das regelmäßig einfach generiert wird, ist das ja auch nicht so das Problem.

Andy Grunwald (00:29:25 - 00:29:44)

Du hast jetzt gerade gesagt, die Datenbanken sind so optimiert und wir reden ja auch von Analytics-Datenbanken. Du sagtest gerade, dass Clickhouse auch so eine Datenbank ist, die auf Analytics optimiert ist. Wenn wir über sowas reden, was heißt das denn, dass eine Datenbank auf Analytics optimiert ist? Also was ist denn da optimiert im Vergleich zu einer klassischen MySQL oder einem klassischen Postgre?

Wolfi Gassler (00:29:44 - 00:31:00)

Das kann man natürlich jetzt nicht ganz allgemein beantworten, aber einen Trend, den es gibt, sind die spaltenorientierten Datenbanken. Da haben wir ja schon in einigen Episoden darüber gesprochen. Da kann man auf unsere Webseite gehen und auf das Tag Datenbanken klicken. Verlinken wir natürlich auch in den Show Notes. Da haben wir einige Datenbank Episoden schon zu diesem Thema. Aber da werden Daten auch anders abgespeichert. Und wie du zuerst gesagt hast, da vergisst man dann vielleicht auch auf die Normalform, dass man wirklich Daten dupliziert, damit man schneller darauf zugreifen kann. Aber ein klassisches Beispiel wäre das Geschlecht in der Tabelle. Da hast du immer nur zwei Werte. Männlich, weiblich, männlich, weiblich oder vielleicht mal drei oder vielleicht auch fünf. Egal, auf jeden Fall hast du über Millionen von Zeilen immer nur fünf Ausprägungen und das kannst du dann sehr gut optimieren, dass du dir das abspeicherst in einer optimierten Form und wenn du dann eine Anfrage über das Geschlecht machst, welches Produkt wird eher von weiblichen Kunden gekauft zum Beispiel oder von männlichen Kunden, dann kannst du so eine Anfrage extrem schnell beantworten, weil du nur dieses Geschlecht dediziert abspeicherst in der optimierten Form. Und so arbeiten dann analytische Datenbanken, dass die eben auf diese Patterns, die man da üblicherweise hat, optimiert sind und dementsprechend auch die interne Organisation und die Speicherstruktur dementsprechend auf diesen Use Case hin Du.

Andy Grunwald (00:31:01 - 00:31:15)

Hattest gerade gesagt, da gibt es irgendwie Tools und die machen ganz viel Magie und das ist ganz einfach. Das bedeutet, ich muss mir jetzt nicht die 3JS nehmen und Tortengramm-JS und baue mir meine eigenen Analytics-Frontends. Also das brauche ich alles nicht mehr oder muss ich das schon noch machen?

Wolfi Gassler (00:31:16 - 00:31:55)

Ich war selber sehr erstaunt, wie ich vor einiger Zeit mal mich mit diesem Thema beschäftigt habe, wie weit diese Tools schon alle sind. Also ein bekanntes Tool ist eben Metabase, ist Open Source. Und das Ding installierst du dir zum Beispiel über Docker, ist ein Docker-Image. dem sagst du, okay, das ist meine Datenbank, die bindest du an oder auch mehrere Datenquellen, kannst du mehrere Datenquellen anbinden und dann hast du ein vollwertiges System mit einer User-Verwaltung, mit einer Verwaltung von dem ganzen Datenmodell, du hast SQL-Wizards, das heißt, du kannst ganz einfach abfragen, selber erstellen ohne SQL zu schreiben, du kannst aufwendige SQL-Quiz schreiben und kannst dir dann.

Andy Grunwald (00:31:57 - 00:32:00)

Warmes Bier, ich sag's dir.

Wolfi Gassler (00:32:00 - 00:34:55)

Und kannst dann auswählen, was für eine Visualisierung du haben willst, ein Totentdiagramm oder irgendwelche Grafen, Tabellen, kannst diese sortieren, kannst es in Dashboards ablegen, kannst die Dashboards teilen über einen Public Link zum Beispiel, du brauchst nicht mal einen User haben dann dafür, das heißt, du kannst es auch mit der Außenwelt teilen, das Ganze wird aktualisiert. Du kannst Alert schalten, dass du bei E-Mail diese Reports zugesendet bekommst. Also das ist wirklich super, super einfach. Und da gibt es eben nicht nur Metabase. Superset ist ein anderes. Das ist von der Apache Foundation. Ist in Python prima geschrieben. Ist vielleicht weniger user-friendly als Metabase, würde ich sagen. Kann viel, viel mehr Graph-Typen. Die haben, glaube ich, so um die 300 Graph-Typen, die sie unterstützen. Also da hast du dann nicht nur ein Totendiagramm, sondern drei Variationen von speziellen Totendiagrammen wahrscheinlich. Aber da kannst du wirklich fancy Grafiken damit bauen. Dafür ist es vielleicht die Zielgruppe mehr in Richtung Data Analysts, also Leute, die sich wirklich mit Daten beschäftigen, während Metabase wirklich super einfaches User Interface hat und sehr user friendly ist. Und man da auch dann zum Beispiel bei gewissen Graphen ganz einfach mit so einer Lupenfunktion eben so drill-down-Funktionen starten kann, dass man wirklich reinzoomt in die Daten, ohne dass man das irgendwie programmiert oder definiert, sondern dass man da so wirklich ganz, ganz einfach mit den Daten arbeiten kann. Der Vollständigkeit halber, Redash gibt es auch noch auf dem Visualisierungsmarkt, ist ebenfalls Open Source, wie eben auch Superset und Metabase, ist auch in Python geschrieben, ist ein bisschen neuerer Player, ist meiner Meinung nach weniger user-friendly. Gibt es eigentlich ein deutsches Wort? Benutzerfreundlich, danke. Ist weniger benutzerfreundlich, ist vielleicht auch ein bisschen mehr buggy, was ich so mitbekommen habe, aber hat auch sehr viel Potenzial und ist eben auch sehr, sehr leistungsstark. Grafana haben wir schon öfters erwähnt, in der DevOps-Welt kommt mehr aus der DevOps-Ecke, aber alle, die mal mit Grafana gearbeitet haben, da kann man natürlich auch im Hintergrund einfach SQL Query schreiben und sich ein Dashboard zusammen klicken. Ist jetzt aber weniger für diesen speziellen Use Case, für die Visualisierung, für die Exploration von Daten eigentlich gemacht und hat dadurch natürlich auch ein paar Nachteile. Aber wer natürlich jetzt schon Grafana hat und sich vielleicht schnell ein Dashboard zusammen klicken will, der kann natürlich das genauso mit Grafana machen, ohne jetzt was Neues wirklich aufzusetzen. Aber wie gesagt, die anderen sind super einfach. Das ist meistens ein Docker-Image. Die haben automatisch irgendwie 10, 20 Datenbank-Anbindungen built-in. Automatisch kann man also wirklich auf die meisten Datenquellen, Datenbanken zugreifen und kann sich dann schöne Statistiken zusammenbauen. Und wir können auch gerne mal so ein paar Statistiken verlinken. Wir haben auch kürzlich gerade was getweetet bezüglich Spotify und Apple, wie unsere Hörerschaft sich da verhält. Auch das war mit Metabase generiert. Da steckt einfach eine SQL-Query dahinter, die auf die Rohdaten zugreift und dann dementsprechend die Visualisierung in einer sehr schönen Form baut.

Andy Grunwald (00:34:55 - 00:35:10)

Grafana kenne ich natürlich aus dem, wie du gesagt hast, DevOps-Cloud-Bereich. Ich hätte es jetzt nicht direkt mit klassischen KPIs und Firmenanalytics in Verbindung gebracht, oder ich habe auch bisher noch niemanden gesehen, der klassische AB-Test-Auswertungen mit Grafana macht.

Wolfi Gassler (00:35:10 - 00:35:20)

Wäre aber wahrscheinlich möglich. Also ich glaube, du könntest das schon so weit umbauen, weil du ja im Hintergrund auch nur SQL-Query schreibst. Insofern wäre das möglich, aber es ist nicht dafür gemacht, ja.

Andy Grunwald (00:35:21 - 00:35:41)

Sofern du natürlich den SQL-Adapter drin hast und allem drum und dran, aber ich würde fast sagen, dass Grafana schon eher für technisch versierte Leute ist, weil so wie das aufgebaut ist und auch wie du die Queries schreibst, je nach Datenbank und so weiter und so fort, dann gibt es natürlich Grafana eigene Funktionen, wenn es an die Zeitfilter geht und Co.

Wolfi Gassler (00:35:41 - 00:36:17)

Ja, was mir einfach wichtig ist, ist, dass man Grafana vielleicht auch oft vergisst. Du bist jetzt ein Techie, ein Developer und hast da ein cooles Site-Project und setzt dir da ein Grafana-Dashboard auf für deine Servermetriken. Und wenn du dann irgendwelche Businessmetriken haben willst, wie viele neue Signups hat man oder solche Dinge, dann überlegt man sich da vielleicht schon, ah, jetzt brauche ich ein Metabase oder ein Superset oder whatever. Aber eigentlich kann man auch ganz normal ein Dashboard in Grafana da mitbauen. für diese Businessmetriken. Also das sollte kein Problem sein und funktioniert auch mit Grafana gut. Also wer schon Grafana hat, vielleicht auch dran denken, man kann ein paar Businessmetriken auch damit.

Andy Grunwald (00:36:17 - 00:36:39)

Okay, jetzt hast du mir ein paar Tool-Namen um die Ohren geschmissen und jetzt hast du gesagt, okay, auch wenn du Grafana hast, nimm Grafana. Welche Tipps würdest du mir in die Hand geben, wenn ich jetzt wirklich mich heute Abend nochmal hinsetze und mal versuche mein erstes Dashboard zu bauen? Was denkst du, worauf sollte man achten? Was sind die zwei oder drei Do's in die zwei oder drei Don'ts, die du Neulingen an die Hand geben würdest?

Wolfi Gassler (00:36:40 - 00:37:04)

Ja, man muss zuerst natürlich mal wissen, was will man überhaupt messen. Wie es halt überall so ist, weil du musst dir irgendwo Ziele setzen. Wenn du jetzt im Sport ohne Ziele irgendwas messen willst, das wird halt schwierig, weil du arbeitest ja üblicherweise irgendwo hin. Das heißt, man muss sich überlegen, okay, was ist wichtig für mein Projekt, für meine Firma, was für KPIs. Jetzt wollte ich gerade sinnvoll erklären, was KPIs heißt. Andi, was heißt KPIs?

Andy Grunwald (00:37:04 - 00:37:05)

Key Performance Indikatoren.

Wolfi Gassler (00:37:05 - 00:37:10)

Ja, dafür habe ich dich, Andi. Key-Performance-Indikatoren, wie heißt das auf Deutsch?

Andy Grunwald (00:37:10 - 00:37:14)

Ich weiß es nicht, ich gebe das jetzt bei DeepL ein.

Wolfi Gassler (00:37:14 - 00:37:16)

Schlüsselkennzahlen, Andi.

Andy Grunwald (00:37:16 - 00:37:18)

Wichtige Leistungsindikatoren.

Wolfi Gassler (00:37:18 - 00:39:12)

Leistungsindikatoren klingt natürlich noch besser. Genau, also bei einem Sport will ich wissen, okay, wie schnell bin ich beim Laufen zum Beispiel, wenn ich auf einem Marathon hin trainiere. Bei meinem Produkt will ich vielleicht wissen, wie viele neue User habe ich, wie viele User verliere ich, solche Dinge. Hörer und Hörerinnen habe ich für ein Podcast zum Beispiel, also alle diese Dinge, wo ich mich vielleicht auch verbessern will in Zukunft, weil ich will ja mehr Hörerinnen zum Beispiel bei einem Podcast oder ich will mehr Umsatz bei einer Firma, das wären halt dann dementsprechend KPIs und diese KPIs muss ich mal definieren, damit ich dann überhaupt Anfragen schreiben kann und vielleicht auch dann sehe, dass es gar nicht so einfach ist, weil wenn es darum geht, wenn ich rausfinden will, wie viel User habe ich denn, wie viel User verliere ich, dann ist es vielleicht gar nicht mehr so einfach, das in SQL abzubilden und es ist dann schon komplexer, das aus meinen Daten rauszulesen, diese Retention von Usern zum Beispiel. Also wenn ich diese KPIs habe, dann kann ich dementsprechend die SQL Queries erstellen und daraufhin dieses Dashboard und dann habe ich mal einen guten Start, mit dem man mal anfangen kann, beginnen kann Und später kann man dann natürlich sich überlegen, okay, ich habe so viele Daten, was könnte ich denn noch alles rauslesen? Was habe ich für Daten zur Verfügung? Kann da explorativ durchgehen? Wenn ich da zum Beispiel jetzt Podcasts wieder als Beispiel nehmen darf, wenn wir herausfinden, wie viele Hörerinnen wir haben pro Episode und wir auch sehen über Spotify und Apple, wie viel Prozent von einer Episode werden angehört, dann können wir auch Rückschlüsse daraus ziehen, wie interessant Themen sind und welche Themen bei unserer Hörerschaft gut ankommen. Und solche Dinge wird man vielleicht nicht beim ersten Dashboard natürlich herauslesen und probieren zu beantworten, aber diese Dinge kann man dann über die Zeit, wenn man mehr mit den Daten arbeitet, natürlich auch rauslesen und sich vielleicht dann auch Gedanken machen, was kann ich denn noch alles aus meinen Daten rausbekommen, wenn ich sie sinnvoll verbinde, Korrelationen vielleicht mache in den Daten, um dann eben meine Entscheidungen in Zukunft besser treffen zu können.

Andy Grunwald (00:39:13 - 00:39:30)

Wenn ich hier jetzt so reden höre mit explorativ, ich schaue mir die Daten an, überlege, was ich wirklich wissen möchte, lese die Daten, überlege, ob ich noch eine Follow-up-Frage habe und so weiter und so fort, dann hört sich das ziemlich aufwendig und zeitintensiv an. Wie viel Zeit verbringst du eigentlich in den Daten für deine nächsten Entscheidungen?

Wolfi Gassler (00:39:30 - 00:39:32)

Sehr wenig, weil ich ja ein sehr bauchgetriebener Mensch bin.

Andy Grunwald (00:39:32 - 00:39:48)

Wundervoll, dass wir eine Episode über datengetriebene Entscheidungen machen. Klasse. Aber das ist ein gutes Stichwort. Ist der Bauch generell falsch oder sind datengetriebene und datenunterstützte Entscheidungen the new normal? Also fällt der Bauch komplett weg?

Wolfi Gassler (00:39:48 - 00:41:24)

Also wie gesagt, ich glaube, dass der Bauch schon auch lernt, weil es ist ja einfach die Erfahrung, die man hat. Man hat irgendwas gelernt und man weiß nicht genau so, warum das ist, aber man hat halt einfach aus der Erfahrung gesehen, das funktioniert gut und darum macht man es wieder. Man sollte halt nicht darauf alleine das ganze passieren und ich glaube Daten sind schon sehr sehr wichtig, weil auch wenn wir jetzt wieder bei dem Podcast Thema sind, wir zwei haben natürlich eine sehr genaue Meinung, was interessante Themen sind und wir haben aber keine Ahnung, wie die Hörerschaft zu draußen reagiert und das haben wir auch gesehen, wie das Wartungsfenster ganz anders an Dinge herantritt und diese Sachen kannst du dann über Daten am ehesten lösen, indem du eben die Daten sammelst und dann mehr Informationen bekommst, als was du jemals mit deinem Bauchgefühl abdecken könntest. Und da sind natürlich Daten schon hilfreich. Und ich versuche natürlich auch möglichst viele Daten zu bekommen. Aber man hat halt nicht immer alle Daten zur Verfügung. Und sogar wenn man alle Daten zur Verfügung hat, heißt es nur lang nicht, dass die Entscheidung so einfach ist. Wenn wir als Beispiel nehmen die ganzen Covid-Entscheidungen. Da waren die Daten vorhanden. Du hast genau gewusst, Wie viele Geimpfte, wie viele Infizierte, die Daten waren alle da. Aber dann eine Entscheidung zu treffen, politisch, was du daraus machst mit den Daten, ist ja auch nicht so einfach. Also nur weil du Daten zur Verfügung hast, heißt es noch lang nicht, dass die Entscheidungen einfacher werden. Aber du hast halt das als zusätzlichen Input, zu deinem Bauch vielleicht auch, zu anderen, Meinungen und wenn die Daten natürlich gut sind, Daten können natürlich auch einfach schlecht sein und dementsprechend nicht wirklich verwendbar, aber wenn die Daten möglichst gut sind, dann helfen sie dir bei deinen Entscheidungen und das sind eben genau diese Data Supported Decisions.

Andy Grunwald (00:41:25 - 00:42:29)

Jetzt hast du gerade darüber gesprochen, okay, wenn wir uns zum Beispiel die Hörer von unserem Podcast ansehen, um herauszufinden, welches Thema interessant ist. Jetzt ist es natürlich bei Podcasts so, genauso wie bei sehr vielen anderen Medien, dass es dieses klassische Sommerloch gibt. Das bedeutet, du hast Faktoren, die du nicht beeinflussen kannst, die deine Daten beeinflussen. Und jetzt stelle ich mir die Frage, da gibt es ja sowas wie die statistische Signifikanz. Ab wann sind denn diese Daten aussagekräftig? Und da frage ich mich, nur weil ich die Daten hab, heißt das ja nicht, dass die aussagekräftig sind, oder? Jetzt mal angenommen, wir haben das Sommerloch überstanden. Und angenommen, die Monate oder die Jahreszeiten spielen bei unseren Hörern jetzt eine Rolle, okay, und jetzt sind wir im Ende September, Anfang Oktober. Und aus irgendwelchen Gründen haben wir ganz viele Hörer aus München, Was ist denn Ende September, Anfang Oktober immer in München? Ich denke, dass das Oktoberfest schon einen Einfluss auf unseren Podcast haben könnte. Und jetzt frage ich mich natürlich, inwieweit sind unsere Podcast-Hörerdaten signifikant oder statistisch relevant, wenn das Oktoberfest ist?

Wolfi Gassler (00:42:29 - 00:44:51)

Also grundsätzlich bei unserem Podcast ist mal ganz klar, dass alle Episoden nachgehört werden. Egal ob bei Oktoberfest, bei Sommerloch oder sonst was, unsere Hörerinnen sind so committed, dass alles nachgehört wird. Davon können wir ja mal ausgehen, würde ich sagen. Aber du hast schon recht, das Problem ist immer, dass du ganz viele Einflussfaktoren hast und es ist halt sehr schwierig, die alle rauszufiltern. Ein ganz klassisches Beispiel ist, du führst jetzt irgendein neues Feature ein, auf deinem Webshop zum Beispiel, und der Umsatz geht nach unten. Dann würdest du meinen, okay bei diesem Feature, das hat negative Auswirkungen und damit verkaufen wir weniger. Jetzt kann es aber sein, dass im Hintergrund zufällig zur selben Zeit irgendwie das tolle DevOps Team oder die Admins irgendwas geändert haben und die Webseite ist plötzlich um 20% langsamer und nur darum gibt es weniger Käufe. Das heißt, wenn du auch nur so einfache Tests machst, dann kann es natürlich sein, dass du gewisse Parameter einfach nicht kennst und die beeinflussen natürlich das Ganze. Oder eben auch Einflüsse von außen, Wirtschaftslage, andere Dinge und das macht es natürlich dann schon schwieriger mit einzuberechnen. Darum gibt es ja dieses A-B-Testing, dass ich eben parallel zwei Tests laufen lasse, weil dann sind A und B langsamer durch die Änderung durch die Administratoren und dann solltet ihr das rauslesen können. Aber das ist nur ein Beispiel und das zeigt halt, wie schwierig das Ganze ist mit Daten und wie Daten auch falsch interpretiert werden können, vielleicht manche Daten eben falsch sind oder man einfach die Entscheidungen dann falsch trifft. Und darum ist es eben wichtig, dass man nicht nur auf die Daten vertraut und halt auch sinnvoll mit den Entscheidungen umgeht und da durchaus auch noch ein Bauchgefühl oder andere Faktoren mit einbezieht und nicht nur die reinen Daten und nur Daten, das ist das einzig Wahre. Und manchmal hat man auch einfach keine Daten. Das kann natürlich auch passieren oder zu wenig. Da spielt übrigens auch dieses Thema mit qualitative und quantitative Daten noch mit rein, weil du kannst natürlich auch, wenn du ganz viele quantitative Daten von deinen Logs, von deinem Webserver hast, kannst du natürlich auch qualitative Daten erheben, indem du User-Umfragen machst. Und da hast du vielleicht dann weniger Daten, aber bekommst halt zusätzlich noch mehr Dimensionen mit rein und da kannst du natürlich auch vielleicht so technische Fehler oder so dadurch abfangen, weil du halt diese qualitativen Daten auch nochmal hast. Also auch da kannst du natürlich probieren, mit qualitativen und quantitativen Daten mehr Informationen zu bekommen, um die Entscheidungen dann noch besser zu treffen.

Andy Grunwald (00:44:51 - 00:45:03)

Aber immer wenn ich jetzt sowas höre wie User-Umfragen, dann denke ich immer an manuell erhobene Daten und dann denke ich immer an einen erhöhten Säuberungsaufwand, einen erhöhten Cleaningaufwand, weil die ja nicht maschinell strukturiert erhoben wurden.

Wolfi Gassler (00:45:04 - 00:45:13)

Ja, oder du brauchst gar nichts cleanen, weil du hast nur 50 Leute befragt und dann liest du dir einfach diese 50 Fragebögen durch oder 20. Aber die können auch sehr aussagekräftig sein und sehr hilfreich.

Andy Grunwald (00:45:13 - 00:45:22)

Ich glaube, ich würde sogar die 50 Antworten irgendwie automatisieren. Ich glaube, ich würde da stundenlang reinsetzen, um irgendwas zu automatisieren, was vielleicht in 10 Minuten gelesen werden würde.

Wolfi Gassler (00:45:23 - 00:45:49)

Ja, wenn du gerade so freie Textfelder hast oder freie Fragen, wo du halt sagst, okay, was stört dich, was würdest du besser machen, so offene Fragen, dann ist es halt schwieriger, das zu automatisieren und in eine tabellarische Form zu bringen. Ist natürlich teilweise auch möglich, aber solche qualitativen Umfragen haben meistens einen anderen Zweck und ergänzen dann nur die quantitativen Daten dementsprechend für diese Bereiche, die eben über die quantitativen Daten nicht abgefragt werden können.

Andy Grunwald (00:45:49 - 00:46:00)

Wen würdest du denn von den großen Firmen als Vorreiter in dem Bereich sehen? Also wo weißt du zum Beispiel, dass das wirklich in Fleisch und Blut übergegangen ist?

Wolfi Gassler (00:46:00 - 00:47:26)

Ja, ich würde jetzt Trivago sagen, aber teilweise eben sogar zu datengetrieben unter Umständen. Aber auch Google hat ganz früh damit angefangen und die haben eben ein zentrales System zur Verfügung gestellt, wo jeder in der Firma Zugriff auf alle Daten hat, möglichst einfachen Zugriff, um eben solche datengetriebenen Entscheidungen treffen zu können. oder mehr Daten und Informationen zur Verfügung haben. Aber es ist ja nicht nur ein System, das du brauchst. Du brauchst auch die Kultur in der Firma, dass man einfach immer auf Daten zurückgreift, dass das auch normal ist, dass man Daten präsentiert und dass man einfach sagt, okay, ich bin der Product Owner, ich mache das jetzt so, weil ich glaube, das ist richtig, sondern dass es halt auch einfach dazu gehört, okay, man schaut sich die Daten an, man präsentiert die Daten und daraufhin werden Entscheidungen getroffen. Also es hat natürlich viel damit zu tun, wie ist die Kultur, wie ist der normale Ablauf in einer Firma und erst dann, was habe ich für Tools jeweils zur Verfügung. Aber ich würde sagen, heutzutage muss eigentlich jede Firma oder auch jedes kleine Site-Project mittlerweile einfach mit Daten arbeiten, weil es einerseits so einfach ist, aber auch die Qualität der Entscheidungen natürlich besser werden und Wenn man jetzt wachsen will mit dem Side-Project, dann, glaube ich, muss man sich einfach die Daten anschauen. Weil wenn man nur für sich selber arbeitet, das kann funktionieren, aber man muss meiner Meinung nach auf die User, auf die Audience einfach auch ein bisschen zugehen und probieren, die Audience, die User zu verstehen, um dann das Richtige eben zu bauen, sich dementsprechend weiterzuentwickeln. Und das trifft auch Firmen zu, auf Side-Projects, wo auch immer das ist.

Andy Grunwald (00:47:26 - 00:47:30)

Du hattest gerade gesagt, dass man auch zu Daten getrieben sein kann. Was heißt das?

Wolfi Gassler (00:47:30 - 00:48:17)

Ja, das ist eben das, was ich am Anfang schon erwähnt habe mit Data-Driven vs. Data-Supported Decision, dass man eben nur alles auf die Daten legt und man kann keine Entscheidung mehr treffen, ohne die richtigen Daten zu haben, weil das funktioniert eben nicht immer. Es gibt Situationen, da hast du zu wenig Daten, zu schlechte Daten. Manchmal macht es auch Sinn, sich über die Daten hinwegzusetzen. Eben, vielleicht riskiert man dann einen Umsatzeinbruch, aber man hat glücklichere User am Ende. Also auch das kann eine gewisse strategische Entscheidung sein. und man kann eben nicht alles mit Daten entscheiden, aber Daten sind auf jeden Fall eine super hilfreiche Informationsquelle und gerade heutzutage mit den einfachen Tools, mit diesen Visualisierungstools, die meisten Dinge habe ich schon in der Datenbank, gibt es eigentlich keine Ausrede mehr, dass man die Daten nicht sinnvoll verwenden kann.

Andy Grunwald (00:48:18 - 00:48:57)

Mein Problem ist bei solchen Dashboards und allem drum und dran, ab und zu frage ich mich eigentlich, auf was gucke ich denn da? Auf welche Daten sehe ich hier, wie interpretiere ich die und was sagen sie mir? Ab und zu komme ich mir halt so vor, wie ich lese Quellcode, den ich vor einem Jahr geschrieben habe. Und vielleicht schreckt mich das so ein bisschen ab, immer nur auf Dashboards zu schauen. Sie sind natürlich super schön, allem drum und dran. Wie umgehst du diese Problematik, dass du weißt, auf welche Daten du genau schaust oder wie du diese Daten interpretieren solltest? Wir haben das zum Beispiel im DevOps-Umfeld, im SRE, im Infrastruktur-Umfeld relativ oft. Wir sehen eine Metrik und wir wissen nicht genau, was diese Metrik aussagt, weil ich zum Beispiel das Dashboard nicht gebaut habe.

Wolfi Gassler (00:48:58 - 00:50:07)

Ja, das ist natürlich ein guter Punkt, den du da anschneidest. Das ist so ähnlich wie die Dokumentation. Du musst natürlich auch die Dashboards dementsprechend dokumentieren, die Informationen dazusetzen. Und das ist wirklich ein schwieriger Punkt, weil deinen Source Code, den müssen üblicherweise nicht automatisch ganz viele andere Leute verstehen. Deine Dashboards aber meistens schon. Und auch da geht es wieder darum, möglichst benutzerfreundlich die Informationen zur Verfügung zu stellen, Kontextinformationen zur Verfügung zu stellen, Education zu machen, wie geht man mit den Dashboards um. Das ist halt wie bei jeder anderen Software auch, ich kann nicht irgendwo eine Software hinklatschen und dann hoffen, dass sie verwendet wird. Ich muss halt Einschulungen machen, ich muss den Leuten erklären, warum ich das mache und das vergisst man halt dann oft bei diesen Dingen, weil man sagt, okay, ich verstehe sie eh, das ist gleich wie beim Source-Code, ich verstehe sie eh und ich denke gar nicht dran, dass das jemand anderer vielleicht irgendwann einmal brauchen könnte oder auch drauf schaut. Wenn man selbst etwas erstellt, ist es natürlich immer klar, aber wenn jemand anderer drauf schaut, ist es natürlich viel, viel schwieriger. Auch da haben diese Tools, by the way, Möglichkeiten, Informationen zu den Graphen dazuzuschreiben, Kontextinformationen zu setzen. Also auch da helfen die Tools ein bisschen mit, schon in die Richtung Dokumentation auch zu gehen.

Andy Grunwald (00:50:07 - 00:50:42)

Wieder was gelernt. Ich habe immer gedacht, Grafana wäre so der Platzhiisch, aber ich habe mir gerade mal ein bisschen Metabase angesehen. Interessant. Also ich glaube, ich werde die Tage mal wieder einen Docker-Container runterladen und einen Docker-Container starten. Auch lange nicht mehr gemacht. Dann hoffen wir auf ganz viele neue Tweets, wo du unsere Podcast-Statistiken mit einem Metabase-Dashboard veröffentlichst. Und an alle Hörerinnen und Hörer, ihr müsst natürlich fleißig unsere Folgen haben, damit wir auch Daten haben, die wir dann wieder für euch veröffentlichen können. Ich hoffe, ihr habt ein bisschen Spaß gehabt, ein bisschen was über Daten getrieben, Daten unterstützte, Entscheidungen gelernt. Ich hab's auf jeden Fall und wir würden uns wie immer ein bisschen über Feedback freuen.

Wolfi Gassler (00:50:43 - 00:50:58)

Und natürlich auch über Unterstützung. Und die beste Unterstützung ist Mundpropaganda. Also bitte erzählt anderen Leuten über unser Podcast, schickt Episoden weiter, wenn ihr sie sinnvoll findet, damit wir endlich zu unserem Hockeystick kommen, den wir dann am Ende sehen wollen in unseren Dashboards.

Andy Grunwald (00:50:58 - 00:51:00)

Dann bis nächste Woche, bis bald.

Wolfi Gassler (00:51:00 - 00:51:03)

Und hoffentlich dann mit besserer Stimme bei mir wieder. Ciao.