Data Quality – Hohe Qualität vom Anfang bis zum Ende

00:00:00: Intro

6566: Hallo und herzlich willkommen bei dir Titel future dem inovex Podcast

6566: mein Name ist Wolfgang Schoch und in der heutigen Folge unterhalte ich mich mit meinen beiden Kollegen Kolja Meyer und Marcel spitzer über das Thema data quality aber bevor ich mich darüber schlau mache was data quality eigentlich ist.

6566: Möchte ich mich erstmal darüber schlau machen wenn meine beiden Gesprächspartner heute sind Kolja magst du dich bitte mal vorstellen.

7111: Wolfgang und.

7111: Danke für die Einladung genau ich bin Kolja Meyer bin jetzt seit etwa fünf Jahren bei innovex und tue mich da auf

7111: diversen Gartenprojekt in Rom also fallen mit data Engineering Focus oder eben auch machine learning Engineering und genau diese Schnittstelle finde ich eben auch super spannend an einfach alles aufgeht.

6566: Sehr cool vielen Dank Marcel wie sieht's bei dir aus wie lange bist du denn eigentlich schon an Bord und was machst du so den ganzen Tag.

7112: Wolfgang auch hallo an die Zuhörer ich freue mich auch wie CallYa total hier zu sein zu Gast in deinem Podcast

7112: ich bin seit 6 Jahren bei inovex war auch schon in verschiedenen Kundenprojekten unterwegs habe dort verschiedene

7112: ja holen angenommen vom also meistens als data engineer hat ab aber auch schon

7112: vielleicht am ml engineer also alles rund um produktivierung von machine learning Modellen gemacht und die Bereiche wo ich da unterwegs war war meistens so im Retail und eCommerce.

6566: Und ihr beide seid ihr auf mich zugekommen mit dem Thema data quality und ich möchte ehrlich sein für mich war das anfangs gar kein großes Thema.

6566: Wenn es um daten geht da denke ich eigentlich eher an irgendwelche Algorithmen und Deep learning und machine learning und dann die ganzen in Anführungszeichen coolen Dinge.

6566: Und die Qualität von Daten ja die die gehörte irgendwo dazu für mich war das immer eher so eine Art bei Berg.

6566: Was für ein Vorgespräch schon ein bisschen über dieses Thema gesprochen haben da wurde mir ja auch klar okay das ist wirklich interessant da steckt viel dahinter und deswegen freue ich mich auch dass wir uns da heute mal drüber unterhalten und auch ein bisschen tiefer eintauchen.

6566: Aber lasst uns doch vielleicht mal mit dem grundlegenden Dinge anfangen und zwar mit der Definition von Datenqualität was ist eigentlich data quality.

7112: Ja also data quality wenn man wenn man im Internet recherchiert findet man viele unterschiedliche Definitionen dann so wie ich das für mich am verstehe würde ich sagen Datenqualität ist in erster Linie

7112: der der Grad der Abweichung zwischen dem was meine Daten repräsentieren und der Realität an sich also wenn man es mal ganz abstrakt ausdrücken möchte jetzt kann man das natürlich noch,

7112: oder man kann doch mehr ins Detail gehen und sagen ja wir können jetzt in unterschiedliche Dimension z.b.

7112: Datenqualität bewerten beispielsweise könnte man sich überlegen wie vollständig sind denn die Daten die ich als habe oder wie aktuell sind sie

7112: oder halt eben wie wie akkurat also das was ich vorhin auch gesagt habe mit Vivi sehr entsprechend die Daten der Realität wenn ich jetzt beispielsweise.

7112: 1 1 temperature sensor hab und der.

7112: Sag mir das die Temperatur gerade in einem bestimmten Raum irgendwie 20 Grad ist aber.

7112: In Realität sind das vielleicht mal 18 Grad da habe ich eben diese zwei Grad Abweichung also eine Abweichung von der Realität und das würde meine Datenqualität beeinträchtigen in der negativen Weise.

7111: Ich denke auch dass anhand von verschiedenen Dimension zu beurteilen das bietet sich sehr an weil.

7111: Qualität das ist ja irgendwie für jeden auch ein bisschen unterschiedlich nach unserem ich bezahlen bei der Datenqualität oder bei den Daten

7111: und um dich bisher so gesehen habe ist es bei euch auch immer ein bisschen natürlich produktabhängig also für für für ein Produkt ist es z.b. total wichtig dass jeder jede,

7111: das Datenfeld was man quasi sammelt für dich 100% accuratis wie es in der Realität ansfeldner wird wieder Beispiel Temperatur Sensor dass es wirklich möglichst genau bis auf die zehnte Nachkommastelle irgendwie

7111: aber z.b. jetzt die.

7111: Die Zeit ist leider so wann das zu Verfügung gestellt wird nicht ganz im Vordergrund steht und deshalb ist Datenqualität auch immer abhängig von dem größeren Kontext.

6566: Das heißt dann aber dass ich unabhängig von der Art der Daten jeweils individuell auf Basis von meinem Use-Case entscheiden musst welcher kradan Qualität notwendig ist und wahrscheinlich werde ich da auch.

6566: Mit Menschen sprechen müssen die dann aus Fachbereichen kommen und auch das fachliche Know-How haben um solche Entscheidung zu treffen oder.

7111: Ganz genau und das ist auch schon ziemlich wichtiger Stichpunkt also mit den Fachbereichen da wir haben es ja mit Daten zu tun

7111: und dahinter liegt dann meistens in der Realität eben beglichen nach dem Prozess manche Geschäfte oder manche Kunden die wir auch bopp-folie haben die sind ja z.b. auch aus irgendwelchen analogen

7111: gewachsen und das ganze jetzt erstmal in die digitale Welt zu zu bringen da brauchen wir sicherlich die fachliche Expertise.

6566: Ich kann mir vorstellen dass das dann aber auch ein ganz interessanter Prozess ist oder also wenn ihr mit dem Kunden dann oder mit den Leuten aus den Fachabteilungen spricht denn die haben ja gerne ganz andere Sicht auf die Geschichte.

6566: Unter die sprechen ja womöglich auch eine ganz andere Sprache also

6566: wenn ich mich jetzt fachlich mich Daten beschäftige dann habe ich ein ganz anderen Zugang wie wenn ich jetzt von der technischen Seite komme und

6566: wenn ich so überlege vielleicht habe ich ja als Fachexperte auch irgendwelche impliziten Annahmen also vereinfacht gesagt

6566: naja die Daten die müssen ja passen da mache ich mir keine Gedanken darauf darüber sondern ich denke eher darüber nach was ich damit erreichen möchte

6566: kennt ihr solche Situationen habt ihr da schon was erlebt in dieser in dieser Art.

7112: Also oft ist es so dass man in in einem an einem Produkt Team arbeitet und im im Rahmen dieses.

7112: Projektes werden Daten Pipelines implementiert das heißt man hat irgendwo einen Anfang der Pipeline.

7112: Und in Ente das heißt man liest Daten von ext meistens von externen Quellen man schreibt sie dann irgendwo hin

7112: und oft wird es dann als er so gewisser Weise selbstverständlich erachtet dass die Daten die aus externen Quellen bezogen werden von einer guten Qualität sind das heißt die Annahmen.

7112: Erwartungen die man an die Daten hat mehr oder weniger bewusst.

7112: Dass diese Erwartung halt auch alle beim erfüllt sind und oft ist es so dass es halt auch die meiste Zeit tatsächlich so ist.

7112: Und man deshalb auch gar nicht die Notwendigkeit sieht diese Annahmen die man die gesagt oft implizit an die daten stellt dass man diese auch strukturiert und automatisiert überprüft.

7111: Ich glaube aber was du da eingangs erwähnt hast nur das da sich so zeigen die Technik und die Domäne gewissermaßen die Hand geben müssen das Untertal wichtiger unten zentrale.de nicht

7111: immer glaube ich generell aktuelle Industrie beobachten kann und und das hat

7111: auch ein bisschen mit der Vergangenheit von Datenplattform zu tun würde ich sagen ja so die letzten Jahre

7111: ja da wurde vor allem der data Lake sehr populär man hat Daten über reingepumpt hat sich da aber vielleicht an der Stelle noch weniger Gedanken gemacht so was für mögliche da wo Produkte können vielleicht dazu kommt verstehen

7111: hauptsache erstmal das reinpumpen und dann mal sehen uns heutzutage sind da schon wieder an dem Punkt

7111: wo man die Daten wirklich wertschätzt und dann aber eben

7111: sprechen aussieht hey es reicht jetzt nicht wenn dann sage ich mal die technische Seite drauf schauen ob die

7111: ob die Daten bei Benz alle grünen durchgelaufen sind also passiert technisch Daten von einer PV find aber jetzt eben gar nicht darauf geachtet wurde was ist dann den Daten eigentlich drin.

7111: Und das glaube ich ist eben historisches auch Imperativ entscheiden da was Band.

