Modernisiere Self-Service-Analytics mit dbt

Transcript
Gut, ich würd sagen, so langsam können wir loslegen, oder? Genau, ja, ich glaube, dass die Leute sind hier. Und ja, einen schönen guten Morgen. Vielleicht regner ich 'n Morgen. Ja, einfach zuerst einige Ausreden oder sei bitte höflich im Chat. Sie werden die von diesem Webinar binnen vierundzwanzig Stunden dann kriegen. Lassen uns, also lass uns bitte Feedback, wie wie Sie es finden und ja, wenn da Umfrage ist, dann bitte, es wäre großartig, wann Sie die Umfragen antworten könnten. Und wenn Fragen sind, jederzeit gerne in den Chat und dann beantworten wir gerne die Fragen. Gut. Dann würd ich sagen, start ich mal. Mein Name ist Marc Antort. Ich bin hier Solutions Architekt bei DBT Labs und ja, freu mich heute, euch ein bisschen was von unseren neuen Features zu zeigen, die sich generell mehr an Analysten wenden. Vielleicht kurz zu mir, bevor ich bei DebTC Labs gestartet bin, war ich auch auf der Consulting Seite und war da Data Engineer für eine lange, lange Zeit. Also viele der Herausforderungen, die man so im Alltag hat als Data oder als Analyst. Da ich saß selber von diesem Problem und ja, freu mich, dass ich dann jetzt auf der anderen Seite helfen kann, diese Probleme zu lösen. Wunderbar. Mein Name ist Certanja, Certanja Jushi. Ich bin ein Data Architekt bei Interworks. Wir sind DBT Labs Partners und wir helfen unseren Kunden, ja, cloud basierte und moderne wartungsarme Datenplattformen einfach auf aufzurichten, ne. Und DBT ist ein, ja, ja, sehr wichtigen Teil da drin. Und genau, also die die Sachen, die wir heute oder über die wir wir heute sprechen werden, die sind, ich glaube, für uns allen sehr sensitiver oder sehr, sehr Lieblingsthema, ne. Also Selbstservice, wir haben allen darüber mehrmals vielleicht gesprochen und ja, jede Organisation will einfach datengetrieben und daher ja, ist ein sehr wichtiger Teil davon. Das ist ja, also ohne gelungen oder geschafft zu haben, ist es schwierig für eine Organisation datengetrieben zu sein. Und wir wir werden diskutieren, was für ein Problem und das trotzdem, manchmal fühlt es sich, dass es ist ein wechselndes Ziel oder es ist wie eine Mirat, dass, okay, wir wir haben es, wir sehen es, aber und trotzdem geht es irgendwie oder erreichen wir bis diesem Ziel irgendwie nicht. Und wir werden einfach diskutieren, warum nicht und was können wir dafür tun und wie Dimiti dafür helfen kann. Ja, so Mark, also was sagst Du? Also welche Sachen hast Du gesehen in und für Service? Was meinst Du? Ich glaub, alles schon mal irgendwie gesehen in den unterschiedlichsten Ausführungen, unterschiedlichen Teams, unterschiedlichste Branchenkunden. Alles war eigentlich schon mal irgendwie da, weil Self Service ist, glaub ich, ist kein Thema von den letzten drei Jahren, sondern das Thema Self Service, das hab ich schon im Studium gehört, hey, wir müssen Self Service machen. Und dann haben irgendwie Analysten ja, Zugänge auf die Datenbank oder zu krassen Tools wie Informatiker bekommen und saßen dann da, ja, jetzt können wir Self Service machen, aber sag mal so wirklich Self Service war das dann auch nicht, weil da fehlte dann einfach auch das Know how. Also Wilderwesten war schon oft immer ein Thema bei über alle Jahre hinweg. Ja, und auch auch jetzt, ne, auch mit diesen alle modernen Datenplattformen passiert es mehrmals, dass ja okay, wir haben zum Beispiel Kassen, zum Beispiel Data Breaks oder Snowflake. Wir haben das erworben und und danach ist es aber, ah okay, wir wir geben keinen Zugang zu Analysten, zu diesem, weil das also unsere Daten sind zu viel sensitiv sind und ja, jeder sollten keinen Zugang zu solche solche Plattformen kriegen. Unsere Produktionsdaten sind einfach viel wertvoller. Und dann glaube ich eigentlich ja und die Analysten dann sagen, okay, also wäre cool, wenn ich dazu einen Zugang hätte. Und jetzt, weil ich jetzt keinen Zugang habe, ich hab meinen Zugang zu meinem BI Tool und dort sehe ich die Dashboards und sehe ich, also ich kenne mich die Daten gut aus, aber trotzdem leider kann ich nur die Felder sehen, die mein Data Team für mich zur Verfügung gestellt hat. Und ja, ich sehe auch einfach Fehler und dafür muss ich dann denen kontaktieren, lieber besser, dass okay, ich herunterladen diese Daten, vielleicht basteln was in Excel und dann gehen, also mache ich meine Ziele, ne. Oder wenn wenn mein Chef oder wenn wenn da 'n Analyst ist und dann sein Chef ist, das okay, ich brauche diesen Bericht. Und in diesem Bericht brauche ich auch dieses KPI, wo derzeit dort nicht existiert. Und wie können wir dann dann schnell das schaffen? Wir können jetzt unter einige Stunden unseren Dashboard nicht aktualisieren, weil es einfach geht nicht, obwohl ich, also obwohl als Analyst, wenn ich Zugang zu diesem BI Tool habe und wenn ich auch diese Dashboard aktualisieren kann, die Daten sind dort einfach nicht. Das das das passiert auch mehrmals. Und ja. Meistens ist es ja dann nur irgendwie eine zu zusätzliche Summe oder so, die ich benötige. Da sind zwei Zahlen, ich brauch die aber eigentlich im Bericht zusammen oder noch irgendwie angereichert mit anderen Daten. Technisch gesehen ist das nicht schwierig, aber Zeit, diese Änderung zu machen, die fehlt oft in irgendwie in den IT Teams. Sprints sind schon durchgeplant für die nächsten drei, vier Sprints. Ad hoc Änderungen sind da dann halt immer schwierig noch einzubekommen. Und eigentlich will ich nur die Zahl ausprobieren diese Woche. Ich weiß noch gar nicht, ob ich sie brauche und will's einfach nur testen und will da nicht jetzt drei, vier Monate drauf warten. Ja. Und danach kommen, also was wir jetzt gesprochen haben, ne, also die Schattensysteme, die anfangen zu wachsen. Und ja, also obwohl ich diese modernste, diesen modernsten Stapel auch wenn ich habe, trotzdem fühle ich mich dann besser mit meinen alten Tools, weil ich dort weil ich dort Kontrolle habe, weil ich dort selbst was machen kann. Und dann ist es für das Data Engineering Team oder auch für für IT ist es das a okay. Also wie kann ich diese Data aufführen oder stoppen? Weil jeder dann einfach geht zu diesem Tool und dann ladet die Daten herunter und dann macht was was was die was sie wollen, ne, einfach. Und das ist bisschen dann, ja, das ist bisschen gefährlich auch und auch zum Beispiel, okay, ich hab jetzt seit letzte Woche drei Versionen in meinen Spreadsheets, wo ich drei unterschiedliche Definitionen für eine KPI umgesetzt habe. Und jetzt weiß es nicht, welche davon die aktuellste ist. Die drei habe ich in drei unterschiedliche Meetings benutzt. Und jetzt will ich aber die Richtige an meinem Data Team geben und die das ja, das Data Team sagt das, okay, aber wir haben jetzt halt keine Zeit, ne. Also es ist ja, bist Du nun, es es geht so weiter dann. Und dann die die Tooladoption oder ja die Akzeptanz geht auch runter und die Businessnutzer dann sagen, okay, ich ich kriege meine KPIs sowieso aus einem E-Mail. Meine Analyst schickt mir jeden Tag oder jede Woche eine E-Mail und das kann dann einfach so weitergehen. Warum haben wir so viel dann investiert, ja? Ich glaube, dass also alle Spiele in in diesem Spiel oder die wichtige Spiele sind sind diese Leute, ne. Also Data Engineer, Power Analyst und Business User. Also Business User ist, die Definition ist klar, die Leute, die tatsächlich diese Geschäftswerten, diese Geschäfts KPIs und die Kennzahlen haben wollen, damit die bessere Entscheidungen oder die wichtige Entscheidungen machen können. Und es gibt dann die bisschen Überlappung zwischen und die Data Engineers und die Power Analysten, die arbeiten und die bemühen dafür, dass die Ergebnisse diese KPIs an an solche Nutzer dann zur Verfügung stellen können. Und die Daten sollten dann immer richtig sein, die die Daten sollten immer aktuell sein und so. Aber es gibt auch bisschen Unterschieden in in diesen Rollen. Also Data werden bisschen mehr darauf achten, dass okay, ob die Daten aus meine Quellsysteme wirklich richtig einfließen in meine Data Plattform oder nicht. Oder gibt es also gibt's diese Verbindungen zu dieser API, also steht diese Verbindung noch oder wurde es zusammengebrochen? Daran musste ich dann kümmern. Ich musste auch kümmern, dass niemand sollte die falsche Daten dann kriegen oder die Daten, die die die nicht sehen sollten oder nicht sehen dürfen, plötzlich haben die Zugang auf diesen Daten. Und deswegen Data Engineer sind auch beschäftigt mit solche Sachen, die nicht nur Analyse gehen. Und dann die Power Analysten sind tatsächlich die Nutzer, die zum Beispiel, also die kennen die Daten also aus, ne. Die kennen die Daten sehr gut, die helfen für diese Analyse. Mehrmals passiert ist, dass die Power Analysten, die sind sehr gut mit den Daten, aber nicht immer gut mit den, also mit dem Technik. Das heißt, nicht jeder kann sehr kompliziert das SQL Query schreiben oder Python Code schreiben. Und Data Intelligenz können das machen, aber die kennen die Daten nicht richtig gut aus. Und das einfach bringt, also diese Personas, die müssen miteinander zusammenarbeiten, aber trotzdem, das bringt es, ja, die kommen, die Sachen zwischen denen müssen dann irgendwie fleißig sein. Ja, und ich sag mal, diese Zitate, die kommen wir uns relativ bekannt vor. Also in meiner Zeit als saß ich eigentlich immer auf dem Strich in der Mitte zwischen dem IT Team und zwischen den Power Usern oder Analysten auf der linken Seite, weil oft dann gesagt wurde, hey, ich möcht einfach nur meine Frage beantwortet haben, ohne auf der einen Seite tagelang zu warten über die neue Tabelle oder View oder auf der anderen Seite mich durch undokumentiertes SQL wühlen und selber dann herausfinden in Unmengen an Codezeilen zum Beispiel. Ja. Was ist denn jetzt die Antwort auf meine Frage? Und auf der rechten Seite, auf der Data Engineer Seite sitzt dann halt genau der Gegenpart, der sagt, hey, ich kann nicht alles stehen und liegen lassen für eine Ad hoc Abfrage. Wir haben unsere Sprints geplant, mein Zeit ist auch geplant, sag ich mal. Und es wär eigentlich super, das finden ja die meisten Data Engineers auch gut, wenn die Analysten selber eine Möglichkeit haben, solche Ad hoc Anfragen zu realisieren, selbst die Antwort zu finden. Es geht da ja bei meistens nicht hochkomplexe Abfragen, die auch wirklich Entwicklungszeit brauchen, wo sich dann jemand, der wirklich gut in SQL ist, auch irgendwie ein, zwei Tage mal hinsetzen muss und diese Abfragen baut oder diese Informationen aus den Daten zusammenbringt. Es geht da ja meistens hey, ich brauch aus dem Kunden den Umsatz und die Kundennummern und aus der Region. Die Region, bring mir die Daten bitte zusammen. Und dass ich sehen kann, hey, welche Kunden in welcher Region haben denn grade was an Umsatz generiert? Einfach nur eine Frage, die ich schnell beantwortet haben möchte. Und für solche solchen leichten Sachen hab ich mir auch als Data Engine immer gedacht so, hey, das ist supereasy, das setz ich in fünf Minuten aber ich hab grad nicht die Zeit dazu oder beziehungsweise andere Aufgaben haben grad mehr Priorität. Hey, lass kurz zusammensetzen, lass die Analysten mal irgendwie, dass sie solche Abfragen selber machen können. Und dann geht's los, wie eben schon erwähnt, hey, Zugänge zur Datenbank fehlen, Zugänge zu bestimmten fehlen. Ich kann nur bei meinem BI Tool arbeiten und dann ist einfach genau der Punkt, wo ich dann halt sage, ey, lass uns da die Analysten, dass die auch selber was machen können. Stimmt, ja. Wird danach direkt rausgeschickt, ja? Seh ich grad die Frage, dann kann man die Aufzeichnung auch ansehen. Genau und DBT hat sich jetzt gedacht, hey, wie können wir unsere User genau in diesen Fragen, das wir grade hatten? Bilderwesten, Teams kommunizieren nicht richtig, Ad hoc Anfragen, Datenteam ist überlastet beziehungsweise Sprint ist schon geplant. Wie können wir da helfen, Menschen zu, die zum Beispiel wissen, was sie fragen wollen, aber nicht, wo sie anfangen wollen, die schnell Antworten brauchen und nicht auf Technikteams, IT und so weiter warten wollen oder auch einfach die schnell vorankommen wollen? Die wissen genau, was sie tun, wollen aber die Governance nicht verletzen, sprich, wie eben schon erwähnt, hey, ich will mir die Daten aber die Governance nicht verletzen. Sprich, wie eben schon erwähnt, hey, ich will mir die Daten nicht nach Excel ziehen, dort komplexe Sachen aufbauen und dann meine Fragen beantworten. Ich will das ja gerne mit den Tools machen, die wir haben. Weil dann basiert auch meine Antwort auf Zahlen, die die anderen alle zur Verfügung haben und nicht auf veralteten Zahlen, weil es ist kennt vielleicht jeder mal, man hat sich bis dann doch was in Excel gezogen, arbeitet damit und über Nacht ist eigentlich 'n kompletter neuer Datensatz gekommen, 'n kompletter neuer indische Load und ich arbeite auf völlig veralteten Zahlen, geh ins Meeting, sag, hey, ich hab die Lösung und alle gucken mich an und sagen, hey, da da fehlt jede Menge, ja. Während unsere Datengrundlage hat sich schon stark geändert. Und eigentlich hab ich genau das Richtige gemacht, aber halt leider an den Tools vorbei und ich möchte mit den Tools arbeiten. Und als Letztes, primär richten sich eigentlich diese neuen Features, die wir jetzt bei DBT haben. Ich hab hier einfach mal die verschiedenen Facetten, die wir als Analysten haben, da draußen im haben 'n paar aufgeschrieben, Data Analysten, Business Analysten, technische Analysten, Analytics Engineers. Alle diese Namen, die fassen ja eigentlich zusammen, hey, ich möchte mit den Daten arbeiten und wenn ich kann, vielleicht sogar auch mal selber. Dass ich mir schnell Antworten generiere, dass ich nicht das Vertrauen in unser IT beispielsweise verliere, sondern einfach ja, damit dann arbeiten kann. Und das ist praktisch hier die Folie, die das son bisschen zeigt. Wir wollen ja nicht mit diesen Features sagen, hey, das Team brauchen wir gar nicht mehr. Das ist ja Quatsch. Weil wir brauchen das Team immer noch für, bringen wir die Sourcen zusammen, binde die Sourcen, die Quelldaten alle an in einen vernünftigen Bereich, in vernünftigen und dann in die Daten zur Verfügung stellen. Aber halt nicht mehr so, wie ich es früher kannte, dass man dann da eine View hat, die dann am besten heißt, Umsatz pro Kunde im Quartal und die zeigt wirklich nur Kunden ID an, den Umsatz und das Quartal. Mit mit der View kann ich nicht zum Beispiel auf Wochen oder Tagen nehme zurück. Ich könnt vielleicht auf Jahre, das kann ich hoch addieren. Aber der Informationsgehalt ist da, aber sehr begrenzt. Ich brauch eigentlich eine View, die mir schön auf der kleinsten Ebene aufzeigt, hey, das sind die Umsätze pro Kunde und dann kann ich mir selber damit das Quartal, das Jahr, das Monat erstellen. Und genau das ist das, was wir praktisch mit diesem Service in DBT erreichen wollen. Links die Datengrundlage und rechts die von den verschiedenen Analystengruppen, die mit den Tools arbeiten, die wir zur Verfügung stellen und sich dann selber praktisch die Daten so erstellen oder die Datengrundlage so erstellen für ihre Berichte, wie sie sie benötigen. Hat 'n diverse Vorteil, ich hab sie unten mal mit eins, zwei, drei, vier aufgelistet. SQL Code muss nicht andauernd neu geschrieben werden bei den Teams. Logigesübergreifend und Doppelarbeit wird dann halt auch verhindert, weil natürlich die Analystengruppen in 'nem Datamesh auch am besten miteinander sprechen und man in so Features, wie wir gleich zeigen, wie die wie die Katalog, einfach schon mal vorher sehen kann, hey, was ist denn da? Was gibt's schon? Was kann ich wieder benutzen und muss das Rad nicht neu erfinden? Weil's Rad neu erfinden braucht immer mehr Zeit, als einfach 'n bestehendes Rad an mein Auto zu schrauben und loszufahren. Und ganz wichtig hierbei, KI kann ich natürlich auch unterstützen. Da kommen wir gleich auch noch mal in den Features ja, drauf zurück. KI ist in aller Munde. Möcht mir mein Leben mit KI erleichtern. Ich brauch nicht mehr alles perfekt können oder wissen, wo's genau steht. KI kann mich da super unterstützen. Und selbst wenn ich jetzt neu in SQL bin oder SQL das letzte Mal in der Uni hatte, dann kann ich da mir helfen lassen von KI und trotzdem mit SQL mit den Daten arbeiten, ohne dass ich jetzt wieder einen Wochenrefresh Kurs machen muss, SQL noch mal von Grund auf zu lernen. Genau. Und das sind praktisch die drei Features, die wir in DBT Plattform anbieten, die unserer Ansicht nach darin unterstützen. Von links nach rechts eigentlich das Entdecken, das Interagieren mit Daten und das Entwickeln ganz rechts mit DebTC Canvas. Und auf diese drei Tools wollen wir jetzt auch näher eingehen in unserer Demo. Einmal ganz kurz abgerissen, sag ich mal, DebTC Katalog ist wirklich dazu da, die Daten zu entdecken. Was hab ich schon in meinem Stack zur Verfügung? Ich muss jetzt nicht die nächste aufbauen, die Daten fürn Customer sind schon sicher irgendwo bereitgestellt und ich kann sie einfach wiederverwenden. DBT Insights ist praktisch dafür da, wir hatten ja eben schon gesagt, Zugänge auf Datenbanken fehlen teilweise. Bin ich auf 'ner Databrix, Snowflake oder Fabric unterwegs, viele Analysten haben keine einen Zugang direkt zu der Datenbank, aber vielleicht zu DBT oder hoffentlich zu DBT und können dann hier mit DBT Insights trotzdem sich Abfragen generieren und ja, validieren, verfeinern, können mit den Daten arbeiten direkt in DBT und diese Sachen dann auch teilen. Ich stell das auch gerne vor als, hey, wir können unsere IT super unterstützen, weil wenn ich weiß, hey, da ist 'n Fehler in meinen Daten, ich schon mal die kleine Voranalyse schreiben, schreib leicht aus kommentiert sogar in den Text rein, hey, ich hab das und das und das rausgefunden, speicher mir diesen Inside und häng das an das Ticket an. Da muss nicht der Data im IT Team noch mal eine komplette Analyse fahren, sondern er kriegt praktisch von seinem Analyst mitgegeben, hey, ich hab das Problem entdeckt. Mir fehlen vielleicht die tieferen SQL Kenntnisse, das Problem jetzt schnell zu beheben. Da kennst Du dich vielleicht im tieferen Data Stack, im Backend besser aus. Aber das ist die ja, die Analyse, warum das Problem auftritt. Ja, genau. Die Analysten können auch viele Ideen dann generieren, ne und zeigen das, ja okay, das können wir auch machen und so oder das sollte verbessert werden weiter. Genau, einfach schon Ideen sammeln und dann die Vorarbeit praktisch schon leisten, dann die Data Engineering Teams zu unterstützen. Oder aber ganz auf der rechten Seite mit DBT Canvas selber entwickeln, einfach mit einer Low Code No Code Experience. Ich möcht nicht mit SQL arbeiten, ich möcht mir praktisch eher Drag and drop meine einzelnen Schritte zusammenziehen und selber Models entwickeln, die ich dann weiterhin in meinen ja, verschiedenen Berichten oder Dashboards benutzen kann. Genau. Gut, dann würd ich sagen, springen wir zu den Demos, gucken uns einmal an, was wirklich im Tool gemacht wird, denn am Ende ist das am interessantesten, was kann ich wirklich im Tool machen? Wenn Fragen aufkommen, einfach in den Chat schreiben. Genau. Ja, wir beantworten die dann gerne. Das erhoffen wir die Fragen und fangen wir eh es an. Wir haben gesehen, welche Möglichkeiten mir zur Verfügung stehen als ein Power Analyst in DBT. Als ein Power Analyst, ich kenne die Daten meiner Organisation gut aus und ich arbeite täglich mit den Analysen oder erstelle die Berichten. Und jetzt möchte ich die Daten hinter diesen Analysen besser verstehen oder die Modellen besser verstehen oder die einfach ergänzen. Wie kann ich die mit oder alle diese Sachen mit DBT erledigen? Das sehen wir. Wir hatten auch über die Features geredet, die schrittweise mir ermöglichen können, nämlich entdecken, interagieren und entwickeln, ein besser Anal Service Analytik in DBT zu machen. Wie kann man das tun? Das sehen wir gerade. Ich logge mich in meinem DBT Konto ein und navigiere direkt zum Katalog. Zuerst möchte ich einfach entdecken, was alles da steht in meinem Projekt. Normalerweise als ein Analyst habe ich nur Zugang zu den Modellen, die ganz am Ende in der Kette oder die Vorbereitungskette da sind. Zum Beispiel mein Data Engineering Team hat für mich vorbereitet die Modelle, die konsumfertig sind. Das heißt, volle aggregierte Daten, volle bereinigte Daten und so weiter. In meiner Datenplattform habe ich keinen Zugang, aber nur zu diesen Modellen. Zum Beispiel hier, wenn man sieht, ich arbeite derzeit auf einen Use Case für die Kundenanalyse, Daten für die Kundenanalyse. Und in meinem BI Tool sehe ich normalerweise nur diese zwei Modelle, und fcd orders. Aber mit DBT kann ich die Verbindungen und Beziehungen von diesen Modellen zu den anderen Daten oder Datenquellen besser verstehen? Auf der Landingseite meines Projekts kann ich sehen, wie viele Modelle da sind, wie viele Quellen da sind, ob da ob da irgendwelche Tests da stehen und so weiter. Alle diese Sachen heißen DBD Assets, ne, Ich merke sofort, dass es gibt mehrere Modelle, als die normalerweise ich sehe. Und ich bin neugierig zu finden, okay, woher kommen eigentlich die Daten für meinen oder? Ich kann dann darauf klicken und das ist vielleicht den berühmtesten Blick von DBT oder jeder weiß, wer mit DBT arbeitet, diesen Blick. Dieser Blick heißt. Und dieser Blick sagt mir sofort, dass, okay, die Daten für f c t orders kommen aus SD orders oder SD g paiments. Wenn ich zurückgehe, einen Schritt zurückgehe zu der Modellseite, dann kann man diese also diese Modelling Layer, darüber wir gerade gesprochen haben, ne. Also die Rohdaten werden zum ersten Mal zu, danach vielleicht zum und ähnlich zum. Und das konnte ich dann auch in der Linie ziehen. In diesem kleinen Lineageblick sehe ich nur die eng bezogene Modelle zu dem Modell, das ich gerade sehe. Aber wenn ich zu diesem Blick wechseln würde, dann sehe ich die volle, von woher die Daten einfach stammen. Man kann hier auch merken, dass hier gibt's ein besonderen wie, diese also diese Hierarchie darzustellen. Drei plus mein Modell plus drei bedeutet, bitte zeig mir drei Schichten oder drei Ebenen in der Hierarchie vor meinem Modell und dann drei Schichten oder drei eben nach meinem Modell. Als mein Modell liegt hier ganz am Ende der Kette. Es gibt keine andere weiter oder weitere Modelle nach diesem Modell. Aber ich konnte diese Zahl hier einfach ändern und weitere Modelle oder weitere Hierarchie oder tiefere Ebene der Hierarchie anzeigen lassen. Noch ein wichtiges Feature von diesem Lineischblick ist auch diese Linsen. Normalerweise BYBITI zeigt oder als Standard, BYBITI zeigt mir nur, was ein Acetyp ist von dieser Artiveact. Zum Beispiel ich sehe, dass SRC bedeutet ein Source und MDL bedeutet ein Modell. Aber ich kann diesen Blick ändern und ich kann zum Beispiel zeigen lassen, ob meine Modelle als View material erstellt sind oder als Tabellen erstellt sind. Oder ich kann auch sehen, ob die Tests auf meinen Modellen erfolgreich waren und überhaupt da irgendwelche Tester waren und so weiter. Diese Linsen sind auch ein sehr mächtiges Feature von. Ich kann auch von ein Modell nach anderen Modell zum Beispiel, ich kann hier doppelklicken und direkt zu dem anderen Modell dann springen. Ich gehe hierbei zurück und jetzt, wenn ich mir über den weiß, ich kann auch den Code für mein Modell entdecken oder mehr Informationen über die Spalten kriegen. Die gibt's nicht nur für die Modellen, sondern auch für die Spalten. Und das ist vielleicht mein Lieblingsfeature oder Lieblingsfunktionalität mit Katalog. Hier sehe ich, dass wie diese Spalte eigentlich herkam. Aus welcher Quellspalte gab es mehrere Spalten, die dazu beitragen haben und in welchen Modellen wurde diese Spalte transformiert? Dann zum Beispiel, wenn irgendwas mit dieser Spalte nicht stimmt, ich kann einfach nur in den Modellen ansehen, wo diese Spalte transformiert wurde. Jetzt wir haben mir über die Modell Modellen gelernt. Das heißt, okay, was sind die Beziehungen meines Modells? Was sind die Datenquellen? Welche Tests dastehen und so weiter. Aber die, das ist nur die oberflächliche Information über mein Modell. Ich möchte jetzt wirklich mit den Daten meines Modell, meines Modells dann bearbeiten oder entdecken, was da drinsteht. Und dafür hilft mich dann Debyt Insights. Eine gute Sache ist, dass ich dann direkt zu Debyt Insights von diesem Katalogblick selbst springen. Dafür einfach kann ich hier Data auswählen und sehen wir sofort, dass die hat für uns schon ein schon eine Abfrage vorbereitet und an der rechten Seite hier in diesem Kanäle zeigt uns, okay, welche Modell, also welches Modell explorieren wir derzeit? Ich sollte dann diese oder diese Abfrage ausführen und zuerst testen, ob mich wirklich die Daten kriegen, die ich normalerweise in meinem Tool dann sehe. Ich bin nicht so fleißig mit SQL, aber kann einfache Änderungen dort machen. Zum Beispiel ich kann jetzt hier sagen, wir, nehmen alles und noch mal hier testen würde, ob das funktioniert. Bis das passiert, wir können hier sehen, ja, okay. Jetzt zeigt es mir die zwei Reihen, wo die erste Mauer gleich ist. In diesem Explore Blick kann man auch sehen, okay, welche alle Modelle da sind. Davon würde ich dann erfahren, okay, dass ich weiß, dass diese da ist und fc t orders da ist. Und dann ich ich kann weiter explorieren, okay, welche Spalten da sind, genau die Informationen, die ich aus Katalog auch gekriegt habe. Jetzt möchte ich weiter auf meinem Use Case für Kundenanalyse arbeiten, aber wie gesagt, ich bin nicht viel mit SQL fleißig und dafür kann ich dann Hilfe von Debivi Co Pilot dann geben. Ich habe einige Proms hier vorbereitet. Zum Beispiel, ich möchte wissen, welche alle Kunden da sind, die haben wird von fünfzig oder mehr als fünfzig. Und ich kann es an Copilot fragen und kritisieren, dass nicht nur Co Pilot meine Abfrage oder meinen Prompt auf Deutsch verstanden hat, es hat auch ein dafür hergestellt. Ich kann einfach mit dieser Taste diese Query hier nehmen und also man kann als auch merken, dass dafür musste ich diese DBT gar nicht wissen. Und sehe ich dann, ob es die Ergebnisse gibt, die ich erwarte. Okay, wir haben sieben Kunden, die mehr als also mehr als fünfzig haben. Jetzt möchte ich wissen, dass okay. Also was, wenn diese Kunden oder machen oder bestellen diesen Kunden überhaupt in einer Bestellung mehr als zehn? Zum Beispiel ich kann sagen, dass okay, Wie groß ist Ihre individuelle Bestellung? Gibt es überhaupt eine Bestellung, die mehr als zehn Wert hat? Und das ist nur für die Kunden, die einen wird von mehr als fünfzig haben. Und dafür brauche ich die Daten aus nicht nur ein, sondern zwei Modellen und das muss ich an d b t Co Pilot dann sagen. Und ich sage jetzt, okay, zeige mir bitte die alle Bestellungen mit mehr als oder gleich zehn für Kunden, die Wert mehr als fünfzig haben. Und voila, die gibt mir diese diese auch hier und was uns sehen. Ja. Es gibt mir die Ergebnisse, also ich kann sehen, dass es gibt mehrere Bestellungen, wo die Kunden auf einmal so viel Waren bestellt haben, von Wert viel mehr als zehn, manchmal sogar mehr als zwanzig und so weiter, ne. Aber hier fällt mir noch etwas. Hier kriege ich die Kunden IDs, aber keine Kundennamen. Und daher werde ich das an noch einmal an Copilot das anfragen, das bitte erweitere meine Abfrage, dass diese, also ich weiß von Explorer, dass also ich, wenn ich das hier zurückgehe in mein Modell, zum Beispiel. Ich wusste, dass es gibt die zwei Spalten und dann und ich möchte aber hier die das Ergebnis so aussehen, wobei First und Last Name Spalten kombiniert als einen Namenspalten angezeigt, ne, als als eine neue Spalte. Und lass uns sehen, ob DBD es für uns macht. Ja, wir können hier sehen, dass Co Pilot hat für uns eine neue Abfrage erstellt, wo jetzt eine neue Berechnung oder einen neuen SQL Satz da steht, drinsteht. Und damit kriege ich hoffentlich, Drum, ja, genau, kriege ich die Werten von Kunden oder ich kriege die Liste von Kunden, die nicht nur ihren Wert mehr als fünfzig haben, sondern in einer Bestellung haben mehr als zehn bestellt. Und jetzt bin ich mit diese Analyse zufrieden und ich möchte, dass ich sollte diese, was ich hier bekommen hab, als ein Modell umwandeln. Wie kann man das tun? Das sehen wir gleich. Ja, danke. Dann würd ich sagen, springen wir in den dritten Punkt, den wir heute haben, in unseren Drag and Drop Editor Canvas. Hier kann ich praktisch Models aufbauen, ohne dass ich große, tiefere gehende SQL Kenntnisse haben habe oder einfach einen anderen Weg haben möchte, wie ich mit meinen Models arbeite, wie ich meinen Models aufbaue, nämlich einfach per Drag and drop mir praktisch meine oder mein Model zusammenbaue. Und wenn ich in Canvas rein starte, dann sehe ich das hier zuerst praktisch. Praktisch meine Fläche, hey, hier kann ich das aufbauen und damit arbeiten, was ich möchte, dann habe ich hier verschiedene Möglichkeiten. Ganz links sehen wir, okay, ich kann mitm Input starten, also bestehende Models oder Sources nutzen und diese dann verwenden als Quelle der Daten für mein Model in Canvas. Oder ich kann hier verschiedene Transformation einbauen, mit meinen Daten wirklich etwas machen und verschiedene Models oder verschiedene Quellen zusammenjoinen, kann verschiedene Aggregationen aufbauen. Ich kann mein Ergebnis limitieren, kann es ordnen, filtern, umbenennen. Alles das, was ich möchte, kann ich praktisch hier in Canvas auch machen. Und zu guter Letzt haben wir den Output. Was kommt für ein Model raus? Wie heißt das Model und wo wird es zum Beispiel gespeichert? Wir einfach mal hier jetzt starten und einen Input nehmen, sehen wir auch sehr schnell, okay, mir wird ein Input hinzugefügt und ein Output. Also was benutze ich und wo würd es nachher dann auch liegen? Wie würd mein Model heißen und wo würd es gespeichert? Kümmer ich mich gleich drum, lass uns erst mal praktisch das Model aufbauen. Und dazu sag ich einfach, okay, ich möchte gerne mal mit den Orders arbeiten, hab ich mir vorher im Katalog angeguckt. Da sind die Informationen, die ich haben möchte und die ich brauche. Hier kann ich dann auch direkt noch mal in Canvas sehen, okay, das sind die verschiedenen Spalten, die ich zur Verfügung stehen habe und ich seh direkt, hey, okay, ist da und der ist da. Das sind die beiden Informationen, die ich gerne haben möchte. Und sage ich hier, okay, und mach's mir jetzt einfach, ich sag einfach, hey, ich möcht grad gar keinen Spalt haben und dann füg ich einfach wieder die hinzu, die ich brauche. Wie grad schon gesagt, das ist der und der Status Code. Ich möchte mich wissen, wie viele Kunden sich in den verschiedenen Statuscodes, die wir hier haben, befinden. Das zu bauen, könnte ich SQL benutzen, aber ich kann natürlich auch hier in Canvas das machen. Ich schließe hier einfach mal den. Ich seh, okay, fünfzehntausend Spalten kommen raus, aber nur zwei Spalten werden gerade benutzt. Ich seh das praktisch hier noch mal zusammengefasst, was hier denn rauskommt aus meinem Input. Und jetzt möchte ich mit diesem Input gerne arbeiten und sage, ich kann mir das natürlich hier auch den rausziehen, nämlich eine Aggregation oder ich geh einfach auf das Plus und sage, hey, füg mir bitte eine Aggregation hinzu und sag ihnen auch praktisch, okay, hey, ich möchte gerne über den Status Code gruppieren und alle zählen, die sich in den verschiedenen Status Codes befinden. Kann hier unten auf klicken und sehe jetzt praktisch mit einem Blick, was passiert in diesem Schritt. Ich sehe, was kommt rein, was kommt raus und sehe hier unten, hey, ich hab drei verschiedene Statuscodes und so viele befinden sich aktuell in den verschiedenen Statuscodes. Und so hab ich schon die Information, die ich haben wollte. Ich wollt mich wissen, wie viele Kunden sich in den verschiedenen Statuscodes befinden. Ja, ist fertig. Das Model habe ich mir jetzt einfach hier per Drag and drop zusammengezogen und kann jetzt hier im Output noch sagen, speichern wir das bitte gerne in und das Ding heißt customer Status Code. Und könnte jetzt das Ganze hier oben rechts committen, kann es laufen lassen und hätte dieses Neumodell dann in meinem, in meiner Datenbank und, mit diesen Daten oder mit diesem Neumodell zu arbeiten. Das Coole an Canvas ist, die Logik, die ich jetzt hier habe, versteckt sich nicht komplett hinter diesem kleinen kleinen Kästchen. Und ich weiß nicht, was macht er denn jetzt genau im Hintergrund? Wie wird das Ergebnis? Das Ergebnis sieht gut aus, aber wie kommt er denn zu dem Ergebnis? Und dazu kann ich hier oben auf den kleinen SQL Button klicken und im Hintergrund wird für mich SQL Code erstellt. Bedeutet, jeder kann weiterhin mit diesem Model auch arbeiten. So wird's im abgelegt und möchte jetzt ein anderer Kollege, der eigentlich mit Studio arbeitet, dieses Model bearbeiten, kann er das auch in Studio tun. Er muss nicht Canvas nutzen, er kann das hier tun und dann einfach SQL Code lesen und Änderungen in SQL direkt vornehmen. Jetzt komme ich zu 'nem Punkt zwei, drei Tage später, hey, mir fehlt eigentlich noch eine Information. Also das, was ich hier gebaut hab, war cool, aber mir fehlt noch eine Information. Ich möchte mich gerne wissen, hey, pro Nation Key möchte ich gerne aussehen oder pro Kunde möchte ich noch sehen, in welchem befindet sich die der die verschiedenen Kunden und wie viele sind das dann pro Status Code? Dazu kann ich erst mal zunächst hier auch noch mal auf die Orders gehen und kann hier gucken, hey, hab ich diese Information denn schon hier verfügbar? Und ich sehe, hab ich leider nicht. Das Problem ist, okay, ich muss andere Informationen mir deshalb dazu holen. Ich war im Katalog, hab gesehen, okay, diese Information befindet sich in den. Ich weiß es aber nicht genau, ich könnt mir jetzt per Input den hier zunehmen, könnte das per verbinden und so weiter und so fort. Ich weiß aber nicht genau, wie das funktioniert mit den Joints. Daher hilft mir wieder mein Copilot. Ich hab mir einfach 'n kleinen Prompt geschrieben und sage hier praktisch, hey, behalte das existierende Model so wie es ist bei, weil das ist super, zeigt mir die Informationen an, die ich haben möchte. Und verbinde die beiden Tabellen über den Customer Key und passe mein Modell so an, dass nicht nur nach dem Status Code gruppiert wird, sondern auch nach dem Nation Key, die er dann jetzt über dieses Customer Model bekommt. Und diese Information gebe ich praktisch meinen Copilot und er analysiert jetzt wieder verschiedene Modelle und generiert mir praktisch die verschiedenen Schritte in Canvas, die ich dafür brauche, an diese Informationen zu bekommen. Ich klicke hier und seh dann sehr schnell, das ist das, was ich vorher hatte und das ist das, was jetzt hinzugekommen ist, also was der Copilot mir praktisch vorschlägt. Ich seh hier, okay, das ist mein Ordermodel und hier haben wir jetzt 'n kleinen Rename, damit man ja praktisch weiß, okay, dieser kommt aus Orders. Wenn ich jetzt da ein bisschen runtergehe, sehe ich, okay, er hat mir Customer auch hinzugenommen und hier fügt er auch einen Rename hinzu, Customer Key mit einem kleinen Zeh davor, dass er weiß, okay, dieser Customer Key kommt aus den Customer Modell. Hier hätte er mir hinzugefügt. Hey, cool, hat er automatisch gemacht und auch über den. Hier sehen wir unsere, wie wir vorher auch hatten. Vorher hatten wir nur. Und jetzt sehen wir hier und. Super, genau das, was ich haben wollte. Also klick ich auf. Er übernimmt das Ganze und ich kann einfach mal hier reinspringen und sagen, hey, in meiner Preview sehe ich, super, also ich seh, in welchem pro Code sich wie viele befinden. Aber ich seh auch, ah, das ist nicht so wirklich gut leserlich als Tabelle. Es ist 'n bisschen durcheinander. Okay, fragen wir doch mal unseren Co Pilot. Hey, das ist super, was Du gemacht hast. Aber bitte ordne mir das Ergebnis jetzt noch erst nach und dann nach Status Code, einfach nur, damit ich die Tabelle besser lesen kann. Und die Information geborene ich ihm natürlich auch wieder. Er analysiert wieder verschiedene Models und generiert mir die verschiedenen Schritte, die er benötigt, das, was ich von ihm möchte, zu realisieren. Auf, seh ich wieder, kann's noch mal kontrollieren, okay, das ist alles gleich geblieben, super. Hier macht er nach nach der und kleinen Rename. Weiß ich nicht, ob ich das genau brauch, kann ich vielleicht raus löschen. Aber hier hat er jetzt ein Order eingebaut und sortiert erst nach dem Key und dann nach dem Status Code. Sieht gut aus. Klick auf und kann jetzt einfach mal hier ganz am Ende im Output auf klicken, Ash springt in die Preview. Und ich seh auf einen Blick, super, Status Code geordnet, Ich kann jetzt wirklich sehr leicht sehen pro, wie viele Customer befinden sich in den verschiedenen Statuscodes. Also sehr gut umgesetzt dieses neue Model, was ich haben wollte in Canvas und wie eben schon gezeigt, es wird im Hintergrund komplett SQL Code erzeugt. Dieses Model kann ich jetzt committen und dieses Model kann von meinen Kollegen, die gerne Studio und supercool mit SQL umgehen können, weiter genutzt werden, bearbeitet werden, ergänzt werden, was man möchte. Man kann also wirklich nahtlos zwischen der SQL Experience in Studio und der Drag and Drop Experience in Canvas hin- und herspringen und jeder kann so praktisch dann seinen gewünschten Weg wählen, wie er denn neue Models erstellen möchte in DBT. Wichtig ist auch, ich kann auch bestehende Models bearbeiten. Also ich bin praktisch nicht so familiär mit SQL. Ich mag mein Canvas, ich arbeite gern mit Canvas, aber große, bestehende Models, ja, sind meistens von Kollegen ins Studio gearbeitet worden. Wie man reicht das jetzt? Und ich kann auch hier einfach, hey, Ich hab hier mal das dem Customer Model hinzugefügt und hier sehen wir auf einen Blick, ja, das Ding ist schon etwas größer. Ich sehe hier auch den SQL Code, das sind viele Zeilen Code. Aber ich möchte einfach nur eine neue Spalte hinzufügen und das einfach mal testen, macht das Sinn für meine Dashboards, die ich gerne benutzen möchte? Soll ich sollt ich das mal hinzufügen? Und da spring ich einfach an die richtige Stelle beziehungsweise ich spring einfach mal an die Stelle, wo ich denke, dass sie richtig ist, hier nehm ich ganz am Ende und sage, hey, füg mir mal bitte eine Formula hinzu. Und diese Formula hab ich vorher vielleicht in Insights geschrieben oder in meiner Snowflake oder anderen Datenbank direkt und füge diese hier hinzu. Ich sag einfach, hi, pro Lifetime, wenn Du über drei Millionen bist, bist Du ein Goldkunde, bist Du über zwei Millionen Silber und sonst bist Du halt Bronze. Und füge das mal einfach hierzu und sag, hey, das ist unser new Status, den probieren wir aus, damit unsere Kunden ein bisschen besser zu flecken. Oder ja, springen hier in mein Output und kann sehen, wenn ich ganz nach rechts scroll, hier ist der New Status, hat funktioniert. Aber ich möchte gerne, hey, der, der ist so wichtig grade und kann hier auch einfach sagen, hey, den switch ich mal nach oben direkt hinter den, weil das ist der Punkt, wie wir neu jetzt Kunden selektieren wollen und er schiebt mir dann auch den New Status nach vorne. Und wenn ich jetzt diese Änderung nehme und sie in, ja, in meinen Jobaufbau ausrolle auf meine nächst höheres Environment, auf meine Datenbank, dann wird die Sendung auch durchgeführt. Ich hab mein drin und habe so auch ein bestehendes Model so bearbeitet, dass dieser jetzt verfügbar ist und musste dafür keine einzige, ja, bisschen Zeilen SQL schreiben beziehungsweise nur diese könnte mir auch wieder bei helfen und habe jetzt in einem bestehendes Model diese neue auch hinzugefügt. Und als letzten Punkt möchte ich gerne noch zeigen, den Kreis son bisschen zu schließen, wenn wir in sind, hier praktisch, das war eine kleine Query, die ich mir immer geschrieben habe, Nichts Wildes, hab ich in Insights gearbeitet und möchte das jetzt gerne vielleicht erweitern. Oder diese Query hab ich von 'nem Kollegen bekommen, hab mir mein Kollege da drüber geschickt, hey, das hab ich grade in Insights geschrieben. Kannst Du das mal bitte ausrollen auf die Datenbank? Ich möchte das gerne machen. Ich hab nicht die richtigen Zugänge zum Beispiel. IT Team ist wieder ist überlastet. Das dauert vielleicht eine Woche. Ich kann das aber mit Canvas machen und kann hier oben dann einfach direkt sagen, ich könnt's auch 'n Studio machen, aber ich bin 'n Canvas Fan und sag, okay, ich möcht das gern Canvas machen und er übersetzt mir direkt dieses SQL, was ich grade hatte, nach Canvas, baut hier die verschiedenen Schritte ein und ich könnte das jetzt committen. Ich kann's natürlich auch bearbeiten, kann ihn noch die verschiedenen Schritte umbenennen zum Beispiel oder er hat gesagt, hey, kannst Du vielleicht noch mal eine neue Spalte hinzufügen? Könnte ich jetzt auch hier in Canvas machen und diese Query dann auch noch bearbeiten, die mir mein Kollege rübergeschickt hat und mit Canvas so einarbeiten, dass ich das praktisch committen kann und ausrollen kann. Gut, dann würde ich sagen, das war der Ausblick oder das war die kleine Einsicht in Canvas, was man mit Canvas machen kann. Mit Canvas kann man echt coole Sachen machen. Wenn ich nicht so gern mit SQL arbeite oder lieber eine Drag and Drop Experience habe, kann ich Canvas nutzen. Ich kann bestehende Modelle anpassen. Ich kann neue Modelle aufbauen. Ich kann mir das hin- und herschicken. Ich kann mir meinen Studiokollegen nahtlos ineinander überarbeiten und habe hier praktisch kein Problem, in meinem Team zusammenzuarbeiten und kann wählen, welchen Weg möchte ich denn gehen, neue Models zu erstellen, Mehrwert zu schaffen für mein Unternehmen. Ja, also Darf ich sagen, dann sind wir am Ende angelangt, richtig? Ja. Wenn da Fragen sind, Anregungen, wir können jetzt auch ein paar Minuten in den ein paar Minuten die diskutieren, Sonst würden wir sagen, vielen Dank fürs Mitmachen. Und Sie haben es vielleicht gesehen, also wie mächtig diese Features sind schon von Entdeckung bis Entwicklung, auch wenn ich, oder auch wenn man nicht technisch fleißig ist oder nicht mit Programmierung fleißig ist, kann trotzdem man erreichen. Und ja. Ja, von von mir vielen Dank. Und ja, wenn Fragen sind, gerne Fragen. Ja, gerne. Die Aufzeichnung kann man sich immer angucken. Wird wie gesagt zugesendet, wird auch online auf der Internetinterworks Seite, soweit ich was verstanden hab, bereitgestellt. Also gerne noch mal mal reinsehen dann. Wenn Fragen sind, gerne auf uns zukommen. Dann können wir auch noch mal genauer vielleicht Sessions in bestimmte Features machen.

In diesem Webinar erklärt Marc Antort, wie dbt die Self-Service-Analytics revolutioniert. Er betont die Bedeutung der Zusammenarbeit zwischen Data Engineers, Power Analysts und Business Usern, um datengetriebenes Arbeiten zu ermöglichen. Mit dbt können Analysten Daten einfacher entdecken und analysieren, ohne tiefgehende SQL-Kenntnisse zu benötigen. Die Plattform bietet Funktionen wie den dbt Katalog und dbt Insights, die den Zugang zu Daten erleichtern und die Erstellung von Modellen vereinfachen. Am Ende des Webinars werden die praktischen Anwendungen und Vorteile von dbt demonstriert.

InterWorks uses cookies to allow us to better understand how the site is used. By continuing to use this site, you consent to this policy. Review Policy OK

×

Interworks GmbH
Ratinger Straße 9
40213 Düsseldorf
Germany
Geschäftsführer: Mel Stephenson

Kontaktaufnahme: markus@interworks.eu
Telefon: +49 (0)211 5408 5301

Amtsgericht Düsseldorf HRB 79752
UstldNr: DE 313 353 072

×

Love our blog? You should see our emails. Sign up for our newsletter!