7112: Und oft ist es ja auch so dass diejenigen die dann dafür verantwortlich sind die Daten Pipelines umzusetzen und auch zu betreiben oftmals gar nicht so die Domain expertise haben um bewerten zu können

7112: haben wir ziehen und Datensatz mit hoher Qualität oder ist die Qualität durch irgendwas beeinträchtige falls immer ein Zusammenspiel aus engineers.

7112: Und dumm in Experten und ja die Domänen Experten sind meistens die die sich am besten mit den Daten aus können die dann noch in der Lage sind ihre Annahmen zu formulieren

7112: die eben als Grundlage für die Sicherstellung von Datenqualität dann notwendig sind.

6566: Du hattest jetzt vorhin schon mal ein Beispiel gebracht für Datenqualität dazu dieser Sensor der z.b. immer 2 Grad falsch Mist also wenn es draußen 20 Grad hat dann ist er nur 18° das war ja schon ein Beispiel

6566: was sind denn weitere Beispiele für solche Jahre qualitätsmetriken wenn es um Datenqualität.

6566: Hast du da vielleicht noch was damit wir besseres Verständnis dafür bekommen.

7112: Ein anderes Beispiel für wäre z.b. also stell dir vor du hast du einen Onlineshop du bietest verschiedene Produkte an

7112: und also du hast keine keine Sensordaten keine Messwerte in deinen Daten drin sondern z.b. Artikelbeschreibung oder Artikelmerkmale

7112: und da macht es z.b. dann keinen Sinn wenn wir z.b. denkst an den an den Schuh.

7112: Wo dann halt in deinen Daten drin steht dass er die Schuhgröße rot hat das macht einfach überhaupt keinen Sinn.

7112: Also der Wert der also echt nicht ist völlig okay es ist halt auch eine Zeichenkette also völlig valide aber der macht einfach in in in der Domäne mit mit dem wenn man das domaine Verständnis halt anlegt sozusagen.

7112: Macht dieser Bert einfach gar keinen Sinn.

6566: Okay das heißt wir sind jetzt an der Stelle wo wir jetzt nicht nur sicherstellen möchten

6566: dass die Daten dies beispielsweise durch Sonnensensor generiert werden dass sie korrekt sind und dass wir hier ein technisches Problem ausschließen können also beispielsweise ein defekter Sensor wir möchten darüber hinaus auch noch sicherstellen dass die Daten an sich

6566: logisch korrekt sind also hat es ja das Beispiel mit der Schuhgröße rot und so was möchten wir auch ausschließen

6566: wir möchten im Rahmen von der ganzen data quality also sicherstellen dass die Daten in sich logisch korrekt sind,

6566: stimmt das so.

7111: Genau.

7111: Untis ich glaube auch da kann man quasi noch mal auf verschiedenen Ebenen unterscheiden also zum einen jetzt eben wirklich wenn man sich jetzt mal so eine relationale Beziehung vorstellen wenn man hat eben wie Marcel das

7111: eben hatte meine Eule von irgendwem Onlineshop und tim

7111: das Wetter sieht ja ja ja feingranular.

7111: Define granulated sich darauf quasi aber natürlich gibt's dann auch so ganz klassische mehr agnostische Metriken die dann verzeihe ich auch gar nicht so viel Fachexpertise erfordern die jetzt beispielsweise.

7111: Wann bekommen wir denn eigentlich jeden Tag rein na und ist das vielleicht gibt's da irgendwelche Auffälligkeiten wenn es irgendwie Black Friday ist dann hat dieser Online-Händler sicherlich mehr Schuhe im Verkauf als als Amtsleiter vor

7111: und da kann man dann leben auch noch ein paar.

7111: Aber dieser expectations bis wie es aufgenommen wird also die Erwartung jemand eben an die Daten hat anlegen.

6566: Das wäre sowas wie eine anomaly detection oder

6566: also dass ich meinen Datenfluss laufend überwache beispielsweise mit in welchen KI oder machine learning Systemen um herauszufinden okay ich jetzt gibt's hier eine Anomalie hier ist eine Auffälligkeit und jetzt muss sie irgendwie reagiert werden.

7111: Genau sehr gutes Stichwort auch und tatsächlich dieser diese Liegestützen Verfahren

7111: die können sogar heutzutage ein Stück weit bei der bei dem Schritt helfen wo man eigentlich das Expertise wissen brauchen habe sie krank war sie auch von der anderen Seite her kommt sozusagen und wenn man dann denkt man sich erstmal auch automatisiert oder semiautomatisch quasi einfach mal ein System

7111: Reim Klops und am Ende bekommt man dann z.b. aushält für deine für deine Spalte.

7111: Kategorie habe ich jetzt gefunden Schuhe Hemden und sonst was aber du hast auch überall irgendwie denn den Black Friday

7111: Überweisung zu anderen Tagen.

7112: Genau und eigentlich kann man sagen also jener jede Anomalie ist deutet ja auf eine Abweichung von der Realität hin und jetzt muss man unterschreiben eine Anomalie kann ja auch völlig

7112: Samba Lieder sein

7112: das Beispiel was Kolja gebracht hat es ist Weihnachten und die Verkaufszahlen schießen in die Höhe wäre jetzt ein ein Indiz dafür dass wir eventuell ein Problem mit Datenqualität hätten.

7112: Lohnt sich also noch mal genauer reinzuschauen und dann festzustellen es entspricht den Tatsachen also wir haben kein Datenqualität.

7112: Auf der anderen Seite kann ich ebenso ein Ausreißer oder eine Anomalie in den Garten doch wirklich,

7112: bestätigen dass wir einen dass wir ein Problem haben in unserer Datum außer Datenqualität.

6566: Das beispielsweise Daten doppelt importiert wurden oder so.

7112: Doppelt oder beispielsweise wenn also noch mal bei dem Beispiel des Temperatursensors zu bleiben wenn der wenn der Sensor einfach technisch nur in der Lage ist Temperaturen von minus 30,

7112: plus 100 Grad zu messen und der dir jetzt einen einen Temperaturwert von 500° übermittelt dann weißt du dass es kann gar nicht stimmen.

6566: So eine Art Krause bonitätscheck dann für mich regt das so als ob man diese Datenqualität heute bei solchen Anwendung schon ganz schön in den Mittelpunkt stellt

6566: denn diese ganzen Shakes ob die Daten logisch richtig sind da braucht man ja auch ganz schön viel domänenwissen dass man dann irgendwie ein Code gehst,

6566: um das zu überprüfen und das geht schon stark darüber hinaus einfach nur die input Daten zu validieren und um dann Prinzip sicherzustellen dass das Format stimmt.

6566: Also ist es jetzt in Bali dahinter Ciao oder ist das jetzt ein valides Datum wobei beim Datum muss man aufpassen denn ich glaube das sind auch schon verschiedene Dissertation in drüber geschrieben worden über das Parsen von korrekten Datumsformate

6566: und ich glaube da draußen im Netz gibt's immer noch ein paar Sachen die einen komplett überraschen können.

6566: Aber das ist für mich so die klassische datenvalidierung also habe ich jetzt Äpfel oder habe ich jetzt Birnen das kann ich auch leicht feststellen also außer beim Datum.

6566: Aber was ihr jetzt beschreibt geht der deutlich darüber hinaus ihr arbeitet er richtig mit diesem domänenwissen um sicherzustellen dass die Daten jetzt nicht nur vom Format her korrekt sind sondern dass die auch logisch korrekt sind.

7111: Auf jeden Fall wobei ehrlicherweise jetzt in unsere Diskussionen.

7111: Aber zu der war schon mittlerweile auf mich davon überzeugt dass Datenqualität sehr wichtig ist aber ich glaube dass er nicht aktuell kann man sagen dass es wirklich

7111: Golf 4 Datenplattform noch nicht die Aufmerksamkeit bekommt die size haben sollte also meistens was was ich habe das schon gemerkt habe ist das dann

7111: ja quasi das so.

7111: Größenrechner feedback loop die dann meistens von den Analysten ausgeht zurück getragen wird am Ball für zwei sind zentrales Daten Team.

7111: Die dann.

7111: Wieder verantwortlich dafür sind die eigentlichen ja da qualitätsmetriken geben auf ihre Daten glatt zu ziehen.

7111: Und.

7111: Das ist im Grunde auch ein ziemlich spannendes Angrenzung das Thema mit dem Date am eschener weil er merkt man es auch schon man trägt irgendwie dieser diese Expertise

7111: ihr eigentlich am Ende der der Kette ist bei den Analysten die Datenzentrale Steam die damit vielleicht gar nicht so viel mit anfangen können

7111: und ich denke das ist auch ein großer Teil oder.

7111: Einfach damit zusammen warum man das vielleicht heutzutage noch nicht so in der Art ausgelebt findet.

6566: Das ist übrigens ein gutes Stichwort übers Delta mehr scheint mich ja vor einiger Zeit mit dem Dominik Benz unterhalten und falls du die vorige noch nicht kennst dann hör doch einfach noch mal rein die ist ganz interessant wenn euch für das Thema interessiert

6566: aber zurück zu deinem. CallYa ich frage mich warum das so ist dann auf der einen Seite heißt ja immer data is the new oil oder data ist Danube.

6566: Und wir haben diese ganzen Datenplattform und wir sprechen über Daten pro

6566: bitte und wir sagen ja auch Daten sind das große Kapital von vielen Unternehmen und es gibt diese richtigen Daten schätze die man da Bergen kann und wir haben wie gesagt diese Plattform und wir haben Algorithmen und alles mögliche

6566: aber irgendwie wären dann die Daten und die Datenqualität doch immer wieder so stiefmütterlich behandelt.

6566: Und ich muss dann so eine Analogie denken dann bin ich im Besucher Markt bin und mir irgendwelche Lebensmittel kaufe dann wird er oft damit geworben dass die Zutaten

6566: dass die richtig richtig gut sind da haben wir irgendwelche Bio Zutaten die wurden von Hand gepflückt

6566: die sind in ganz tollen Anbaugebieten angebaut worden und es wird damit geworben

6566: das ist Zutaten ebenso richtig richtig gut sind und deswegen das Produkt ja auch gut sein muss und ich bin ehrlich bei mir funktioniert zu der werbung eigentlich immer ich frage mich aber warum dieses Bewusstsein,

6566: jetzt im Datenbereich noch nicht so super starkes denn wir sagen ja auch immer gerne mal shit in shit out

6566: das bedeutet wenn ich irgendwo schlechte Daten rein stecke dann kann ich keine wirklich sehr guten Ergebnisse oder ist in dem Kontext sehr gutes Daten Produkt bekommen

6566: und da würde mich einfach mal interessieren warum ist das so und warum ist dieses Bewusstsein noch nicht an allen Stellen so stark wie es vielleicht sein sollte.

7112: Jassen interessanter. Vielleicht zu deiner ersten Beobachtung die du gemacht hast dass Daten halt so ein bisschen stiefmütterlich behandelt werden oder mehr so als Beiprodukt von von von dem Softwareprodukt was behalt baut.

7112: Ich glaube also es gibt natürlich ganz viele verschiedene Gründe aber ein ein Grund ist halt auch es ist funktioniert halt also die meiste Zeit geht es ja gut.

7112: Man hat Annahme an die Daten und die sind erstmal ja die meiste Zeit in der Regel erfüllt weil die Produkte oder die produktives von denen ich die Daten beziehen

7112: da kann ich ja schon davon ausgehen dass die Besessenheit ihre gewissenhaft ihre Arbeit tun.

7112: Und ähm das Problem ist halt wenn ich jetzt auf Grundlage von von Daten Entscheidungen treffe sei es automatisiert oder Teil automatisiert oder wie auch immer oder ich z.b. Prognosemodelle auf den Daten trainiere.

7112: Dann dann reicht es ja wenn da jetzt irgendwie mal ein Fehler alle.

7112: Paar Jahre mal auftritt um eine Kasse viel Entscheidung zu treffen die aber dann schon katastrophal sein kann und deshalb ist es halt oft so dass das Thema Datenqualität das die Wichtigkeit dieses Themas halt schon anerkannt wird also zumindest meine Erfahrung aber

7112: dieses Thema an sich halt mehr so bisschen nicht so greifbar ist und halt auch oft dann hinten runterfällt so bei dem daily business.

7111: Ja genau also ich denk auch meistens wenn irgendwelche Dinge nicht angegangen werden dann ist es ja.

7111: Grund dafür der Schmerz ist noch nicht groß genug ich hatte dazu aber dann sehe ich gerade im Bezug zu data quality vor kurzem einen sehr spannenden Artikel gelesen und zwar hat da die Autoren aufgeschlüsselt.

7111: Wie viel das eigentlich gerade auch ein Baby bist das bedeutet man kann sich das ja relativ einfach vorstellen vor allem wenn man so eine zentrale Datenplattform hat wie viel

7111: Leute da eigentlich downstream dranhängen und wie viel daneben so oder wie groß der impact ist man dann wird's mal dass das einfache Beispiel wenn die Daten nicht da sind nur zählt auch unter data quality und wann das dann überhaupt erst auffällt das ist dann

7111: im schlimmsten Fall gerade sind das die Analysten ganz am anderen Ende dann muss quasi alles was zwischen zwischen.

7111: Ab 4. Versuch bei deren Palm bei uns oder bei irgendwelchen zentralen Haltern muss alles wieder aufgearbeitet werden und wenn man solche Inzidenz ist also quasi ganz einfaches Mittel quasi.

7111: Auch mal gegen zu halten wie schwerwiegend das Problem eigentlich ist ne und wie oft das daneben auch auftritt und als zweite Metrik kann man daran eben auch dazu nehmen wie lange es dann braucht.

7111: Und dann sprechen kostet dieses Problem zu fixen und ich bin mir sicher,

7111: bei den meisten Projekten würde der der verantwortliche ziemlich schnell einsehen dass es sich da lohnt also genauer hinzuschauen und mehr zu investieren.

6566: Das erinnert mich so ein bisschen an die Softwareentwicklung vor vielen vielen Jahren in einer anderen Firma in der ich mal gearbeitet habe Daten wir mal ein Projekt

6566: und da wollte unser Kunde keine Qualitätssicherung bezahlen also keine Tests.

6566: Wir hatten das damals glaube ich in die auch explizit ausgewiesen frag mich nicht warum aber vielleicht war das damals so üblich da kann ich mich immer ganz ganz korrekt dran erinnern.

6566: Auf jeden Fall hat der Kunde oder der Projektmanager auf Kundenseite damals gesagt ja sie ist halt solche Experten und ich erwarte dass da einfach keine Fehler gemacht werden deswegen können wir uns das auch sparen.

6566: Unterm

6566: na ich hatte damals ich so super viel Erfahrung beim Berufseinsteiger aber ich fand es damals auch schon irgendwie komplett Absturz ohne Erwartung zu haben dass keine Fehler passieren also

6566: ich meine der Wunsch ist natürlich sehr nachvollziehbar und auch sehr verständlich aber natürlich machen wir immer Fehler natürlich passieren überall Fehler

6566: aber wenn ich schon in der Vergangenheit bin.

6566: Wenn ich mich auch zurück erinnere an die Zeiten und an die Jahre in der in den ich in der Suchtentwicklung gearbeitet habe da gabs auch eine ganz starke Evolution was Qualitätssicherung angeht

6566: also ganz am Anfang hat man halt Unit Test geschrieben und das war's im Großen und Ganzen,

6566: und so diese ganzen anderen Dinge wird so Integrationstests oder heutzutage so riecht

6566: coole Sachen dass man so welche in wireman es hochfährt und ganz ganz tolle integrative Sache Sachen zu testen während der Entwicklung und das alles so mehr oder weniger automatisiert funktioniert das finde ich schon ziemlich cool.

6566: Und ich bin es nicht mehr so aktiv in der Entwicklung aber ich verfolge das alles immer noch so ein kleines bisschen bei mich interessiert und da ist in den letzten ich weiß nicht vielleicht 10-15 Jahren extrem viel passiert.

6566: Nicht nur auf der technischen Seite aus ist ja nicht nur die Tulsi ist heute gibt es ist meiner Meinung nach auch sehr viel so was im Bereich der Einstellung passiert.

6566: Süße ganze Clean Code Bewegung die es gab und auch so diese ganze ist Selbstverständnis dass man sich jetzt nicht mehr nur

6566: jetzt ich verstehe mich jetzt nicht nur als Entwickler sondern ich verstehe mich so als Software-Ingenieur oder diese Kraft manship die ist auch gibt im Bereich Softwareentwicklung wo man dann auch wirklich sagt ja ich nehme übernimm Verantwortung und ich seh das jetzt vielleicht wie ein Handwerker der hat das ganzheitlich betrachtet und einfach ein sehr sehr gutes Ergebnis liefern möchte und da gehört natürlich auch

6566: vernünftige Qualitätssicherung dazu und ich bin heute ein bisschen bei den Analogien irgendwo

6566: und ich frage mich ob das vielleicht ist aber auch eine Analogie sein könnte für das Daten Disneys also wir haben in der Softwareentwicklung diese Evolution was Qualitätssicherung angeht hinter uns und ist es vielleicht auch so

6566: dass wir diese gleiche Evolution auch im Bereich der Daten brauchen

6566: und da einfach noch ein paar Schritte gehen müssen bis wir auf dem gleichen Level sind oder den gleichen Meilensteine reicht haben.

7111: Ja genau absolut also.

7111: Ich denke heutzutage das ist zum Glück nicht so dass man dass man da eine große Diskussion braucht wegen unit ist dass das ist mittlerweile sozusagen angekommen glücklicherweise aber genau so.

7111: Michael aktuell.

7111: Die ganze data Engineering Landschaftsläufe ich mal in großen Teilen immer mehr an die Softwareentwicklung und ich glaube man sieht das auch

7111: ganz oft bei passieren Framework für z.b. DBC die legen dann sehr großen Wert auf dass man einfach diese best practices die man wirklich

7111: Schmerzen sicherlich auch in der Software-Entwicklung gelernt hat dass man die jetzt auch gewissermaßen in den

7111: indem DataContext und Zargen einbauen kann.

7112: Also das ist tatsächlich eine spannende Analogie.

7112: Beispielsweise ich meine worum geht's beim beim testing von von Software letztendlich hat man implizite Erwartung an die Funktionsweise seiner seines Code seiner Funktion

7112: und die stellt man halt sicher und zwar automatisiert und auch bei jeder Änderung des Codes stellt man sie sicher.

7112: Haben und ähnliches lässt sich auch auf die Datenwelt adaptieren dort hat man auch häufig implizite Annahmen an die Daten.

7112: Wieder das Beispiel der Temperatur Sensor der nur zwischen -30 und plus 100 Grad messen kann also einen Temperaturwert außerhalb dieses Intervalls würde gar keinen Sinn machen in dieser Domäne

7112: diese ganzen impliziten Annahmen versuchen halt eben explizit zu machen.

7112: Und dann halt auch eben automatisiert und regelmässig am sicherzustellen insbesondere wenn sich der wenn sich der Datensatz ändert.

6566: Das würde dann aber bedeuten dass die Sache die ich vorhin gesagt habe also mit den Bio-Zutaten diese hochwertig sein müssen damit der spätere Produkt auch sehr hochwertig sein kann dass das ja eigentlich eins zu eins aus wie eine Datenplattform zutrifft.

6566: Wenn unsere Daten hervorragend sind und das bedeutet wir haben validiert dass die korrekt zu Ende sind vom Format richtig die sind logisch richtig und die haben eine sehr hohe Datenqualität.

6566: Erst dann kann ich in Daten Produkt schaffen das eben auch eine sehr hohe Qualität hat.

7111: Genau also wir haben ja eben schon darüber gesprochen dass in der Softwareentwicklung.

7111: Gewisse Praktiken angekommen sind Navi das ist sehr verständlich dass wir Testbarkeit haben dass wir Test schreiben dass wir Versionierung des Codes haben.

7111: Man merkt jetzt eben langsam auch in der Daten Domäne dass das man viel davon braucht um bessere datenprodukte zu zu entwickeln.

7111: Und.

7111: Was ich in letzter Zeit öfters auch mal gelesen hatte da inwiefern ist z.b. auch Sinn machen würde SLS anzubieten wirklich auch für datenprodukte oder die Art wie man Daten bereit

7111: stellt verwandtes Stichwort wären da die datacontract na das war also wirklich ganz genaue Spezifikation hat was man in den Daten

7111: von den Daten erwarten kann wann man sie ja warten kann und das

7111: z.b. auch generell das Thema Datenqualität in diesem Segment data essen und dass wir dann auch wieder die Richtung vom data Mesh Wert gelegt oder.

6566: Ja das ist eine spannende Sache ich glaube es kommt halt auch stark auf den Use Case an denn ich glaube auch so eine sehr sehr hohe Datenqualität die braucht man es sicher auch nicht überall.

6566: Also wenn ich jetzt beispielsweise eine kostenlose Wetter-App auf meiner Website habe und das ist irgendwie ein Hobbyprojekt dann ist es vielleicht ja auch in Ordnung wenn die Daten nicht immer korrekt sind oder wenn die Daten mal irgendwie unvollständig sind.

6566: Denn meine User die wissen dann okay das ist nur Wolfgangs kostenlose Wetter-App und die ist nicht immer erreichbar und manchmal hat die vielleicht auch eine kleine Abweichung aber sie sieht vielleicht cool aus und deswegen nutzen wann deswegen ist es okay.

6566: Also hier ist vielleicht so eine extrem hohe Datenqualität gar nicht notwendig

6566: ganz anders sieht sie dann aber aus wenn jetzt die daten oder Soldaten Produkt zu mein Kerngeschäft ist also wenn ich jetzt irgendein online bist und habe und da halt keine physikalischen Produkte verkaufen sondern nur eine digitale Dienstleistung eine Daten Dienstleistung.

6566: Dann werde ich ein sehr großes Interesse daran haben dass meine Daten korrekt sind dass sie vollständig sind und dass sie zuverlässig sind denn meine Daten wären ja dann höchstwahrscheinlich von anderen Leuten wiederum verwendet und die verlassen sich ja drauf,

6566: das ja dass ich einfach was vernünftiges und was zuverlässiges liefere da kommt ihr auch sehr viel Vertrauen mit dem Spiel was dann mitunter auch natürlich sehr wichtig ist für mich

6566: in meinem Bereich oder in meinem Business und da finde ich jetzt zu diesem Begriff den du genannt hast mit dner datacontract eine sehr sehr spannend.

6566: Dass ich wirklich in den Vertrag in Anführungszeichen festlegen kann in dem genau definiertes wie meine Daten beschaffen sind und was für eine Qualität die haben.

6566: Damit ich mich da einfach drauf verlassen kann.

7112: Gerade wieder auch bei dem Thema data als als ESET also natürlich kannst du als Unternehmen Daten als Produkt bereitstellen und du wirst dann auch wenn du wenn du spannende Daten hast ich denke da z.b.

7112: Weiß ich nicht an

7112: Plattform wo du z.b. wohnungsinserate Liste dass du da halt über den Abo-Modell eben den den zahlenden Kunden gewisse Einblicke zusätzlich gebärst.

7112: Einblick in die daten oder was ja auch ganz populär ist Schnittstellen für für Finanzdaten

7112: also da gibt es auch im Kunden ja großes Interesse dran haben und auch bereit sind dafür Geld zu bezahlen aber dementsprechend hoch sind auch die Erwartung an die Qualität

7112: und auch insbesonder an die Aktualität der Daten.

7112: Und genau also Datenqualität ist es ist natürlich insbesondere da wichtig wo halt eben Daten ausgetauscht werden zwischen Produkten oder zwischen Organisation und das heißt auch innerhalb einer Organisation wenn man also da auch wieder die Analogie zudem zu dem Thema data Mesh wenn man.in in Daten Produkt

7112: denkt eben Daten über über Schnittstellen austauschen

7112: in genau diese Schnittstellen da deshalb besonders wichtig halt eben diese Qualitätsmaßstäbe anzusetzen und diese dann halt auch regelmäßig zu überprüfen.

6566: Ja nichts anderes haben wir der Softwareentwicklung ja auch da haben wir auch schnittstellendefinition und die legen fest wie man über eine Systemgrenze hinweg kommuniziert

6566: und dadurch festgelegt was für Parameter können rein was für Parameter komm raus ich sieht gegebenenfalls noch ein SLA aus oder wie ist der quality of service definiert und darauf kann und muss man sich verlassen wenn man zu oft entwickelt,

6566: denn man brauchte irgendwelche Pfeiler sage ich mal die man ja einfach zu Orientierung nutzen kann.

6566: Und genau sowas finden Datenbereich finde ich es ziemlich spannend aber wie sieht es jetzt in der Praxis aus wir haben jetzt über verschiedene Dinge.

6566: Man kann diese Daten überprüfen auf Vollständigkeit.

6566: Man kann gucken ob die Wertebereiche stimmt das also irgendwelche Daten die ich erwarte jetzt im richtigen Bereich sind du hattest ja so ein Beispiel von dem Sensor der beispielsweise die Temperatur bis 100 Grad messen kann.

6566: Da kann ich dann automatisch sagen ok wenn ich den Wert von 500 Grad irgendwo meinen Daten drin habe dann ist er hundertprozentig falschen dann gibt's Sie irgendein Problem.

6566: Man kann auf Basis des Domänen Wissens noch in welche Logik Überprüfung einbauen,

6566: unter man kann oben drauf vielleicht noch so eine Ausleihe detection haben um wirklich starke Ausreise zu erkennen und auf Basis von der Info auch festzustellen ok Hier stimmt irgendwas nicht hier ja müssen die Daten vielleicht noch mal anschauen

6566: aber wie sieht für euch beide jetzt so die Arbeit ganz korrekt aus also beispielsweise ich bin euer Kunde ich habe ein großen Onlineshop wo ich Fahrräder und Zubehör verkaufe und ich möchte jetzt hier eine hohe Datenqualität haben ich engagiere euch beide

6566: und ihr schaut ja mal nach dem Rechten wie sieht's denn bei euch konkret aus und wie fühlt ihr euren Arbeitstag.

7112: Du kannst anfangen also wie sollen wir vorgehen im besten Falle hast du ein 1 Team 1 1 1 produktteam was gemeinsam an einem Daten Produkt arbeitet und innerhalb dieses Teams hast du im besten Fall auch Domain Experten

7112: Amts und Ansteckbutton in der Regel dann erstmal sozusagen die Köpfe zusammen tauscht sich aus und verschafft sich erstmal den Überblick welche Datenquellen benötigen wir

7112: denn um unsere Daten Produkt zu bauen und er für jeden einzelnen Datensatz kann man dann eben erarbeiten welche.

7112: Wann haben habt ihr denn an an diese Daten also mach das alles mal was ihr

7112: im Kopf hat mal wirklich explizit also beispielsweise die die Kunden id die muss eindeutig sein es darf keine zwei unterschiedlichen Kunden geben mit der gleichen Kunden id.

7112: Das sind so Dinge die man so für selbstverständlich erachtet aber das macht ja schon Sinn dass man das halt auch systematisch überprüft.

7112: Oder dass das nur dass das kein Kunde unterschiedliche alice hat in in dem System.

7112: Am all diese Dinge da versucht man halt möglichst einen angepisst umfangreiches Set an anna Namen zu definieren jeden mehr zusammen mit den Domain Experten im besten Falle sind die Domain Experten selbst dazu in der Lage also das heißt.

7112: Im besten Fall muss der Domain Experte keinen keinen keinen Programmierer sein er muss nicht irgendwie softer schreiben, sondern kann beispielsweise nach deklarativen Art und Weise seine Annahmen formulieren

7112: und die dann halt beispielsweise in in Form eines eine Skriptes oder sowas aufschreiben und die dann

7112: auch unter Versionskontrolle stellen weil auch Annahmen über Daten können sich ja mit der Zeit ändern.

7112: Und und dann ist es quasi wie so eine Art Handover von dem von dem Domäne Experten zu den engineers Body engineers die können dann die diesen Prozess der der Validierung also der der Überprüfung der Annahmen auf auf Datensätze.

7112: In die Daten bei Platz Andi an die kritischen Stellen integrieren.

7112: Das ist im Prinzip einfach einen generischer Prozess der oft auf Grundlage von einem von einem beliebigen Set von Annahmen prüft ob diese Annahmen erfüllt sind oder nicht.

7112: Bonsai nachdem ob daneben die anderen erfüllt sind oder nicht,

7112: kann man verschiedene Aktion in die Wege leiten weil es könnte z.b. sein dass wenn man bereits eine Annahme,

7112: gerade mal nicht erfüllt ist die aber nicht besonders kritisch ist weiß vielleicht noch in so einem.

7112: Toleranzbereich liegt dass man da eben die Daten einfach weiterhin verarbeitet aber zumindest eine Nachricht drauf schickt an inflectional oder per E-Mail das da zumindest Leute darüber informiert werden dass da irgendwas

7112: und Auffälligkeit in den Datensatz war und das kann man halt beliebig weiter denken ja wenn das z.b. kritisch wäre,

7112: hör auf Helligkeit ist könnte man sagen ok diesen Datensatz.

7112: Bzw diesen ganzen vielleicht ist es auch eine ganze Teil Tabelle die sortieren wir jetzt aus die stecken irgendwo in Quarantäne das soll erstmal jemand mit domänenwissen draufschauen und gucken was da mit den Daten falsch ist.

7112: Anderes Wort aber weiter durch ja und jetzt kann man sie auch in Situationen vorstellen wo die andern wo wo die,

7112: an am derart schwer sozusagen verletzt sind dass man die ganze Daten Pipeline stoppen muss bis auf weiteres ist dieser Fehler halt an der Quelle behoben ist.

6566: Was ist wenn ich jetzt feststelle dass ich bei den Daten die ich rein bekomme immer eine Temperatur dabei habe die größer als 100 gratis und wären wir festgestellt.

6566: In unserem Beispiel der Sensor geht nur bis 100 Grad würde ich dann die Notbremse ziehen weil eventuell ja die Hardware defekt ist und jetzt alle Daten dich rein bekomme deswegen unbrauchbar sind.

6566: Und die Daten die ich reinkomme wenn die sich jetzt mit den vorhandenen Daten vermischen dann wird er vielleicht auch dass Daten Produkt dass ich habe unbrauchbar.

7112: Genau und selbst wenn es nur ein temporäres Problem ist also z.b. wenn der senso als Nummer für einen paar Minuten falsche Werte geliefert hat.

7112: Selbst das könnte halt also die Lücke die dadurch in deinem Datensatz entsteht wenn du diese diese dieses Zeiten dabei sozusagen einfach aus sortierst,

7112: diese Lücke die konnte so kritisch sein dass du sozusagen gezwungen bist auch die ganze weitere Verarbeitung zu stoppen selbst wenn der Sensor irgendwann wieder valide Temperaturwerte liefert.

7112: Das Beispiel.

7112: Ob das jetzt so gut ist aber nicht sicher Beispiele wo das eben so ist das man selbst valide Daten dann eben nicht mehr weiterverarbeiten kann bis eben dieser.

7112: Invalider Datensatz halt gepiekst ist.

6566: Wenn man es beispielsweise über irgendwelche Zeitintervalle hinweg Daten berechnet und welche Durchschnitte und auf Basis von den durchschnitten trifft man irgendwelche Entscheidung,

6566: in der Firma werden z.b. irgendwelche großen Finanz Entscheidung getroffen ich kenne mich nicht so gut mit Aktien aus aber wenn ich es mir diese Durchschnittswerte anschauen daraufhin entscheide Hey

6566: dieses riesengroße Aktienpaket das verkaufe ich jetzt war das ist ein super guter Moment dafür und im Nachhinein feststellen da war ein Fehler drin und jetzt ist die Firma leider pleite weil wir alles falsch verkauft haben

6566: dann wäre es natürlich schlecht solche Sachen.

7112: Ja sowas oder oder stell dir vor so Transaktionsdaten ne wenn wir z.b. warenein und Ausgänge in dem Lager hast und du sortierst dann mal irgendwie so ein paar Transaktion aus dann kann das halt dazu führen dass dein Lagerbestand irgendwie negativ ist.

7112: Aber du kannst ja gar keine negative Anzahl von Artikel in deinem Lager haben sowas z.b.

6566: Interessant hinten in deiner Schilderung des ihr iterativ vorgeht das finde ich spannend denn ich komme ja aus der Scrum Ecke und da gehen ja auch immer iterativ vor.

6566: Wir haben zu diesem Grundsatz im Scrum inspect and adapt also mach eine Iteration und beurteile sie dann schau dir an was das gut funktioniert und hat schlecht funktioniert und adaptiere dann also lerne dann daraus für die nächste Iteration.

6566: Ist dieser agile oder iterativer Ansatz für euch auch eine ganz normale Vorgehensweise.

7111: Ja gerade bei der data quality finde ich bietet sich das auch total gut an also aus meiner Erfahrungen und wie war er vorhin auch schon besprochen haben ist es manchmal ein bisschen schwierig das Thema anzugehen hat das.

7111: Verschiedene Richtung denken und das Stehmann irgendwie alle Türen offen und damit so dann gleichzeitigen wie auch alle halt zu wenn man nicht weiß wo man bei hinlaufen will.

7111: Und meinen Zählung ist da immer quasi du dich mit mit.

7111: Ganz unten medrigalm anzufangen aber werden vorne auch schon erwähnt einfach mal auf zu schreiben das muss auch noch überhaupt nichts automatisierte sein das kann da etwas sein Mann lag irgendwo Excel-Sheet an unterlegt

7111: wann ist welcher data quality incident aufgetreten H&M.

7111: Wie lange haben wir beide beide gebraucht um das Ding zu fixen und dem ist behindert na wenn man dieses ganz minimalistisch oft Framework hat kann man sich da auch dann quasi.

7111: Sprint Weise oder in welchen Abschnitten auch immer dann auch verbessern aber vielleicht könnte dann dann dann einen Action alt und seine elgia mit für die ersten.

7111: Incidence irgendwie zwei Stunden gebraucht und jetzt versuchen wir mal aus irgendeiner in der Bibliothek zu verwenden Baixas war der great expectations oder wir versuchen einfach mal.

7111: Stärker wieder shimadzu verwenden da wo dann beispielsweise auch direkt die Typen die typischen

7111: guten Start über quasi absenken also ist das für Zeichen in String Art

7111: Erwartungshaltung die man da quasi an die Daten ab na und so kann man sich dann natürlich iterativ so ein bisschen ran rauben Andi Andi dann auch

7111: größeren komplexer von Metrik na das kann ja wir hatten jetzt schon schon paar komplexe Beispiele zusammen vielleicht pro.

7111: Auch in der weiblichen Verbindung stehen oder das kann sich natürlich dann auch über verschiedene Tabellen erstrecken.

7111: Und das kann man dann qualitativ hinzunehmen.

7112: Datenqualität ist ja auch etwas was man nie.

7112: Endgültig zu 100% garantieren kann das ist ja auch ganz ähnlich wie bei mir uns Softwarequalität sicherstellen würde da kann man noch so viele Unit Test schreiben und so weiter aber.

7112: Zu 100% ausschließen dass

7112: Timecode jetzt Bug frei ist das da würde niemanden die Hand ins Feuer legen also da kann immer was Unvorhergesehenes passieren und eh nicht ist das halt auch bei der Datenqualität also jede erfolgreich war die Birte Erwartung die Zeit natürlich,

7112: auf die Datenqualität ein.

7112: Und so kann man halt sagen ok gefangen vielleicht mit dem minimalen Set von von Erwartung an die wir einem bestimmten Datensatz haben und erweitern diese sukzessive insbesondere dann wenn doch mal irgendwo eine Auffälligkeit Auftritt die halt problematisch ist

7112: genau und wichtig ist halt dass man daneben dann sag mal generisches Framework hat um halt eben einen beliebiges Z an Annahmen auf.

7112: Daten zu validieren.

6566: Dieses iterative Vorgehen ist ja auch ein ganz gutes vorgehen um gute Argumente fürs management oder für den Projektleiter zu finden

6566: denn wenn man wirklich sagt wir gehen iterativ vor und wir fangen mit kleinen Schritten an und schauen dann was passiert dann muss man ja eben nicht direkt irgendwie 200 PC investieren um jetzt mal einen ersten Wurf zu bekommen und erste Auswertung zu bekommen

6566: sondern man kann ja eventuell auch mal mit 5pt anfangen und kann sagen okay wir setzen uns jetzt mal 5 Tage hin und machen mal ganz groben Überblick wir sichten die daten wir führen vielleicht mal ein paar Interviews mit den

6566: Leuten die sich mit der Domäne auskennen um hier besseres Verständnis zu haben und am Ende haben wir vielleicht eine ganz kleine Ausleihe detection auf den Daten

6566: und wer weiß vielleicht kann ich ja auch mit diesem kleinen Invest nach 5 Tagen da schon richtig gute Erkenntnisse herausziehen

6566: die hilfreich sind also wenn ich zu der outlay detection habe dann kann ich ja wirklich vielleicht schon sagen schaut mal wenn man sie historische Daten angeschaut will merken es gibt jede Woche fünf große Ausreißer die wussten wir

6566: ja noch gar nicht also wir wussten nicht dass sie passieren und jetzt schauen wir uns die mal an ist gehen wir da mal vielleicht in der nächste Iteration da mal ein bisschen tiefer rein,

6566: und wer weiß vielleicht ist da irgendwie ein großes Problem von dem wir doch gar nichts,

6566: und wir können uns jetzt darum kümmern bevor uns ist richtig auf die Füße fällt ich habe noch eine kleine Frage an dich Kolja du hattest ja gerade eben und great expectations erwähnt,

6566: und dann ich kenne das noch gar nicht so vielleicht mal ganz kurz erklären was ich dahinter verbirgt.

7111: Ja wenn expectations das ist ein eine Python binary übrigens auch ein sehr toller empfehlenswerter Roman von Dickens glaube ich ursprünglich

7111: und genau also zu deutsch hat er ja auch der Roman die die gleiche Besetzung also große Erwartungen und

7111: Fußball wir auch was was man in dem darüber TV findet also es geht anzeletti.

7111: Von dem Projekt ist ein bisschen dass man expectations also diese Erwartungen definiert ne und das kann jetzt sitzen bunter Blumenstrauß aus dem was wir auch teilweise schon erwähnt haben als ob das zum Beispiel rowcount über eine ganze,

7111: Tabelle oder irgendwelche.

7111: Die komischen Eigenschaften die man die man in den Daten erwartet überfordert mit den Kategorien ich erwarte nur Schuhe und und Hemden irgendwie meiner Tabelle

7111: zu relativ ausgeklügelten statistischen Metriken die man eben dann auch,

7111: kann man seine Daten quasi anlegen kann und dann sind wir quasi auch gar nicht weit von entfernt von dem was wir eben beschrieben haben also sprich Nachnamen Initialen rendered sage ich mal dass man eben.

7111: So Library in die entsprechenden Daten Pipelines integriert wenn man.

7111: Dieser groundwork mal getan hat ist es im Grunde danach immer sukzessive diese expectations hinzuzufügen und das Schöne dabei ist wirklich dass die relativ selbstsprechend sind also.

7111: Wie ein explodierter ist aber das ist dann wirklich sowas wie expect.

7111: Count bigger than keine Ahnung was nun dann wird man quasi noch mal einer ein bestimmte Nintendo 1.

7111: Sprich doch das also auch eine perfekte Schnittstelle für für.

7111: Fachexperten und eben die technische Seite von von.

7111: Was heißt öfters und damit hat man bisher ich immer ganz gute Erfahrung gemacht.

6566: Ja cool wenn man das so einfach formulieren kann dann ist es ja fast schon so eine Art domänenspezifische Sprache,

6566: ich finde es super wenn dann jemand aus der Fachabteilung sich hinsetzen kann und direkt durch Regeln runter schreiben kann ohne jetzt ein großes Hintergrundwissen über Programmierung oder so zu haben sondern wenn man dann vielleicht wirklich einfach solche fertigen vorgefertigten Regel nehmen kann

6566: mit der ja überprüft man den rowcount oder irgendwelche anderen Sachen und dadurch halt so ne Plach Qualitätssicherung zu erreichen.

7111: Ganz genau.

7111: Soll ich dann auch noch nicht mal also in der DSL in dem Sinne dass man sich noch in irgendein Programmiersprache befindet sondern das ist wirklich auch als Jason spezifizierbar Nase da muss man dann jetzt auch keiner keine große ID oder das eigentlich ausdrücken soll man kann der Bericht

7111: das ist gut soll ich mal tations eintragen die man dann neben der Doku findet.

7112: Also ja

7112: es geht beides also du kannst die ja expectation in Form von JSON files definieren great expectations bietet ja aber auch an über verschiedene Apps halt direkt mit dem Datensatz zu interagieren beispielsweise kannst du

7112: dann Datensatz in Form von dem Pandas dataframe oder einem Spark dataframe einlesen

7112: wann ist diesen dann in den great expectations data Frame um das ist im Prinzip einfach nur wie ein Rapper und deinen ursprünglichen data frame

7112: und am ob diesen Bäcker Frank Reichenhall programmatisch auch deine deine Erwartungen definieren.

7112: Genau die die Funktion die Koje angesprochen hat z.b. Sixpack Cullum value to be between.

7112: X und Y oder expect Kalimba used to be normally distributed oder sowas für ML Modelle ganz interessant genau und.

7112: Dr schöner great expectations halt auch dass es dir im Prinzip.

7112: Aber die Möglichkeit bietet diese diese anderen die Du vorab definiert hast auch zu zu validieren also das ganze compute was da im Hintergrund gemacht werden muss oder müssen Aggregate berechnet werden da muss irgendwie geprüft werden dass da keine Nullwerte in innominate drin sind

7112: und das tut halt alles abgenommen und du bekommst dann nach erfolgter Validierung halt wiesenart.

7112: Bericht am Becher Annahmen denn jetzt genau erfolgreich geprüft wurden und welche nicht und kannst dann halt entsprechend reagieren.

7111: Und da sei bemerkt ja mal auf dem Gebiet coole Integration Richtung es lag und ich glaube mittlerweile auch Microsoft Teams und wahrscheinlich noch einige andere Dinge gell ja

7111: die man so verwendet was ist bei meinem Bauch sehr transparent machen und dann wenn irgendwas fehlgeschlagen ist und das bietet sich dann wiederum z.b. auch andere werden

7111: Von von dem SLA Gedanken ist die schönste Form das sozusagen nicht direkt den hätten quasi dem Konsumenten Team zu Ex Pausen aber zumindest gibt's ne relativ einfach

7111: zu machen dass irgendwas jetzt aktuell nicht in den Daten ist wie man es erwartet hätte.

6566: Und werden dann alle Daten validiert also stell mir das so vor dass ich hier bei great expectations eine Reihe von Regeln habe die mehr oder weniger aufwendig sind und werden jetzt in so einem richtigen Szenario alle Daten durch die Pipeline durchkommen

6566: auch einmal durch dieses komplette regelset durch geleitet um die zu validieren.

7112: Ja also wenn du dir so eine Daten Pipeline anschaust dann gibt es ja immer sozusagen das ist ja eine Aneinanderreihung von Transformation wo du aus dem Datensatz

7112: Arne Datensatz be machst und überall wo du halt eben diese Transformation an wenn es das sind stellen die eben in Frage kommen um da halt eben so ein Set von Annahmen zu validieren.

7112: Jetzt ist es aber so dass du halt nicht an an jeder Stelle in deiner Datenbank eine Validierung machen musst weil es ist ja halt auch eben.

7112: Rechenintensiv und teuer das heißt insbesondere so.

7112: Der Anfang und das Ende einer Daten pipelined eignet sich halt besonders um halt Annahmen zu prüfen oder halt eben irgendwo zwischendrin wo vielleicht man ml Modell trainiert wird oder sowas er hat eben diese diese

7112: stellen wo deshalb besonders sensibel ist wenn da irgendwas mit den Daten nicht stimmt

7112: ähm und dass man halt üblicherweise macht ist heute man braucht sich im Prinzip so Verzweigung auf also wo du quasi an dieser Zweigstelle die die Datenqualität bzw deine Erwartung bei dir und.

7112: Dann entsprechend links oder rechts abbiegt je nachdem ob dein Datensatz die Validierung erfolgreich bestanden hat oder eben nicht genau und so gesehen

7112: das kann jetzt auf verschiedenen granularitätsstufe machen du kannst beispielsweise wenn auch nur eine Annahme nicht erfolgreich validiert werden konnte den gesamten Datensatz aussortieren und quasi,

7112: in Quarantäne schieben du kannst aber auch sagen also wenn ihr z.b. eine Annahme hast die sich jetzt nur auf einzelne Zeilen was wird dann jetzt noch auf einen Cent zeilenbasiert beispielsweise.

7112: Die custom ID doch nicht mehr als sein oder sowas dann könntest du auch hergehen und nur diese eine Zeile aussortieren und den Rest aber dann quasi weiterleiten und weiterverarbeiten.

7111: Genau deshalb auch mal Tobias ein bisschen Fingerspitzengefühl bei den expectations und daneben natürlich mit den Daten auch selber Anna weil wenn jetzt irgendwie mal der rowcount von der Tabelle um 0,5

7111: und ab weißt dann will man wahrscheinlich nicht dass die ganze Zeit beim stehen bleibt sondern eben nur bei schlimmeren können zum Beispiel ich die Hälfte der.

6566: Mehr glaube ich wie wirkt sich das eigentlich auf die Performance aus also wenn ich da jetzt irgendwelche aufwendigen Regeln drin habe merkt man das.

7111: Ich erinnere mich tatsächlich als ich vor paar Jahren great expectations zum ersten Mal eingesetzt hat da war es ein bisschen schaust aber weil wir dort schon mit relativ großen Datenmengen gearbeitet hatten

7111: und dort also damals war es nur möglich quasi dass die Library quasi auf einem Note quasi zu verwenden

7111: mittlerweile ist es aber tatsächlich möglich auch bald expectations in Kombination mit Becher zwei bissbark zu verwenden also spricht das dann auf die Validierungen verteilt stattfindet

7111: das kann natürlich je nach expectation das natürlich aufwendiger können das aufwendige Berechnung sein aber man hatte auf jeden Fall die Möglichkeit.

7111: Zu skalieren sozusagen.

6566: Aber mit der Klaus unterwegs sind dann ist es ja kein Problem denn da kann man dann ja nahtlos hochskalieren und sein können wir auch mit ganz ganz großen Datenmengen umgehen.

7112: Aber prinzipiell muss man schon sich bewusst darüber sein dass halt jede Validierung von Erwartung auf Daten halten mit gewissen kosten einhergeht und da halt eben eine Balance finden und da kann ich mir schon vorstellen gerade wenn man zu rennen,

7112: also Bereiche kommt wo halt.

7112: Deshalb sehr zeitkritisch ist dass man halt möglichst schnell möglichst aktuelle Daten haben möchte wo also das Hansen in dem wichtige Rolle spielt

7112: da dann halt irgendwo eine datenvalidierung dazu integrieren das schlägt natürlich dann halt eben.

7112: In negativer Weise auch die Latenz durch so dass man halt da daneben immer eine Balance finden muss.

7111: Ja total guter. Total gut an. Also wenn expectation sie sind sicherlich nicht die richtige Library rum

7111: beide 27 Events irgendwie so frisch in die in die Plattform kommen von dem Frontend User Tracking oder so dass man da erstmal damit great expectations. Ob irgendein Zelte letztes sondern da gibt's dann sicherlich an.

6566: Und ansonsten wenn ich große Datenmengen habe und jetzt eine sehr geringe Latenz brauche

6566: gibt's dann sei doch andere Strategien also dass ich beispielsweise nur jedes tausendste Datenpaket mir anschaue und in die validiere um da wenigstens ein gutes Gefühl zu bekommen halt durch so eine Stichprobe

6566: oder gibt's vielleicht noch andere Möglichkeiten wie ich dann umgehen kann wenn ich jetzt nicht unbegrenzte Ressourcen habe um das Live alles durchzuführen.

7112: Genau dass das wäre eine Idee also das könnte man halt machen also dass man halt systematisch Samples von deinen Daten von den Daten validiert was heute andere Alternative ist also man kann auch unterscheiden

7112: möchte man die Validierung machen bevor man die Daten beispielsweise.

7112: In in den größeren Datensatz integriert oder bevor man sie an externe Konsumenten halt bereitstellt

7112: oder möchte man das im Nachhinein machen

7112: also man kann ja trotzdem so einen z.b. Datenstrom relativ zeitnah bereitstellen oder in einen in eine Größe in einen größeren Datensatz integrieren

7112: und dann hat auf diesem großen Datensatz regelmäßig Validierung durchführen so dass man dann halt zumindest im Nachhinein oder sehr zeitnah

7112: mitbekommt wenn da die Datenqualität beeinträchtigt ist im besten Falle hat man dann auch noch nennen

7112: eine Möglichkeit halt eben z.b. diese diese fehlerhaften Datensätze aus dem großen Datensatz zu entfernen oder zu korrigieren

7112: oder vielleicht über so eine Art time travelling Feature auf einen früheren Stand von dem von dem Datensatz zurückspringen zu können also quasi Senat Fallback Mechanismus.

6566: Sehr interessant gedanklich komme ich jetzt aber wieder zu dem Punkt den wir vorhin schon das ein oder andere mal besprochen haben und zwar zu den Domänen expert.

6566: Denn hier brauche ich ja eigentlich die Unterstützung von den Domänen Experten denn nur die können mir sagen ob es auch in Ordnung ist wenn ich diese Daten vielleicht einen Tag später oder eine Stunde später analysiere und dann den Pointer bekomme hey das stimmt irgendwas nicht du musst jetzt noch irgendwo reagieren.

6566: Denn für uns Techniker ist es vielleicht immer ziemlich cool die modernste und die eskalierende Lösung zu haben aber hier finde ich jetzt auch spannend dass es vielleicht ja einfachere Lösung gibt.

6566: Die mit weniger Hardware mit weniger Ressourcen auskommen und die nach Use-Case auch noch sehr sehr gut passen können.

7111: Genau also wie die wir eigentlich schon besprochen hatten das ist von von Daten Produkt Zutaten Produkt eigentlich unterschiedlich was für Daten qualitätsmetriken entscheiden sein können.

7111: Und dementsprechend sollte man dann auch den den Katalog von great expectations von der technischen Seite soll ich mal vorsichtig benutzen Ausmalbild sicherlich keinen Sinn

7111: expectations wieder mittlerweile gelistet haben die einfach mal über die daten laufen zu lassen das ist sicherlich nicht das empfehlenswerteste

7111: danke.

6566: Lass uns doch zum Ende hin noch einen Blick in die Zukunft werfen wer mir jetzt viel drüber gesprochen dass es schon Gemeinsamkeiten zwischen Software Engineering und data Engineering gibt.

6566: Okay da steckt doch überall schon der Begriff Engineering drin aber wir haben drüber gesprochen dass ich jetzt im Software-Engineering ganz viele Sachen im Zusammenhang mit Qualitätssicherung entwickelt haben und dass ich die Sachen auch immer noch.

6566: Und dass wir jetzt in data Engineering ähnliche Ansätze sehen was glaubt ihr denn wie sich das data engineering in diesem Bezug in den nächsten ich weiß nicht 45 Jahren vielleicht weiterentwickeln kann.

7111: Der berühmte Blick in die Glaskugel.

6566: Ja ich hoffe ihr habt eure Kristallkugeln schön poliert das hatte ich euch ja vorab gesagt jetzt ist der Zeitpunkt dafür.

7111: Genau genau poliert und bereits ja also ich denke und hoffe gewissermaßen auch dass die verschiedenen.

7111: Dann sage ich mal noch enger zusammenwachsen werden ich glaube dein Trainieren kann man das aktuell ganz gut beobachten dass es nur so schießt von von neuen Frameworks und Tools woraus man einfach dann aussieht.

7111: Der Bedarf und dieser neuen Frame Frameworks und Tools gerade eben auch in vier mit der dem Fokus auf klassische Softwareentwicklung und.

7111: Wenn ich es dann bitte auch weiterhin sehr groß und ich denke da wird es gewissermaßen dann auch zu einer zu einer Verschmelzung kommen stellenweise.

7112: Also was man ja auch die letzten Jahre gesehen hat dass die Unternehmen halt mehr und mehr auch datengetrieben werden heißt sie treffen Entscheidungen basierend auf Daten.

7112: Teilweise bereits Hulk oder vollautomatisiert

7112: es werden mehr und mehr datenprodukte gebaut in dem Sinne dass man halt auch eben z.b. maschinelle Lernverfahren einsetzt wo halt auch Datenqualität eine zentrale Rolle spielt

7112: und daher kann ich also was ich feststelle ist halt eben das dass,

7112: Daten mehr und mehr als eigenes esse begriffen werden aber dann halt auch einen eigenes Interesse daran hat

7112: da halt eben ein qualitativ hochwertiges Produkt anzubieten sei es innerhalb eines Unternehmens über verschiedene datenprodukte hinweg aber auch über Unternehmensgrenzen hinaus.

7112: Beispiel der Anbieter von Finanzdaten oder Wohnungsinserat and oder so etwas in die Richtung.

6566: Weiß dass du dass es auch in Zukunft noch ganz spannend bleibt ich kann mir noch am Projekt erinnern wo ich als Entwickler tätig war.

6566: Und dann auch er zu tun hat er mit Leuten aus dem data Engineering Bereich,

6566: eigentlich macht das schon gefragt habe hey warum duzt ihr vielleicht nicht die Best Practices die wir ja auch haben also sowas wie Versionskontrolle beispielsweise

6566: warum hat er miteinander gesprochen und hat sich gegenseitig da auch mal Tipps gegeben und das fand ich immer eine total gute Sache weil man da auf der einen Seite Wissen weitergeben konnte das für ein selbst selbstverständlich war.

6566: Auf der anderen Seite aber auch was neues lernen konnte und ich sag mal wenn man den 14 Jahre nur Java-Entwicklung macht dann steckt man da halt ganz tief drin in diesem Jahr war Tunnel und hat vielleicht nicht unbedingt zu viel Ahnung was ist noch an

6566: modernen interessanten Sachen und ansetzen gibt's die halt außerhalb von dem Kosmos sind

6566: konnte nicht wann solche Projekte dann auch immer ein ganz guter Weg um einfach mal was neues dazu zu lernen ich finde schön dass wir bei uns halt Leute aus allen Bereichen haben und ich beobachte auch das gerade so die Software best practices.

6566: Dass die jetzt halt nicht nur bei uns in der Entwicklung verwendet werden sondern dass die ganz selbstverständlich auch im Bereich data Engineering verwendet werden denn da entwickelt man ja auch Software vielleicht auf einem anderen Level oder mit dem anderen

6566: Focus

6566: und diese best practices die werden auch natürlich im Bereich alteo verwendet also bei den Kollegen und Kollegin ist eh um den Betrieb von Systemen kümmern weil da wird heutzutage durchaus Software entwickelt da muss man auch irgendwie Dinge versionieren da müssen auch ähnliche Skripte getestet werden jetzt.

6566: Und dann das finde ich einfach super spannend.

7111: Ja ich find das ist eine total gute Analogie zu zu data Engineering general na weil das ist jetzt nicht nur also.

7111: Quality is eben 1und Ahnsbeck aus der data science Ecke und vielen verschiedenen natürlich auch Infrastruktur Tiere sind da immer relevant deshalb ist auf jeden Fall.

7111: Super Spannungsfeldern ich glaube das bist du auch noch wach bleiben.

7112: Und idealerweise arbeitest du mit Kollegen und Kolleginnen in einem Team zusammen die halt eben die unterschiedlichsten Skills Verein und mal eben gemeinsam an einem Produkt zu arbeiten und so kann man halt auch

7112: am gegenseitig voneinander lernen und halt auch ebenso Energien schaffen.

6566: Ja da bin ich ein riesen Fan und zwar eigentlich schon mein ganzes Berufsleben lang ich fand es immer schon toll im Team zu arbeiten mit vielen Leuten die in unterschiedliches wissen haben dann mal ganz ehrlich

6566: du kannst nicht alles wissen also du kannst vielleicht in der Breite schon ja ein ziemlich breites Wissen haben um Dinge zu verstehen um Zusammenhänge zu verstehen und dann hast du halt noch so ein zwei drei Bereiche wodurch richtig richtig gut auskennst.

6566: Aber das ist ok und jetzt bin ich in dem Projekt und die zwei drei Sachen in denen mich richtig gut auskenne

6566: die reicht natürlich nicht aus und so ein ganzes Projekt umzusetzen und den Situation das ist natürlich toll dann noch so einen CallYa oder soll Marcel oder noch eine andere Kollegin irgendwie zu haben

6566: die eben andere Schwerpunkte haben so dass man sich gut erkennst uns dann die Sache wenn wir gut erledigen kann das Projekt gut umsetzen kann und dabei auch immer noch was lernst denn ich glaube so dieses Wissen in der Breite dass man hat

6566: für mich ist das auch so ein bisschen wie ein Baum also so ein Baum der Richter jedes Jahr so ein neuen Ring.

6566: Mit diesem Wissen dass man in der Breite hat wenn ich ist es ja genauso wenn man viele Jahre mit Leuten zusammen arbeitet und von denen was lernen kann dann gibt's da auch immer wieder noch mal so eine kleine Schicht oben drauf und dadurch wird dieses breite wissen.

6566: Ja immer noch ein bisschen breiter und das ist einfach eine schöne Sache dadurch wieder Job auch nie langweilig.

6566: Und jetzt muss ich die Gelegenheit doch direkt mal für einen unverschämten Werbeblock nutzen wenn ihr Lust habt was mit Daten zu machen dann schaut doch mal auf unserer Webseite auf inovex de

6566: denn wir suchen aktuellen paar Leute für den Bereich data engineering,

6566: und vielleicht ist es ja was für euch dann dann könntet ihr in Zukunft ja mal mit dem Marcel mit dem CallYa zusammen Projektarbeiten und euch z.b. um data quality kümmern und natürlich auch gerne bei mir hier zu Gast im Podcast sein.

7111: Ja absolut

7111: also ich glaube das ist eine super Gelegenheit weil bei uns kann man eben einfach bei so vielen verschiedenen Daten Töpfen quasi reinschauen mit Daten experimentieren auf die Datenqualität gucken wir jetzt hier ausführlich besprochen haben

7111: und was eben auch schon gesagt Amazon Eltern sind irgendwie das wirklich jeden Tag irgendwie eine neue Aufgabe und das ist auch was mich zumindest total,

7111: Bock drauf hat dann genau meldet euch.

6566: So jetzt zum Schluss hin wie sieht's aus haben wir die wichtigsten Themen im Bereich data quality behandelt oder gibt's noch irgendwelche anderen Themen die war auf jeden Fall jetzt noch ansprechen soll.

7111: Ich glaube wir sind halt solche über die wichtigsten.

7111: Dinge gegangen also vielleicht noch mal zusammengefasst ne es ist immer super wichtig auf die auf die Domäne zuschauen mit den richtigen Leuten sich erstmal zusammenzusetzen und das ganze dann iterativ anzugehen.

7112: Ja

7112: dann werden die wesentlichen Punkte angesprochen wenn man jetzt aber mal wirklich so in die Tiefe noch mal eintauchen möchten das Thema da gibt es einige Blog Beiträge und Artikel Kolja und ich wir schreiben

7112: zufälligerweise gerade aktuell ein und wir bieten demnächst auch ein ein Meetup an also da.

7112: Gibt es viele Möglichkeiten sich noch weitergehende Informationen rund um data quality zu.

7112: Besorgen.

6566: Ja da ist er direkt noch mal Werbung drin wann ist denn dieses Mieter bist du schon bekannt.

7112: Wir haben mal grob ausgemacht dass wir das Meetup so im August bzw September jetzt diesen Jahres also 20-22 machen.

6566: Okay und wenn das bekannt ist dann könnte es auf jeden Fall bei uns auf der Webseite finden oder ihr geht einfach auf Meetup.com und ihr folgt uns da dann bekommt es dann auch automatisch mit sobald hier in announcement stattfindet und ja fragen euch noch mal

6566: gibt's schon irgendwelche Infos über den Inhalt also habt ihr da vielleicht schon eine kleine Sneak-Preview für uns.

7111: Mit great expectations werden wir uns auf jeden Fall auch beschäftigen auf dem Mieter.

6566: Dann sind die Erwartung auf jeden Fall sehr groß.

6566: CallYa Marcel vielen Dank dass ihr da wart und heute was über data quality erzählt habt ich habe viel gelernt und ich werde es wissen natürlich als mein eigenes ausgeben wenn ich mich demnächst irgendwann mal wieder mit Leuten über Daten unterhalte vielen Dank dafür.

7111: Vielen Dank für die Einladung.

7112: Ja danke auch Ciao zusammen und vielen Dank für eure Aufmerksamkeit.

6566: Ja von meiner Seite vielen Dank fürs Zuhören die nächste Folge die gibt's wieder in zwei Wochen

6566: und deine Lust habt dann freut uns doch auf unseren sozialen Kanälen z.b. auf Instagram oder auch auf LinkedIn dabei kommt immer die aktuelle News mit und natürlich auch die aktuelle Info wenn es neue Episode,

6566: wenn Ihr Feedback zum Podcast habt dann schreibt mir doch gerne E-Mail an Podcast erinner weg.de ich würde mich freuen von euch zu hören tschüss und bis bald.

01:03:07: Intro